This patch removes possible ambiguities with respect to the naming of
kernel-dependent binaries and libraries. It also removes the use of
kernel-specific global side effects from the build system. The reach of
kernel-specific peculiarities has thereby become limited to the actual
users of the respective 'syscall-<kernel>' libraries.
Kernel-specific build artifacts are no longer generated at magic places
within the build directory (like okl4's includes, or the L4 build
directories of L4/Fiasco and Fiasco.OC, or the build directories of
various kernels). Instead, such artifacts have been largely moved to the
libcache. E.g., the former '<build-dir>/l4/' build directory for the L4
build system resides at '<build-dir>/var/libcache/syscall-foc/build/'.
This way, the location is unique to the kernel. Note that various tools
are still generated somewhat arbitrarily under '<build-dir>/tool/' as
there is no proper formalism for building host tools yet.
As the result of this work, it has become possible to use a joint Genode
build directory that is usable with all kernels of a given hardware
platform. E.g., on x86_32, one can now seamlessly switch between linux,
nova, sel4, okl4, fiasco, foc, and pistachio without rebuilding any
components except for core, the kernel, the dynamic linker, and the timer
driver. At the current stage, such a build directory must still be
created manually. A change of the 'create_builddir' tool will follow to
make this feature easily available.
This patch also simplifies various 'run/boot_dir' plugins by removing
the option for an externally hosted kernel. This option remained unused
for many years now.
Issue #2190
This patch decouples the kernel-specific implementation of the dynamic
linker from its kernel-agnostic binary interface. The name of the
kernel-specific dynamic linker binary now corresponds to the kernel,
e.g., 'ld-linux.lib.so' or 'ld-nova.lib.so'. Applications are no longer
linked directly against a concrete instance of the dynamic linker but
against a shallow stub called 'ld.lib.so'. This stub contains nothing
but the symbols provided by the dynamic linker. It thereby represents
the Genode ABI.
At system-integration time, the kernel-specific run/boot_dir back ends
integrate the matching the kernel-specific variant of the dynamic linker
as 'ld.lib.so' into the boot image.
The ABI symbol file for the dynamic linker is located at
'base/lib/symbols/ld'. It contains the joint ABI of all supported
architectures. The new utility 'tool/abi_symbols' eases the creation of
such an ABI symbol file for a given shared library. Its result should be
manually inspected and edited as needed.
The patch removes the 'syscall' library from 'base_libs.mk' to avoid
polluting the kernel-agnostic ABI with kernel-specific interfaces.
Issue #2190
Issue #2195
Instead of solving the problem to deliver ROM modules to core while booting
differently for the several kernels (multi-boot, elfweaver, core re-linking),
this commit unifies the approaches. It always builds core as a library, and
after all binaries are built from a run-script, the run-tool will link an
ELF image out of the core-library and all boot modules. Thereby, core can
access its ROM modules directly.
This approach now works for all kernels except Linux.
With this solution, there is no [build_dir]/bin/core binary available anymore.
For debugging purposes you will find a core binary without boot modules, but
with debug symbols under [run_dir].core.
Fix#2095
* Remove 'test' routine from kernel/core
* Move 'cpu_scheduler' and 'double_list' test to user-land
* Remove 'hw_info' target at all (can be recycled in a topic branch)
The new parameter specifies the additional timeout duration in seconds
which is incurred by AMT log processing, e.g. time spent waiting for the
system to boot.
- disable iommu
- increase root_cnode further for native boot
- support vesa driver on native hardware
- don't mask edge triggered ioapic irqs
- increase various allocators to get noux_tool_chain_* booting natively
Issue #2044
- adjust syscall bindings to support -fPIC
- read serial i/o ports from BIOS data area
- use autoconf.h provided by sel4
-- to avoid ambiguity between sel4 kernel and user libraries
-- remove manual set defines
- remove debug messages
- increase user virtual area to 3GB
Issue #1720
Issue #2044
When running the same kernel in a VM as on the host system and the
kernel boot message from the VM appears on the log output, the run tool
assumes that the host machine has rebooted unexpectedly. With this
commit, an unexpected reboot is assumed only if the kernel boot message
appears at the beginning of a line. On base-hw, we enforce a line feed
at the beginning of the boot message as the SPIKE emulator log starts
with the first message of the kernel lacking a line feed.
Fixes#2041
Enable the ACPI functionality in the platform_drv on hw_x86_64_muen and
provide a simple generated XML report as ROM session in order to make
the PCI configuration space available.
This is a requirement to implement support for MSI on hw_x86_64_muen.
The script takes the following RUN_OPT parameters:
--image-muen-external-build Muen system is built automatically or externally
--image-muen-system Muen system policy
--image-muen-components Muen system components
--image-muen-hardware Muen hardware platform
--image-muen-gnat-path Path to GNAT toolchain
--image-muen-spark-path Path to SPARK toolchain
Causes trouble if a gz image is loaded via grub and later used as initrd for a
Linux VM (e.g. with Seoul VMM)
Discovered during Turmvilla scenario #1552 and issue #1733.
This makes use of the iPXE sanboot command [1] which downloads and
boots an ISO image directly via HTTP. Therefore, your RUN_OPT needs
both
--include image/iso and
--include load/ipxe
NOTE: The webserver serving the ISO image must support ranged requests,
see [2].
[1] - http://ipxe.org/cmd/sanboot
[2] - http://forum.ipxe.org/showthread.php?tid=7295&pid=10482#pid10482
iPXE is an open source network boot firmware which supports booting from
a web server via HTTP [1].
The following two parameters can be used to specify the iPXE/HTTP setup:
--load-ipxe-base-dir
This parameter specifies the base directory of the HTTP server from
which the target machine downloads the files.
--load-ipxe-boot-dir
The directory relative to iPXE base dir which contains the iPXE
chainload configuration and all necessary files.
The target machine is expected to request the following iPXE
configuration via HTTP:
http://${HOST_URL}/${ipxe-boot-dir}/boot.cfg
This can be achieved by building iPXE with the following embedded
script:
#!ipxe
dhcp
chain http://${HOST_URL}/${ipxe-boot-dir}/boot.cfg
See also [2] for additional information.
[1] - http://ipxe.org/
[2] - http://ipxe.org/howto/chainloading#breaking_the_loop_with_an_embedded_scriptFixes#1708
Instead of holding SPEC-variable dependent files and directories inline
within the repository structure, move them into 'spec' subdirectories
at the corresponding levels, e.g.:
repos/base/include/spec
repos/base/mk/spec
repos/base/lib/mk/spec
repos/base/src/core/spec
...
Moreover, this commit removes the 'platform' directories. That term was
used in an overloaded sense. All SPEC-relative 'platform' directories are
now named 'spec'. Other files, like for instance those related to the
kernel/architecture specific startup library, where moved from 'platform'
directories to explicit, more meaningful places like e.g.: 'src/lib/startup'.
Fix#1673
The plugin works just like the netio plugin and uses the following
parameters
--power-off-energenie-host network address of device
--power-off-energenie-password password for device
--power-off-energenie-port target port of device
The run plugin is not generic and works for NETIO4/NETIO230 powerplugs
only. Further, this opens the path for other vendor-specific powerplug
plugins.
Note, the plugin parameter for the addressed powerplug was renamed to
--power-on-netio-host resp.
--power-off-netio-host
If a user has e.g. /tftpboot/x86 as directory and configures
base_dir=/tftboot and offset_dir=/x86, this leads to bad behavior
as the load module creates a symlink
/tftpboot/x86/<builddir> -> <absolut_builddir>
in this case instead of the desired
/tftpboot/x86 -> <absolut_builddir>
Furthermore, the module works on
/tftpboot/x86/config-00-00-00-00-00-00
and
/tftpboot/x86/<builddir>/config-00-00-00-00-00-00
afterwards, which looks bad too. As there is no warning at all, this can
be hard to debug. The commit adds an appropriate check with error message and
exit -1 on an existing directory.
Fixes#1630
The base-hw kernel on x86_64 currently assumes 254 MiB of RAM. The RAM
region is subtracted from the I/O mem allocator and therefore this range
is not available for device I/O.
If qemu is started with -m 128, the region for (emulated) PCI config
space access lies within this region and I/O mem allocation in the
pci_drv will fail. Giving qemu more RAM moves the PCI config space out
of the 254 MiB region, making the run/libc_ffat scenario with acpi work.
