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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot