On 15.10.18 07:14, AKASHI Takahiro wrote: > On Mon, Oct 15, 2018 at 04:01:06AM +0300, Tuomas Tynkkynen wrote: >> Hi Takahiro, >> >> On Fri, 12 Oct 2018 14:07:57 +0900 >> AKASHI Takahiro <takahiro.aka...@linaro.org> wrote: >> >>> This variable, fdt_addr_t, is missing in the current qemu-arm.h while >>> it seems to be mandatory, at least, to run distro_bootcmd as expected. >>> So just add its definition. A size of 1MB would be enough. >>> >> >> In what way is this required for distro_bootcmd to work? At least in the >> past I've tested qemu_arm64_defconfig and EFI boot with the Fedora >> netinst image and it has worked fine in stock U-Boot. >> >> Note that these '-machine virt' based targets are slightly different >> from real hardware in the sense that instead of loading a .dtb file >> provided by the OS, the device tree is provided by QEMU. In the hunk >> below you can see "fdt_addr=0x40000000\0" providing the address of >> the QEMU-provided device tree which the distro scripts should be >> using. > > Yep, I know that. > I was not clear; what distro bootcmd, or more specifically scan_dev_for_efi, > tries to do regarding fdt handling is that, if "fdtfile" variable is defined, > it supersedes qemu's own dtb (that is what "fdt_addr" points to), but > this trick doesn't work expectedly if "fdt_addr_r" variable is not defined. > >> I guess in principle having ${fdt_addr_r} set as well shouldn't hurt and >> might be used for testing/unusual purposes. > > I don't know whether the case is "unsual" or not. > But doc/README.distro cleary says that fdt_addr_r is *mandatory*. > If u-boot works without it, it's a bug, otherwise we must correct > the doc (or scan_dev_for_efi in the first place?).
I agree. Boards that support distro boot *must* provide fdt_addr_r. Otherwise distro scripts may fail unexpectedly because they assume the variable is present. > > Thanks, > -Takahiro Akashi > >> Glancing at cmd/pxe.c, >> there is a problem though, in that if ${fdt_addr_r} were defined, a PXE >> file using the FDTDIR directive would attempt loading a dtb file named >> "<NULL>-qemu-arm.dtb" instead of falling back to using ${fdt_addr}. >> That bug would need to be fixed first before applying this patch. Well, and that load will fail and everyone's happy, no? IMHO we should fall back to $fdtcontroladdr always, but the pxe boot path is not something I would endorse onto anyone (what you want as PXE really is called 'dhcp' in the efi_loader distro boot world) Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot