Issue using XDS100v2 when moved to a new version 4.1.18-ti-r49

[gnu gnu]

Hi,

I am trying to setup Jtag connection(with xds100v2) to debug Uboot and TI mainline kernel 4.1.y branch.

I am following Robert nelson's instructions at this link: https://eewiki.net/display/linuxonarm/BeagleBone+Black and flash emmc with the uboot,kernel and filesystem.

When I was on kernel_version 4.1.13-ti-r34, I was able to connect to target and debug uboot(I did not try Linux debug though o this version). Later I realized that I have forgot to include "build kernel with debug info", so I re-run build_kernel.sh, it moved kernel to 4.1.18-ti-r49, where I am unable to do any jtag debugging.

Currently with the new build flashed to emmc, I halt uboot from booting linux kernel and then connect Jtag, it all works fine till this point. Next if I run the target using CCS UI, instead of resuming, uboot resets itself. I suspect on resume somehow the board is getting reset.

I did not see this behaviour in the earlier version. But since I am not a git expert I do not know how can I move back to the previous tag.

So two questions:

1. Is this a known bug on 4.1.y branch ?

2. How can I move back to 4.1.13-ti-r34 tag.

Regards

Nagla

[Robert Nelson]

yes/no, but i'll give you a workaround.. ;)

> 2. How can I move back to 4.1.13-ti-r34 tag.

You can't, atleast not from that build script..

Users wanted "P9_41" back under userspace control, this was
"clkout2_pin" which is xdma_event_intr1.clkout2 tied to the jtag...

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/270d9d3268e648b2fa891ea92bdc04d42586746a

I'll add the clkout2_pin back as an include you can use with the
"dtb-rebuilder" to re-enable it.

right now, you can grab the dtb-rebuilder:

https://github.com/RobertCNelson/dtb-rebuilder/commits/4.1-ti

and checkout "4.1.17-ti-rt-r47" aka: bf7939dd0aa7af8ffdd7061fc31d1af7d5d31dd5

Which was right before the change..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Robert Nelson]

On Thu, Mar 3, 2016 at 8:00 AM, Robert Nelson <robert...@gmail.com> wrote:
> On Thu, Mar 3, 2016 at 1:11 AM, gnu gnu <nagla...@gmail.com> wrote:
>>
>> Hi,
>>
>> I am trying to setup Jtag connection(with xds100v2) to debug Uboot and TI
>> mainline kernel 4.1.y branch.
>> I am following Robert nelson's instructions at this link:
>> https://eewiki.net/display/linuxonarm/BeagleBone+Black and flash emmc with
>> the uboot,kernel and filesystem.
>> When I was on kernel_version 4.1.13-ti-r34, I was able to connect to target
>> and debug uboot(I did not try Linux debug though o this version). Later I
>> realized that I have forgot to include "build kernel with debug info", so I
>> re-run build_kernel.sh, it moved kernel to 4.1.18-ti-r49, where I am unable
>> to do any jtag debugging.
>> Currently with the new build flashed to emmc, I halt uboot from booting
>> linux kernel and then connect Jtag, it all works fine till this point. Next
>> if I run the target using CCS UI, instead of resuming, uboot resets itself.
>> I suspect on resume somehow the board is getting reset.
>>
>> I did not see this behaviour in the earlier version. But since I am not a
>> git expert I do not know how can I move back to the previous tag.
>>
>> So two questions:
>> 1. Is this a known bug on 4.1.y branch ?

and here's the easy workaround:

https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/94adc3cac2ac9d9ed16cff2d425acb92d7b243f0

./build_kernel.sh

stop build after menuconfig pop;s up:

edit:

KERNEL/arch/arm/boot/dts/am335x-boneblack.dts

/* #include "am335x-bone-jtag.dtsi" */ -> #include "am335x-bone-jtag.dtsi"

./tools/rebuild.sh

jtag back...

