[U-Boot] config: enable CONFIG_API in distro config

Dennis Gilmore dennis at ausil.us
Mon Apr 21 16:49:57 CEST 2014


On Sun, 20 Apr 2014 09:55:53 -0700
Simon Glass <sjg at chromium.org> wrote:

> Hi Dennis,
> 
> On 19 April 2014 08:42, Dennis Gilmore <dennis at ausil.us> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sat, 19 Apr 2014 15:01:40 +0100
> > Ian Campbell <ijc at hellion.org.uk> wrote:
> >
> > > On Fri, 2014-04-18 at 11:43 -0600, Simon Glass wrote:
> > > > Hi Stephen,
> > > >
> > > > On 18 April 2014 11:23, Stephen Warren <swarren at wwwdotorg.org>
> > > > wrote:
> > > > > On 04/18/2014 09:35 AM, Tom Rini wrote:
> > > > >> On Thu, Apr 10, 2014 at 03:55:48PM -0500, Rob Herring wrote:
> > > > >>
> > > > >>> From: Rob Herring <robh at kernel.org>
> > > > >>>
> > > > >>> CONFIG_API is needed for u-boot apps such as grub2, so
> > > > >>> enable it for distro config.
> > > > >>>
> > > > >>> Cc: Dennis Gilmore <dennis at ausil.us>
> > > > >>> Signed-off-by: Rob Herring <robh at kernel.org>
> > > > >>
> > > > >> This breaks a number of boards that have opted in to the
> > > > >> distro config. The full list is:
> > > > >> whistler trimslice beaver tec paz00 ventana cardhu harmony
> > > > >> dalmore plutux medcom-wide rpi_b venice2 colibri_t20_iris
> > > > >> tec-ng seaboard
> > > > >>
> > > > >> How do you guys want to handle this?  I can apply now and
> > > > >> they can be fixed up later, or I can wait for fixup patches
> > > > >> to come out and apply them all at once.  Thanks!
> > > > >
> > > > > I've sent patches that solve all the build problems on Tegra
> > > > > with CONFIG_API enabled.
> > > > >
> > > > > That said, I still conceptually object to
> > > > > config_distro_defaults.h enabling API support in order to
> > > > > support grub; I believe the distros need to get together and
> > > > > nail down a *single* boot mechanism to standardize upon,
> > > > > rather than having Fedora support BootloaderSpec,
> > > > > Ubuntu/Linaro(?) support Grub, something else support LILO,
> > > > > something else support UEFI,
> > >
> > > AIUI the distros *are* standardising: on grub2.
> >
> > not in arm space at least,
> >
> 
> I have no great love for grub2 and the pain of not using on ARM
> devices would in my case succumb to an extremely small aspirin.

that I know of only ppc and x86 use grub2, I never quite got it working
on sparc before I gave up on the platform. What we are trying to do is
to make the default user experience just work, be simple, easily
updateable. 

> 
> > > AIUI BootloaderSpec is a spec to standardise the configuration of
> > > UEFI. It is used to install the distro's bootloader (often grub2)
> > > into the UEFI boot list, for grub-on-UEFI scenarios.
> >
> > not at all true, bootloader spec is designed to be a platform and
> > bootloader agnostic way to boot open systems. its designed to
> > share /boot between open operating systems, UEFI, bios, u-boot etc
> > have zero to do with it. you can compliantly boot operating systems
> > using any type of platform
> >
> > > Where the lowlevel firmware is u-boot then they want to use grub2
> > > on it so that things are consistently grub no matter whether the
> > > platform uses UEFI, u-boot, PC BIOS etc.
> > >
> > > >  etc. Without this, we'll force every U-Boot binary to
> > > > > be bloated with all kinds of redundant code. Having a single
> > > > > standard mechanism was always the point of
> > > > > config_distro_defaults.h in my mind. If we really need Grub
> > > > > support, wouldn't it be better to have U-Boot parse and
> > > > > execute grub.cfg, just like it does extlinux.cfg?
> > > >
> > > > That seems to make a lot more sense to me. How hard can it
> > > > possibly be?
> > >
> > > Very. grub.cfg is essentially a complete bash-a-like programming
> > > language. At work we try to parse it for Xen's "pygrub" utility
> > > and it breaks pretty frequently when people introduce random new
> > > variables etc.
> >
> > Which is why we are standardising distro booting using u-boots
> > syslinux compatibility in distro land.  it's not uncommon to users,
> > since isos have used isolinux for years. right now its feature set
> > is somewhat simple. but over time we should be able to do things
> > like commandline editing and using menu to select different
> > kernels.  But there is a very solid foundation available today that
> > works really well.
> >
> 
> Can you suggest a starting point for trying this out on am ARM
> platform? (e.g. OMAP, Tegra, Exynos) I'd like to see how it works.

as of 2014.04 it will work on tegra, its worked on calxeda since it was
added but their default environment is outside of u-boot itself. I have
some patches submitted that need futher thought and work converting
omap and wandboard. If you have a prefered platform I can throw
together a patch for you to test.

> 
> >
> > AFAIK no one is really working on grub2 for use with u-boot as
> > linaro who was doing the work have decided to drop u-boot support
> > and only do UEFI.
> >
> 
> So UEFI boots through grub2? We seem to have a talent for making
> things complicated?
UEFI is loading grub2. I think some people have tried gummiboot, i do
not know of anyone using UEFI directly as its not really all that
simple to do.

> Regards,
> Simon

Dennis


More information about the U-Boot mailing list