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.
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/coreboot@coreboot.org/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 kakaroto@kakaroto.homelinux.net 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.h tml And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=393 0-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 hanetzer@startmail.com 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
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
-- Paul Kocialkowski, developer of free digital technology and hardware support
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: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski contact@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.
-
Paul Kocialkowski -
Youness Alaoui