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

[Alexander Graf <agraf@suse.de>]

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@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@nvidia.com>
>>>>>>> Cc: Alexander Graf <agraf@suse.de>
>>>>>>> Signed-off-by: Andreas F?rber <afaerber@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 :).

> 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.


Alex

> 
>> It's really just a convenience helper. And a nice piece to the puzzle
>> that by convention allows users to think less about u-boot internals.
>> The efi code works fine without.
> 
> Yes, but it's also something that requires some external logic.
>