| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
kernel linker, after the r297686.
Sponsored by: The FreeBSD Foundation
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the boot loader should not skip over these anymore while loading images.
Otherwise the kernel can still panic when it doesn't find the .eh_frame
section belonging to the .rela.eh_frame section.
Unfortunately this will require installing boot loaders from sys/boot
before attempting to boot with a new kernel.
Reviewed by: kib
MFC after: 2 weeks
X-MFC-With: r296419
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set WARNS if not set for EFI boot code and fix the issues highlighted by
setting it.
Most components are set to WARNS level 6 with few being left at lower
levels due to the amount of changes needed to fix at higher levels.
Error types fixed:
* Missing / invalid casts
* Missing inner structs
* Unused vars
* Missing static for internal only funcs
* Missing prototypes
* Alignment changes
* Use of uninitialised vars
* Unknown pragma (intrinsic)
* Missing types etc due to missing includes
* printf formatting types
Reviewed by: emaste (in part)
MFC after: 2 weeks
X-MFC-With: r293268
Sponsored by: Multiplay
Differential Revision: https://reviews.freebsd.org/D4839
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement a subset of the multiboot specification in order to boot Xen
and a FreeBSD Dom0 from the FreeBSD bootloader. This multiboot
implementation is tailored to boot Xen and FreeBSD Dom0, and it will
most surely fail to boot any other multiboot compilant kernel.
In order to detect and boot the Xen microkernel, two new file formats
are added to the bootloader, multiboot and multiboot_obj. Multiboot
support must be tested before regular ELF support, since Xen is a
multiboot kernel that also uses ELF. After a multiboot kernel is
detected, all the other loaded kernels/modules are parsed by the
multiboot_obj format.
The layout of the loaded objects in memory is the following; first the
Xen kernel is loaded as a 32bit ELF into memory (Xen will switch to
long mode by itself), after that the FreeBSD kernel is loaded as a RAW
file (Xen will parse and load it using it's internal ELF loader), and
finally the metadata and the modules are loaded using the native
FreeBSD way. After everything is loaded we jump into Xen's entry point
using a small trampoline. The order of the multiboot modules passed to
Xen is the following, the first module is the RAW FreeBSD kernel, and
the second module is the metadata and the FreeBSD modules.
Since Xen will relocate the memory position of the second
multiboot module (the one that contains the metadata and native
FreeBSD modules), we need to stash the original modulep address inside
of the metadata itself in order to recalculate its position once
booted. This also means the metadata must come before the loaded
modules, so after loading the FreeBSD kernel a portion of memory is
reserved in order to place the metadata before booting.
In order to tell the loader to boot Xen and then the FreeBSD kernel the
following has to be added to the /boot/loader.conf file:
xen_cmdline="dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga"
xen_kernel="/boot/xen"
The first argument contains the command line that will be passed to the Xen
kernel, while the second argument is the path to the Xen kernel itself. This
can also be done manually from the loader command line, by for example
typing the following set of commands:
OK unload
OK load /boot/xen dom0_mem=1024M dom0_max_vcpus=2 dom0pvh=1 console=com1,vga
OK load kernel
OK load zfs
OK load if_tap
OK load ...
OK boot
Sponsored by: Citrix Systems R&D
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D517
For the Forth bits:
Submitted by: Julien Grall <julien.grall AT citrix.com>
|
| |
|
|
|
|
|
|
|
|
| |
associating an optional PNP hint table with this module. In the
future, when these are added, these changes will silently ignore the
new type they would otherwise warn about. It will always be safe to
ignore this data. Get this into the builds today for some future
proofing.
MFC After: 3 days
|
| |
|
|
|
|
|
| |
kld that only contained a sysctl). The kernel linker allows such
modules, so the boot loader should not reject them.
MFC after: 2 weeks
|
| |
|
|
|
|
| |
Some of loader filesystems are very ill equipped to handle seeking
backwards within the file. Namely, tftp requires trasfer to be
restarted from the start of the file every time we go backwards.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. arch_loadaddr - used by platform code to adjust the address at which
the object gets loaded. Implement PC98 using this new interface instead
of using conditional compilation. For ELF objects the ELF header is
passed as the data pointer. For raw files it's the filename. Note that
ELF objects are first considered as raw files.
2. arch_loadseg - used by platform code to keep track of actual segments,
so that (instruction) caches can be flushed or translations can be
created. Both the ELF header as well as the program header are passed
to allow platform code to treat the kernel proper differently from any
additional modules and to have all the relevant details of the loaded
segment (e.g. protection).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current code doesn't check size of elf sections and may perform needless
actions of zero-sized memory allocation and similar.
The bigger issue is that alignment requirement of a zero-sized section
gets effectively applied to the next section if it has smaller alignment
requirement. But other tools, like gdb and consequently kgdb,
completely ignore zero-sized sections and thus may map symbols to
addresses differently.
Zero-sized sections are not typical in general.
Their typical (only, even) cause in FreeBSD modules is inline assembly that
creates custom sections which is found in pcpu.h and vnet.h. Mere inclusion
of one of those header files produces a custom section in elf output.
If there is no actual use for the section in a given module, then the
section remains empty.
Better solution is to avoid creating zero-sized sections altogether,
which is in plans.
Preloaded modules are handled in boot code (load_elf_obj.c), while
dynamically loaded modules are handled by kernel (link_elf_obj.c).
Based on code by: np
MFC after: 3 weeks
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
means:
o Remove Elf64_Quarter,
o Redefine Elf64_Half to be 16-bit,
o Redefine Elf64_Word to be 32-bit,
o Add Elf64_Xword and Elf64_Sxword for 64-bit entities,
o Use Elf_Size in MI code to abstract the difference between
Elf32_Word and Elf64_Word.
o Add Elf_Ssize as the signed counterpart of Elf_Size.
MFC after: 2 weeks
|
|
|
format modules, which are currently only used on the amd64 platform.
This initial implementation just parses enough of the module to
allow it to extract dependencies and load all the bits into the
right place in memory, so the kernel must still do the full relocation
and linking. The details of the loaded sections are passed to the
kernel by supplying a copy of the ELF section header table as module
metadata with the MODINFOMD_SHDR tag.
|
