JLINK gdbserver and jtag debugging with Raspberry Pi 2

[tarkshya]

Hello Friends,

Has anyone tried setting up segger's j-link, with its GDB server on a Raspberry Pi 2, the cortex-a7 version.

On a B+ (arm 11 version), the GDB server (GUI version) crashes, command line server doesn't crash, but doesnt work either. probably i feel it doesn't support broadcom's ARM11, may be i am wrong. Don't have a raspi 2 with me, hence asking.


I specifically want to know about segger j-link (with segger's GDB server) on Raspi 2, if anyone as any information, kindly let me know.


Thanks
Tarkshya

[dwelch67]

the gpio pins are multiplexed, to connect the jtag to external I/O you need a little code to do that. https://github.com/dwelch67/raspberrypi armjtag or whatever I called it. the little bit of code will make those connections then you can wire up your favorite debugger and talk to the arm.

[tarkshya]

Hello David,

I intially went with your example (yours is a well known repository on the net) and was able to get jtag working, but it works with other jtag debuggers like lauterbach, but not with jlink. Kindly also note, this is with Raspberry Pi B+ and not with Raspberry Pi 2 (as i dont have that model).

Again, am NOT using openocd, i am talking about JLINK's gdbserver, both UI and command line version, with arm-none-eabi-gdb, which doesnt seem to work with B+ too.

If someone having a JLINK and Raspberry Pi 2/Pi 3 could confirm that it works, with JLINK's GDB server and arm-none-eabi-gdb, that would help.


Thanks
Tarkshya

[dwelch67]

Step one is exposing the signals to the outside world, step two wire it up, step three get the software working. I was just getting you past step one. I assumed you werent interested in the openocd stuff I have.

The title of this question is raspberry pi 2 yes? So I assumed that is what you were talking about, a raspberry pi 2.

If it works with lauterbach, then my guess it is either how you wired up the jlink or a jlink config or software settings, or your jlink is broken, does your jlink work with anything not raspberry pi? have you checked it lately with something else? Does your jlink and/or jlink software support the cortex-a7? I am still not entirely sure if you are talking about the pi2 (cortex-a7) or the pi1 rev 2 (B+, A+, etc) (arm11).

David

[tarkshya]

Hello David,

My Jlink setup works with Cortex-M4, ARM7 TDMI chips, that i have tested. I've verified the wiring its all correct (used JLINK's gdbserver, and arm-none-eabi-gdb)

Here is what is happening - Kindly Note, the server in question is JLINK's gdbserver (you can find it inside jlink's installation directory - should be something like jlinkgdbserver.exe).

The debugger being used is arm-none-eabi-gdb

For Raspberry Pi B+ (ARM 11), it detects the chip as ARM11, but setting breakpoints, reading data etc don't work as expected, when i try to print variables, its giving me garbage. It is to note the same setup with lauterbach (&trace32), does everything fine.


For Raspberry Pi 2 (ARM cortex A7) and Raspberry Pi 3 (Cortex A53), i was not able to test it, as i dont have the boards right now.


Would it be possible for you to test both the boards (Pi2 - cortex A7 and Pi3-cortex A53) with JLINK and JLINK's gdbserver?


Thanks
Tarskhya

[tarkshya]

i couldn't test it with other Cortex-A7 boards (as nothing is with me right now), JLINK is a full featured pro version, so should support cortex A7. I suppose there is a problem with JLINK's gdbserver.exe software, but i am not sure, if only someone could verify it on his/her setup, that would help.

When i try to debug on B+ (arm 11), it reports some register not implemented error (i can tell you the exact error if you want, am not near my setup right now).

If you are using any specific config file for the broadcom ARM11, Cortex-A7 etc processors, then kindly let me know.

As mentioned, i have not tried it on Raspi 2 or Rasp 3 (cortex A7 & A53 versions). I am not sure whether its specific to JLINK's GDB server, hence someone needs to test it on his/her setup, with the said GDB server.



Thanks
Tarkshya

[henry10210]

Hello, I realize I am 1.5 year late on this thread. I've been learning about Cortex-A7 and A53 in the last month and just confirmed with SEGGER what you guys hint at (could not parse what you guys were talking about in my ignorance): SEGGER does not support RPi. But they did tell me that making a JLinkScript is very doable. Apparently RPi 2 cores (all 4 of them) are APB-AP, and someone posted the base address of those AP. I have been trying to find document where they get that information. Normally such information is in the chip data sheet or programmer's guide but in in case of BCM2836/7 I have yet to find anything close. I aim to share the JLinkScript I am writing with the J-Link/RPi bare metal community. I spent the entire weekend reading the ADI (ARM debug interface) specification and coresight 3.0 TRM. If anybody knows a less painful way to piece together a clear understanding of the necessary interface between BCM2836 and J-Link, please enlighten me.

