On Sun, Sep 8, 2019 at 3:10 PM Atish Patra <atish.pa...@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@lists.denx.de > https://lists.denx.de/listinfo/u-boot _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot