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.abdurachma...@sifive.com; Alistair Francis > <alistair.fran...@wdc.com>; Anup Patel <anup.pa...@wdc.com> > Cc: u-boot@lists.denx.de; open...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot