Nova multiboot v.1 flags == 0 ???

Paul Dufresne dufresnep at ...9...
Thu Sep 22 02:12:38 CEST 2016


I think I have a problem with Nova multiboot specification.

In https://github.com/udosteinberg/NOVA/blob/master/src/start.S :

/*
* Multiboot Header
*/
__boot_header: .long 0x1badb002
.long 0x0
.long -0x1badb002

This is multiboot v.1 (current version is 2).

3.1.1 The layout of Multiboot header
------------------------------------

The layout of the Multiboot header must be as follows:

Offset  Type    Field Name     Note
0       u32     magic          required
4       u32     flags          required
8       u32     checksum       required
12      u32     header_addr    if flags[16] is set
16      u32     load_addr      if flags[16] is set
20      u32     load_end_addr  if flags[16] is set
24      u32     bss_end_addr   if flags[16] is set
28      u32     entry_addr     if flags[16] is set
32      u32     mode_type      if flags[2] is set
36      u32     width          if flags[2] is set
40      u32     height         if flags[2] is set
44      u32     depth          if flags[2] is set

...

'magic'
     The field 'magic' is the magic number identifying the header, which
     must be the hexadecimal value '0x1BADB002'.

'flags'
     The field 'flags' specifies features that the OS image requests or
     requires of an boot loader.

The problem is here, flags is 0 so it request nothing from the Boot Loader!

'checksum'
     The field 'checksum' is a 32-bit unsigned value which, when added
     to the other magic fields (i.e.  'magic' and 'flags'), must have a
     32-bit unsigned sum of zero.

So the result table returns have not much information you can trust to be there:
   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 |
             +-------------------+
     88      | framebuffer_addr  |    (present if flags[12] is set)
     96      | framebuffer_pitch |
     100     | framebuffer_width |
     104     | framebuffer_height|
     108     | framebuffer_bpp   |
     109     | framebuffer_type  |
     110-115 | color_info        |

Or is it some code that change the flags and checksum somewhere?

I guess flags[6] would be usefull to get memory map:
   If bit 6 in the '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       | base_addr         |
     8       | length            |
     16      | type              |
             +-------------------+

   where 'size' is the size of the associated structure in bytes, which
can be greater than the minimum of 20 bytes.  'base_addr' is the
starting address.  'length' is the size of the memory region in bytes.
'type' is the variety of address range represented, where a value of 1
indicates available RAM, value of 3 indicates usable memory holding ACPI
information, value of 4 indicates reserved memory which needs to be
preserved on hibernation, value of 5 indicates a memory which is
occupied by defective RAM modules and all other values currently
indicated a reserved area.

Info is from:
http://wiki.osdev.org/Multiboot

More prrecisely External link near the end for:
http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot

which give a texi file that I changed to txt with:
$ makeinfo --plaintext --force multiboot.texi  > multiboot.txt




More information about the users mailing list