Help me test the flashrom v1.7 binary build

Flashrom v1.7 binary just dropped for Windows!

Can you help me test the flashrom v1.7 binary build?

It’s enough if you just confirm whether you can read and write the SPI flash chips you have on hand. If there’s any problem, let me know and I’ll check whether there’s an issue in the BP-firmware or whatever. Thank you very much.


Use the last firmware: Bus Pirate firmware auto build: main branch - #674 by Bus-Pirate

1 Like

TEST cmd

randomize_bin.py

#!/usr/bin/env python3
"""Overwrite every byte of a .bin file with random data. File size never changes."""
import argparse, os, sys

def randomize(path):
    with open(path, "r+b") as f:
        data = f.read()
        unique = set(data)
        state = "all 0xFF" if unique == {0xFF} else "all 0x00" if unique == {0x00} else "mixed"
        print(f"Original content: {state}.")
        f.seek(0)
        f.write(os.urandom(len(data)))
    print(f"Done: '{path}' randomized ({len(data)} bytes, size unchanged).")

if __name__ == "__main__":
    p = argparse.ArgumentParser(description="Overwrite every byte of a .bin file with random data, keeping its size.")
    p.add_argument("file", help="Path to the .bin file to randomize")
    args = p.parse_args()
    if not os.path.isfile(args.file):
        sys.exit(f"Error: '{args.file}' does not exist or is not a file.")
    randomize(args.file)

flashrom.exe --progress -V -p buspirate_spi:dev=COM??,spispeed=125k,serialspeed=115200 -E

del flash_content.img

flashrom.exe --progress -V -p buspirate_spi:dev=COM??,spispeed=125k,serialspeed=115200 -r flash_content.img

python randomize_bin.py flash_content.img

flashrom.exe --progress -V -p buspirate_spi:dev=COM??,spispeed=125k,serialspeed=115200 -w flash_content.img

flashrom.exe --progress -V -p buspirate_spi:dev=COM??,spispeed=125k,serialspeed=115200 -v flash_content.img


TEST TABLE (read+write) - 10 cm dupont cable

bp6rev2

  • SST25VF080B → r: :white_check_mark: | w: :white_check_mark:
  • W25Q64BV/W25Q64CV/W25Q64FV → r: :white_check_mark: | w: :white_check_mark:
  • AT25DF021A → r: :white_check_mark: | w: :white_check_mark:
  • W25Q256JV
  • AT45DB161D
  • P25Q16H
  • GD25Q64
  • MX25L1606E
  • MX25U4033E

BP5XL ← Dreg doesn’t have it

  • SST25VF080B
  • W25Q64BV/W25Q64CV/W25Q64FV
  • AT25DF021A
  • W25Q256JV
  • AT45DB161D
  • P25Q16H
  • GD25Q64
  • MX25L1606E
  • MX25U4033E

bp5rev10 ← Dreg doesn’t have it

  • SST25VF080B
  • W25Q64BV/W25Q64CV/W25Q64FV
  • AT25DF021A
  • W25Q256JV
  • AT45DB161D
  • P25Q16H
  • GD25Q64
  • MX25L1606E
  • MX25U4033E

bp5rev8-sd

  • SST25VF080B → :-1:
  • W25Q64BV/W25Q64CV/W25Q64FV → :-1:
  • AT25DF021A
  • W25Q256JV
  • AT45DB161D
  • P25Q16H
  • GD25Q64
  • MX25L1606E
  • MX25U4033E

bp3.6 (very old)

  • SST25VF080B → r: :white_check_mark: | w: :white_check_mark:
  • W25Q64BV/W25Q64CV/W25Q64FV → r: :white_check_mark: | w: :white_check_mark:
  • AT25DF021A → r: :white_check_mark: | w: :white_check_mark:
  • W25Q256JV
  • AT45DB161D
  • P25Q16H
  • GD25Q64
  • MX25L1606E
  • MX25U4033E

I’ve bought these to test: W25Q256JV, AT25DF021A, AT45DB161D, P25Q16H, GD25Q64, MX25L1606E, MX25U4033E, SST25VF080B, W25Q64BV (they’ll be arriving over the next few weeks…)

The bp6rev2 works fine - for the moment - as expected :blush: . But when using the standard BPcable + bp5rev8-sd, some bytes are coming through incorrectly :weary_face: , and it’s not always the same position. I’m going to check the firmware… Hopefully I can fix it easily by tweaking the code a bit. We’ll see…

