| commit | 57af8075106406e701bc4608a9371c072fb18a7f | [log] [tgz] |
|---|---|---|
| author | Venkatesh Srinivas <venkateshs@google.com> | Wed Dec 12 19:58:53 2018 +0000 |
| committer | CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> | Thu Dec 13 23:12:11 2018 +0000 |
| tree | 22f0d6c0428557ae522bb6541a14867a8ba1db07 | |
| parent | da9af758b7b08381adbbc2bcd0d99de4f1557d78 [diff] |
[bootloader] Retry fixed allocation at 100000h w/ smaller size Gigaboot allocates a fixed region at 10_0000h for the kernel text and rodata/bss. By default it did a 6 MiB allocation, but certain platforms (ex: GCE) were unable to allocate 6 contiguous megabytes. Try a 6 MB allocation; if it fails, retry a 3 MB allocation at the same fixed address. This allows 'fx gce' to work. This should be safe for GCE builds -- 3 MiB runs from 10_0000h to 40_0000h. A build of zircon.elf at head with gcc: 13 .bss 00083510 ffffffff80231000 ffffffff80231000 00131f50 2**12 size ... bss 537872 So BSS runs from 23_1000h - 2b_4510h, which fits within the 3 MB allocation. A clang build of zx: [14] .bss NOBITS ffffffff80251000 001515d0 BSS runs from 25_1000h to 2d_6000h, which also fits fine within the 3 MB alloc. This will no longer be necessary when the kernel is relocatable. Tested: GCE: fx gce create-fuchsia-image instance && fx gce create instance; tested that zx booted to shell. ... Description: efi\boot\bootx64.efi FilePath: efi\boot\bootx64.efi OptionNumber: 0. handle 0 boot: cannot obtain 6291456 bytes for kernel @ 0x100000 KALLOC DONE ... NUC(NUC7i3BNH): Tested that was able to load gigaboot from the EFI shell, kernel fixed allocation succeeds when bootx64.efi is run from EFI (but not from GRUB), tested that zircon.elf / image were loadable. https://screenshot.googleplex.com/gwddVFusYNR (with BSS size) Acer Switch SA5-271: Tested that the updated loader can run from EFI (no EFI shell available), can load zircon.elf / zircon.zbi from a GPT formatted USB key. Change-Id: Ie57e428a17a99951aaec9658830ae5feeca4ba54
Zircon is the core platform that powers the Fuchsia OS. Zircon is composed of a microkernel (source in kernel/...) as well as a small set of userspace services, drivers, and libraries (source in system/...) necessary for the system to boot, talk to hardware, load userspace processes and run them, etc. Fuchsia builds a much larger OS on top of this foundation.
The canonical Zircon Git repository is located at: https://fuchsia.googlesource.com/zircon
A read-only mirror of the code is present at: https://github.com/fuchsia-mirror/zircon
The Zircon Kernel provides syscalls to manage processes, threads, virtual memory, inter-process communication, waiting on object state changes, and locking (via futexes).
Currently there are some temporary syscalls that have been used for early bringup work, which will be going away in the future as the long term syscall API/ABI surface is finalized. The expectation is that there will be about 100 syscalls.
Zircon syscalls are generally non-blocking. The wait_one, wait_many port_wait and thread sleep being the notable exceptions.
This page is a non-comprehensive index of the zircon documentation.