[U-Boot] [PATCH v4 0/3] arm: tegra: apalis-tk1 and ext clock loopback

[Alexander Graf]

On 24/03/2017 23:22, Marcel Ziswiler wrote:
> Hi Alexander
>
> On Tue, 2017-03-21 at 14:50 +0100, Alexander Graf wrote:
>>
>> On 21/03/2017 14:37, Marcel Ziswiler wrote:
>>> Hi Alex
>>>
>>> On Tue, 2017-03-21 at 10:46 +0100, Alexander Graf wrote:
>>>>
>>>> On 21/03/2017 10:29, Marcel Ziswiler wrote:
>>>>> This series adds support for the Toradex Apalis TK1 and
>>>>> introduces
>>>>> a new
>>>>> option to disable the external clock loopback on SDMMC3.
>>>>>
>>>>> The whole series is also available here:
>>>>>
>>>>> http://git.toradex.com/cgit/u-boot-toradex.git/log/?h=for-next
>>>>>
>>>>> Changes in v4:
>>>>> - Re-based.
>>>>> - Drop patches 2 and 3:
>>>>>     mmc: tegra: move CONFIG_TEGRA_MMC from headers to
>>>>> defconfigs
>>>>>     mmc: tegra: introduce CONFIG_TEGRA_MMC to Kconfig
>>>>>   in favor of commit 1d2c0506d31a9997e5ffc22e90942902f673b107
>>>>>     mmc: move more driver config options to Kconfig
>>>>>   from Masahiro.
>>>>> - Meld patch 6
>>>>>     apalis-tk1: clean-up defconfig
>>>>>   into first one.
>>>>> - Add distro boot fallback.
>>>>> - Enable FIT and device tree overlay support.
>>>>> - Explicitly drop EFI loader support.
>>>>
>>>> Any particular reason for this?
>>>
>>> Yes, a waste of 20K which on some of our modules is rather crucial.
>>> I
>>> personally think force enabling EFI for everything was not too
>>> smart an
>>> idea but whatever.
>>
>> Well, it's enabled by default for a good reason: Compatibility.
>
> While I do agree about compatibility I don't quite see what this has to
> do with EFI. I personally don't believe the BIOS/EFI disaster of the
> x86 world is worth copying to ARM, sorry. Other distributions like
> Fedora e.g. achieve the same with distro boot isn't it? After all isn't

Fedora uses extlinux for 32bit ARM and UEFI for 64bit ARM. The main 
reason they're using extlinux is that at the point in time when they 
standardized on it as their preferred booting method, the UEFI 
implementation didn't exist yet.

> the device tree the agreed upon hardware description in the ARM world?

Yes, device tree is very much agree upon as hardware description! And 
with UEFI nothing changes in that regard. We still use device tree by 
default and unless you're really into shooting yourself into your own 
feet I don't see why you'd want to do it any differently.

This is not an ACPI vs DT discussion. It's really just about the 
question which entity controls selection and handover into the kernel.

With UEFI it's much easier to implement snapshot booting for example, 
because you can move all of that logic into a platform agnostic piece of 
code. It's the only supported way to have KASLR work on arm64. It allows 
for boot selection logic (A/B fallback for example) in something outside 
of a boot script or your boot loader sources, so that code stays reusable.

Take a look at my video at ELC for some rationale behind it:

   https://www.youtube.com/watch?v=qJAkJ3nmWgM

>> I want to move to a world where people can just take a random
>> distribution and expect it to work, rather than waste weeks over
>> weeks on fiddling around with random BSPs that nobody really wants
>> only to realize 2 years down the road that their security footprint
>> is en par with a swiss cheese.
>
> Hey, nothing against Swiss cheese! And BTW the term Swiss cheese is
> about as nonsense as the term Linux. There is really a huge collection
> of different Swiss cheeses... Sorry, I just do get upset at times if
> certain countries gastronomy people do ask whether I want my sandwich
> with Swiss cheese wondering what they mean by that. But I guess those
> chaps now do have their very own issues (;-p).

:)

>
>> It's also the preferred option to boot BSD for example.
>>
>> So how bad are the 20k for you? In fact, I'm surprised it's 20k at
>> all -
>> it used to be 10k. The overhead of DM should be much higher and I
>> doubt
>> you want to disable that ;). Usually a full U-Boot build is ~500k,
>> so
>> even at 20k we're talking about 4% - less than a compiler update
>> usually
>> gets you.
>>
>> If size really is such a big concern, moving to THUMB code is going
>> to
>> buy you much more in storage savings than dropping (quite useful)
>> UEFI
>> support.
>>
>> If however there are real technical issues with it, I'm happy to
>> hear
>> them and fix them as far as possible.
>
> The technical issue is that I still don't quite see why U-Boot needs
> EFI. I stopped using SuSE more than 15 years ago and never regretted

For 32bit ARM it doesn't really "need" it. If you feel terribly strongly 
about it, I don't have hard feelings with leaving it out. But if it's 
really just a matter of taste rather than technical merit, I'd rather 
prefer to have the option available for users. The same reason you 
usually want to have distro boot support enabled and not just a 
hardcoded bootcmd line.

> it, no pun intended.
>
> But if it is really agreed upon mandatory to enable it I am happy to do
> so as I would love to finally get that thing in after an almost 4
> months endeavour.

I'm not nacking this patch set, even with EFI_LOADER disabled. But I 
think that if there's no good reason to disable the feature, we should 
leave it enabled.

And if you really are size constrained with today's configuration, 
please enable thumb2, otherwise you will get bitten on random compiler 
updates down the road.


Thanks,

Alex