[dwelch67]

I think you mostly if not completely need to worry about generic armv7 and not raspberry pi specific, the raspberry pi specific part is that they dont have dedicated jtag pins for the ARM, so you need a little code to switch the gpio pins to the jtag function, then you let the debugger in, if the debugger is overly complicated or trying to sell you chip support I would move on, free ones are better. There is the connecting and talking to the arm core, there there is adding support for specific peripherals in a specific chip (supporting the chip specific interface to a flash/storage device for example).

Openocd and a jlink should get you in, if not segger's software, if they have scripts that you can see/modify see what they have for the various armv7 cores, what is common or different between those scripts and make one from the common stuff...

[henry10210]

Thank you for the reply David,
I am surprised that you believe a generic Cortex A7 config will work out of the box for RPi, because that's exactly what SEGGER support said would NOT work (after I bought the $700 J-Link Ultra).

Maybe I made a mistake when I compiled openocd, but I did not find an RPi or BCM238x cfg files in /usr/local/share/openocd after "make install". I did find your bcmrpi2.cfg and tried that out, like this:

parallels@ubuntu:/usr/local/share/openocd/scripts$ openocd -f interface/jlink.cfg -f board/rpi2.cfg
...
Info : JTAG tap: bcm2836.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
Error: JTAG-DP STICKY ERROR <-- sometimes I don't get this; haven't figured out why
Info : accepting 'gdb' connection on tcp/3333
Error: target not examined yet

Error: Register map is not available yet, the target is not fully initialised
Segmentation fault (core dumped)

I found that all the JTAG action happens initially, before gdb target remote :3333 command--which leads to the openocd crashing, as you can see above. It must mean that something is getting left out in bcmrpi2.cfg so that the target is not "examined" up front.

I am going to try your bcmrpi2.cfg tonight again, and match that against the OpenOCD manual.

P.S. I quite appreciate the service you've done to the community with your metal repo. You are one of the rare birds who can "do" AND "teach".

[tarkshya]

Hi Henry,


did you try this with jlink's GDB server? When i tried, i didnt have jlink ultra or plus, only the base model(that too version 8), that refused to work even with the basic B+ (arm 1176). Though i could load basic bare metal programs, but couldn't properly set any breakpoints (only b+).

Did you check this link ? http://sysprogs.com/VisualKernel/tutori ... jtagsetup/

In the link above, they use B+ with openocd. Did you try with openocd 0.10.0 (probably you did?). What i would suggest is to google for Raspberry Pi 3 (yes PI-3 cortex A53) jlink openocd config file (there are a lot of similar variants on various github repos) and modify it for cortex A7 (or raspberry pi 2 case).

for e.g. https://github.com/daniel-k/openocd/blo ... t/rpi3.cfg

see this - http://apeman0.blogspot.com/2017/07/ras ... l-and.html

or see this - [url]https://gist.github.com/jitomesky/4b564 ... 359d9d[url]

one thing to note in the above config (for rpi3) is the use of "aarch64". If you change that to cortex_a, and try with cortex a7, it should show something (atleast recognize some cores or like that), i had very limited success in getting jtag recognized on cortex a7 (but i suspect thats because of my v8 jlink).


