config: enable CONFIG_API in distro config
PATCH 1/1 config: enable CONFIG_API in distro config
From: Rob Herring <[email protected]>
CONFIG_API is needed for u-boot apps such as grub2, so enable it for distro config.
--- include/config_distro_defaults.h | 1 + 1 file changed, 1 insertion(+)
include/config_distro_defaults.h +1 -0
@@ -30,6 +30,7 @@#endif #define CONFIG_OF_LIBFDT +#define CONFIG_API #define CONFIG_CMD_BOOTZ #define CONFIG_CMD_DHCP
Signature · 1 line
1.9.1
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>
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!
Signature · 8 lines
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>
Quoted 7 lines · Tom Rini
Quoted 5 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.
Quoted 7 lines
Quoted 2 lines
Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>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-widerpi_bvenice2colibri_t20_iristec-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.
Quoted 16 lines · Stephen Warren
Quoted 7 lines · Tom Rini
Quoted 5 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Quoted 7 lines
Quoted 2 lines
Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>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-widerpi_bvenice2colibri_t20_iristec-ng seaboard
Quoted 7 lines
Hmm. That's all or most Tegra boards. What's the break?
That said, I wonder why we need
CONFIG_APIin 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).
Quoted 4 lines
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Signature · 8 lines
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>
Quoted 19 lines · Tom Rini
Quoted 18 lines · Stephen Warren
Quoted 7 lines · Tom Rini
Quoted 5 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Quoted 7 lines
Quoted 2 lines
Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHmm. That's all or most Tegra boards. What's the break?
Quoted 7 lines
Quoted 5 lines
That said, I wonder why we need
CONFIG_APIin 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?
Quoted 11 lines · Stephen Warren
Quoted 10 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>
Quoted 6 lines
Quoted 4 lines
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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHmm. 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.
Quoted 5 lines
That said, I wonder why we need
CONFIG_APIin 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
If Rob broke it, Rob should fix it.
--
nvpublic
Quoted 33 lines
-----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: enableCONFIG_APIin distro config* PGP Signed by an unknown key
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHow 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
Quoted 1 line · Tom Warren
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.
Signature · 8 lines
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>
Quoted 7 lines · Tom Rini
Quoted 1 line · Tom Warren
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_DEVICEfor 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
Quoted 10 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>
Quoted 8 lines
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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHow 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?
Hi Stephen,
Quoted 43 lines · Stephen Warren
Quoted 10 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>Quoted 8 lines
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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHow 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_APIenabled.That said, I still conceptually object to
config_distro_defaults.henabling 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 ofconfig_distro_defaults.hin 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?
Quoted 2 lines
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
Quoted 32 lines · Simon Glass
Hi Stephen,
Quoted 29 lines · Stephen Warren
Quoted 10 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>Quoted 8 lines
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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHow 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_APIenabled.That said, I still conceptually object to
config_distro_defaults.henabling 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.
Quoted 8 lines
etc. Without this, we'll force every U-Boot binary to
Quoted 4 lines
be bloated with all kinds of redundant code. Having a single standard mechanism was always the point of
config_distro_defaults.hin 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.
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi Dennis,
Quoted 42 lines · Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 36 lines · On Sat, 19 Apr 2014 15:01:40 +0100 Ian Campbell <[email protected]> wrote:
Quoted 34 lines · Simon Glass
Hi Stephen,
Quoted 30 lines · Stephen Warren
Quoted 16 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>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-widerpi_bvenice2colibri_t20_iristec-ng seaboardQuoted 3 lines
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_APIenabled.That said, I still conceptually object to
config_distro_defaults.henabling 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,
Quoted 4 lines
Quoted 1 line
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.
Quoted 29 lines
Quoted 3 lines
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
Quoted 11 lines
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.
Quoted 7 lines
etc. Without this, we'll force every U-Boot binary to
Quoted 5 lines
be bloated with all kinds of redundant code. Having a single standard mechanism was always the point of
config_distro_defaults.hin 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?Quoted 7 lines
Quoted 2 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
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
Quoted 47 lines · On Sun, 20 Apr 2014 09:55:53 -0700 Simon Glass <[email protected]> wrote:
Hi Dennis,
Quoted 43 lines · Dennis Gilmore
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 37 lines · On Sat, 19 Apr 2014 15:01:40 +0100 Ian Campbell <[email protected]> wrote:
Quoted 35 lines · Simon Glass
Hi Stephen,
Quoted 31 lines · Stephen Warren
Quoted 16 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>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-widerpi_bvenice2colibri_t20_iristec-ng seaboardQuoted 3 lines
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_APIenabled.That said, I still conceptually object to
config_distro_defaults.henabling 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,
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
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.
Quoted 39 lines
Quoted 30 lines
Quoted 4 lines
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
Quoted 11 lines
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.
Quoted 7 lines
etc. Without this, we'll force every U-Boot binary to
Quoted 5 lines
be bloated with all kinds of redundant code. Having a single standard mechanism was always the point of
config_distro_defaults.hin 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?Quoted 7 lines
Quoted 2 lines
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.
Quoted 8 lines
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.
Quoted 2 lines
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.
Quoted 9 lines
Quoted 6 lines
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.
Quoted 2 lines
Regards,
Simon
Dennis
Hi Dennis,
Quoted 5 lines · Dennis Gilmore
On Sun, 20 Apr 2014 09:55:53 -0700
Simon Glass <[email protected]> wrote:[snip]
Quoted 9 lines
Can you suggest a starting point for trying this out on am ARM
Quoted 1 line
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?
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
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.
Quoted 6 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
Regards,
SimonDennis
Regards,
Simon
Quoted 20 lines · Simon Glass
Hi Dennis,
On 21 April 2014 08:49, Dennis Gilmore <[email protected] <mailto:[email protected]>> wrote:
On Sun, 20 Apr 2014 09:55:53 -0700
Simon Glass <sjg at chromium.org <mailto:[email protected]>> wrote:[snip]
Quoted 2 lines
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.
Quoted 2 lines
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:
Quoted 16 lines
TIMEOUT 30
default primaryMENU 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-ee4800cc860fLABEL 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
Quoted 32 lines · Stephen Warren
Quoted 10 lines · Tom Rini
Quoted 7 lines · Rob Herring
From: Rob Herring <[email protected]>
CONFIG_APIis needed for u-boot apps such as grub2, so enable it for distro config.Cc Dennis Gilmore <[email protected]>Signed-off-by Rob Herring <[email protected]>Quoted 8 lines
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-widerpi_bvenice2colibri_t20_iristec-ng seaboardHow 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_APIenabled.That said, I still conceptually object to
config_distro_defaults.henabling 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 ofconfig_distro_defaults.hin my mind.
Quoted 1 line
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.
Quoted 8 lines
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?
Quoted 2 lines
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
Quoted 9 lines · Rob Herring
Quoted 8 lines
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?
Quoted 3 lines
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
Quoted 4 lines · Leif Lindholm
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.
Quoted 2 lines · Stephen Warren
That said, I still conceptually object to
config_distro_defaults.henabling 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.