On 2025-01-24 08:31, Keith Hui wrote:
Hello all,
Doing some work with (Bill's) Asus P8Z77-V board and running into some
issues and limits.
See it unfold at https://review.coreboot.org/c/coreboot/+/85413
That said, I've run into a few issues and limits trying to bring
feature parity to it. It will also help me with porting coreboot to
two more boards in the family: P8Z77-V LE PLUS and Sabertooth Z77. A
patch has been sent for Sabertooth and I have one on the way maybe
early next month - it needs a cap replaced, maybe more. The other
board is on hand and a patch is being prepared. I'll put in as much as
I can get working before sending it in.
#1. Bill has been testing this patch (thanks!) with PCH soft strap #9
configured to have all lanes as x1. Actual routing is controlled by 3
GPIO lines from the super I/O, and it has card presence lines wired to
the PCH. I got both working, but Bill still couldn't get his card to
work on one of the two x1 slots. I need more fresh eyes to help.
I've taken a look myself and added a comment on CB:85413
#2. Changing flash descriptor from within coreboot.
I've come to a point where I need to be able to change the PCH soft
straps based on user selection. As you can see in 85413, and in
consultation with Nicholas (that convo is also on this list), to make
it fully work I need to be able to change the otherwise read-only soft
strap #9 in the flash descriptor, and it appears Asus is doing it as
well. I know about SPI console - I actually used it during early
attempts of porting my P8Z77-M - but I have not dealt with writing to
the SPI from within coreboot nor have I studied SPI console deep
enough to be able to come up with code of my own.
The SPI console probably wouldn't have all the information relevant for
rewriting the IFD, as it relies on the console region being pre-erased.
At runtime it just appends to the unwritten portion of the console
region using SPI write commands, which just sets erased bits (one) to
zero as appropriate. Glancing through the codebase, it seems like
smmstore is able to erase flash. Refer to drivers/smmstore/store.c.
Based on that it looks like you'd want a region device for the SPI flash
and then call rdev_eraseat() on it, and then rdev_writeat() on it. Just
a note, there is a comment in drivers/spi/flashconsole.c that suggests
doing an erase freezes the SPI controller.
7-series PCH supports hardware sequencing if the SPI flash chip meets
certain requirements. Does it mean I can just write() to the memory
area mapped for SPI flash, and it fires the SPI commands for me? Will
it do sector erase on my behalf and preserve what's not being
overwritten?
Hardware sequencing doesn't generate any SPI commands based on MMIO
accesses. Instead, it provides an abstracted interface through the HSFS,
HSFC, FADDR, and FDATA[N] registers where software essentially just
programs the type of operation to execute (read, write, or erase), a
linear address into the flash space, and data. You still need to
manually take care of preserving existing data. Given that the smallest
erase block is 4K, the size of the descriptor, you will need to preserve
the entire IFD contents, update the data, erase the IFD, and write the
modified data back. I suppose the exception would be if you only needed
to change a 1 to a 0, in which you could just send a write without an
erase, but generally you'll need to do more as I described.
Nicholas mentioned some Haswell boards also need this done. Would love
to hear some progress there.
No updates on from me regarding that.
#3. Dynamic device tree?
There will be times when the devicetree needs to change based on user
selection. Not necessarily nvram options, but also choices made in
'make menuconfig'. In my efforts they are respectively
enabling/disabling PCIe root ports 2-4 (based on whether port 1 is set
for x4) and enabling the SIO serial port on Sabertooth if the user
enables the "hacked serial port" in Kconfig. Devicetrees are supposed
to be static, I get this. Where are the runtime hooks where code can
go in and say "nope, this device is off"?
I'm not too familiar with this, but it seems like something with
firmware config could be used for this [1]? It seems like it only has
backends for ChromeEC, files in CBFS, or Vital Product Data (VPD)
though. Refer to lib/fw_config.c and the FW_CONFIG* options in
src/Kconfig. Perhaps a new interface for arbitrary mainboard specific
firmware config backends could be added? Then configs firmware config
values could be defined based on things like GPIOs or Kconfig values.
Many thanks
Keith
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
[1]
https://review.coreboot.org/c/coreboot/+/84710/1/Documentation/internals/devicetree_language.md#1034
Cheers,
Nicholas
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
