Hi coreboot list,
I have been attempting to use a raspberry pi for spi flashing and when I use the 3.3v pin the raspberry pi doesn't power up as the chip draws too much power through the 3.3v pin for the raspberry pi to also run. I am powering the RPi through micro-USB, either connected to wall outlet or another computer.
What is your recommended method for powering the chip and RPi?
Looking online [1] some folks recommend using laptop AC adapter + wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure that's a dependable strategy because I don't know if coreboot has WoL functionality for the x230 should I want to reflash the chip [2].
Advice/thoughts appreciated, and let me know if there's a better place to ask this question.
FYI this is the chip I am trying to program: [3]
Thanks, Michael
[1] https://www.bios-mods.com/forum/Thread-REQUEST-Lenovo-Thinkpad-X230-Whitelis... [2] https://www.coreboot.org/Board:lenovo/x230 [3] http://www.zlgmcu.com/mxic/pdf/NOR_Flash_c/MX25L3206E_DS_EN.pdf
Michael Carbone wrote:
I have been attempting to use a raspberry pi for spi flashing and when I use the 3.3v pin the raspberry pi doesn't power up as the chip draws too much power through the 3.3v pin for the raspberry pi to also run.
It's not the flash chip drawing current, it's the rest of the mainboard.
A PC mainboard has 10-20 different voltages. The 3.3 V rail with the flash chip is only one of them. Each platform (CPU+chipset) defines a strict sequence and timing for turning voltages on, for the platform to function correctly.
If the mainboard is otherwise unpowered and the 3.3 V rail is connected to an external supply then that sequence and the timing is guaranteed to be violated. This could cause anything from permanent hardware damage (maybe unlikely, but certainly possible) to random malfunction, e.g. excessive current draw, as long as the outside supply is connected.
What is your recommended method for powering the chip and RPi?
Looking online [1] some folks recommend using laptop AC adapter + wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure that's a dependable strategy
In fact I consider it the *only* dependable strategy. It is the obvious way to adhere to the required power up sequence.
The next question becomes - how to ensure that the SPI bus master is not driving the SPI bus, when the mainboard is powered?
This requires some platform- and possibly mainboard-specific research into exactly how the SPI master powers up.
On i945 platforms (X60, T60), the 3.3 V rail is active whenever the AC adapter is connected, also when the system is off. Very handy. On other platforms that's not neccessarily the case, and some tricks can and will be needed to get 3.3 V up but keep the SPI master in reset, hoping that will make its SPI output pins high-impedance, rather than drive 0 or 1. The latter would cause a short circuit if the external SPI programmer drives the opposite level.
The correct solution to having two SPI masters with a single slave (flash chip) is to insert a bus switch before the slave, so that only one master can access the flash at any given time. This requires moving the flash chip off the mainboard onto an adapter PCB with the bus switch on it. There exists an open design for such an adapter PCB already, but I don't know off the top of my head who made it. Hopefully the author or someone else (lynxis?) can post the link.
Thanks
//Peter
On Thu, Dec 01, 2016 at 01:15:59PM +0000, Peter Stuge wrote:
Michael Carbone wrote:
I have been attempting to use a raspberry pi for spi flashing and when I use the 3.3v pin the raspberry pi doesn't power up as the chip draws too much power through the 3.3v pin for the raspberry pi to also run.
It's not the flash chip drawing current, it's the rest of the mainboard.
For some mainboards (like the 15" 2014 Macbook Pro) I had to add a 1-10 Ohm resistor on the power lead from my flasher, which basically glitches the rest of the mainboard, but since many SPI flash chips can run at a slightly lower voltage it allowed me to read/write the firmware. This is probably not the right way to do it.
[...]
Looking online [1] some folks recommend using laptop AC adapter + wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure that's a dependable strategy
In fact I consider it the *only* dependable strategy. It is the obvious way to adhere to the required power up sequence.
I've never had success with this technique due to the multi-master situation that you described. The PCH (or ME?) on modern CPUs seemed to always be driving the IO lines when I provided power. Now I always unplug the AC adapter and remove the battery before powering up my flasher (although I do leave the chip-clip connected).
Perhaps I'm a little more YOLO with many of my test machines than is prudent, so I don't worry too much about what other bits are being powered up by the 3.3V rail. On the x230 I used an external bench supply and found that the rail needed about 110 mA to function:
https://www.flickr.com/photos/osr/28494632165/lightbox
So on my teensy 2 flasher I replaced the small SMD regulator with a larger UA78M33 regulator in a TO-220 package that can supply 500mA:
https://www.flickr.com/photos/osr/30531707094/lightbox
My biggest problem these days is that the chipclips seem to wear out after a few hundred applications (the pins get pushed upwards, making the connection flaky). Anyone have a recommendation for one that can stand up to constant use?
Now I always unplug the AC adapter and remove the battery before powering up my flasher (although I do leave the chip-clip connected).
This is about right. I programmed most of INTEL platforms using dediprog SF100: ATOM: from D4xx/D5xx (Pine Creek) series, TNC, BYT-M/I, BSW and CORE (IVB, HSW, BDX-DE, BDW-H, SKL-Y/U), whereas for some HSW-U series it was necessary to put platform in S5 state by shutting down them to S5. AC in most cases removed, I did not have battery since I played with test platforms. And there were 4x2 pins connectors for most of platforms, recently with special small connector forms and adapters for SF100 programming heads, but in some cases I needed clip to connect directly to flash.
Zoran
On Thu, Dec 1, 2016 at 3:02 PM, Trammell Hudson hudson@trmm.net wrote:
On Thu, Dec 01, 2016 at 01:15:59PM +0000, Peter Stuge wrote:
Michael Carbone wrote:
I have been attempting to use a raspberry pi for spi flashing and when
I
use the 3.3v pin the raspberry pi doesn't power up as the chip draws
too
much power through the 3.3v pin for the raspberry pi to also run.
It's not the flash chip drawing current, it's the rest of the mainboard.
For some mainboards (like the 15" 2014 Macbook Pro) I had to add a 1-10 Ohm resistor on the power lead from my flasher, which basically glitches the rest of the mainboard, but since many SPI flash chips can run at a slightly lower voltage it allowed me to read/write the firmware. This is probably not the right way to do it.
[...]
Looking online [1] some folks recommend using laptop AC adapter + wake-on-lan (and not using the VCC/3.3v pin), but I'm not sure that's a dependable strategy
In fact I consider it the *only* dependable strategy. It is the obvious way to adhere to the required power up sequence.
I've never had success with this technique due to the multi-master situation that you described. The PCH (or ME?) on modern CPUs seemed to always be driving the IO lines when I provided power. Now I always unplug the AC adapter and remove the battery before powering up my flasher (although I do leave the chip-clip connected).
Perhaps I'm a little more YOLO with many of my test machines than is prudent, so I don't worry too much about what other bits are being powered up by the 3.3V rail. On the x230 I used an external bench supply and found that the rail needed about 110 mA to function:
https://www.flickr.com/photos/osr/28494632165/lightbox
So on my teensy 2 flasher I replaced the small SMD regulator with a larger UA78M33 regulator in a TO-220 package that can supply 500mA:
https://www.flickr.com/photos/osr/30531707094/lightbox
My biggest problem these days is that the chipclips seem to wear out after a few hundred applications (the pins get pushed upwards, making the connection flaky). Anyone have a recommendation for one that can stand up to constant use?
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
-
Michael Carbone -
Peter Stuge -
Trammell Hudson -
Zoran Stojsavljevic