You do mention that you tried with bcmrpi2.cfg from dwelch's repo. I tried too (long back), but somehow i couldn't get it to work. But when i modified other rpi3/rpi2 config files (found from different github repos) for cortex_a, i did have very limited success (like it recognized cores etc), that too on a v8 jlink (which per segger doesn't officially support cortex a7). Two of those links i have mentioned above.



On a side note -
Although you mention that you spent around $700 for jlink, there are several cheaper options available (like ftdi based, flyswatter, olimex etc). One of the best jtag debuggers out there is lauterbach. A brand new version costs several thousand dollars, but on ebay you can find several second hand models for as less as $300-$400 (if you are lucky, for your required arm architechture). You can download the demo trace32 software from their website (its 30 mins time limited software, but with full functionality). Also if you want full functionality of the software, it costs around $400 dollars, but worth the money. I had access to lauterbach and i tested my raspberry pi b+ & 2 with it, both work very well. And their website provides config files for bcm2835, 2836, 2837.



Thanks
Tarkshya

[henry10210]

Thank you very much for the detailed explanation Tarkshya, I appreciate your taking the time.
Yes, I've read that sysprog webpage probably dozens of times now. Just getting the TDI to respond in response to my JLinkExe command took a lot of time. I actually turned on "--debug 1" on the openocd command last night and tried dwelch67's bcmrpi2.cfg again. It looks like my RPi2 is returning some (garbage?) unexpected value while openocd is querying the DAP IDR register, and interpreting that as a STICKY error bit. I messed around with different base address value, and even got past that stage but gave up after a couple of hours because it seemed like I was fumbling in the dark (again). I think I have tried modifying those rpi3.cfg for cortex_a7 without success, but that's already like a month ago, so I am fuzzy on the detail. It might have been when I was trying them with JLinkGDBServer instead. Since I now have slightly better understanding of the ADI, Coresight, DAP, etc, I should actually circle back and try your suggestions again.

Tarkshya, do you have some interest in using J-Link software for the RPi work? If so, would you be willing to work with me (help me out) to write a proper JLinkScript for RPi2 if I sent you my J-Link Plus v9.3 (you can keep it)? Please don't take this any wrong way; I am not proposing a this-for-that. It's just that I am partial to SEGGER SW (I laughed while reading one of dwelch67's README: he wrote that free tools are better--I'd like to have beer with him some day). A week ago, I wrote confidently on SEGGER forum that I would like to share my JLinkScript with the community, but since then have lost the patience to figure out the JLinkScript necessary to talk to RPi2; I just didn't know how little I knew about the ARM debug system. I do want to know more, but I am impatient to start my AMP bare metal FW development on RPi, so looking to get some help. Hope you will be interested in my proposal.

[henry10210]

It dawned on me today that u-boot (which I am using as the bootloader) might have configured the cache and MMU differently than the bare metal setup shown in dwelch's armjtag example. So I tried to remap the GPIO ALT functions to TAG mode in a Linux user mode program (Sysprog provided example), and found that openocd succeeded in connecting to RPi2's BCM2836 using dwelch67's bcmrpi2.cfg. It's slow as molasses for some reason, but it did work at least once.

Now I am going to have to understand how u-boot setups up cache and MMU!

[jspeccy]

Now I am going to have to understand how u-boot setups up cache and MMU!

What I can remember is that u-boot changes the VBAR register and you need to invalidate the unified TLB on MMU init.

As specified in ARM Cortex-A Series Programmer's Guide (DEN0013D), section 8.8, after disable MMU is needed to invalidate L1-Cache, TLB and branch predictor (point 2 from sample code). U-boot disables the MMU, but don't do any additional action.

[henry10210]

Thank you very much for the tip jspeccy. To understand you, I spent today just reading the disassembly of the u-boot (built after make rpi_2_defconfig). In cpu_init_cp15 (called right after setting the VBAR), the MMU AND the cache are both disabled.

What I can remember is that u-boot changes the VBAR register and you need to invalidate the unified TLB on MMU init.

As specified in ARM Cortex-A Series Programmer's Guide (DEN0013D), section 8.8, after disable MMU is needed to invalidate L1-Cache, TLB and branch predictor (point 2 from sample code). U-boot disables the MMU, but don't do any additional action.

I am still mystified at 3 things:
If U-Boot is running with cache and MMU disabled; just writing to the GPIO ALT function registers as I have done in my standalone program (which is unnecessary, since you can do exactly the same thing with mw.l command like this example:

Code: Select all

mw.l 0x3f200000 0x04a020
mw.l 0x3f200008 0x65b6c0

)
It still doesn't work, so I started thinking there is another problem. On the other hand, I see consistent use of "DMB SY" in U-Boot code, so that is doubly puzzling. If cache and MMU are disabled as U-Boot claims (in top level README), why even bother calling DMB SY in writel(), for example? This suggests that the cache IS turned on?

I am beginning to think that chasing whether my U-Boot standalone program is correctly writing the GPIO peripheral register, since I DO see TDI line moving in the logic analyzer; if the ALT functions were not written correctly, I would expect TDI to not respond at all!

I think I may just have to start recapitulating armjtag example from the bare metal repo....

[henry10210]

Just confirmed that dwelch67's armjtag binaries (yes he checked in the binaries, so that I could be absolutely certain I am running the same binary he was) fail to connect openocd in the same way as my U-Boot does. dwelch67's README does not mention anything special he does (other than restarting openocd when he resets the target), so it is a mystery why I get further when remapping the GPIO (the ALT functions) through Linux vs. bare metal. I suspect that I will have to manually parse the DAP packets to understand what is going on.

I usually don't skimp on tools but Lauterbach is out of my price range even for me (especially since I want the armv8 model that can talk to bcm2837)...

[tarkshya]

Hope you will be interested in my proposal.

regarding your proposal (thanks by the way), i have since moved away from jlink. And given my busy schedule, i hardly get any time for these hobby pursuits.

But for your present situation, any reason why you are using uboot instead of directly running your bare-metal programs ?

[henry10210]

Hi tarkshya, I understand.
I started understanding DAP protocol yesterday, and confirmed that I see the problem that openocd is calling out (the STICKYERR bit set). I *think* the root cause is that the system's DBGEN is 0 (what JLinkExe was reporting from the beginning). I have yet to find out how to ensure that the DBG subsystem is turned on. From the DAP SCR returned to openocd, it looks like both the system and the debug power are on, but I can't think of why the DAP will assert the STICKYERR bit suddenly.

But for your present situation, any reason why you are using uboot instead of directly running your bare-metal programs ?

As I reported yesterday, dwelch's armjtag has exactly the SAME PROBLEM with my openocd through J-Link trying to connect to U-Boot. I ordered the FT2232H eval board that is described in the bare-metal README (actually a Chinese knockoff on eBay) so I'll see how that goes. I suspect the problem is on the target end, so FT2232H should exhibit the same problem. Re: U-Boot: My end goal is to enable an AMP (asymmetric multi-processing) on RPi2/3, with the bare-metal FW kicked off as soon as possible after PoR. This means I need a boot loader that can boot multiple cores (I might even run different bare metal on each cores) before booting Linux. U-Boot was the first boot loader I could think of that meets the requirement.

Anyhow, to recap: I AM using bare-metal right now to debug the JTAG part, so I will hopefully understand more within the next week. Since I've never bare-metal programmed an application processor, this is a touch going, but I will hopefully make some progress by the end of the Thanksgiving break.

[tarkshya]

My end goal is to enable an AMP (asymmetric multi-processing) on RPi2/3, with the bare-metal FW kicked off as soon as possible after PoR.

Sorry for my confusion. But isn't raspberry pi's firmware kicking uboot, then uboot kicking your firmware, an unwanted indirection (you can cut that uboot thing) ? Can't you directly use pi's fw (start.elf etc.) to directly run your fw ? (and do whatever amp stuff you want in your fw).

[henry10210]

You are absolutely right about start.elf being able to start the bare-metal FW; that's how dwelch67 runs his bare metal.
But how would I then start Linux after kicking off my bare metal FW on CPU3? I would have to read the zImage (or uImage) from the /boot partition, decompress it, setup the correct CRT, process the linux boot args give that to the Linux image that has been copied to the right place in the DRAM, right? I can write all that (taking god knows how long), or I can just use U-Boot. Are you thinking about something that I am not seeing?

[dwelch67]

u-boot is just bloat that isnt needed, launching linux is fairly simple and the pi folks are doing that without the need for u-boot. if your goal is to run linux this is a bare metal forum. If you want to add a bootloader then thats fine, go ahead and add it. they have done all of the work, initialized dram, etc. so you simply need to launch linux. copy it to ram, copy the dtb and set atags, set r0, etc, branch.

[dwelch67]

reading the entire post, perhaps you want to start with a linux kernel that is single core and/or doesnt use all four cores, use the stock method for loading and running it. insuring the other one/two/three are not being used by linux. then from that linux or later using a custom bootloader you can launch different firmware on each core.

[jlbates]

Successfully connected J-LINK to RPi 1. I believe this same fix applies to a RPi 2. Using jwelch's "armjtag" project, I had to activate the RTCK gpio23 as well as all the others. I guess the RPi requires this pin to be activated even though I did not have the pin wired. Added the following to "armjtag"

ra&=~(7<<9); //gpio23
ra|=3<<9; //alt4 ARM_RTCK

Was able to connect using SEGGER's J-LINK v6.22d GDB Server and Commander. Then connected using OpenOCD with Eclipse. All this was done on windows 7.

Hope this helps.

[Danijel]

On a side note -
... One of the best jtag debuggers out there is lauterbach. A brand new version costs several thousand dollars, but on ebay you can find several second hand models for as less as $300-$400 (if you are lucky, for your required arm architechture). You can download the demo trace32 software from their website (its 30 mins time limited software, but with full functionality). Also if you want full functionality of the software, it costs around $400 dollars, but worth the money. I had access to lauterbach and i tested my raspberry pi b+ & 2 with it, both work very well. And their website provides config files for bcm2835, 2836, 2837.

Thanks
Tarkshya

Hi Tarkshya,
Regarding Lauterbach jtag debuggers.

I just recently purchased RPi 3B+ because I need to test my code on Cortex A53.
The software tools I'd like to use are Windows+Cygwin+Eclipse+GCC toolchain.

Are there JTAG debuggers out there that I could use for this setup? What about Lauterbach, will it work?

My main concern is that they tie the tools to their software, so not sure if I could use my Eclipse setup?

Please advise... Thanks!