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

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

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 ?

yes/no, but i'll give you a workaround.. :wink:

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...

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:

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

Which was right before the change..

Regards,

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...

Regards,

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

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..

Regards,

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.

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

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,