[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