[coreboot] Multiboot support

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue Sep 9 22:12:17 CEST 2008


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/





More information about the coreboot mailing list