OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Nov 17, 2017 6:49 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Grub memory map
PostPosted: Wed Sep 27, 2017 11:05 am 
Offline

Joined: Tue Apr 11, 2017 3:19 am
Posts: 12
Hello.

I am trying to understand memory map that is given by GRUB.
I do next commands:
1. multiboot (hd0,1)/my_cool_bootloader
2. module (hd0,1)/bzImage
and get next memory map:
Quote:
INFO: main.c: entry addr=0x00000000 INFO: main.c: entry size=0x00000014 INFO: main.c: entry len=0x0009F000 INFO: main.c: entry type=0x00000001
INFO: main.c: entry addr=0x0009F000 INFO: main.c: entry size=0x00000014 INFO: main.c: entry len=0x00001000 INFO: main.c: entry type=0x00000002
INFO: main.c: entry addr=0x000E8000 INFO: main.c: entry size=0x00000014 INFO: main.c: entry len=0x00018000 INFO: main.c: entry type=0x00000002
INFO: main.c: entry addr=0x00100000 INFO: main.c: entry size=0x00000014 INFO: main.c: entry len=0x1FEF0000 INFO: main.c: entry type=0x00000001
INFO: main.c: entry addr=0x1FFF0000 INFO: main.c: entry size=0x00000014 INFO: main.c: entry len=0x00010000 INFO: main.c: entry type=0x00000003
INFO: main.c: entry addr=0xFFFC0000 INFO: main.c: entry size=0x00000014 INFO: main.c: entry len=0x00040000 INFO: main.c: entry type=0x00000002


The address where is loaded bzImage by GRUB is:
Quote:
INFO: main: mods_addr=0x000100B0


The size of bzImage is:
Quote:
ls -l bzImage
6258176 Sep 14 16:59 bzImage


1. I can not see some memory range for bzImage in memory map. Where is it?
2. Address 0x100B0 is from 1st range, but the size of it range is 0x0009F000 that is smaller than size of bzImage and next range has type=2=Reserved, so how it can be written bzImage there?
3. Where am I wrong?
4. How than get "correct" memory map after GRUB?

Thanks for your help.


Top
 Profile  
 
 Post subject: Re: Grub memory map
PostPosted: Wed Sep 27, 2017 7:35 pm 
Offline
Member
Member
User avatar

Joined: Tue Dec 25, 2007 6:03 am
Posts: 702
Location: Perth, Western Australia
The memory map reported by grub is just the map it got from the firmware. It doesn't include entries for the regions of memory that you're currently using (i.e. your kernel image, or the modules loaded for you by grub, or the memory map itself).

_________________
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc


Top
 Profile  
 
 Post subject: Re: Grub memory map
PostPosted: Thu Sep 28, 2017 12:10 am 
Offline

Joined: Tue Apr 11, 2017 3:19 am
Posts: 12
thepowersgang wrote:
The memory map reported by grub is just the map it got from the firmware. It doesn't include entries for the regions of memory that you're currently using (i.e. your kernel image, or the modules loaded for you by grub, or the memory map itself).

Ok. I see.
Than there is 3 question:
1. How get the actual memory map? I need to wite own Ā«mapperĀ» and using it to create actual map with loaded regions by GRUB?
2. How GRUB loaded module to reserved ( type=2) memory? We can see it from memory map and start address of module below.
3. Is module loaded by GRUB is continious in memory or it can be loaded some part in first avaible region and remaining part to another avaiable region? F.e. for memory map that iis shown below first part of module will be loaded from 0x00100b0 to 0x009f000 and remaining part is loaded from 0x100000 because of regions betweeen 0x009f000 and 0x100000 is reserved?


Top
 Profile  
 
 Post subject: Re: Grub memory map
PostPosted: Thu Sep 28, 2017 1:22 am 
Offline
Member
Member

Joined: Thu Jul 05, 2007 8:58 am
Posts: 170
The memory map you listed looks reasonable for a modern computer. As grub module loading is highly unlikely to have bugs that would cause it to load over reserved memory regions (there is quite a number of people here that use/have used it without issues), this suggests that you are parsing the module list given by the multiboot header incorrectly. There is a number of ways this can go wrong, the easiest way to figure out what is for you to compare what your code is doing to the data structures defined in the multiboot documentation provided by grub,


Top
 Profile  
 
 Post subject: Re: Grub memory map
PostPosted: Thu Sep 28, 2017 7:38 am 
Offline

Joined: Tue Apr 11, 2017 3:19 am
Posts: 12
davidv1992 wrote:
The memory map you listed looks reasonable for a modern computer. As grub module loading is highly unlikely to have bugs that would cause it to load over reserved memory regions (there is quite a number of people here that use/have used it without issues), this suggests that you are parsing the module list given by the multiboot header incorrectly. There is a number of ways this can go wrong, the easiest way to figure out what is for you to compare what your code is doing to the data structures defined in the multiboot documentation provided by grub,