1 Like

Unfortunately, I don’t have a Windows box. Maybe I could try setting up a VM, but I’d have to do which chips I have around to see if it’s worthwhile

1 Like

@mbrugman could you test the native Linux build of flashrom v1.7?

I could. Just let me try to track down some flash chips, haha. Might be a few days before I got to that, if that’s ok

1 Like

could also be some wire signal interference crap. spurious edges can cause the weirdest effects when data desyncs

1 Like

In case anyone gets bored and is curious, here’s how I’m going to set everything up so it’s plug-and-play and easy to use.

I’m going to label everything with a permanent marker and then put cyanoacrylate over it. I’ll use electrical tape + permanent marker + cyanoacrylate to label the chip model and the maximum voltage I’m going to use it at.

That way, the labels don’t get rubbed off by handling, they last a really long time, and I don’t have to keep rewriting them (If I get a little IPA residue on my hand, it’s not really a problem…)

First, I grabbed some typical 2.54 mm male-female stacked headers. That way, I can connect the standard Bus Pirate cable on the male side and use the female side to connect to the flash memories.

I’m going to sacrifice this cable and solder it directly to make sure I get a good electrical connection.

I’m marking the cable’s “polarity” so they’ll all be wired the same way.

I bought a bunch of those typical ready-made boards for Winbond SPI flash memory. They’re pretty cheap when you buy them in bulk, so I’m just desoldering the SOIC chips they come with and replacing them with all the new ones I bought. That way, I don’t have to design and make a PCB.

Next step: I’m attaching some electrical tape to the module with cyanoacrylate and writing the part number and the maximum voltage I’ll use on it. That way, you can tell at a glance what each module is.

Some of the spi flash memories aren’t the exact this SOIC package that fits these PCBs perfectly, like the one in the photo. They’re slightly narrower, but that’s fine—you just center them carefully and, with a bit of solder and patience, you can get a good fit and solid electrical contact.

I know all of this is pretty hacky and messy, and there’s no going back once I do it, but I’ll be using these for a long time and I want to have them ready to test everything with flashrom, the flash probe command, etc. Maybe it seems like way too much effort :rofl:

1 Like

I’ve had some problems with the standard Bus Pirate cables for my setups. I’ve tried all the used ones I had and even pulled out a brand new unused one:

And the problem persists,


so I made a DIY 10cm Dupont cable and everything works much better.

I’ll put in the table which things work well in my setups with the 10cm

Example AT25DF021A

BP standard original NEW cable

SPI> [0x9F r:3]

CS Enabled
TX: 0x9F
RX: 0x1E 0x08 0x00 ← BAD
CS Disabled

Dreg’s DIY 10cm dupont cable

SPI> [0x9F r:3]

CS Enabled
TX: 0x9F
RX: 0x1F 0x43 0x01 ← GOOD
CS Disabled

And flashrom: Found Atmel flash chip “AT25DF021A” (256 kB, SPI).

Since the 10-pin female Dupont connector is a bit of a pain to plug into and remove from the Bus Pirate (it fits too tightly), I made a short cable version using an MX connector and crimped MX wires, just like the original Bus Pirate cables.

New PR! It had a few bugs that made reads not always repeatable, so I fixed those and
tested it on a BP6 and a BP5 rev8 against several flash chips and AVRs.
Any review or testing would be very welcome:

@ian @mbrugman

All the memory chips I was missing have arrived, that was fast! Time to solder!

“Good review thank you” wtf

1 Like

Done!

2 Likes

Never thought to use superglue to lock the sharpie writing. That alone is a worthy hack.

It’s mainly useful so you don’t smudge the permanent marker ink with your fingers, and if you spill some IPA, it doesn’t affect the labels. That said… it’s a pain in the ass to do.. And it takes a while to dry.

1 Like

@ian has merged my changes to AVRDude and flashrom, so everything should work better now. If anyone can test it and give me some feedback, I’d really appreciate it. I’ll also be testing it with all the memory chips I’ve bought. @AreYouLoco

https://forum.buspirate.com/t/bus-pirate-5-auto-build-main-branch/20/999999

Will try to find time and test it. i have some Winbonds on hand that may be reprogrammed. And some GigaDevice to read out.

1 Like