Advice on JTAG debugging RTEMS for ARM (beaglebone)

[James Fitzsimons]

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> 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>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20201231/67f3fe70/attachment.html>