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

2018-03-06 Thread 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
 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  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
>>  wrote:
>>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  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
>>> 

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

2018-03-05 Thread 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  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
>  wrote:
>> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  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.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

2018-03-05 Thread Mike Banon
> 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
 wrote:
> On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  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.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

2018-03-05 Thread Youness Alaoui
On Sun, Mar 4, 2018 at 4:50 AM, Paul Kocialkowski  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.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

2018-03-04 Thread Paul Kocialkowski
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
> > > >  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
> > > > > 

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

2018-02-16 Thread 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/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
>> >  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 

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

2018-02-13 Thread 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/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!

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 :
> > > 

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

2018-02-09 Thread 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/coreboot@coreboot.org/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 

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

2018-02-06 Thread Mike Banon
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)

@ 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

Latest status update for Origami-EC firmware:
https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html

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
>>
>> --
>> 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

-- 

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

2018-02-05 Thread Youness Alaoui
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
>
> --
> 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] ENE KB3940Q-A1 embedded controller custom firmware

2018-02-02 Thread Marty E. Plummer
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