| Message ID | 572608F6.6020309@gmx.de |
|---|---|
| State | New |
| Headers | show |
Hi, Le dimanche 01 mai 2016 à 15:47 +0200, Joerg Albert a écrit : > On 01.05.2016 10:37, Paul Kocialkowski wrote: > > Hi, > > > > could you CC the flashrom mailing list in your future responses? This will > > probably interest others! > I wasn't aware of this mailing lists, thanks! > > Le dimanche 24 avril 2016 à 23:15 +0200, Joerg Albert a écrit : > > > I'll try to program the internal SPI of a KB9012 (inside a Thinkpad S531) > > > - as > > > soon as I've found the correct image and soldered the necessary wires. > > The KB9012 chips has an internal flash memory that is distinct from the > > BIOS' > > SPI flash, so beware not to confuse both! > > I'm aware of this. The S531 manual says, that the system indicator LED shall > flash three times when the power supply gets connected (without switching the > notebook on). As I don't see this and the voltage at the KB9012 is correct I > guess that the EC is not working properly. That makes sense, even though I really don't know enough about your device to say. It's a fun thing to do anyway and it would allow some more testing on my patches, so I encourage you to do it anyway :) > Flashing the BIOS SPI may be the second step ;-) > > > > Found your patch here: > > > > > > http://patchwork.coreboot.org/patch/4325/ > > > > > > Why couldn't I use FlashDirectAccess? Is this meant to program external > > > SPI > > > flash only? > > Yes, that's my understanding of it too. It just makes a bridge between the > > BIOS' > > SPI flash and the KB9012 pads. This is because it's often easier to reflash > > it > > using the keyboard connector, that is often available without fully opening > > the > > device. > > > > What you want if you need to reflash the EC is not FlashDirectAccess, but > > EDI. > > Note that some firmwares explicitly disable it, so you have to ground pin 42 > > to > > enter "test mode", where the 8051 is not running. > > > > Note that the EDI pins are often exported on the keyboard connector, which > > makes > > soldering more doable. > > > The keyboard connector of the S531 has a pitch of 0.5mm, too close for my > soldering experience. > I couldn't find a flex cable matching the connector either, so I went for > soldering wires to some vias/testpoints instead. Good thing if you were able to get all pins that way! Soldering is generally not too hard with flux and braid. What I did is shown on my latest FOSDEM slides: ht tp://ftp-osl.osuosl.org/pub/replicant/conferences/fosdem-2016/the-road-to- liberating-software-at-the-lower-levels.pdf on the slides about the KB9012 EC. > Connected a RaspberryPi and had some problems with the detection of the > KB9012. It seemed to detect the KB9012 > on every second trial only: That's quite strange, can you try with another programmer? Any cheap ch341a- based board would do for a comparison. > -------------- > pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c > "KB9012 (EDI)" -V > flashrom v0.9.9-r1954 on Linux 3.18.11+ (armv6l) > flashrom is free software, get the source code at https://flashrom.org > > flashrom was built with libpci 3.1.9, GCC 4.6.3, little endian > Command line (5 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 > -c KB9012 (EDI) -V > Calibrating delay loop... OS timer resolution is 5 usecs, 229M loops per > second, 10 myus = 11 us, 100 myus = 103 us, 1000 myus = 994 us, 10000 myus = > 10064 us, 20 myus = 26 us, OK. > Initializing linux_spi programmer > Using device /dev/spidev0.0 > Using 1024 kHz clock > The following protocols are supported: SPI. > Probing for ENE KB9012 (EDI), 128 kB: probing for EDI > EDI: found hw version 195 EDI id 4 > Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on linux_spi. > No operations were specified. > pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c > "KB9012 (EDI)" -V > flashrom v0.9.9-r1954 on Linux 3.18.11+ (armv6l) > flashrom is free software, get the source code at https://flashrom.org > > flashrom was built with libpci 3.1.9, GCC 4.6.3, little endian > Command line (5 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 > -c KB9012 (EDI) -V > Calibrating delay loop... OS timer resolution is 4 usecs, 226M loops per > second, 10 myus = 11 us, 100 myus = 102 us, 1000 myus = 1839 us, 10000 myus = > 10424 us, 16 myus = 21 us, OK. > Initializing linux_spi programmer > Using device /dev/spidev0.0 > Using 1024 kHz clock > The following protocols are supported: SPI. > Probing for ENE KB9012 (EDI), 128 kB: probing for EDI > EDI: failed to read hw version (-1) > No EEPROM/flash device found. > Note: flashrom can never write if the flash chip isn't found automatically. > pi@raspberrypi ~ $ flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 -c > "KB9012 (EDI)" -V > flashrom v0.9.9-r1954 on Linux 3.18.11+ (armv6l) > flashrom is free software, get the source code at https://flashrom.org > > flashrom was built with libpci 3.1.9, GCC 4.6.3, little endian > Command line (5 args): flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=1024 > -c KB9012 (EDI) -V > Calibrating delay loop... OS timer resolution is 5 usecs, 229M loops per > second, 10 myus = 11 us, 100 myus = 102 us, 1000 myus = 994 us, 10000 myus = > 10061 us, 20 myus = 22 us, OK. > Initializing linux_spi programmer > Using device /dev/spidev0.0 > Using 1024 kHz clock > The following protocols are supported: SPI. > Probing for ENE KB9012 (EDI), 128 kB: probing for EDI > EDI: found hw version 195 EDI id 4 > Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on linux_spi. > No operations were specified. > -------- > > I've also tried with "speed=2048" (as the KB9012 manual states a minimum clock > of 1MHz) - same problem. > / > /I've added some error/debug printouts and it seems like the KB9012 answers > with all-zeros on each second start of the probe. That's typical of not getting any answer if I'm not mistaken about the SPI bus. > If the buffer content is correct everything else afterwards works fine. > > So I've added a quick workaround in edi_read_byte() and edi_read() to re-do > any read if the buffer contains zero at the first byte. > See the patches attached. I'll have to check that this doesn't cause further problems, but it looks like a good plan. > No idea why it behaves that way, maybe the SPI detection on these pins is a > bit shaky? I couldn't say, my setup works reliably. It doesn't look like a connector issue if it works with your patch. Maybe probe the line with a logic analyzer to see what's going on? > Pin 42 was grounded and the KB9012 remained powered during the whole session. Thanks for the feedback! Cheers,
From eaac203b40988272d95a754eaddf6b68aecb181c Mon Sep 17 00:00:00 2001 From: Joerg Albert <jal2@gmx.de> Date: Sun, 1 May 2016 13:17:14 +0000 Subject: [PATCH 2/2] add workaround for the problem that the KB9012 replies all zeros on each second start --- edi.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/edi.c b/edi.c index 85e5178..05796ed 100644 --- a/edi.c +++ b/edi.c @@ -67,12 +67,28 @@ static int edi_read_byte(struct flashctx *flash, unsigned short address, unsigne edi_read_cmd(cmd, address); + // msg_pdbg("%s: buffer length 0x%x\n", __func__, sizeof(buffer)); + rc = spi_send_command(flash, sizeof(cmd), sizeof(buffer), cmd, buffer); if (rc) { msg_perr("EDI: %s: spi_send_command failed with %d\n", __func__, rc); return -1; } +#if 0 + msg_pdbg("%s: read buffer:", __func__); + for(i=0; i < sizeof(buffer); i++) { + msg_pdbg(" %02x", buffer[i]); + } + msg_pdbg("\n"); +#endif + + /* I sometimes see the chip return a buffer of all zeros. + It works correctly with the second try. + */ + if (buffer[0] == 0) + return -2; + idx = 0; for (i = 0; i < sizeof(buffer); i++) { @@ -109,6 +125,11 @@ static int edi_read(struct flashctx *flash, unsigned short address, unsigned cha do { rc = edi_read_byte(flash, address, data); + + /* dirty workaround for my problem that the chip answers all zeros on each second start ... */ + if (rc == -2) + rc = edi_read_byte(flash, address, data); + if (rc == -EDI_NOT_READY) { /* * Buffer size is increased, one step at a time, -- 1.7.10.4