Raspberry Pi portable workbench(Project Christoph)

So, I've forgot an SD card of Project Christoph at home and I urgently need to flash a SPI BIOS flash. While I'm installing all my SPI tools on a fresh image, lemme make a log with instructions:

apt-get install subversion usbutils build-essential libftdi1 libftdi-dev zlib1g-dev  libusb-dev
svn co https://code.coreboot.org/svn/flashrom/trunk flashrom
cd flashrom
make CONFIG_ENABLE_LIBPCI_PROGRAMMERS=no  CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=no
Usage instructions:
./flashrom -p linux_spi:dev=/dev/spidev0.0 #Detecting the chip
./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -r fw.bin #Reading firmware from it
./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -r fw2.bin #Reading firmware again
sha512sum fw.bin && sha512sum fw2.bin #Checking two images to see if SPI works OK

./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -E #Erasing the chip
./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -w image.bin #Writing image to the chip

"spispeed" parameter, although not documented anywhere, means SPI speed in kHz, so 8000 is 8MHz - the fastest Pi can get AFAIK and the parameter that works quite well.

I had plenty of problems today with a SPI flash labeled as W25Q64.W. It was a chip bought in China (like, the buyer was physically in China. Feels weird, right?), and by the datasheet claimed to be working at 1.8V and 1.8V only. It worked for me with all the logic and power shifted to 1.8, however, the readings weren't reliable and the flashing would never verify - the flash would erase correctly and read back as FFs, but writing to it would not get verified. I connected it to 3.3V - and not only it did not burn in flames, it did flash and read correctly. I spent 3 hours on this shit. Conclusion? Don't believe those Chinese-bought flash chips. The markings were looking totally legit, but it feels like a fake to me due to this inconsistency with the datasheet.

This whole code piece sounds like a nice #pyLCI - Linux Control Interface application, but there's still a lot of UI elements I need to add, like file browser and so on.

I've got a friend who makes a living making custom speaker systems/headphones/laser cut things, and as with many fields today, it's got a lot to do with electronics. Many of the things he does are one-offs, thus, it makes sense to re-purpose some Chinese boards sometimes just for the sake of adding a feature. Think "Hey, maybe you could add Bluetooth to those speakers of mine?" And that's exactly what one of my "workdays" was about recently.

There it is. A board he had spare, from an adapter which plugs into one of those iPod/iPhone docks which have built-in speakers, receives audio through Bluetooth and streams it to the said dock. Some of those docks have decent enough sound quality, thus it makes sense to add adapters, and some of those are just lacking Bluetooth, as we know, everything's better with Bluetooth. In the end, why have a dock that's suitable for your iPod but not for your Android phone?

Anyway, he didn't need that adapter and it was suitable for the task. Normally, it would just be a simple job of soldering a couple of wires and leaving it inside the speaker - just look at these testpoints!

But then, it wouldn't need me if it were so easy. He also wanted the adapter Bluetooth name replaced, since, you know, he's producing one-offs and putting his brand name on them so that people come and see - he's put a lot of work in these, and he really does - except for BT adapters, where it's no sense to reinvent the wheel. It'd be all good, but "I-WAVE" is not really his brand name, and it's not even nice-looking. Moreover, there wasn't really any process for changing it - as you can imagine with a custom product not even intended to be disassembled, not to mention soldered to.

Yes, that chip on the left side has all the markings erased. Those dicks, why'd you do that? I don't even understand what it does. It doesn't seem to work with USB, and yet it seems to be connected to the 30-pin connector. It seems to be some kind of PIC, Chinese manufacturers love thise and placement of VCC/GND pins seems like it. Also, it might be connected to the OVC3860's UART.
The OVC3860 seems to have been featured on Hackaday one time, and it seems it accepts custom AT commands. It also is available on more hackable modules that are intended to be connected to *duinos and such - here's one guy doing basically the same hack as me, and there seemed to be a nice forum thread ot two about it too. But whatever, I discovered them only later somehow, that's why you do your Google homework properly before hacking =D
I had to take a closer look:

Sorry for bad pics (that's the best camera I have). Anyway, if you don't see a 24C08 EEPROM, you'll have to take my word for it. And what's the best place for storing such things other than EEPROM?

Now, let's return to my workbench. As you can see, the shield has the I2C pins broken out (this is not my shield, it's an exact copy though):

Great. The only problem is alleged 5V-only operation, but AFAIK some 5V devices like this work on 3.3V, they just aren't tested on this. Anyway, I'll plug a male header in the 3V3-UART-I2C 2.54 female header and just solder wires to it:

That way, I can plug/unplug this chip whenever I want. I also can add a female header to the board the EEPROM was soldered to, to avoid soldering the chip to the board every time I need to test a new firmware image:

Now let's load dev-i2c, deadbug the EEPROM on wires the same way it was connected on the board, connect its VCC to the 3V3 supply and see if it's OK with 3V3, at least for basic operation:

root@raspberrypi:~# i2cdetect -y -a 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 52 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Yes, it is. There are 4 addresses, and, funnily enough, each of them is mapped to a 256-byte section of this 1 Kilobyte EEPROM.
Now, there are nice tutorials for RPi+I2C EEPROMs. I used this one with great success, and that means using eeprog software. I had to make&make install it, but it went great.
That's what I found out after half an hour of searching the BT address in the first section, which read like this:

