Advice on JTAG debugging RTEMS for ARM (beaglebone)

[Christian Mauderer]

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
>>      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 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):

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

Christian