On 19.10.18 08:33, AKASHI Takahiro wrote: > On Thu, Oct 18, 2018 at 09:25:04AM +0200, Alexander Graf wrote: >> >> >> On 18.10.18 00:25, Tuomas Tynkkynen wrote: >>> Hi Alexander, >>> >>> On Tue, 16 Oct 2018 15:04:26 +0200 >>> Alexander Graf <ag...@suse.de> wrote: >>> >>> ... >>>>> >>>>>> 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? >>> >>> No, because currently if DTB loading from the filesystem/tftp is >>> attempted and it fails, it aborts the boot. It doesn't matter if it's >>> via a 'FDT' or 'FDTDIR' directive. In the case of typical hardware >>> that's probably the desired behaviour. >>> >>> I guess the qemu_arm + FDTDIR case can be fixed by not attempting >>> a .dtb load if the default fdtfile is not known due to $soc or $board >>> being unset. At least I doubt that some other board could be relying >>> on a filename containing literally "<NULL>" :) >> >> Well - IIRC $soc and $board should also always be defined ;). So yet >> another thing to fix in the QEMU port. > > See my patch below. Are you happy with it? > (qemu-qemu-arm.dtb doesn't make sense to me, though :) > >>> >>>> IMHO we should >>>> fall back to $fdtcontroladdr always >>> >>> FWIW, to me the idea of passing $fdtcontroladdr to the OS has always >>> filled me with dread. On top of the usual backwards- and >>> forwards-compatibility problems that happen when mixing and matching >>> kernels and DTBs from different releases, you now have to deal with >> >> That's something that we seriously as a community need to get sorted >> out. We're pushing hard for it in the EBBR context. The fact that people >> are afraid of putting *hardware desciption* into their firmware is just >> mind boggling. > > I don't have a strong opinion, but it seems to me that 'fall-back' approach > is quite normal. If it doesn't work on a specific board, 'fdt_addr' > should be defined. > > Thanks, > -Takahiro Akashi > > >>> issues like U-Boot specific .dts that are majorly diverged from Linux >>> ones, or where the .dts is otherwise from Linux but the U-Boot specific >> >> These case should really be the minority. And if you see those, please >> fix them. >> >>> additions break it for Linux, or where the .dts used is wrong for the >> >> I've never seen a case where a U-Boot addition broke the DT for Linux. >> >>> specific hardware revision but close enough for U-Boot's purposes, >>> and so on... >> >> Again, something that just needs fixing. Device trees belong to the >> entity that knows hardware, not to the OS. Otherwise you lose the >> abstraction layer that DT gives you and you lose the ability to run >> "generic" kernels. And of course you break the ecosystem, because now >> good luck running BSD, your own little toy OS, etc ;) >> >> >> Alex > > ===8<=== > From 47b26a86359a3b612e890f2ca2d5d20092f9f4e1 Mon Sep 17 00:00:00 2001 > From: AKASHI Takahiro <takahiro.aka...@linaro.org> > Date: Fri, 19 Oct 2018 15:22:02 +0900 > Subject: [PATCH] arm: qemu: rework Kconfig > > Define SYS_SOC and move SYS_* to a canonical place (under board). > > Signed-off-by: AKASHI Takahiro <takahiro.aka...@linaro.org>
Looks good enough to me, but it's up to Tuomas to double check and take as he's the qemu-arm maintainer :). It also usually helps to post the patch as a new message, not buried inside a thread ;). Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot