[M] Change in coreboot[main]: mainboard/qemu-riscv: Add PCI support

[Alper Nebi Yasak (Code Review)]

Attention is currently required from: Arthur Heymans, Felix Held, Philipp Hug, ron minnich.

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

Change subject: mainboard/qemu-riscv: Add PCI support
......................................................................

Patch Set 2:

(6 comments)

File src/mainboard/emulation/qemu-riscv/include/mainboard/addressmap.h:

https://review.coreboot.org/c/coreboot/+/80378/comment/c3830659_ac7cf9a5 :
PS2, Line 11: #define QEMU_VIRT_PCIE_LOW_MMIO_SIZE 0x40000000
This looks odd compared to others in the `(1ULL * GiB)` form, but it's like that in the QEMU code as well (and not a `#define` there).

File src/mainboard/emulation/qemu-riscv/include/mainboard/addressmap.h:

https://review.coreboot.org/c/coreboot/+/80378/comment/aac41625_8fa09da1 :
PS1, Line 12: #define QEMU_VIRT_PCIE_ECAM_BASE 0x30000000
            : #define QEMU_VIRT_PCIE_ECAM_SIZE 0x3fffffff
> probably not needed, since there are CONFIG_ECAM_MMCONF_BASE_ADDRESS and CONFIG_ECAM_MMCONF_LENGTH. […]

Yeah, these `QEMU_VIRT_PCIE_ECAM_BASE/SIZE` defines are here because I've mimicked how qemu-aarch64 does it (CB:75925). The second one should've been a size of `(256 * MiB)` instead of that address. I removed them and switched to `mmconf_resource()`.

https://review.coreboot.org/c/coreboot/+/80378/comment/e6eec1de_1c5a99d1 :
PS1, Line 15: #define QEMU_VIRT_PCIE_HIGH_MMIO_BASE 0x300000000ULL
> this is correct for rv32, but not for rv64, the base depends on the selected amount of memory. […]

Thanks, looks like I got confused a lot here. The QEMU code also aligns it to `VIRT64_HIGH_PCIE_MMIO_SIZE` just after the calculation you quoted, so I think the (unaligned) value shouldn't work at all for RV64. I updated the patch to calculate the MMIO base in `read_resources()` based on `cbmem_top()`. Hopefully correctly, but having bochs-display work with the wrong values is making me less confident in relying on my testing.

File src/mainboard/emulation/qemu-riscv/mainboard.c:

https://review.coreboot.org/c/coreboot/+/80378/comment/4150fb70_4e611187 :
PS1, Line 47: 	mmio_range(dev, index++, QEMU_VIRT_PCIE_ECAM_BASE, QEMU_VIRT_PCIE_ECAM_SIZE);
> can mmconf_resource be used instead?

That appears to work fine (also on ARM64), at least enough to get bochs-display working with my other patches.

File src/mainboard/emulation/qemu-riscv/mainboard.c:

https://review.coreboot.org/c/coreboot/+/80378/comment/f9ec9490_6b78e6de :
PS2, Line 28: 	res->limit = 0xffff;
I'm having some trouble with this on RV32:

```
[INFO ]  === Resource allocator: DOMAIN: 00000000 - Pass 1 (relative placement) ===
[INFO ]  === Resource allocator: DOMAIN: 00000000 - Pass 2 (allocating resources) ===
[DEBUG]  DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 65535 limit: 800bbdb800000000<NULL>
[INFO ]   DOMAIN: 00000000: Resource ranges:
[INFO ]   * Base: 3b000000000, Size: 10000000000, Tag: 802a5e74
[INFO ]   * Base: fc2000000000, Size: 10000000000, Tag: 40000000
[DEBUG]    PCI: 00:00:03.0 10 *  [0xffff00000000 - 0xffff00000000] limit: 800bd29c00000000
[DEBUG]  DOMAIN: 00000000 io: base: 0 size: 0 align: 0 gran: 65535 limit: 800bd9e000000000<NULL>
[DEBUG]  DOMAIN: 00000000 mem: base: 0 size: 0 align: 0 gran: 2147483647 limit: 800bbdb800000000<NULL>
[DEBUG]  DOMAIN: 00000000 mem: base: 3 size: 0 align: 0 gran: 4294967295 limit: 800bbdb800000003=== Resource allocator: %s - Pass 2 (allocating resources) ===

```

If I set `res->size = 0xffff` as well, I see it changes `base` in the message above instead. I tried putting a few `printk(BIOS_DEBUG, "limit: %llx\n", res->limit)` in `print_domain_res()` but the value is different every time. I can't figure out how, some confusion about the width of a type or argument order, causing a shift? Would be nice if someone could take a deeper look.

But somehow bochs-display works regardless of all that, so I didn't notice this in the first patchset.

https://review.coreboot.org/c/coreboot/+/80378/comment/2f274922_9dbcdccd :
PS2, Line 42: 		res->base = ALIGN_UP((uintptr_t)_dram + (uintptr_t)cbmem_top(),
`cbmem_top()` via probing RAM is limited to detecting up to 16 GiB after CB:36486 even if there's more, where this could result in the wrong value. We could take the amount of RAM from device-tree, but there's PCI details there as well which might be preferable if we could decipher them.