[PATCH] buildrom: Add support for OpenBIOS as payload
See patch. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
--- Config.in (Revision 169) +++ Config.in (Arbeitskopie) @@ -94,6 +94,7 @@ config USE_LZMA bool "Enable LZMA compression" depends on !(PAYLOAD_OFW && COREBOOT_V2) + depends on !(PAYLOAD_OPENBIOS && COREBOOT_V2) depends on !(PAYLOAD_FILO && COREBOOT_V2) depends on !(PAYLOAD_ETHERBOOT && COREBOOT_V2) default y I've always wondered what the reason for this is. Is there something magical about these payloads and their interactions with lzma? Thanks, Myles
On Mon, Apr 28, 2008 at 10:20:31AM -0600, Myles Watson wrote:
--- Config.in (Revision 169) +++ Config.in (Arbeitskopie) @@ -94,6 +94,7 @@ config USE_LZMA bool "Enable LZMA compression" depends on !(PAYLOAD_OFW && COREBOOT_V2) + depends on !(PAYLOAD_OPENBIOS && COREBOOT_V2) depends on !(PAYLOAD_FILO && COREBOOT_V2) depends on !(PAYLOAD_ETHERBOOT && COREBOOT_V2) default y
I've always wondered what the reason for this is. Is there something magical about these payloads and their interactions with lzma?
There seems to be some issue with OFW, not sure about the others, they're probably ok, but we should test that. OpenBIOS is ok too, I tested with a manual build. It seems the problem is with v2 boards doing nrv2b or no compression instead of lzma (which we usually expect in buildrom), but that's for another patch. Reattaching new patch for OpenBIOS, enabling the lzma option also. I also added a check for 'detok' from fcode-utils, so the user is warned if he doesn't have fcode-utils installed. Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-----Original Message----- From: Uwe Hermann [mailto:uwe@hermann-uwe.de] Sent: Wednesday, April 30, 2008 4:42 AM To: Myles Watson Cc: coreboot@coreboot.org Subject: Re: [coreboot] [PATCH] buildrom: Add support for OpenBIOS as a payload
On Mon, Apr 28, 2008 at 10:20:31AM -0600, Myles Watson wrote:
--- Config.in (Revision 169) +++ Config.in (Arbeitskopie) @@ -94,6 +94,7 @@ config USE_LZMA bool "Enable LZMA compression" depends on !(PAYLOAD_OFW && COREBOOT_V2) + depends on !(PAYLOAD_OPENBIOS && COREBOOT_V2) depends on !(PAYLOAD_FILO && COREBOOT_V2) depends on !(PAYLOAD_ETHERBOOT && COREBOOT_V2) default y
I've always wondered what the reason for this is. Is there something magical about these payloads and their interactions with lzma?
There seems to be some issue with OFW, not sure about the others, they're probably ok, but we should test that.
OpenBIOS is ok too, I tested with a manual build. It seems the problem is with v2 boards doing nrv2b or no compression instead of lzma (which we usually expect in buildrom), but that's for another patch.
Reattaching new patch for OpenBIOS, enabling the lzma option also. I also added a check for 'detok' from fcode-utils, so the user is warned if he doesn't have fcode-utils installed.
I agree with the TODO of building fcode-utils as a dependency. You could do the check and include it if fcode-utils is not already installed. Otherwise the user might not know where to get it. A separate issue is that you don't remove the .configured stamp on a make clean. With that change: Acked-by: Myles Watson <mylesgw@gmail.com> Thanks, Myles
On Wed, Apr 30, 2008 at 08:21:30AM -0600, Myles Watson wrote:
I agree with the TODO of building fcode-utils as a dependency. You could do the check and include it if fcode-utils is not already installed. Otherwise the user might not know where to get it.
I'm a bit uncertain here, we also don't install ruby or perl or subversion or git or wget for the user. Yes, fcode-utils is not as common as all the other utilities but there _are_ packages (e.g. in Debian) for it, or it can be installed manually from http://openbios.org/FCODE_suite I'll also document that in the wiki soon. Maybe it's a good idea to install them locally in the buildrom build dir if unavailable, but where do we draw the line in general? Are there some guidelines on what we install and we expect the user to have installed already (or manually install it on demand)?
A separate issue is that you don't remove the .configured stamp on a make clean.
With that change:
Acked-by: Myles Watson <mylesgw@gmail.com>
Done, r173, thanks! Uwe. -- http://www.hermann-uwe.de | http://www.holsham-traders.de http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
On Wed, Apr 30, 2008 at 08:21:30AM -0600, Myles Watson wrote:
I agree with the TODO of building fcode-utils as a dependency. You could do the check and include it if fcode-utils is not already installed. Otherwise the user might not know where to get it.
I'm a bit uncertain here, we also don't install ruby or perl or subversion or git or wget for the user. Yes, fcode-utils is not as common as all the other utilities but there _are_ packages (e.g. in Debian) for it, or it can be installed manually from
http://openbios.org/FCODE_suite
I'll also document that in the wiki soon. Maybe it's a good idea to install them locally in the buildrom build dir if unavailable, but where do we draw the line in general? Are there some guidelines on what we install and we expect the user to have installed already (or manually install it on demand)?
Good question. I personally would say that things that every distribution has we expect the user to install, and things that are rarer we install. Another way to do it would be to put installation instructions (at least the URL) in the warning. Myles
participants (2)
-
Myles Watson -
Uwe Hermann