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

Sat Apr 1 04:22:13 UTC 2017

Hi,

On 24 March 2017 at 17:52, Marcel Ziswiler <marcel.ziswiler at toradex.com> wrote:
> On Fri, 2017-03-24 at 23:40 +0100, Alexander Graf wrote:
>>
>> 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-n
>> > > > > > ext
>> > > > > >
>> > > > > > 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.
>
> It probably also will never work across all 32-bit ARM variants
> available out there.
>
>> > 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.
>
> Another area which probably will never generically work across all
> hardware just because there are simply too many hardware variants out
> there in the 32-bit ARM world.
>
>> Take a look at my video at ELC for some rationale behind it:
>>
>>    https://www.youtube.com/watch?v=qJAkJ3nmWgM
>
> Yes, I have seen that one before and we were shaking our heads. But
> maybe it really is the way to go just like systemd is now ruling the
> world (;-p).
>
>> > > 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.
>
> Uups, we still have it kind of hard coded by default but at least with
> a distro boot fall back.
>
>> > 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.
>
> OK, I will send a V5 which does not explicitly disable it.

It's your board, I don't see why you can't disable it.

>
>> 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.
>
> Unfortunately the platforms I have that are space constrained do not
> support any such but again those probably won't ever run any regular
> distro neither.

We certainly should not mandate EFI support in U-Boot :-( I think it's
a nice idea if you have to use EFI/grub on your system though. A great
way to get past the legacy problem.

Anyway, the video looks interesting - are the slides available
somewhere? I'd really like to see how this is presented.

Regards,
Simon