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

[Stephen Warren]

On 04/13/2016 11:42 AM, Andreas Färber wrote:
> Am 13.04.2016 um 19:00 schrieb Stephen Warren:
>> 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
>
> You're late for that discussion, we had that months ago on this mailing
> list. We already concluded that SUSE does not and will not generate
> extlinux.conf; EFI is a boot mechanism that we already support from x86
> and aarch64 and that there are tools for (e.g., grub-mkconfig), unlike
> extlinux.conf. There was also a FOSDEM talk on extlinux.conf that can be
> summarized as some people like it and there's nothing wrong with it but
> it's not a one-size-fits-all solution for everyone, including non-Linux
> OSes such as Haiku.
>
>> 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.
>
> $fdtfile needs to be the Linux filename. It does not always follow the
> same pattern as the U-Boot variables you suggest here.
> CONFIG_DEFAULT_DEVICE_TREE ".dtb" might work better, and that was my
> question to you.

That pattern is a good default that at least historically applied to all 
the systems where the distro bootcmds were enabled. Perhaps the set of 
systems using the distro bootcmds has increased now so the default isn't 
always applicable. Boards can set $fdtfile /if/ needed because of that, 
but I don't think should be forced to in all cases where the default 
makes sense.

> It's part of the generic mechanism, so not just select boards. Yet I was
> told that all boards are expected to set their cacheline size (although
> that is not a board but CPU property), so similarly we can (yes, newly)
> desire all boards to provide DT related settings as well.

OK, but enabling the feature on boards where we know the requirements 
aren't met doesn't seem useful, since it won't work well, as evidenced 
by this patch.

> If you would supply a feature-complete DT in the first place, we
> wouldn't need $fdtfile here, but it seemed that that was not realistic
> to expect for the upcoming U-Boot release.

Given the current primary DT source location, I don't think the issue is 
complete-vs-incomplete DTs at all. However, that's straying quite off-topic.