[gnu gnu]

Thanks Robert... But as I mentioned earlier I am not at all good at git, so could you please let me know what commands I need to run ? Right now my kernel makefile points to 4.1.18

One other thing which I am unable to get is that since with the with new build I stop uboot into loading and running the linux kernel(basically i am at uboot command prompt), so why do I see this issue while in earlier version its not present?  Pinmux settings will come into picture only when debugging Linux kernel if I am right.Why should it affect Uboot debug, where uboot repo and build does not change at all?

Regards

Nagla

[Robert Nelson]

On Fri, Mar 4, 2016 at 8:10 AM, gnu gnu <nagla...@gmail.com> wrote:
> Thanks Robert... But as I mentioned earlier I am not at all good at git, so
> could you please let me know what commands I need to run ? Right now my
> kernel makefile points to 4.1.18

So delete the repo and re-clone, then follow the guide posted in the
previous message..

>
> One other thing which I am unable to get is that since with the with new
> build I stop uboot into loading and running the linux kernel(basically i am
> at uboot command prompt), so why do I see this issue while in earlier
> version its not present? Pinmux settings will come into picture only when
> debugging Linux kernel if I am right.Why should it affect Uboot debug, where
> uboot repo and build does not change at all?

Sorry, i never bother with jtag debugging. I just gave you an easy way
to revert the functionality i had changed by default..

[William Hermans]

One other thing which I am unable to get is that since with the with new build I stop uboot into loading and running the linux kernel(basically i am at uboot command prompt), so why do I see this issue while in earlier version its not present?  Pinmux settings will come into picture only when debugging Linux kernel if I am right.Why should it affect Uboot debug, where uboot repo and build does not change at all?

THis is not necessarily true. uboot at minimum can do *some* pinmux control. As it has the to use I2C, which in the case of the beagebone boards is sometimes used to determine which board file to load. Through reading the onboard eeprom, which sits on an I2C bus . . . At least that's my understanding.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[gnu gnu]

I tried everything in my knowledge and googling through, to move back to tag 4.1.13-ti-r33 but I get errors. So is there no way to move back to a tag... even when I clone a new repo ??  Pls help. Your last instructions were not clear to me, so want to move back to working version i.e4.1.13-ti-r33 

.

1. Tried to create a new repo 

git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git

cd ti-linux-kernel-dev/

git checkout tags/4.1.13-ti-r33

./build_kernel.sh

2.tried to switch to a new tag on exisiting repo

git reset --hard 4.1.13-ti-r33

./build_kernel.sh

Error:

Applying: Fix remoteproc to work with the PRU GNU Binutils port

error: drivers/remoteproc/pruss_remoteproc.c: does not exist in index

Patch failed at 0001 Fix remoteproc to work with the PRU GNU Binutils port

When you have resolved this problem run "git am --resolved".

If you would prefer to skip this patch, instead run "git am --skip".

To restore the original branch and stop patching run "git am --abort".

Regards

Nagla

[Robert Nelson]

On Mar 6, 2016 1:23 AM, "gnu gnu" <nagla...@gmail.com> wrote:
>
> I tried everything in my knowledge and googling through, to move back to tag 4.1.13-ti-r33 but I get errors. So is there no way to move back to a tag... even when I clone a new repo ??  Pls help. Your last instructions were not clear to me, so want to move back to working version i.e4.1.13-ti-r33 
> .
> 1. Tried to create a new repo 
> git clone https://github.com/RobertCNelson/ti-linux-kernel-dev.git
> cd ti-linux-kernel-dev/
> git checkout tags/4.1.13-ti-r33
> ./build_kernel.sh
>
> 2.tried to switch to a new tag on exisiting repo
> git reset --hard 4.1.13-ti-r33
> ./build_kernel.sh

You can't, one of the git reps we pull is constantly changing with no tags..

Just do what I said, as I pushed a special patch for you to enable.

Regards,