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 <swar...@nvidia.com>
>>>>> Cc: Alexander Graf <ag...@suse.de>
>>>>> Signed-off-by: Andreas Färber <afaer...@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.
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.
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.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
