Re: [U-Boot] config: enable CONFIG_API in distro config
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
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
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
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@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
participants (3)
-
Dennis Gilmore -
Simon Glass -
Stephen Warren