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 <chr...@rtems.org
<mailto:chr...@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
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
