On Sun, 20 Apr 2014 09:55:53 -0700 Simon Glass <s...@chromium.org> wrote:
> Hi Dennis, > > On 19 April 2014 08:42, Dennis Gilmore <den...@ausil.us> wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Sat, 19 Apr 2014 15:01:40 +0100 > > Ian Campbell <i...@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 <swar...@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 <r...@kernel.org> > > > > >>> > > > > >>> CONFIG_API is needed for u-boot apps such as grub2, so > > > > >>> enable it for distro config. > > > > >>> > > > > >>> Cc: Dennis Gilmore <den...@ausil.us> > > > > >>> Signed-off-by: Rob Herring <r...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot