An update on the use of Index I/O to access the SPI flash from software. I figured out the problem with coreboot. We weren't setting the LPC I/O decode range 0x380-0x383 in the LPC PCI config (gen1_dec config in devicetree) which would allow us to talk to the EC using Index I/O on port 0x380. Once I set that, I was able to access Index I/O on my coreboot-ed machine, and that opens up the software-based flashing support.
On Mon, Mar 5, 2018 at 5:34 PM, Youness Alaoui kakaroto@kakaroto.homelinux.net wrote:
Thanks for the advice Mike, but I think you misunderstood the issue. I wasn't talking about the internal memory of the EC, but rather about accessing the EC firmware in SPI flash via an external SPI flasher. The problem is that the SPI flash power rail is the same as the EC chip, so as soon as we power the SPI flash to read it, it will also power the EC chip, which will drive the SPI I/O pins high/low to read its firmware, and since the EC executes the firmware from the flash, that means that the SPI flash will constantly be accessed by the EC and the external flasher can't take control of the I/O. However, it looks like if the EC firmware crashes, it will stop using the flash and will therefore 'release' the I/O pins for the external flasher to use them. If I short MISO with VCC, then the EC will read its firmware as being all 0xFF (which is the same as when I corrupted the flash by erasing its first sector), and that will cause it to crash and release the SPI flash, then we can read it. No need to solder or enable debug mode or anything like that.
Anyways, my true purpose is to use software flashing only, I already have read/write/sector_erase support written but it requires the use of the Index I/O (LPC port 0x380) which I can only access when I flash the machine with the AMI BIOS, but which becomes inaccessible if I only have coreboot. I think it's because AMI will send EC vendor-specific commands via LPC port 62h/66h to configure it and enable the Index I/O access. I've suggested to Paul if we could a reduced firmware that would only log to UART all the accesses to the EC via the LPC port 62/66 (kind of like doing SerialICE for the EC) so we could document the vendor specific commands AMI uses to enable Index I/O. Once we know that, we should be able to read/write to the EC flash using software only.
On Mon, Mar 5, 2018 at 4:04 PM, Mike Banon mikebdp2@gmail.com wrote:
otherwise, the EC prevents us from accessing it
Maybe KB3940Q has the same protection as KB9012 : unless the EC's ground pin has been shortened with motherboard's ground _before_ you have powered a motherboard, you would not have any access; otherwise, EC will go into debug mode and you'll have the full access to its' internal memory. To avoid the soldering, you could look through the instructions described here - http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate ; in short : use a keyboard flex cable to reach EC spi pins as well as its' ground, and a test hook clip to easily get a ground of your motherboard
On Mon, Mar 5, 2018 at 11:00 PM, Youness Alaoui kakaroto@kakaroto.homelinux.net wrote:
On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski contact@paulk.fr wrote:
Hi,
Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
> Sure, you can trust hardware flashing more than software flashing, > but > I really need software flashing. If it was just for me, yeah, I > could > fiddle with it to flash it by hardware for my personal needs, but > when > it's about deploying it to all our customer base, that's another > story, the only solution is software flashing. Obviously, it would > have to work in coreboot, so whatever coreboot is doing wrong (or > AMI > is doing right.. my guess is that it's probably something with the > EC > ACPI code), we'd have to figure that out first in order to get the > read/write support.
Either way, since the EC firmware resides in the SPI flash, it'll be no issue to reflash it both by software and hardware.
On the librems, the EC firmware resides in a separate 64KB SPI flash, it's not shared with the bios, and I haven't found a way to access it.
Is it really only 64 KiB? The chip definitely supports more and it seems a bit small to fit the whole firmware.
Yes, it's a MX25L512. I can send you the firmwares that were on it if you're curious (each machine revision had a different firmware, even though it's the same ene chip in all of them, I don't know enough about the EC to know if that's normal).
The cool thing is that I was able to flash the chip externally, but only when I corrupted the EC firmware (I erased the first page and the laptop crashed before I finished re-programming it by software). I reproduced it twice again, if the EC firmware has crashed, it stops accessing the SPI flash and we can program it with an external flasher, otherwise, the EC prevents us from accessing it. So I think it might be possible to simply short the MOSI/MISO to VCC to cause the firmware to be unreadable, so the EC doesn't boot, then we should be able to read/write from the EC with a pomona clip.
-
Youness Alaoui