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. Cheers, James On Tue, 29 Dec 2020 at 22:20, Christian Mauderer <o...@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 <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
