[flashrom] ENE KB9012 patches: new test results

[Paul Kocialkowski]

HI,

Le samedi 08 octobre 2016 à 01:15 +0300, Mike Banon a écrit :
> How long are your wires? I am using short ones (the likes of 10 cm).
> > For high-speed signals, this can have an influence.
> my wires are 11 cm, 8 cm of which is 12 strands high quality copper
> and only 3 cm are ordinary aluminium (inside the 30 pin 0.5mm pitch
> keyboard-like connector). Copper has 1.65x times better electrical
> conductivity than aluminium, so these mixed material 11 cm are about
> 7.8 cm in aluminium-only terms, which seems to be short enough to be
> reliable, also because read 128KB checksum is always the same

Yes, indeed. I was worried that long wires would cause a specific issue in the
frequency range we're dealing with, but the symptoms would indeed rather be
random errors. And the length looks good anyway.

> > Also, you should try to reduce the SPI clock speed: if the
> > "works 1 out of 2 times" issue is caused by a clock speed that is
> > slightly too fast for the KB9012, lowering it could bring the
> > required stability. However, it worked directly with CH341A here.
> According to page 229 of kb datasheet EDI_CLK should be between 1 MHz
> and 8 MHz, so can't set lower than 1 MHz (tried, it always fails).

Right, good point, I had lost sight of that.

> With other speeds it works 1 out of 2 times regardless of speed
> selection. For CH341A I don't know how to choose a speed, and its'
> results are the same (but works much faster). What is interesting is
> that, if it would be purely a clock issue, it would have worked in 50%
> cases - but there would not be a clear "fail/success/fail/success"
> pattern - instead, a bunch of fails and success that are 50% by
> average statistics.

Yes, you're perfectly right!

>  Moreover, this "fail/success" pattern always
> continues if I unplug a programmer from USB, plug it back and try
> again - which makes me sure that the outcome of each try depends on a
> current state of KB9012 or board in general.

That makes sense.

>  Possible theory is that KB9012 ENE debug interface (EDI) could behave
> differently on different boards.

To figure that out, I could give you the spare board that I put out to first
write flashrom support while traveling. I know for sure that it works 100% of
the time with my setup.

>  There are four main types of G505S motherboards that I am
> aware of:
> *) LA-A091P rev.1.0 - discrete graphics is 8570M <-- my case
> *) LA-A091P rev.1.A - discrete graphics is 8570M
> *) LA-A091P rev.1.A - discrete graphics is R5 M230
> *) LA-A092P rev.1.A - no discrete graphics <-- your case

The one I have is marked with LA-A091P rev: 1.A, which has discrete graphics
too. I'll order more boards (more or less) soon as I need them for development
(both EC and Coreboot), so hopefully I'll get one that has a similar bug.

> Also it could be that there was a group of KB9012 with buggy EDI
> interface, and both me and Joerg got one :P (but that is less likely)

Indeed, but could be possible.

I think the best way to figure it out is that I send you one that is known to
work reliably with my setup and see if the issue still occurs.

> In any case this detection problem is minor, it takes just a couple of
> seconds to retry the last console command...

Yes indeed, but I'd like to know why it's happening at all. Also, perhaps we can
do something about it in the code (IIRC Joerg had sent a change in that
direction).

I'd be happier if flashrom support for it was reliable for all users :)

