On Thu, Apr 14, 2016 at 12:38:22AM +0200, Alexander Graf wrote: > > > On 14.04.16 00:17, Tom Rini wrote: > > On Wed, Apr 13, 2016 at 07:21:27PM +0200, Alexander Graf wrote: > >> > >> > >>> Am 13.04.2016 um 19:00 schrieb Stephen Warren <[email protected]>: > >>> > >>>> On 04/13/2016 09:51 AM, Alexander Graf wrote: > >>>>> On 04/13/2016 05:31 PM, Stephen Warren wrote: > >>>>>> On 04/13/2016 06:55 AM, Andreas Färber wrote: > >>>>>>> Am 13.04.2016 um 14:48 schrieb Andreas Färber: > >>>>>>> The 4.5.0 kernel cannot cope with U-Boot's internal device tree, and > >>>>>>> the > >>>>>>> distro boot commands are looking for $fdtfile, so provide it to avoid > >>>>>>> having users supply a dumb boot.scr doing a setenv fdtfile ...; boot, > >>>>>>> defeating the purpose of generic EFI boot. > >>>>>>> > >>>>>>> Cc: Stephen Warren <[email protected]> > >>>>>>> Cc: Alexander Graf <[email protected]> > >>>>>>> Signed-off-by: Andreas Färber <[email protected]> > >>>>>>> --- > >>>>>>> include/configs/jetson-tk1.h | 4 ++++ > >>>>>>> 1 file changed, 4 insertions(+) > >>>>>>> > >>>>>>> diff --git a/include/configs/jetson-tk1.h > >>>>>>> b/include/configs/jetson-tk1.h > >>>>>>> index 59dbb20..82a4be4 100644 > >>>>>>> --- a/include/configs/jetson-tk1.h > >>>>>>> +++ b/include/configs/jetson-tk1.h > >>>>>>> @@ -63,6 +63,10 @@ > >>>>>>> /* General networking support */ > >>>>>>> #define CONFIG_CMD_DHCP > >>>>>>> > >>>>>>> +#define BOARD_EXTRA_ENV_SETTINGS \ > >>>>>>> + "fdtfile=tegra124-jetson-tk1.dtb\0" \ > >>>>>>> + "" > >>>>>> > >>>>>> Is there any more intelligent solution than doing this for each board? > >>>>> > >>>>> Yes, the distro boot scripts shouldn't be using $fdtfile > >>>>> unconditionally since it's not guaranteed to be set. The model is that > >>>>> boot scripts determine the FDT filename, and $fdtfile is an optional > >>>>> override. > >>>> > >>>> The point of all of the efi magic is that we can completely get rid of > >>>> boot scripts. Boards use the distro scripts, everything else gets > >>>> implicitly detected and executed. The way other boards deal with common > >>>> code mapping into separate boards is to either implement a "findfdt" > >>>> scriptlet or directly write the fdtfile variable (e.g. beaglebone) in > >>>> board init (e.g. rpi). > >>>> > >>>>> It looks like the hard-coded use of $fdtfile was added into the EFI > >>>>> path, which I didn't get to review, and which shouldn't be enabled by > >>>>> default but unfortunately is. > >>>> > >>>> s/un// :) > >>>> > >>>> Just imagine a world where people don't have to worry about bootloaders > >>>> anymore. Things would "just work". You plug in a usb stick, it comes up, > >>>> boots Linux, everthing goes without anyone touching boot scripts, > >>>> downloading board specific files, etc. You could get a random > >>>> distribution from a common download page from somewhere and just run it. > >>>> > >>>> Well, you can also just look at any random x86 system. They get at least > >>>> that part pretty right these days. > >>> > >>> Well, you can also get the same benefit using extlinux.conf, and without > >>> relying on EFI:-P > >>> > >>> Anyway, nothing in your benefits-of-EFI statement implies that relying on > >>> $fdtfile being set is correct. That's a new requirement that didn't exist > >>> before. Either the requirement needs to be removed (e.g. using a default > >>> FDT filename such as "${soc}-${board}${boardver}.dts") or only enabling > >>> this functionality on boards that do set $fdtfile, since it relies on > >>> that. > >> > >> On boards that fon't set fdtfile we just don't load it, because we can't > >> find the file. So you're getting a working grub2 payload, but Linux gets > >> an empty device tree unless you pass it in using the grub2 "devicetree" > >> command. > > > > Well, hold up. We are _not_ at the point right now where the device > > tree we use is the kernel device tree. We're trying to make sure there > > If I understand correctly that depends on the board. On some systems > like the pine64 the device tree is just a copy of the Linux device tree. > I don't see why we couldn't aim for that model going forward. > > And with that I'm not saying "this is how it works today". If you want a > reasonable working system today you probably need to provide your own > device tree at a well-known location. But thinking mid-term I don't see > why a board author couldn't just keep the U-Boot device tree and the > Linux device tree in sync. > > Again, none of this is mandatory, required, or even recommended today. I > just want to make sure that people see the potential and make the (in my > opinion) best path be the easiest one to take :).
Yes, the long term goal is that everyone be able to share the same canonical device tree, bootloader and OS. And that's making progress all around and I think devicetree.org will help there too. But the problem I want to make sure you see is that you can't just use the kernel device tree on U-Boot and have it work on anything that does DM+SPL. The u-boot,dm-pre-reloc flag is required, isn't going to be in the kernel tree and is still something that needs sorting out. > > are no cases of incompatible bindings, and we're trying to make sure we > > play nicely and get the canonical device tree to have everything we > > need. But it seems risky at best to assume the loaded tree is the right > > tree for the kernel. > > So would you prefer if the board manually specifies it as the right tree > for the kernel? I'm not sure that buys us anything really. If it's the > wrong one, booting will fail. I'm saying I think today unless you know you've loaded a known correct for the kernel device tree into $fdtaddr you shouldn't use that for the kernel. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
