sculpt/x86: improve booting on foc and seL4 on native hw

[alex-ab]

Currently both platforms, foc and sel4, fail to boot Sculpt very early on native hardware. One observation is that some of the Io_mem requests are denied. This leads to faulty behavior in core, acpi and the platform driver. Even so the platforms are not officially supported, we should/can improve the robustness on the mentioned components. Additionally some features are missing, e.g. for FOC the rsdp xst/rsdt discovery in core to be bootable on UEFI.

[alex-ab]

On FOC an endless loop triggers on failed io_mem connection creation, which makes the system close to unusable:

[init -> drivers -> pci_decode] 00:15.0 remap MEM BAR0 [00000000d9745000,00000000d9746000) to 0x4017000000
[init -> runtime] child "ram_fs" announces service "File_system"
Error: got no mapping!
Error: map_local_io failed

KERNEL: Warning: nothing mapped: (Mem_space) from [0xffffffff4c76de98/c]: 0000000000000000 size: 0000000000000001 to [0xffffffff4bfafad8/89c]

KERNEL: Warning: nothing mapped: (Mem_space) from [0xffffffff4c76de98/c]: 0000000000000000 size: 0000000000000001 to [0xffffffff4bfafad8/89c]

KERNEL: Warning: nothing mapped: (Mem_space) from [0xffffffff4c76de98/c]: 0000000000000000 size: 0000000000000001 to [0xffffffff4bfafad8/89c]

The last line continues over and over.

[alex-ab]

The successful mapping of io_mem and the error case is not distinguished in FOC clearly, which leads to this undesired behavior. Unfortunately, the return value of 0 for io_mem_session_component::_map_local can't be used to differentiate both cases, since on other base-* platforms no local io_mem mapping in core is actually required, so they will ever return 0. After looking at the code, there is actually Dataspace_attr, which encapsulate well the good and bad/error case, but the code fragments between base and base-* are a bit disconnected. With commit 640fbf3 the Dataspace_attr is now used with io_mem _map_local, so that the ambiguity can be avoided. With 640fbf3 we get a bit further and the platform driver dies:

[init -> drivers -> pci_decode] 00:15.0 remap MEM BAR0 [00000000d9745000,00000000d9746000) to 0x4017000000
[init -> runtime] child "ram_fs" announces service "File_system"
Error: got no mapping!
Error: map_local_io failed [00000000fed90000,00000000fed91000)
Error: Local MMIO mapping failed!
[init -> drivers -> platform] Error: IO_MEM-session creation failed (label="", ram_quota=6K, cap_quota=3, base=0xfed90000, size=0x1000, wc=no)
[init -> drivers -> platform] Error: Uncaught exception of type 'Genode::Service_denied'
[init -> drivers -> platform] Warning: abort called - thread: ep

[alex-ab]

With commits ba32f34 and 51ecf36 the platform driver survives if the io_mem session creation failed regarding iommu on foc and on seL4 if an invalid irq number is specified (e.g. 255).

[chelmuth]

[init -> drivers -> pci_decode] 00:15.0 remap MEM BAR0 [00000000d9745000,00000000d9746000) to 0x4017000000

This looks like we should enhance the fixup conditions in pci_decode as remapping should only be required for uninitialized BARs.

[alex-ab]

Please consider the commits for review

[chelmuth]

I merged all commits but c365199 platform: be robust on IRQ creation failure because it produced merge conflicts. @nfeske if you disagree with changes please let me know.

[alex-ab]

I merged all commits but c365199 platform: be robust on IRQ creation failure because it produced merge conflicts.

@chelmuth: please consider b828f16 which is now based on current staging, which just adds the try/catch.

[alex-ab]

Please consider 01ebff7 to avoid mysterious "LD: not valid elf file" errors during runtime on foc.
Commit 2f251dc helps to shrink a bit the "felt" performance differences.

[nfeske]

Commit 2f251dc helps to shrink a bit the "felt" performance differences.

Very good. Extra thanks for the de-duplication! :)