search

jklmnn / base-linux-hw

GNU General Public License v3.0
1 stars 1 forks source link

Enable IO port session. #3

Closed jklmnn closed 6 years ago

jklmnn commented 7 years ago

I created a test scenario to turn on all keyboard LEDs based on this SO post.

If I run the io port operations from the test program the usual segfault appears. But if I run the commands directly in the constructor of the IO Port session I get the following output:

IO Ports: 0x60 x 4 -> 0
on
[    2.720146] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
[    2.749385] atkbd serio0: Spurious ACK on isa0060/serio0. Some program might be trying to access hardware directly.
[init] child "timer" announces service "Timer"
[init -> keyboard_led-test] --- IO_Port keyboard LED test ---

I tried to test this code on real hardware. When calling these methods from Linux, the keyboard LEDs showed up as expected but only on a native PS/2 keyboard. On Genode nothing happened yet. I also noticed that if the kernel command line console=tty0 console=ttyS0,115200 was used, the output of /init and Genode only showed up in the serial output. cc @senier

jklmnn commented 7 years ago

I have tested the forking behaviour of ioperm. On Linux forking the process worked without problems.
On Genode I checked the PID. The inb and outb operations are always executed as PID 1 no matter where they're called from. Calling ioperm from the client didn't change anything but calling it directly inside inb and outb made it work.

senier commented 7 years ago

That makes perfect sense. Obviously everything is proxied through core. If you iopl() in core's main(), does that work?

jklmnn commented 7 years ago

That works indeed! But how we integrate this optimally into Genode? I'm not sure if a Linux syscall in core is what we want.

senier commented 7 years ago

But doesn't core have platform-specific code anyway? What should also work is to set iopl() in your init as it should be passed on to core. However, apparently this does not work - we need to investigate why.

jklmnn commented 6 years ago

As far as I remember this was in a working state so I think we can also close this.

jklmnn commented 6 years ago

To answer the question above: I added iopl to the platform specific code of core (https://github.com/jklmnn/genode/commit/58be28320e2d0472bfda6a732b4c468be5f54378).

senier commented 6 years ago

Yep, that matches my memories ;-) IMHO we should create one "Stress testing" issue where we all the hardware-related session (including IRQ) using realistic workloads. This will also reveal potential open issues with IO_PORT and IO_MEM.