i new linux , learing how linux comes know avaible physical mmeory .i came know there bios system call int 0x15 willl gives e20 memory map.
now find piece of code says defination converting efi memory map e820 memory map.what above mean??
is meant underlaying motherboard firmware efi based since code runs on x86 need convert e820 memory map
if ,does x86 knows e820 memory maps??
what difference between e820 , efi memory maps??
looking forward detailed answer on same.
in both cases, have firmware (bios or efi) responsible detecting memory (and how much) physically plugged in, , operating system needs know information in some format.
is meant underlaying motherboard firmware efi based since code runs on x86 need convert e820 memory map
your confusion here efi , x86 incompatible - aren't. efi firmware has own mechanisms reporting available memory - specifically, can use getmemorymap boot service (before invoke exitbootservices) retrieve memory map firmware. however, critically, memory map in format efi firmware wishes report (efi_memory_descriptor) rather e820. in scenario, not attempt int 15h, since have information need.
i suspect linux kernel use e820 format internal representation of memory on x86 architecture. however, when booting efi, kernel must use efi firmware boot services, chooses convert answer gets e820 format.
this not necessary thing kernel writing do. need know how memory mapped.
it case bootloaders provide information you, example grub. part of multiboot specification allows instruct bootloader must provide information kernel.
for more on this, ever-useful osdev wiki has code samples etc. relevant sections getting memory maps grub here.
further points:
the os needs understand memory mapped several reasons. 1 avoid using physical memory firmware services reside, other communication devices share memory cpu. video buffer common example of this.
secondly, listing memory map in efi not difficult. if haven't discovered it, uefi shell comes firmware has memmap command display memory map. if want implement yourself, quick , dirty way looks this:
efi_status efiapi printmemorymap(efi_system_table* systemtable) { efi_status status = efi_success; uintn memmapsize = sizeof(efi_memory_descriptor)*16; uintn memmapsizeout = memmapsize; uintn memmapkey = 0; uintn memmapdescriptorsize = 0; uint32 memmapdescriptorversion = 0; uintn descriptorcount = 0; uintn = 0; uint8_t* buffer = null; efi_memory_descriptor* memorydescriptorptr = null; { buffer = allocatepool(memmapsize); if ( buffer == null ) break; status = gbs->getmemorymap(&memmapsizeout, (efi_memory_descriptor*)buffer, &memmapkey, &memmapdescriptorsize, &memmapdescriptorversion); print(l"memorymap: status %x\n", status); if ( status != efi_success ) { freepool(buffer); memmapsize += sizeof(efi_memory_descriptor)*16; } } while ( status != efi_success ); if ( buffer != null ) { descriptorcount = memmapsizeout / memmapdescriptorsize; memorydescriptorptr = (efi_memory_descriptor*)buffer; print(l"memorymap: descriptorcount %d\n", descriptorcount); ( = 0; < descriptorcount; i++ ) { memorydescriptorptr = (efi_memory_descriptor*)(buffer + (i*memmapdescriptorsize)); print(l"type: %d phsyicalstart: %lx virtualstart: %lx numberofpages: %d attribute %lx\n", memorydescriptorptr->type, memorydescriptorptr->physicalstart, memorydescriptorptr->virtualstart, memorydescriptorptr->numberofpages, memorydescriptorptr->attribute); } freepool(buffer); } return status; } this reasonably straightforward function. getmemorymap complains bitterly if don't pass in large enough buffer, keep incrementing buffer size until have enough space. loop , print. aware sizeof(efi_memory_descriptor) in fact not difference between structs in output buffer - use returned size calculation shown above, or you'll end larger table have (and address spaces wrong).
it wouldn't massively difficult decide on common format e820 table.
Comments
Post a Comment