Advice on JTAG debugging RTEMS for ARM (beaglebone)

[Ian Caddy]

Hi James,

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.

regards,

Ian Caddy


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.
>
> Cheers,
> James
>
> 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
>     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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20210104/5a234702/attachment.html>