[coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

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 at 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 at 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 at kakaroto.homelinux.net> wrote:
>>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski <contact at 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.