Commit Graph

7 Commits

Author SHA1 Message Date
Stefan Kalkowski
07c8d1652e hw_arndale: setup ARM hypervisor mode
To enable support of hardware virtualization for ARM on the Arndale board,
the cpu needs to be prepared to enter the non-secure mode, as long as it does
not already run in it. Therefore, especially the interrupt controller and
some TrustZone specific system registers need to be prepared. Moreover,
the exception vector for the hypervisor needs to be set up properly, before
booting normally in the supervisor mode of the non-secure world.

Ref #1405
2015-02-27 11:48:05 +01:00
Stefan Kalkowski
a40932a324 hw: refactor irq controllers
* 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
2015-02-27 11:43:56 +01:00
Stefan Kalkowski
a3abf74d1e hw: remove code duplication related to Exynos5 SoC
Fixes #1396
2015-02-16 13:40:36 +01:00
Martin Stein
09e6c3457f hw_arndale: consider timer resets
On Arndale, the kernel timer resets to the initial value of the last
count-down and continues as soon as it reaches zero. We must check this
via the interrupt status when we read out the timer value and in case
return 0 instead of the real value.

fix #1299
2014-11-28 12:02:37 +01:00
Martin Stein
b8ba3a7a22 hw: rename Kernel::Processor Kernel::Cpu
Kernel::Processor was a confusing remnant from the old scheme where we had a
Processor_driver (now Genode::Cpu) and a Processor (now Kernel::Cpu).
This commit also updates the in-code documentation and the variable and
function naming accordingly.

fix #1274
2014-11-28 12:02:35 +01:00
Martin Stein
8dad54c914 hw: fix scheduler timing on prio preemption
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
2014-11-14 12:00:45 +01:00
Martin Stein
a5cf09fa6e hw: re-organize file structure
fix #1197
2014-08-15 10:19:48 +02:00