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.