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 TypeField Name Note
0 u32 magic required
4 u32 flags required
8 u32 checksum required
12 u32 header_addrif 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
