<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi James,</p>
<p>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.</p>
<p>That way no SD card required and all running in the memory.</p>
<p>regards,</p>
<p>Ian Caddy</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 31/12/2020 4:39 am, James Fitzsimons
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAPi7d=Cf-Dkoxo=_+m7RbRksiPSvh9628i7gvdF-ma11CGWu5A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Hi Christian,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I'll keep investigating as not having to copy to an SD card
would make the workflow a bit more convenient.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>James<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 29 Dec 2020 at 22:20,
Christian Mauderer <<a href="mailto:oss@c-mauderer.de"
moz-do-not-send="true">oss@c-mauderer.de</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
29/12/2020 05:43, Chris Johns wrote:<br>
> On 29/12/20 3:24 pm, James Fitzsimons wrote:<br>
>> Hi Chris,<br>
>><br>
>> Thanks very much for your reply and advice.<br>
>><br>
>> On Tue, 29 Dec 2020 at 11:58, Chris Johns <<a
href="mailto:chrisj@rtems.org" target="_blank"
moz-do-not-send="true">chrisj@rtems.org</a><br>
>> <mailto:<a href="mailto:chrisj@rtems.org"
target="_blank" moz-do-not-send="true">chrisj@rtems.org</a>>>
wrote:<br>
>><br>
>> > I'm using TI Code Composer Studio to load
the RTEMS application image via<br>
>> XDS100<br>
>> > V3.0 debugger. If I reset the program
counter and step through the startup<br>
>> code<br>
>> > I see it error on the bsp_fdt_get() call.<br>
>><br>
>> Is this a crash or is an error reported? We
should report an error and not<br>
>> crash.<br>
>><br>
>><br>
>> Neither - the processor continues running, just not
executing anything useful.<br>
>><br>
>> > My IDE isn't copying an fdt image to the
expected location the way uboot<br>
>> would,<br>
>> > and so this makes sense. My question is how
do other people get around<br>
>> this problem?<br>
>> ><br>
>> > Has anyone else used a similar setup and
solved this issue?<br>
>><br>
>> I have not hit this issue but I saw this as a
problem with the approach taken of<br>
>> loading an FDT via the bootloader. It would have
been nice to have a way to<br>
>> integrate an FDT into the IMFS (or executable)
rather than an external load.<br>
>><br>
>><br>
>> Agreed - this would make it much easier to debug
things. Even just having this<br>
>> as an option<br>
>> to support debugging would be useful.<br>
>> <br>
>><br>
>> Another approach is to boot using uboot and have
it load the FDT and RTEMS<br>
>> executable then jump to it. If you can connect
via JTAG, reset the processor,<br>
>> set a hardware break point on the entry point to
RTEMS, and start the processor<br>
>> running from reset it should trigger when uboot
jumps to RTEMS. The entry point<br>
>> is at a fixed address. When the breakpoint is
hit delete it and then you can set<br>
>> further break points in your application.<br>
>><br>
>><br>
>> Thanks for this suggestion - I've managed to get this
working pretty much as you<br>
>> described.<br>
>> I build the SD card image and boot from that, then
connect via JTAG, reset and<br>
>> break on Init().<br>
>> It's a pretty clunky process, but at least I have
actual on device debugging<br>
>> working now instead of<br>
>> having to rely on printf debugging.<br>
> <br>
> Excellent and thanks for reporting it back to us. Yes it
is clunky however<br>
> anything else would need time spent adding IMFS support
or directly linked in<br>
> support and no one has done that.<br>
<br>
The imxrt BSP uses an FDT that is build into the binary. It
should be <br>
possible to use a similar approach on custom applications for
the BBB. <br>
To do that in an application I would expect that you have to
do the <br>
following (I did not test it but it should work):<br>
<br>
1. Convert the dtb that you want to use to a c file:<br>
<br>
rtems-bin2c -C -N bbb_dtb path/to/your.dtb bbb_dtb.c<br>
<br>
2. Compile that bbb_dtb.c in your application.<br>
<br>
3. Add the following to your application (for example where
you define <br>
the Init task):<br>
<br>
---------<br>
#include <bsp/fdt.h><br>
<br>
extern const unsigned char bbb_dtb[];<br>
<br>
void bsp_fdt_copy(const void *src)<br>
{<br>
/* Do nothing */<br>
}<br>
<br>
const void *bsp_fdt_get(void)<br>
{<br>
return bbb_dtb;<br>
}<br>
----------<br>
<br>
Be aware of the licensing: The FDTs for BBB that I know are
all GPL. So <br>
linking it in as a blob will most likely put your application
under the <br>
terms of GPL.<br>
<br>
The licensing is also the reason why I would have problems
adding an FDT <br>
blob and an option to link it in directly to the RTEMS
repository. If <br>
you have a FDT that is not GPL please let me know.<br>
<br>
Best regards<br>
<br>
Christian<br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:users@rtems.org">users@rtems.org</a>
<a class="moz-txt-link-freetext" href="http://lists.rtems.org/mailman/listinfo/users">http://lists.rtems.org/mailman/listinfo/users</a></pre>
</blockquote>
</body>
</html>