Hi,
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
On 09/09/08 18:59 +0200, Robert Millan wrote:
Hi,
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
I don't suppose we could talk you into a v2 patch as well?
Jordan
On Tue, Sep 09, 2008 at 11:19:27AM -0600, Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
Hi,
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Good :-). I'll get to work.
I don't suppose we could talk you into a v2 patch as well?
Maybe ;-). I do the v3 patch, and once we're done with it, I'll see how easy/hard it is to backport it, is that ok?
Thanks
On 09.09.2008 19:37, Robert Millan wrote:
On Tue, Sep 09, 2008 at 11:19:27AM -0600, Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
That means the concerns about size are valid and the proposed way to fix them won't work.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Good :-). I'll get to work.
I don't suppose we could talk you into a v2 patch as well?
Maybe ;-). I do the v3 patch, and once we're done with it, I'll see how easy/hard it is to backport it, is that ok?
What advantages does Multiboot have over storing the parsed kernel in the LAR? Will Multiboot make SELF obsolete before it's even introduced? How about the ELF loader already in coreboot v3?
Regards, Carl-Daniel
On 09/09/08 20:00 +0200, Carl-Daniel Hailfinger wrote:
On 09.09.2008 19:37, Robert Millan wrote:
On Tue, Sep 09, 2008 at 11:19:27AM -0600, Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
That means the concerns about size are valid and the proposed way to fix them won't work.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Good :-). I'll get to work.
I don't suppose we could talk you into a v2 patch as well?
Maybe ;-). I do the v3 patch, and once we're done with it, I'll see how easy/hard it is to backport it, is that ok?
What advantages does Multiboot have over storing the parsed kernel in the LAR? Will Multiboot make SELF obsolete before it's even introduced? How about the ELF loader already in coreboot v3?
There is no one true load method. If Robert is willing to do the work, then it is something that should be considered. It makes nothing obsolete and it makes coreboot more useful. It is hard to object to that.
Jordan
On Tue, Sep 09, 2008 at 01:24:44PM -0600, Jordan Crouse wrote:
What advantages does Multiboot have over storing the parsed kernel in the LAR? Will Multiboot make SELF obsolete before it's even introduced? How about the ELF loader already in coreboot v3?
There is no one true load method. If Robert is willing to do the work, then it is something that should be considered. It makes nothing obsolete and it makes coreboot more useful. It is hard to object to that.
Particularly if you consider how widespread use of multiboot is.
Thanks, Ward.
On Tue, Sep 09, 2008 at 08:00:53PM +0200, Carl-Daniel Hailfinger wrote:
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
So if I show you working code that proves your statement wrong, I assume you'd have no objection?
That means the concerns about size are valid and the proposed way to fix them won't work.
I believe I can implement a loader whose size is reasonably small. But again, I'd rather back that up with code than expect to be blindly trusted.
What advantages does Multiboot have over storing the parsed kernel in the LAR? Will Multiboot make SELF obsolete before it's even introduced? How about the ELF loader already in coreboot v3?
I think you're confusing Multiboot with an executable file format, like ELF, but it's mostly orthogonal to that. In fact, Multiboot is commonly used in combination with ELF.
And I don't know what SELF is, but I don't pretend to obsolete anything, just want to provide users with an option.
On 09.09.2008 21:26, Robert Millan wrote:
On Tue, Sep 09, 2008 at 08:00:53PM +0200, Carl-Daniel Hailfinger wrote:
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
So if I show you working code that proves your statement wrong, I assume you'd have no objection?
Please explain how exactly you can tell the OS about reserved memory areas without coreboot tables and without e820 tables. The official multiboot spec has no way to do that.
And "working code" means you have to solve that reserved memory problem, otherwise it's working by accident.
That means the concerns about size are valid and the proposed way to fix them won't work.
I believe I can implement a loader whose size is reasonably small. But again, I'd rather back that up with code than expect to be blindly trusted.
My point was that you can't save some size by disabling coreboot tables. Since the multiboot loader will have nonzero size, there will be a size increase.
What advantages does Multiboot have over storing the parsed kernel in the LAR? Will Multiboot make SELF obsolete before it's even introduced? How about the ELF loader already in coreboot v3?
I think you're confusing Multiboot with an executable file format, like ELF, but it's mostly orthogonal to that. In fact, Multiboot is commonly used in combination with ELF.
No, I was talking about the coreboot ability of booting ELF files directly. Since coreboot does not have a disk driver, that multiboot interface will only be used to boot operating systems in the ROM. Right?
And I don't know what SELF is, but I don't pretend to obsolete anything, just want to provide users with an option.
That SELF question was directed at Jordan and he sort of answered it.
Regards, Carl-Daniel
On Tue, Sep 09, 2008 at 09:39:03PM +0200, Carl-Daniel Hailfinger wrote:
On 09.09.2008 21:26, Robert Millan wrote:
On Tue, Sep 09, 2008 at 08:00:53PM +0200, Carl-Daniel Hailfinger wrote:
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
So if I show you working code that proves your statement wrong, I assume you'd have no objection?
Please explain how exactly you can tell the OS about reserved memory areas without coreboot tables and without e820 tables. The official multiboot spec has no way to do that.
Yes, it does. You must have missed it.
I believe I can implement a loader whose size is reasonably small. But again, I'd rather back that up with code than expect to be blindly trusted.
My point was that you can't save some size by disabling coreboot tables. Since the multiboot loader will have nonzero size, there will be a size increase.
Maybe I can save size, or maybe not, but in either case I don't expect my code will be taking an unreasonable amount of bytes (and then again, you don't have to use it if you don't want to).
No, I was talking about the coreboot ability of booting ELF files directly. Since coreboot does not have a disk driver, that multiboot interface will only be used to boot operating systems in the ROM. Right?
Right.
On 09.09.2008 21:53, Robert Millan wrote:
On Tue, Sep 09, 2008 at 09:39:03PM +0200, Carl-Daniel Hailfinger wrote:
On 09.09.2008 21:26, Robert Millan wrote:
On Tue, Sep 09, 2008 at 08:00:53PM +0200, Carl-Daniel Hailfinger wrote:
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
So if I show you working code that proves your statement wrong, I assume you'd have no objection?
Please explain how exactly you can tell the OS about reserved memory areas without coreboot tables and without e820 tables. The official multiboot spec has no way to do that.
Yes, it does. You must have missed it.
Let me quote the spec:
The format of the Multiboot information structure (as defined so far) follows:
+-------------------+ 0 | flags | (required) +-------------------+ 4 | mem_lower | (present if flags[0] is set) 8 | mem_upper | (present if flags[0] is set) +-------------------+ 12 | boot_device | (present if flags[1] is set) +-------------------+ 16 | cmdline | (present if flags[2] is set) +-------------------+ 20 | mods_count | (present if flags[3] is set) 24 | mods_addr | (present if flags[3] is set) +-------------------+ 28 - 40 | syms | (present if flags[4] or | | flags[5] is set) +-------------------+ 44 | mmap_length | (present if flags[6] is set) 48 | mmap_addr | (present if flags[6] is set) +-------------------+ 52 | drives_length | (present if flags[7] is set) 56 | drives_addr | (present if flags[7] is set) +-------------------+ 60 | config_table | (present if flags[8] is set) +-------------------+ 64 | boot_loader_name | (present if flags[9] is set) +-------------------+ 68 | apm_table | (present if flags[10] is set) +-------------------+ 72 | vbe_control_info | (present if flags[11] is set) 76 | vbe_mode_info | 80 | vbe_mode | 82 | vbe_interface_seg | 84 | vbe_interface_off | 86 | vbe_interface_len | +-------------------+
Please tell me where I can find the mechanism to reserve arbitrary memory regions in the above spec extract.
I believe I can implement a loader whose size is reasonably small. But again, I'd rather back that up with code than expect to be blindly trusted.
My point was that you can't save some size by disabling coreboot tables. Since the multiboot loader will have nonzero size, there will be a size increase.
Maybe I can save size, or maybe not, but in either case I don't expect my code will be taking an unreasonable amount of bytes (and then again, you don't have to use it if you don't want to).
OK.
No, I was talking about the coreboot ability of booting ELF files directly. Since coreboot does not have a disk driver, that multiboot interface will only be used to boot operating systems in the ROM. Right?
Right.
In that case, adding the multiboot support to libpayload would indeed be the way to go.
Regards, Carl-Daniel
On Tue, Sep 09, 2008 at 10:12:17PM +0200, Carl-Daniel Hailfinger wrote:
Please tell me where I can find the mechanism to reserve arbitrary memory regions in the above spec extract.
I'm sorry, but I lack the time for this. When I provide a patch, I assume it'll be clarified.
On 09.09.2008 22:27, Robert Millan wrote:
On Tue, Sep 09, 2008 at 10:12:17PM +0200, Carl-Daniel Hailfinger wrote:
Please tell me where I can find the mechanism to reserve arbitrary memory regions in the above spec extract.
I'm sorry, but I lack the time for this. When I provide a patch, I assume it'll be clarified.
I provided proof that your claim is wrong according to the official multiboot spec. You have exactly two ways out: - Prove (by quoting the spec) that I misread the spec. - Tell us about another version of the spec which has the feature I asked for.
Regards, Carl-Daniel
On Tue, Sep 09, 2008 at 10:46:42PM +0200, Carl-Daniel Hailfinger wrote:
On 09.09.2008 22:27, Robert Millan wrote:
On Tue, Sep 09, 2008 at 10:12:17PM +0200, Carl-Daniel Hailfinger wrote:
Please tell me where I can find the mechanism to reserve arbitrary memory regions in the above spec extract.
I'm sorry, but I lack the time for this. When I provide a patch, I assume it'll be clarified.
I provided proof that your claim is wrong according to the official multiboot spec. You have exactly two ways out:
- Prove (by quoting the spec) that I misread the spec.
- Tell us about another version of the spec which has the feature I
asked for.
Since you're obviously challenging me, I will choose the way I see fit to respond to your challenge.
And the way I choose is by sending code that proves you wrong.
Carl-Daniel Hailfinger wrote:
On 09.09.2008 19:37, Robert Millan wrote:
On Tue, Sep 09, 2008 at 11:19:27AM -0600, Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Sorry, that won't fly. The official Multiboot spec at http://www.gnu.org/software/grub/manual/multiboot/multiboot.html lacks quite a few things needed by the OS and supported by coreboot tables.
That means the concerns about size are valid and the proposed way to fix them won't work.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Good :-). I'll get to work.
I don't suppose we could talk you into a v2 patch as well?
Maybe ;-). I do the v3 patch, and once we're done with it, I'll see how easy/hard it is to backport it, is that ok?
What advantages does Multiboot have over storing the parsed kernel in the LAR? Will Multiboot make SELF obsolete before it's even introduced?
No, it's another thing that would be parsed into SELF if done right. I think it's a libpayload job though, and can be used by, for example, bayou and filo,... and possibly coreinfo and others...
Robert Millan wrote:
On Tue, Sep 09, 2008 at 11:19:27AM -0600, Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
Hi,
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Good :-). I'll get to work.
I don't suppose we could talk you into a v2 patch as well?
Maybe ;-). I do the v3 patch, and once we're done with it, I'll see how easy/hard it is to backport it, is that ok?
In v3, we basically even dropped the ELF parser from coreboot itself and have the lar utility parse the ELF instead.
I believe it would be the best thing to extend lar in the same way so it can preparse multiboot. that way code size in coreboot is not an issue.
v2 is a different story.
On Tue, Sep 09, 2008 at 09:40:31PM +0200, Stefan Reinauer wrote:
In v3, we basically even dropped the ELF parser from coreboot itself and have the lar utility parse the ELF instead.
I believe it would be the best thing to extend lar in the same way so it can preparse multiboot. that way code size in coreboot is not an issue.
Multiboot is not really something that is "parsed" like ELF. I think I should better prepare that patch, then you'll see what I mean.
Robert Millan wrote:
On Tue, Sep 09, 2008 at 09:40:31PM +0200, Stefan Reinauer wrote:
In v3, we basically even dropped the ELF parser from coreboot itself and have the lar utility parse the ELF instead.
I believe it would be the best thing to extend lar in the same way so it can preparse multiboot. that way code size in coreboot is not an issue.
Multiboot is not really something that is "parsed" like ELF.
What makes you say so? What part would keep multiboot from being preparsed?
On Tue, Sep 09, 2008 at 10:05:27PM +0200, Stefan Reinauer wrote:
Robert Millan wrote:
On Tue, Sep 09, 2008 at 09:40:31PM +0200, Stefan Reinauer wrote:
In v3, we basically even dropped the ELF parser from coreboot itself and have the lar utility parse the ELF instead.
I believe it would be the best thing to extend lar in the same way so it can preparse multiboot. that way code size in coreboot is not an issue.
Multiboot is not really something that is "parsed" like ELF.
What makes you say so? What part would keep multiboot from being preparsed?
I think it's better if I provide a proof-of-concept patch, and then we discuss how this preparsing would work.
On 09/09/08 22:28 +0200, Robert Millan wrote:
On Tue, Sep 09, 2008 at 10:05:27PM +0200, Stefan Reinauer wrote:
Robert Millan wrote:
On Tue, Sep 09, 2008 at 09:40:31PM +0200, Stefan Reinauer wrote:
In v3, we basically even dropped the ELF parser from coreboot itself and have the lar utility parse the ELF instead.
I believe it would be the best thing to extend lar in the same way so it can preparse multiboot. that way code size in coreboot is not an issue.
Multiboot is not really something that is "parsed" like ELF.
What makes you say so? What part would keep multiboot from being preparsed?
I think it's better if I provide a proof-of-concept patch, and then we discuss how this preparsing would work.
Indeed - lets stop trying to beat up Robert and let him write some code. We do not want to be that project that never matures because we are too busy trying to second guess ourselves and generate "perfect" code out of the chute. Working code beats conjecture any day of the week. Robert - make multiboot work, and we will adjust our home-grown half baked "standards" to your needs, and not force you to adjust yours to ours.
Jordan
On Tue, Sep 09, 2008 at 02:46:25PM -0600, Jordan Crouse wrote:
On 09/09/08 22:28 +0200, Robert Millan wrote:
On Tue, Sep 09, 2008 at 10:05:27PM +0200, Stefan Reinauer wrote:
Robert Millan wrote:
On Tue, Sep 09, 2008 at 09:40:31PM +0200, Stefan Reinauer wrote:
In v3, we basically even dropped the ELF parser from coreboot itself and have the lar utility parse the ELF instead.
I believe it would be the best thing to extend lar in the same way so it can preparse multiboot. that way code size in coreboot is not an issue.
Multiboot is not really something that is "parsed" like ELF.
What makes you say so? What part would keep multiboot from being preparsed?
I think it's better if I provide a proof-of-concept patch, and then we discuss how this preparsing would work.
Indeed - lets stop trying to beat up Robert and let him write some code. We do not want to be that project that never matures because we are too busy trying to second guess ourselves and generate "perfect" code out of the chute. Working code beats conjecture any day of the week. Robert - make multiboot work, and we will adjust our home-grown half baked "standards" to your needs, and not force you to adjust yours to ours.
Thanks Jordan. I'll get to work now ...
Indeed - lets stop trying to beat up Robert and let him write some code. We do not want to be that project that never matures because we are too busy trying to second guess ourselves and generate "perfect" code out of the chute. Working code beats conjecture any day of the week. Robert - make multiboot work, and we will adjust our home-grown half baked "standards" to your needs, and not force you to adjust yours to ours.
Thanks Jordan. I'll get to work now ...
Here, here Jordan. Robert do your thing :-)
On Tue, Sep 09, 2008 at 11:19:27AM -0600, Jordan Crouse wrote:
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Same here. Unconditional support.
Thanks! Ward.
Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
Hi,
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Absolutely. But maybe this is something that should go into libpayload instead, so many others can play well?
Stefan
On 09.09.2008 21:33, Stefan Reinauer wrote:
Jordan Crouse wrote:
On 09/09/08 18:59 +0200, Robert Millan wrote:
Hi,
I'm thinking that it'd be interesting for coreboot to have direct support for Multiboot, so that Multiboot kernels can be used directly without GRUB/FILO as middle man (somewhat like this thing you call "LAB").
When I brought this up on IRC, Patrick expressed concerns about size. I suppose the best would be to give users the option to provide either coreboot tables or Multiboot, whatever is needed for their payload, instead of adding both things unconditionally.
Nevertheless I don't expect the basic Multiboot support to be excessively big.
If this idea sounds fine, I could provide a patch for v3.
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Absolutely. But maybe this is something that should go into libpayload instead, so many others can play well?
That's a great idea! It would also enable Bayou (which is an awesome piece of software) to support Multiboot. In that scenario, everyone wins.
Regards, Carl-Daniel
On Tue, Sep 09, 2008 at 09:33:14PM +0200, Stefan Reinauer wrote:
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Absolutely. But maybe this is something that should go into libpayload instead, so many others can play well?
Isn't libpayload a library for payloads?
Robert Millan wrote:
On Tue, Sep 09, 2008 at 09:33:14PM +0200, Stefan Reinauer wrote:
I support this idea unconditionally. I know the limitations and concerns about multiboot - but playing well with others is something we need to do a better job of.
Absolutely. But maybe this is something that should go into libpayload instead, so many others can play well?
Isn't libpayload a library for payloads?
yes.
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Joseph Smith -
Peter Stuge -
Robert Millan -
Stefan Reinauer -
Ward Vandewege