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 -- http://www.hailfinger.org/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
