Advice on JTAG debugging RTEMS for ARM (beaglebone)
ianc at goanna.iinet.net.au
Mon Jan 4 01:37:58 UTC 2021
For our setup (on an imx6 system), I use GDB to download the u-boot
image (with my FDT) I want into memory (load this one last so it has
the execution address), and the RTEMS image (load first) , and then call
the u-boot image which starts my RTEMS image with the FDT in place.
That way no SD card required and all running in the memory.
On 31/12/2020 4:39 am, James Fitzsimons wrote:
> Hi Christian,
> Thanks very much for this suggestion. I gave it a shot this morning
> and although it's not working yet, I can at least see the PC register
> is pointing to the right location in memory now which is a step in the
> right direction.
> I'll keep investigating as not having to copy to an SD card would make
> the workflow a bit more convenient.
> On Tue, 29 Dec 2020 at 22:20, Christian Mauderer <oss at c-mauderer.de
> <mailto:oss at c-mauderer.de>> wrote:
> On 29/12/2020 05:43, Chris Johns wrote:
> > On 29/12/20 3:24 pm, James Fitzsimons wrote:
> >> Hi Chris,
> >> Thanks very much for your reply and advice.
> >> On Tue, 29 Dec 2020 at 11:58, Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>
> >> <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
> >> > I'm using TI Code Composer Studio to load the RTEMS
> application image via
> >> XDS100
> >> > V3.0 debugger. If I reset the program counter and step
> through the startup
> >> code
> >> > I see it error on the bsp_fdt_get() call.
> >> Is this a crash or is an error reported? We should report
> an error and not
> >> crash.
> >> Neither - the processor continues running, just not executing
> anything useful.
> >> > My IDE isn't copying an fdt image to the expected
> location the way uboot
> >> would,
> >> > and so this makes sense. My question is how do other
> people get around
> >> this problem?
> >> >
> >> > Has anyone else used a similar setup and solved this issue?
> >> I have not hit this issue but I saw this as a problem with
> the approach taken of
> >> loading an FDT via the bootloader. It would have been nice
> to have a way to
> >> integrate an FDT into the IMFS (or executable) rather than
> an external load.
> >> Agreed - this would make it much easier to debug things. Even
> just having this
> >> as an option
> >> to support debugging would be useful.
> >> Another approach is to boot using uboot and have it load
> the FDT and RTEMS
> >> executable then jump to it. If you can connect via JTAG,
> reset the processor,
> >> set a hardware break point on the entry point to RTEMS,
> and start the processor
> >> running from reset it should trigger when uboot jumps to
> RTEMS. The entry point
> >> is at a fixed address. When the breakpoint is hit delete
> it and then you can set
> >> further break points in your application.
> >> Thanks for this suggestion - I've managed to get this working
> pretty much as you
> >> described.
> >> I build the SD card image and boot from that, then connect via
> JTAG, reset and
> >> break on Init().
> >> It's a pretty clunky process, but at least I have actual on
> device debugging
> >> working now instead of
> >> having to rely on printf debugging.
> > Excellent and thanks for reporting it back to us. Yes it is
> clunky however
> > anything else would need time spent adding IMFS support or
> directly linked in
> > support and no one has done that.
> The imxrt BSP uses an FDT that is build into the binary. It should be
> possible to use a similar approach on custom applications for the
> To do that in an application I would expect that you have to do the
> following (I did not test it but it should work):
> 1. Convert the dtb that you want to use to a c file:
> rtems-bin2c -C -N bbb_dtb path/to/your.dtb bbb_dtb.c
> 2. Compile that bbb_dtb.c in your application.
> 3. Add the following to your application (for example where you
> the Init task):
> #include <bsp/fdt.h>
> extern const unsigned char bbb_dtb;
> void bsp_fdt_copy(const void *src)
> /* Do nothing */
> const void *bsp_fdt_get(void)
> return bbb_dtb;
> Be aware of the licensing: The FDTs for BBB that I know are all
> GPL. So
> linking it in as a blob will most likely put your application
> under the
> terms of GPL.
> The licensing is also the reason why I would have problems adding
> an FDT
> blob and an option to link it in directly to the RTEMS repository. If
> you have a FDT that is not GPL please let me know.
> Best regards
> users mailing list
> users at rtems.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users