[U-Boot] [PATCH] config: enable CONFIG_API in distro config
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
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!
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.
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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?
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
If Rob broke it, Rob should fix it.
-- nvpublic
-----Original Message----- From: Tom Rini [mailto:tom.rini@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@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
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.
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
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?
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
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.
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
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
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.
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.
participants (7)
-
Ian Campbell -
Leif Lindholm -
Rob Herring -
Simon Glass -
Stephen Warren -
Tom Rini -
Tom Warren