From kstanevich at imsa.edu Sat Oct 3 19:13:36 2015 From: kstanevich at imsa.edu (Kyle Stanevich) Date: Sat, 3 Oct 2015 10:13:36 -0700 Subject: [flashrom] trouble flashing EN25S64 on Lenovo N21 chromebook Message-ID: Hi, I have attached all the output from my command line. Hopefully it will be useful for you. Do you think that I will ever have a chance to flash this chip, or should I go and buy another laptop? Thanks, Kyle Stanevich -------------- next part -------------- A non-text attachment was scrubbed... Name: errors Type: application/octet-stream Size: 60059 bytes Desc: not available URL: From stefan.tauner at alumni.tuwien.ac.at Sat Oct 3 22:56:35 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sat, 3 Oct 2015 22:56:35 +0200 Subject: [flashrom] trouble flashing EN25S64 on Lenovo N21 chromebook In-Reply-To: References: Message-ID: <201510032056.t93Kua6T002496@mail2.student.tuwien.ac.at> On Sat, 3 Oct 2015 10:13:36 -0700 Kyle Stanevich wrote: > Hi, > > I have attached all the output from my command line. Hopefully it will > be useful for you. > > Do you think that I will ever have a chance to flash this chip, or > should I go and buy another laptop? Hi, first of all you should not reboot before fixing the issue. If you made a backup first, you should try to write that instead. If that works you are at least safe... I am not familiar with the N21 but you probably have to disable a write protection. Also, chromebooks work best with google's (chromiumos') version of flashrom. -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From nico.h at gmx.de Sun Oct 4 21:48:42 2015 From: nico.h at gmx.de (Nico Huber) Date: Sun, 4 Oct 2015 21:48:42 +0200 Subject: [flashrom] [PATCH] ft2232: Hack to delay SPI command after CS# assertion Message-ID: <1443988122-3459-1-git-send-email-nico.h@gmx.de> Here's a tiny hack that I use to externally flash my X200s with an FT2232H. It delays the SPI command by repeating the CS# assertion command many times. Signed-off-by: Nico Huber --- ft2232_spi.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/ft2232_spi.c b/ft2232_spi.c index 08742ec..a85925c 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -419,15 +419,16 @@ static int ft2232_spi_send_command(struct flashctx *flash, struct ftdi_context *ftdic = &ftdic_context; static unsigned char *buf = NULL; /* failed is special. We use bitwise ops, but it is essentially bool. */ - int i = 0, ret = 0, failed = 0; + int i = 0, j, ret = 0, failed = 0; int bufsize; static int oldbufsize = 0; + const int extra_assert_time = 288; if (writecnt > 65536 || readcnt > 65536) return SPI_INVALID_LENGTH; /* buf is not used for the response from the chip. */ - bufsize = max(writecnt + 9, 260 + 9); + bufsize = max(writecnt, 260) + 9 + extra_assert_time * 3; /* Never shrink. realloc() calls are expensive. */ if (bufsize > oldbufsize) { buf = realloc(buf, bufsize); @@ -446,9 +447,11 @@ static int ft2232_spi_send_command(struct flashctx *flash, * operations. */ msg_pspew("Assert CS#\n"); - buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ - buf[i++] = pindir; + for (j = 0; j <= extra_assert_time; ++j) { + buf[i++] = SET_BITS_LOW; + buf[i++] = 0 & ~cs_bits; /* assertive */ + buf[i++] = pindir; + } if (writecnt) { buf[i++] = MPSSE_DO_WRITE | MPSSE_WRITE_NEG; -- 2.4.6 From kstanevich at imsa.edu Mon Oct 5 01:22:35 2015 From: kstanevich at imsa.edu (Kyle Stanevich) Date: Sun, 4 Oct 2015 18:22:35 -0500 Subject: [flashrom] trouble flashing EN25S64 on Lenovo N21 chromebook In-Reply-To: <201510032056.t93Kua6T002496@mail2.student.tuwien.ac.at> References: <201510032056.t93Kua6T002496@mail2.student.tuwien.ac.at> Message-ID: Hi, I am still having trouble flashing the EN25S64 chip on my Lenovo N21 chromebook. I have connected a raspberry pi to the EN25S64 on the Lenovo N21 motherboard chip via this clip ( http://www.amazon.com/Qunqi-Soic8-Flash-Clips-Programmer/dp/B014IXR9RG). On the raspberry pi (which is running raspbian) I run the command "sudo ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 -w ~/Downloads/bios.bin". I have removed the write protect screw, but I don't think that matters because I am connecting to the chip directly. I have tried to compile google's (chromiumos') version of flashrom, but I could not get it to compile due to many errors. Therefore, I am using the latest version of flashrom which compiles fine. It seams to me that the problem is there is something not working correctly writing/erasing/reading to the chip. Erase functions 1 through 3 all fail when using the command shown above. It hangs up on erase function 2 for a very long time. I had to run it overnight until erase function 2 failed. I have tried running the same command again, and it is currently still stuck at "Trying erase function 2... 0x000000-0x7fffff:E". It has been stuck at this line for 16 hours, with the raspberry pi at 100% cpu usage the entire time. The line "This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE" indicates to me that this chip has not yet been tested. I would like to help out with testing for this chip since I have one and have the hardware required to flash it. What can I do to help out? Thanks, Kyle Stanevich On Sat, Oct 3, 2015 at 3:56 PM, Stefan Tauner < stefan.tauner at alumni.tuwien.ac.at> wrote: > On Sat, 3 Oct 2015 10:13:36 -0700 > Kyle Stanevich wrote: > > > Hi, > > > > I have attached all the output from my command line. Hopefully it will > > be useful for you. > > > > Do you think that I will ever have a chance to flash this chip, or > > should I go and buy another laptop? > > Hi, > > first of all you should not reboot before fixing the issue. > If you made a backup first, you should try to write that instead. > If that works you are at least safe... > > I am not familiar with the N21 but you probably have to disable a write > protection. Also, chromebooks work best with google's (chromiumos') > version of flashrom. > > -- > Kind regards/Mit freundlichen Gr??en, Stefan Tauner > -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at gigabyte.getmyip.com Mon Oct 5 14:50:31 2015 From: admin at gigabyte.getmyip.com (=?UTF-8?Q?Micha=c3=abl_Zweers?=) Date: Mon, 5 Oct 2015 14:50:31 +0200 Subject: [flashrom] MX25L25635E / 4 byte addressing In-Reply-To: References: <201509150712.t8F7C8HU026837@mail2.student.tuwien.ac.at> Message-ID: <56127217.8070708@gigabyte.getmyip.com> Hello, I have used the same patch set on trunk to flash W25Q256 (WSON version). I still need to build a system to check what was actually written. (I'll try to flash Openwrt to the chip and run in on a MT7620 with modded U-boot). If there is anything I can do to move this along, please let me know. Kind regards, Micha?l Zweers On 21-9-2015 14:59, Peter Martini wrote: > On Tue, Sep 15, 2015 at 3:12 AM, Stefan Tauner > > wrote: > > On Tue, 15 Sep 2015 02:26:39 -0400 > Peter Martini > wrote: > > > Hello, > > > > I've checked out master from the flashrom svn repo, compiled, and was able > > to see my chip (MX25L25635E). The id wasn't recognized, but after a quick > > patch to copy a MX25L128... to ..L256.., I got it to successfully read the > > first 16MB of the chip - however, I can't get any further than that, > > because changing the values in the table to the right values moves me from > > 3 byte addressing to 4 byte addressing territory (if I understand this > > correctly), and it looks like there aren't any patches merged for that yet. > > > > Is there a patch set actively in the works? > > Nope, there isn't, at least nothing that I know about or that will hit > vanilla flashrom soon. > > -- > Kind regards/Mit freundlichen Gr??en, Stefan Tauner > > > Thanks for the quick reply. I did some digging, and found a patch set > from January, resurrected and forward ported to the current tip of > flashrom on github.com/petermartini/flashrom > , and confirmed it worked well > enough that it worked on my chipset. > > This was Boris' work, and I guess it was incomplete / petered out before > being committed; does it ring any bells? > > It seems the thread petered out around > http://www.flashrom.org/pipermail/flashrom/2015-January/013168.html. > > I'm happy to help, if I can, get that patch set merged in if there's > work to be done on it so I can upstream my chipset's specs. > > Thanks! > Peter > > > _______________________________________________ > flashrom mailing list > flashrom at flashrom.org > http://www.flashrom.org/mailman/listinfo/flashrom > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bleoal at openmailbox.org Tue Oct 6 02:03:06 2015 From: bleoal at openmailbox.org (bleoal at openmailbox.org) Date: Mon, 05 Oct 2015 19:03:06 -0500 Subject: [flashrom] flashrom output on HP 425 Notebook Message-ID: <1b11ab9da0e792f27907bf7f92e6464c@openmailbox.org> Hello: My name is Bruno, last few days ago I founded information about the coreboot project. My question is: Why flashrom says it doesn't support my motherboard if my chipset is supported on the coreboot project wiki. Northbridge: AMD Fam10h Support:OK Southbridge: AMD SB7x0/SB8x0/SB9x0 1002:439d Support:OK SuperI/O: SMSC? FDC37B72x Support:OK CPU: AMD Athlon II P340 Dual-Core Here is the output: Flashrom 0.9.5.2-r1517 : $ sudo flashrom -p internal -V flashrom v0.9.5.2-r1517 on Linux 3.2.0-29-generic (x86_64), built with libpci 3.1.8, GCC 4.6.3, little endian flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OS timer resolution is 1 usecs, 731M loops per second, 10 myus = 10 us, 100 myus = 100 us, 1000 myus = 999 us, 10000 myus = 10009 us, 4 myus = 4 us, OK. Initializing internal programmer No coreboot table found. DMI string system-manufacturer: "Hewlett-Packard" DMI string system-product-name: "HP 425" DMI string system-version: " " DMI string baseboard-manufacturer: "Hewlett-Packard" DMI string baseboard-product-name: "1475" DMI string baseboard-version: "KBC Version 72.13" DMI string chassis-type: "Notebook" Laptop detected via DMI. ======================================================================== WARNING! You seem to be running flashrom on an unsupported laptop. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See http://www.flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== Aborting. lspci -nnvvxxx $ sudo lspci -nnvvxxx 00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] RS880 Host Bridge [1022:9601] Subsystem: Hewlett-Packard Company Device [103c:1475] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [44] HyperTransport: MSI Mapping Enable+ Fixed+ Capabilities: [b0] Subsystem: Hewlett-Packard Company Device [103c:1475] Kernel modules: shpchp 00: 3c 10 02 96 07 00 30 02 00 00 04 06 00 40 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 51 51 20 02 20: 20 94 30 94 01 80 f1 8f 00 00 00 00 00 00 00 00 30: 00 00 00 00 44 00 00 00 00 00 00 00 ff 00 08 00 40: 00 00 00 00 08 b0 03 a8 00 00 00 00 3c 10 75 14 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 0d 00 00 00 3c 10 75 14 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:04.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 0) [1022:9604] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag+ RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep+ BwNot+ LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #4, PowerLimit 0.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState+ RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4159 Capabilities: [b0] Subsystem: Hewlett-Packard Company Device [103c:1475] Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+ Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [110 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Kernel driver in use: pcieport Kernel modules: shpchp 00: 22 10 04 96 07 04 10 00 00 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 02 02 00 31 41 00 00 20: 20 93 10 94 01 90 01 91 00 00 00 00 00 00 00 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 01 58 03 c8 00 00 00 00 10 a0 42 01 20 80 00 00 60: 10 08 00 00 12 0c 30 01 43 00 11 78 00 00 24 00 70: 00 00 48 01 00 00 01 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 05 b0 01 00 0c 30 e0 fe 59 41 00 00 00 00 00 00 b0: 0d b8 00 00 3c 10 75 14 08 00 03 a8 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:07.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (PCIE port 3) [1022:9607] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag+ RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #247, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep+ BwNot+ LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed unknown, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Slot #7, PowerLimit 0.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet- LinkState- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4161 Capabilities: [b0] Subsystem: Hewlett-Packard Company Device [103c:1475] Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+ Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [110 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Kernel driver in use: pcieport Kernel modules: shpchp 00: 22 10 07 96 07 04 10 00 00 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 03 05 00 21 21 00 00 20: 20 92 10 93 11 91 01 92 00 00 00 00 00 00 00 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 01 58 03 c8 00 00 00 00 10 a0 42 01 20 80 00 00 60: 10 08 00 00 12 0c 30 f7 00 00 00 11 60 00 3c 00 70: 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 05 b0 01 00 0c 30 e0 fe 61 41 00 00 00 00 00 00 b0: 0d b8 00 00 3c 10 75 14 08 00 03 a8 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:09.0 PCI bridge [0604]: Advanced Micro Devices [AMD] RS780/RS880 PCI to PCI bridge (PCIE port 4) [1022:9608] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag+ RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep+ BwNot+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #9, PowerLimit 0.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet+ LinkState+ RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- DevCap2: Completion Timeout: Not Supported, TimeoutDis- ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- ARIFwd- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0300c Data: 4169 Capabilities: [b0] Subsystem: Hewlett-Packard Company Device [103c:1475] Capabilities: [b8] HyperTransport: MSI Mapping Enable+ Fixed+ Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [110 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed+ WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Kernel driver in use: pcieport Kernel modules: shpchp 00: 22 10 08 96 07 04 10 00 00 00 04 06 10 00 01 00 10: 00 00 00 00 00 00 00 00 00 06 06 00 f1 01 00 20 20: 10 92 10 92 f1 ff 01 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 01 58 03 c8 00 00 00 00 10 a0 42 01 20 80 00 00 60: 10 08 00 00 12 0c 30 00 42 00 11 70 00 00 4c 00 70: 00 00 48 01 00 00 01 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 05 b0 01 00 0c 30 e0 fe 69 41 00 00 00 00 00 00 b0: 0d b8 00 00 3c 10 75 14 08 00 03 a8 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:11.0 SATA controller [0106]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (prog-if 01 [AHCI 1.0]) Subsystem: Hewlett-Packard Company Device [103c:1475] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00: 02 10 84 43 07 00 a0 02 40 01 04 06 00 40 81 00 10: 00 00 00 00 00 00 00 00 00 07 07 40 10 10 80 22 20: f0 ff 00 00 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40: 26 00 3c ff 00 00 00 00 0c 0f 3d d1 00 00 00 00 50: 01 00 00 00 08 00 03 a8 00 00 00 00 85 00 ff ff 60: ca 0e 17 00 ba 98 10 02 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 01 00 02 06 e0: 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00:14.5 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI2 Controller [1002:4399] (prog-if 10 [OHCI]) Subsystem: Hewlett-Packard Company Device [103c:1475] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Kernel driver in use: k10temp Kernel modules: k10temp 00: 22 10 03 12 00 00 10 00 00 00 00 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 40: ff ff ff 3f 58 00 b0 4a 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 05 00 60 1a 00 00 00 10 51 80 01 60 70: 51 11 32 60 01 01 98 00 14 0c 20 00 11 08 07 00 80: 81 f6 0b e6 e6 41 e6 01 08 00 00 00 00 60 58 02 90: 00 00 00 00 80 00 00 00 90 0f 88 70 00 00 00 00 a0: b9 0a 0d b0 ef 0f 88 2b 28 07 04 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 24 0f 81 c8 14 0b 39 03 43 52 27 70 e0: 00 00 00 00 30 06 40 01 61 5f 07 00 00 00 00 00 f0: 0f 00 10 00 00 00 00 00 00 00 00 00 63 0f 10 00 00:18.4 Host bridge [0600]: Advanced Micro Devices [AMD] Family 10h Processor Link Control [1022:1204] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- [disabled] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Kernel driver in use: fglrx_pci Kernel modules: fglrx, radeon 00: 02 10 12 97 07 00 10 00 00 00 00 03 10 00 80 00 10: 08 00 00 80 01 50 00 00 00 00 30 94 00 00 00 00 20: 00 00 00 00 00 00 20 94 00 00 00 00 3c 10 75 14 30: 00 00 00 00 50 00 00 00 00 00 00 00 0b 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 75 14 50: 01 a0 03 06 00 00 00 00 10 a0 12 00 a0 8f 00 00 60: 10 08 0a 00 01 0d 00 00 00 00 01 11 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 01 00 01 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01:05.1 Audio device [0403]: Advanced Micro Devices [AMD] nee ATI RS880 HDMI Audio [Radeon HD 4200 Series] [1002:970f] Subsystem: Hewlett-Packard Company Device [103c:1475] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Capabilities: [48] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [d0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us ClockPM+ Surprise- LLActRep+ BwNot- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [13c v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Capabilities: [160 v1] Device Serial Number 00-00-af-ff-ff-0d-cc-52 Capabilities: [16c v1] Power Budgeting Kernel driver in use: wl Kernel modules: wl, bcma, brcmsmac 00: e4 14 27 47 06 00 10 00 01 00 80 02 10 00 00 00 10: 04 00 10 92 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 83 14 30: 00 00 00 00 40 00 00 00 00 00 00 00 05 01 00 00 40: 01 58 03 06 08 40 00 00 05 d0 80 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 09 48 78 00 11 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 10 00 18 00 00 00 00 80 00 00 00 03 00 00 00 90: 00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 03 00 00 10 10 18 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 10 00 01 00 a0 8f 00 00 00 00 10 00 11 6c 17 00 e0: 42 00 11 30 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Superiotool output: $ sudo superiotool -deV superiotool r6637 Probing for ALi Super I/O at 0x3f0... Failed. Returned data: id=0xffff, rev=0xff Probing for ALi Super I/O at 0x370... Failed. Returned data: id=0xffff, rev=0xff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0x0400, id=0x014c Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x2e... Failed. Returned data: vid=0xffff, id=0xffff Probing for Fintek Super I/O at 0x4e... Failed. Returned data: vid=0xffff, id=0xffff Probing for ITE Super I/O (init=standard) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x25e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=standard) at 0x2e... Failed. Returned data: id=0x4c01, rev=0x0 Probing for ITE Super I/O (init=it8502e) at 0x2e... Failed. Returned data: id=0x4c01, rev=0x0 Probing for ITE Super I/O (init=it8761e) at 0x2e... Failed. Returned data: id=0x4c01, rev=0x0 Probing for ITE Super I/O (init=it8228e) at 0x2e... Failed. Returned data: id=0x4c01, rev=0x0 Probing for ITE Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id=0x4c01, rev=0x0 Probing for ITE Super I/O (init=standard) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8502e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8761e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=it8228e) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8661f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for ITE Super I/O (init=legacy/it8671f) at 0x370... Failed. Returned data: id=0xffff, rev=0xf Probing for NSC Super I/O at 0x2e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x4e... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x15c... Failed. Returned data: port=0xff, port+1=0xff Probing for NSC Super I/O at 0x164e... Failed. Returned data: port=0xff, port+1=0xff Probing for Nuvoton Super I/O at 0x164e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x2e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for Nuvoton Super I/O at 0x4e... Failed. Returned data: chip_id=0xffff Probing for Nuvoton Super I/O (sid=0xfc) at 0x4e... Failed. Returned data: sid=0xff, id=0xffff, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x2e... Found SMSC FDC37B72x (id=0x4c, rev=0x01) at 0x2e Register dump: idx 03 20 21 22 23 24 26 27 28 2b 2c 2d 2e 2f val 00 4c 01 00 00 04 2e 00 00 00 00 00 00 00 def 03 4c 00 00 00 04 MM MM 00 NA NA NA NA NA LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 f2 f4 f5 val 00 00 00 00 00 00 00 00 00 00 def 00 03 f0 06 02 0e 00 ff 00 00 LDN 0x03 (Parallel port) idx 30 60 61 70 74 f0 f1 val 00 00 00 00 00 00 00 def 00 00 00 00 04 3c 00 LDN 0x04 (COM1) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 00 00 00 00 LDN 0x05 (COM2) idx 30 60 61 70 f0 f1 f2 val 00 00 00 00 00 00 00 def NA 00 00 00 00 02 03 LDN 0x07 (Keyboard) idx 30 70 72 f0 val 01 01 0c 00 def 00 00 00 00 LDN 0x08 (Aux I/O) idx 30 b0 b1 b2 b3 b8 c0 c1 c2 c3 c4 c5 c6 c8 ca cb cc d0 d1 d2 d3 d4 d5 d6 d7 e0 e1 e2 e3 e4 e5 e6 e7 ef f0 f1 f2 f3 f4 f6 f9 fa val 01 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 def 00 NA NA NA NA NA 00 01 NA NA NA 00 NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA 00 00 00 MM NA NA NA LDN 0x0a (ACPI) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 00 00 NA NA No extra registers known for this chip. Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x2e... Failed. Returned data: id=0x00, rev=0x00 Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x4e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x162e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x164e... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x3f0... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x20/0x21) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for SMSC Super I/O (idregs=0x0d/0x0e) at 0x370... Failed. Returned data: id=0xff, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x2e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x4e... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x3f0... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x370... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x88) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x89) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x86,0x86) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for Winbond Super I/O (init=0x87,0x87) at 0x250... Failed. Returned data: id/oldid=0xff/0x0f, rev=0xff Probing for VIA Super I/O at 0x3f0... PCI device 1106:0686 not found. Probing for Server Engines Super I/O at 0x2e... Failed. Returned data: id=0xffff, rev=0xff From contact at paulk.fr Sat Oct 10 16:20:19 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 10 Oct 2015 16:20:19 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support Message-ID: <1444486821-10619-1-git-send-email-contact@paulk.fr> Some chips such as the ENE KB9012 internal flash require a write granularity of 128 bytes. Signed-off-by: Paul Kocialkowski --- flash.h | 1 + flashrom.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/flash.h b/flash.h index 2c2839f..24861ba 100644 --- a/flash.h +++ b/flash.h @@ -85,6 +85,7 @@ enum write_granularity { write_gran_1bit, /* Each bit can be cleared individually. */ write_gran_1byte, /* A byte can be written once. Further writes to an already written byte cause * its contents to be either undefined or to stay unchanged. */ + write_gran_128bytes, /* If less than 128 bytes are written, the unwritten bytes are undefined. */ write_gran_264bytes, /* If less than 264 bytes are written, the unwritten bytes are undefined. */ write_gran_512bytes, /* If less than 512 bytes are written, the unwritten bytes are undefined. */ write_gran_528bytes, /* If less than 528 bytes are written, the unwritten bytes are undefined. */ diff --git a/flashrom.c b/flashrom.c index d51a44c..c9c7e31 100644 --- a/flashrom.c +++ b/flashrom.c @@ -781,6 +781,9 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; } break; + case write_gran_128bytes: + result = need_erase_gran_bytes(have, want, len, 128); + break; case write_gran_256bytes: result = need_erase_gran_bytes(have, want, len, 256); break; @@ -847,6 +850,9 @@ static unsigned int get_next_write(const uint8_t *have, const uint8_t *want, uns case write_gran_1byte_implicit_erase: stride = 1; break; + case write_gran_128bytes: + stride = 128; + break; case write_gran_256bytes: stride = 256; break; -- 1.9.1 From contact at paulk.fr Sat Oct 10 16:20:20 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 10 Oct 2015 16:20:20 +0200 Subject: [flashrom] [PATCH 2/3] Flag-driven erased bit value In-Reply-To: <1444486821-10619-1-git-send-email-contact@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> Message-ID: <1444486821-10619-2-git-send-email-contact@paulk.fr> Most flash chips are erased to ones and programmed to zeros. However, some other flash chips, such as the ENE KB9012 internal flash, work the opposite way. Signed-off-by: Paul Kocialkowski --- flash.h | 3 ++- flashrom.c | 42 ++++++++++++++++++++++-------------------- 2 files changed, 24 insertions(+), 21 deletions(-) diff --git a/flash.h b/flash.h index 24861ba..3d14d56 100644 --- a/flash.h +++ b/flash.h @@ -123,6 +123,7 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_ERASED_ZERO (1 << 10) enum test_state { OK = 0, @@ -275,7 +276,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f int read_flash_to_file(struct flashctx *flash, const char *filename); char *extract_param(const char *const *haystack, const char *needle, const char *delim); int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, uint8_t erased); void print_version(void); void print_buildinfo(void); void print_banner(void); diff --git a/flashrom.c b/flashrom.c index c9c7e31..e463a18 100644 --- a/flashrom.c +++ b/flashrom.c @@ -669,7 +669,7 @@ static int compare_range(const uint8_t *wantbuf, const uint8_t *havebuf, unsigne /* start is an offset to the base address of the flash chip */ int check_erased_range(struct flashctx *flash, unsigned int start, - unsigned int len) + unsigned int len, uint8_t erased) { int ret; uint8_t *cmpbuf = malloc(len); @@ -678,7 +678,7 @@ int check_erased_range(struct flashctx *flash, unsigned int start, msg_gerr("Could not allocate memory!\n"); exit(1); } - memset(cmpbuf, 0xff, len); + memset(cmpbuf, erased, len); ret = verify_range(flash, cmpbuf, start, len); free(cmpbuf); return ret; @@ -731,7 +731,7 @@ out_free: } /* Helper function for need_erase() that focuses on granularities of gran bytes. */ -static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran) +static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran, uint8_t erased) { unsigned int i, j, limit; for (j = 0; j < len / gran; j++) { @@ -741,7 +741,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig continue; /* have needs to be in erased state. */ for (i = 0; i < limit; i++) - if (have[j * gran + i] != 0xff) + if (have[j * gran + i] != erased) return 1; } return 0; @@ -761,7 +761,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig * @gran write granularity (enum, not count) * @return 0 if no erase is needed, 1 otherwise */ -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran) +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, uint8_t erased) { int result = 0; unsigned int i; @@ -776,31 +776,31 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; case write_gran_1byte: for (i = 0; i < len; i++) - if ((have[i] != want[i]) && (have[i] != 0xff)) { + if ((have[i] != want[i]) && (have[i] != erased)) { result = 1; break; } break; case write_gran_128bytes: - result = need_erase_gran_bytes(have, want, len, 128); + result = need_erase_gran_bytes(have, want, len, 128, erased); break; case write_gran_256bytes: - result = need_erase_gran_bytes(have, want, len, 256); + result = need_erase_gran_bytes(have, want, len, 256, erased); break; case write_gran_264bytes: - result = need_erase_gran_bytes(have, want, len, 264); + result = need_erase_gran_bytes(have, want, len, 264, erased); break; case write_gran_512bytes: - result = need_erase_gran_bytes(have, want, len, 512); + result = need_erase_gran_bytes(have, want, len, 512, erased); break; case write_gran_528bytes: - result = need_erase_gran_bytes(have, want, len, 528); + result = need_erase_gran_bytes(have, want, len, 528, erased); break; case write_gran_1024bytes: - result = need_erase_gran_bytes(have, want, len, 1024); + result = need_erase_gran_bytes(have, want, len, 1024, erased); break; case write_gran_1056bytes: - result = need_erase_gran_bytes(have, want, len, 1056); + result = need_erase_gran_bytes(have, want, len, 1056, erased); break; case write_gran_1byte_implicit_erase: /* Do not erase, handle content changes from anything->0xff by writing 0xff. */ @@ -1424,6 +1424,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, unsigned int starthere = 0, lenhere = 0; int ret = 0, skip = 1, writecount = 0; enum write_granularity gran = flash->chip->gran; + uint8_t erased = (flash->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff; /* curcontents and newcontents are opaque to walk_eraseregions, and * need to be adjusted here to keep the impression of proper abstraction @@ -1431,17 +1432,17 @@ static int erase_and_write_block_helper(struct flashctx *flash, curcontents += start; newcontents += start; msg_cdbg(":"); - if (need_erase(curcontents, newcontents, len, gran)) { + if (need_erase(curcontents, newcontents, len, gran, erased)) { msg_cdbg("E"); ret = erasefn(flash, start, len); if (ret) return ret; - if (check_erased_range(flash, start, len)) { + if (check_erased_range(flash, start, len, erased)) { msg_cerr("ERASE FAILED!\n"); return -1; } /* Erase was successful. Adjust curcontents. */ - memset(curcontents, 0xff, len); + memset(curcontents, erased, len); skip = 0; } /* get_next_write() sets starthere to a new value after the call. */ @@ -1938,6 +1939,7 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, int ret = 0; unsigned long size = flash->chip->total_size * 1024; int read_all_first = 1; /* FIXME: Make this configurable. */ + uint8_t erased = (flash->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff; if (chip_safety_check(flash, force, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -1964,15 +1966,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_gerr("Out of memory!\n"); exit(1); } - /* Assume worst case: All bits are 0. */ - memset(oldcontents, 0x00, size); + /* Assume worst case: All bits are not erased. */ + memset(oldcontents, ~erased, size); newcontents = malloc(size); if (!newcontents) { msg_gerr("Out of memory!\n"); exit(1); } - /* Assume best case: All bits should be 1. */ - memset(newcontents, 0xff, size); + /* Assume best case: All bits should be erased. */ + memset(newcontents, erased, size); /* Side effect of the assumptions above: Default write action is erase * because newcontents looks like a completely erased chip, and * oldcontents being completely 0x00 means we have to erase everything -- 1.9.1 From contact at paulk.fr Sat Oct 10 16:20:21 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 10 Oct 2015 16:20:21 +0200 Subject: [flashrom] [PATCH 3/3] ENE Embedded Debug Interface (EDI) and ENE KB9012 EC internal flash support In-Reply-To: <1444486821-10619-1-git-send-email-contact@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> Message-ID: <1444486821-10619-3-git-send-email-contact@paulk.fr> The ENE Embedded Debug Interface (EDI) is a SPI-based interface for accessing the memory of ENE embedded controllers. The ENE KB9012 EC is an embedded controller found on various laptops such as the Lenovo G505s. It features a 8051 microcontroller and has 128 KiB of internal storage for program data. EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO) when flash direct access is not in use. Some firmwares disable EDI at run-time, so it might be necessary to ground pin 42 to reset the 8051 microcontroller before accessing the KB9012 via EDI. Signed-off-by: Paul Kocialkowski --- Makefile | 2 +- chipdrivers.h | 6 + edi.c | 418 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ edi.h | 34 +++++ ene.h | 55 ++++++++ flashchips.c | 23 ++++ 6 files changed, 537 insertions(+), 1 deletion(-) create mode 100644 edi.c create mode 100644 edi.h create mode 100644 ene.h diff --git a/Makefile b/Makefile index c439d8d..661c52a 100644 --- a/Makefile +++ b/Makefile @@ -368,7 +368,7 @@ endif CHIP_OBJS = jedec.o stm50.o w39.o w29ee011.o \ sst28sf040.o 82802ab.o \ - sst49lfxxxc.o sst_fwhub.o flashchips.o spi.o spi25.o spi25_statusreg.o \ + sst49lfxxxc.o sst_fwhub.o edi.o flashchips.o spi.o spi25.o spi25_statusreg.o \ opaque.o sfdp.o en29lv640b.o at45db.o ############################################################################### diff --git a/chipdrivers.h b/chipdrivers.h index cac94f3..8015b52 100644 --- a/chipdrivers.h +++ b/chipdrivers.h @@ -194,4 +194,10 @@ int erase_sector_stm50(struct flashctx *flash, unsigned int block, unsigned int int probe_en29lv640b(struct flashctx *flash); int write_en29lv640b(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len); +/* edi.c */ +int edi_chip_block_erase(struct flashctx *flash, unsigned int page, unsigned int size); +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len); +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); +int edi_probe_kb9012(struct flashctx *flash); + #endif /* !__CHIPDRIVERS_H__ */ diff --git a/edi.c b/edi.c new file mode 100644 index 0000000..a3e0539 --- /dev/null +++ b/edi.c @@ -0,0 +1,418 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2015 Paul Kocialkowski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include +#include "flash.h" +#include "ene.h" +#include "edi.h" + +static unsigned int edi_read_buffer_length = EDI_READ_BUFFER_LENGTH_DEFAULT; + +static struct ene_chip ene_kb9012 = { + .hwversion = ENE_KB9012_HWVERSION, + .ediid = ENE_KB9012_EDIID, +}; + +static void edi_write_cmd(unsigned char *cmd, unsigned short address, unsigned char data) +{ + cmd[0] = EDI_WRITE; /* EDI write command. */ + cmd[1] = 0x00; /* Address is only 2 bytes. */ + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ + cmd[4] = data; /* Write data. */ +} + +static void edi_read_cmd(unsigned char *cmd, unsigned short address) +{ + cmd[0] = EDI_READ; /* EDI read command. */ + cmd[1] = 0x00; /* Address is only 2 bytes. */ + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ +} + +static int edi_write(struct flashctx *flash, unsigned short address, unsigned char data) +{ + unsigned char cmd[5] = { 0 }; + int rc; + + edi_write_cmd((unsigned char *)cmd, address, data); + + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned char *)cmd, NULL); + if (rc) + return rc; + + return 0; +} + +static int edi_read(struct flashctx *flash, unsigned short address, unsigned char *data) +{ + unsigned char cmd[4] = { 0 }; + unsigned char buffer[edi_read_buffer_length]; + unsigned int i; + int rc; + + edi_read_cmd((unsigned char *)cmd, address); + + memset(buffer, 0, sizeof(buffer)); + + rc = spi_send_command(flash, sizeof(cmd), sizeof(buffer), (unsigned char *)cmd, (unsigned char *)buffer); + if (rc) + return rc; + + for (i = 0; i < sizeof(buffer); i++) { + if (buffer[i] == EDI_NOT_READY) + continue; + + if (buffer[i] == EDI_READY) { + if (i == (sizeof(buffer) - 1)) { + /* + * Buffer size was too small for receiving the value. + * This is as good as getting only EDI_NOT_READY. + */ + + buffer[i] = EDI_NOT_READY; + break; + } + + *data = buffer[i + 1]; + return 0; + } + } + + if (buffer[i - 1] == EDI_NOT_READY) { + /* + * Buffer size is increased, one step at a time, + * to hold more data if we only catch EDI_NOT_READY. + * Once CS is deasserted, no more data will be sent by the EC, + * so we cannot keep reading afterwards and have to start a new + * transaction with a longer buffer, to be safe. + */ + + if ((edi_read_buffer_length + 1) <= EDI_READ_BUFFER_LENGTH_MAX) { + msg_pwarn("%s: Retrying read with greater buffer length!\n", __func__); + edi_read_buffer_length++; + + return edi_read(flash, address, data); + } else { + msg_perr("%s: Maximum buffer length reached and data still not ready!\n", __func__); + return -1; + } + } + + return -1; +} + +static int edi_chip_probe(struct flashctx *flash, struct ene_chip *chip) +{ + unsigned char hwversion = 0; + unsigned char ediid = 0; + int rc; + + rc = edi_read(flash, ENE_EC_HWVERSION, &hwversion); + if (rc < 0) + return 0; + + rc = edi_read(flash, ENE_EC_EDIID, &ediid); + if (rc < 0) + return 0; + + if (chip->hwversion == hwversion && chip->ediid == ediid) + return 1; + + return 0; +} + +static int edi_disable(struct flashctx *flash) +{ + unsigned char cmd = EDI_DISABLE; + int rc; + + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned char *)&cmd, NULL); + if (rc) + return rc; + + return 0; +} + +static int edi_spi_enable(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); + if (rc < 0) + return rc; + + buffer |= ENE_XBI_EFCFG_CMD_WE; + + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); + if (rc < 0) + return rc; + + return 0; +} + +static int edi_spi_disable(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); + if (rc < 0) + return rc; + + buffer &= ~ENE_XBI_EFCFG_CMD_WE; + + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); + if (rc < 0) + return rc; + + return 0; +} + +static int edi_spi_busy(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); + if (rc < 0) + return rc; + + return !!(buffer & ENE_XBI_EFCFG_BUSY); +} + +static int edi_8051_reset(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); + if (rc < 0) + return rc; + + buffer |= ENE_EC_PXCFG_8051_RESET; + + rc = edi_write(flash, ENE_EC_PXCFG, buffer); + if (rc < 0) + return rc; + + return 0; +} + +static int edi_8051_execute(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); + if (rc < 0) + return rc; + + buffer &= ~ENE_EC_PXCFG_8051_RESET; + + rc = edi_write(flash, ENE_EC_PXCFG, buffer); + if (rc < 0) + return rc; + + return 0; +} + +int edi_chip_block_erase(struct flashctx *flash, unsigned int page, unsigned int size) +{ + unsigned int timeout = 64; + + if (size != flash->chip->page_size) { + msg_perr("%s: Block erase size is not page size!\n", __func__); + return -1; + } + + edi_spi_enable(flash); + + edi_write(flash, ENE_XBI_EFA0, ((page & 0xff) >> 0)); + edi_write(flash, ENE_XBI_EFA1, ((page & 0xff00) >> 8)); + edi_write(flash, ENE_XBI_EFA2, ((page & 0xff0000) >> 16)); + + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_ERASE); + + while (edi_spi_busy(flash) && timeout--) + programmer_delay(10); + + edi_spi_disable(flash); + + return 0; +} + +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len) +{ + unsigned int address = start; + unsigned int pages; + unsigned int timeout; + unsigned int i, j; + + if ((start % flash->chip->page_size) != 0) { + msg_perr("%s: Start address is not page-aligned!\n", __func__); + return -1; + } + + if ((len % flash->chip->page_size) != 0) { + msg_perr("%s: Length is not page-aligned!\n", __func__); + return -1; + } + + pages = len / flash->chip->page_size; + + edi_spi_enable(flash); + + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + + for (i = 0; i < pages; i++) { + timeout = 64; + + /* Clear page buffer. */ + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_HVPL_CLEAR); + + for (j = 0; j < flash->chip->page_size; j++) { + if ((address - start) > 0) { + if (((address - 1) & 0xff) != (address & 0xff)) + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + if (((address - 1) & 0xff00) != (address & 0xff00)) + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + if (((address - 1) & 0xff0000) != (address & 0xff0000)) + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + } + + edi_write(flash, ENE_XBI_EFDAT, *buf); + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_HVPL_LATCH); + + buf++; + address++; + } + + /* Program page buffer to flash. */ + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_PROGRAM); + + while (edi_spi_busy(flash) && timeout--) + programmer_delay(10); + } + + edi_spi_disable(flash); + + return 0; +} + +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len) +{ + unsigned int address = start; + unsigned int i; + unsigned int timeout; + int rc; + + edi_spi_enable(flash); + + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + + /* + * EDI brings such a drastic overhead that there is about no need to + * have any delay in between calls. The EDI protocol will handle wait + * I/O times on its own anyway. + */ + + for (i = 0; i < len; i++) { + timeout = 64; + + if ((address - start) > 0) { + if (((address - 1) & 0xff) != (address & 0xff)) + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + if (((address - 1) & 0xff00) != (address & 0xff00)) + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + if (((address - 1) & 0xff0000) != (address & 0xff0000)) + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + } + + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_READ); + + do { + rc = edi_read(flash, ENE_XBI_EFDAT, buf); + if (!rc) + break; + + /* Just in case. */ + while (edi_spi_busy(flash) && timeout--) + programmer_delay(10); + } while (rc); + + buf++; + address++; + } + + edi_spi_disable(flash); + + return 0; +} + +int edi_shutdown(void *data) +{ + struct flashctx *flash; + int rc; + + if (data == NULL) + return -1; + + flash = (struct flashctx *)data; + + rc = edi_8051_execute(flash); + if (rc < 0) { + msg_perr("%s: Unable to execute 8051!\n", __func__); + return -1; + } + + rc = edi_disable(flash); + if (rc < 0) { + msg_perr("%s: Unable to disable EDI!\n", __func__); + return -1; + } + + return 0; +} + +int edi_probe_kb9012(struct flashctx *flash) +{ + int probe; + int rc; + + probe = edi_chip_probe(flash, &ene_kb9012); + if (!probe) + return 0; + + rc = edi_8051_reset(flash); + if (rc < 0) { + msg_perr("%s: Unable to reset 8051!\n", __func__); + return 0; + } + + register_shutdown(edi_shutdown, (void *)flash); + + return 1; +} diff --git a/edi.h b/edi.h new file mode 100644 index 0000000..d9387b1 --- /dev/null +++ b/edi.h @@ -0,0 +1,34 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2015 Paul Kocialkowski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef __EDI_H__ +#define __EDI_H__ 1 + +#define EDI_READ 0x30 +#define EDI_WRITE 0x40 +#define EDI_DISABLE 0xf3 + +#define EDI_NOT_READY 0x5f +#define EDI_READY 0x50 + +#define EDI_READ_BUFFER_LENGTH_DEFAULT 3 +#define EDI_READ_BUFFER_LENGTH_MAX 32 + +#endif diff --git a/ene.h b/ene.h new file mode 100644 index 0000000..445d28b --- /dev/null +++ b/ene.h @@ -0,0 +1,55 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2015 Paul Kocialkowski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#ifndef __ENE_H__ +#define __ENE_H__ 1 + +#define ENE_XBI_EFA0 0xfea8 +#define ENE_XBI_EFA1 0xfea9 +#define ENE_XBI_EFA2 0xfeaa +#define ENE_XBI_EFDAT 0xfeab +#define ENE_XBI_EFCMD 0xfeac +#define ENE_XBI_EFCFG 0xfead + +#define ENE_XBI_EFCFG_CMD_WE (1 << 3) +#define ENE_XBI_EFCFG_BUSY (1 << 1) + +#define ENE_XBI_EFCMD_HVPL_LATCH 0x02 +#define ENE_XBI_EFCMD_READ 0x03 +#define ENE_XBI_EFCMD_ERASE 0x20 +#define ENE_XBI_EFCMD_PROGRAM 0x70 +#define ENE_XBI_EFCMD_HVPL_CLEAR 0x80 + +#define ENE_EC_PXCFG 0xff14 + +#define ENE_EC_PXCFG_8051_RESET 0x01 + +#define ENE_EC_HWVERSION 0xff00 +#define ENE_EC_EDIID 0xff24 + +#define ENE_KB9012_HWVERSION 0xc3 +#define ENE_KB9012_EDIID 0x04 + +struct ene_chip { + unsigned char hwversion; + unsigned char ediid; +}; + +#endif diff --git a/flashchips.c b/flashchips.c index 574ad74..13f0574 100644 --- a/flashchips.c +++ b/flashchips.c @@ -3201,6 +3201,29 @@ const struct flashchip flashchips[] = { }, { + .vendor = "ENE", + .name = "KB9012 (EDI)", + .bustype = BUS_SPI, + .total_size = 128, + .page_size = 128, + .feature_bits = FEATURE_ERASED_ZERO, + .tested = TEST_OK_PREW, + .probe = edi_probe_kb9012, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {128, 1024} }, + .block_erase = edi_chip_block_erase, + }, + }, + .gran = write_gran_128bytes, + .write = edi_chip_write, + .read = edi_chip_read, + .voltage = {2700, 3600}, + }, + + { .vendor = "ESMT", .name = "F49B002UA", .bustype = BUS_PARALLEL, -- 1.9.1 From nico.h at gmx.de Mon Oct 12 21:24:55 2015 From: nico.h at gmx.de (Nico Huber) Date: Mon, 12 Oct 2015 21:24:55 +0200 Subject: [flashrom] flashrom output on HP 425 Notebook In-Reply-To: <1b11ab9da0e792f27907bf7f92e6464c@openmailbox.org> References: <1b11ab9da0e792f27907bf7f92e6464c@openmailbox.org> Message-ID: <561C0907.1010406@gmx.de> Hi Bruno, people were quite busy with the coreboot conference last week. In case you didn't find answers on your own yet: > My question is: Why flashrom says it doesn't support my motherboard if > my chipset is supported on the coreboot project wiki. Your question somehow answers itself: For coreboot, every motherboard has to be supported individually. And that's sometimes also true for flashrom. So in your case, flashrom may know how to access the flash chip but doesn't know if there are other programs / chips like the EC that may intervene. Maybe try a newer version of flashrom, yours seems outdated. In the end, you can try to force flashrom, but this could brick your machine. Also, if you target at running coreboot on your machine, I don't think it's supported. But that's a question for the coreboot mailing list. Nico From gwenj at trabucayre.com Wed Oct 14 10:43:08 2015 From: gwenj at trabucayre.com (Gwenhael Goavec-Merou) Date: Wed, 14 Oct 2015 10:43:08 +0200 Subject: [flashrom] [PATCH 2/2] fix compiling with non glibc libcs In-Reply-To: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> References: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> Message-ID: <1444812188-8766-2-git-send-email-gwenj@trabucayre.com> From: Gwenhael Goavec-Merou When musl is used to provides libc flashrom built fail with : [...] rayer_spi.c:(.text+0x95): undefined reference to `outb' [...] satamv.c:(.text+0x5e): undefined reference to `outl' satamv.c:(.text+0x7b): undefined reference to `outb' collect2: error: ld returned 1 exit status This patch changed test on __GLIBC__ by __linux__ to obtain a more generic verification. Patch based on : http://git.buildroot.net/buildroot/commit/package/exfat-utils/0001-fix-compiling-with-non-glibc-libcs.patch?id=2ca62551c04d3bcb0e2e83b9f4f5d3ff8d12110e Signed-off-by: Gwenhael Goavec-Merou --- hwaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hwaccess.h b/hwaccess.h index 3e46192..cf27577 100644 --- a/hwaccess.h +++ b/hwaccess.h @@ -27,7 +27,7 @@ #include "platform.h" #if IS_X86 -#if defined(__GLIBC__) +#if defined(__linux__) #include #endif #endif -- 2.4.9 From gwenj at trabucayre.com Wed Oct 14 10:43:07 2015 From: gwenj at trabucayre.com (Gwenhael Goavec-Merou) Date: Wed, 14 Oct 2015 10:43:07 +0200 Subject: [flashrom] [PATCH 1/2] Add missing header for musl compatibility Message-ID: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> From: Gwenhael Goavec-Merou According to : http://autobuild.buildroot.net/results/3de/3de936d9be79e151e66af15193084d82a0f2c04a/build-end.log linux/ioctl.h header must be included in linux_spi.c to obtain missing _IOC_SIZEBITS. Patch based on : http://git.buildroot.net/buildroot/commit/package/c-periphery/0001-Add-missing-header-for-musl-compatibility.patch?id=60974ee92dd8ff9e43cc6b785ea5131a8851e74c Signed-off-by: Gwenhael Goavec-Merou --- linux_spi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/linux_spi.c b/linux_spi.c index 26725e1..8d72420 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -28,6 +28,7 @@ #include #include #include +#include #include #include "flash.h" #include "chipdrivers.h" -- 2.4.9 From nico.h at gmx.de Wed Oct 14 21:43:04 2015 From: nico.h at gmx.de (Nico Huber) Date: Wed, 14 Oct 2015 21:43:04 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <1444486821-10619-1-git-send-email-contact@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> Message-ID: <561EB048.9060604@gmx.de> On 10.10.2015 16:20, Paul Kocialkowski wrote: > Some chips such as the ENE KB9012 internal flash require a write granularity of > 128 bytes. > > Signed-off-by: Paul Kocialkowski clean patch, +2 > --- > flash.h | 1 + > flashrom.c | 6 ++++++ > 2 files changed, 7 insertions(+) > > diff --git a/flash.h b/flash.h > index 2c2839f..24861ba 100644 > --- a/flash.h > +++ b/flash.h > @@ -85,6 +85,7 @@ enum write_granularity { > write_gran_1bit, /* Each bit can be cleared individually. */ > write_gran_1byte, /* A byte can be written once. Further writes to an already written byte cause > * its contents to be either undefined or to stay unchanged. */ > + write_gran_128bytes, /* If less than 128 bytes are written, the unwritten bytes are undefined. */ > write_gran_264bytes, /* If less than 264 bytes are written, the unwritten bytes are undefined. */ > write_gran_512bytes, /* If less than 512 bytes are written, the unwritten bytes are undefined. */ > write_gran_528bytes, /* If less than 528 bytes are written, the unwritten bytes are undefined. */ > diff --git a/flashrom.c b/flashrom.c > index d51a44c..c9c7e31 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ -781,6 +781,9 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum > break; > } > break; > + case write_gran_128bytes: > + result = need_erase_gran_bytes(have, want, len, 128); > + break; > case write_gran_256bytes: > result = need_erase_gran_bytes(have, want, len, 256); > break; > @@ -847,6 +850,9 @@ static unsigned int get_next_write(const uint8_t *have, const uint8_t *want, uns > case write_gran_1byte_implicit_erase: > stride = 1; > break; > + case write_gran_128bytes: > + stride = 128; > + break; > case write_gran_256bytes: > stride = 256; > break; > From nico.h at gmx.de Wed Oct 14 21:59:03 2015 From: nico.h at gmx.de (Nico Huber) Date: Wed, 14 Oct 2015 21:59:03 +0200 Subject: [flashrom] [PATCH 2/3] Flag-driven erased bit value In-Reply-To: <1444486821-10619-2-git-send-email-contact@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <1444486821-10619-2-git-send-email-contact@paulk.fr> Message-ID: <561EB407.9070004@gmx.de> On 10.10.2015 16:20, Paul Kocialkowski wrote: > Most flash chips are erased to ones and programmed to zeros. However, some other > flash chips, such as the ENE KB9012 internal flash, work the opposite way. > > Signed-off-by: Paul Kocialkowski Looks good, some comments below. Nico > --- > flash.h | 3 ++- > flashrom.c | 42 ++++++++++++++++++++++-------------------- > 2 files changed, 24 insertions(+), 21 deletions(-) > > diff --git a/flash.h b/flash.h > index 24861ba..3d14d56 100644 > --- a/flash.h > +++ b/flash.h > @@ -123,6 +123,7 @@ enum write_granularity { > #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) > #define FEATURE_OTP (1 << 8) > #define FEATURE_QPI (1 << 9) > +#define FEATURE_ERASED_ZERO (1 << 10) > > enum test_state { > OK = 0, > @@ -275,7 +276,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f > int read_flash_to_file(struct flashctx *flash, const char *filename); > char *extract_param(const char *const *haystack, const char *needle, const char *delim); > int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); > -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); > +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, uint8_t erased); When reading `erased` I though it sounds like a boolean. Maybe call it `erased_value`? > void print_version(void); > void print_buildinfo(void); > void print_banner(void); > diff --git a/flashrom.c b/flashrom.c > index c9c7e31..e463a18 100644 > --- a/flashrom.c > +++ b/flashrom.c > @@ -669,7 +669,7 @@ static int compare_range(const uint8_t *wantbuf, const uint8_t *havebuf, unsigne > > /* start is an offset to the base address of the flash chip */ > int check_erased_range(struct flashctx *flash, unsigned int start, > - unsigned int len) > + unsigned int len, uint8_t erased) There's already `struct flashctx *` in the signature, doesn't that have the information this time, already? [...] > @@ -1424,6 +1424,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, > unsigned int starthere = 0, lenhere = 0; > int ret = 0, skip = 1, writecount = 0; > enum write_granularity gran = flash->chip->gran; > + uint8_t erased = (flash->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff; You could make the transformation a macro or inline function, that would save you from writing it out in full again. Also, as this variable never changes later, it could be declared `const`. Hmmm, that also applies to the added parameters. From nico.h at gmx.de Wed Oct 14 23:39:06 2015 From: nico.h at gmx.de (Nico Huber) Date: Wed, 14 Oct 2015 23:39:06 +0200 Subject: [flashrom] [PATCH 3/3] ENE Embedded Debug Interface (EDI) and ENE KB9012 EC internal flash support In-Reply-To: <1444486821-10619-3-git-send-email-contact@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <1444486821-10619-3-git-send-email-contact@paulk.fr> Message-ID: <561ECB7A.10407@gmx.de> On 10.10.2015 16:20, Paul Kocialkowski wrote: > The ENE Embedded Debug Interface (EDI) is a SPI-based interface for accessing > the memory of ENE embedded controllers. > > The ENE KB9012 EC is an embedded controller found on various laptops such as > the Lenovo G505s. It features a 8051 microcontroller and has 128 KiB of internal > storage for program data. > > EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO) when > flash direct access is not in use. Some firmwares disable EDI at run-time, so > it might be necessary to ground pin 42 to reset the 8051 microcontroller before > accessing the KB9012 via EDI. > > Signed-off-by: Paul Kocialkowski Thank you for taking the time to write a clean implementation. I had a good time reading it and learning about that EDI protocol :) I don't know the hardware, so I've only commented on general stuff. It looks good on the easy to test, positive paths. Failure handling OTOH needs more work. Nico > --- > Makefile | 2 +- > chipdrivers.h | 6 + > edi.c | 418 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > edi.h | 34 +++++ > ene.h | 55 ++++++++ > flashchips.c | 23 ++++ > 6 files changed, 537 insertions(+), 1 deletion(-) > create mode 100644 edi.c > create mode 100644 edi.h > create mode 100644 ene.h > > diff --git a/Makefile b/Makefile > index c439d8d..661c52a 100644 > --- a/Makefile > +++ b/Makefile > @@ -368,7 +368,7 @@ endif > > CHIP_OBJS = jedec.o stm50.o w39.o w29ee011.o \ > sst28sf040.o 82802ab.o \ > - sst49lfxxxc.o sst_fwhub.o flashchips.o spi.o spi25.o spi25_statusreg.o \ > + sst49lfxxxc.o sst_fwhub.o edi.o flashchips.o spi.o spi25.o spi25_statusreg.o \ > opaque.o sfdp.o en29lv640b.o at45db.o > > ############################################################################### > diff --git a/chipdrivers.h b/chipdrivers.h > index cac94f3..8015b52 100644 > --- a/chipdrivers.h > +++ b/chipdrivers.h > @@ -194,4 +194,10 @@ int erase_sector_stm50(struct flashctx *flash, unsigned int block, unsigned int > int probe_en29lv640b(struct flashctx *flash); > int write_en29lv640b(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len); > > +/* edi.c */ > +int edi_chip_block_erase(struct flashctx *flash, unsigned int page, unsigned int size); > +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len); > +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); > +int edi_probe_kb9012(struct flashctx *flash); > + > #endif /* !__CHIPDRIVERS_H__ */ > diff --git a/edi.c b/edi.c > new file mode 100644 > index 0000000..a3e0539 > --- /dev/null > +++ b/edi.c > @@ -0,0 +1,418 @@ > +/* > + * This file is part of the flashrom project. > + * > + * Copyright (C) 2015 Paul Kocialkowski > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Please drop that last paragraph from all new files. FSF's address used to change and might again. > + */ > + > +#include > +#include "flash.h" > +#include "ene.h" > +#include "edi.h" > + > +static unsigned int edi_read_buffer_length = EDI_READ_BUFFER_LENGTH_DEFAULT; > + > +static struct ene_chip ene_kb9012 = { > + .hwversion = ENE_KB9012_HWVERSION, > + .ediid = ENE_KB9012_EDIID, > +}; Could be `const` from what I've seen. > + > +static void edi_write_cmd(unsigned char *cmd, unsigned short address, unsigned char data) > +{ > + cmd[0] = EDI_WRITE; /* EDI write command. */ > + cmd[1] = 0x00; /* Address is only 2 bytes. */ > + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ > + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ > + cmd[4] = data; /* Write data. */ > +} > + > +static void edi_read_cmd(unsigned char *cmd, unsigned short address) > +{ > + cmd[0] = EDI_READ; /* EDI read command. */ > + cmd[1] = 0x00; /* Address is only 2 bytes. */ > + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ > + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ > +} > + > +static int edi_write(struct flashctx *flash, unsigned short address, unsigned char data) > +{ > + unsigned char cmd[5] = { 0 }; edi_write_cmd() below already fully initializes `cmd`. > + int rc; > + > + edi_write_cmd((unsigned char *)cmd, address, data); > + > + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned char *)cmd, NULL); I don't see a reason to cast `cmd`. But maybe it's just my C. Also you could just return spi_send_command(...)... > + if (rc) > + return rc; > + > + return 0; ... or return rc unconditionally. It looks very weird that way. > +} > + > +static int edi_read(struct flashctx *flash, unsigned short address, unsigned char *data) > +{ > + unsigned char cmd[4] = { 0 }; Again, `cmd` gets fully initialized later. > + unsigned char buffer[edi_read_buffer_length]; > + unsigned int i; > + int rc; > + > + edi_read_cmd((unsigned char *)cmd, address); > + > + memset(buffer, 0, sizeof(buffer)); Why? > + > + rc = spi_send_command(flash, sizeof(cmd), sizeof(buffer), (unsigned char *)cmd, (unsigned char *)buffer); Maybe unnecessary casts. > + if (rc) > + return rc; > + > + for (i = 0; i < sizeof(buffer); i++) { > + if (buffer[i] == EDI_NOT_READY) > + continue; > + > + if (buffer[i] == EDI_READY) { > + if (i == (sizeof(buffer) - 1)) { > + /* > + * Buffer size was too small for receiving the value. > + * This is as good as getting only EDI_NOT_READY. > + */ > + > + buffer[i] = EDI_NOT_READY; > + break; If you break here, `i` won't get increased and `buffer[i]` is never read. > + } > + > + *data = buffer[i + 1]; > + return 0; > + } So you're ignoring everything but EDI_READY and EDI_NOT_READY. Are there other valid values that might occur? Or could we just bail out? return failure here? > + } > + > + if (buffer[i - 1] == EDI_NOT_READY) { > + /* > + * Buffer size is increased, one step at a time, > + * to hold more data if we only catch EDI_NOT_READY. > + * Once CS is deasserted, no more data will be sent by the EC, > + * so we cannot keep reading afterwards and have to start a new > + * transaction with a longer buffer, to be safe. > + */ > + > + if ((edi_read_buffer_length + 1) <= EDI_READ_BUFFER_LENGTH_MAX) { So that's equivalent to `edi_read_buffer_length < EDI_READ_BUFFER_LENGTH_MAX`. > + msg_pwarn("%s: Retrying read with greater buffer length!\n", __func__); > + edi_read_buffer_length++; > + > + return edi_read(flash, address, data); Oh, recursion... stack usage looks not that bad, but could you live without it? For example write a edi_retry_read() that calls a non-recur- sive edi_read() in a loop? > + } else { > + msg_perr("%s: Maximum buffer length reached and data still not ready!\n", __func__); > + return -1; You'd return -1 anyway below, but that's ok, it looks more balanced this way... > + } > + } > + > + return -1; > +} > + > +static int edi_chip_probe(struct flashctx *flash, struct ene_chip *chip) `chip` could be const. > +{ > + unsigned char hwversion = 0; > + unsigned char ediid = 0; > + int rc; > + > + rc = edi_read(flash, ENE_EC_HWVERSION, &hwversion); > + if (rc < 0) > + return 0; > + > + rc = edi_read(flash, ENE_EC_EDIID, &ediid); > + if (rc < 0) > + return 0; > + > + if (chip->hwversion == hwversion && chip->ediid == ediid) > + return 1; > + > + return 0; > +} > + > +static int edi_disable(struct flashctx *flash) > +{ > + unsigned char cmd = EDI_DISABLE; const? > + int rc; There's no need for a variable here. Just return spi_send_command(...). > + > + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned char *)&cmd, NULL); > + if (rc) > + return rc; > + > + return 0; > +} > + > +static int edi_spi_enable(struct flashctx *flash) > +{ > + unsigned char buffer = 0; > + int rc; > + > + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); > + if (rc < 0) It looks odd if you know, that it won't be > 0. > + return rc; > + > + buffer |= ENE_XBI_EFCFG_CMD_WE; > + > + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); > + if (rc < 0) > + return rc; > + > + return 0; return edi_write(...)? > +} > + > +static int edi_spi_disable(struct flashctx *flash) > +{ > + unsigned char buffer = 0; > + int rc; > + > + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); > + if (rc < 0) > + return rc; > + > + buffer &= ~ENE_XBI_EFCFG_CMD_WE; > + > + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); > + if (rc < 0) > + return rc; > + > + return 0; > +} > + > +static int edi_spi_busy(struct flashctx *flash) > +{ > + unsigned char buffer = 0; > + int rc; > + > + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); > + if (rc < 0) > + return rc; > + > + return !!(buffer & ENE_XBI_EFCFG_BUSY); > +} > + > +static int edi_8051_reset(struct flashctx *flash) > +{ > + unsigned char buffer = 0; > + int rc; > + > + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); > + if (rc < 0) > + return rc; > + > + buffer |= ENE_EC_PXCFG_8051_RESET; > + > + rc = edi_write(flash, ENE_EC_PXCFG, buffer); > + if (rc < 0) > + return rc; > + > + return 0; > +} > + > +static int edi_8051_execute(struct flashctx *flash) > +{ > + unsigned char buffer = 0; > + int rc; > + > + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); > + if (rc < 0) > + return rc; > + > + buffer &= ~ENE_EC_PXCFG_8051_RESET; > + > + rc = edi_write(flash, ENE_EC_PXCFG, buffer); > + if (rc < 0) > + return rc; > + > + return 0; > +} > + > +int edi_chip_block_erase(struct flashctx *flash, unsigned int page, unsigned int size) Pedantic me: unsigned int is not assured to be wider than 16-bit ;) but that's a flashrom interface, isn't it? > +{ > + unsigned int timeout = 64; > + > + if (size != flash->chip->page_size) { Is this even possible? Or some kind of assertion? > + msg_perr("%s: Block erase size is not page size!\n", __func__); > + return -1; > + } > + > + edi_spi_enable(flash); > + > + edi_write(flash, ENE_XBI_EFA0, ((page & 0xff) >> 0)); > + edi_write(flash, ENE_XBI_EFA1, ((page & 0xff00) >> 8)); > + edi_write(flash, ENE_XBI_EFA2, ((page & 0xff0000) >> 16)); > + > + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_ERASE); Every edi_write() may fail...[1] > + > + while (edi_spi_busy(flash) && timeout--) Um, edi_spi_busy() also returns true (!= 0) if it failed to read at all. > + programmer_delay(10); > + > + edi_spi_disable(flash); > + > + return 0; [1]...returning 0 anyway? > +} > + > +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len) > +{ > + unsigned int address = start; > + unsigned int pages; > + unsigned int timeout; > + unsigned int i, j; > + > + if ((start % flash->chip->page_size) != 0) { > + msg_perr("%s: Start address is not page-aligned!\n", __func__); > + return -1; > + } > + > + if ((len % flash->chip->page_size) != 0) { > + msg_perr("%s: Length is not page-aligned!\n", __func__); > + return -1; > + } > + > + pages = len / flash->chip->page_size; > + > + edi_spi_enable(flash); > + > + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); > + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); > + > + for (i = 0; i < pages; i++) { > + timeout = 64; > + > + /* Clear page buffer. */ > + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_HVPL_CLEAR); > + > + for (j = 0; j < flash->chip->page_size; j++) { > + if ((address - start) > 0) { Just got confused here, so `start` is the overall start not the start of the page. Would have known that, when `start` would have been declared const ;) Also it's equivalent to `address > start`. > + if (((address - 1) & 0xff) != (address & 0xff)) > + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); > + if (((address - 1) & 0xff00) != (address & 0xff00)) > + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > + if (((address - 1) & 0xff0000) != (address & 0xff0000)) > + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); > + } > + > + edi_write(flash, ENE_XBI_EFDAT, *buf); > + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_HVPL_LATCH); > + > + buf++; > + address++; > + } > + > + /* Program page buffer to flash. */ > + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_PROGRAM); > + > + while (edi_spi_busy(flash) && timeout--) > + programmer_delay(10); > + } > + > + edi_spi_disable(flash); > + > + return 0; Again, every edi_write() may fail, edi_spi_{en,dis}able() also. Not checking on single calls might be ok, but in a sheer endless loop? that's not good. Guess, the SPI programmer driver runs into a timeout of one second for every call to spi_send_command(), you'd be waiting ages for this to end. > +} > + > +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len) > +{ > + unsigned int address = start; > + unsigned int i; > + unsigned int timeout; > + int rc; > + > + edi_spi_enable(flash); > + > + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); > + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); > + > + /* > + * EDI brings such a drastic overhead that there is about no need to > + * have any delay in between calls. The EDI protocol will handle wait > + * I/O times on its own anyway. > + */ > + > + for (i = 0; i < len; i++) { > + timeout = 64; > + > + if ((address - start) > 0) { > + if (((address - 1) & 0xff) != (address & 0xff)) > + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); > + if (((address - 1) & 0xff00) != (address & 0xff00)) > + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > + if (((address - 1) & 0xff0000) != (address & 0xff0000)) > + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); > + } > + > + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_READ); > + > + do { > + rc = edi_read(flash, ENE_XBI_EFDAT, buf); > + if (!rc) > + break; if (!timeout) return ...? or loop for ever! > + > + /* Just in case. */ > + while (edi_spi_busy(flash) && timeout--) > + programmer_delay(10); > + } while (rc); Redundant check (rc can't be zero when we reach it) hides the endless loop. Nice try! hehe > + > + buf++; > + address++; > + } > + > + edi_spi_disable(flash); > + > + return 0; > +} > + > +int edi_shutdown(void *data) > +{ > + struct flashctx *flash; > + int rc; > + > + if (data == NULL) > + return -1; > + > + flash = (struct flashctx *)data; > + > + rc = edi_8051_execute(flash); > + if (rc < 0) { > + msg_perr("%s: Unable to execute 8051!\n", __func__); > + return -1; > + } > + > + rc = edi_disable(flash); > + if (rc < 0) { > + msg_perr("%s: Unable to disable EDI!\n", __func__); > + return -1; > + } > + > + return 0; > +} > + > +int edi_probe_kb9012(struct flashctx *flash) > +{ > + int probe; > + int rc; > + > + probe = edi_chip_probe(flash, &ene_kb9012); > + if (!probe) > + return 0; > + > + rc = edi_8051_reset(flash); > + if (rc < 0) { > + msg_perr("%s: Unable to reset 8051!\n", __func__); > + return 0; > + } > + > + register_shutdown(edi_shutdown, (void *)flash); > + > + return 1; > +} > diff --git a/edi.h b/edi.h > new file mode 100644 > index 0000000..d9387b1 > --- /dev/null > +++ b/edi.h > @@ -0,0 +1,34 @@ > +/* > + * This file is part of the flashrom project. > + * > + * Copyright (C) 2015 Paul Kocialkowski > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#ifndef __EDI_H__ > +#define __EDI_H__ 1 > + > +#define EDI_READ 0x30 > +#define EDI_WRITE 0x40 > +#define EDI_DISABLE 0xf3 > + > +#define EDI_NOT_READY 0x5f > +#define EDI_READY 0x50 > + > +#define EDI_READ_BUFFER_LENGTH_DEFAULT 3 > +#define EDI_READ_BUFFER_LENGTH_MAX 32 > + > +#endif > diff --git a/ene.h b/ene.h > new file mode 100644 > index 0000000..445d28b > --- /dev/null > +++ b/ene.h > @@ -0,0 +1,55 @@ > +/* > + * This file is part of the flashrom project. > + * > + * Copyright (C) 2015 Paul Kocialkowski > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > + */ > + > +#ifndef __ENE_H__ > +#define __ENE_H__ 1 > + > +#define ENE_XBI_EFA0 0xfea8 > +#define ENE_XBI_EFA1 0xfea9 > +#define ENE_XBI_EFA2 0xfeaa > +#define ENE_XBI_EFDAT 0xfeab > +#define ENE_XBI_EFCMD 0xfeac > +#define ENE_XBI_EFCFG 0xfead > + > +#define ENE_XBI_EFCFG_CMD_WE (1 << 3) > +#define ENE_XBI_EFCFG_BUSY (1 << 1) > + > +#define ENE_XBI_EFCMD_HVPL_LATCH 0x02 > +#define ENE_XBI_EFCMD_READ 0x03 > +#define ENE_XBI_EFCMD_ERASE 0x20 > +#define ENE_XBI_EFCMD_PROGRAM 0x70 > +#define ENE_XBI_EFCMD_HVPL_CLEAR 0x80 > + > +#define ENE_EC_PXCFG 0xff14 > + > +#define ENE_EC_PXCFG_8051_RESET 0x01 > + > +#define ENE_EC_HWVERSION 0xff00 > +#define ENE_EC_EDIID 0xff24 > + > +#define ENE_KB9012_HWVERSION 0xc3 > +#define ENE_KB9012_EDIID 0x04 > + > +struct ene_chip { > + unsigned char hwversion; > + unsigned char ediid; > +}; > + > +#endif > diff --git a/flashchips.c b/flashchips.c > index 574ad74..13f0574 100644 > --- a/flashchips.c > +++ b/flashchips.c > @@ -3201,6 +3201,29 @@ const struct flashchip flashchips[] = { > }, > > { > + .vendor = "ENE", > + .name = "KB9012 (EDI)", > + .bustype = BUS_SPI, > + .total_size = 128, > + .page_size = 128, > + .feature_bits = FEATURE_ERASED_ZERO, > + .tested = TEST_OK_PREW, > + .probe = edi_probe_kb9012, > + .probe_timing = TIMING_ZERO, > + .block_erasers = > + { > + { > + .eraseblocks = { {128, 1024} }, > + .block_erase = edi_chip_block_erase, > + }, > + }, > + .gran = write_gran_128bytes, > + .write = edi_chip_write, > + .read = edi_chip_read, > + .voltage = {2700, 3600}, > + }, > + > + { > .vendor = "ESMT", > .name = "F49B002UA", > .bustype = BUS_PARALLEL, > From alfonsojon1997 at gmail.com Mon Oct 12 05:06:26 2015 From: alfonsojon1997 at gmail.com (Jonathan Alfonso) Date: Sun, 11 Oct 2015 22:06:26 -0500 Subject: [flashrom] Flashrom failed on Acer C720P, using Fedora 23 Message-ID: Hi, I have this output... http://paste.flashrom.org/view.php?id=2803 I can't reboot right now, so I'm looking for a fix... I don't know what to do though. Help is definitely appreciated... -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfonsojon1997 at gmail.com Mon Oct 12 06:04:19 2015 From: alfonsojon1997 at gmail.com (Jonathan Alfonso) Date: Sun, 11 Oct 2015 23:04:19 -0500 Subject: [flashrom] Flashrom failed on Acer C720P, using Fedora 23 In-Reply-To: References: Message-ID: <20151012040419.5501011.85417.6024@gmail.com> An HTML attachment was scrubbed... URL: From kylestanevich at gmail.com Thu Oct 8 20:48:44 2015 From: kylestanevich at gmail.com (Kyle Stanevich) Date: Thu, 8 Oct 2015 13:48:44 -0500 Subject: [flashrom] trouble flashing EN25S64 on Lenovo N21 chromebook In-Reply-To: References: <201510032056.t93Kua6T002496@mail2.student.tuwien.ac.at> Message-ID: Hi, This is just a follow up email. I was wondering what the status is of support for the EN25S64 bios chip. I have tried to flash it many times and it always fails. See my message below for more details. I would like to help out with any testing for this chip, however if I don't hear back from you soon, I will probably be returning the laptop I have which contains the EN25S64 chip. Thanks, Kyle Stanevich On Oct 4, 2015 6:22 PM, "Kyle Stanevich" wrote: > Hi, > > I am still having trouble flashing the EN25S64 chip on my Lenovo N21 > chromebook. I have connected a raspberry pi to the EN25S64 on the Lenovo > N21 motherboard chip via this clip ( > http://www.amazon.com/Qunqi-Soic8-Flash-Clips-Programmer/dp/B014IXR9RG). > On the raspberry pi (which is running raspbian) I run the command "sudo > ./flashrom -VVV -p linux_spi:dev=/dev/spidev0.0 -w ~/Downloads/bios.bin". I > have removed the write protect screw, but I don't think that matters > because I am connecting to the chip directly. > > I have tried to compile google's (chromiumos') version of flashrom, but I > could not get it to compile due to many errors. Therefore, I am using the > latest version of flashrom which compiles fine. > > It seams to me that the problem is there is something not working > correctly writing/erasing/reading to the chip. Erase functions 1 through 3 > all fail when using the command shown above. It hangs up on erase function > 2 for a very long time. I had to run it overnight until erase function 2 > failed. I have tried running the same command again, and it is currently > still stuck at "Trying erase function 2... 0x000000-0x7fffff:E". It has > been stuck at this line for 16 hours, with the raspberry pi at 100% cpu > usage the entire time. > > The line "This flash part has status UNTESTED for operations: PROBE READ > ERASE WRITE" indicates to me that this chip has not yet been tested. I > would like to help out with testing for this chip since I have one and have > the hardware required to flash it. What can I do to help out? > > Thanks, > Kyle Stanevich > > > > On Sat, Oct 3, 2015 at 3:56 PM, Stefan Tauner < > stefan.tauner at alumni.tuwien.ac.at> wrote: > >> On Sat, 3 Oct 2015 10:13:36 -0700 >> Kyle Stanevich wrote: >> >> > Hi, >> > >> > I have attached all the output from my command line. Hopefully it will >> > be useful for you. >> > >> > Do you think that I will ever have a chance to flash this chip, or >> > should I go and buy another laptop? >> >> Hi, >> >> first of all you should not reboot before fixing the issue. >> If you made a backup first, you should try to write that instead. >> If that works you are at least safe... >> >> I am not familiar with the N21 but you probably have to disable a write >> protection. Also, chromebooks work best with google's (chromiumos') >> version of flashrom. >> >> -- >> Kind regards/Mit freundlichen Gr??en, Stefan Tauner >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svn at flashrom.org Fri Oct 16 04:16:20 2015 From: svn at flashrom.org (repository service) Date: Fri, 16 Oct 2015 04:16:20 +0200 Subject: [flashrom] [commit] r1897 - trunk Message-ID: Author: stefanct Date: Fri Oct 16 04:16:20 2015 New Revision: 1897 URL: http://flashrom.org/trac/flashrom/changeset/1897 Log: Add support for 128 bytes write granularity. Some chips such as the ENE KB9012 internal flash require a write granularity of 128 bytes. Signed-off-by: Paul Kocialkowski Acked-by: Nico Huber Modified: trunk/flash.h trunk/flashrom.c Modified: trunk/flash.h ============================================================================== --- trunk/flash.h Sun Jul 5 18:53:22 2015 (r1896) +++ trunk/flash.h Fri Oct 16 04:16:20 2015 (r1897) @@ -85,6 +85,7 @@ write_gran_1bit, /* Each bit can be cleared individually. */ write_gran_1byte, /* A byte can be written once. Further writes to an already written byte cause * its contents to be either undefined or to stay unchanged. */ + write_gran_128bytes, /* If less than 128 bytes are written, the unwritten bytes are undefined. */ write_gran_264bytes, /* If less than 264 bytes are written, the unwritten bytes are undefined. */ write_gran_512bytes, /* If less than 512 bytes are written, the unwritten bytes are undefined. */ write_gran_528bytes, /* If less than 528 bytes are written, the unwritten bytes are undefined. */ Modified: trunk/flashrom.c ============================================================================== --- trunk/flashrom.c Sun Jul 5 18:53:22 2015 (r1896) +++ trunk/flashrom.c Fri Oct 16 04:16:20 2015 (r1897) @@ -781,6 +781,9 @@ break; } break; + case write_gran_128bytes: + result = need_erase_gran_bytes(have, want, len, 128); + break; case write_gran_256bytes: result = need_erase_gran_bytes(have, want, len, 256); break; @@ -847,6 +850,9 @@ case write_gran_1byte_implicit_erase: stride = 1; break; + case write_gran_128bytes: + stride = 128; + break; case write_gran_256bytes: stride = 256; break; From stefan.tauner at alumni.tuwien.ac.at Fri Oct 16 04:25:34 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Fri, 16 Oct 2015 04:25:34 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <561EB048.9060604@gmx.de> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <561EB048.9060604@gmx.de> Message-ID: <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> On Wed, 14 Oct 2015 21:43:04 +0200 Nico Huber wrote: > On 10.10.2015 16:20, Paul Kocialkowski wrote: > > Some chips such as the ENE KB9012 internal flash require a write granularity of > > 128 bytes. > > > > Signed-off-by: Paul Kocialkowski > clean patch, +2 I've understood that as an acked-by... ;) Thanks to both of you. Committed in r1897. -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From stefan.tauner at alumni.tuwien.ac.at Fri Oct 16 20:10:14 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Fri, 16 Oct 2015 20:10:14 +0200 Subject: [flashrom] M25P10-A write success confirmed and verified Message-ID: <201510161810.t9GIAEoP018215@mail2.student.tuwien.ac.at> We got a mail by a reporter who does not want to get his email address published, therefore I will quote his email verbatim below. > Hello, > > I can confirm that I have just successfully flashed an ST 25P10VP flash > chip, in circuit, using a Raspberry Pi, its onboard SPI, a Pomona 5250 SOIC > clip and some female jumper wires. > > I updated the Raspberry Pi B+ with rpi-update to the latest firmware and > kernel, and compiled the code from svn://flashrom.org/flashrom/trunk on the > Raspberry device itself. I just used the -p and -w parameters to make this > work, no other magic. Flashrom reported write success and verified status > on the chip. > > According to Micron documentation, the markings 25P10VP correspond to a > M25P10-A, and flashrom recognizes this type indeed. Since the status for > writing this chip is still a question mark, I thought I should report a > success. > > I encountered zero errors during the use of flashrom, everything worked in > one go. Flashrom allowed me to recover a friend's WD HDD with a burnt-out > PCB. So a big thank you is in order! > > Thank you so much! > > P.S. Could you please keep my e-mail address private? > > Kind regards, > Martijn Schiedon I'll add the respective flag for the M25P10-A. Thanks Martijn for the report! Please include a verbose log file next time. -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From leonardovilla84 at gmail.com Thu Oct 15 16:19:28 2015 From: leonardovilla84 at gmail.com (Leonardo Villarreal Cortez) Date: Thu, 15 Oct 2015 09:19:28 -0500 Subject: [flashrom] Report: Intel DH67CF BLH6710H.86A.0160.2012.1204.1156 read Message-ID: hello, i have an intel board series dh67, i need bios dump. can help me facilitating the file of dump ? thanks -- Atentamente, Leonardo Villarreal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From r_brown100r at mail2world.com Sat Oct 17 02:07:27 2015 From: r_brown100r at mail2world.com (Robert Brown) Date: Fri, 16 Oct 2015 17:07:27 -0700 Subject: [flashrom] SOIC8 test clip - cant write to BIOS SPI flash chip Message-ID: <9A95527C47DC43CB81C8C0295B948A1C@mail2world.com> Unfortunately I don't have any soldering tools or experience, so if you could give an advice about ISP programming (In-System-Programming/In-Situ-Programming) , it will be super helpful! I teardown a bricked laptop, removed AC power, laptop's power battery, and even a small CMOS battery, and now I am trying to write a working BIOS image to laptop's SPI flash chip using a SOIC8 test clip. But here is a problem: I could read a dump from this BIOS chip without problems, however it fails when I am trying to write - so the contents of BIOS flash chip are remaining unchanged. Luckily I found out this helpful wiki page - http://flashrom.org/ISP , which describes common problems with this ISP method of flashing, as well as gives 3 hints for solution! Sadly this page is currently down, so here is a screenshot: http://i.imgur.com/SJEYHR2.png 1. - tried to make shorter wires, less than 10cm as they recommend - it did not help 2. - soldering is out of possibility, cant do it, and also: wires are already short and they are good quality (pure copper) 3. - This hint looks more promising, but I need help in understanding this piece of information: "disconnect Vcc from the programmer and power it with its normal PSU" If I understand correctly, by Vcc they mean Vcc pin of the BIOS flash chip. But if I disconnect Vcc from the programmer, what is "normal PSU" which should power this Vcc pin? Should I connect to motherboard a laptop's power battery, or small CMOS battery, or AC adapter of laptop, so that this Vcc pin would be powered by them, or it is forbidden to do it while using SPI programmer in the same time? Or its better to try to power Vcc of flash chip from "USB to TTL" adapter - which has this 3V3 (3.3V) voltage pin? Yours faithfully, Robert Brown

