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

[Anup Patel]

Hi,

I think keeping FDT placement in-sync between U-Boot and OpenSBI
across platforms is going to be painful.

I suggest that for all platforms U-Boot explicitly load FDT from somewhere
so:
1. U-Boot ${fdt_addr_r} default value will be recommended location of FDT
2. U-Boot ${fdtcontroladdr} will always point to copy of FDT passed by OpenSBI
3. To forward FDT passed by OpenSBI to Linux, U-Boot users can always explicitly
copy FDT from ${fdtcontroladdr} to ${fdt_addr_r} using U-Boot copy command

I also suspect that in-future for certain platforms FDT passed to U-Boot and
FDT passed to Linux might be little different due to U-Boot specific changes
in DTS.

Thoughts ??

Regards,
Anup

> -----Original Message-----
> From: Atish Patra
> Sent: Sunday, September 8, 2019 5:40 PM
> To: david.abdurachmanov at sifive.com; Alistair Francis
> <Alistair.Francis at wdc.com>; Anup Patel <Anup.Patel at wdc.com>
> Cc: u-boot at lists.denx.de; opensbi at lists.infradead.org
> Subject: FDT placement in OpenSBI + U-Boot + Linux kernel issue for RISC-V
> 
> 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 ?
> 
> 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.
> 
> 
> --
> Regards,
> Atish