The Flaming Yinlips

furan-yinlips

No, that’s not a Playstation Vita up there, it’s a “Yinlips YDPG18A” portable game system. [Ian] found that his Yinlips was lacking in the flash memory department, so he fired up his soldering iron. The Yinlips is based on an Allwinner Sunxi series processor, and uses a standard TSOP48 footprint flash. There is some standardization in flash pin out and packages, so [Ian] picked up the largest pin compatible chips he could find – a pair of 256 gigabit (32 gigabyte) chips from Micron. Desoldering the existing flash proved to be a bit of an adventure as the flash was glued down. [Ian] also didn’t have his hot air gun handy, making things even more interesting. Careful work with a razor blade broke the glue bond.

It turns out that the soldering was the easy part. All flash chips have geometry, die count, page size, block count, sector size, etc. The geometry is similar to the geometry in a hard drive. In fact, just like in modern hard drives, a system will read some basic information before accessing the full storage array. In the case of NAND flash, the processor can access the first page of memory, and query the flash for its part number. Once the part number is known, the geometry can be determined via a lookup table. [Ian] checked the NAND table on github, so he knew going in that his flash chips were not supported. Due to the complexities of booting Allwinner processors into Linux or Android, the table and the NAND driver that uses it exist in several places. The bootloader’s axf file, U-Boot, and several flash application binaries sent from the PC based LiveSuit flash app all required modification. Most of these files were packed into a single flash image. [Ian] used imgrepacker to unpack the image, then opened the hex files. The fact that he knew what the original flash parameter tables looked like was key. He searched for an existing Micron flash table entry, and replaced the parameters with those of his new chips.

With all the files modified, [Ian] re-packed his flash image and sent it over. The Yinlips rewarded his hard work by continually resetting in a bootloop. [Ian] wasn’t going to give up though. He wired into the boot console, and discovered that a CRC check failure on one of his modified files was causing the reset. He then disassembled binary issuing the reset. Changing the return value of the CRC to always pass fixed the issue. [Ian's] now has a collagen infused Yinlips with 58GB of internal storage. Pretty good for a device that only started with 2GB.

Reading NAND flash with an Arduino

[HC] took a gander around the Googles and saw a number of people trying to read NAND flash chips with an Arduino. It’s an interesting problem; at 16 Megahertz, [HC] is looking at about 60 nanoseconds per instruction cycle, and flash chips normally operate around 20 ns. He got the build working, and was able to read the memory contents and ID of a flash chip.

Right now, it’s just a proof-of-concept to demonstrate that reading flash memory is possible. [HC] used an Arduino Mega to pull the manufacture ID off a flash chip. Because there isn’t exactly a whole lot of storage on an Arduino to hold Megabytes of data, so [HC] is looking for a way to pull data off his flash chip. He’s considering sending it over Ethernet or storing it on an SD card.

This isn’t the first time we’ve seen a roundabout way to use those cheap, ubiquitous NAND flash chips. Considering we’ve got a few dozen of them housed in unused thumb drives, [HC]‘s work shows a lot of potential. He posted a topic on his forum to see if there’s any interest in further developments, something we’d like to see.