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