Hi,
I want to use something like LinuxBIOS/Coreboot to allow my software to be installed as "boot from ROM" by end-users.
Previously (many months ago) I assessed LinuxBIOS and found that it wasn't a viable option, as my payload would need to be constantly updated to reflect changes in LinuxBIOS, and I couldn't have a single payload that worked regardless of which (past, present and future) version of LinuxBIOS/Coreboot the end-user installs.
As LinuxBIOS/Coreboot is *almost* exactly what I'm looking for, I'm wondering if this situation has changed or if it's likely to change in future; or if LinuxBIOS/Coreboot will never be a viable option.
Specifically, I need something that puts the computer into a well defined state and passes information to the payload in a well defined manner. This implies that any future changes to the firmware are either transparent to the payload, or that future changes preserve backward compatibility for the payload.
Note: This doesn't mean that Coreboot couldn't be extended, only that the payload would need to detect (via. a well defined method) which version of Coreboot is present before using features/information added in later versions.
Basically, I want to implement code that complies with some sort of "Coreboot Specification" and know that my code will work for all (past, present and future) versions of Coreboot, and that end-users will be able to independently update the version of Coreboot they're using or the version of my software they're using without compatibility problems between different versions of both projects.
Cheers,
Brendan
On Sat, Jan 26, 2008 at 08:20:06AM +0000, Brendan Trotter wrote:
Basically, I want to implement code that complies with some sort of "Coreboot Specification" and know that my code will work for all (past, present and future) versions of Coreboot
It would be great if you would help create this.
What, specifically, do you need?
So far there is the coreboot table with some information about the system, and payloads are 32-bit elf binaries.
Perhaps the best solution for you is to write a special loader payload that abstracts away coreboot and then hands over to your main application?
//Peter
Peter Stuge wrote:
On Sat, Jan 26, 2008 at 08:20:06AM +0000, Brendan Trotter wrote:
Basically, I want to implement code that complies with some sort of "Coreboot Specification" and know that my code will work for all (past, present and future) versions of Coreboot
It would be great if you would help create this.
Back in 2005 I started writing up specifications compliant to the according IEEE standards for project management and testing. It's just a start and nowhere near complete, but may be worth a look: http://www.coreboot.org/Distributed_and_Automated_Testsystem
Please, if you have time, ideas, contributions, help us to improve those documents.
Stuff like this is relevant to get LinuxBIOS into safety critical applications.
Hi,
On 1/27/08, Peter Stuge peter@stuge.se wrote:
What, specifically, do you need?
For long-term viability, I need something (e.g. a formal specification) that gives guarantees on the (past, present and future) behaviour that a payload can expect from Coreboot, which includes considerations for both forward and backward compatability.
So far there is the coreboot table with some information about the system, and payloads are 32-bit elf binaries.
Yes, and the structure used by entries in the coreboot table is a good start (e.g. "type + length + data", where unrecognised entries defined in later versions of coreboot can easily be skipped by older payloads that don't recognise these entries). But this alone isn't enough, as nothing says which entries are optional and which entries are required, nothing says which data values are permitted for each entry type, and nothing guarantees that "coreboot version N+1" won't use entirely different entries or an entirely different structure.
Payloads are 32-bit (and maybe 64-bit, and possibly compressed?) elf binaries, but does coreboot support relocations? If the payload is linked to be loaded at the fixed address 0x40000000 will it work if the computer only has 128 MB of RAM? What happens if the payload's main function returns to coreboot? Which arguments are passed to the payload's main function?
Perhaps the best solution for you is to write a special loader payload that abstracts away coreboot and then hands over to your main application?
That is what I'd like to do. However, there's a difference between writing one special loader payload for all versions of coreboot/LinuxBIOS, and writing many seperate payloads (one for each different version of coreboot/LinuxBIOS) while also monitoring the coreboot mailing list and contantly maintaining my code to keep up with changes.
On 1/27/08, Peter Stuge peter@stuge.se also wrote:
It would be great if you would help create this.
I wouldn't consider it appropriate for a relative stranger who has no intention of becoming a project member/developer (ie. me) to create a specification that all future versions of coreboot must comply with. This sort of specification is something the project leader should write (or IMHO, should have written).
There is a compromise here though: I'm willing to write a *draft* specification (in HTML format), that coreboot project members could use as a reference or as the basis for their own specification. The draft specification would be mostly a work of fiction - something that specifies how I would do things if I was doing things, rather than something that specifies how coreboot members will do things or how coreboot members have done things...
Cheers,
Brendan
Hi,
On 28.01.2008 21:04, Brendan Trotter wrote:
On 1/27/08, Peter Stuge peter@stuge.se wrote:
What, specifically, do you need?
For long-term viability, I need something (e.g. a formal specification) that gives guarantees on the (past, present and future) behaviour that a payload can expect from Coreboot, which includes considerations for both forward and backward compatability.
A forked version of Elfboot would be a good way to achieve that. You'd have to port that fork to newer coreboot versions, though. Or adopt my suggestion below and use Linux.
So far there is the coreboot table with some information about the system, and payloads are 32-bit elf binaries.
Yes, and the structure used by entries in the coreboot table is a good start (e.g. "type + length + data", where unrecognised entries defined in later versions of coreboot can easily be skipped by older payloads that don't recognise these entries). But this alone isn't enough, as nothing says which entries are optional and which entries are required, nothing says which data values are permitted for each entry type, and nothing guarantees that "coreboot version N+1" won't use entirely different entries or an entirely different structure.
Exactly. That's why you don't want the eternal interface guarantee from coreboot, but from a payload which serves as abstraction layer and can be modified according to your liking.
Payloads are 32-bit (and maybe 64-bit, and possibly compressed?) elf binaries, but does coreboot support relocations? If the payload is linked to be loaded at the fixed address 0x40000000 will it work if the computer only has 128 MB of RAM? What happens if the payload's main function returns to coreboot?
Depends on the coreboot version, on how much memory was clobbered, whether the payload reconfigured the chipset, etc.
Which arguments are passed to the payload's main function?
None, mostly.
Perhaps the best solution for you is to write a special loader payload that abstracts away coreboot and then hands over to your main application?
That is what I'd like to do. However, there's a difference between writing one special loader payload for all versions of coreboot/LinuxBIOS, and writing many seperate payloads (one for each different version of coreboot/LinuxBIOS) while also monitoring the coreboot mailing list and contantly maintaining my code to keep up with changes.
We don't guarantee any interface stability. Doing that would be insane. We don't actively try to break the interface, but... There are many new and exciting developments in the area of passing information from firmware to operating systems. The field is not mature enough for painless standardization.
On 1/27/08, Peter Stuge peter@stuge.se also wrote:
It would be great if you would help create this.
I wouldn't consider it appropriate for a relative stranger who has no intention of becoming a project member/developer (ie. me) to create a specification that all future versions of coreboot must comply with. This sort of specification is something the project leader should write (or IMHO, should have written).
Such a specification is only appropriate once the majority of boards on the market are supported, possibly including boards for architectures besides x86. I do NOT expect any formally binding specification at least for the next two years.
There is a compromise here though: I'm willing to write a *draft* specification (in HTML format), that coreboot project members could use as a reference or as the basis for their own specification. The draft specification would be mostly a work of fiction - something that specifies how I would do things if I was doing things, rather than something that specifies how coreboot members will do things or how coreboot members have done things...
There is one very easy way out: Linux. The Linux kernel guarantees most of its userspace interfaces to be stable for years, if not decades. Coreboot will be able to launch Linux as a payload for the foreseeable future. Implement your code as Linux userspace software and be happy.
Regards, Carl-Daniel
Hi again Brendan,
On Mon, Jan 28, 2008 at 08:04:28PM +0000, Brendan Trotter wrote:
On 1/27/08, Peter Stuge peter@stuge.se wrote:
What, specifically, do you need?
For long-term viability, I need something (e.g. a formal specification) that gives guarantees on the (past, present and future) behaviour that a payload can expect from Coreboot, which includes considerations for both forward and backward compatability.
This is not very specific, quite the contrary this is completely generic. I asked so you can tell us what you would like.
Yes, and the structure used by entries in the coreboot table is a good start (e.g. "type + length + data", where unrecognised entries defined in later versions of coreboot can easily be skipped by older payloads that don't recognise these entries). But this alone isn't enough,
Very true.
Payloads are 32-bit (and maybe 64-bit, and possibly compressed?) elf binaries, but does coreboot support relocations? If the payload is linked to be loaded at the fixed address 0x40000000 will it work if the computer only has 128 MB of RAM?
Is this functionality that you need?
What happens if the payload's main function returns to coreboot? Which arguments are passed to the payload's main function?
The payload can not return. Coreboot does not leave a return address on the stack. When the payload is started, Coreboot is history.
On 1/27/08, Peter Stuge peter@stuge.se also wrote:
It would be great if you would help create this.
I wouldn't consider it appropriate for a relative stranger who has no intention of becoming a project member/developer (ie. me) to create a specification
I disagree. This is one great thing about open source.
Specifically because noone else has created what you need, it is not only appropriate but also encouraged if you, however strange you are, would contribute on the matter. With that contribution (and actually with this discussion) I already consider you a member of the project. All is not code.
that all future versions of coreboot must comply with.
I think this is a separate discussion. I realize it is crucial to you, but perhaps the discussion can lead to new innovations which can loosen requirements.
This sort of specification is something the project leader should write (or IMHO, should have written).
That's not really a community development model, is it? That sounds like a very hiearchichal model, which is not too common in small projects like our own.
Open source for me is all about anyone and everyone contributing whatever they can when they can and want to.
There is a compromise here though: I'm willing to write a *draft* specification (in HTML format), that coreboot project members could use as a reference or as the basis for their own specification.
As you may have noticed from following the list, this is exactly how we work - someone makes a suggestion, people iterate on it and discuss, eventually arriving at code, or the trashcan. :)
The draft specification would be mostly a work of fiction - something that specifies how I would do things if I was doing things, rather than something that specifies how coreboot members will do things or how coreboot members have done things...
I think it would be awesome if you could do that! No need to make it fancy, a plain text email to the list is perfectly fine. (And may actually be prefered over HTML for some project members.)
//Peter
-
Brendan Trotter -
Carl-Daniel Hailfinger -
Peter Stuge -
Stefan Reinauer