[coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

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.