From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 20 Oct 2017 08:54:43 -0400 Subject: [U-Boot] [PATCH 3/3] efi_loader: Do not enable it by default for sunxi In-Reply-To: <20171020123627.z7coumddoybzcuvf@flea> References: <20171019082649.27819-4-maxime.ripard@free-electrons.com> <20171019090147.6sgmbn6zlfeicnnq@flea> <20171019114308.e6chfcejddb5ipsp@flea> <20171020072058.ebbqzvabj6m5ya6t@flea> <20171020123627.z7coumddoybzcuvf@flea> Message-ID: <20171020125443.GF12015@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Oct 20, 2017 at 02:36:27PM +0200, Maxime Ripard wrote: > On Fri, Oct 20, 2017 at 01:27:36PM +0100, Peter Robinson wrote: > > On Fri, Oct 20, 2017 at 8:20 AM, Maxime Ripard > > wrote: > > > On Thu, Oct 19, 2017 at 05:40:20PM -0400, Rob Clark wrote: > > >> On Thu, Oct 19, 2017 at 7:43 AM, Maxime Ripard > > >> wrote: > > >> > On Thu, Oct 19, 2017 at 10:12:36AM +0100, Peter Robinson wrote: > > >> >> On Thu, Oct 19, 2017 at 10:06 AM, Peter Robinson wrote: > > >> >> > On Thu, Oct 19, 2017 at 10:01 AM, Maxime Ripard > > >> >> > wrote: > > >> >> >> On Thu, Oct 19, 2017 at 09:43:20AM +0100, Peter Robinson wrote: > > >> >> >>> On Thu, Oct 19, 2017 at 9:26 AM, Maxime Ripard > > >> >> >>> wrote: > > >> >> >>> > The EFI loader support takes around 31kB on an ARMv7 board, which makes us > > >> >> >>> > trip across the size limit we've had on the U-Boot binary. > > >> >> >>> > > > >> >> >>> > Since it's not an essential feature, disable it by default for ARCH_SUNXI > > >> >> >>> > so that we get back some extra room for user customisations. > > >> >> >>> > > >> >> >>> Does this disable it on aarch64 boards by default such as the Pine64? > > >> >> >>> If so NAK as Fedora, SUSE and I'm pretty sure Debian all use EFI to > > >> >> >>> boot aarch64 devices and this would regress this for all those > > >> >> >>> distros. > > >> >> >> > > >> >> >> This is something that Fedora, Suse and I'm pretty sure Debian can add > > >> >> >> to their defconfig. These are just default configuration, not > > >> >> >> one-size-fits-all configuration. > > >> >> > > > >> >> > So you're making at least three groups of users do more work? It could > > >> >> > also be argued that those that need the smaller space could disable it > > >> >> > if they don't need it in their configuration. > > >> >> > > >> >> Ultimately the problem with the argument about disabling it by default > > >> >> and distros can enable it if they want to is a false one. > > >> > > > >> > If it's a false one, then I guess Red Hat doesn't have any kind of > > >> > custom defconfigs for Fedora or RHEL for the kernel? > > >> > > >> kernel is part of the distro, "firmware" (ie. u-boot or whatever > > >> implements UEFI) should not be.. so this argument is a bit of a red > > >> herring. > > > > > > Then that discussion is entirely moot. If the distros don't care about > > > building the U-Boot binary, why should they care about maintaining the > > > U-Boot's defconfig like Peter was suggesting? > > > > You're taking that and turning it around wrong, we currently have to > > care about building it. Ultimately what we'd like is to not have to > > care. One is the current status quo, the other is future desire! > > Then we're back to the previous question you didn't answer. If you > have to build it, why can't you have a custom defconfig, or a > configuration fragment like Rob suggested, like you do for the kernel? Because the goal is that boards ship from the manufacturer with a firmware that's "good enough". And firmware updates are handled by Someone Else, rather than the distro. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: