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

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

[Rob Herring]

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>
---
 include/config_distro_defaults.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h
index 5d18a4b..75eb6f5 100644
--- a/include/config_distro_defaults.h
+++ b/include/config_distro_defaults.h
@@ -30,6 +30,7 @@
 #endif
 
 #define CONFIG_OF_LIBFDT
+#define CONFIG_API
 
 #define CONFIG_CMD_BOOTZ
 #define CONFIG_CMD_DHCP
-- 
1.9.1

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

[Tom Rini]

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140418/8c4b011c/attachment.pgp>

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

[Stephen Warren]

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

Hmm. That's all or most Tegra boards. What's the break?

That said, I wonder why we need CONFIG_API in the distro config; the
purpose of that config is to allow the "pxe" and "sysboot" commands not
to work. If we start supporting all kinds of other random boot
mechanisms, we'll just end up with a fragmented mess, rather than a
unified boot mechanism.

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

[Tom Rini]

On Fri, Apr 18, 2014 at 09:44:44AM -0600, Stephen Warren 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
> 
> Hmm. That's all or most Tegra boards. What's the break?
> 
> That said, I wonder why we need CONFIG_API in the distro config; the
> purpose of that config is to allow the "pxe" and "sysboot" commands not
> to work. If we start supporting all kinds of other random boot
> mechanisms, we'll just end up with a fragmented mess, rather than a
> unified boot mechanism.

It's to add grub2, as Rob says :)  But the breakage is over things like
CONFIG_SYS_MAX_MMC_DEVICE, and a few other things (that's just the
common one, but I still saw some breakage when I set that to 2 for tegra
stuff).

> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140418/7ac3e76c/attachment.pgp>

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

[Stephen Warren]

On 04/18/2014 09:55 AM, Tom Rini wrote:
> On Fri, Apr 18, 2014 at 09:44:44AM -0600, Stephen Warren 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
>>
>> Hmm. That's all or most Tegra boards. What's the break?
>>
>> That said, I wonder why we need CONFIG_API in the distro config; the
>> purpose of that config is to allow the "pxe" and "sysboot" commands not
>> to work. If we start supporting all kinds of other random boot
>> mechanisms, we'll just end up with a fragmented mess, rather than a
>> unified boot mechanism.
> 
> It's to add grub2, as Rob says :)

Right, but why should that be part of the standard distro config, which
isn't Grub2, but rather pxe/sysboot?

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

[Rob Herring]

On Fri, Apr 18, 2014 at 10:44 AM, 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
>
> Hmm. That's all or most Tegra boards. What's the break?

Missing CONFIG_SYS_MMC_MAX_DEVICE at least for trimslice which is only
ever set on zynq. I'll look into it.

> That said, I wonder why we need CONFIG_API in the distro config; the
> purpose of that config is to allow the "pxe" and "sysboot" commands not
> to work. If we start supporting all kinds of other random boot
> mechanisms, we'll just end up with a fragmented mess, rather than a
> unified boot mechanism.

As the commit says, distro's want to support grub2 which runs as a
u-boot application.

Rob

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

[Tom Warren]

If Rob broke it, Rob should fix it.

--
nvpublic

> -----Original Message-----
> From: Tom Rini [mailto:tom.rini at gmail.com] On Behalf Of Tom Rini
> Sent: Friday, April 18, 2014 8:36 AM
> To: Rob Herring; Simon Glass; Tom Warren; Stephen Warren
> Cc: u-boot at lists.denx.de; Dennis Gilmore; Rob Herring
> Subject: Re: [U-Boot] config: enable CONFIG_API in distro config
> 
> * PGP Signed by an unknown key
> 
> 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!
> 
> --
> Tom
> 
> * Unknown Key
> * 0x94391D56

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

[Tom Rini]

On Fri, Apr 18, 2014 at 08:44:49AM -0700, Tom Warren wrote:

> If Rob broke it, Rob should fix it.

Well, it's non-obvious system details, in some cases.  I can guess at
CONFIG_SYS_MMC_MAX_DEVICE for Tegra for example, but there was some
other breakage wrt lcd things.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140418/0868acbd/attachment.pgp>

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

[Rob Herring]

On Fri, Apr 18, 2014 at 10:56 AM, Tom Rini <trini@ti.com> wrote:
> On Fri, Apr 18, 2014 at 08:44:49AM -0700, Tom Warren wrote:
>
>> If Rob broke it, Rob should fix it.
>
> Well, it's non-obvious system details, in some cases.  I can guess at
> CONFIG_SYS_MMC_MAX_DEVICE for Tegra for example, but there was some
> other breakage wrt lcd things.

This config option is to set max_dev in api_storage.c. IMHO, the use
of max_dev is a bit pointless. The get_dev function will return NULL
when there are no more devices. My plan to fix is by removing max_dev
usage altogether.

There also appears to be a bug in that more than 1 device of a given
type will never be enumerated. The problem is in dev_stor_get. When
first is set, then *more is always returned as 0.

Rob

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

[Stephen Warren]

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, 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?

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

[Simon Glass]

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, 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

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

[Ian Campbell]

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.

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

[Simon Glass]

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

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

[Dennis Gilmore]

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

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

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] config: enable CONFIG_API in distro config

[Simon Glass]

Hi Dennis,

On 21 April 2014 08:49, Dennis Gilmore <dennis@ausil.us> wrote:

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

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

Tegra is OK - I have a trimslice and a badger(?) if either of those is OK.
So do I just try to install Fedora and see what happens?


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

OK.


>
> > Regards,
> > Simon
>
> Dennis
>

Regards,
Simon

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

[Stephen Warren]

On 04/21/2014 11:57 AM, Simon Glass wrote:
> Hi Dennis,
> 
> On 21 April 2014 08:49, Dennis Gilmore <dennis@ausil.us
> <mailto:dennis@ausil.us>> wrote:
> 
>     On Sun, 20 Apr 2014 09:55:53 -0700
>     Simon Glass <sjg at chromium.org <mailto:sjg@chromium.org>> wrote:
> 
> [snip]
> 
>     > 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.
> 
> 
> Tegra is OK - I have a trimslice and a badger(?) if either of those is
> OK. So do I just try to install Fedora and see what happens?

s/badger/Beaver/

Yes, both of those support finding and executing /boot/extlinux.cfg in
mainline.

I've just been manually creating extlinux.cfg for now. An example might be:

> TIMEOUT 30
> default primary
> 
> MENU TITLE Venice2 eMMC boot options
> 
> LABEL primary
>        MENU LABEL primary kernel
>        LINUX zImage
>        FDTDIR./
>        APPEND console=ttyS0,115200n8 console=tty1 rootwait rw root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f
> 
> LABEL backup
>        MENU LABEL backup kernel
>        LINUX backup/zImage
>        FDTDIR backup/
>        APPEND console=ttyS0,115200n8 console=tty1 rootwait rw root=PARTUUID=5f71e06f-be08-48ed-b1ef-ee4800cc860f

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

[Rob Herring]

On Fri, Apr 18, 2014 at 12:23 PM, 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, 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:

Huh, why would I use grub. I just boot my kernels directly. :)
Enabling this for grub was something requested for highbank that I'm
just getting around to.

> 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?

Uggg, That certainly sounds pointless to use.

Leif, comments?

> 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?

I don't disagree, but at least some distros keep saying they must have
grub itself. That's why grub on u-boot was done in the first place.

Rob

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

[Leif Lindholm]

On Fri, Apr 18, 2014 at 05:54:51PM -0500, Rob Herring wrote:
> > 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?
> 
> Uggg, That certainly sounds pointless to use.
> 
> Leif, comments?

a)
As for speed, the u-boot grub used to run with caches disabled (default
mode for "kernel" image loaded by bootm). Vladimir got fed up just
before Christmas and changed that, so it's now fast even on the RPi..

b)
There is no real restriction on RAM size (other than you having enough),
but the link address is currently fixed at build time.
Optimally, the grub kernel should be position independent, but that
wasn't trivial, and by the time the basic port was upstream, Linaro
Enterprise Group had de-prioritised work on 32-bit ARM.

Ian Campbell wrote some neat patches for patching the (grub) kernel
link addres at grub-install time, which would be an improvement, but is
also quite invasive over several ports:
http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00426.html

/
    Leif

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

[Ian Campbell]

On Sat, 2014-04-19 at 02:05 +0100, Leif Lindholm wrote:
> Ian Campbell wrote some neat patches for patching the (grub) kernel
> link addres at grub-install time, which would be an improvement, but is
> also quite invasive over several ports:
> http://lists.gnu.org/archive/html/grub-devel/2013-12/msg00426.html

Even with this you still need some sort of distro mechanism for
determining the grub load address for the platform at installation time,
which is a pain.

Leif and I also poked at the possibility of a relocatable (i.e. PIC/PIE)
grub image, but just couldn't get the compiler to produce anything
halfway correct (not sure why, but it was getting into some of the
dustier corners of gcc/ld options).

Ian.

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

[Ian Campbell]

On Fri, 2014-04-18 at 11:23 -0600, Stephen Warren wrote:
> That said, I still conceptually object to config_distro_defaults.h
> enabling API support in order to support grub;

A worse problem is that I'm far from convinced that the API is suitable
to be used in production.

The mechanism for determining the API entry point involves scanning the
region around some address looking for a signature. The search area is
determined by the coincidence that the API signature struct is allocated
with u-boot's malloc and can therefore be found somewhere near the GD
pointer, which happens to be in a register which is luckily not
corrupted when booting. grub has a hack for at least one platform which
mallocd more data and therefore the signature ended up outside of the
region to be searched.

The calling convention is also somewhat poorly specified, and has been
broken at least once because the app is required to preserve u-boot's GD
pointer in the correct register and that register has changed at least
once inadvertently because the GD register isn't (wasn't?) considered
API. http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/174287

Maybe some of this is just down to the API not being very widely used in
practice, but to me it has the smell of a prototype which got out of
hand and became an API without someone revisiting the issues which made
it experimental to start with...

Look at the history of api/* and example/api/*. Other than occasional
build fixes and generic changes which touch it nothing has really
changed since the very first "experimental" commit...

Sorry if this comes across as ragging on the API, but my experience with
using it for grub-on-u-boot was incredibly frustrating and not very
reassuring...

Ian.