Hi All
Using flashrom (with IMC patch), flash coreboot base build for AMD Persimmon board. Passes verifying flash; but IMC resume failed. Poweroff - doesn't fully power off. Stops with "Power down."; manual poweroff
I guess because coreboot does not provide any IMC firmware here.
Reboot system, and able to ssh into system; no VGA from the board itself. No VGA is expected because I did not add a vBios to the coreboot image.
Trying to flash back the AMI original bios; fails with:
root@debian:~# ./flashrom_imcpatch -p internal -w AMI.rom flashrom v0.9.6.1-r1564 on Linux 2.6.32-5-686 (i686) flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK. coreboot table found at 0xc717d000. Found chipset "AMD SB7x0/SB8x0/SB9x0". Enabling flash write... (Shutting down IMC failed!) FAILED! FATAL ERROR! Error: Programmer initialization failed.
Here I guess the bit which is telling that IMC is active survived reboot.
Power off, unplug board power supply, moving both jumpers (JP12, JP13 on pin 2-3) for 30 seconds to clear CMOS settings. Reboot; Retry flashrom AMI; outputs:
root@debian:~# ./flashrom_imcpatch -p internal -w AMI.rom flashrom v0.9.6.1-r1564 on Linux 2.6.32-5-686 (i686) flashrom is free software, get the source code at http://www.flashrom.org
Calibrating delay loop... OK. coreboot table found at 0xc717d000. Found chipset "AMD SB7x0/SB8x0/SB9x0". Enabling flash write... OK.
This confirms that IMC is "dead" here, there is no MBOX interface no bit which tells if IMC is active.
Found SST flash chip "SST25VF032B" (4096 kB, SPI) at physical address 0xffc00000 . Flash image seems to be a legacy BIOS. Disabling coreboot-related checks. Reading old flash chip contents... done. Erasing and writing flash chip... ERASE FAILED at 0x00000000! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x00000fff: 0x200 ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00000008! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x00007fff: 0xfff ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00000008! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x0000ffff: 0x1fff ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00000008! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x003fffff: 0x7ffff ERASE FAILED! Reading current flash chip contents... done. ERASE FAILED at 0x00000000! Expected=0xff, Read=0x7f, failed byte count from 0x00000000-0x003fffff: 0x80000 ERASE FAILED!
I admit this is strange. The only explanation is that the IMC tries to run non-existing stuff. So it in fact tries to execute something and there is no way it could tell us that it is active. Not sure what to do here. I know there is some soft strap override but I dont know if current strap can be read to detect if IMC is enabled but actually not doing anything.
Maybe this is getChipSysMode() in CIMX.
Power on Nothing
Yes because it erased most of the flash ;)
So... This is going to be complicated. Can you please send me in private both images? Or paste URL where i can get ami bios image.
I will check if IMC firmware is there or not (I guess none in coreboot). What we could possibly do is to re-add a firmware to coreboot image. But we would have to override the straps and activate the imc. There is also BuildParameters.ImcEnableOverWrite in SB800 CIMX.
What is your goal here anyway? To have smooth transition to coreboot? Or you just reported this issue?
I guess we need to implement some safety checks that if IMC strap is always enabled then IMC firmware must exist and ideally be same as in flash.
But first we need to know what CIMX is doing.
if 1) EC is disabled and it is re-enabled by soft strap
This seems not to be the case, because
if (validateImcFirmware (pConfig)) { softwareToggleImcStrapping (pConfig);
It will enable the IMC only if valid firmware is found. And for CIMX800 we are not doing this, only hudson has AMD firmware.
2) if it is enabled by some hardware strap
This could be detected most likely by getChipSysMode() in this case we need to disallow write of firmware which has no IMC code. Here are couple of problems, what to do if firmware is there, but different for example... Or with coreboot may happen it is on different location. Franly I don't know how to deal with that because for this I would need detailed knowledge of the firmware itself. I only disassembled that and I can see it just spins in memory when 0xb4 is invoked and waits for 0xb5 (and I have seen sometimes for 0xb6)
And this gets worse because Hudson has USB firmware and Gigabit ethernet firmware. Which are are same PITA.
Thanks Rudolf
Cheers, Michel.
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Saturday, March 30, 2013 3:54 AM To: Racine, Michel Cc: Stefan Tauner; roxfan; frederic.temporelli@bull.net; wmkamp@datakamp.de; flashrom@flashrom.org Subject: Re: [flashrom] AMD - SP5100 - take SPI ownership (1/2)
Hi,
Found chipset "AMD SB7x0/SB8x0/SB9x0" with PCI ID 1002:439d. Enabling flash write... EC SIO is at 0x16e EC MBOX is at 0x3e (Shutting down IMC) SPI base address is at 0xfec10000
This means that firmware correctly responded to the command and most likely moved itself to internal RAM.
Verifying flash... VERIFIED.
EC SIO is at 0x16e EC MBOX is at 0x3e (IMC resume failed!)
This means that firmware was not able to continue at the end?
I have a couple of questions:
- did you perform full power cycle (even unplugging the PSU)?
I suspect that the IMC may run even if main cpu is off. I also suspect it fully initializes only if performing this "cold boot".
- what was the update? It was from original BIOS to coreboot? Does coreboot have a embedded IMC image? Does the IMC image start at the same location?
What we could additionally check is if the IMC firmware location does not match in source and dest image, bail out. Or if the base addr has been changed.
Thanks Rudolf