On Wed, Sep 02, 2020 at 01:26:00PM +0200, Duss Pirmin wrote:
Hello Stefan
On 01.09.20 13:46, Stefan Kalkowski wrote:
The Attached_mmio abstraction from the `os/include/os/attached_mmio.h` header is no appropriated one for your use-case anymore. Instead you might use the Attached_dataspace abstraction to map the I/O memory into the address space, and put the resulting "local_addr" into the Mmio abstraction explicitly. That is the one you have used before for the register definitions and access.
Many thanks. With this I can initialize an Mmio structure that represents the registers of the device.
But as soon I try to read from a register the driver terminates with the following error: Kernel: MMU-fault not handled ESR=0x92000210 Kernel: init -> i2c2_drv -> ep raised unhandled MMU fault ip=0x1009930 fault-addr=0x20008 type=unknown Writing to a register never returns.
If I change the base address to 0x30B5000 (usdhc2) the read succeeds.
I had the same error before the update without using `platform_drv`, which led me to think, that maybe the clocks for the subsystem aren't initialized. But this is now done by `platform_drv`.
You encounter a synchronous, external data-abort. I don't know which I2C bus you try to access, and what clocks you configured for it in the device configuration of the platform driver. However, can you try to access the same I2C bus within base-hw bootstrap, before the MMU is enabled using physical addresses directly? Maybe, the problem is related to the fact that you access the MMIO region from the userland? I've encountered a similar problem when accessing the GPC (general power controller).
Regards Stefan
Best regards, Pirmin
Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users