Hello. Assuming this is 3v3 by default. I'm currently working on a ryzen pc, and have to flash fairly
often. ryzen's use a 1v8 flash chip (as often as I've seen, at least), and I'm currently using a ch341a
with one of those 1v8 stepdown addons. Would I be able to use this with the addon for my use
case?

Also, how fast can this write, generally speaking? the ch341a is ok if its just an iteration of an existing
coreboot build, but if I'm going back to stock or from stock to coreboot it takes quite a while.

Does anyone ask for UART passthrough to be added to the functionality of pico-serprog?

A use case is: programming an FPGA, then switching to talking to it via UART on TX and RX lines. It would be very nice to not have to use a whole separate device. Ideally there should be dual serial ports - one for serprog and the other for the uart so the code connected to the uart can say connected during the flashing process.

Is this a feature that could be added to pico-serprog, or is this better done as a fork and do something new project?

I tried this one and flashrom couldn't even communicate with the programmer -- I think its pio related (not sure entirely, I later tried in my own implementation the pio but couldn't get it to work either) -- in the version I forked (https://codeberg.org/libreboot/pico-serprog) it could communicate but couldn't read more than a small part of the rom without getting an error. That's when I tried again with pio -- to no avail, but I realized only a subset of the serprog spec is implemented: https://github.com/flashrom/flashrom/blob/main/Documentation/serprog-protocol.txt

So the problem I faced in the second version was actually that neither project implemented the commands that tell flashrom how much buffer the device can handle. Once I implemented these and some other commands, I got it to work. I tried 1024, then 512, and then went to 8 because the higher value buffers got out of sync/didn't work for me. But 8 works great -- its slow, takes about 10-12 minutes to read a 16MB rom chip, and about the same to write, except write is a read + write + read, so about 30-40 minutes for that.

Here is my version in case its helpful to anyone, the main branch is whats working for me and then I have two pio related PRs I could never get to work: https://github.com/opensensor/pico-serprog I would have forked from this branch but my code is closer in line with the libreboot codeberg version.

Example:

Probing for Generic unknown SPI chip (REMS), 0 kB: compare_id: id1 0xa1, id2 0x17
Found Unknown flash chip "SFDP-capable chip" (16384 kB, SPI).
===
This flash part has status UNTESTED for operations: WP
The test status of this chip may have been updated in the latest development
version of flashrom. If you are running the latest development version,
please email a report to [email protected] if any of the above operations
work correctly for you with this flash chip. Please include the flashrom log
file for all operations you tested (see the man page for details), and mention
which mainboard or programmer you tested in the subject line.
Thanks for your help!
Reading flash... read_flash:  region (00000000..0xffffff) is readable, reading range (00000000..0xffffff).
done.
serprog: Output drivers disabled

Note -- the version I have uses a different pin-out than version.

I stumbled upon the libreboot fork of this firmware today. One improvement that stood out to me is that they increased the GPIO drive strength:

+    gpio_set_drive_strength(SPI_MISO, GPIO_DRIVE_STRENGTH_12MA);
+    gpio_set_drive_strength(SPI_MOSI, GPIO_DRIVE_STRENGTH_12MA);
+    gpio_set_drive_strength(SPI_SCK,  GPIO_DRIVE_STRENGTH_12MA);
+    gpio_set_drive_strength(SPI_CS,   GPIO_DRIVE_STRENGTH_12MA);

This might be worth copying.

The following is generated when trying to compile for RP2040 chip.
Host is windows using the C++ libraries, example setup guide for current config: https://notenoughtech.com/featured/c-c-and-micropython-sdk-for-raspberry-pi-pico-on-windows/

pico-serprog-main\main.c:159:31: error: 'stdio_usb' undeclared (first use in this function); did you mean 'stdio_flush'?

is there a dependency missing?

Thanks for this.
I had some issues getting it to work with the current pico-sdk (v1.3).

The CDC device /dev/ttyACM0 was never enumerated and dmesg kept spitting errors like usb 1-1.2: can't set config #1, error -110

But, checking out pico-sdk v1.2.0 fixed my issue. and it enumerates and presents ttyACM0 as expected.

Didnt investigate further, but its likely changes in tinyUSB pulled into pico-sdk