In previous post I told how I bricked my ebook reader (Elonex 621EB, which most likely is rebranded Netronix eb600). After two days of searching around and testing, I managed to recover it. JTAG is something new to me. I’ve known the basics of it, but I’ve never used it for anything. So I had to learn how to use OpenOCD. Because of that, I had few problems during the recovering process.
I wanted to use BusPirate as JTAG-adapter, so I needed to recompile OpenOCD with –enable-buspirate flag.
At that point, OpenOCD and Bus Pirate worked correctly and it was time to get started with JTAG. I needed to find out which .cfg -files I should use with OpenOCD. I started with board/mini2440.cfg, because mini2440 and this ebook reader both have s3c2440 and rest of the hardware is about similar. The line 129 of mini2440.cfg (“jtag interface”) seemed to be incomplete and gave “Command requires more arguments” error ( Update: Maybe that line should be “jtag interface buspirate”?). I took a shortest path and commented that line hoping that it’s not needed. After testing the mini2440.cfg with line 129 commented, I had a thought that I can’t access the NAND, which is the place where U-Boot (and everything else) should be located. Nand -command of the OpenOCD gave me an error “Command requires more arguments”, no matter what arguments I used. I studied the config files in board/ -folder by reading them and reading OpenOCD’s documentations (most important in order to fix the “nand problem”: NAND Configuration Commands). Board’s .cfg file should have “nand device name driver target [configparams…]” command in it. There was “nand device s3c2440 0” in mini2440.cfg. That isn’t enough. Well, I left that line alone and wrote a new line: “nand device s3c2440.nand s3c2440 s3c2440.cpu”. That command should be placed before “init” command.
After those two modifications, everything was working without errors. It was time to begin flashing the U-Boot to the beginning of the NAND. In mini2440.cfg there was “flash_uboot” procedure which initialize the board, probes nand device 0 and prints NAND’s information, erases first 0x40000 bytes of the NAND and writes file “/tftpboot/u-boot-nand512.bin” to the beginning of the NAND. I moved my U-Boot.bin (dumped from the nand, before bricking the device) file to that location, ran OpenOCD, took a telnet connection to localhost post 4444 and ran “flash_uboot”. I knew writing the NAND would take long time, so I left the computer and came back after an hour. Considering that the Bus Pirate might be slower that “real” JTAG-devices, I gave it another 15 minutes to process. Even after that, it seemed like it was still writing the NAND. I thought something must be wrong. I closed OpenOCD with ^C, disconnected Bus Pirate from the computer and ebook reader, disconnected and reinserted the ebook readers battery and pushed the power button: IT BOOTED! That was great news. I still don’t know, was there problem with writing the U-Boot, or did the OpenOCD hang after finishing.
I was able to recover the ebook reader by using dumped U-Boot, but what if I didn’t have the dumped U-Boot? Well, the firmware updates are downloaded as self-extracting archives. U-Boot can be found in that archive, by going to the “files” folder and choosing one of the u-boot.bin* files. In my case, correct one might be the u-boot.bin-eb600em.
I will try to burn that to the NAND and try, if it works. Update: Yep, it works. It took one hour to flash u-boot.bin-eb600em to NAND using Bus Pirate, OpenOCD didn’t hang. U-Boot file from firmware update archive is 163 kB and dumped U-Boot is 512 kB. Writing 512 kB would take about 3 hours. But why did the dumped U-Boot work after writing only little over 1/3 of it to NAND? The U-Boot is placed in the beginning of the file and takes only 163 kB of space and rest of the file consists of 0xFF (all the bits are ones). Erasing the NAND (or part of it) changes bits from zero to one. Zero can be changed to one only by erasing the NAND and one can be changed to zero only by writing to it. Therefore there is no need to write rest of the file, if there are only ones left.
Conclusion: these ebook readers can be recovered from failed bootloader update, even without previously dumped U-boot! File/ -folder also has u-boot.tmp* files in it, maybe those are for loading the U-Boot to ram, instead of the NAND? Now I have way to recover my device, I don’t have to be so careful anymore. I can experiment with “wrong” bootloaders and kernels without worrying that I’ll brick the device.