_______________________________________________________________
Get the Free email that has everyone talking at http://www.mail2world.com
Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More!
-------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.h at gmx.de Sat Oct 17 12:57:54 2015 From: nico.h at gmx.de (Nico Huber) Date: Sat, 17 Oct 2015 12:57:54 +0200 Subject: [flashrom] SOIC8 test clip - cant write to BIOS SPI flash chip In-Reply-To: <9A95527C47DC43CB81C8C0295B948A1C@mail2world.com> References: <9A95527C47DC43CB81C8C0295B948A1C@mail2world.com> Message-ID: <562229B2.50706@gmx.de> Hi Robert, it might be easier to help if we knew your Laptop model. Also, please provide a full log of the failing flashrom run with the -V switch, you can specify a log file with -o. On 17.10.2015 02:07, Robert Brown wrote: > But here is a problem: I could read a dump from this BIOS chip without > problems, however Please further define "without problems". Did you try several reads and compared the contents? > it fails when I am trying to write - so the contents of BIOS flash chip > are remaining unchanged. Log please. By guessing two possible issues come in mind: 1. Your pro- grammer doesn't provide enough power for erasure. 2. The write protec- tion pin of your flash chip is asserted. > Should I connect to motherboard a laptop's power battery, or small CMOS > battery, or AC adapter of laptop, I'd try with the AC adapter. In that case Vcc must _not_ be connected to your programmer. GND, OTOH, has to stay connected. > so that this Vcc pin would be powered by them, or it is forbidden to do > it while using SPI programmer in the same time? Not forbidden. It's sometimes even encouraged because there are boards where the Vcc pin of the flash chip is directly connected to other chips, which would draw down the power from the programmer. > Or its better to try to power Vcc of flash chip from "USB to TTL" > adapter - which has this 3V3 (3.3V) voltage pin? It really depends on your machine. Nico From r_brown100r at mail2world.com Sat Oct 17 16:56:20 2015 From: r_brown100r at mail2world.com (Robert Brown) Date: Sat, 17 Oct 2015 07:56:20 -0700 Subject: [flashrom] SOIC8 test clip - cant write to BIOS SPI flash chip Message-ID: Dear Nico, > > It might be easier to help if we knew your Laptop model. Also, please > provide a full log of the failing flashrom run with the -V switch, you > can specify a log file with -o. > Right now I'm away from that laptop and cant remember its model (or provide a flashrom log) However I remember the most important thing: the model of BIOS SPI flash chip is EON EN25QH32 which is supported by flashrom since version 0.9.6 . I got a latest datasheet at official EON website ( here it is - http://www.eonssi.com/upfile/p2013114174725.pdf ) > > Please further define "without problems". Did you try several reads and > compared the contents? > Yes I tried several reads and the contents of flash chip are always the same. Moreover, I was able to successfully write 00s and FFs for a few times, and right now the contents of SPI flash chip: 00's - first 1MB , FF's - last 3MB > > By guessing two possible issues come in mind: 1. Your programmer doesn't provide > enough power for erasure. 2. The write protection pin of your flash chip is asserted. > Because I was able to write at least some stuff, I believe that your 1st theory is true: maybe a part of current that should be going to flash chip for a successfull write, is powering a half of the surrounding circuit instead... > > I'd try with the AC adapter. In that case Vcc must _not_ be connected to > your programmer. GND, OTOH, has to stay connected. > > Not forbidden. It's sometimes even encouraged because there are boards > where the Vcc pin of the flash chip is directly connected to other > chips, which would draw down the power from the programmer. > Thank you very much for advice, Nico! As soon as I get back to equipment I am going to disconnect a Vcc pin from a programmer to avoid the overvoltage (just checked the datasheet above and Vcc is the 8th leg of that flash chip) Hopefully it will be powered good enough by the AC adapter ;-) Just not sure what to do with a CMOS battery, too afraid to connect it back together with AC adapter - if there would be overvoltage I am screwed... > >> >> Or its better to try to power Vcc of flash chip from "USB to TTL" >> adapter - which has this 3V3 (3.3V) voltage pin? >> > > It really depends on your machine. > EN25QH32 datasheet tells that this flash chip supports between 2.7V and 3.6V, 3.3V seems OK and I would probably try taking it to Vcc from "USB to TTL adapter" if the solution with a laptop's AC adapter will not work... AC adapter would also powering EC controller, so what if EC will setup a write protect? Best wishes, Robert Brown <-----Original Message-----> >From: Nico Huber [nico.h at gmx.de] >Subject: Re: [flashrom] SOIC8 test clip - cant write to BIOS SPI flash chip > > >On 17.10.2015 02:07, Robert Brown wrote: >> But here is a problem: I could read a dump from this BIOS chip without >> problems, however > > >> it fails when I am trying to write - so the contents of BIOS flash chip >> are remaining unchanged. >Log please. By guessing two possible issues come in mind: 1. Your pro- >grammer doesn't provide enough power for erasure. 2. The write protec- >tion pin of your flash chip is asserted. > >> Should I connect to motherboard a laptop's power battery, or small CMOS >> battery, or AC adapter of laptop, >I'd try with the AC adapter. In that case Vcc must _not_ be connected to >your programmer. GND, OTOH, has to stay connected. > >> so that this Vcc pin would be powered by them, or it is forbidden to do >> it while using SPI programmer in the same time? >Not forbidden. It's sometimes even encouraged because there are boards >where the Vcc pin of the flash chip is directly connected to other >chips, which would draw down the power from the programmer. > >> Or its better to try to power Vcc of flash chip from "USB to TTL" >> adapter - which has this 3V3 (3.3V) voltage pin? >It really depends on your machine. > >Nico >. >

