mirror of
https://github.com/genodelabs/genode.git
synced 2024-12-30 10:38:55 +00:00
Remove stale documentation
The topics are either covered by the Genode Founations book for by our tools, in particular the integration of the prepare_port mechanism with the run tool.
This commit is contained in:
Norman Feske
Christian Helmuth
parent
cc4e21e7a7
commit
03c3040a1d
@ -1,119 +0,0 @@
|
|||||||
|
|
||||||
=============================================
|
|
||||||
How to use Genode with the Fiasco microkernel
|
|
||||||
=============================================
|
|
||||||
|
|
||||||
|
|
||||||
Norman Feske, Christian Helmuth
|
|
||||||
|
|
||||||
Abstract
|
|
||||||
########
|
|
||||||
|
|
||||||
This documentation describes the process of building and booting the L4/Fiasco
|
|
||||||
version of Genode. It assumes that you are familiar with basic concepts
|
|
||||||
described in the introductory documentation of Genode, namely the "How to start
|
|
||||||
exploring Genode" document.
|
|
||||||
|
|
||||||
|
|
||||||
Preconditions
|
|
||||||
#############
|
|
||||||
|
|
||||||
The Fiasco version of Genode relies on the following components from
|
|
||||||
the source tree of the Fiasco microkernel and the L4 environment (which also
|
|
||||||
need additional tools).
|
|
||||||
|
|
||||||
|
|
||||||
Tools
|
|
||||||
=====
|
|
||||||
|
|
||||||
* Gawk
|
|
||||||
* Bison
|
|
||||||
* Byacc
|
|
||||||
* Python
|
|
||||||
|
|
||||||
|
|
||||||
The Fiasco microkernel
|
|
||||||
======================
|
|
||||||
|
|
||||||
Information about Fiasco are provided at its official website:
|
|
||||||
|
|
||||||
! http://os.inf.tu-dresden.de/fiasco/prev/
|
|
||||||
|
|
||||||
To download the kernel and integrate it with Genode, issue the following
|
|
||||||
command from within the toplevel directory:
|
|
||||||
|
|
||||||
! ./tool/ports/prepare_port fiasco
|
|
||||||
|
|
||||||
For the vesa driver on x86 the x86emu library is required and can be downloaded
|
|
||||||
and prepared by invoking the following command:
|
|
||||||
|
|
||||||
! ./tool/ports/prepare_port x86emu
|
|
||||||
|
|
||||||
This command will download a prepackaged version of the kernel tested
|
|
||||||
with Genode. The build process of the kernel is integrated with Genode's
|
|
||||||
build system. After creating a build directory using 'create_builddir'
|
|
||||||
with 'fiasco_x86' as argument:
|
|
||||||
|
|
||||||
! <genode-dir>/tool/create_builddir fiasco_x86 \
|
|
||||||
! BUILD_DIR=<build-dir>
|
|
||||||
|
|
||||||
From within the new <build-dir>, the kernel can be compiled via
|
|
||||||
|
|
||||||
! make kernel/fiasco
|
|
||||||
|
|
||||||
When using Genode's run mechanism, there is no need to explicitly build the
|
|
||||||
kernel. The run environment (see 'tool/run/boot_dir/fiasco') takes care of it.
|
|
||||||
So you can simple execute run scripts from within the build directory, for
|
|
||||||
example:
|
|
||||||
|
|
||||||
! make run/demo
|
|
||||||
|
|
||||||
|
|
||||||
Behind the scenes
|
|
||||||
=================
|
|
||||||
|
|
||||||
For using the L4/Fiasco kernel, some basic user-level components and libraries
|
|
||||||
are needed. These are subsumed under the name L4 environment an are organized
|
|
||||||
as a number of packages. These packages provide two types of components. There
|
|
||||||
are low-level components for booting up and interfacing to Fiasco and there are
|
|
||||||
higher-level components that compose a basic OS infrastructure. For Genode, we
|
|
||||||
only rely on the low-level packages.
|
|
||||||
|
|
||||||
Previous versions of Genode included all necessary sources from the L4
|
|
||||||
environment in the '3rd/fiasco/snapshot' subdirectory. From release 10.02, the
|
|
||||||
'3rd' directory is no longer part of the release archive and also removed from
|
|
||||||
the subversion repository. Please download the '3rd_fiasco.tar.bz2' archive.
|
|
||||||
The source are organized as follows
|
|
||||||
|
|
||||||
:'tool': contains the tools that are used by the build processes of
|
|
||||||
the L4 environment and Fiasco. For example, the build process of Fiasco
|
|
||||||
relies on the 'preprocess' tool.
|
|
||||||
|
|
||||||
:'kernel': contains the Fiasco microkernel.
|
|
||||||
|
|
||||||
:'l4': contains the L4-environment source tree. The single packages
|
|
||||||
are located at 'l4/pkg'.
|
|
||||||
|
|
||||||
From all the packages of the L4 environment, the following three are of
|
|
||||||
interest for using Genode:
|
|
||||||
|
|
||||||
:'pkg/l4sys': contains the Fiasco system-call bindings.
|
|
||||||
|
|
||||||
The system-call bindings are a set of C-header files that define the
|
|
||||||
application-programming interface for invoking the system calls of
|
|
||||||
Fiasco.
|
|
||||||
|
|
||||||
:'pkg/sigma0':
|
|
||||||
|
|
||||||
Sigma0 is the initial memory manager required to use Fiasco.
|
|
||||||
|
|
||||||
:'pkg/bootstrap':
|
|
||||||
|
|
||||||
Bootstrap is the program that is started by the boot loader.
|
|
||||||
After being started, Bootstrap prepares the bare machine to
|
|
||||||
accommodate Fiasco. On many embedded architectures, bootstrap
|
|
||||||
is used to create a single binary image containing all boot-time
|
|
||||||
OS components.
|
|
||||||
|
|
||||||
Those components are implicitly built by the Genode build system when
|
|
||||||
issuing 'make kernel/fiasco'.
|
|
||||||
@ -1,78 +0,0 @@
|
|||||||
|
|
||||||
===================================
|
|
||||||
Genode on the Fiasco.OC microkernel
|
|
||||||
===================================
|
|
||||||
|
|
||||||
|
|
||||||
Stefan Kalkowski
|
|
||||||
|
|
||||||
|
|
||||||
Fiasco.OC is a microkernel originally developed by the OS group of the
|
|
||||||
TU-Dresden. Nowadays, it is primarily maintained and developed by
|
|
||||||
the company Kernkonzept. It's an object-oriented capability-based system
|
|
||||||
for x86, ARM, PowerPC and MIPS platforms.
|
|
||||||
|
|
||||||
This document provides brief instructions about downloading, building and
|
|
||||||
booting the Fiasco.OC version of Genode.
|
|
||||||
|
|
||||||
|
|
||||||
Prerequisites
|
|
||||||
#############
|
|
||||||
|
|
||||||
You need certain tools to use the Fiasco.OC build system. On Debian/Ubuntu
|
|
||||||
systems you have to install the following packages:
|
|
||||||
|
|
||||||
! apt-get install make gawk g++ binutils pkg-config g++-multilib subversion
|
|
||||||
|
|
||||||
Moreover, you need to download and install the tool-chain used by Genode. Have
|
|
||||||
a look at this page:
|
|
||||||
|
|
||||||
:[http://genode.org/download/tool-chain]:
|
|
||||||
Genode tool-chain
|
|
||||||
|
|
||||||
|
|
||||||
Building the Fiasco.OC version of Genode
|
|
||||||
########################################
|
|
||||||
|
|
||||||
The current version of Genode is available at the public Github repository:
|
|
||||||
|
|
||||||
:http://github.com/genodelabs/genode:
|
|
||||||
Github repository of Genode
|
|
||||||
|
|
||||||
After you've fetched the Genode source tree from the git repository, or
|
|
||||||
downloaded the latest release tar archive, you need the Fiasco.OC source code,
|
|
||||||
its kernel-bindings, additional bootstrap tools etc. To simplify that step,
|
|
||||||
you can use the 'prepare_port' tool:
|
|
||||||
|
|
||||||
! ./tool/ports/prepare_port foc
|
|
||||||
|
|
||||||
This will install all necessary third-party source code in the 'contrib' folder.
|
|
||||||
|
|
||||||
Now, go to a directory where you want the Genode/Fiasco.OC build directory to
|
|
||||||
remain. Use the helper script in the 'tool' directory of the Genode
|
|
||||||
source tree to create the initial build environment. You need to state the
|
|
||||||
build directory you want to create, and the hardware architecture to run
|
|
||||||
Fiasco.OC/Genode on. Choose 'x86_32', 'x86_64', or one of the available ARM
|
|
||||||
boards.
|
|
||||||
|
|
||||||
! <genode-dir>/tool/create_builddir x86_64
|
|
||||||
|
|
||||||
Now, go to the newly created build directory and type make:
|
|
||||||
|
|
||||||
! cd build/x86_64
|
|
||||||
! make KERNEL=foc
|
|
||||||
|
|
||||||
This will build the Fiasco.OC kernel, its bootstrap code, and every Genode component,
|
|
||||||
that runs on top of Fiasco.OC.
|
|
||||||
|
|
||||||
If you just want to give Genode/Fiasco.OC a try, you can call e.g.: the demo run-script
|
|
||||||
instead of building everything:
|
|
||||||
|
|
||||||
! make run/demo KERNEL=foc
|
|
||||||
|
|
||||||
|
|
||||||
Further Information
|
|
||||||
###################
|
|
||||||
|
|
||||||
:[https://l4re.org/fiasco/]:
|
|
||||||
Official website for the Fiasco.OC microkernel.
|
|
||||||
@ -1,195 +0,0 @@
|
|||||||
|
|
||||||
==========================================
|
|
||||||
How to use Genode with the NOVA hypervisor
|
|
||||||
==========================================
|
|
||||||
|
|
||||||
Norman Feske
|
|
||||||
|
|
||||||
|
|
||||||
When we started the development of Genode in 2006 at the OS Group of the TU
|
|
||||||
Dresden, it was originally designated to be the user land of a next-generation
|
|
||||||
and to-be-developed new kernel called NOVA. Because the kernel was not ready at
|
|
||||||
that time, we had to rely on intermediate solutions as kernel platform such as
|
|
||||||
L4/Fiasco and Linux during development. These circumstances led us to the
|
|
||||||
extremely portable design that Genode has today and motivated us to make Genode
|
|
||||||
available on the whole family of L4 microkernels. In December 2009, the day we
|
|
||||||
waited for a long time had come. The first version of NOVA was publicly
|
|
||||||
released:
|
|
||||||
|
|
||||||
:Official website of the NOVA hypervisor:
|
|
||||||
[http://hypervisor.org]
|
|
||||||
|
|
||||||
Besides the novel and modern kernel interface, NOVA has a list of features that
|
|
||||||
sets it apart from most other microkernels, in particular support for
|
|
||||||
virtualization hardware, multi-processor support, and capability-based
|
|
||||||
security.
|
|
||||||
|
|
||||||
|
|
||||||
Why bringing Genode to NOVA?
|
|
||||||
############################
|
|
||||||
|
|
||||||
NOVA is an acronym for NOVA OS Virtualization Architecture. It stands for a
|
|
||||||
radically new approach of combining full x86 virtualization with microkernel
|
|
||||||
design principles. Because NOVA is a microkernelized hypervisor, the term
|
|
||||||
microhypervisor was coined. In its current form, it successfully addresses
|
|
||||||
three main challenges. First, how to consolidate a microkernel system-call API
|
|
||||||
with a hypercall API in such a way that the API remains orthogonal? The answer
|
|
||||||
to this question lies in NOVA's unique IPC interface. Second, how to implement
|
|
||||||
a virtual machine monitor outside the hypervisor without spoiling
|
|
||||||
performance? The Vancouver virtual machine monitor that runs on top NOVA proves
|
|
||||||
that a decomposition at this system level is not only feasible but can yield
|
|
||||||
high performance. Third, being a modern microkernel, NOVA set out to pursue a
|
|
||||||
capability-based security model, which is a challenge on its own.
|
|
||||||
|
|
||||||
Up to now, the NOVA developers were most concerned about optimizing and
|
|
||||||
evaluating NOVA for the execution of virtual machines, not so much about
|
|
||||||
running a fine-grained decomposed multi-server operating system. This is where
|
|
||||||
Genode comes into play. With our port of Genode to NOVA, we contribute the
|
|
||||||
workload to evaluate NOVA's kernel API against this use case. We are happy to
|
|
||||||
report that the results so far are overly positive.
|
|
||||||
|
|
||||||
At this point, we want to thank the main developers of NOVA Udo Steinberg and
|
|
||||||
Bernhard Kauer for making their exceptional work and documentation publicly
|
|
||||||
available, and for being so responsive to our questions. We also greatly
|
|
||||||
enjoyed the technical discussions we had and look forward to the future
|
|
||||||
evolution of NOVA.
|
|
||||||
|
|
||||||
|
|
||||||
How to explore Genode on NOVA?
|
|
||||||
##############################
|
|
||||||
|
|
||||||
To download the NOVA kernel and integrate it with Genode, issue the following
|
|
||||||
command from within toplevel directory:
|
|
||||||
|
|
||||||
! ./tool/ports/prepare_port nova
|
|
||||||
|
|
||||||
For the vesa driver on x86 the x86emu library is required and can be downloaded
|
|
||||||
and prepared by invoking the following command from within the 'libports'
|
|
||||||
directory:
|
|
||||||
|
|
||||||
! ./tool/ports/prepare_port x86emu
|
|
||||||
|
|
||||||
For creating a preconfigured build directory prepared for compiling Genode for
|
|
||||||
NOVA, use the 'create_builddir' tool:
|
|
||||||
|
|
||||||
! <genode-dir>/tool/create_builddir nova_x86_32 BUILD_DIR=<build-dir>
|
|
||||||
|
|
||||||
This tool will create a fresh build directory at the location specified
|
|
||||||
as 'BUILD_DIR'. Provided that you have installed the
|
|
||||||
[http://genode.org/download/tool-chain - Genode tool chain], you can now build
|
|
||||||
the NOVA kernel via
|
|
||||||
|
|
||||||
! make kernel
|
|
||||||
|
|
||||||
For test driving Genode on NOVA directly from the build directory, you can use
|
|
||||||
Genode's run mechanism. For example, the following command builds and executes
|
|
||||||
Genode's graphical demo scenario on Qemu:
|
|
||||||
|
|
||||||
! make run/demo
|
|
||||||
|
|
||||||
|
|
||||||
Challenges
|
|
||||||
##########
|
|
||||||
|
|
||||||
From all currently supported base platforms of Genode, the port to NOVA was
|
|
||||||
the most venturesome effort. It is the first platform with kernel support for
|
|
||||||
capabilities and local names. That means no process except the kernel has
|
|
||||||
global knowledge. This raises a number of questions that seem extremely hard
|
|
||||||
to solve at the first sight. For example: There are no global IDs for threads
|
|
||||||
and other kernel objects. So how to address the destination for an IPC message?
|
|
||||||
Or another example: A thread does not know its own identity per se and there is
|
|
||||||
no system call similar to 'getpid' or 'l4_myself', not even a way to get a
|
|
||||||
pointer to a thread's own user-level thread-control block (UTCB). The UTCB,
|
|
||||||
however, is needed to invoke system calls. So how can a thread obtain its UTCB
|
|
||||||
in order to use system calls? The answers to these questions must be provided by
|
|
||||||
user-level concepts. Fortunately, Genode was designed for a capability kernel
|
|
||||||
right from the beginning so that we already had solutions to most of these
|
|
||||||
questions. In the following, we give a brief summary of the specifics of Genode
|
|
||||||
on NOVA:
|
|
||||||
|
|
||||||
* We maintain our own system-call bindings for NOVA ('base-nova/include/nova/')
|
|
||||||
derived from the NOVA specification. We put the bindings under MIT license
|
|
||||||
to encourage their use outside of Genode.
|
|
||||||
|
|
||||||
* Core runs directly as roottask on the NOVA hypervisor. On startup, core
|
|
||||||
maps the complete I/O port range to itself and implements debug output via
|
|
||||||
the serial/UART I/O ports defined by the BIOS data area.
|
|
||||||
|
|
||||||
* Because NOVA does not allow rootask to have a BSS segment, we need a slightly
|
|
||||||
modified linker script for core (see 'src/core/core.ld').
|
|
||||||
All other Genode programs use Genode's generic linker script.
|
|
||||||
|
|
||||||
* The Genode 'Capability' type consists of a portal selector expressing the
|
|
||||||
destination of a capability invocation.
|
|
||||||
|
|
||||||
* Thread-local data such as the UTCB pointer is provided by the new thread
|
|
||||||
context management introduced with the Genode release 10.02. It enables
|
|
||||||
each thread to determine its thread-local data using the current stack
|
|
||||||
pointer.
|
|
||||||
|
|
||||||
* NOVA provides threads without time called local execution contexts (EC).
|
|
||||||
Local ECs are used as server-side RPC handlers. The processing time
|
|
||||||
needed to perform RPC requests is provided by the client during the RPC call.
|
|
||||||
This way, RPC semantics becomes very similar to function call semantics with
|
|
||||||
regard to the accounting of CPU time. Genode already distinguishes normal
|
|
||||||
threads (with CPU time) and server-side RPC handlers ('Rpc_entrypoint')
|
|
||||||
and, therefore, can fully utilize this elegant mechanism without changing the
|
|
||||||
Genode API.
|
|
||||||
|
|
||||||
* On NOVA, there are no IPC send or IPC receive operations. Hence, this part
|
|
||||||
of Genode's IPC framework cannot be implemented on NOVA. However, the
|
|
||||||
corresponding classes 'Ipc_istream' and 'Ipc_ostream' are never used directly
|
|
||||||
but only as building blocks for the actually used 'Ipc_client' and
|
|
||||||
'Ipc_server' classes. Compared with the other Genode base platforms, Genode's
|
|
||||||
API for synchronous IPC communication maps more directly onto the NOVA
|
|
||||||
system-call interface.
|
|
||||||
|
|
||||||
* The Lock implementation utilizes NOVA's semaphore as a utility to let a
|
|
||||||
thread block in the attempt to get a contended lock. In contrast to the
|
|
||||||
intuitive way of using one kernel semaphore for each user lock, we use only
|
|
||||||
one kernel semaphore per thread and the peer-to-peer wake-up mechanism we
|
|
||||||
introduced in the release 9.08. This has two advantages: First, a lock does
|
|
||||||
not consume a kernel resource, and second, the full semantics of the Genode
|
|
||||||
lock including the 'cancel-blocking' semantics are preserved.
|
|
||||||
|
|
||||||
* On the current version of NOVA, kernel capabilities are delegated using IPC.
|
|
||||||
Genode supports this scheme by being able to marshal 'Capability' objects as
|
|
||||||
RPC message payload. In contrast to all other Genode base platforms where
|
|
||||||
the 'Capability' object is just plain data, the NOVA version must marshal
|
|
||||||
'Capability' objects such that the kernel translates the sender-local name to
|
|
||||||
the receiver-local name. This special treatment is achieved by overloading
|
|
||||||
the marshalling and unmarshalling operators of Genode's RPC framework. The
|
|
||||||
transfer of capabilities is completely transparent at API level and no
|
|
||||||
modification of existing RPC stub code was needed.
|
|
||||||
|
|
||||||
|
|
||||||
Manually booting Genode on NOVA
|
|
||||||
###############################
|
|
||||||
|
|
||||||
NOVA supports multi-boot-compliant boot loaders such as GRUB, Pulsar, or gPXE.
|
|
||||||
For example, a GRUB configuration entry for booting the Genode demo scenario
|
|
||||||
with NOVA looks as follows, whereas 'genode/' is a symbolic link to the
|
|
||||||
'var/run/demo/genode' directory created by invoking the 'demo' run script.
|
|
||||||
|
|
||||||
! title Genode demo scenario
|
|
||||||
! kernel /hypervisor iommu serial
|
|
||||||
! module /genode/core
|
|
||||||
! module /genode/config
|
|
||||||
! module /genode/init
|
|
||||||
! module /genode/timer
|
|
||||||
! module /genode/nitpicker
|
|
||||||
! ...
|
|
||||||
|
|
||||||
Limitations
|
|
||||||
###########
|
|
||||||
|
|
||||||
The current NOVA version of Genode is able to run the complete Genode demo
|
|
||||||
scenario including several device drivers (PIT, PS/2, VESA, PCI) and the GUI.
|
|
||||||
Still the NOVA support is not on par with some of the other platforms.
|
|
||||||
The current limitations are:
|
|
||||||
|
|
||||||
* Threads (ECs) can not be migrated to another CPU once started.
|
|
||||||
|
|
||||||
* For portals used as exception vectors for threads, the thread causing the
|
|
||||||
exception and the handler thread which is bound to the exception portal must
|
|
||||||
be on the same CPU.
|
|
||||||
@ -1,128 +0,0 @@
|
|||||||
|
|
||||||
==============================
|
|
||||||
Genode on the OKL4 microkernel
|
|
||||||
==============================
|
|
||||||
|
|
||||||
|
|
||||||
Stefan Kalkowski
|
|
||||||
|
|
||||||
|
|
||||||
OKl4 is a microkernel developed and distributed by Open Kernel Labs. It is
|
|
||||||
focused on embedded devices. Genode support the OKL4 kernel version 2.1
|
|
||||||
on the x86_32 platform.
|
|
||||||
|
|
||||||
This document provides brief instructions about downloading, building and
|
|
||||||
booting the OKL4 version of Genode.
|
|
||||||
|
|
||||||
|
|
||||||
Prerequisites
|
|
||||||
#############
|
|
||||||
|
|
||||||
You need Python 2.4 to use the OKL4 build system. On Debian/Ubuntu systems
|
|
||||||
simply type:
|
|
||||||
|
|
||||||
! apt-get install python2.4
|
|
||||||
|
|
||||||
Since Ubuntu 10.04, the python2.4 package is no longer part of the official
|
|
||||||
repositories. However, you can manually add the repository via:
|
|
||||||
|
|
||||||
! add-apt-repository ppa:python24-team/python24
|
|
||||||
! apt-get update
|
|
||||||
|
|
||||||
Moreover, you need to download and install the tool-chain used by Genode. Have
|
|
||||||
a look at this page:
|
|
||||||
|
|
||||||
:[http://genode.org/download/tool-chain]:
|
|
||||||
Genode tool-chain
|
|
||||||
|
|
||||||
|
|
||||||
Downloading and building the OKL4 kernel
|
|
||||||
########################################
|
|
||||||
|
|
||||||
To download the OKL4 source code, issue the following command:
|
|
||||||
|
|
||||||
! <genode-dir>/tool/ports/prepare_port okl4
|
|
||||||
|
|
||||||
It will take care of downloading the kernel's source code and applying the
|
|
||||||
patches found at 'base-okl4/patches'.
|
|
||||||
|
|
||||||
For the VESA driver on x86, the x86emu library is required and can be downloaded
|
|
||||||
and prepared by invoking the following command:
|
|
||||||
|
|
||||||
! <genode-dir>/tool/ports/prepare_port x86emu
|
|
||||||
|
|
||||||
To create a build directory for Genode running on OKL4, use the 'create_builddir'
|
|
||||||
tool:
|
|
||||||
|
|
||||||
! <genode-dir>/tool/create_builddir okl4_x86
|
|
||||||
|
|
||||||
Once you have created the build directory at '<genode-dir>/build/okl4_x86',
|
|
||||||
the OKL4 kernel can be built from within the build directory via
|
|
||||||
|
|
||||||
! make kernel
|
|
||||||
|
|
||||||
|
|
||||||
Running the Genode demonstration scenario
|
|
||||||
#########################################
|
|
||||||
|
|
||||||
For a quick test drive of the OKL4 kernel, issue 'make run/demo' from the
|
|
||||||
build directory.
|
|
||||||
|
|
||||||
|
|
||||||
Manually building a boot image
|
|
||||||
##############################
|
|
||||||
|
|
||||||
This section is not needed when using Genode's run-script mechanism. The manual
|
|
||||||
steps described below are automatically executed via the OKL4 run environment
|
|
||||||
as found at 'tool/run/boot_dir/okl4'.
|
|
||||||
|
|
||||||
To practically use the OKL4 kernel and applications running on top of it, Open
|
|
||||||
Kernel Labs provide a tool called 'elfweaver', that is used to merge different
|
|
||||||
application binaries and the kernel itself into one single elf binary that can
|
|
||||||
be executed by your bootloader, e.g. Grub.
|
|
||||||
|
|
||||||
To configure 'elfweaver' to merge the appropriated elf binaries you have to
|
|
||||||
provide an XML file. A good starting point is the 'weaver_x86.xml' file that
|
|
||||||
includes the Genode demo example. Simply copy that file to your Genode build
|
|
||||||
directory and adapt the 'file' attribute of the 'kernel' tag to the absolute
|
|
||||||
path of the OKL4 kernel we build previously.
|
|
||||||
|
|
||||||
! cp <path_to_genode_src>/base-okl4/tool/weaver_x86.xml weaver.xml
|
|
||||||
|
|
||||||
The corresponding line in your weaver.xml should look like this:
|
|
||||||
|
|
||||||
! <kernel file="<path_to_okl4_src>/build/pistachio/bin/kernel" xip="false" >
|
|
||||||
|
|
||||||
Before creating the image, we need to supply a Genode config file as well.
|
|
||||||
For a quick start, you can copy and rename the template provided 'os/config/demo'
|
|
||||||
to '<buil-ddir>/bin/config'. Alternatively, you can assign another file to the
|
|
||||||
'filename' of the 'memsection' declaration for the config file in 'weaver.xml'.
|
|
||||||
Now, we can use 'elfweaver' to create the image. Go to the 'bin' directory in
|
|
||||||
the Genode build directory that contains all the binaries and invoke the
|
|
||||||
script.
|
|
||||||
|
|
||||||
! cd bin
|
|
||||||
! <path_to_okl4_src>/tools/pyelf/elfweaver merge --output=weaver.elf ../weaver.xml
|
|
||||||
! strip weaver.elf
|
|
||||||
|
|
||||||
Note: the given paths to the resulting elf file and the input xml file have to
|
|
||||||
be relative.
|
|
||||||
|
|
||||||
*Bug alert:* Elfweaver triggers an assertion when too many memsections are
|
|
||||||
declared in the 'weaver.xml' file and just outputs the following message
|
|
||||||
! An error occurred:
|
|
||||||
Apparently, elfweaver has a problem with calculating the size of the boot info
|
|
||||||
section. As a quick fix, you can increase the value of 'BOOTINFO_GUESS_OPS' in
|
|
||||||
'<okl4-dir>/tools/pyelf/weaver/bootinfo.py'.
|
|
||||||
|
|
||||||
The resulting elf image can be loaded by GRUB now.
|
|
||||||
|
|
||||||
|
|
||||||
Further Information
|
|
||||||
###################
|
|
||||||
|
|
||||||
:[http://genode.org/documentation/articles/genode-on-okl4]:
|
|
||||||
Article about the porting work of Genode to OKL4, featuring many technical
|
|
||||||
insights that are useful to understand the peculiarities of this base
|
|
||||||
platform.
|
|
||||||
|
|
||||||
@ -1,68 +0,0 @@
|
|||||||
|
|
||||||
=========================================
|
|
||||||
Genode on the L4ka::Pistachio microkernel
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
|
|
||||||
Norman Feske
|
|
||||||
|
|
||||||
|
|
||||||
Pistachio is the reference implementation of the L4 API version x.2 (also
|
|
||||||
referred to a v4). It is developed by the System Architecture Group at the
|
|
||||||
University of Karlsruhe, Germany and the DiSy group at the University of
|
|
||||||
New South Wales, Australia.
|
|
||||||
|
|
||||||
Because this kernel has been the experimentation platform for a lot of exciting
|
|
||||||
research experiments at the L4ka group and it is the basis for the commercial
|
|
||||||
version of L4 developed by OK-Labs, Pistachio is a very interesting base
|
|
||||||
platform for the Genode OS Framework.
|
|
||||||
|
|
||||||
The original port of the Genode OS Framework to Pistachio is the work of Julian
|
|
||||||
Stecklina who wanted to elaborate on the portability of the framework and
|
|
||||||
explore the use of Pistachio's multi-processor capabilities with Genode.
|
|
||||||
|
|
||||||
This document provides brief instructions about downloading, building and
|
|
||||||
booting the Pistachio version of Genode.
|
|
||||||
|
|
||||||
|
|
||||||
Downloading, building, and using L4ka::Pistachio
|
|
||||||
################################################
|
|
||||||
|
|
||||||
Please make sure that you haved downloaded and installed the tool chain,
|
|
||||||
which will be used for both, the L4ka::Pistachio kernel and Genode.
|
|
||||||
|
|
||||||
:[http://genode.org/download/tool-chain]:
|
|
||||||
Preconfigured GNU tool chain for building Genode
|
|
||||||
|
|
||||||
To download the kernel source codes, issue './tool/ports/prepare_port pistachio'.
|
|
||||||
This command will checkout the upstream Git repository of the kernel. Please
|
|
||||||
make sure to have Git installed.
|
|
||||||
|
|
||||||
For the vesa driver on x86 the x86emu library is required and can be downloaded
|
|
||||||
and prepared by invoking the following command:
|
|
||||||
|
|
||||||
! ./tool/ports/prepare_port x86emu
|
|
||||||
|
|
||||||
After having successfully prepared the 'base-pistachio' repository and
|
|
||||||
'libports' you are ready to create a Genode build directory using the
|
|
||||||
'tool/create_builddir':
|
|
||||||
|
|
||||||
! <genode-dir>/tool/create_builddir pistachio_x86 \
|
|
||||||
! BUILD_DIR=<build-dir>
|
|
||||||
|
|
||||||
From within this directory, you can build the kernel by using 'make kernel'.
|
|
||||||
The kernel will be built within '<build-dir>/kernel/pistachio' using the Genode
|
|
||||||
tool chain.
|
|
||||||
|
|
||||||
To build and start Genode directly from within the Genode build directory,
|
|
||||||
issue
|
|
||||||
|
|
||||||
! make run/demo
|
|
||||||
|
|
||||||
This command will execute the steps described in the run script located at
|
|
||||||
'os/run/demo.run'. It will build all Genode components needed for the demo
|
|
||||||
scenario, create a configuration, and start the scenario using Qemu. To inspect
|
|
||||||
the individual steps more closely or learn the steps needed to manually
|
|
||||||
integrate Genode with L4ka::Pistachio, please revisit the Pistachio-specific
|
|
||||||
run environment at 'tool/run/boot_dir/pistachio'.
|
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user