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

[Marcel Ziswiler <marcel.ziswiler@toradex.com>]

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.

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

> Thanks,

Thank you.

> Alex

Cheers

Marcel