The MB2 spec "definition of terms used through the specification" defines terms like "must", "should", but also "u8", "u16", "u32", and "u64":
> "u8" > The type of unsigned 8-bit data. > > "u16" > The type of unsigned 16-bit data. Because the target architecture > is little-endian, u16 is coded in little-endian. > > "u32" > The type of unsigned 32-bit data. Because the target architecture > is little-endian, u32 is coded in little-endian. > > "u64" > The type of unsigned 64-bit data. Because the target architecture > is little-endian, u64 is coded in little-endian. Does the sentence about the target architecture being LE, and thusly the integer value being LE as well still make sense in Multiboot2? To me this looks like a copy-and-paste error from the Multiboot1 specification. The description of the MB2 header layout says that the values in the OS image are in native endianness, not LE: > 3.1.1 The layout of Multiboot2 header > ------------------------------------- > > The layout of the Multiboot2 header must be as follows: > > Offset Type Field Name Note > 0 u32 magic required > 4 u32 architecture required > 8 u32 header_length required > 12 u32 checksum required > 16-XX tags required > > The fields 'magic', 'architecture', 'header_length' and 'checksum' > are defined in *note Header magic fields::, 'tags' are defined in > *note Header tags::. All fields are in native endianness. On > bi-endian platforms native-endianness means the endiannes OS image > starts in. And for the Boot Information, there appears to be no mention of endianness for the values the bootloader gives to the OS image. If we were to take the existing definitions of u16, u32, u64 seriously, the values the bootloader gives to the OS image would be in little endian, even if the OS image with the MB2 header is big endian. That appears to be somewhere between weird and wrong. If weird, it should be mentioned explicitly, and if wrong, it should be corrected. AFAICT, the u16, u32, u64 definitions should be corrected to state that those values are in native endianness (maybe unless specifically stated otherwise). I have to admit I have not checked whether the grub code actually stores values for the OS image in little endian regardless of native endianness. That would surprise me very much, though. Uli _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel