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.
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.
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.
Ian.