[U-Boot] [PATCH] jetson-tk1: Set fdtfile environment variable

[Tom Rini]

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 <swarren at wwwdotorg.org>:
> >>>
> >>>> 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 <swarren at nvidia.com>
> >>>>>>> Cc: Alexander Graf <agraf at suse.de>
> >>>>>>> Signed-off-by: Andreas Färber <afaerber at suse.de>
> >>>>>>> ---
> >>>>>>>  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160413/1d32263f/attachment.sig>