This originally started out as an attempt to fix a Reolink RLC-520 camera that was bricked in a firmware update. In the end, I still haven’t figured out how to get it working again. I was, however, able to dump the firmware from a working reference camera of the same revision and also get the firmware running in QEMU. The emulation portion will likely be in a separate part 2.
The attempted firmware update apparently failed miserably as it never came back online. There was no power interruption as far as I know. To this day, I don’t know why it failed. After following the reset procedure and still no signs of life, Reolink offered to send a replacement camera for the cost of shipping and I could keep the broken one. With a broken device I had the perfect opportunity to dissect it, figure out why it failed, potentially fix it, and learn something in the process. My thought is that the flash memory was corrupted in the update.
After getting everything apart I found what looked like the flash chip on the main board. There was some paint on part of it and after scratching part of it off I could read the part number.
I found this part on DigiKey and confirmed it was a SPI 128MBIT NOR Memory IC. The data sheet no longer appeared to be there so after a quick search on the Wayback Machine I found the data sheet for this which had the pinout diagram, which is standard for most flash memory, and the operating voltage 2.7V - 3.6V.
I first needed something that could interact and speak SPI. If you aren’t familiar with SPI, Ben Eater has a great video on it. There are a wide variety of devices I found for this. Most are based on the FTDI single channel FT232H or dual channel FT2232H and for this reason I bought and also recommend the Adafruit breakout board which is the cheapest option of the bunch.
The connections that need to be made with the memory IC and the Adafruit FT232H are as follows:
| Adafruit FT232H | Memory IC |
|---|---|
| 3.3V | VCC (pin 8) |
| GND | GND (pin 4) |
| SPICS (D3) | CS# (pin 1) |
| MISO (D2) | SO/SIO1 (pin 2) |
| MOSI (D1) | SI/SIO0 (pin 5) |
| SCK/SCL (D0) | SCLK (pin 6) |
There are several places that mentioned that all pins of the memory IC should be connected, that would be reset and write protection pin. However, the datasheet for this particular chip seemed to suggest this wasn’t needed. It says, “The pin of RESET#, RESET#/SIO3 or WP#/SIO2 will remain internal pull up function while this pin is not physically connected in system configuration. However, the internal pull up function will be disabled if the system has physical connection to RESET#, RESET#/SIO3 or WP#/SIO2 pin.” Maybe I read that wrong but I don’t think this was related to any issues I encountered. Just note that this may be needed in certain situations.
There are several options for making connections with the flash IC. The easiest is if it is a removable DIP package where you could insert it into a socket. The flash chip in this case was in a SOIC package. This is surface mounted. Because I didn’t want to desolder and resolder the chip I opted to first try reading and writing the flash directly with it still on the board using a SOIC8 test clip, the 8 being the number of pins.
Another option not diving into desoldering is to use micro grabbers like these that clip onto the pins of the chip.
One thing I also tried was a 3D printed probing jig. Instructions for this can be found here. Note that these make use of acupuncture needles. Amazon and other sellers don’t seem to carry these. However, the exact same thing can be found for 3D printer nozzle cleaning.
One possibility is that other onboard components can interfere with reading and writing to the flash chip. To get around that you would need to desolder it. For this you would want a hot air station and also potentially a board preheater. Once the chip is desoldered you could use a socket like this one. It allows you to easily swap chips in and out without having to solder them.
Alternatively there are breakout boards like this that the surface mount chip can be soldered to.
The common software I found for dumping flash memory was flashrom. I found a post of someone trying to dump the same flash chip. The bad news is that they weren’t able to get flashrom working and opted to use UART. Unfortunately for me I was unable to identify any UART pins. The MX25L12833F did not appear to be supported in flashrom 1.2 which is the latest packaged binary version. Looking at the version on GitHub there is mention of the chip. So since the release in 2021 support for it appeared to be added. The following is a list of commands to compile and install the latest version from GitHub on the latest version of Ubuntu.
sudo apt install libpci-dev zlib1g-dev libftdi1-dev libusb-dev libusb-1.0-0-dev build-essential pkg-config
git clone https://github.com/flashrom/flashrom.git
cd flashrom
make
sudo make installHowever, after getting the latest version installed it didn’t seem to detect any flash device at all. This I determined to be due to the fact the clip wasn’t making good contact. After numerous times reseating the clip it finally recognized at least something but gave the following error.
At this point I started printing the probing jig mentioned above as the clip was annoying to use. The clip I had was an inexpensive one so maybe there are better ones out there but I didn’t have a great experience with them. Also, to eliminate any potential of anything else on the board interfering I tried desoldering the chip and then tried to use the flashrom tool again. However, I still got the same error. This made me think it was definitely a problem with the tool.
I started looking for alternative software to flashrom. There wasn’t much I found except for the Tigard wiki page. It mentions that flashrom is slow and two other viable alternatives are libmpsse and pyftdi. Of those they recommended pyftdi and even listed instructions on using it. Using the instructions I was able to dump the flash successfully. It’s good to do this twice and diff the two to make sure that you got a good read.
After getting the reference firmware from the working device I tried writing it to the bricked device. However, after trying twice to write it and read it back it was different from the reference in both attempts. Hoping for the best I tried powering it on and it didn’t work still. So far I haven’t achieved the original intent of fixing the camera. However, I have learned a decent amount and now have a copy of the firmware I can emulate in QEMU.