zir_blazer

I had the exact opposite impression, there are a lot of user contributions working on old platforms, and even specific platform communities. For example, you have 15h.org which is a community dedicated to AMD Bulldozer / Piledriver generation, and they managed to fix a few things that were left broken in Coreboot. I also saw an influx of users working in Sandy Bridge / Ivy Bridge / Haswell era Intel platforms with an occasional Skylake. The problem is, precisely, that most of the user contributions are for old platforms that nobody that does NOT currently owns those will want to touch if you're purchasing new. I would have been very enthusiastic about that work if it was done about 10 years ago or so, nowadays they seem to be hobby projects that don't advance anything forward.

There do exists individual users that work on newer stuff, after the MSI Z690-A / Z790-P there were 2 people that did ports for H610 since at that point the platform was supported and they only had to port the Motherboard. However, they are rather rare, since the kind of user that Coreboot seems to attract are from the privacy and security anti-ME/PSP crowd that don't even want to use newer platforms, which is the exact opposite of my view.

A lot of the work companies does may be just for their internal systems or reference platform and these may not get to the hands of end users, ever. I still recall Phoronix articles covering Coreboot releases always taking a jab at the new supported Motherboards until the MSI Z690-A DDR4 port from 2022.

No idea on the AXI Bus you're talking about, so can't make comparisons.

MMIO (Memory Mapped I/O) is essentially memory (Whenever RAM or ROM) from OTHER devices that is directly visible on the CPU Address Space. My understanding is that from the CPU side, MMIO is mostly transparent (Except for the massive increase in latency) because it gets used like if it was interacting with its own workspace with regular instructions like MOV.

What PCIe ReBAR changes is that before, you could only see a 256 MiB window onto the GPU VRAM, so there was an added overhead since the GPU may need to relocate things from inside that window somewhere else on its total VRAM (So yes, it may be interpreted as if what you see from the CPU side is just some kind of exchange buffer). I believe the best way to describe how it operates is comparing it to EMS (Expanded Memory) from the DOS days since it also worked with a similar, if not the same idea. You could only see a portion of the total memory from what was installed on the EMS card (A 128 KiB window located on the upper part of the 1 MiB address space from the 8086 CPU), so you had to switch which Page (Region) of the memory was visible, adding a lot of overhead and most likely requiring an additional buffer in main RAM to move data from one Page to another. However, since I have no knowledge if the GPUs really work like that I can't confirm. I never knew whenever the 256 MiB is "fixed" (You always see the same Region) or if you can decide which section of the VRAM to make visible.

These kind of BIOS modding shenannigans is why I got interesed in Coreboot, so that enhancing a Firmware capabilities becomes possible without touching propietary tools/code.

Other similar mods included adding NVMe Boot capabilities to older Firmwares that didn't supported them so that you could boot from modern NVMe drives if you used some kind of adapter (As none of those Motherboards have M.2 Slots, but you can use them with a PCIe-to-M.2 adapter card). Also adding required stuff to get certain CPUs booting in Motherboard that were never officially supported (Depending on generation, could be as simple as adding new CPU Microcode).

Since about 5 or 6 years ago, PCIe Video Cards advertise a capability known as Resizeable BAR. PCI Devices like GPUs require some memory to use for PCI MMIO, which is directly visible on the CPU Address Space. As a side note, this Address Space is shared with RAM, and anyone that was around when having 4 GiB RAM with a 32 Bit OS was common (Earlier than 2010 or so) knows that you only saw about 3.25 GiB RAM or so because of sharing the Address Space with PCI MMIO, and those fortunate enough to have used SLI usually saw even less than that, like 2.87 GiB RAM.

GPUs has been using a 256 MiB PCI MMIO window regardless of how much VRAM they actually have since... nearly forever? At least since PCIe is a thing, since I recall than AGP Aperture Size was seteable in era accurate BIOSes. PCIe 3.0 specification introduced a feature known as Resizeable BAR, where the PCI Device can tell a compatible Firmware how much MMIO it actually wants. GPUs uses that to tell a ReBAR capable UEFI Firmware that it wants more MMIO (Usually as big as the GPU VRAM), or uses legacy 256 MiB otherwise.

> Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle.

I believe that only the first Pentium 3 core, Katmai, did this.

> This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video processing companies had to document that the x87/MMX registers were enabled and context switched for user mode code.

I have some faint memories of hearing somewhere that Long Mode didn't support x87. I wonder if it is related to this early info you mention and it being Microsoft specific.

Currently it should work only with Phoenix based APUs (8700G and 8600G, the non-IGP 8700F and 8400F, and whatever other GE or PRO versions of those). It was already mentioned elsewhere that Phoenix2 8300G and 8500G does NOT work, so expect the doc to be fixed ASAP.