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

[Simon Glass]

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, 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.
>
> BTW, does Grub work well for you? I did try it many months ago, and found:
>
> a) It was excruciatingly slow, to the point of not being useful.
>
> b) The binary had hard-coded memory layout, and hence couldn't be
> generic across multiple boards, since SoCs put their RAM in different
> places, boards have differing amounts of RAM, etc. This kinda defeats
> the whole purpose, since distros would need to install board-specific
> Grub binaries. Perhaps this could be solved similarly to the kernel's
> CONFIG_ARM_PATCH_PHYS_VIRT?
>
> 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? Is the problem getting access to grub.cfg from U-Boot, or
something else?

Regards,
Simon