Advice on JTAG debugging RTEMS for ARM (beaglebone)
oss at c-mauderer.de
Tue Dec 29 09:20:10 UTC 2020
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>> wrote:
>> > I'm using TI Code Composer Studio to load the RTEMS application image via
>> > V3.0 debugger. If I reset the program counter and step through the startup
>> > 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
>> 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
>> > 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
>> 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 BBB.
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 define
the Init task):
extern const unsigned char bbb_dtb;
void bsp_fdt_copy(const void *src)
/* Do nothing */
const void *bsp_fdt_get(void)
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.
More information about the users