[flashrom] AMD - SP5100 - take SPI ownership (1/2)

Wed Apr 3 00:35:09 CEST 2013

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 at 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 at 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 at assembler.cz]
> Sent: Saturday, March 30, 2013 3:54 AM
> To: Racine, Michel
> Cc: Stefan Tauner; roxfan; frederic.temporelli at bull.net; wmkamp at datakamp.de; flashrom at 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:
>
> 1) 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".
>
> 2) 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
>