SONE Takeshi <ts...@cm...> writes:
> Hi,
> I think that Multiboot loader in Etherboot is not correctly
> implemented.
I am certain I looked at this before and seeing things
matching the etherboot behavior. But looking now
there is a difference in behavior.
Quoting the appropriate piece of the multiboot specification.
> If bit 6 in the multiboot_info.flags word is set, then the
> 'mmap_*' fields are valid, and indicate the address and length of
> a buffer containing a memory map of the machine provided by the
> BIOS. 'mmap_addr' is the address, and 'mmap_length' is the total
> size of the buffer. The buffer consists of one or more of the
> following size/structure pairs ('size' is really used for
> skipping to the next pair):
>
> +-------------------+
> -4 | size |
> +-------------------+
> 0 | BaseAddrLow |
> 4 | BaseAddrHigh |
> 8 | LengthLow |
> 12 | LengthHigh |
> 16 | Type |
> +-------------------+
>
> where 'size' is the size of the associated structure in bytes,
> which can be greater than the minimum of 20 bytes. 'BaseAddrLow'
> is the lower 32 bits of the starting address, and 'BaseAddrHigh'
> is the upper 32 bits, for a total of a 64-bit starting address.
> 'LengthLow' is the lower 32 bits of the size of the memory region
> in bytes, and 'LengthHigh' is the upper 32 bits, for a total of a
> 64-bit length. 'Type' is the variety of address range
> represented, where a value of 1 indicates available RAM, and all
> other values currently indicated a reserved area.
>
> The map provided is guaranteed to list all standard RAM that
> should be available for normal use.
The etherboot interpretation of this was that size only occurred
once and was at a negative offset from the beginning of the
buffer.
The oskit and grub interpretation seems to be that size is a
member of the structure that we have an array of.
+-------------------+
0 | size |
+-------------------+
4 | BaseAddrLow |
8 | BaseAddrHigh |
12 | LengthLow |
16 | LengthHigh |
24 | Type |
+-------------------+
SONE Takeshi <ts...@cm...> writes:
> The Specification says 'mmap_addr' points to 'size' of the
> first mmap entry, but Etherboot's structure points to
> 'base_addr_low'.
The specification says that size occurs at offset -4...
Which is what etherboot implements.
> Also, the 'size' of a mmap entry should not include the size of itself,
> but Etherboot does. (That is, a Multiboot OS looks at every 'size+4'
> bytes for mmap entries, but with Etherboot, the mmap entries are
> at every 'size' bytes.)
No. Etherboot gets the size part correct. It just only includes it
once.
> The Multiboot Specification may be ambiguous and misleading,
> but the example code in the Specification and the implementation
> in GRUB are different from Etherboot.
I agree here. Things are ambiguous.
> Eric's mkelfImage is based on Etherboot's implementation
> so it should also be fixed.
It is based on the same interpretation of the standard so
it has the same problem..
If you want to submit a patch to fix etherboot please go ahead.
I would request that anything that fixes multiboot support also
add the detection of the multiboot header so it can coexist with
more sane loaders.
If not I suggest we just delete that code. Since it is incorrect,
and there are better mechanisms in etherboot currently.
Eric
|