_______________________________________________________________
Get the Free email that has everyone talking at http://www.mail2world.com
Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More!
-------------- next part -------------- An HTML attachment was scrubbed... URL: From r_brown100r at aim.com Sat Oct 17 01:48:38 2015 From: r_brown100r at aim.com (r_brown100r at aim.com) Date: Fri, 16 Oct 2015 19:48:38 -0400 Subject: [flashrom] SOIC8 test clip - cant write to BIOS SPI flash chip Message-ID: <150730e2510-4fd1-f5b2@webprd-a92.mail.aol.com> Unfortunately I don't have any soldering tools or experience, so if you could give an advice about ISP programming (In-System-Programming/In-Situ-Programming) , it will be super helpful! I teardown a bricked laptop, removed AC power, laptop's power battery, and even a small CMOS battery, and now I am trying to write a working BIOS image to laptop's SPI flash chip using a SOIC8 test clip. But here is a problem: I could read a dump from this BIOS chip without problems, however it fails when I am trying to write - so the contents of BIOS flash chip are remaining unchanged. Luckily I found out this helpful wiki page - http://flashrom.org/ISP , which describes common problems with this ISP method of flashing, as well as gives 3 hints for solution! Sadly this page is currently down, so here is a screenshot: http://i.imgur.com/SJEYHR2.png 1. - tried to make shorter wires, less than 10cm as they recommend - it did not help 2. - soldering is out of possibility, cant do it, and also: wires are already short and they are good quality (pure copper) 3. - This hint looks more promising, but I need help in understanding this piece of information: "disconnect Vcc from the programmer and power it with its normal PSU" If I understand correctly, by Vcc they mean Vcc pin of the BIOS flash chip. But if I disconnect Vcc from the programmer, what is "normal PSU" which should power this Vcc pin? Should I connect to motherboard a laptop's power battery, or small CMOS battery, or AC adapter of laptop, so that this Vcc pin would be powered by them, or it is forbidden to do it while using SPI programmer in the same time? Or its better to try to power Vcc of flash chip from "USB to TTL" adapter - which has this 3V3 (3.3V) voltage pin? Yours faithfully, Robert Brown -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.lisovoy at yandex.ru Sat Oct 17 16:10:14 2015 From: igor.lisovoy at yandex.ru (=?koi8-r?B?7MnTz9fPyiDpx8/S2A==?=) Date: Sat, 17 Oct 2015 17:10:14 +0300 Subject: [flashrom] Asus M2N-MX/DVI2 Message-ID: <1264951445091014@web13o.yandex.ru> An HTML attachment was scrubbed... URL: From contact at paulk.fr Sun Oct 18 19:37:35 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sun, 18 Oct 2015 19:37:35 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <561EB048.9060604@gmx.de> <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> Message-ID: <1445189855.3397.4.camel@paulk.fr> Hi, Le vendredi 16 octobre 2015 ? 04:25 +0200, Stefan Tauner a ?crit : > On Wed, 14 Oct 2015 21:43:04 +0200 > Nico Huber wrote: > > > On 10.10.2015 16:20, Paul Kocialkowski wrote: > > > Some chips such as the ENE KB9012 internal flash require a write > > > granularity of > > > 128 bytes. > > > > > > Signed-off-by: Paul Kocialkowski > > clean patch, +2 > > I've understood that as an acked-by... ;) > Thanks to both of you. > Committed in r1897. Great, thanks a lot Nico for reviewing this and Stefan for merging it! I noticed that you have reworded the commit message: I usually do not use conjugated verbs in commit headline. Does this conflict with flashrom's guidelines? It looks a bit strange to me to have my commit worded in a way that really does not match what I naturally do! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: https://www.replicant.us/ Blog: https://blog.replicant.us/ Wiki/tracker/forums: https://redmine.replicant.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From c-d.hailfinger.devel.2006 at gmx.net Sun Oct 18 20:58:34 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sun, 18 Oct 2015 20:58:34 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <1445189855.3397.4.camel@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <561EB048.9060604@gmx.de> <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> <1445189855.3397.4.camel@paulk.fr> Message-ID: <5623EBDA.7000706@gmx.net> Hi Paul, On 18.10.2015 19:37, Paul Kocialkowski wrote: > I noticed that you have reworded the commit message: I usually do not > use conjugated verbs in commit headline. Does this conflict with > flashrom's guidelines? No formal guidelines, but "128 bytes write granularity support" is missing a crucial piece of information: Was this a bugfix, a new feature or something you removed? The reworded commit message has that info. > It looks a bit strange to me to have my commit worded in a way that > really does not match what I naturally do! Regards, Carl-Daniel From arpita.biswas07 at gmail.com Tue Oct 20 21:26:37 2015 From: arpita.biswas07 at gmail.com (Arpita Biswas) Date: Tue, 20 Oct 2015 12:26:37 -0700 Subject: [flashrom] Trying to flash coreboot onto on-board SPI chip of HP Envy H87 haswell chipset. Message-ID: Hi all, I am trying to update BIOS with coreboot onto HP Envy H87 haswell chipset (ipm87_mp) . I am using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64). However dediprog doesn't detect the chip when it's soldered on-board. On removing the chip from board, I can detect/read/write onto it without any issues. I've tried (and failed) with the following configurations : (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2) ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) ---> 3.3V, VCC ---> 3.3V with motherboard power ON. (2) Same config as above but I tried to isolate the chip by removing CMOS battery + removing jumper on SPI header + powering OFF the motherboard. (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float. (4) I tried using flashrom on the box too as internal programmer, but it did not recognize the SPI chip. Error log says "Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific)." I've a feeling that something on the motherboard is interfering with the SPI chip since an off-board chip is working fine. Does anybody have any pointers on what could be going wrong ? Thanks in advance, - Arpita -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhendrix at google.com Tue Oct 20 23:05:16 2015 From: dhendrix at google.com (David Hendricks) Date: Tue, 20 Oct 2015 14:05:16 -0700 Subject: [flashrom] [coreboot] Trying to flash coreboot onto on-board SPI chip of HP Envy H87 haswell chipset. In-Reply-To: References: Message-ID: On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas wrote: > Hi all, > > I am trying to update BIOS with coreboot onto HP Envy H87 haswell chipset > (ipm87_mp) > . I am > using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64). > However dediprog doesn't detect the chip when it's soldered on-board. On > removing the chip from board, I can detect/read/write onto it without any > issues. > > I've tried (and failed) with the following configurations : > (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2) > ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) ---> > 3.3V, VCC ---> 3.3V with motherboard power ON. > > (2) Same config as above but I tried to isolate the chip by removing CMOS > battery + removing jumper on SPI header + powering OFF the motherboard. > > (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float. > > (4) I tried using flashrom on the box too as internal programmer, but it > did not recognize the SPI chip. Error log says "Found Programmer flash chip > "Opaque flash chip" (8192 kB, Programmer-specific)." > > I've a feeling that something on the motherboard is interfering with the > SPI chip since an off-board chip is working fine. Does anybody have any > pointers on what could be going wrong ? > I suspect your motherboard does not isolate the SPI ROM's voltage supply and thus your Dediprog is effectively powering other components on the board. If you can find a way to hold the PCH and ME in reset while the board is powered on, that might work. Or, with the board off, you can try using an external power supply (the usual warnings about possibly frying your board apply). > > Thanks in advance, > - Arpita > > -- > coreboot mailing list: coreboot at coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From c-d.hailfinger.devel.2006 at gmx.net Tue Oct 20 23:20:56 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Tue, 20 Oct 2015 23:20:56 +0200 Subject: [flashrom] FOSDEM deadlines now! Message-ID: <5626B038.80901@gmx.net> Hi, we obviously want to participate in FOSDEM. https://fosdem.org/2016/news/2015-09-24-call-for-participation/ ACT NOW! Some deadlines already expired. Some can still be managed. Main track talks: Deadline 2015-10-30 (10 days left) One hour of entertainment, huge audience. Anyone up for the challenge? Stands: Deadline 2015-11-13 (24 days left) I can send in the proposal if I'm not going to be alone there. How many tables do we want for our stand/booth(s)? Who is coming? Lightning talks: Deadline 2015-11-27 (38 days left) Short and to the point. Your 15-minute elevator pitch. Can you sell the project? All deadlines are at 23.59 UTC Developer room proposal: Deadline EXPIRED Maybe some developer room will accept talks/demos from us. Regards, Carl-Daniel From arpita.biswas07 at gmail.com Wed Oct 21 01:51:15 2015 From: arpita.biswas07 at gmail.com (Arpita Biswas) Date: Tue, 20 Oct 2015 16:51:15 -0700 Subject: [flashrom] [coreboot] Trying to flash coreboot onto on-board SPI chip of HP Envy H87 haswell chipset. In-Reply-To: References: Message-ID: Hi David, That did the trick !!! Thanks a bunch ! For anyone else interested, here is the combination of things I did : SOIC config as (1) mentioned earlier + held down the power button for 30 sec to reset it + removed CMOS battery + removed jumper on SPI header (that cuts off the processor signal to SPI chip) + plugged in the power cable (that way enough power was there throughout the board for dediprog to detect) + removed the DIM (dunno if that made any difference, but did it since a post mentioned it anyways!). Dediprog then detected it sweetly :) :) Cheers, - Arpita On Tue, Oct 20, 2015 at 2:05 PM, David Hendricks wrote: > > > On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas > wrote: > >> Hi all, >> >> I am trying to update BIOS with coreboot onto HP Envy H87 haswell >> chipset (ipm87_mp) >> . I am >> using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64). >> However dediprog doesn't detect the chip when it's soldered on-board. On >> removing the chip from board, I can detect/read/write onto it without any >> issues. >> >> I've tried (and failed) with the following configurations : >> (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP (IO2) >> ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD (IO3) ---> >> 3.3V, VCC ---> 3.3V with motherboard power ON. >> >> (2) Same config as above but I tried to isolate the chip by removing CMOS >> battery + removing jumper on SPI header + powering OFF the motherboard. >> >> (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float. >> >> (4) I tried using flashrom on the box too as internal programmer, but it >> did not recognize the SPI chip. Error log says "Found Programmer flash chip >> "Opaque flash chip" (8192 kB, Programmer-specific)." >> >> I've a feeling that something on the motherboard is interfering with the >> SPI chip since an off-board chip is working fine. Does anybody have any >> pointers on what could be going wrong ? >> > > I suspect your motherboard does not isolate the SPI ROM's voltage supply > and thus your Dediprog is effectively powering other components on the > board. > > If you can find a way to hold the PCH and ME in reset while the board is > powered on, that might work. Or, with the board off, you can try using an > external power supply (the usual warnings about possibly frying your board > apply). > > > >> >> Thanks in advance, >> - Arpita >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot >> > > > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhendrix at google.com Wed Oct 21 01:58:58 2015 From: dhendrix at google.com (David Hendricks) Date: Tue, 20 Oct 2015 16:58:58 -0700 Subject: [flashrom] [coreboot] Trying to flash coreboot onto on-board SPI chip of HP Envy H87 haswell chipset. In-Reply-To: References: Message-ID: Cool, glad it worked! To make things slightly easier, you should also try keeping the CMOS battery and DIM (whatever that is) in. On Tue, Oct 20, 2015 at 4:51 PM, Arpita Biswas wrote: > Hi David, > > That did the trick !!! Thanks a bunch ! For anyone else interested, here > is the combination of things I did : > > SOIC config as (1) mentioned earlier + held down the power button for 30 > sec to reset it + removed CMOS battery + removed jumper on SPI header (that > cuts off the processor signal to SPI chip) + plugged in the power cable > (that way enough power was there throughout the board for dediprog to > detect) + removed the DIM (dunno if that made any difference, but did it > since a post mentioned it anyways!). > > Dediprog then detected it sweetly :) :) > > Cheers, > - Arpita > > On Tue, Oct 20, 2015 at 2:05 PM, David Hendricks > wrote: > >> >> >> On Tue, Oct 20, 2015 at 12:26 PM, Arpita Biswas < >> arpita.biswas07 at gmail.com> wrote: >> >>> Hi all, >>> >>> I am trying to update BIOS with coreboot onto HP Envy H87 haswell >>> chipset (ipm87_mp) >>> . I am >>> using Dediprog + SOIC 8-pin flash clip for flashing the SPI chip (W25Q64). >>> However dediprog doesn't detect the chip when it's soldered on-board. On >>> removing the chip from board, I can detect/read/write onto it without any >>> issues. >>> >>> I've tried (and failed) with the following configurations : >>> (1) SPI pin ------> Dediprog : /CS ---> CS, DO (IO1) ---> MISO, /WP >>> (IO2) ---> 3.3V, GND ---> GND, DI (IO0) ---> MOSI, CLK ---> CLK, /HOLD >>> (IO3) ---> 3.3V, VCC ---> 3.3V with motherboard power ON. >>> >>> (2) Same config as above but I tried to isolate the chip by removing >>> CMOS battery + removing jumper on SPI header + powering OFF the motherboard. >>> >>> (3) Similar as (1) and (2), but let /HOLD, /Vcc and /WP float. >>> >>> (4) I tried using flashrom on the box too as internal programmer, but it >>> did not recognize the SPI chip. Error log says "Found Programmer flash chip >>> "Opaque flash chip" (8192 kB, Programmer-specific)." >>> >>> I've a feeling that something on the motherboard is interfering with the >>> SPI chip since an off-board chip is working fine. Does anybody have any >>> pointers on what could be going wrong ? >>> >> >> I suspect your motherboard does not isolate the SPI ROM's voltage supply >> and thus your Dediprog is effectively powering other components on the >> board. >> >> If you can find a way to hold the PCH and ME in reset while the board is >> powered on, that might work. Or, with the board off, you can try using an >> external power supply (the usual warnings about possibly frying your board >> apply). >> >> >> >>> >>> Thanks in advance, >>> - Arpita >>> >>> -- >>> coreboot mailing list: coreboot at coreboot.org >>> http://www.coreboot.org/mailman/listinfo/coreboot >>> >> >> >> >> -- >> David Hendricks (dhendrix) >> Systems Software Engineer, Google Inc. >> > > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark.Rowlinson at uk.fujitsu.com Wed Oct 21 16:18:45 2015 From: Mark.Rowlinson at uk.fujitsu.com (Rowlinson Mark) Date: Wed, 21 Oct 2015 15:18:45 +0100 Subject: [flashrom] Flash chip/chipset not found Message-ID: Hi, I have a 32bit touch screen device running CentOS 5.2 which has some of its BIOS settings accessible in /dev/nvram and others elsewhere else (that's why I've been loooking at flashrom). I have tried later distributions (CentOS 6.7 and the System Rescue CD) and they both report the following: [root at server ~]# /var/tmp/flashrom-0.9.8/flashrom -p internal flashrom v0.9.8-r1888 on Linux 2.6.32-573.el6.i686 (i686) flashrom is free software, get the source code at http://www.flashrom.org Calibrating delay loop... OK. WARNING: No chipset found. Flash detection will most likely fail. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. [root at server ~]# What information is needed to identify the chipset in use so support can be added for these devices? Best Regards, Mark Rowlinson Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu". This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free. Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW. Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW. PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE. Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From GNUtoo at no-log.org Thu Oct 22 00:24:06 2015 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Thu, 22 Oct 2015 00:24:06 +0200 Subject: [flashrom] SOIC8 test clip - cant write to BIOS SPI flash chip In-Reply-To: <562229B2.50706@gmx.de> References: <9A95527C47DC43CB81C8C0295B948A1C@mail2world.com> <562229B2.50706@gmx.de> Message-ID: <20151022002406.2fcea0dd@top-laptop> On Sat, 17 Oct 2015 12:57:54 +0200 Nico Huber wrote: > 2. The write protection pin of your flash chip is asserted. That's what I suspect too, but it could also be some other sort of write protections. Some chip do support more flexible ways of write protecting the chip, that's for instance used in the chromebook where, if I understand correctly, only a region of the chip is protected (like 2MB/16MB for instance). I should check the datasheet mentioned previously. I'll look briefly if the issue is not resolved. Robert, since the laptop is bricked anyway and that you already have backups of the flash, you could try to erase the chip with "flashrom --erase" and then dump the content of the chip again. That way you could more easily see which zones have been erased, and which haven't. Also please attach the log next time. Also, I'm not used to all the issues related to powering the laptop on or not, I never took the time to look that up. Do you have a multimeter to investigate such issues? If so you could check the voltages at the chip pins (to verify if any drop is occurring), you could also check the value of pins like WP# (write protect). On Sat, 17 Oct 2015 12:57:54 +0200 Nico Huber wrote: > I'd try with the AC adapter. In that case Vcc must _not_ be connected > to your programmer. GND, OTOH, has to stay connected. If that happens, could the EC be destroyed? or the laptop power system? I've a laptop that doesn't lit its leds once a power supply is connected to it. I broke it while messing with reflashing after trying to test ME related stuff on it. On Sat, 17 Oct 2015 12:57:54 +0200 Nico Huber wrote: > > so that this Vcc pin would be powered by them, or it is forbidden > > to do it while using SPI programmer in the same time? > Not forbidden. It's sometimes even encouraged because there are boards > where the Vcc pin of the flash chip is directly connected to other > chips, which would draw down the power from the programmer. Robert, I think it can be detected by measuring the voltage at the pins of the SPI programmer before and after plugging the clip. Nico, Are there other common issues of the same kind with laptops? Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From c-d.hailfinger.devel.2006 at gmx.net Thu Oct 22 08:07:02 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 22 Oct 2015 08:07:02 +0200 Subject: [flashrom] Flash chip/chipset not found In-Reply-To: References: Message-ID: <56287D06.3080707@gmx.net> Hi Mark, On 21.10.2015 16:18, Rowlinson Mark wrote: > I have a 32bit touch screen device running CentOS 5.2 which has some of its BIOS settings accessible in /dev/nvram and others elsewhere else (that's why I've been loooking at flashrom). > I have tried later distributions (CentOS 6.7 and the System Rescue CD) and they both report the following: > [root at server ~]# /var/tmp/flashrom-0.9.8/flashrom -p internal > flashrom v0.9.8-r1888 on Linux 2.6.32-573.el6.i686 (i686) > [...] > WARNING: No chipset found. Flash detection will most likely fail. > No EEPROM/flash device found. It seems we have to add some PCI IDs to our southbridge table. Do you have an exact name of the machine in question? > What information is needed to identify the chipset in use so support can be added for these devices? (as root) lspci -nnvvvxxx That should be sufficient for us to find out the southbridge and some of its settings. Regards, Carl-Daniel From contact at paulk.fr Thu Oct 22 09:04:57 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Thu, 22 Oct 2015 09:04:57 +0200 Subject: [flashrom] [PATCH 2/3] Flag-driven erased bit value In-Reply-To: <561EB407.9070004@gmx.de> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <1444486821-10619-2-git-send-email-contact@paulk.fr> <561EB407.9070004@gmx.de> Message-ID: <1445497497.1363.9.camel@paulk.fr> Hi Nico, Le mercredi 14 octobre 2015 ? 21:59 +0200, Nico Huber a ?crit : > On 10.10.2015 16:20, Paul Kocialkowski wrote: > > Most flash chips are erased to ones and programmed to zeros. > > However, some other > > flash chips, such as the ENE KB9012 internal flash, work the > > opposite way. > > > > Signed-off-by: Paul Kocialkowski > Looks good, some comments below. Thanks for the review Nico, I'll submit v2 of this patch with your comments in mind. > > --- > > flash.h | 3 ++- > > flashrom.c | 42 ++++++++++++++++++++++-------------------- > > 2 files changed, 24 insertions(+), 21 deletions(-) > > > > diff --git a/flash.h b/flash.h > > index 24861ba..3d14d56 100644 > > --- a/flash.h > > +++ b/flash.h > > @@ -123,6 +123,7 @@ enum write_granularity { > > #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | > > FEATURE_WRSR_WREN) > > #define FEATURE_OTP (1 << 8) > > #define FEATURE_QPI (1 << 9) > > +#define FEATURE_ERASED_ZERO (1 << 10) > > > > enum test_state { > > OK = 0, > > @@ -275,7 +276,7 @@ int probe_flash(struct registered_master *mst, > > int startchip, struct flashctx *f > > int read_flash_to_file(struct flashctx *flash, const char > > *filename); > > char *extract_param(const char *const *haystack, const char > > *needle, const char *delim); > > int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, > > unsigned int start, unsigned int len); > > -int need_erase(const uint8_t *have, const uint8_t *want, unsigned > > int len, enum write_granularity gran); > > +int need_erase(const uint8_t *have, const uint8_t *want, unsigned > > int len, enum write_granularity gran, uint8_t erased); > When reading `erased` I though it sounds like a boolean. Maybe call > it > `erased_value`? Good point. > > void print_version(void); > > void print_buildinfo(void); > > void print_banner(void); > > diff --git a/flashrom.c b/flashrom.c > > index c9c7e31..e463a18 100644 > > --- a/flashrom.c > > +++ b/flashrom.c > > @@ -669,7 +669,7 @@ static int compare_range(const uint8_t > > *wantbuf, const uint8_t *havebuf, unsigne > > > > /* start is an offset to the base address of the flash chip */ > > int check_erased_range(struct flashctx *flash, unsigned int start, > > - unsigned int len) > > + unsigned int len, uint8_t erased) > There's already `struct flashctx *` in the signature, doesn't that > have > the information this time, already? It does indeed, and I agree we'd better not pass extra arguments when those can be figured out from what we already have. Having a macro for erased_value will help. > [...] > > > @@ -1424,6 +1424,7 @@ static int > > erase_and_write_block_helper(struct flashctx *flash, > > unsigned int starthere = 0, lenhere = 0; > > int ret = 0, skip = 1, writecount = 0; > > enum write_granularity gran = flash->chip->gran; > > + uint8_t erased = (flash->chip->feature_bits & > > FEATURE_ERASED_ZERO) ? 0x00 : 0xff; > You could make the transformation a macro or inline function, that > would > save you from writing it out in full again. Also, as this variable > never > changes later, it could be declared `const`. Hmmm, that also applies > to > the added parameters. Agreed, I will make those changes, probably with a macro. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: https://www.replicant.us/ Blog: https://blog.replicant.us/ Wiki/tracker/forums: https://redmine.replicant.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From contact at paulk.fr Thu Oct 22 08:58:53 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Thu, 22 Oct 2015 08:58:53 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <5623EBDA.7000706@gmx.net> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <561EB048.9060604@gmx.de> <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> <1445189855.3397.4.camel@paulk.fr> <5623EBDA.7000706@gmx.net> Message-ID: <1445497133.1363.4.camel@paulk.fr> Hi Carl-Daniel, Le dimanche 18 octobre 2015 ? 20:58 +0200, Carl-Daniel Hailfinger a ?crit : > On 18.10.2015 19:37, Paul Kocialkowski wrote: > > I noticed that you have reworded the commit message: I usually do > > not > use conjugated verbs in commit headline. Does this conflict > > with > > flashrom's guidelines? > > No formal guidelines, but "128 bytes write granularity support" is > missing a crucial piece of information: Was this a bugfix, a new > feature > or something you removed? > The reworded commit message has that info. Well, it does end with "support", which indicates that support for this was introduced, so I don't think it was confusing. I really see commit headlines as titles, not active phrases and would like to keep my commits phrased this way. Please let me know during patch review next time you find the commit headline not precise enough. Thanks! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: https://www.replicant.us/ Blog: https://blog.replicant.us/ Wiki/tracker/forums: https://redmine.replicant.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From clg at fr.ibm.com Thu Oct 22 11:21:10 2015 From: clg at fr.ibm.com (=?UTF-8?q?C=C3=A9dric=20Le=20Goater?=) Date: Thu, 22 Oct 2015 11:21:10 +0200 Subject: [flashrom] [RFC PATCH] add support for N25Q256 Message-ID: <1445505670-17404-1-git-send-email-clg@fr.ibm.com> I needed to reflash a N25Q256 on a host system and hacked flashrom to make this work. For this, I used the 4-Bytes address support developed by Boris Baykov. This is why the patch is an RFC. The whole patchset is available under github here: https://github.com/legoater/flashrom I can help in getting this patchset merged but do the comments in : http://patchwork.coreboot.org/patch/4272/ need to be all addressed or can we rework a bit the patchset to merge the main changes separately : - 4-bytes addressing - W25Q256.V support - SFDP - Progress visualization - ... Tested under Linux with spidev. Signed-off-by: C?dric Le Goater --- flashchips.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) Index: flashrom.git/flashchips.c =================================================================== --- flashrom.git.orig/flashchips.c +++ flashrom.git/flashchips.c @@ -9330,6 +9330,48 @@ const struct flashchip flashchips[] = { }, { + .vendor = "Micron/Numonyx/ST", + .name = "N25Q256..3E", /* ..3E = 3V, uniform 64KB/4KB blocks/sectors */ + .bustype = BUS_SPI, + .manufacture_id = ST_ID, + .model_id = ST_N25Q256__3E, + .total_size = 32768, + .page_size = 256, + /* supports SFDP */ + /* OTP: 64B total; read 0x4B, write 0x42 */ + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI + | FEATURE_4BA_SUPPORT, + .four_bytes_addr_funcs = + { + .enter_4ba = spi_enter_4ba_b7_we, /* enter 4-bytes addressing mode by CMD B7 + WREN */ + .read_nbyte = spi_nbyte_read_4ba_direct, /* read directly from any mode, no need to enter 4ba */ + .program_byte = spi_byte_program_4ba, /* write from 4-bytes addressing mode */ + .program_nbyte = spi_nbyte_program_4ba /* write from 4-bytes addressing mode */ + }, + .tested = TEST_OK_PREW, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 8192 } }, + .block_erase = spi_block_erase_20_4ba, + }, { + .eraseblocks = { {64 * 1024, 512} }, + .block_erase = spi_block_erase_d8_4ba, + }, { + .eraseblocks = { {32 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + .printlock = spi_prettyprint_status_register_n25q, /* TODO: config, lock, flag regs */ + .unlock = spi_disable_blockprotect_n25q, /* TODO: per 64kB sector lock registers */ + .write = spi_chip_write_256, /* Multi I/O supported */ + .read = spi_chip_read, /* Fast read (0x0B) and multi I/O supported */ + .voltage = {2700, 3600}, + }, + + { .vendor = "MoselVitelic", .name = "V29C51000B", .bustype = BUS_PARALLEL, From stefan.tauner at alumni.tuwien.ac.at Thu Oct 22 22:05:00 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Thu, 22 Oct 2015 22:05:00 +0200 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <1445497133.1363.4.camel@paulk.fr> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <561EB048.9060604@gmx.de> <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> <1445189855.3397.4.camel@paulk.fr> <5623EBDA.7000706@gmx.net> <1445497133.1363.4.camel@paulk.fr> Message-ID: <201510222005.t9MK50Rs012698@mail2.student.tuwien.ac.at> On Thu, 22 Oct 2015 08:58:53 +0200 Paul Kocialkowski wrote: > Hi Carl-Daniel, > > Le dimanche 18 octobre 2015 ? 20:58 +0200, Carl-Daniel Hailfinger a > ?crit : > > On 18.10.2015 19:37, Paul Kocialkowski wrote: > > > I noticed that you have reworded the commit message: I usually do > > > not > use conjugated verbs in commit headline. Does this conflict > > > with > > > flashrom's guidelines? > > > > No formal guidelines, but "128 bytes write granularity support" is > > missing a crucial piece of information: Was this a bugfix, a new > > feature > > or something you removed? > > The reworded commit message has that info. > > Well, it does end with "support", which indicates that support for this > was introduced, so I don't think it was confusing. > > I really see commit headlines as titles, not active phrases and would > like to keep my commits phrased this way. > > Please let me know during patch review next time you find the commit > headline not precise enough. Hello Paul, I have not replied yet because Carl-Daniel's message described the thoughts I had/have when changing commit logs pretty much exactly. Your approach on commit logs (seeing the first line as the "subject") is IMHO a defensible argument. After all, that's how git calls it as well in many places. However, using imperative sentences is much more common and IMHO it is better. I see every commit as an entity that changes our code base... so it always *does* something and often it is interesting what the most descriptive verb is for what it is doing (e.g. add, fix, improve, refactor, ...) to better understand what the change is about. Just like Carl-Daniel explained for the commit in question. I can not be sure that if we someone looks at the commit in three years he will remember or even know that 128 byte granularity was introduced about the time this commit happened. It is much easier to understand a commit if the subject contains a verb that makes the action clear. Also, let's suppose we would have to revert a commit because it was really a bad idea to commit it in the first place and we can not fix it easily. The normal commit message would be ?Revert "128 bytes write granularity support"? in your case vs. ?Revert "Add support for 128 bytes write granularity.? in the imperative case. The issue with the subject without a verb is similar to the original. In the second case it is completely clear that the support was removed again. Without a verb it could be a fix that is reverted, an improvement, or even the revert of removing the support... it is simply not explicit enough IMHO. Others have written about the subject as well, but I can not find a lot of texts explaining the WHY very good... this is one example: http://chris.beams.io/posts/git-commit/#imperative Your other patches are affected as well and I intend to rephrase them as I see fit. I hope you understand/agree now... if not I'll have another argument: the maintainers have to maintain the codebase and are the ones who read commit messages the most, hence it should be the decision of the maintainers what's written in commit messages because they are affected most by them. The submitter can simply dump the code and hope it gets merged but apart from seeing some mails with the subject during communication it does not affect his work on the project later (because there often is none... otherwise he is not merely a submitter). -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From Mark.Rowlinson at uk.fujitsu.com Thu Oct 22 22:24:13 2015 From: Mark.Rowlinson at uk.fujitsu.com (Rowlinson Mark) Date: Thu, 22 Oct 2015 21:24:13 +0100 Subject: [flashrom] Flash chip/chipset not found In-Reply-To: <56287D06.3080707@gmx.net> References: <56287D06.3080707@gmx.net> Message-ID: Hi Carl-Daniel, Thanks for the swift response, I have attached output from the command requested. The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. Best Regards, Mark Rowlinson -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] Sent: 22 October 2015 07:07 To: Rowlinson Mark ; flashrom at flashrom.org Subject: Re: [flashrom] Flash chip/chipset not found Hi Mark, On 21.10.2015 16:18, Rowlinson Mark wrote: > I have a 32bit touch screen device running CentOS 5.2 which has some of its BIOS settings accessible in /dev/nvram and others elsewhere else (that's why I've been loooking at flashrom). > I have tried later distributions (CentOS 6.7 and the System Rescue CD) and they both report the following: > [root at server ~]# /var/tmp/flashrom-0.9.8/flashrom -p internal flashrom > v0.9.8-r1888 on Linux 2.6.32-573.el6.i686 (i686) [...] > WARNING: No chipset found. Flash detection will most likely fail. > No EEPROM/flash device found. It seems we have to add some PCI IDs to our southbridge table. Do you have an exact name of the machine in question? > What information is needed to identify the chipset in use so support can be added for these devices? (as root) lspci -nnvvvxxx That should be sufficient for us to find out the southbridge and some of its settings. Regards, Carl-Daniel Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu". This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free. Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW. Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW. PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE. Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU. -------------- next part -------------- A non-text attachment was scrubbed... Name: lspci-nnvvvxxx.log Type: application/octet-stream Size: 40375 bytes Desc: lspci-nnvvvxxx.log URL: From c-d.hailfinger.devel.2006 at gmx.net Sat Oct 24 10:22:28 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Sat, 24 Oct 2015 10:22:28 +0200 Subject: [flashrom] Flash chip/chipset not found In-Reply-To: References: <56287D06.3080707@gmx.net> Message-ID: <562B3FC4.9000808@gmx.net> Hi Mark, this is a VIA VT8251 PCI to ISA Bridge you're using. I think Stefan Tauner (in CC) already was discussing something similar here: http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html That email even has a patch attached. On 22.10.2015 22:24, Rowlinson Mark wrote: > Thanks for the swift response, I have attached output from the command requested. > > The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. Heh, would be fun to add this to our tests. Regards, Carl-Daniel From contact at paulk.fr Sat Oct 24 13:19:58 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 24 Oct 2015 13:19:58 +0200 Subject: [flashrom] [PATCH 3/3] ENE Embedded Debug Interface (EDI) and ENE KB9012 EC internal flash support In-Reply-To: <561ECB7A.10407@gmx.de> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <1444486821-10619-3-git-send-email-contact@paulk.fr> <561ECB7A.10407@gmx.de> Message-ID: <1445685598.2022.4.camel@paulk.fr> Hi Nico, Le mercredi 14 octobre 2015 ? 23:39 +0200, Nico Huber a ?crit : > On 10.10.2015 16:20, Paul Kocialkowski wrote: > > The ENE Embedded Debug Interface (EDI) is a SPI-based interface for > > accessing > > the memory of ENE embedded controllers. > > > > The ENE KB9012 EC is an embedded controller found on various > > laptops such as > > the Lenovo G505s. It features a 8051 microcontroller and has 128 > > KiB of internal > > storage for program data. > > > > EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI > > -MISO) when > > flash direct access is not in use. Some firmwares disable EDI at > > run-time, so > > it might be necessary to ground pin 42 to reset the 8051 > > microcontroller before > > accessing the KB9012 via EDI. > > > > Signed-off-by: Paul Kocialkowski > Thank you for taking the time to write a clean implementation. I had > a > good time reading it and learning about that EDI protocol :) > I don't know the hardware, so I've only commented on general stuff. Thanks for reviewing this! The EDI protocol is described in the KB9012 datasheet, application apendix A.5 Embedded Flash Brief Description and the internal SPI controller in part 4.14 X-Bus Interface (XBI). > It looks good on the easy to test, positive paths. Failure handling > OTOH needs more work. I will probably send v2 right away, feel free to follow up the discussion on some of these comments in there, it'll probably be easier. > Nico > > > --- > > Makefile | 2 +- > > chipdrivers.h | 6 + > > edi.c | 418 > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > edi.h | 34 +++++ > > ene.h | 55 ++++++++ > > flashchips.c | 23 ++++ > > 6 files changed, 537 insertions(+), 1 deletion(-) > > create mode 100644 edi.c > > create mode 100644 edi.h > > create mode 100644 ene.h > > > > diff --git a/Makefile b/Makefile > > index c439d8d..661c52a 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -368,7 +368,7 @@ endif > > > > CHIP_OBJS = jedec.o stm50.o w39.o w29ee011.o \ > > sst28sf040.o 82802ab.o \ > > - sst49lfxxxc.o sst_fwhub.o flashchips.o spi.o spi25.o > > spi25_statusreg.o \ > > + sst49lfxxxc.o sst_fwhub.o edi.o flashchips.o spi.o spi25.o > > spi25_statusreg.o \ > > opaque.o sfdp.o en29lv640b.o at45db.o > > > > ################################################################## > > ############# > > diff --git a/chipdrivers.h b/chipdrivers.h > > index cac94f3..8015b52 100644 > > --- a/chipdrivers.h > > +++ b/chipdrivers.h > > @@ -194,4 +194,10 @@ int erase_sector_stm50(struct flashctx *flash, > > unsigned int block, unsigned int > > int probe_en29lv640b(struct flashctx *flash); > > int write_en29lv640b(struct flashctx *flash, const uint8_t *buf, > > unsigned int start, unsigned int len); > > > > +/* edi.c */ > > +int edi_chip_block_erase(struct flashctx *flash, unsigned int > > page, unsigned int size); > > +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, > > unsigned int start, unsigned int len); > > +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned > > int start, unsigned int len); > > +int edi_probe_kb9012(struct flashctx *flash); > > + > > #endif /* !__CHIPDRIVERS_H__ */ > > diff --git a/edi.c b/edi.c > > new file mode 100644 > > index 0000000..a3e0539 > > --- /dev/null > > +++ b/edi.c > > @@ -0,0 +1,418 @@ > > +/* > > + * This file is part of the flashrom project. > > + * > > + * Copyright (C) 2015 Paul Kocialkowski > > + * > > + * This program is free software; you can redistribute it and/or > > modify > > + * it under the terms of the GNU General Public License as > > published by > > + * the Free Software Foundation; either version 2 of the License, > > or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public > > License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > > 02110-1301 USA > Please drop that last paragraph from all new files. FSF's address > used > to change and might again. Right, perhaps it would be worth fixing this for each flashrom file, too. > > + */ > > + > > +#include > > +#include "flash.h" > > +#include "ene.h" > > +#include "edi.h" > > + > > +static unsigned int edi_read_buffer_length = > > EDI_READ_BUFFER_LENGTH_DEFAULT; > > + > > +static struct ene_chip ene_kb9012 = { > > + .hwversion = ENE_KB9012_HWVERSION, > > + .ediid = ENE_KB9012_EDIID, > > +}; > Could be `const` from what I've seen. Correct. > > + > > +static void edi_write_cmd(unsigned char *cmd, unsigned short > > address, unsigned char data) > > +{ > > + cmd[0] = EDI_WRITE; /* EDI write command. */ > > + cmd[1] = 0x00; /* Address is only 2 bytes. */ > > + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ > > + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ > > + cmd[4] = data; /* Write data. */ > > +} > > + > > +static void edi_read_cmd(unsigned char *cmd, unsigned short > > address) > > +{ > > + cmd[0] = EDI_READ; /* EDI read command. */ > > + cmd[1] = 0x00; /* Address is only 2 bytes. */ > > + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ > > + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ > > +} > > + > > +static int edi_write(struct flashctx *flash, unsigned short > > address, unsigned char data) > > +{ > > + unsigned char cmd[5] = { 0 }; > edi_write_cmd() below already fully initializes `cmd`. Right, but I see that as a good programming habit, initializing memory that will be filled by another function, because we might be using a buffer larger than what the function will fill, etc. Of course here, it's so simple that it's 100% safe to remove the initialization, but I don't think it's a problem to keep it. > > + int rc; > > + > > + edi_write_cmd((unsigned char *)cmd, address, data); > > + > > + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned > > char *)cmd, NULL); > I don't see a reason to cast `cmd`. But maybe it's just my C. That's true, it's not required at all. > Also you could just return spi_send_command(...)... I prefer to always have a rc variable and check the return code explicitly. Actually, I prefer to use known return codes for my local (static) functions and not return the return code of the function causing the error. This is not what I did in this patch and I'll correct this. This is simply my coding style and while there are some minor advantages (moving code blocks around more easily, only bothering once about what those functions return as good return code) and disadvantages (longer code, very redundant), I'd like to keep things this way unless there is an explicit policy in flashrom not to do this. Also, I very much dislike checking functions' return codes with inline calls in conditional statements or when returning, it simply looks somewhat ugly to me, unless the function returns a boolean value. > > + if (rc) > > + return rc; > > + > > + return 0; > ... or return rc unconditionally. It looks very weird that way. See above. > > +} > > + > > +static int edi_read(struct flashctx *flash, unsigned short > > address, unsigned char *data) > > +{ > > + unsigned char cmd[4] = { 0 }; > Again, `cmd` gets fully initialized later. See above. > > + unsigned char buffer[edi_read_buffer_length]; > > + unsigned int i; > > + int rc; > > + > > + edi_read_cmd((unsigned char *)cmd, address); > > + > > + memset(buffer, 0, sizeof(buffer)); > Why? Same thing here, spi_send_command *should* fill-in the whole buffer, but in case it doesn't, I'd rather have known values instead, just in case garbage turns out to take one of EDI_READY or EDI_NOT_READY. This is probably not a hard requirement either, but seems like a good programming habit to produce reliable code to me. > > + > > + rc = spi_send_command(flash, sizeof(cmd), sizeof(buffer), > > (unsigned char *)cmd, (unsigned char *)buffer); > Maybe unnecessary casts. > > > + if (rc) > > + return rc; > > + > > + for (i = 0; i < sizeof(buffer); i++) { > > + if (buffer[i] == EDI_NOT_READY) > > + continue; > > + > > + if (buffer[i] == EDI_READY) { > > + if (i == (sizeof(buffer) - 1)) { > > + /* > > + * Buffer size was too small for > > receiving the value. > > + * This is as good as getting only > > EDI_NOT_READY. > > + */ > > + > > + buffer[i] = EDI_NOT_READY; > > + break; > If you break here, `i` won't get increased and `buffer[i]` is never > read. Well spotted, I missed that one. Of course, I need to increase i here. I'll probably go with another variable "index" that keeps that last value of i seen in the loop, since increasing i before breaking looks too artificial to really be straightforward. > > + } > > + > > + *data = buffer[i + 1]; > > + return 0; > > + } > So you're ignoring everything but EDI_READY and EDI_NOT_READY. Are > there > other valid values that might occur? Or could we just bail out? > return > failure here? Well, as far as I could see from the documentation, the only valid byte should be read after EDI_READY. EDI_NOT_READY indicates that we should keep reading and other values should be treated as garbage. I think this implementation is consistent with that. Especially, values of 0 usually occur when the kb9012 is not responding (not powered, etc) so I don't want to do anything in particular when it happens (such as increasing the buffer). > > + } > > + > > + if (buffer[i - 1] == EDI_NOT_READY) { > > + /* > > + * Buffer size is increased, one step at a time, > > + * to hold more data if we only catch > > EDI_NOT_READY. > > + * Once CS is deasserted, no more data will be > > sent by the EC, > > + * so we cannot keep reading afterwards and have > > to start a new > > + * transaction with a longer buffer, to be safe. > > + */ > > + > > + if ((edi_read_buffer_length + 1) <= > > EDI_READ_BUFFER_LENGTH_MAX) { > So that's equivalent to `edi_read_buffer_length < > EDI_READ_BUFFER_LENGTH_MAX`. Quite right! This one is quite ugly. > > + msg_pwarn("%s: Retrying read with greater > > buffer length!\n", __func__); > > + edi_read_buffer_length++; > > + > > + return edi_read(flash, address, data); > Oh, recursion... stack usage looks not that bad, but could you live > without it? For example write a edi_retry_read() that calls a non > -recur- > sive edi_read() in a loop? Fair enough, let's go with renaming edi_read to edi_read_byte and having edi_read wrap the call to edi_read_byte, check its rc for EDI_NOT_READY and implement the buffer increase logic in a non -recursive way. > > + } else { > > + msg_perr("%s: Maximum buffer length > > reached and data still not ready!\n", __func__); > > + return -1; > You'd return -1 anyway below, but that's ok, it looks more balanced > this way... This becomes more consistent with the new code flow suggested above. > > + } > > + } > > + > > + return -1; > > +} > > + > > +static int edi_chip_probe(struct flashctx *flash, struct ene_chip > > *chip) > `chip` could be const. Ack. > > +{ > > + unsigned char hwversion = 0; > > + unsigned char ediid = 0; > > + int rc; > > + > > + rc = edi_read(flash, ENE_EC_HWVERSION, &hwversion); > > + if (rc < 0) > > + return 0; > > + > > + rc = edi_read(flash, ENE_EC_EDIID, &ediid); > > + if (rc < 0) > > + return 0; > > + > > + if (chip->hwversion == hwversion && chip->ediid == ediid) > > + return 1; > > + > > + return 0; > > +} > > + > > +static int edi_disable(struct flashctx *flash) > > +{ > > + unsigned char cmd = EDI_DISABLE; > const? Would make sense, but since other definitions of cmd in edi_read/edi_write are not const, I'd prefer to have this one not be const for consistency. > > + int rc; > There's no need for a variable here. Just return > spi_send_command(...). Not my coding style, see above. > > + > > + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned > > char *)&cmd, NULL); > > + if (rc) > > + return rc; > > + > > + return 0; > > +} > > + > > +static int edi_spi_enable(struct flashctx *flash) > > +{ > > + unsigned char buffer = 0; > > + int rc; > > + > > + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); > > + if (rc < 0) > It looks odd if you know, that it won't be > 0. I don't find that surprising. Negative rc for error and zero for success is what I usually do. > > + return rc; > > + > > + buffer |= ENE_XBI_EFCFG_CMD_WE; > > + > > + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); > > + if (rc < 0) > > + return rc; > > + > > + return 0; > return edi_write(...)? See above. > > +} > > + > > +static int edi_spi_disable(struct flashctx *flash) > > +{ > > + unsigned char buffer = 0; > > + int rc; > > + > > + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); > > + if (rc < 0) > > + return rc; > > + > > + buffer &= ~ENE_XBI_EFCFG_CMD_WE; > > + > > + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); > > + if (rc < 0) > > + return rc; > > + > > + return 0; > > +} > > + > > +static int edi_spi_busy(struct flashctx *flash) > > +{ > > + unsigned char buffer = 0; > > + int rc; > > + > > + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); > > + if (rc < 0) > > + return rc; > > + > > + return !!(buffer & ENE_XBI_EFCFG_BUSY); > > +} > > + > > +static int edi_8051_reset(struct flashctx *flash) > > +{ > > + unsigned char buffer = 0; > > + int rc; > > + > > + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); > > + if (rc < 0) > > + return rc; > > + > > + buffer |= ENE_EC_PXCFG_8051_RESET; > > + > > + rc = edi_write(flash, ENE_EC_PXCFG, buffer); > > + if (rc < 0) > > + return rc; > > + > > + return 0; > > +} > > + > > +static int edi_8051_execute(struct flashctx *flash) > > +{ > > + unsigned char buffer = 0; > > + int rc; > > + > > + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); > > + if (rc < 0) > > + return rc; > > + > > + buffer &= ~ENE_EC_PXCFG_8051_RESET; > > + > > + rc = edi_write(flash, ENE_EC_PXCFG, buffer); > > + if (rc < 0) > > + return rc; > > + > > + return 0; > > +} > > + > > +int edi_chip_block_erase(struct flashctx *flash, unsigned int > > page, unsigned int size) > Pedantic me: unsigned int is not assured to be wider than 16-bit ;) > but > that's a flashrom interface, isn't it? Yep, I copied the prototype as-is. > > +{ > > + unsigned int timeout = 64; > > + > > + if (size != flash->chip->page_size) { > Is this even possible? Or some kind of assertion? I haven't seen flashrom ask for this, but it could. When that happens, some bits on the page are left unprogrammed and when the whole page is written to memory, we're losing data. Handling that in edi.c causes way way too much overhead, so I'm just enforcing these assumptions to be safe. > > + msg_perr("%s: Block erase size is not page > > size!\n", __func__); > > + return -1; > > + } > > + > > + edi_spi_enable(flash); > > + > > + edi_write(flash, ENE_XBI_EFA0, ((page & 0xff) >> 0)); > > + edi_write(flash, ENE_XBI_EFA1, ((page & 0xff00) >> 8)); > > + edi_write(flash, ENE_XBI_EFA2, ((page & 0xff0000) >> 16)); > > + > > + edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_ERASE); > Every edi_write() may fail...[1] Indeed, I have added all the rc checking at a later point when coding and apparently missed those. Good spotting! > > + > > + while (edi_spi_busy(flash) && timeout--) > Um, edi_spi_busy() also returns true (!= 0) if it failed to read at > all. Quite right, let's make this edi_spi_busy(flash) == 1 and nevermind the error just this one time. > > + programmer_delay(10); > > + edi_spi_disable(flash); > > + > > + return 0; > [1]...returning 0 anyway? > > +} > > + > > +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, > > unsigned int start, unsigned int len) > > +{ > > + unsigned int address = start; > > + unsigned int pages; > > + unsigned int timeout; > > + unsigned int i, j; > > + > > + if ((start % flash->chip->page_size) != 0) { > > + msg_perr("%s: Start address is not page > > -aligned!\n", __func__); > > + return -1; > > + } > > + > > + if ((len % flash->chip->page_size) != 0) { > > + msg_perr("%s: Length is not page-aligned!\n", > > __func__); > > + return -1; > > + } > > + > > + pages = len / flash->chip->page_size; > > + > > + edi_spi_enable(flash); > > + > > + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); > > + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > > + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> > > 16)); > > + > > + for (i = 0; i < pages; i++) { > > + timeout = 64; > > + > > + /* Clear page buffer. */ > > + edi_write(flash, ENE_XBI_EFCMD, > > ENE_XBI_EFCMD_HVPL_CLEAR); > > + > > + for (j = 0; j < flash->chip->page_size; j++) { > > + if ((address - start) > 0) { > Just got confused here, so `start` is the overall start not the start > of the page. Indeed. The point here is simply to check that address - 1 is within the requested range, otherwise we end up setting the address twice the first time. Also, note that the address has to be set each time we write a byte to the page buffer. Unfortunately, it doesn't append the byte we just wrote to the page buffer. > Would have known that, when `start` would have been declared const ;) Sure, but again, I copied the prototype as-is from struct flashchip. Feel free to change that for the whole flashrom ;) > Also it's equivalent to `address > start`. Good point, that's more readable. > > + if (((address - 1) & 0xff) != > > (address & 0xff)) > > + edi_write(flash, > > ENE_XBI_EFA0, ((address & 0xff) >> 0)); > > + if (((address - 1) & 0xff00) != > > (address & 0xff00)) > > + edi_write(flash, > > ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > > + if (((address - 1) & 0xff0000) != > > (address & 0xff0000)) > > + edi_write(flash, > > ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); > > + } > > + > > + edi_write(flash, ENE_XBI_EFDAT, *buf); > > + edi_write(flash, ENE_XBI_EFCMD, > > ENE_XBI_EFCMD_HVPL_LATCH); > > + > > + buf++; > > + address++; > > + } > > + > > + /* Program page buffer to flash. */ > > + edi_write(flash, ENE_XBI_EFCMD, > > ENE_XBI_EFCMD_PROGRAM); > > + > > + while (edi_spi_busy(flash) && timeout--) > > + programmer_delay(10); > > + } > > + > > + edi_spi_disable(flash); > > + > > + return 0; > Again, every edi_write() may fail, edi_spi_{en,dis}able() also. Not > checking on single calls might be ok, but in a sheer endless loop? > that's not good. Guess, the SPI programmer driver runs into a timeout > of one second for every call to spi_send_command(), you'd be waiting > ages for this to end. Sure, that will be fixed. > > +} > > + > > +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned > > int start, unsigned int len) > > +{ > > + unsigned int address = start; > > + unsigned int i; > > + unsigned int timeout; > > + int rc; > > + > > + edi_spi_enable(flash); > > + > > + edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); > > + edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); > > + edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> > > 16)); > > + > > + /* > > + * EDI brings such a drastic overhead that there is about > > no need to > > + * have any delay in between calls. The EDI protocol will > > handle wait > > + * I/O times on its own anyway. > > + */ > > + > > + for (i = 0; i < len; i++) { > > + timeout = 64; > > + > > + if ((address - start) > 0) { > > + if (((address - 1) & 0xff) != (address & > > 0xff)) > > + edi_write(flash, ENE_XBI_EFA0, > > ((address & 0xff) >> 0)); > > + if (((address - 1) & 0xff00) != (address & > > 0xff00)) > > + edi_write(flash, ENE_XBI_EFA1, > > ((address & 0xff00) >> 8)); > > + if (((address - 1) & 0xff0000) != (address > > & 0xff0000)) > > + edi_write(flash, ENE_XBI_EFA2, > > ((address & 0xff0000) >> 16)); > > + } > > + > > + edi_write(flash, ENE_XBI_EFCMD, > > ENE_XBI_EFCMD_READ); > > + > > + do { > > + rc = edi_read(flash, ENE_XBI_EFDAT, buf); > > + if (!rc) > > + break; > if (!timeout) return ...? or loop for ever! Thanks, sorry for such carelessness, there are other places where timeout is not checked (even though it's more critical in this spot). > > + > > + /* Just in case. */ > > + while (edi_spi_busy(flash) && timeout--) > > + programmer_delay(10); > > + } while (rc); > Redundant check (rc can't be zero when we reach it) hides the endless > loop. Nice try! hehe That's correct, I simply prefer to have a dummy condition loosely related to the code logic (that is never actually reached) because, well, it doesn't hurt and looks better then while (1). If you believe it obfuscates the code, I'd be fine with removing that form. > > + > > + buf++; > > + address++; > > + } > > + > > + edi_spi_disable(flash); > > + > > + return 0; > > +} > > + > > +int edi_shutdown(void *data) > > +{ > > + struct flashctx *flash; > > + int rc; > > + > > + if (data == NULL) > > + return -1; > > + > > + flash = (struct flashctx *)data; > > + > > + rc = edi_8051_execute(flash); > > + if (rc < 0) { > > + msg_perr("%s: Unable to execute 8051!\n", > > __func__); > > + return -1; > > + } > > + > > + rc = edi_disable(flash); > > + if (rc < 0) { > > + msg_perr("%s: Unable to disable EDI!\n", > > __func__); > > + return -1; > > + } > > + > > + return 0; > > +} > > + > > +int edi_probe_kb9012(struct flashctx *flash) > > +{ > > + int probe; > > + int rc; > > + > > + probe = edi_chip_probe(flash, &ene_kb9012); > > + if (!probe) > > + return 0; > > + > > + rc = edi_8051_reset(flash); > > + if (rc < 0) { > > + msg_perr("%s: Unable to reset 8051!\n", __func__); > > + return 0; > > + } > > + > > + register_shutdown(edi_shutdown, (void *)flash); > > + > > + return 1; > > +} > > diff --git a/edi.h b/edi.h > > new file mode 100644 > > index 0000000..d9387b1 > > --- /dev/null > > +++ b/edi.h > > @@ -0,0 +1,34 @@ > > +/* > > + * This file is part of the flashrom project. > > + * > > + * Copyright (C) 2015 Paul Kocialkowski > > + * > > + * This program is free software; you can redistribute it and/or > > modify > > + * it under the terms of the GNU General Public License as > > published by > > + * the Free Software Foundation; either version 2 of the License, > > or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public > > License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > > 02110-1301 USA > > + */ > > + > > +#ifndef __EDI_H__ > > +#define __EDI_H__ 1 > > + > > +#define EDI_READ 0x30 > > +#define EDI_WRITE 0x40 > > +#define EDI_DISABLE 0xf3 > > + > > +#define EDI_NOT_READY 0x5f > > +#define EDI_READY 0x50 > > + > > +#define EDI_READ_BUFFER_LENGTH_DEFAULT 3 > > +#define EDI_READ_BUFFER_LENGTH_MAX 32 > > + > > +#endif > > diff --git a/ene.h b/ene.h > > new file mode 100644 > > index 0000000..445d28b > > --- /dev/null > > +++ b/ene.h > > @@ -0,0 +1,55 @@ > > +/* > > + * This file is part of the flashrom project. > > + * > > + * Copyright (C) 2015 Paul Kocialkowski > > + * > > + * This program is free software; you can redistribute it and/or > > modify > > + * it under the terms of the GNU General Public License as > > published by > > + * the Free Software Foundation; either version 2 of the License, > > or > > + * (at your option) any later version. > > + * > > + * This program is distributed in the hope that it will be useful, > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > + * GNU General Public License for more details. > > + * > > + * You should have received a copy of the GNU General Public > > License > > + * along with this program; if not, write to the Free Software > > + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA > > 02110-1301 USA > > + */ > > + > > +#ifndef __ENE_H__ > > +#define __ENE_H__ 1 > > + > > +#define ENE_XBI_EFA0 0xfea8 > > +#define ENE_XBI_EFA1 0xfea9 > > +#define ENE_XBI_EFA2 0xfeaa > > +#define ENE_XBI_EFDAT 0xfeab > > +#define ENE_XBI_EFCMD 0xfeac > > +#define ENE_XBI_EFCFG 0xfead > > + > > +#define ENE_XBI_EFCFG_CMD_WE (1 << 3) > > +#define ENE_XBI_EFCFG_BUSY (1 << 1) > > + > > +#define ENE_XBI_EFCMD_HVPL_LATCH 0x02 > > +#define ENE_XBI_EFCMD_READ 0x03 > > +#define ENE_XBI_EFCMD_ERASE 0x20 > > +#define ENE_XBI_EFCMD_PROGRAM 0x70 > > +#define ENE_XBI_EFCMD_HVPL_CLEAR 0x80 > > + > > +#define ENE_EC_PXCFG 0xff14 > > + > > +#define ENE_EC_PXCFG_8051_RESET 0x01 > > + > > +#define ENE_EC_HWVERSION 0xff00 > > +#define ENE_EC_EDIID 0xff24 > > + > > +#define ENE_KB9012_HWVERSION 0xc3 > > +#define ENE_KB9012_EDIID 0x04 > > + > > +struct ene_chip { > > + unsigned char hwversion; > > + unsigned char ediid; > > +}; > > + > > +#endif > > diff --git a/flashchips.c b/flashchips.c > > index 574ad74..13f0574 100644 > > --- a/flashchips.c > > +++ b/flashchips.c > > @@ -3201,6 +3201,29 @@ const struct flashchip flashchips[] = { > > }, > > > > { > > + .vendor = "ENE", > > + .name = "KB9012 (EDI)", > > + .bustype = BUS_SPI, > > + .total_size = 128, > > + .page_size = 128, > > + .feature_bits = FEATURE_ERASED_ZERO, > > + .tested = TEST_OK_PREW, > > + .probe = edi_probe_kb9012, > > + .probe_timing = TIMING_ZERO, > > + .block_erasers = > > + { > > + { > > + .eraseblocks = { {128, 1024} }, > > + .block_erase = > > edi_chip_block_erase, > > + }, > > + }, > > + .gran = write_gran_128bytes, > > + .write = edi_chip_write, > > + .read = edi_chip_read, > > + .voltage = {2700, 3600}, > > + }, > > + > > + { > > .vendor = "ESMT", > > .name = "F49B002UA", > > .bustype = BUS_PARALLEL, > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From contact at paulk.fr Sat Oct 24 13:24:38 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 24 Oct 2015 13:24:38 +0200 Subject: [flashrom] [PATCH v2 1/2] Flag-driven erased bit value Message-ID: <1445685879-2314-1-git-send-email-contact@paulk.fr> Most flash chips are erased to ones and programmed to zeros. However, some other flash chips, such as the ENE KB9012 internal flash, work the opposite way. Signed-off-by: Paul Kocialkowski --- flash.h | 5 ++++- flashrom.c | 39 +++++++++++++++++++++------------------ 2 files changed, 25 insertions(+), 19 deletions(-) diff --git a/flash.h b/flash.h index 24861ba..55d02de 100644 --- a/flash.h +++ b/flash.h @@ -123,6 +123,9 @@ enum write_granularity { #define FEATURE_WRSR_EITHER (FEATURE_WRSR_EWSR | FEATURE_WRSR_WREN) #define FEATURE_OTP (1 << 8) #define FEATURE_QPI (1 << 9) +#define FEATURE_ERASED_ZERO (1 << 10) + +#define ERASED_VALUE(flash) ((flash->chip->feature_bits & FEATURE_ERASED_ZERO) ? 0x00 : 0xff) enum test_state { OK = 0, @@ -275,7 +278,7 @@ int probe_flash(struct registered_master *mst, int startchip, struct flashctx *f int read_flash_to_file(struct flashctx *flash, const char *filename); char *extract_param(const char *const *haystack, const char *needle, const char *delim); int verify_range(struct flashctx *flash, const uint8_t *cmpbuf, unsigned int start, unsigned int len); -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran); +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value); void print_version(void); void print_buildinfo(void); void print_banner(void); diff --git a/flashrom.c b/flashrom.c index c9c7e31..bd8ef3f 100644 --- a/flashrom.c +++ b/flashrom.c @@ -673,12 +673,13 @@ int check_erased_range(struct flashctx *flash, unsigned int start, { int ret; uint8_t *cmpbuf = malloc(len); + const uint8_t erased_value = ERASED_VALUE(flash); if (!cmpbuf) { msg_gerr("Could not allocate memory!\n"); exit(1); } - memset(cmpbuf, 0xff, len); + memset(cmpbuf, erased_value, len); ret = verify_range(flash, cmpbuf, start, len); free(cmpbuf); return ret; @@ -731,7 +732,7 @@ out_free: } /* Helper function for need_erase() that focuses on granularities of gran bytes. */ -static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran) +static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsigned int len, unsigned int gran, const uint8_t erased_value) { unsigned int i, j, limit; for (j = 0; j < len / gran; j++) { @@ -741,7 +742,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig continue; /* have needs to be in erased state. */ for (i = 0; i < limit; i++) - if (have[j * gran + i] != 0xff) + if (have[j * gran + i] != erased_value) return 1; } return 0; @@ -761,7 +762,7 @@ static int need_erase_gran_bytes(const uint8_t *have, const uint8_t *want, unsig * @gran write granularity (enum, not count) * @return 0 if no erase is needed, 1 otherwise */ -int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran) +int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum write_granularity gran, const uint8_t erased_value) { int result = 0; unsigned int i; @@ -776,31 +777,31 @@ int need_erase(const uint8_t *have, const uint8_t *want, unsigned int len, enum break; case write_gran_1byte: for (i = 0; i < len; i++) - if ((have[i] != want[i]) && (have[i] != 0xff)) { + if ((have[i] != want[i]) && (have[i] != erased_value)) { result = 1; break; } break; case write_gran_128bytes: - result = need_erase_gran_bytes(have, want, len, 128); + result = need_erase_gran_bytes(have, want, len, 128, erased_value); break; case write_gran_256bytes: - result = need_erase_gran_bytes(have, want, len, 256); + result = need_erase_gran_bytes(have, want, len, 256, erased_value); break; case write_gran_264bytes: - result = need_erase_gran_bytes(have, want, len, 264); + result = need_erase_gran_bytes(have, want, len, 264, erased_value); break; case write_gran_512bytes: - result = need_erase_gran_bytes(have, want, len, 512); + result = need_erase_gran_bytes(have, want, len, 512, erased_value); break; case write_gran_528bytes: - result = need_erase_gran_bytes(have, want, len, 528); + result = need_erase_gran_bytes(have, want, len, 528, erased_value); break; case write_gran_1024bytes: - result = need_erase_gran_bytes(have, want, len, 1024); + result = need_erase_gran_bytes(have, want, len, 1024, erased_value); break; case write_gran_1056bytes: - result = need_erase_gran_bytes(have, want, len, 1056); + result = need_erase_gran_bytes(have, want, len, 1056, erased_value); break; case write_gran_1byte_implicit_erase: /* Do not erase, handle content changes from anything->0xff by writing 0xff. */ @@ -1424,6 +1425,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, unsigned int starthere = 0, lenhere = 0; int ret = 0, skip = 1, writecount = 0; enum write_granularity gran = flash->chip->gran; + const uint8_t erased_value = ERASED_VALUE(flash); /* curcontents and newcontents are opaque to walk_eraseregions, and * need to be adjusted here to keep the impression of proper abstraction @@ -1431,7 +1433,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, curcontents += start; newcontents += start; msg_cdbg(":"); - if (need_erase(curcontents, newcontents, len, gran)) { + if (need_erase(curcontents, newcontents, len, gran, erased_value)) { msg_cdbg("E"); ret = erasefn(flash, start, len); if (ret) @@ -1441,7 +1443,7 @@ static int erase_and_write_block_helper(struct flashctx *flash, return -1; } /* Erase was successful. Adjust curcontents. */ - memset(curcontents, 0xff, len); + memset(curcontents, erased_value, len); skip = 0; } /* get_next_write() sets starthere to a new value after the call. */ @@ -1938,6 +1940,7 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, int ret = 0; unsigned long size = flash->chip->total_size * 1024; int read_all_first = 1; /* FIXME: Make this configurable. */ + const uint8_t erased_value = ERASED_VALUE(flash); if (chip_safety_check(flash, force, read_it, write_it, erase_it, verify_it)) { msg_cerr("Aborting.\n"); @@ -1964,15 +1967,15 @@ int doit(struct flashctx *flash, int force, const char *filename, int read_it, msg_gerr("Out of memory!\n"); exit(1); } - /* Assume worst case: All bits are 0. */ - memset(oldcontents, 0x00, size); + /* Assume worst case: All bits are not erased. */ + memset(oldcontents, ~erased_value, size); newcontents = malloc(size); if (!newcontents) { msg_gerr("Out of memory!\n"); exit(1); } - /* Assume best case: All bits should be 1. */ - memset(newcontents, 0xff, size); + /* Assume best case: All bits should be erased. */ + memset(newcontents, erased_value, size); /* Side effect of the assumptions above: Default write action is erase * because newcontents looks like a completely erased chip, and * oldcontents being completely 0x00 means we have to erase everything -- 2.4.3 From contact at paulk.fr Sat Oct 24 13:24:39 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 24 Oct 2015 13:24:39 +0200 Subject: [flashrom] [PATCH v2 2/2] ENE Embedded Debug Interface (EDI) and ENE KB9012 EC internal flash support In-Reply-To: <1445685879-2314-1-git-send-email-contact@paulk.fr> References: <1445685879-2314-1-git-send-email-contact@paulk.fr> Message-ID: <1445685879-2314-2-git-send-email-contact@paulk.fr> The ENE Embedded Debug Interface (EDI) is a SPI-based interface for accessing the memory of ENE embedded controllers. The ENE KB9012 EC is an embedded controller found on various laptops such as the Lenovo G505s. It features a 8051 microcontroller and has 128 KiB of internal storage for program data. EDI can be accessed on the KB9012 through pins 59-62 (CS-CLK-MOSI-MISO) when flash direct access is not in use. Some firmwares disable EDI at run-time, so it might be necessary to ground pin 42 to reset the 8051 microcontroller before accessing the KB9012 via EDI. Signed-off-by: Paul Kocialkowski --- Makefile | 2 +- chipdrivers.h | 6 + edi.c | 532 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ edi.h | 30 ++++ ene.h | 51 ++++++ flashchips.c | 23 +++ 6 files changed, 643 insertions(+), 1 deletion(-) create mode 100644 edi.c create mode 100644 edi.h create mode 100644 ene.h diff --git a/Makefile b/Makefile index c439d8d..661c52a 100644 --- a/Makefile +++ b/Makefile @@ -368,7 +368,7 @@ endif CHIP_OBJS = jedec.o stm50.o w39.o w29ee011.o \ sst28sf040.o 82802ab.o \ - sst49lfxxxc.o sst_fwhub.o flashchips.o spi.o spi25.o spi25_statusreg.o \ + sst49lfxxxc.o sst_fwhub.o edi.o flashchips.o spi.o spi25.o spi25_statusreg.o \ opaque.o sfdp.o en29lv640b.o at45db.o ############################################################################### diff --git a/chipdrivers.h b/chipdrivers.h index cac94f3..8015b52 100644 --- a/chipdrivers.h +++ b/chipdrivers.h @@ -194,4 +194,10 @@ int erase_sector_stm50(struct flashctx *flash, unsigned int block, unsigned int int probe_en29lv640b(struct flashctx *flash); int write_en29lv640b(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len); +/* edi.c */ +int edi_chip_block_erase(struct flashctx *flash, unsigned int page, unsigned int size); +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len); +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len); +int edi_probe_kb9012(struct flashctx *flash); + #endif /* !__CHIPDRIVERS_H__ */ diff --git a/edi.c b/edi.c new file mode 100644 index 0000000..df081b5 --- /dev/null +++ b/edi.c @@ -0,0 +1,532 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2015 Paul Kocialkowski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include +#include "flash.h" +#include "ene.h" +#include "edi.h" + +static unsigned int edi_read_buffer_length = EDI_READ_BUFFER_LENGTH_DEFAULT; + +static const struct ene_chip ene_kb9012 = { + .hwversion = ENE_KB9012_HWVERSION, + .ediid = ENE_KB9012_EDIID, +}; + +static void edi_write_cmd(unsigned char *cmd, unsigned short address, unsigned char data) +{ + cmd[0] = EDI_WRITE; /* EDI write command. */ + cmd[1] = 0x00; /* Address is only 2 bytes. */ + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ + cmd[4] = data; /* Write data. */ +} + +static void edi_read_cmd(unsigned char *cmd, unsigned short address) +{ + cmd[0] = EDI_READ; /* EDI read command. */ + cmd[1] = 0x00; /* Address is only 2 bytes. */ + cmd[2] = (address >> 8) & 0xff; /* Address higher byte. */ + cmd[3] = (address >> 0) & 0xff; /* Address lower byte. */ +} + +static int edi_write(struct flashctx *flash, unsigned short address, unsigned char data) +{ + unsigned char cmd[5] = { 0 }; + int rc; + + edi_write_cmd(cmd, address, data); + + rc = spi_send_command(flash, sizeof(cmd), 0, (unsigned char *)cmd, NULL); + if (rc) + return -1; + + return 0; +} + +static int edi_read_byte(struct flashctx *flash, unsigned short address, unsigned char *data) +{ + unsigned char cmd[4] = { 0 }; + unsigned char buffer[edi_read_buffer_length]; + unsigned int index; + unsigned int i; + int rc; + + edi_read_cmd(cmd, address); + + memset(buffer, 0, sizeof(buffer)); + + rc = spi_send_command(flash, sizeof(cmd), sizeof(buffer), (unsigned char *)cmd, (unsigned char *)buffer); + if (rc) + return -1; + + index = 0; + + for (i = 0; i < sizeof(buffer); i++) { + index = i; + + if (buffer[i] == EDI_NOT_READY) + continue; + + if (buffer[i] == EDI_READY) { + if (i == (sizeof(buffer) - 1)) { + /* + * Buffer size was too small for receiving the value. + * This is as good as getting only EDI_NOT_READY. + */ + + buffer[i] = EDI_NOT_READY; + break; + } + + *data = buffer[i + 1]; + return 0; + } + } + + if (buffer[index] == EDI_NOT_READY) + return -EDI_NOT_READY; + + return -1; +} + +static int edi_read(struct flashctx *flash, unsigned short address, unsigned char *data) +{ + int rc; + + do { + rc = edi_read_byte(flash, address, data); + if (rc == -EDI_NOT_READY) { + /* + * Buffer size is increased, one step at a time, + * to hold more data if we only catch EDI_NOT_READY. + * Once CS is deasserted, no more data will be sent by the EC, + * so we cannot keep reading afterwards and have to start a new + * transaction with a longer buffer, to be safe. + */ + + if (edi_read_buffer_length < EDI_READ_BUFFER_LENGTH_MAX) { + msg_pwarn("%s: Retrying read with greater buffer length!\n", __func__); + edi_read_buffer_length++; + } else { + msg_perr("%s: Maximum buffer length reached and data still not ready!\n", __func__); + return -1; + } + } else if (rc < 0) { + return -1; + } + } while (rc == -EDI_NOT_READY); + + return 0; +} + +static int edi_disable(struct flashctx *flash) +{ + unsigned char cmd = EDI_DISABLE; + int rc; + + rc = spi_send_command(flash, sizeof(cmd), 0, &cmd, NULL); + if (rc) + return -1; + + return 0; +} + +static int edi_chip_probe(struct flashctx *flash, const struct ene_chip *chip) +{ + unsigned char hwversion = 0; + unsigned char ediid = 0; + int rc; + + rc = edi_read(flash, ENE_EC_HWVERSION, &hwversion); + if (rc < 0) + return 0; + + rc = edi_read(flash, ENE_EC_EDIID, &ediid); + if (rc < 0) + return 0; + + if (chip->hwversion == hwversion && chip->ediid == ediid) + return 1; + + return 0; +} + +static int edi_spi_enable(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); + if (rc < 0) + return -1; + + buffer |= ENE_XBI_EFCFG_CMD_WE; + + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); + if (rc < 0) + return -1; + + return 0; +} + +static int edi_spi_disable(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); + if (rc < 0) + return -1; + + buffer &= ~ENE_XBI_EFCFG_CMD_WE; + + rc = edi_write(flash, ENE_XBI_EFCFG, buffer); + if (rc < 0) + return -1; + + return 0; +} + +static int edi_spi_busy(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_XBI_EFCFG, &buffer); + if (rc < 0) + return -1; + + return !!(buffer & ENE_XBI_EFCFG_BUSY); +} + +static int edi_8051_reset(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); + if (rc < 0) + return -1; + + buffer |= ENE_EC_PXCFG_8051_RESET; + + rc = edi_write(flash, ENE_EC_PXCFG, buffer); + if (rc < 0) + return -1; + + return 0; +} + +static int edi_8051_execute(struct flashctx *flash) +{ + unsigned char buffer = 0; + int rc; + + rc = edi_read(flash, ENE_EC_PXCFG, &buffer); + if (rc < 0) + return -1; + + buffer &= ~ENE_EC_PXCFG_8051_RESET; + + rc = edi_write(flash, ENE_EC_PXCFG, buffer); + if (rc < 0) + return -1; + + return 0; +} + +int edi_chip_block_erase(struct flashctx *flash, unsigned int page, unsigned int size) +{ + unsigned int timeout = 64; + int rc; + + if (size != flash->chip->page_size) { + msg_perr("%s: Block erase size is not page size!\n", __func__); + return -1; + } + + rc = edi_spi_enable(flash); + if (rc < 0) { + msg_perr("%s: Unable to enable SPI!\n", __func__); + return -1; + } + + rc = edi_write(flash, ENE_XBI_EFA0, ((page & 0xff) >> 0)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFA1, ((page & 0xff00) >> 8)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFA2, ((page & 0xff0000) >> 16)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_ERASE); + if (rc < 0) + return -1; + + while (edi_spi_busy(flash) == 1 && timeout--) + programmer_delay(10); + + if (!timeout) { + msg_perr("%s: Timed out waiting for SPI not busy!\n", __func__); + return -1; + } + + rc = edi_spi_disable(flash); + if (rc < 0) { + msg_perr("%s: Unable to disable SPI!\n", __func__); + return -1; + } + + return 0; +} + +int edi_chip_write(struct flashctx *flash, const uint8_t *buf, unsigned int start, unsigned int len) +{ + unsigned int address = start; + unsigned int pages; + unsigned int timeout; + unsigned int i, j; + int rc; + + if ((start % flash->chip->page_size) != 0) { + msg_perr("%s: Start address is not page-aligned!\n", __func__); + return -1; + } + + if ((len % flash->chip->page_size) != 0) { + msg_perr("%s: Length is not page-aligned!\n", __func__); + return -1; + } + + pages = len / flash->chip->page_size; + + rc = edi_spi_enable(flash); + if (rc < 0) { + msg_perr("%s: Unable to enable SPI!\n", __func__); + return -1; + } + + rc = edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + if (rc < 0) + return -1; + + for (i = 0; i < pages; i++) { + timeout = 64; + + /* Clear page buffer. */ + rc = edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_HVPL_CLEAR); + if (rc < 0) + return -1; + + for (j = 0; j < flash->chip->page_size; j++) { + if (address > start) { + if (((address - 1) & 0xff) != (address & 0xff)) { + rc = edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + if (rc < 0) + return -1; + } + + if (((address - 1) & 0xff00) != (address & 0xff00)) { + rc = edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + if (rc < 0) + return -1; + } + + if (((address - 1) & 0xff0000) != (address & 0xff0000)) { + rc = edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + if (rc < 0) + return -1; + } + } + + rc = edi_write(flash, ENE_XBI_EFDAT, *buf); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_HVPL_LATCH); + if (rc < 0) + return -1; + + buf++; + address++; + } + + /* Program page buffer to flash. */ + rc = edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_PROGRAM); + if (rc < 0) + return -1; + + while (edi_spi_busy(flash) == 1 && timeout--) + programmer_delay(10); + + if (!timeout) { + msg_perr("%s: Timed out waiting for SPI not busy!\n", __func__); + return -1; + } + } + + rc = edi_spi_disable(flash); + if (rc < 0) { + msg_perr("%s: Unable to disable SPI!\n", __func__); + return -1; + } + + return 0; +} + +int edi_chip_read(struct flashctx *flash, uint8_t *buf, unsigned int start, unsigned int len) +{ + unsigned int address = start; + unsigned int i; + unsigned int timeout; + int rc; + + rc = edi_spi_enable(flash); + if (rc < 0) { + msg_perr("%s: Unable to enable SPI!\n", __func__); + return -1; + } + + rc = edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + if (rc < 0) + return -1; + + rc = edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + if (rc < 0) + return -1; + + /* + * EDI brings such a drastic overhead that there is about no need to + * have any delay in between calls. The EDI protocol will handle wait + * I/O times on its own anyway. + */ + + for (i = 0; i < len; i++) { + timeout = 64; + + if (address > start) { + if (((address - 1) & 0xff) != (address & 0xff)) { + rc = edi_write(flash, ENE_XBI_EFA0, ((address & 0xff) >> 0)); + if (rc < 0) + return -1; + } + + if (((address - 1) & 0xff00) != (address & 0xff00)) { + rc = edi_write(flash, ENE_XBI_EFA1, ((address & 0xff00) >> 8)); + if (rc < 0) + return -1; + } + + if (((address - 1) & 0xff0000) != (address & 0xff0000)) { + rc = edi_write(flash, ENE_XBI_EFA2, ((address & 0xff0000) >> 16)); + if (rc < 0) + return -1; + } + } + + rc = edi_write(flash, ENE_XBI_EFCMD, ENE_XBI_EFCMD_READ); + if (rc < 0) + return -1; + + do { + rc = edi_read(flash, ENE_XBI_EFDAT, buf); + if (rc == 0) + break; + + /* Just in case. */ + while (edi_spi_busy(flash) == 1 && timeout--) + programmer_delay(10); + + if (!timeout) { + msg_perr("%s: Timed out waiting for SPI not busy!\n", __func__); + return -1; + } + } while (rc); + + buf++; + address++; + } + + rc = edi_spi_disable(flash); + if (rc < 0) { + msg_perr("%s: Unable to disable SPI!\n", __func__); + return -1; + } + + return 0; +} + +int edi_shutdown(void *data) +{ + struct flashctx *flash; + int rc; + + if (data == NULL) + return -1; + + flash = (struct flashctx *)data; + + rc = edi_8051_execute(flash); + if (rc < 0) { + msg_perr("%s: Unable to execute 8051!\n", __func__); + return -1; + } + + rc = edi_disable(flash); + if (rc < 0) { + msg_perr("%s: Unable to disable EDI!\n", __func__); + return -1; + } + + return 0; +} + +int edi_probe_kb9012(struct flashctx *flash) +{ + int probe; + int rc; + + probe = edi_chip_probe(flash, &ene_kb9012); + if (!probe) + return 0; + + rc = edi_8051_reset(flash); + if (rc < 0) { + msg_perr("%s: Unable to reset 8051!\n", __func__); + return 0; + } + + register_shutdown(edi_shutdown, (void *)flash); + + return 1; +} diff --git a/edi.h b/edi.h new file mode 100644 index 0000000..542bf26 --- /dev/null +++ b/edi.h @@ -0,0 +1,30 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2015 Paul Kocialkowski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __EDI_H__ +#define __EDI_H__ 1 + +#define EDI_READ 0x30 +#define EDI_WRITE 0x40 +#define EDI_DISABLE 0xf3 + +#define EDI_NOT_READY 0x5f +#define EDI_READY 0x50 + +#define EDI_READ_BUFFER_LENGTH_DEFAULT 3 +#define EDI_READ_BUFFER_LENGTH_MAX 32 + +#endif diff --git a/ene.h b/ene.h new file mode 100644 index 0000000..e03e49b --- /dev/null +++ b/ene.h @@ -0,0 +1,51 @@ +/* + * This file is part of the flashrom project. + * + * Copyright (C) 2015 Paul Kocialkowski + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __ENE_H__ +#define __ENE_H__ 1 + +#define ENE_XBI_EFA0 0xfea8 +#define ENE_XBI_EFA1 0xfea9 +#define ENE_XBI_EFA2 0xfeaa +#define ENE_XBI_EFDAT 0xfeab +#define ENE_XBI_EFCMD 0xfeac +#define ENE_XBI_EFCFG 0xfead + +#define ENE_XBI_EFCFG_CMD_WE (1 << 3) +#define ENE_XBI_EFCFG_BUSY (1 << 1) + +#define ENE_XBI_EFCMD_HVPL_LATCH 0x02 +#define ENE_XBI_EFCMD_READ 0x03 +#define ENE_XBI_EFCMD_ERASE 0x20 +#define ENE_XBI_EFCMD_PROGRAM 0x70 +#define ENE_XBI_EFCMD_HVPL_CLEAR 0x80 + +#define ENE_EC_PXCFG 0xff14 + +#define ENE_EC_PXCFG_8051_RESET 0x01 + +#define ENE_EC_HWVERSION 0xff00 +#define ENE_EC_EDIID 0xff24 + +#define ENE_KB9012_HWVERSION 0xc3 +#define ENE_KB9012_EDIID 0x04 + +struct ene_chip { + unsigned char hwversion; + unsigned char ediid; +}; + +#endif diff --git a/flashchips.c b/flashchips.c index 574ad74..13f0574 100644 --- a/flashchips.c +++ b/flashchips.c @@ -3201,6 +3201,29 @@ const struct flashchip flashchips[] = { }, { + .vendor = "ENE", + .name = "KB9012 (EDI)", + .bustype = BUS_SPI, + .total_size = 128, + .page_size = 128, + .feature_bits = FEATURE_ERASED_ZERO, + .tested = TEST_OK_PREW, + .probe = edi_probe_kb9012, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {128, 1024} }, + .block_erase = edi_chip_block_erase, + }, + }, + .gran = write_gran_128bytes, + .write = edi_chip_write, + .read = edi_chip_read, + .voltage = {2700, 3600}, + }, + + { .vendor = "ESMT", .name = "F49B002UA", .bustype = BUS_PARALLEL, -- 2.4.3 From Mark.Rowlinson at uk.fujitsu.com Sun Oct 25 22:57:34 2015 From: Mark.Rowlinson at uk.fujitsu.com (Rowlinson Mark) Date: Sun, 25 Oct 2015 21:57:34 +0000 Subject: [flashrom] Flash chip/chipset not found In-Reply-To: <562B3FC4.9000808@gmx.net> References: <56287D06.3080707@gmx.net> <562B3FC4.9000808@gmx.net> Message-ID: Hi Carl-Daniel, Thanks again - I'll have access to the machines again on Tuesday and will try this out. Best Regards, Mark Rowlinson -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] Sent: 24 October 2015 09:22 To: Rowlinson Mark ; flashrom at flashrom.org Subject: Re: [flashrom] Flash chip/chipset not found Hi Mark, this is a VIA VT8251 PCI to ISA Bridge you're using. I think Stefan Tauner (in CC) already was discussing something similar here: http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html That email even has a patch attached. On 22.10.2015 22:24, Rowlinson Mark wrote: > Thanks for the swift response, I have attached output from the command requested. > > The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. Heh, would be fun to add this to our tests. Regards, Carl-Daniel Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu". This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free. Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW. Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW. PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE. Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU. From stefan.tauner at alumni.tuwien.ac.at Mon Oct 26 23:59:38 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Mon, 26 Oct 2015 23:59:38 +0100 Subject: [flashrom] [PATCH 1/2] Add missing header for musl compatibility In-Reply-To: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> References: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> Message-ID: <201510262259.t9QMxdNH005056@mail2.student.tuwien.ac.at> On Wed, 14 Oct 2015 10:43:07 +0200 Gwenhael Goavec-Merou wrote: > From: Gwenhael Goavec-Merou > > According to : > http://autobuild.buildroot.net/results/3de/3de936d9be79e151e66af15193084d82a0f2c04a/build-end.log > > linux/ioctl.h header must be included in linux_spi.c to obtain missing _IOC_SIZEBITS. > > Patch based on : > http://git.buildroot.net/buildroot/commit/package/c-periphery/0001-Add-missing-header-for-musl-compatibility.patch?id=60974ee92dd8ff9e43cc6b785ea5131a8851e74c > > Signed-off-by: Gwenhael Goavec-Merou Hi Gwenhael, I don't see how this is related to flashrom. It seems to be a patch against c-periphery. Did you notice any compile problems of flashrom itself? -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From gwenj at trabucayre.com Tue Oct 27 08:12:24 2015 From: gwenj at trabucayre.com (gwenhael.goavec) Date: Tue, 27 Oct 2015 08:12:24 +0100 Subject: [flashrom] [PATCH 1/2] Add missing header for musl compatibility In-Reply-To: <201510262259.t9QMxdNH005056@mail2.student.tuwien.ac.at> References: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> <201510262259.t9QMxdNH005056@mail2.student.tuwien.ac.at> Message-ID: <20151027081224.4a47367f@x230.trabucayre.com> Hi Stefan On Mon, 26 Oct 2015 23:59:38 +0100 Stefan Tauner wrote: > On Wed, 14 Oct 2015 10:43:07 +0200 > Gwenhael Goavec-Merou wrote: > > > From: Gwenhael Goavec-Merou > > The compile problem is shown in this build report : > > http://autobuild.buildroot.net/results/3de/3de936d9be79e151e66af15193084d82a0f2c04a/build-end.log This problem is clearly related to flashrom. > > > > linux/ioctl.h header must be included in linux_spi.c to obtain > > missing _IOC_SIZEBITS. > > This patch is not my patch but one that I was inspired to do mine : > > Patch based on : > > http://git.buildroot.net/buildroot/commit/package/c-periphery/0001-Add-missing-header-for-musl-compatibility.patch?id=60974ee92dd8ff9e43cc6b785ea5131a8851e74c > > > > Signed-off-by: Gwenhael Goavec-Merou > > > > Hi Gwenhael, > > I don't see how this is related to flashrom. It seems to be a patch > against c-periphery. Did you notice any compile problems of flashrom > itself? > -- > Kind regards/Mit freundlichen Gr??en, Stefan Tauner My patch to fix compile issue is on the missing part of this mail (on the bottom of http://patchwork.coreboot.org/patch/4327/). regards, Gwenhael From contact at paulk.fr Tue Oct 27 13:04:00 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Tue, 27 Oct 2015 13:04:00 +0100 Subject: [flashrom] [PATCH 1/3] 128 bytes write granularity support In-Reply-To: <201510222005.t9MK50Rs012698@mail2.student.tuwien.ac.at> References: <1444486821-10619-1-git-send-email-contact@paulk.fr> <561EB048.9060604@gmx.de> <201510160225.t9G2PY36018948@mail2.student.tuwien.ac.at> <1445189855.3397.4.camel@paulk.fr> <5623EBDA.7000706@gmx.net> <1445497133.1363.4.camel@paulk.fr> <201510222005.t9MK50Rs012698@mail2.student.tuwien.ac.at> Message-ID: <1445947440.2678.15.camel@collins> Hi Stefan, Le jeudi 22 octobre 2015 ? 22:05 +0200, Stefan Tauner a ?crit : > On Thu, 22 Oct 2015 08:58:53 +0200 > Paul Kocialkowski wrote: > > > Hi Carl-Daniel, > > > > Le dimanche 18 octobre 2015 ? 20:58 +0200, Carl-Daniel Hailfinger a > > ?crit : > > > On 18.10.2015 19:37, Paul Kocialkowski wrote: > > > > I noticed that you have reworded the commit message: I usually do > > > > not > use conjugated verbs in commit headline. Does this conflict > > > > with > > > > flashrom's guidelines? > > > > > > No formal guidelines, but "128 bytes write granularity support" is > > > missing a crucial piece of information: Was this a bugfix, a new > > > feature > > > or something you removed? > > > The reworded commit message has that info. > > > > Well, it does end with "support", which indicates that support for this > > was introduced, so I don't think it was confusing. > > > > I really see commit headlines as titles, not active phrases and would > > like to keep my commits phrased this way. > > > > Please let me know during patch review next time you find the commit > > headline not precise enough. > > Hello Paul, > > I have not replied yet because Carl-Daniel's message described the > thoughts I had/have when changing commit logs pretty much exactly. > Your approach on commit logs (seeing the first line as the "subject") is > IMHO a defensible argument. After all, that's how git calls it as well > in many places. > > However, using imperative sentences is much more common and IMHO it is > better. I see every commit as an entity that changes our code base... > so it always *does* something and often it is interesting what the most > descriptive verb is for what it is doing (e.g. add, fix, improve, > refactor, ...) to better understand what the change is about. Just like > Carl-Daniel explained for the commit in question. Well, I don't see both points of view as contradictory. When introducing support for something new, I think we're not losing any information when formatting the subject line as: Feature foo support introduction instead of Introduce support for feature foo This goes for all the things that we might want to describe: * Bug #123 fixup * Feature bar improvement * Baz code re-factoring Most active verbs have (more or less direct) equivalent nouns that can be used. I get the argument that we're doing something to the code base, so it makes sense to use active verbs, but for some reason, I just find that somewhat ugly. Perhaps my vision of things will change with time, but that's how I see it for now. Also, it seems that there is a lot of disparity regarding the tense used for such verbs : Added support for X/Add support for X/Adds support for X. And I don't really see any good way to choose between those. And I hate that sort of lack of consistency, so using non-verbal sentences felt like an elegant solution. > I can not be sure that if we someone looks at the commit in three years > he will remember or even know that 128 byte granularity was introduced > about the time this commit happened. It is much easier to understand > a commit if the subject contains a verb that makes the action clear. Well, let's not forget that commit messages come with longer explanations that must play a role, more than saying the same as the subject. I really see the subject as a title to the longer commit message. > Also, let's suppose we would have to revert a commit because it was > really a bad idea to commit it in the first place and we can not fix it > easily. The normal commit message would be > ?Revert "128 bytes write granularity support"? in your case vs. > ?Revert "Add support for 128 bytes write granularity.? in the > imperative case. The issue with the subject without a verb is similar > to the original. In the second case it is completely clear that the > support was removed again. Without a verb it could be a fix that is > reverted, an improvement, or even the revert of removing the support... > it is simply not explicit enough IMHO. Well, I think that "support" implies "support introduction", but that's something else. Also, git wraps the original line around quotation marks, which also adds some clarity. > Others have written about the subject as well, but I can not find a lot > of texts explaining the WHY very good... this is one example: > > http://chris.beams.io/posts/git-commit/#imperative One very good point here is that git uses the imperative when creating a commit on its own (Revert, Merge, etc). That sounds reasonable enough as a guideline for me to switch my behaviour. > Your other patches are affected as well and I intend to rephrase them > as I see fit. I hope you understand/agree now... if not I'll have > another argument: the maintainers have to maintain the codebase and are > the ones who read commit messages the most, hence it should be the > decision of the maintainers what's written in commit messages because > they are affected most by them. The submitter can simply dump the code > and hope it gets merged but apart from seeing some mails with the > subject during communication it does not affect his work on the project > later (because there often is none... otherwise he is not merely a > submitter). Well, that makes sense, yes, but keep in mind that it's also part of the author's contribution, so I'd like things to be discussed beforehand, just like it is somewhat rude to change a patch the way you like and merge it without discussing it with its author through code review first. Let's say that I wouldn't object to having commit subjects rephrased the way git does it internally. Thanks for taking the time to explain all this. Paul Kocialkowski -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From vacek.janko at gmail.com Tue Oct 27 10:43:20 2015 From: vacek.janko at gmail.com (John Vacek) Date: Tue, 27 Oct 2015 10:43:20 +0100 Subject: [flashrom] CHIPSET: alix 3d3 Message-ID: Proceeding anyway because user forced us to. Found chipset "AMD CS5536". Enabling flash write... OK. WARNING: unexpected second chipset match: "AMD CS5536" ignoring, please report lspci and board URL to flashrom at flashrom.org with 'CHIPSET: your board name' in the subject line. Found AMIC flash chip "A49LF040A" (512 kB, LPC) at physical address 0xfff80000. No operations were specified. http://www.pcengines.ch/alix3d3.htm root at kali-alix:~# lspci -nn 00:01.0 Host bridge [0600]: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge [1022:2080] (rev 33) 00:01.1 VGA compatible controller [0300]: Advanced Micro Devices [AMD] Geode LX Video [1022:2081] 00:01.2 Entertainment encryption device [1010]: Advanced Micro Devices [AMD] Geode LX AES Security Block [1022:2082] 00:09.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6105M [Rhine-III] [1106:3053] (rev 96) 00:0c.0 SATA controller [0106]: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller [1095:3512] (rev 01) 00:0e.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11a/b/g [14e4:4324] (rev 02) 00:0f.0 ISA bridge [0601]: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA [1022:2090] (rev 03) 00:0f.2 IDE interface [0101]: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE [1022:209a] (rev 01) 00:0f.3 Multimedia audio controller [0401]: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio [1022:2093] (rev 01) 00:0f.4 USB controller [0c03]: Advanced Micro Devices [AMD] CS5536 [Geode companion] OHC [1022:2094] (rev 02) 00:0f.5 USB controller [0c03]: Advanced Micro Devices [AMD] CS5536 [Geode companion] EHC [1022:2095] (rev 02) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mark.Rowlinson at uk.fujitsu.com Wed Oct 28 23:25:23 2015 From: Mark.Rowlinson at uk.fujitsu.com (Rowlinson Mark) Date: Wed, 28 Oct 2015 22:25:23 +0000 Subject: [flashrom] Flash chip/chipset not found In-Reply-To: <562B3FC4.9000808@gmx.net> References: <56287D06.3080707@gmx.net> <562B3FC4.9000808@gmx.net> Message-ID: Hi Carl-Daniel, That change does allow the chipset to be recognised and it will write out the ROM. It seems to be the BIOS code only (no settings) as it doesn't change if I change any settings within the BIOS. I've been directed to a save/restore utility that comes on the BIOS update image and it seems the last version actually accesses the data I'm interested in so I'm investigating this route at the moment. Best Regards, Mark Rowlinson -----Original Message----- From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] Sent: 24 October 2015 09:22 To: Rowlinson Mark ; flashrom at flashrom.org Subject: Re: [flashrom] Flash chip/chipset not found Hi Mark, this is a VIA VT8251 PCI to ISA Bridge you're using. I think Stefan Tauner (in CC) already was discussing something similar here: http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html That email even has a patch attached. On 22.10.2015 22:24, Rowlinson Mark wrote: > Thanks for the swift response, I have attached output from the command requested. > > The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. Heh, would be fun to add this to our tests. Regards, Carl-Daniel Unless otherwise stated, this email has been sent from Fujitsu Services Limited, from Fujitsu (FTS) Limited, or from Fujitsu Telecommunications Europe Limited, together "Fujitsu". This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free. Fujitsu Services Limited, registered in England No 96056, registered office 22 Baker Street, London W1U 3BW. Fujitsu (FTS) Limited, registered in England No 03808613, registered office 22 Baker Street, London W1U 3BW. PFU Imaging Solutions Europe Limited, registered in England No 1578652, registered office Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE. Fujitsu Telecommunications Europe Limited, registered in England No 2548187, registered office Solihull Parkway, Birmingham Business Park, Birmingham, B37 7YU. From stefan.tauner at alumni.tuwien.ac.at Thu Oct 29 00:32:08 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Thu, 29 Oct 2015 00:32:08 +0100 Subject: [flashrom] [PATCH 1/2] Add missing header for musl compatibility In-Reply-To: <20151027081224.4a47367f@x230.trabucayre.com> References: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> <201510262259.t9QMxdNH005056@mail2.student.tuwien.ac.at> <20151027081224.4a47367f@x230.trabucayre.com> Message-ID: <201510282332.t9SNW8px001258@mail2.student.tuwien.ac.at> On Tue, 27 Oct 2015 08:12:24 +0100 "gwenhael.goavec" wrote: > Hi Stefan > On Mon, 26 Oct 2015 23:59:38 +0100 > Stefan Tauner wrote: > > > On Wed, 14 Oct 2015 10:43:07 +0200 > > Gwenhael Goavec-Merou wrote: > > > > > From: Gwenhael Goavec-Merou > > > > The compile problem is shown in this build report : > > > http://autobuild.buildroot.net/results/3de/3de936d9be79e151e66af15193084d82a0f2c04a/build-end.log > This problem is clearly related to flashrom. Well, yes true... however, I am not sure if that's actually a problem with the includes in flashrom or the actual headers they are using. After all we do not use the undefined macro directly, so it should be brought in by the header file that uses it IMHO. flashrom does not support non-glibc C libraries yet anyway (this also affects your other patch) so this needs more investigation in any case. I am currently building a musl "crosscompiler" toolchain on our flashrom buildbot to allow for that (because the musl-gcc wrapper does not work with libraries like libpci). Don't expect any results soon but I'll put it on my todo list... thanks for the heads-up. -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From c-d.hailfinger.devel.2006 at gmx.net Thu Oct 29 01:36:35 2015 From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger) Date: Thu, 29 Oct 2015 01:36:35 +0100 Subject: [flashrom] Flash chip/chipset not found In-Reply-To: References: <56287D06.3080707@gmx.net> <562B3FC4.9000808@gmx.net> Message-ID: <56316A13.1070100@gmx.net> Hi Mark, would it be possible for you to generate a log file using the additional parameter --output logfile.txt when doing a read of the flash chip, then send that log file to us? That would help us to finally merge support for the VT8251 chipset in your point-of-sale IBM/Toshiba AnyPlace Kiosk Model 48xx series. We have a strict rule that flashrom must be 100% reliable and thus we keep log files for any newly supported/tested chipset around for reference. Your log file would be used as reference for VT8251. That said, it would be very interesting to know where the settings are actually stored. Have you looked into the top 128 bytes of NVRAM? Maybe there is another flash chip? Is there any way to trace what the save/restore tool does (i.e. does it run on Linux)? Regards, Carl-Daniel On 28.10.2015 23:25, Rowlinson Mark wrote: > Hi Carl-Daniel, > > That change does allow the chipset to be recognised and it will write out the ROM. It seems to be the BIOS code only (no settings) as it doesn't change if I change any settings within the BIOS. > > I've been directed to a save/restore utility that comes on the BIOS update image and it seems the last version actually accesses the data I'm interested in so I'm investigating this route at the moment. > > Best Regards, > Mark Rowlinson > > -----Original Message----- > From: Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2006 at gmx.net] > Sent: 24 October 2015 09:22 > To: Rowlinson Mark ; flashrom at flashrom.org > Subject: Re: [flashrom] Flash chip/chipset not found > > Hi Mark, > > this is a VIA VT8251 PCI to ISA Bridge you're using. > > I think Stefan Tauner (in CC) already was discussing something similar here: > http://www.flashrom.org/pipermail/flashrom/2012-July/009552.html > That email even has a patch attached. > > > On 22.10.2015 22:24, Rowlinson Mark wrote: >> Thanks for the swift response, I have attached output from the command requested. >> >> The device in question is an IBM (now Toshiba) AnyPlace Kiosk Model 4838-310. The models we have are a mixture of 4838-310 and 4838-330 and support documentation refers to them as 4838-3xx. > Heh, would be fun to add this to our tests. > > Regards, > Carl-Daniel > From stefan.tauner at alumni.tuwien.ac.at Thu Oct 29 23:55:37 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Thu, 29 Oct 2015 23:55:37 +0100 Subject: [flashrom] [PATCH 1/2] Add missing header for musl compatibility In-Reply-To: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> References: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> Message-ID: <201510292255.t9TMtb4G006279@mail2.student.tuwien.ac.at> On Wed, 14 Oct 2015 10:43:07 +0200 Gwenhael Goavec-Merou wrote: > From: Gwenhael Goavec-Merou > > According to : > http://autobuild.buildroot.net/results/3de/3de936d9be79e151e66af15193084d82a0f2c04a/build-end.log > > linux/ioctl.h header must be included in linux_spi.c to obtain missing _IOC_SIZEBITS. > > Patch based on : > http://git.buildroot.net/buildroot/commit/package/c-periphery/0001-Add-missing-header-for-musl-compatibility.patch?id=60974ee92dd8ff9e43cc6b785ea5131a8851e74c This is actually a bug in the linux headers that apparently is hidden by the glibc headers because they include the right headers "by accident": glibc headers corresponding to Linux 3.2.0: # 23 "sys/ioctl.h" 2 # 24 "/usr/include/x86_64-linux-gnu/bits/ioctls.h" 3 4 # 1 "/usr/include/x86_64-linux-gnu/asm/ioctls.h" 1 3 4 # 1 "/usr/include/asm-generic/ioctls.h" 1 3 4 # 1 "/usr/include/linux/ioctl.h" 1 3 4 # 1 "/usr/include/x86_64-linux-gnu/asm/ioctl.h" 1 3 4 # 1 "/usr/include/asm-generic/ioctl.h" 1 3 4 > _IOC_SIZEBITS (found out with the help of gcc -E -dD and some grep foo) With musl's 1.0.5 (stable) headers sys/ioctl.h does not include any OS-specific headers (I think) and thus no _IOC_SIZEBITS. That makes it fail to compile flashrom's linux_spi.c as indicated in the log. Why is that a bug in the kernel headers? Because linux/spi/spidev.h defines a macro named SPI_MSGSIZE (that flashrom uses) that relies on another macro (_IOC_SIZEBITS)from asm-generic/ioctl.h that should be (indirectly) brought in by spidev.h. Does it matter? No, we have to support it anyway hence I will include the proposed change (if no regression crops up). Still, I would like this to be reported "upstream". Could you please do that Gwenhael? -- Kind regards/Mit freundlichen Gr??en, Stefan Tauner From stefan.tauner at alumni.tuwien.ac.at Fri Oct 30 02:42:51 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Fri, 30 Oct 2015 02:42:51 +0100 Subject: [flashrom] [PATCH] Add (implicit) support for musl libc. In-Reply-To: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> References: <1444812188-8766-1-git-send-email-gwenj@trabucayre.com> Message-ID: <1446169371-30693-1-git-send-email-stefan.tauner@alumni.tuwien.ac.at> From: Gwenhael Goavec-Merou This is mostly achieved by fixing or refining the inclusion of header files and replacing glibc-specific ifdefs with more generic ones. - : Linux-specific and not only available in glibc. Include it if we are running Linux and not only if glibc is active. - : should be (and is) replaced by (without the "sys" prefix). - : Does not include all necessary headers, namely _IOC_SIZEBITS that is used in the definition of SPI_MSGSIZE is not brought in via but instead we relied so far on glibc's including it via . Change that to explicitly including . - : Would also be available in musl but there is no easy way to detect it so we do not try yet. The bug report and initial patches were Signed-off-by: Gwenhael Goavec-Merou Signed-off-by: Stefan Tauner --- No regressions detected on the buildbot... flashrom can be built completely (with libpci, libusb and libftdi programmers) with musl after applying this. hwaccess.h | 3 ++- linux_spi.c | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/hwaccess.h b/hwaccess.h index 3e46192..25b1456 100644 --- a/hwaccess.h +++ b/hwaccess.h @@ -27,7 +27,7 @@ #include "platform.h" #if IS_X86 -#if defined(__GLIBC__) +#if defined(__linux__) #include #endif #endif @@ -115,6 +115,7 @@ #if !defined (__FLASHROM_BIG_ENDIAN__) && !defined (__FLASHROM_LITTLE_ENDIAN__) /* Nonstandard libc-specific macros for determining endianness. */ +/* musl provides an endian.h as well... but it can not be detected from within C. */ #if defined(__GLIBC__) #include #if BYTE_ORDER == LITTLE_ENDIAN diff --git a/linux_spi.c b/linux_spi.c index 26725e1..19b4965 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -22,13 +22,14 @@ #include #include #include -#include +#include #include #include #include +#include #include #include -#include +#include #include "flash.h" #include "chipdrivers.h" #include "programmer.h" -- Kind regards, Stefan Tauner From contact at paulk.fr Sat Oct 31 10:41:28 2015 From: contact at paulk.fr (Paul Kocialkowski) Date: Sat, 31 Oct 2015 10:41:28 +0100 Subject: [flashrom] [coreboot] FOSDEM deadlines now! In-Reply-To: <5626B038.80901@gmx.net> References: <5626B038.80901@gmx.net> Message-ID: <1446284488.2576.7.camel@collins> Hi, Le mardi 20 octobre 2015 ? 23:20 +0200, Carl-Daniel Hailfinger a ?crit : > we obviously want to participate in FOSDEM. > https://fosdem.org/2016/news/2015-09-24-call-for-participation/ > > ACT NOW! > > Some deadlines already expired. Some can still be managed. > > Main track talks: Deadline 2015-10-30 (10 days left) > One hour of entertainment, huge audience. > Anyone up for the challenge? I have submitted a talk proposal about liberating modern computers, and will of course be talking about Coreboot there. Not everything I'm mentioning in the talk was properly documented at this point (especially regarding work on the KB9012 EC), but I hope to correct that before the event! Liberating (modern) computers from the ground up: a tale of Libreboot, Chromebooks and EC Abstract: Most of the computers we use daily are relying on proprietary software at the lower levels. This includes the bootloader (previously known as BIOS), firmwares running on various microcontrollers inside peripherals and controllers and even microcodes inside processors. However, some devices and platforms perform better than others when it comes to software freedom at these levels: some are supported by free bootloaders, such as U-Boot and Coreboot. Thus, it becomes less of a stretch to liberate those devices, which is also crucial for privacy and security. Chromebooks are such good targets, since they ship with Coreboot and a free embedded controller firmware. While some models still require proprietary pieces here and there, a few can actually boot up with only free software and are now supported by Libreboot, the fully free distribution of Coreboot. In addition, they implement a robust security model that, for once, does not conflict with the user's interest. On the other hand, a few recent AMD devices also show real potential for free software, with possible areas of work for freeing them at the low levels. In particular, freeing the software running on such an AMD laptop's embedded controller is currently work in progress, with all the tools needed in hands. Description: Starting from a personal use case, this talk will first draw a general overview of the current status of free software support at the lower levels of modern computers, especially bootloaders, firmwares running inside chips and microcodes, with a particular emphasis on embedded devices. The common limitations when freeing these devices will be highlighted, along with the examples of recent Intel and AMD platforms and how they compare to different kinds of embedded systems on a chip. With the overall picture of the situation a mind, the rest of the talk will focus on a few examples of modern computers that were picked up based on a personal use case and show potential for running with free software at the lower levels. This will highlight what was already achieved at this point, what is work in progress and what would be doable in the future. The first interesting devices that will be mentioned are Chromebooks, with mention of how they usually perform better that most other modern computers when it comes to free software. While not all Chromebooks are good candidates for running a fully free bootloader (depending on the platform they're using), a few of them are, such as the C201 Chromebook (by Asus) that is now supported by Libreboot. This talk will highlight all the challenges encountered when adding support for this Chromebook to Libreboot and what is next for liberating it. Other potential Chromebooks that would be worth supporting in Libreboot will also be mentioned. Still guided by a personal incentive, two modern computers, the G505s laptop (by Lenovo) and the F2A85-M (PRO) mainboard (by Asus) will be highlighted as they use an AMD platform that shows some potential for freedom, whereas modern Intel platforms appear to be fatally flawed. While the road to running those computers in freedom appears to be long, if not fatally obstructed, there are still some areas of work. In particular, the road to freeing the G505s's KB9012 embedded controller will be presented in details, with an emphasis on the incentive behind it and security considerations regarding embedded controllers. This last part will show how it was possible to gather information on the platform, implement access to its internal flash externally, grab an UART serial port, solder standalone boards for tests and execute code on the device, up to blinking a LED! > Stands: Deadline 2015-11-13 (24 days left) > I can send in the proposal if I'm not going to be alone there. > How many tables do we want for our stand/booth(s)? > Who is coming? I will definitely be around at FOSDEM, not sure I should have a seat at the table at this point (I'm still pretty new to the community), but I'd be happy to come by! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: https://www.replicant.us/ Blog: https://blog.replicant.us/ Wiki/tracker/forums: https://redmine.replicant.us/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From stefan.tauner at alumni.tuwien.ac.at Sat Oct 31 21:50:59 2015 From: stefan.tauner at alumni.tuwien.ac.at (Stefan Tauner) Date: Sat, 31 Oct 2015 21:50:59 +0100 Subject: [flashrom] [PATCH] Add (implicit) support for musl libc. In-Reply-To: <1446169371-30693-1-git-send-email-stefan.tauner@alumni.tuwien.ac.at> References: <1446169371-30693-1-git-send-email-stefan.tauner@alumni.tuwien.ac.at> Message-ID: <1446324659-19719-1-git-send-email-stefan.tauner@alumni.tuwien.ac.at> This is mostly achieved by fixing or refining the inclusion of header files and replacing glibc-specific ifdefs with more generic ones. - : Contains iopl(2) and x86 I/O port access functions (inb, outb etc). Generally Linux-specific but also availble on debian/kFreeBSD. Provided by glibc as well as musl and uclibc. Include it if we are running Linux or if glibc is detected. - : should be (and is) replaced by (without the "sys" prefix). - : Does not include all necessary headers, namely _IOC_SIZEBITS that is used in the definition of SPI_MSGSIZE is not brought in via but instead we relied so far on glibc's including it via . Change that to explicitly including . - : Would also be available in musl but there is no easy way to detect it so we do not try yet. The bug report and initial patches were Signed-off-by: Gwenhael Goavec-Merou Signed-off-by: Stefan Tauner --- New version because the sys/io.h change was actually breaking Debian/kFreeBSD! Moved it down where all the IN[BWL]/OUT[BWL] definitions are. hwaccess.h | 14 ++++++++------ linux_spi.c | 5 +++-- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/hwaccess.h b/hwaccess.h index 3e46192..390f0e4 100644 --- a/hwaccess.h +++ b/hwaccess.h @@ -26,12 +26,6 @@ #include "platform.h" -#if IS_X86 -#if defined(__GLIBC__) -#include -#endif -#endif - #if NEED_PCI == 1 /* * libpci headers use the variable name "index" which triggers shadowing @@ -115,6 +109,7 @@ #if !defined (__FLASHROM_BIG_ENDIAN__) && !defined (__FLASHROM_LITTLE_ENDIAN__) /* Nonstandard libc-specific macros for determining endianness. */ +/* musl provides an endian.h as well... but it can not be detected from within C. */ #if defined(__GLIBC__) #include #if BYTE_ORDER == LITTLE_ENDIAN @@ -204,6 +199,13 @@ cpu_to_be(64) #if NEED_PCI == 1 #if IS_X86 +/* sys/io.h provides iopl(2) and x86 I/O port access functions (inb, outb etc). + * It is included in glibc (thus available also on debian/kFreeBSD) but also in other libcs that mimic glibc, + * e.g. musl and uclibc. */ +#if defined(__linux__) || defined(__GLIBC__) +#include +#endif + #define __FLASHROM_HAVE_OUTB__ 1 /* for iopl and outb under Solaris */ diff --git a/linux_spi.c b/linux_spi.c index 26725e1..19b4965 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -22,13 +22,14 @@ #include #include #include -#include +#include #include #include #include +#include #include #include -#include +#include #include "flash.h" #include "chipdrivers.h" #include "programmer.h" -- Kind regards, Stefan Tauner