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:[email protected]]
Sent: Saturday, March 30, 2013 3:54 AM
To: Racine, Michel
Cc: Stefan Tauner; roxfan; [email protected]; [email protected];
[email protected]
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
_______________________________________________
flashrom mailing list
[email protected]
http://www.flashrom.org/mailman/listinfo/flashrom