Seems that there is hard to do error in this part.
I do in next way:
1. Address of module is got in next way:
Code:
int boot_main(uint32_t mboot_ptr)
{
    multiboot_info_t *mbinfo = (multiboot_info_t *) mboot_ptr;
....
    log_info("main", "mods_addr=%X\n", (multiboot_module_t *) mbinfo->mods_addr);
...

mboot_ptr is got by pushing ebx on the stack in next way:
Code:
MBOOT_PAGE_ALIGN    equ 1<<0    ; Load kernel and modules on a page boundary
MBOOT_MEM_INFO      equ 1<<1    ; Provide your kernel with memory info
MBOOT_HEADER_MAGIC  equ 0x1BADB002 ; Multiboot Magic value
; NOTE: We do not use MBOOT_AOUT_KLUDGE. It means that GRUB does not
; pass us a symbol table.
MBOOT_HEADER_FLAGS  equ MBOOT_PAGE_ALIGN | MBOOT_MEM_INFO
MBOOT_CHECKSUM      equ -(MBOOT_HEADER_MAGIC + MBOOT_HEADER_FLAGS)

[BITS 32]

[GLOBAL mboot]                  ; Make 'mboot' accessible from C.
[EXTERN code]                   ; Start of the '.text' section.
[EXTERN bss]                    ; Start of the .bss section.
[EXTERN end]                    ; End of the last loadable section.

mboot:
    dd  MBOOT_HEADER_MAGIC      ; GRUB will search for this value on each
                                ; 4-byte boundary in your kernel file
    dd  MBOOT_HEADER_FLAGS      ; How GRUB should load your file / settings
    dd  MBOOT_CHECKSUM          ; To ensure that the above values are correct
   
    dd  mboot                   ; Location of this descriptor
    dd  code                    ; Start of kernel '.text' (code) section.
    dd  bss                     ; End of kernel '.data' section.
    dd  end                     ; End of kernel.
    dd  start                   ; Kernel entry point (initial EIP).

[GLOBAL start]
[EXTERN boot_main]

start:
    mov ecx, [ap_init_len]
    mov esi, ap_init
    mov edi, 0x1000
    rep movsb

    ; Load multiboot information:
    push    ebx

    cli
    call boot_main
    jmp $


2. Memory map I got in next way:
Code:
void func(multiboot_info_t *mbinfo)
{
    multiboot_memory_map_t *mmap = (multiboot_memory_map_t *)(mbinfo->mmap_addr);

    while((uint32_t) mmap < mbinfo->mmap_addr + mbinfo->mmap_length) {
        .....
         mmap = (multiboot_memory_map_t*) ( (uint32_t)mmap + mmap->size + sizeof(mmap->size) );
    }
}

Loading in next way:
Code:
multiboot (hd0,1)/my_bootloader
module (hd0,1)/bzImage ...


3. I dont think that multiboot structure is changed but I am using next one:
Code:
struct multiboot_info
{
  /* Multiboot info version number */
  multiboot_uint32_t flags;

  /* Available memory from BIOS */
  multiboot_uint32_t mem_lower;
  multiboot_uint32_t mem_upper;

  /* "root" partition */
  multiboot_uint32_t boot_device;

  /* Kernel command line */
  multiboot_uint32_t cmdline;


  /* Boot-Module list */
  multiboot_uint32_t mods_count;
  multiboot_uint32_t mods_addr;

  union
  {
    multiboot_aout_symbol_table_t aout_sym;
    multiboot_elf_section_header_table_t elf_sec;
  } u;

  /* Memory Mapping buffer */
  multiboot_uint32_t mmap_length;
  multiboot_uint32_t mmap_addr;

  /* Drive Info buffer */
  multiboot_uint32_t drives_length;
  multiboot_uint32_t drives_addr;

  /* ROM configuration table */
  multiboot_uint32_t config_table;

  /* Boot Loader Name */
  multiboot_uint32_t boot_loader_name;

  /* APM table */
  multiboot_uint32_t apm_table;

  /* Video */
  multiboot_uint32_t vbe_control_info;
  multiboot_uint32_t vbe_mode_info;
  multiboot_uint16_t vbe_mode;
  multiboot_uint16_t vbe_interface_seg;
  multiboot_uint16_t vbe_interface_off;
  multiboot_uint16_t vbe_interface_len;
};
typedef struct multiboot_info multiboot_info_t;


Top
 Profile  
 
 Post subject: Re: Grub memory map
PostPosted: Thu Sep 28, 2017 9:57 am 
Offline
Member
Member

Joined: Thu Jul 05, 2007 8:58 am
Posts: 170
Go read the docs again, mod_addr points to a list describing the loaded modules, not the module itself (otherwise it couldn't provide you with multiple modules and things like command lines).


Top
 Profile  
 
 Post subject: Re: Grub memory map
PostPosted: Thu Sep 28, 2017 12:00 pm 
Offline

Joined: Tue Apr 11, 2017 3:19 am
Posts: 12
davidv1992 wrote:
Go read the docs again, mod_addr points to a list describing the loaded modules, not the module itself (otherwise it couldn't provide you with multiple modules and things like command lines).

yeah, was my fault when copying from another my project this code.
it is look correct now:
Code:
module = (multiboot_module_t *) mbinfo->mods_addr;
log_info("main", "module_start=%X\n", module->mod_start);
log_info("main", "module_end=%X\n", module->mod_end);


Output:
Code:
INFO: main: module_start=0x00109000
INFO: main: module_end=0x006B62A0


Thanks.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group