.????.?????? ??.
.???.??.?&?X?.??
???.??$?.../.>?v
??? ? ..?`.?????
'??|.?.....?.???
????????"?.B X$Y
(Z.z.?.?.?????.|
?7?Yf...0???..??
???..?.?9?@.??(f
??.?@r??.??.??x?
?.0._???.???????
????wwww???@?..?
.????????? 0%.Q?
... ?????P ???0?
??.....???Z??.??
"&?.???.????"2?.

After the realisation about the address-to-space mapping, I read data from all of the addresses and pieced the dump together:

.????.?????? ??.
.???.??.?&?X?.??
???.??$?.../.>?v
??? ? ..?`.?????
'??|.?.....?.???
????????"?.B X$Y
(Z.z.?.?.?????.|
?7?Yf...0???..??
???..?.?9?@.??(f
??.?@r??.??.??x?
?.0._???.???????
????wwww???@?..?
.????????? 0%.Q?
... ?????P ???0?
??.....???Z??.??
"&?.???.????"2?.
??&(?.??????????
?.???.?.???.?.??
?.?.???<?.???<?.
???????..??...??
?..????.????.???
..????.???..????
.???...???.?????
c??? ??5????.???
.?????.????,????
? ????..???X.???
???.???????#?.?{
.2.??? ?=?.UU..0
000....I-WAVE.xx
.?????? ???.??.?
..?.?.}..?...QRR
Q..?@.?.????????
.????fU.-?AJ????
?@???l?{??.???.x
}??w?E??????P???
l??2?????t???^-1
B`+?????#J?Q4??+
.^??,???X?[ea?0?
?1????????????"?
M????(e???.j.??;
-??8>\(?4???a}??
????n?????eb??X@
??..............
.........a}????!
??9911`.??.i.?..
......?i.??.?.9i
.??.?...........
................
................
................
................
..........!??...
................
................
................
................
................
..xG?F.????./???
?.???h?(???h?(??
?H.x?(??? .??.??
???G..??.???Hy??
???(???*??? .??.
????. ?G..?????.
..    ..........

Much better. You see that bit with I-WAVE? Here's how it looks like in binary:

c0: 30 30 30 00 ff ff ff 49 2d 57 41 56 45 00 78 78    000....I-WAVE.xx

Unless there are checksums (well, who needs them on a freaking cheap BT adapter?), we've got at least 6 characters we can change as we wish - and maybe more, depends on how the bytes in front of the name and after it can be treated. So I decided to test it with a shorter name (Russian-speaking people reading this, forgive me for an immature name):

Wonderful. Friend was happy too. Then I decided to check if the two following bytes (reading 78 78) could be overwritten:

Yes, they could. Erasing those two 78 bytes could have broken some aspect of this chip's firmware (I didn't yet test the audio, after all), but that proves it's searching for the null terminator, as @charliex suggested in the #Hacker Channel. I also wonder if preceding FF bytes can be erased... Yet to be tested. Names longer than 6 ASCII characters are still more like POC for me, but it's nevertheless a fun hack. I look forward to branding one in my nickname, making it more universal with i.e. a 3.5mm socket and similar features and making it a part of my toolkit - if only I had a necessity... =D There's even an article from which you can get general tips on improving this module's efficiency. Also, UART of this adapter are still unused - but I don't need them as for now, too. Maybe someday later.
My setup - I was not at home while doing all of this, I just bring all the tools with me:

One more capability to my Raspberry Pi programmer. Maybe one day I can start selling those as kits/full units on eBay =)

I sometimes need to read and write SPI flash memory chips. Furthermore, I just got a task to re-flash a BIOS on a motherboard, so I had some additional motivation to make me a tool that does it. I've heard good things about FlashROM, it's a pretty versatile package which is open-source and supports many programming platforms, including Raspberry Pi.

The motherboard (MSI FM2-A75MA-P33) had a SOIC SPI flash chip which was soldered on, but all the pins were available on a header, pinout for which seemed to be already reverse-engineered and available on the Internet.
The header had 2MM spacing between pins, but I bought a corresponding connector for this and soldered a ribbon cable with proper spacing to it. I then soldered this cable to the prototyping shield I use and made a cable which'd connect it to the proper SPI&power pins.

That way, I can label it something like "MSI BIOS adapter", and next time I just plug it in the same way and not worry about searching for pinouts, soldering or checking connections etc.

Some concerns:
If you're doing In-System Programming (with chip still soldered to the mainboard and leads attached to the chip), you might run into the issue that you might backpower the mainboard. In my case, the current on 3V3 line was around 300mA - and my gut feeling told me this wasn't exactly consumption of the flash chip alone, but at least it didn't hurt anything. It might be worse in other cases, in my case RPi just rebooted every time I'd connect the chip to it - so I tried not to disconnect it. In some cases though, as it is with router boards, you need to avoid backpowering. I have a SBC which will simply power up and try to read the flash as soon as 3V3 is applied, and that's not acceptable if you're trying to flash the ROM. I guess you could hold RESET signal of that SBC low though, yet to check this. I also guess old tricks with lifting pads off the board still apply, too.