Hi Dennis,
On 19 April 2014 08:42, Dennis Gilmore dennis@ausil.us wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 19 Apr 2014 15:01:40 +0100 Ian Campbell ijc@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@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@kernel.org
CONFIG_API is needed for u-boot apps such as grub2, so enable it for distro config.
Cc: Dennis Gilmore dennis@ausil.us Signed-off-by: Rob Herring robh@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.
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.
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?
Regards, Simon