✧✦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 threadTim SmallMar 3
@whitequark @elly Yes you're right, I hadn't appreciated DRAM address setup is significant here. Looks like @th has been here and done this already (2019) complete with write-up and C3 talk - https://trmm.net/Spispy/#how - hardware (ULX3S) is still available on crowdsupply. MuseLab iCESugar-Pro might be another target (similar DRAM chip), but would take some work to port.
spispy: Open source flash emulation

Overview of the spispy flash emulator based on the open source ULX3S board using an ECP5 FPGA and 32 MB of DRAM.

Trammell Hudson's Projects
Show threadTrammell HudsonMar 3
@tim @whitequark @elly the new 16MiB psram chips mean I should revisit the ice40 based spispy. The fpga pin-to-pin time was too slow to mux two 8 MiB chips but a single one should be workable. https://protosupplies.com/product/psram_16mb/
Show threadTim Small
@th @whitequark @elly I hadn't seen 16MiB SPI PSRAM SOIC, but I had found 32MiB at about €5 e.g. APS512XXN-OB9-BG (1.8v octal SPI, BGA package). ... but I've no idea if the latencies and clocks make this viable or not.
Mar 3 at 10:04amWeb
Show threadTrammell HudsonMar 3
@tim @whitequark @elly that doesn't implement the SPI flash protocol so you're dependent on the fpga doing translation and then the pin-to-pin latency of the fpga fabric becomes a problem. and based on a skim of the datasheet, it looks like the PSRAM can introduce delays during internal refreshes which breaks the read commands that need predictable latency.
Show threadTrammell HudsonMar 3
@tim @whitequark @elly one of the key hacks in spispy is that our DRAM controller can inhibit refresh cycles when the CSn pin is asserted or a read cycle has started, ensuring that we do not have any delays.
Show threadTim SmallMar 3
@th @whitequark @elly "The PASR bits restrict refresh operation to a portion of the total memory [...] or none of the array." but then you have the latency added by toggling it.
Could you hack around it by writing data to a pair of PSRAM ICs (full contents mirrored)? That would allow alternating which IC had refresh enabled, allowing all reads to be directed to the refresh-disabled IC? Might not be viable with this part due to the need for command translation, but maybe useful with other PSRAMs?
Show thread✧✦Catherine✦✧Mar 3
@tim @th @elly yes this is the standard way to deal with it