> On Fri, Oct 7, 2016 at 11:08 AM, Paul Kocialkowski <contact at paulk.fr> wrote:
> > 
> > Hi,
> > 
> > Le samedi 01 octobre 2016 à 05:18 +0300, mikeb mikeb a écrit :
> > > 
> > > Hi Paul, very happy to read your reply! I confirm that:
> > > 1) grounding pin 42 to go into test mode - OK, all the grounds were
> > > connected
> > > together: programmer's, mainboard's and KB9012's 42 pin
> > 
> > Sounds good then! Note that the proprietary firmware explicitly disables EDI
> > (the protocol used to access the memory), so grounding pin 42 is the only
> > way to
> > access it.
> > 
> > > 
> > > 2) powering the mainboard - OK, but only by power adapter, battery was not
> > > plugged in. if I do not connect a power adapter, KB9012 cannot be detected
> > > at
> > > all, which is expected behavior.
> > 
> > This is correct.
> > 
> > > 
> > >  Maybe you are connecting the battery while doing this; there should be
> > > some
> > > reason why your results are different. In any case, this 50% detection
> > > issue
> > > is just a minor inconvenience at the moment. What surprising me more is
> > > that
> > > reading time difference between BPv4 and CH341A
> > 
> > I do not have the battery plugged when flashing the device, and plugging it
> > in
> > doesn't change anything here.
> > 
> > How long are your wires? I am using short ones (the likes of 10 cm). For
> > high
> > -speed signals, this can have an influence. Also, you should try to reduce
> > the
> > SPI clock speed: if the "works 1 out of 2 times" issue is caused by a clock
> > speed that is slightly too fast for the KB9012, lowering it could bring the
> > required stability. However, it worked directly with CH341A here.
> > 
> > The different read times are likely due to different SPI clock frequencies.
> > I
> > don't know what CH341A uses but it seems to be a good compromise. FTDI
> > programmers tend to use a clock frequency that is too fast for the KB9012,
> > so it
> > has to be divided with divisor=8.
> > 
> > However, this makes the read slower than CH341A.
> > 
> > > 
> > > I have some questions for you regarding Origami, but since they are not
> > > directly related to flashrom I separate them into another private message
> > > without CC'ing a list (you will receive it in less than a hour)
> > 
> > Indeed, let's keep this discussion about flashrom-related topics only.
> > 
> > Origami-EC will get its own infrastructure eventually anyway (I hope soon).
> > 
> > Cheers!
> > 
> > > 
> > > On Fri, Sep 30, 2016 at 11:20 PM, Paul Kocialkowski <paulk at paulk.fr>
> > > wrote:
> > > > 
> > > > Hi, I got your emails just fine, I just didn't have time to sit down and
> > > > write a proper reply but I'm very enthusiasic about working with you !
> > > > 
> > > > Cheers,
> > > > Paul Kocialkowski
> > > > 
> > > > Le vendredi 23 septembre 2016 à 03:16 +0300, mikeb mikeb a écrit :
> > > > > 
> > > > > Good day! I just tried reading from KB9012 and encountered exactly the
> > > > same
> > > > > 
> > > > > problem as Joerg Albert has ( https://www.flashrom.org/pipermail/flash
> > > > > rom/
> > > > 2016
> > > > > 
> > > > > -May/014653.html ) - chip is detected only every second time. This is
> > > > > not
> > > > > caused by cabling. While it is recommended for SPI that the wires
> > > > > should
> > > > be
> > > > > 
> > > > > shorter than 20cm, my wires are 11 cm: 8 cm of which is 12 strands
> > > > > high
> > > > > quality copper and only 3 cm are ordinary aluminium inside the 30 pin
> > > > 0.5mm
> > > > > 
> > > > > pitch keyboard-like connector
> > > > 
> > > > This is interesting! I still haven't been able to reproduce the issue
> > > > (but
> > > > haven't tried so hard either). Could you indicate whether you are:
> > > > * grounding pin 42 to go into test mode
> > > > * powering the mainboard
> > > > 
> > > > Thanks!
> > > > 
> > > > 
> > > > > 
> > > > > NOTE: it was much easier and safer to solder 1P wires to this
> > > > > connector
> > > > rather
> > > > > 
> > > > > than to motherboard, and you could remove/insert it at any time - what
> > > > > a
> > > > great
> > > > > 
> > > > > convenience! The only 1P wire I had to solder to motherboard is to
> > > > > motherboard's ground, - to make it possible to unite three grounds
> > > > > (motherboard s, KB9012 s and programmer s) - and that was really easy
> > > > because
> > > > > 
> > > > > at least one of these orange circle grounds has a great distance
> > > > > between
> > > > it
> > > > > 
> > > > > and motherboard's elements so it is difficult to screw up there :)
> > > > > Going
> > > > to
> > > > > 
> > > > > share photos and write some manuals about connectivity, hopefully
> > > > > helpful
> > > > to
> > > > > 
> > > > > the people like me who want to participate in Origami EC project -
> > > > creation of
> > > > > 
> > > > > open source firmware for KB9012 which in case of success will be a
> > > > > HUGE
> > > > step
> > > > > 
> > > > > towards Lenovo G505S liberation (AMD laptop with coreboot support) .
> > > > > Discovered Paul's presentation talk by pure accident -
> > > > > https://www.youtube.com/watch?v=B708jdCiW7o
> > > > > 
> > > > > So I tried using two SPI programmers: 1) CH341A . 2) Bus Pirate v4 .
> > > > > The
> > > > only
> > > > > 
> > > > > observed difference is a speed: for CH341A read takes 13-14 minutes,
> > > > > while
> > > > for
> > > > > 
> > > > > BPv4 - despite the latest 7.0 firmware with level 3 optimizations (
> > > > > http:/
> > > > /dan
> > > > > 
> > > > > gerousprototypes.com/docs/Bus_Pirate#Download ) and SPI speed is 8 MHz
> > > > > -
> > > > it
> > > > > 
> > > > > takes 40 minutes to read! Checksums of the files are the same and the
> > > > files
> > > > > 
> > > > > have almost the same contains as KB9012 image for LA-A091P G505S that
> > > > > I
> > > > found
> > > > > 
> > > > > online (same except the area 0x1d000 - 0x1e0f0, their image is filled
> > > > > with
> > > > > 0xff there, mine has many 0x00 with a few 0xff and also data -
> > > > > probably
> > > > > encoded serial number and similar stuff) , so I am pretty sure these
> > > > > programmers both are reading without errors in my setup, just at the
> > > > different
> > > > > 
> > > > > speeds for some weird reason
> > > > > 
> > > > > Patches applied before testing:
> > > > > 1) https://patchwork.coreboot.org/patch/4412/
> > > > > 2) https://patchwork.coreboot.org/patch/4413/
> > > > > 3) https://patchwork.coreboot.org/patch/4414/
> > > > > 
> > > > > This problem with 1/2 detection rate is not a blocker, more like a
> > > > > small
> > > > > inconvenience, so I strongly believe that these patches should be
> > > > > merged
> > > > as
> > > > > 
> > > > > soon as possible! Paul Kocialkowski has committed them almost a year
> > > > > ago,
> > > > such
> > > > > 
> > > > > a major feature and still not merged??
> > > > > 
> > > > > Below you could see some -VVV detection logs.
> > > > > 
> > > > > After reading this really inspiring article ( http://code.paulk.fr/art
> > > > > icle
> > > > 25/a
> > > > > 
> > > > > n-incentive-for-liberating-computers-my-own-use-case ) I guess that
> > > > > Paul's
> > > > > motherboard is LA-A092P, very similar to LA-A091P but no extra GPU.
> > > > > Could
> > > > that
> > > > > 
> > > > > be a reason he is not getting a detection problem? Just a wild
> > > > > guess...
> > > > > 
> > > > > Yours sincerely,
> > > > > Mikeb
> > > > > 
> > > > > 1) Common part of "2) and "3)" - CH341A tries to detect:
> > > > > sudo ./flashrom -p ch341a_spi -c "KB9012 (EDI)" -VVV
> > > > > flashrom v0.9.9-r1954 on Linux 4.4.0-36-generic (x86_64)
> > > > > flashrom is free software, get the source code at https://flashrom.org
> > > > > flashrom was built with libpci 3.3.1, GCC 5.4.0 20160609, little
> > > > > endian
> > > > > Command line (5 args): ./flashrom -p ch341a_spi -c KB9012 (EDI) -VVV
> > > > > 
> > > > > 2) FAIL:
> > > > > Calibrating delay loop... OS timer resolution is 1 usecs, 578M loops
> > > > > per
> > > > > second, 10 myus = 11 us, 100 myus = 92 us, 1000 myus = 914 us, 10000
> > > > > myus
> > > > =
> > > > > 
> > > > > 9661 us, 4 myus = 5 us, OK.
> > > > > Initializing ch341a_spi programmer, Device revision is 3.0.4
> > > > > Wrote 3 bytes: aa 61 00
> > > > > Wrote 4 bytes: ab b7 7f 20
> > > > > The following protocols are supported: SPI.
> > > > > Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region:
> > > > > mapping
> > > > > KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff
> > > > > Read 7 bytes: ff ff ff ff 00 00 00
> > > > > programmer_unmap_flash_region: unmapped 0x0000000000000000
> > > > > No EEPROM/flash device found.
> > > > > Note: flashrom can never write if the flash chip isn't found
> > > > automatically.
> > > > > 
> > > > > Wrote 4 bytes: ab b7 40 20
> > > > > 
> > > > > 3) SUCCESS:
> > > > > Calibrating delay loop... OS timer resolution is 1 usecs, 629M loops
> > > > > per
> > > > > second, 10 myus = 11 us, 100 myus = 100 us, 1000 myus = 994 us, 10000
> > > > > myus
> > > > =
> > > > > 
> > > > > 9974 us, 4 myus = 4 us, OK.
> > > > > Initializing ch341a_spi programmer, Device revision is 3.0.4
> > > > > Wrote 3 bytes: aa 61 00
> > > > > Wrote 4 bytes: ab b7 7f 20
> > > > > The following protocols are supported: SPI.
> > > > > Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region:
> > > > > mapping
> > > > > KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff
> > > > > Read 7 bytes: 00 00 00 00 fa 0a c3
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 24 ff ff ff
> > > > > Read 7 bytes: 00 00 00 00 fa 0a 20
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff
> > > > > Read 7 bytes: 00 00 00 00 fa 0a 00
> > > > > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 80
> > > > > Read 5 bytes: 00 00 00 00 00
> > > > > Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi.
> > > > > programmer_unmap_flash_region: unmapped 0x0000000000000000
> > > > > No operations were specified.
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff
> > > > > Read 7 bytes: 00 00 00 00 fa 0a 80
> > > > > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 00
> > > > > Read 5 bytes: 00 00 00 00 00
> > > > > Wrote 34 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 cf
> > > > > Read 1 bytes: 00
> > > > > Wrote 4 bytes: ab b7 40 20
> > > > > 
> > > > > 4) Small part of Bus Pirate v4 reading log:
> > > > > buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03
> > > > > 0x30
> > > > 0x00
> > > > > 
> > > > > 0xfe 0xab, receiving 0x01 0x5f 0x50 0x90
> > > > > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00
> > > > > 0x40
> > > > > 0x00 0xfe 0xa8 0xc6, receiving 0x01
> > > > > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00
> > > > > 0x40
> > > > > 0x00 0xfe 0xac 0x03, receiving 0x01
> > > > > buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03
> > > > > 0x30
> > > > 0x00
> > > > > 
> > > > > 0xfe 0xab, receiving 0x01 0x5f 0x50 0xec
> > > > > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00
> > > > > 0x40
> > > > > 0x00 0xfe 0xa8 0xc7, receiving 0x01
> > > > > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00
> > > > > 0x40
> > > > > 0x00 0xfe 0xac 0x03, receiving 0x01
> > > > > 
> > > > > 5) Small part of CH341A reading log:
> > > > > Read 5 bytes: 00 00 00 00 00
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff
> > > > > Read 7 bytes: 00 00 00 00 fa 0a ff
> > > > > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 15 fb
> > > > > Read 5 bytes: 00 00 00 00 00
> > > > > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 35 c0
> > > > > Read 5 bytes: 00 00 00 00 00
> > > > > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00
> > > > > 00
> > > > 00 00
> > > > > 
> > > > > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff
> > > > > 
> > > > --
> > > > Paul Kocialkowski, developer of low-level free software for embedded
> > > > devices
> > > > 
> > > > Website: https://www.paulk.fr/
> > > > Coding blog: https://code.paulk.fr/
> > > > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
> > > > _______________________________________________
> > > > flashrom mailing list
> > > > flashrom at flashrom.org
> > > > https://www.flashrom.org/mailman/listinfo/flashrom
> > > > 
> > --
> > Paul Kocialkowski, developer of low-level free software for embedded devices
> > 
> > Website: https://www.paulk.fr/
> > Coding blog: https://code.paulk.fr/
> > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://www.flashrom.org/pipermail/flashrom/attachments/20161009/2fdb3ba1/attachment.asc>