Physical memory init uses multiboot info
authorBarret Rhoden <brho@cs.berkeley.edu>
Sun, 16 Jun 2013 00:20:04 +0000 (17:20 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Sat, 22 Jun 2013 17:29:30 +0000 (10:29 -0700)
commite2d26f6c090ae9c3d431b744c92cc4dbef3b4661
tree1da4ced6782aa2e3b73c38a0a28a3d53ba51cf7f
parentdb42f5bfbb78c10016ac1ca1d38a691f7aea61c6
Physical memory init uses multiboot info

The old style of trusting only the BIOS memory detection, would miss out
on pmem above 4GB.  Additionally, we were assuming the area from right
above the kernel til the end of extended memory was free, instead of
checking the mmap ranges.

Now we parse the multiboot info to figure out which memory ranges are
really free.  Additionally, we use the largest range (which might not be
the one the kernel is already sitting in) for our boot allocator.
Systems with obscene amounts of RAM (256GB) will need more RAM than fits
in extended memory (~6GB for the pages array).

Anyway, we try to handle situations whether or not the kernel is in the
boot allocator zone, whether the zone is larger than addressable
physical memory, and a bunch of other things.
18 files changed:
kern/arch/riscv/page_alloc.c
kern/arch/riscv/pmap.c
kern/arch/x86/frontend.c
kern/arch/x86/page_alloc.c
kern/arch/x86/pmap32.c
kern/arch/x86/pmap64.c
kern/arch/x86/ros/mmu32.h
kern/arch/x86/ros/mmu64.h
kern/include/kmalloc.h
kern/include/multiboot.h
kern/include/page_alloc.h
kern/include/pmap.h
kern/include/ros/memlayout.h
kern/src/init.c
kern/src/kmalloc.c
kern/src/multiboot.c
kern/src/page_alloc.c
kern/src/pmap.c