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