[U-Boot] FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V

[David Abdurachmanov]

On Sun, Sep 8, 2019 at 3:10 PM Atish Patra <Atish.Patra at wdc.com> wrote:
>
> Hi All,
>
> I noticed following issues around U-Boot fdt location in Unleashed and
> Qemu virt machine.
>
> OpenSBI copies the FDT to following addresses for respective platforms
>
> Qemu:           0x82200000
> Unleashed:      0x88000000
>
>
> As CONFIG_PRIOR_STAGE is set for both platforms, fdt is first copied to
> gd->fdt_blob and then gets relocated to a different address(gd-
> >new_fdt) in function reloc_fdt.
>
> As a result, FDT is present at two locations.
>
> 1. 0x88000000(Unleashed)/0x82200000(Qemu) : OpenSBI copied FDT to this
> address.
> 2. gd->new_fdt: U-Boot relocated the fdt to this address.
> fdtcontroladdr will also point to this address.
>
> However, commit ac12c6190927 (riscv: set CONFIG_SYS_BOOTM_LEN to
> SZ_64M) in U-boot changed Qemu config so that fdt_addr_r points to
> 0x88000000 which is wrong as nobody copies fdt to above address in
> Qemu.
> Also, 5.3-rc+ kernels overwrite the address pointed by fdtcontroladdr.
>
> As a result, fdtcontroladdr won't work on any platform and fdt_addr_r
> will work only for Unleashed but not for Qemu.
>
> I am not sure what should be the ideal solution to avoid these kind of
> fdt placement issues in future. Here are the few possible ones.
>
> 1. Change the FDT_JUMP_ADDR in OpenSBI to 0x88000000(RAM+128MB) for
> Qemu as well. This won't work as Qemu copies initrd to that address. I
> guess best next option is to copy to 0x84000000(RAM+64MB) and U-boot
> config for Qemu accordingly.
>
> 2. Change fdt_addr_r to 0x82200000 in Qemu. Update documentation to use
> fdt only from fdt_addr_r not fdtcontroladdr.
>
> @david: What was the reason behind changing it for Qemu ?

Not enough space for the kernel. Thus it was moved from 16M to 64M
(which was a  common thing for some ARM boards, e.g. 96Boards).

I that point I didn't know about QEMU limitation and initrd placement
(IIUC only if you use -initrd).
>
> 3. Fix gd->new_fdt computation. This may affect every board which is
> not a very good idea either.
>
> 4. Mandate loading fdt only from tftp or sdcard which is the safest
> option and will avoid these kind of complications. However, I think a
> default booting method without tftp server should at least work. Let me
> know if that is not a sane request. In that case, we should update
> documentation to clearly say that only tftpboot or sdcard loading
> method works.

I don't think we should require this. FDT should be part of the firmware
(FSBL, U-Boot SPI, OpenSBI, U-Boot, etc.). There should be a way to
override the default one from the firmware (e.g. via tfptboot, PXE or
EXTLINUX configs), but that's optional as majority people will not do
that.

david

>
>
> --
> Regards,
> Atish
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot