The driver for the Freescale eSDHCv2 doesn't support the highest
available bus frequency by now and also the bus width may be set to a
higher value but that needs further checks on the capabilities of the
inserted card.
The commits provide a benchmark as it exists for the OMAP4 SDHC driver.
Fix#1458
* Introduce hw-specific crt0 for core that calls e.g.: init_main_thread
* re-map core's main thread UTCB to fit the right context area location
* switch core's main thread's stack to fit the right context area location
Fix#1440
Drivers like SD-Card, platform, AHCI, and framebuffer are specified as Exynos5
compliant. But they are at least not compliant with Odroid-XU although this is
Exynos5. Thus, prevent tests that rely on such drivers when building for
hw_odoid_xu. Furthermore, make previous Arndale regulator/consts.h,
uart_defs.h, and some Board_base enums available to all Exynos5 builds to
enable at least building the drivers.
Fixes#1419
The USB Armory is almost the same as the i.MX53-QSB but it uses only
one of the two RAM banks available in i.MX53. Furthermore we use the USB
Armory only with Trustzone enabled.
Ref #1422
* enables world-switch using ARM virtualization extensions
* split TrustZone and virtualization extensions hardly from platforms,
where it is not used
* extend 'Vm_session' interface to enable configuration of guest-physical memory
* introduce VM destruction syscall
* add virtual machine monitor for hw_arndale that emulates a simplified version
of ARM's Versatile Express Cortex A15 board for a Linux guest OS
Fixes#1405
To enable the usage of virtualization extension related instructions
there is the need to enable the '-mcpu=cortex_a15' compiler flag on
those cpus. To not conflict with other compiler flags (Ref #810) we've
to disable the '-march=arm_v7a' flag.
Ref #1405
* name irq controller memory mapped I/O regions consistently
in board descriptions
* move irq controller and timer memory mapped I/O region descriptions
from cpu class to board class
* eliminate artificial distinction between flavors of ARM's GIC
* factor cpu local initialization out of ARM's GIC interface description,
which is needed if the GIC is initialized differently e.g. for TrustZone
Ref #1405
This patch changes the Shared_object::lookup function to use a
reinterpret_cast instead of a static_cast to allow the conversion
from symbol addresses to arbitrary pointers.
The linker scripts use to fill alignment gaps within the text section
with the magic value 0x90909090, which correponds to the opcodes of four
nop instructions on x86. This patch removes this value because it
apparently solves no problem. If, for some reason (e.g., due to a dangling
pointer) a thread executes instructions within alignment paddings, NOP
instructions are not any better than any other instruction. The program
will eventually execute the instructions after the padding, which is
most likely fatal. It would be more reasonable to fill the padding with
the opcode of an illegal instruction so that such an error can be
immediately detected. That said, I cannot remember a single instance,
where the fill value has helped us during debugging.
Even if the mechanism served a purpose on x86, it is still better to
remove it because it does not equally work on the other architectures
where the linker scripts are used. I.e., on ARM, the opcode 0x90909090
is not a NOP instruction.
If newlines are in the string send to the core log service, they don't get
the label properly appended before each output. The messages then look like
they are coming from core.
Fixes#1368
This has to be used during shared object creation and destruction because global
lists are manipulated. We cannot use the 'Elf_object::lock' here because there
may be jump-slot relocations during object initialization.
Fixes#1350
When building Genode for VEA9X4 as micro-hypervisor protected by the ARM
TrustZone hardware we ran into limitations regarding our basic daily
testing routines. The most significant is that, when speaking about RAM
partitioning, the only available options are to configure the whole SRAM
to be secure and the whole DDR-RAM to be non-secure or vice versa. The
SRAM however provides only 32 MB which isn't enough for both a
representative non-secure guest OS or a secure Genode that is still
capable of passing our basic tests. This initiated our decision to
remove the VEA9X4 TrustZone-support.
Fixes#1351
This wasn't necessary before because we built an l4 library for
Pistachio and linked it against each application. With the new linker,
we compile the required files from within Genode and create a syscall
library that is only linked to ldso. If a program uses system calls
directly, for example, DDE kit's spinlock implementation, the required
symbols must be made globally accessible.
Fixes#1306
On the Versatile Express Cortex A9x4 platform the first memory region
0x0 - 0x4000000 is a hardware remapped memory area, containing flash
and DDR RAM copies and thus should not be added in addition to all
DDR RAM regions and the SRAM region.
In the init configuration one can configure the donation of CPU time via
'resource' tags that have the attribute 'name' set to "CPU" and the
attribute 'quantum' set to the percentage of CPU quota that init shall
donate. The pattern is the same as when donating RAM quota.
! <start name="test">
! <resource name="CPU" quantum="75"/>
! </start>
This would cause init to try donating 75% of its CPU quota to the child
"test". Init and core do not preserve CPU quota for their own
requirements by default as it is done with RAM quota.
The CPU quota that a process owns can be applied through the thread
constructor. The constructor has been enhanced by an argument that
indicates the percentage of the programs CPU quota that shall be granted
to the new thread. So 'Thread(33, "test")' would cause the backing CPU
session to try to grant 33% of the programs CPU quota to the thread
"test". By now, the CPU quota of a thread can't be altered after
construction. Constructing a thread with CPU quota 0 doesn't mean the
thread gets never scheduled but that the thread has no guaranty to receive
CPU time. Such threads have to live with excess CPU time.
Threads that already existed in the official repositories of Genode were
adapted in the way that they receive a quota of 0.
This commit also provides a run test 'cpu_quota' in base-hw (the only
kernel that applies the CPU-quota scheme currently). The test basically
runs three threads with different physical CPU quota. The threads simply
count for 30 seconds each and the test then checks wether the counter
values relate to the CPU-quota distribution.
fix#1275
Do not support the global construction from of objects from within a global
constructor of another object. This can happen if, for example, dlopen is called
from a global constructor. The construction will be post-boned until the current
constructor has finished.
The memory barrier prevents the compiler from changing the program order
of memory accesses in such a way that accesses to the guarded resource
get outside the guarded stage. As cmpxchg() defines the start of the
guarded stage it also represents an effective memory barrier.
On x86, the architecture ensures to not reorder writes with older reads,
writes to memory with other writes (except in cases that are not
relevant for our locks), or read/write instructions with I/O
instructions, locked instructions, and serializing instructions.
However on ARM, the architectural memory model allows not only that
memory accesses take local effect in another order as their program
order but also that different observers (components that can access
memory like data-busses, TLBs and branch predictors) observe these
effects each in another order. Thus, a correct program order isn't
sufficient for a correct observation order. An additional architectural
preservation of the memory barrier is needed to achieve this.
Fixes#692
Previously, the timer was used to remember the state of the time slices.
This was sufficient before priorities entered the scene as a thread always
received a fresh time slice when he was scheduled away. However, with
priorities this isn't always the case. A thread can be preempted by another
thread due to a higher priority. In this case the low-priority thread must
remember how much time he has consumed from its current time slice because
the timer gets re-programmed. Otherwise, if we have high-priority threads
that block and unblock with high frequency, the head of the next lower
priority would start with a fresh time slice all the time and is never
superseded.
fix#1287
Martin Stein
Alexander Boettcher
Sebastian Sumpf
Norman Feske
Stefan Kalkowski
Josef Söntgen
Christian Helmuth