device tree loading from uboot.

Kinsey Moore kinsey.moore at oarcorp.com
Thu Oct 19 13:56:29 UTC 2023


On Mon, Oct 16, 2023 at 11:19 AM Sam Price <thesamprice at gmail.com> wrote:

> i want to test the device tree loading stuff in qemu.
> I don't see a way to set the r5 register on startup via command line in
> qemu.
>
>
> void bsp_fdt_copy(const void *src)
> {
>   const volatile uint32_t *s = (const uint32_t *) src;
>
> im tempted to either hard code the src location rather than passing it in
> via r5
> or add a check if the passed in value is null then use a hard coded
> address.
> if(src == 0x0)
> {
>   s = BSP_START_COPY_FDT_ADDRESS;
> }
>
> qemu can then take a address for the device tree file and place it in
> the proper memory address
>
> -device
> loader,file=$DTB_FILE,addr=$BSP_START_COPY_FDT_ADDRESS,force-raw=true \
>
> Does this seem reasonable or is there a way people are testing device
> tree support in qemu by setting the r5 register on startup?
>

That register is generally set by the bootloader and under QEMU there
generally isn't a bootloader (not to say that there can't be), and QEMU has
a bunch of platform-specific rules on where to place that address if at
all. For MicroBlaze (which I assume you're talking about from the mention
of r5 for FDT), it looks like QEMU may stuff the address into r7 instead of
r5 based on main_cpu_reset() in hw/microblaze/boot.c in Xilinx's branch.

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20231019/a50f156a/attachment.htm>


More information about the devel mailing list