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@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:
- 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.
- 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@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:
- https://patchwork.coreboot.org/patch/4412/
- https://patchwork.coreboot.org/patch/4413/
- 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
- 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
- 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
- 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
- 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
- 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@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