2.0 KiB
2.0 KiB
x86 architecture documentation
This section contains documentation about coreboot on x86 architecture.
State of x86_64 support
At the moment there's no single board that supports x86_64 or to be exact
ARCH_RAMSTAGE_X86_64
and ARCH_ROMSTAGE_X86_64
.
In order to add support for x86_64 the following assumptions are made:
- The CPU supports long mode
- All memory returned by malloc must be below 4GiB in physical memory
- All code that is to be run must be below 4GiB in physical memory
- The high dword of pointers is always zero
- The reference implementation is qemu
- The CPU supports 1GiB hugepages
Assuptions for all stages using the reference implementation
- 0-4GiB are identity mapped using 2MiB-pages as WB
- Memory above 4GiB isn't accessible
- page tables reside in memory mapped ROM
- A stage can install new page tables in RAM
Page tables
Page tables are generated by a tool in util/pgtblgen/pgtblgen
. It writes
the page tables to a file which is then included into the CBFS as file called
pagetables
.
To generate the static page tables it must know the physical address where to place the file.
The page tables contains the following structure:
- PML4E pointing to PDPE
- PDPE with $n entries each pointing to PDE
- $n PDEs with 512 entries each
At the moment $n is 4, which results in identity mapping the lower 4 GiB.
Steps to add basic support for x86_64
- Add x86_64 toolchain support - DONE
- Fix compilation errors - DONE
- Fix linker errors - TODO
- Add x86_64 rmodule support - DONE
- Add x86_64 exception handlers - DONE
- Setup page tables for long mode - DONE
- Add assembly code for long mode - DONE
- Add assembly code for postcar stage - TODO
- Add assembly code to return to protected mode - TODO
- Implement reference code for mainboard
emulation/qemu-q35
- TODO
Porting other boards
- Fix compilation errors
- Test how well CAR works with x86_64 and paging
- Improve mode switches
- Test libgfxinit / VGA Option ROMs / FSP