Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Paul Kocialkowski]

Hi,

Le vendredi 09 février 2018 à 14:33 -0500, Youness Alaoui a écrit :
> On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon 
> wrote:
> > Thank you very much for telling about EC-1.75 project!
> > http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
> > Maybe some of its' elements could be borrowed for Origami
> > if the hardware is similar? (haven't compared the datasheets)
>
> There will probably be some things in common. I don't know how much
> of
> ec-1.75 is good enough to be reused though, or if it's maintainable,
> etc.. but yes, it could be a good starting point.

There is indeed a lot in common with that code, but the code itself is
not structured and organized at all so reusing the codebase makes very
little sense. I mostly use this code for reference and it has already
proven useful (e.g. for special trickery that has to be implemented
when going to low power mode).
> > @ Youness and Marty :
> >
> > Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug
> > Interface
> > (the protocol used to access the internal memory of KB9012) unless
> > pin
> > 42 is grounded
> > _before_ powering the KB9012 controller ! Maybe its the same with
> > your
> > another KB ?
> > If you ground that pin (not necessarily 42, your KB's pin number
> > could
> > be different)
> > to put your EC into debug mode, maybe then you could successfully
> > read/write it ?
> >
> > Here is the full description of my successful KB9012 hardware
> > flashing setup
> > through the keyboard port using a flex cable with soldered wires:
> > 0.5mm pitch
> > makes it hard to solder directly to keyboard port, and also I like
> > flex cable solution
> > because its much faster to remove/insert a cable than to
> > solder/desolder the wires
> >
> > http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
> >
> > ^^^ Had to unite three grounds ( programmer's, mainboard's and
> > KB9012's 42 pin )
> > to make it work
> >
> > Currently we are actively working on the inclusion of KB9012
> > flashing support
> > to the official flashrom - but its already possible via the
> > unofficial patches.
> > Changes 23258 - 23263 at the https://review.coreboot.org/#/q/projec
> > t:flashrom

Note that the patches have been merged at this point, so ENE EDI
support in flashrom is now ready. I am also wondering about using
libflashrom to write an EDI debugger (since, after all, EDI has access
to the whole external memory).
> > I haven't compared the datasheets of KB9012 and your KB, so I don't
> > know
> > if they are using exactly the same debug interface or it is
> > slightly different
> > (please check if there are differences, maybe you'll have to write
> > some code)
> >
> > I trust hardware flashing more than the software, especially your
> > current AMI BIOS setup
> > which isn't free software. Maybe the direct hardware flashing is
> > also
> > possible for you
>
> 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.
> > Latest status update for Origami-EC firmware:
> > https://www.mail-archive.com/[e-mail]/msg50646.html
>
> Thanks! Good to see the status update on that.

In order to kickstart the development of the Origami-EC firmware, I am
designing evaluation boards for both the KB9012 and the KB3930 that
will expose most of the I/O ports with headers, LEDs, buttons,
connectors, etc. The design is done with KiCAD and will be released
under the GPLv3+ as part of the Origami-EC project. I am also preparing
a debug board to reflash the EC on the G505s from the keyboard
connector.

There is also ongoing work on the emulator and the SerialICE-like
library for relatying and tracing I/O on the device via UART. Also,
note that the emulator can now emulate a virtual console so it's
already possible to build and interract with the firmware!

Cheers,

Paul
> > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> >  wrote:
> > > Hi Marty,
> > >
> > > Unfortunately, the EC firmware on the Librems is not open and we
> > > have
> > > someone working on that aspect, but with everything we have to
> > > handle,
> > > I think it's only being done part time.
> > > We found something similar to you with the private submodule for
> > > the
> > > PS/2 module on the OLPC code.
> > > More specifically :
> > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html
> > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A
> > > 1
> > >
> > > I had opened a ticket a while ago here :
> > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
> > > don't
> > > know the status of that project, maybe you can contact the
> > > developer
> > > (Paul Kocialkowski) and see where he's at with his development of
> > > that
> > > project (which, I need to mention, hasn't been publicly launched
> > > yet,
> > > as far as I know) and he might benefit from your help if you are
> > > interested in doing that.
> > > The last time we spoke he said :
> > > "The OLPC code is nowhere close to usable on any other platform.
> > > Additionally, it is so poorly written that I don't think it is a
> > > suitable codebase for any future development. On the other hand,
> > > my
> > > Origami-EC project (that I will publicly launch soon) should
> > > provide a
> > > flexible codebase to add support for new devices."
> > >
> > > Note that the tracker ticket above is quite outdated, we know how
> > > to
> > > dump the EC (the problem was that it can't be done via hardware
> > > because the EC is on the same power rail as the 64KB flash chip,
> > > so
> > > when we power the flash via hardware, the EC boots and takes
> > > control
> > > of the SPI lines) but for some reason, we could only dump it via
> > > software (using ectool) through the AMI BIOS firmware, with
> > > coreboot,
> > > we only get 0xFF returned, I don't believe we had time to
> > > investigate
> > > the cause for that.
> > >
> > > Sorry for not having any better news for you, but I hope this
> > > helps a
> > > little you at least.
> > >
> > > Good luck,
> > > Youness.
> > >
> > > On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer
> > >  wrote:
> > > > Greetings,
> > > >
> > > > Currently working on a port for the hp g7-2247us laptop, which
> > > > features
> > > > an ene kb3940q ec, which hopefully should be very similar to
> > > > the kb3930
> > > > ec, which has a datasheet available to the public in a few
> > > > places.
> > > >
> > > > Said similar ec is used in some OLPC devices, as well as some
> > > > purism
> > > > devices, and I was hoping someone in the list would have some
> > > > contacts
> > > > with those guys so as to be able to use their ec firmware as a
> > > > bit of a
> > > > reference design, but the OLPC ec firmware repo has a 'private'
> > > > submodule which I cannot access and I simply cannot find a repo
> > > > for the
> > > > purism ec firmware to reference.
> > > >
> > > > Any assistance you could provide on this matter would be
> > > > greatly
> > > > appreciated.
> > > >
> > > > Marty E. Plummer

ENE KB3940Q-A1 embedded controller custom firmware

[Youness Alaoui]

> > 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.
The 'ectool' is able to read it (ram idx reads if i remember
correctly) but it only worked with AMI BIOS. So there will definitely
be some work to be done there. You probably know a lot more about this
already, like what this 'ram idx' is, and why it didn't work in
coreboot, or if it's possible to read/write the flash using this EDI
interface, etc...
> > > Latest status update for Origami-EC firmware:
> > > https://www.mail-archive.com/[e-mail]/msg50646.html
> >
> > Thanks! Good to see the status update on that.
>
> In order to kickstart the development of the Origami-EC firmware, I am
> designing evaluation boards for both the KB9012 and the KB3930 that
> will expose most of the I/O ports with headers, LEDs, buttons,
> connectors, etc. The design is done with KiCAD and will be released
> under the GPLv3+ as part of the Origami-EC project. I am also preparing
> a debug board to reflash the EC on the G505s from the keyboard
> connector.
>
> There is also ongoing work on the emulator and the SerialICE-like
> library for relatying and tracing I/O on the device via UART. Also,
> note that the emulator can now emulate a virtual console so it's
> already possible to build and interract with the firmware!

That's some really great news. A dev board will definitely be useful
for testing/debugging/developing Origami-EC!
> Cheers,
>
> Paul
> > > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> > >  wrote:
> > > > Hi Marty,
> > > >
> > > > Unfortunately, the EC firmware on the Librems is not open and we
> > > > have
> > > > someone working on that aspect, but with everything we have to
> > > > handle,
> > > > I think it's only being done part time.
> > > > We found something similar to you with the private submodule for
> > > > the
> > > > PS/2 module on the OLPC code.
> > > > More specifically :
> > > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html
> > > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A
> > > > 1
> > > >
> > > > I had opened a ticket a while ago here :
> > > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
> > > > don't
> > > > know the status of that project, maybe you can contact the
> > > > developer
> > > > (Paul Kocialkowski) and see where he's at with his development of
> > > > that
> > > > project (which, I need to mention, hasn't been publicly launched
> > > > yet,
> > > > as far as I know) and he might benefit from your help if you are
> > > > interested in doing that.
> > > > The last time we spoke he said :
> > > > "The OLPC code is nowhere close to usable on any other platform.
> > > > Additionally, it is so poorly written that I don't think it is a
> > > > suitable codebase for any future development. On the other hand,
> > > > my
> > > > Origami-EC project (that I will publicly launch soon) should
> > > > provide a
> > > > flexible codebase to add support for new devices."
> > > >
> > > > Note that the tracker ticket above is quite outdated, we know how
> > > > to
> > > > dump the EC (the problem was that it can't be done via hardware
> > > > because the EC is on the same power rail as the 64KB flash chip,
> > > > so
> > > > when we power the flash via hardware, the EC boots and takes
> > > > control
> > > > of the SPI lines) but for some reason, we could only dump it via
> > > > software (using ectool) through the AMI BIOS firmware, with
> > > > coreboot,
> > > > we only get 0xFF returned, I don't believe we had time to
> > > > investigate
> > > > the cause for that.
> > > >
> > > > Sorry for not having any better news for you, but I hope this
> > > > helps a
> > > > little you at least.
> > > >
> > > > Good luck,
> > > > Youness.
> > > >
> > > > On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer
> > > >  wrote:
> > > > > Greetings,
> > > > >
> > > > > Currently working on a port for the hp g7-2247us laptop, which
> > > > > features
> > > > > an ene kb3940q ec, which hopefully should be very similar to
> > > > > the kb3930
> > > > > ec, which has a datasheet available to the public in a few
> > > > > places.
> > > > >
> > > > > Said similar ec is used in some OLPC devices, as well as some
> > > > > purism
> > > > > devices, and I was hoping someone in the list would have some
> > > > > contacts
> > > > > with those guys so as to be able to use their ec firmware as a
> > > > > bit of a
> > > > > reference design, but the OLPC ec firmware repo has a 'private'
> > > > > submodule which I cannot access and I simply cannot find a repo
> > > > > for the
> > > > > purism ec firmware to reference.
> > > > >
> > > > > Any assistance you could provide on this matter would be
> > > > > greatly
> > > > > appreciated.
> > > > >
> > > > > Marty E. Plummer
>
> Website: https://www.paulk.fr/
> Coding blog: https://code.paulk.fr/
> Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
> --
> coreboot mailing list: [e-mail]
> https://mail.coreboot.org/mailman/listinfo/coreboot