[L] Change in coreboot[main]: arch/io.h: Add port I/O functions to other architectures

[Alper Nebi Yasak (Code Review)]

Attention is currently required from: Arthur Heymans, Jianjun Wang, Julius Werner, Nico Huber, Ron Minnich, Shelley Chen, Yu-Ping Wu.

Alper Nebi Yasak has posted comments on this change by Alper Nebi Yasak. ( https://review.coreboot.org/c/coreboot/+/80372?usp=email )

Change subject: arch/io.h: Add port I/O functions to other architectures
......................................................................

Patch Set 5:

(1 comment)

File src/device/Kconfig:

https://review.coreboot.org/c/coreboot/+/80372/comment/a1f5d3d2_5d8b90a0?usp... :
PS5, Line 532: 	  CPU communicate with peripheral devices over PCI I/O space.
> Sorry, I have to admit I know basically nothing about PCI

Honestly, me too -- all I think I know is thanks to this endeavor. I don't really have solid answers for most of what you are asking.
> So if we do translate this by just adding CONFIG_PCI_IOBASE to everything, where does that IOBASE come from in the hardware?

Looks to me like the translation is handled by the PCIe Controller (a.k.a. Host Bridge? a.k.a. Root Complex?) hardware inside the SoC. I'd assume it's statically set up, and the address space details would be originally listed in each SoC's TRMs, but don't actually know. Maybe drivers for some hardware can set it up dynamically?
> I mostly want to make sure that we can really have this thing in a Kconfig

It's a simplification, in part due to me not fully understanding things. I found the [first article I linked](https://www.thegoodpenguin.co.uk/blog/outb-iowrite-and-friends/) while writing that comment here, which helped a lot, but I'm still deciphering things. Linux seems to be doing some virtual addressing and remapping stuff, and the proper addresses are usually from device-tree, and there's weird boards that don't use MMIO for it but run custom code?

I checked some device-tree files in Linux, and some of them have multiple PCIe sections like that ([`sc8280xp-lenovo-thinkpad-x13s.dts`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...) and [`sc8280xp.dtsi`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch...) for example) so having multiple controllers appears to be possible. Some of these have what looks to me like I/O space ranges, so it's not a single global window, but per controller?

There are a number of files with ranges commented as I/O if you want to check, try `git grep "^\s*ranges = <0x[0-9]1[0-9]*\s+[0x]+\s+[0x]+\s"` in kernel tree.

---

I see there's a device-tree entry for PCIe host bridge in the QEMU ARM64 device-tree. Ideally, we should parse it and use mappings from that, e.g.:

```
pcie@10000000 {
    interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
    interrupt-map = [...];
    #interrupt-cells = <0x01>;
    ranges = <0x1000000 0x00 0x00        0x00 0x3eff0000  0x00 0x10000
              0x2000000 0x00 0x10000000  0x00 0x10000000  0x00 0x2eff0000
              0x3000000 0x80 0x00        0x80 0x00        0x80 0x00>;
    reg = <0x40 0x10000000 0x00 0x10000000>;
    msi-map = <0x00 0x8003 0x00 0x10000>;
    dma-coherent;
    bus-range = <0x00 0xff>;
    linux,pci-domain = <0x00>;
    #size-cells = <0x02>;
    #address-cells = <0x03>;
    device_type = "pci";
    compatible = "pci-host-ecam-generic";
};
```

I've formatted the ranges field to my best understanding. The first three cells are a PCI address, where the very first is [some weird bitfield](https://elinux.org/Device_Tree_Usage#PCI_Address_Translation). Next `0x00 0x3eff0000` is the `CONFIG_PCI_IOBASE` address that I've used and works. Last two `0x00 0x10000` is a 64K size.

Also, other ranges look like `VIRT_PCIE_LOW/HIGH_MMIO_BASE` from mainboard `addressmap.h`, and the `reg` property looks like `CONFIG_ECAM_MMCONF_BASE_ADDRESS`. So probably all of `mainboard.c` `read_resources()` can be replaced by parsing the device-tree. But I probably won't be able to do that much work soon.