Hi,
The above-4GB ROM3 MMIO mapping for MMIO access to more than 16MBytes of
SPI flash is only available on the newer AMD SoCs; namely the SoCs that
support 4byte addressing of SPI flashes. I think Picasso didn't support
larger than 16MBytes flash chips and I think from Renoir/Cezanne on SPI
flashes with more than 16MBytes are supported by the hardware.
While you could still send read/write commands manually via the SPI
controller registers to access more than 16MBytes on the older SoCs, you
won't get more than 16MBytes mapped into MMIO space on the SoCs which
don't support more than 16MByte SPI flashes. coreboot uses the MMIO
mapping for read accesses to the flash, since that's faster compared to
accessing it via the SPI controller. Basically in order to MMIO-map more
than 16MBytes, the hardware in the SoC needs to support 4 byte addressing.
Regards,
Felix
On 02/12/2025 16:11, Maximilian Brune wrote:
It is possible to map more than 16MB (although only recently):
https://review.coreboot.org/c/coreboot/+/86584 <https://
review.coreboot.org/c/coreboot/+/86584>
It however requires 64 bit mode enabled in coreboot and I am not sure if
the old SOCs have the ROM3 window.
greetings
Max
Am Di., 2. Dez. 2025 um 14:23 Uhr schrieb Marshall Dawson
<[email protected] <mailto:[email protected]>>:
Years ago, I spent a lot of time with those devices and their SPI
controllers. I'm not aware of any way to map more than the
"traditional" 16MB region (or a different 16MB into the region). In
modern APUs, it tends to rely on cooperation with some PSP
features. I don't believe there's been any attempt to put that into
coreboot for the newer devices. Although Felix would be better
informed, I'm not aware of any customer designs to justify it.
Since the details are considered NDA, PSP manipulation is only
implemented in coreboot on an as-needed basis.
Thanks,
Marshall
On Tue, Dec 2, 2025 at 7:17 AM Mike Banon <[email protected]
<mailto:[email protected]>> wrote:
Good day! I found out it is possible to have 64 MB SPI flash on
DIP-8 boards such as AMD opensource AGESA ones (A88XM-E, AM1I-A,
KGPE-D16, etc.) : simply take a WSON8 chip such
as W25Q512JVEIQ / W25Q512JVEIM and plug it into WSON8-to-DIP8
adapter. It works with flashrom + USB CH341A adapter, although
it takes almost 10 minutes to read. So this setup is physically
possible, although a bit slow.
Some time ago while we've been discussing 64MB QEMU builds,
Felix Held sent me the following detailed reply:
> SPI NOR flash chips with more than 16MByte use 4 byte
addresses while ones with up to 16MBytes use 3 byte addresses.
The SPI flash controllers on older systems often only support
the 3 byte address mode. Also typically only up to 16 MBytes
worth of SPI flash contents can be mapped right below the 4GB
boundary, since the 16MByte below that contain the MMIO of for
example LAPIC and IOAPIC.
> Had a quick look at the BKDG for family 16h model 30h, which
is newer than the chip used on G505S or A88XM-E, and it didn't
have the registers in the SPI controller that I'd expect to be
present if it supports the 4 byte address mode.
However, recently I discovered the following notes on flashrom
mailing list and got a bit confused:
> Large size flash chips support special instructions to use 4-
bytes addresses directly from 3-bytes addressing mode and
without switching to 4-bytes mode.
> The W25Q256FV [a smaller sibling of W25Q512JV] is an example
of a chip which supports: - Native 4BA instructions - Extended
address register: 3BA commands used with a separate register to
hold the most significant address byte. - 4BA address mode: 3BA
commands re-purposed to clock in 4 address bytes instead of 3.
I just built an old 64MB coreboot for KGPE-D16 using almost the
same config as the 2MB one (I used the unofficial SeaBIOS
advanced_bootmenu / multiple_floppies patches from https://
review.coreboot.org/c/coreboot/+/32351 <https://
review.coreboot.org/c/coreboot/+/32351> and filled the free CBFS
space with a lot of KolibriOS floppies that are the hardest to
compress) . But so far I have been waiting for 20 minutes (just
in case it is as slow as CH341A) and still no reaction from this
coreboot board. However, a coreboot of this board (provided by
15h.org <http://15h.org> community) is quite far from coreboot
master and doesn't have its later benefits - so these test
results are a bit inconclusive - and my A88XM-E board that has
almost the latest coreboot master thanks to restore_agesa.sh
script (https://review.coreboot.org/c/coreboot/+/79838 <https://
review.coreboot.org/c/coreboot/+/79838>) is hard to access at
the moment...
Please tell me, is there any modern coreboot's support for
extended address register - as a workaround to use >16MB chips
in 3BA mode with the help of such a register? If not - could it
be added somehow, so that the older SPI controllers capable of
only 3BA still could access the chips which support this helpful
register?
--
Best regards, Mike Banon
Open Source Community Manager of 3mdeb - https://3mdeb.com/
<https://3mdeb.com/>
_______________________________________________
coreboot mailing list -- [email protected]
<mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
coreboot mailing list -- [email protected]
<mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
