Commit Graph

6 Commits

Author SHA1 Message Date
Martin Stein
1336b0a751 mmio: upper-bounds checks
The classes Genode::Mmio, Genode::Register_set, Genode::Attached_mmio, and
Platform::Device::Mmio now receive a template parameter 'size_t SIZE'. In each
type that derives from one of these classes, it is now statically checked that
the range of each Genode::Register::Register- and
Genode::Register_set::Register_array-deriving sub-type is within [0..SIZE).

That said, SIZE is the minimum size of the memory region provided to the above
mentioned Mmio classes in order to avoid page faults or memory corruption when
accessing the registers and register arrays declared inside.

Note, that the range end of a register array is not the end of the last item
but the end of integer access that is used for accessing the last bit in the
last item.

The constructors of Genode::Mmio, Genode::Attached_mmio, and
Platform::Device::Mmio now receive an argument 'Byte_range_ptr range' that is
expected to be the range of the backing memory region. In each type that derives
from on of these classes, it is now dynamically checked that 'range.num_bytes
>= SIZE', thereby implementing the above mention protection against page faults
and memory corruption.

The rest of the commit adapts the code throughout the Genode Labs repositories
regarding the changes. Note that for that code inside Core, the commits mostly
uses a simplified approach by constructing MMIO objects with range
[base..base+SIZE) and not with a mapping- or specification-related range size.
This should be fixed in the future.

Furthermore, there are types that derive from an MMIO class but don't declare
any registers or register arrays (especially with Platform::Device::Mmio). In
this case SIZE is set to 0. This way, the parameters must be actively corrected
by someone who later wants to add registers or register arrays, plus the places
can be easily found by grep'ing for Mmio<0>.

Fix #4081
2024-02-26 08:59:07 +01:00
Stefan Kalkowski
6a7247ab44 platform: remove cache attribute from io_mem call
Instead of allowing the client to set a caching attribute
in the io_mem() call of the device interface, which was
only used to decide in between of the memory  being
write-combined or not, remove it from the API.
Instead use the information delivered by the devices ROM,
whether memory from a PCI BAR is prefetchable or not,
to decide whether it is mapped write-combined or not.

Ref genodelabs/genode#4578
2022-10-12 12:09:34 +02:00
Stefan Kalkowski
281785f6bd platform API: make MMIO dataspace cap accessible
In case of the GPU multiplexer, we need to delegate MMIO memory
to the framebuffer client in form of a managed dataspace. To be
able to attach a given Platform::Device::Mmio object to a region map
we need to access its capability.

Ref genodelabs/genode#4578
2022-10-12 11:59:08 +02:00
Stefan Kalkowski
de7fdd3e1a platform_drv: wait for device's availability
Instead of returning an invalid device capability when a device
is (not yet) available, e.g. a PCI device is requested before the
PCI bus got parsed accordingly, we check the device capability
within the Platform::Connection utilities, and register temporarily
an Io_signal_handler to wait for changes of the devices ROM, and
try the device aquisition again. Thereby, simple drivers so not have
to take the burden to do so.

To enable this feature for all drivers, we always have to export a
devices ROM, but limit the information about physical resources
(I/O memory addresses, IRQ numbers, I/O port ranges) to clients with
'info=yes' in their policy description.

Fix genodelabs/genode#4496
2022-05-25 12:19:32 +02:00
Stefan Kalkowski
57aab46fc3 platform: introduce I/O ports in API
* Introduces Platform::Device::Io_port client utility
* Implements I/O ports as common device resources in platform driver

Fix genodelabs/genode#4436
2022-03-07 16:42:56 +01:00
Stefan Kalkowski
7db602faec os: deprecate platform API for x86, rpi, imx53
* Move platform APIs to "legacy/" subdirectory
* Rename old pc, imx53, and rpi platform_drv
  to "legacy_*_platform_drv"

Fix #4359
2022-01-19 12:38:12 +01:00