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=multiboo...
which give a texi file that I changed to txt with: $ makeinfo --plaintext --force multiboot.texi > multiboot.txt
Hello Paul,
On Wed, Sep 21, 2016 at 08:12:38PM -0400, Paul Dufresne wrote:
I think I have a problem with Nova multiboot specification.
[...]
Sorry but I currently have no time to read your details about the Multiboot spec. Therefore, I'd like to ask you for a short summary of the issue you experience.
Greets