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.
The boot modules assembled by the generated boot_modules.s file is
accessed from core using struct Bm_header. Unfortunately the assembler
.long directive is synonym to .int [1] and thus has the same size as the
C++ int type and *not* long. Use the matching assembly type .quad in
boot_modules.s when generating the file for 64-bit platforms such as
x86_64.
[1] - https://sourceware.org/binutils/docs/as/Long.html
This patch contains the initial code needed to build and bootstrap the
base-hw kernel on x86 64-bit platforms. It gets stuck earlier
because the binary contains 64-bit instructions, but it is started in
32-bit mode. The initial setup of page tables and switch to long mode is
still missing from the crt0 code.
On each execution the output buffer is overriden when run_genode_until
is executed multiple times. Run scripts, that depend on extracting
information after several execution steps, e.g. noux_net_netcat, will
fail to do so. Therefore, we append the newly captured log output to
the old output buffer.
Issue #1327.
The mkfs.ext2 heuristics select the "small" ext2 usage type, which does
not fit well with GiB-sized pen drives. For example, the block size is
just 1024 bytes compared to 4096 for "default". Therefore, we enforce
the default usage type as this fits our use case of dumping the image to
USB sticks better.
While booting up, some devices send garbage over the serial connection.
This can result in an unexpected EOF event within expect(1). A filter
program may be specified with '--log-serial-filter' to circumvent this
problem. Then, the output of the serial program is piped through
the filter, which may sanitize the character stream.
Fixes#1395.
and move it close to run_genode_until implementation.
Somehow the "match_max -d" gets ignored if it is to far away and some
our run scripts fails because the buffer contains not all information
(seen for affinity.run on a 8 core machine)
Due to commit "run: relax IP power plug recognition + serial EOF",
when piping the serial command through 'tr', some characters might
get buffered, thereby preventing some run scripts to finish correctly.
This commit removes the 'tr' hack. Instead, to circumvent the 'expect'
problem, which kills under special conditions spawned childs used to
obtain serial line content, whenever EOF of the serial command is
recognized during the boot phase, the child process gets re-spawned.
* To communicate with IP power plug devices from Koukaam, to remote
control power supply of test boards, don't parse minor versions, but
support different IP power plugs
* TCL's expect may report an EOF when reading from the spawned serial
terminal, especially when using 'socat' to stream serial over TCP/IP,
although the spawned child is still running and delivering content.
This problem is clearly not dependent on the characters send, but
possibly due to strange pipe signals. When piping the serial output
through 'tr' the problem vanishs.
The older SOAP EOI protocol is not supported with AMT version 9+. By default
the wsman tool will be used if installed.
RUN_OPT examples to enforce amtool or wsman:
--target amt --amt-tool wsman
--target amt --amt-tool amttool
Fixes#1251
This provides bootable disk images for x86 platforms via
! RUN_OPT="--target disk"
The resulting disk image contains one ext2 partition with binaries from
the GRUB2 boot loader and the run scenario. The default disk size fits
all binaries, but is configurable via
! --disk-size <size in MiB>
in RUN_OPT.
The feature depends on an grub2-head.img, which is part of the commit,
but may also be generated by executing tool/create_grub2. The script
generates a disk image prepared for one partition, which contains files
for GRUB2. All image preparation steps that need superuser privileges
are conducted by this script.
The final step of writing the entire image to a disk must be executed
later by
sudo dd if=<image file> of=<device> bs=8M conv=fsync
Fixes#1203.
By adding: "--target jtag \
--jtag-debugger <debugger configuration> \
--jtag-board <board configuration>" to the RUN_OPTs
this commits enables the run-tool to load and execute an ELF image
via JTAG to the target platform.
Fixes#1191
Using 'upvar' instead of 'global' in the 'append_if' and 'lappend_if'
functions makes it possible to use these functions with local variables
of the calling function.
Fixes#1137.
