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 <kakar...@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 <mikeb...@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 >> <kakar...@kakaroto.homelinux.net> wrote: >>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <cont...@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. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
