I accidentally bricked my Mini M8S II too a while ago playing with experimental images and decided to take shot of unbricking it. My symptoms were no boot, no display output, no USB or SD boot, no USB Burning device showing up, and toothpick methods were unsuccessful. Basically every usual unbricking method that should be tried first was unsuccessful. The optical jack was still giving a red light so there was still a spark of life. The goal is to write a working firmware to the eMMC NAND flash to get the box working again.
At last, I stumbled upon various threads about shorting to unbrick. This process is not well documented considering the vast amount of brands and even revision within the same product. What you see on images is no guarantee for success. People are looking for possible shorting points with risk of shortening the lifespan of their device or even damaging it permanently. But this thread did give me an idea. Why not erase the eMMC instead of shorting it? The point of eMMC pin shorting is to disable the eMMC so the device can't boot and enables SD boot again. Erasing the eMMC also prevents it from booting so it should enable SD boot again to restore the hardware using the usual methods again. And luckily this hypothesis worked in my case.
First I needed to be able to interface with the device in this bricked condition and see if it even works, especially when all other usual 'blind' unbricking methods fail. So I opened the device and soldered some wires to the board to connect it with my USB-TTL converter. They kinda a must have in troubleshooting and really cheap. You can buy A FTDI based USB-TTL converter with support for 3.3V and 5V circuits for just a few bucks on your favorite online China store. With a serial interface you can exactly see what your device is doing and interface with some low-level system functionality. The M8S II serial interface consists of 4 holes in a row at the board edge of the SD card reader. The pin out starting with the square mark: GND (connect to USB-TTL GND), TxD (connect to USB-TTL RxD), RxD (connect to USB-TTL TxD) and VCC (do not connect to USB-TTL). The baudrate is the usual 115200 with the kind of devices.
I used PuTTY to open the serial connection and powered on the device. To see what's going on and what failed booting, I searched for a normal boot log of a functioning M8S II and found this topic. Apparently, there are 5 boot stages. The stages are B1, B2, B30, B31 and B33. People stuck in B1 without working SD boot are doomed. After B1, the booting magic happens involves the eMMC memory. Stuck between stages B2 and B31 doesn't really make sense to me, assuming failing to load u-boot (stage B33) enables SD-boot again. That's the whole point of doing the shorting method: disabling the eMMC so it can't proceed from B1 into B2 and further and thus enabling SD boot again. I could be wrong tho, so I'm hoping you are all here stuck on a bricked device that passes into u-boot (stage B33) but fails to start the kernel / system image, with no recovery available via USB / SD boot or USB burning. Probably caused by flashing a half working incompatible u-boot, idk. At least u-boot is working to issue some commands reaching this point, otherwise it should be already possible to unbrick the device using the conventional methods.
A full memory backup could be loaded into memory using the build in u-boot TFTP client to write it contents to the eMMC memory. But I don't have such a backup so I went with erasing my eMMC instead of shorting it. I don't know if there is some extra data stored on the memory but the usual stuff for embedded devices to boot are included in the firmware images: u-boot, kernel and system image. All can be reflashed. It's possible the eMMC contains additional partitions containing such as wireless calibration data and MAC addresses, but big chance those get regenerated if this is a thing with Amlogic devices. I disconnect all USB sticks and SD cards from my device and played around with the 'mmc' command to find and select my eMMC storage. Then I used the 'mmc erase 0 1000000000' command to erase the full eMMC NAND flash, give or take a few zero's on the last digit. You can fill in the exact bytes to erase using the total size of your eMMC flash, or just hit it with a big number and remove a digit when it gives an error.
After a few minutes the erasing was done and I powered cycled my device. The serial console indicated the boot process was stuck in B1 now. An expected result and SD booting should also works again. I made a bootable SD card using the original firmware found online (update_MINIM8SII_rv112_megabox_20170320.img for Mini M8S II) and extracted the firmware using level 1 extraction with the Amlogic Customization Tool. I renamed the extracted bootloader.PARTITION, recovery.PARTITION and meson1.dtb files to u-boot.bin, recovery.img and dtb.img respectively. Burn Card Maker tool (v2.0.2) was used to flash u-boot.bin to the SD card (note that the u-boot.bin file is not visible in the file picker by default). I then copied all three renamed files to the SD card (including u-boot.bin again). The device successfully recognized the SD card and used it as booting device. It didn't boot to an OS because I didn't include a system image. But there it was, device unbricked!
I also noticed some logging on the serial console about USB burning being available again. I thought why not, let's test that and flash the original firmware mentioned earlier to the eMMC. I connected the device with a male-male USB A cable to my computer. The Mini M8S II was immediately recognized by Windows again. The firmware was flashed using the Amlogic USB Burning Tool (v2.1.7.3). In case you might be stuck at some % during the flashing.. Try to download the firmware again and use checksums to verify the download. You even might have damaged memory or hardware. It's basically a blank new start by erasing the eMMC, assuming you didn't screw up somewhere in the process. Luckily for me, the original firmware flashed perfectly.. To be replaced with a custom firmware in a matters of minutes.
At last, I stumbled upon various threads about shorting to unbrick. This process is not well documented considering the vast amount of brands and even revision within the same product. What you see on images is no guarantee for success. People are looking for possible shorting points with risk of shortening the lifespan of their device or even damaging it permanently. But this thread did give me an idea. Why not erase the eMMC instead of shorting it? The point of eMMC pin shorting is to disable the eMMC so the device can't boot and enables SD boot again. Erasing the eMMC also prevents it from booting so it should enable SD boot again to restore the hardware using the usual methods again. And luckily this hypothesis worked in my case.
First I needed to be able to interface with the device in this bricked condition and see if it even works, especially when all other usual 'blind' unbricking methods fail. So I opened the device and soldered some wires to the board to connect it with my USB-TTL converter. They kinda a must have in troubleshooting and really cheap. You can buy A FTDI based USB-TTL converter with support for 3.3V and 5V circuits for just a few bucks on your favorite online China store. With a serial interface you can exactly see what your device is doing and interface with some low-level system functionality. The M8S II serial interface consists of 4 holes in a row at the board edge of the SD card reader. The pin out starting with the square mark: GND (connect to USB-TTL GND), TxD (connect to USB-TTL RxD), RxD (connect to USB-TTL TxD) and VCC (do not connect to USB-TTL). The baudrate is the usual 115200 with the kind of devices.
I used PuTTY to open the serial connection and powered on the device. To see what's going on and what failed booting, I searched for a normal boot log of a functioning M8S II and found this topic. Apparently, there are 5 boot stages. The stages are B1, B2, B30, B31 and B33. People stuck in B1 without working SD boot are doomed. After B1, the booting magic happens involves the eMMC memory. Stuck between stages B2 and B31 doesn't really make sense to me, assuming failing to load u-boot (stage B33) enables SD-boot again. That's the whole point of doing the shorting method: disabling the eMMC so it can't proceed from B1 into B2 and further and thus enabling SD boot again. I could be wrong tho, so I'm hoping you are all here stuck on a bricked device that passes into u-boot (stage B33) but fails to start the kernel / system image, with no recovery available via USB / SD boot or USB burning. Probably caused by flashing a half working incompatible u-boot, idk. At least u-boot is working to issue some commands reaching this point, otherwise it should be already possible to unbrick the device using the conventional methods.
A full memory backup could be loaded into memory using the build in u-boot TFTP client to write it contents to the eMMC memory. But I don't have such a backup so I went with erasing my eMMC instead of shorting it. I don't know if there is some extra data stored on the memory but the usual stuff for embedded devices to boot are included in the firmware images: u-boot, kernel and system image. All can be reflashed. It's possible the eMMC contains additional partitions containing such as wireless calibration data and MAC addresses, but big chance those get regenerated if this is a thing with Amlogic devices. I disconnect all USB sticks and SD cards from my device and played around with the 'mmc' command to find and select my eMMC storage. Then I used the 'mmc erase 0 1000000000' command to erase the full eMMC NAND flash, give or take a few zero's on the last digit. You can fill in the exact bytes to erase using the total size of your eMMC flash, or just hit it with a big number and remove a digit when it gives an error.
After a few minutes the erasing was done and I powered cycled my device. The serial console indicated the boot process was stuck in B1 now. An expected result and SD booting should also works again. I made a bootable SD card using the original firmware found online (update_MINIM8SII_rv112_megabox_20170320.img for Mini M8S II) and extracted the firmware using level 1 extraction with the Amlogic Customization Tool. I renamed the extracted bootloader.PARTITION, recovery.PARTITION and meson1.dtb files to u-boot.bin, recovery.img and dtb.img respectively. Burn Card Maker tool (v2.0.2) was used to flash u-boot.bin to the SD card (note that the u-boot.bin file is not visible in the file picker by default). I then copied all three renamed files to the SD card (including u-boot.bin again). The device successfully recognized the SD card and used it as booting device. It didn't boot to an OS because I didn't include a system image. But there it was, device unbricked!
I also noticed some logging on the serial console about USB burning being available again. I thought why not, let's test that and flash the original firmware mentioned earlier to the eMMC. I connected the device with a male-male USB A cable to my computer. The Mini M8S II was immediately recognized by Windows again. The firmware was flashed using the Amlogic USB Burning Tool (v2.1.7.3). In case you might be stuck at some % during the flashing.. Try to download the firmware again and use checksums to verify the download. You even might have damaged memory or hardware. It's basically a blank new start by erasing the eMMC, assuming you didn't screw up somewhere in the process. Luckily for me, the original firmware flashed perfectly.. To be replaced with a custom firmware in a matters of minutes.
?
Comment