Subsequently he instead sent it to [Buy it Fix it] on YouTube for an attempted repair, which at the very least would be a less costly option. These systems use a signal generator connected to the cable, with a separate detector wirelessly tracking this signal. By itself that doesn’t sound too complex, but as it turns out it wasn’t quite so straightforward to diagnose.
After eliminating a basic power or display issue, the SoC’s boot sequence was traced, including reading from the 128 MB NAND Flash. At first glance the unit appeared to be trying to boot and work as normal, which was confirmed after finding a serial port and seeing the log output on it. This showed that the NAND Flash’s boot image failed validation due to apparent corruption.
After desoldering the TSOP 48 Flash package and stuffing it into a reader, at first glance the data on it looked fine. After a tragic detour with Google’s Gemini chatbot that led to a lot of wasted time, the solution that the human intelligence came up with was to crack open the tracer unit in the set and ogle at its firmware, in particular the bootloader.
Comparing the two Flash dump files, there were a few flipped bits in the bootloader section, likely due to cells in the Flash having lost their charge. Writing the generator’s Flash with a corrected image led to it booting up happily again into the Linux 2.6-based firmware, seemingly no worse for wear. Of course, one has to consider here that the NAND Flash IC clearly has a few leaky cells in it, so replacing it with a fresh one could be a good idea for a long-term fix.
You must be logged in to post a comment Login