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-leave@coreboot.org
[1] https://review.coreboot.org/c/coreboot/+/84710/1/Documentation/internals/dev...
Cheers, Nicholas