✧✦Catherine✦✧Feb 25

do you need to work with SPI flash a lot? do you hate the unreliable clothespin clip style clips? do you want a clip that actually works and is cheap?

aliexpress has you covered! check this product out [not sponsored]

there is a bit of a learning curve (you need to push on it quite strongly to make a connection) but after that it just works. do note that the pin 1 marker on the 8-pin DIP connector isn't placed in the right spot, but it is marked correctly on the probe itself and the little adapter board it has on the other end.

I tested the WSON-8 and SOIC-8-W versions so I'm quite sure the other two work also

Show threadellyFeb 25
@whitequark I got one of those recently, paired with fast flasher (like PiPico) it's a godsend. No more f#$%ing around with clips that never get reliable reads or being pretty much screwed in case of WSON.

(I have shaky hands most of the time, holding them at an ~80 degree angle helps. You can also use a rubber band to make it stay in place.)
Show threadTim SmallMar 1
@elly @whitequark How fast it is to iterate whilst doing coreboot dev? Is flash erase and program time still the bottleneck (or am I out of date)? Dunno if this is viable, but could you emulate SPI flash using a small FPGA (maybe even Pi Pico PIO) like this? Write data out to a pair of "mirrored" PSRAM ICs. Get around refresh-induced latency spikes by routing reads to one PSRAM while the mirror pair is doing its refresh? Simpler than implementing DRAM in an FPGA? Program from dev box via USB.
Show threadellyMar 1
@tim @whitequark I'm using Glasgow for OpenSIL/coreboot development on Framework 16 right now (because it was the most convenient tool that supports 1.8V, and on AMD SoCs all I/O is 1.8V only).
With 32MB flash it takes about ~25 seconds if I do a full flash, but that's rarely the case while doing iterations to your code. Usually you overwrite few blocks at the time. If you just need a fast SPI flasher and aren't working on brand-new(ish) SoCs that use 1.8V SPI, PiPico will get you there just fine as well.

Glasgow could do SPI emulation if it had enough memory I guess? I never worked with FPGAs, but EM100 flashers that are "industry standard" and cost ~800 euro/piece have Xilinx Spartan 6/7 FPGAs with ~128MB of RAM inside. I have one such emulator from work and that takes ~5 seconds to upload the flash image and boot the DUT.

Nice part about Glasgow is that you can do dual-applet mode (i.e: glasgow multi spi-flashrom --voltage A=1.8 -f 12000 tcp::2222 ++ uart --voltage B=1.8 --tx B1 --rx B0 tty), but I need to figure out how to make it configure pins as input/float after it finishes the SPI transaction. Right now I need to put it into safe mode (glasgow safe or pressing the button) or platform won't "see" the flash.
Show thread✧✦Catherine✦✧Mar 1

@elly @tim

  • i'm very pleased that it works! i'm planning to iterate on the existing applet (really, rewrite it while applying lessons learned) to make QSPI-capable and SFDP-native memory-25q. it won't write any faster but it will read faster. would you be interested in testing it?
  • there is a HyperRAM addon for revC (not in production yet) which would add more than enough DRAM to do this, but speed may be a significant issue; it is an open question whether that will work well for SPI flash emulation at "x86 SoC" speeds because of specifics of HyperRAM. unless you can set some soft straps to limit it to maybe 12-24 MHz at most, then yes
  • you can actually not refresh modern DRAM at room temperature for as long as a full second and still get back a bit-for-bit replica of like 64 MB of data (I checked this). so refresh intervals aren't the biggest problem here. it's the address-to-out latency that is
  • for floating the pins once it finishes the SPI transaction, this is a very simple (few LOC and straightforward) change to the QSPI PHY that i've meant to do for a while, if you open an issue i won't forget to do it
  • (the platform doesn't "see" the flash because glasgow keeps CS# high and SCK in the last state, so there's a bus conflict when the SoC tries to boot. glasgow has much stronger drivers and therefore wins)
Show thread✧✦Catherine✦✧Mar 1
@elly @tim also are you running glasgow on the phone itself via termux or is that an ssh session?
Show threadellyMar 1
@whitequark @tim It was just a test, I switched to using my workstation as host but I ran it natively (this phone is running pmOS)
Show thread✧✦Catherine✦✧Mar 1
@elly @tim oh nice! pmOS would make sense, Android has a screwy libusb interface that I want to support but I think still can't
Show threadelly
@whitequark @tim yeah, Android is pretty much useless for hacking purposes these days. Decade ago you could download an app that would configure your phone as mass storage gadget and you could boot your systems using ISOs on your phone. Of course you can't do that anymore because *reasons*. It's also missing kernel drivers for basic stuff like usb-serial-simple.

On pmOS you can mount ISOs as mass storage, use mSD card as an external drive, use TTL adapters/SuzyQ to debug DUTs and of course use Glasgow for whatever you want. It feels great to have a smol device in your pocket that does what you want it to and doesn't try to fight you every step of the way 
Mar 1 at 9:20pmWeb