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

[Youness Alaoui]

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.
> @ 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/project:flashrom
>
> 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.
> 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.
> Best regards,
> Mike Banon
>
> 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-A1
> >
> > 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