Hi Mariusz,
The proposal of calling fast_spi_early_init() in bootblock is working. Other Intel processors are already doing the same way, probably this was missing in Denverton. Also, it works better than using BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES as we don't have the other issue I have pointed out. The patch was submitted for review: https://review.coreboot.org/c/coreboot/+/57033
Thanks, Sumo
On Fri, Jun 11, 2021 at 9:05 AM Szafranski, MariuszX < mariuszx.szafranski@intel.com> wrote:
Hi Sumo,
It should be simple as adding SPI early init to bootblock.
You could try to add call to
fast_spi_early_init(DEFAULT_SPI_BASE);
at the end of bootblock_soc_early_init function from src/soc/intel/denverton_ns/bootblock/bootblock.c
I suspect that after that MRC writing should also work in earlier stage if there will be no address conflict (can`t verify that myself for now☹ )
Please try and let us know.
Mariusz
*From:* Sumo kingsumos@gmail.com *Sent:* Friday, June 11, 2021 12:11 AM *To:* mariusz.szafranski@akumat.pl *Cc:* Coreboot coreboot@coreboot.org *Subject:* [coreboot] Re: denverton_ns: failed to write RW_MRC_CACHE
Hi Mariusz,
Setting BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES solved the problem, thanks!
The only drawback of saving MRC CACHE in later state are the additional resets which are requested by FSP_S (silicon init) - for each additional reset the DDR4 training data is lost and this delays the startup a little bit, but this was also occurring in old coreboot-4.8.1.
Basically those additional resets happens when the CMOS is cleared (when RTC-power-well settings are lost also) so FSP_S resets the system to reconfigure peripherals (ie. SATA, HSIO changes, etc) - and for each reset DDR4 training must be performed again.
For coreboot-4.8.1 in the past I have successfully implemented a change to save MRC CACHE before calling FSP_S to fix this, it worked well but I never used that change in production to not take any risk since I was unsure about side effects. But this improvement can save some time during manufacturing as some resets can't be avoided (here at least 1 reset always happens). It would be good if this can be implemented somehow in coreboot latest...
Hopefully this info could be useful to someone ;)
Kind regards,
Sumo
On Thu, Jun 10, 2021 at 3:41 PM Mariusz Szafrański via coreboot < coreboot@coreboot.org> wrote:
Hi Sumo,
Please try to additionally select MRC_WRITE_NV_LATE or BOOT_DEVICE_SPI_FLASH_NO_EARLY_WRITES to push MRC writing to later state
W dniu 10.06.2021 o 16:58, Sumo pisze:
Hi,
I'm stuck in a problem where coreboot fails to write the MRC cache in the SPI Flash.
Below is the log output:
FMAP: area RW_MRC_CACHE found @ 810000 (65536 bytes) MRC: Checking cached data update for 'RW_MRC_CACHE'. SF: Detected 00 0000 with sector size 0x1000, total 0x1000000 MRC: no data in 'RW_MRC_CACHE' MRC: cache data 'RW_MRC_CACHE' needs update. SPI Transaction Error at Flash Offset 810000 HSFSTS = 0x01046003 REGF metadata allocation failed: 1949 data blocks 4096 total blocks MRC: failed to update 'RW_MRC_CACHE'.
Any clues?
Thanks,
Sumo
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.