🚀 Remix Mini PC Project: Progress Update and Current Status

🔹 Intro & status

The Remix Mini PC was originally designed as a compact Android-based device, but my goal in this project has been to repurpose it with alternative firmware, enabling it to run an open-source operating system like Armbian. This journey has involved firmware modifications, bootloader experimentation and overcoming various hardware challenges. In this post, I’ll document the progress so far, the obstacles encountered, and the solutions explored along the way.

---

🔹 Initial Challenges and Experimentation

🛠 Understanding the Remix Mini Hardware

• One of the biggest roadblocks was that my device lacked NAND/eMMC storage, meaning I had to figure out how to boot directly from an SD card. This led to investigating the Allwinner SoC boot sequence to determine how it prioritizes storage devices. For example, unlike traditional x86 PCs, which default to the BIOS boot order, Allwinner SoCs attempt to boot from eMMC first, then SD, and lastly USB if configured
• I examined the Remix Mini’s internal hardware, including the Allwinner SoC, memory configuration, and peripheral support, to understand its limitations and potential modifications. This included verifying if the SPI flash could be used as an alternative boot method
• Since eMMC was not an option, any firmware or bootloader modifications had to be stored externally, adding complexity to keeping configurations persistent. I had to rely on manually reloading U-Boot each time the system booted up

🔄 Experimenting with Alternative Firmware

• Testing U-Boot modifications was essential for enabling SD card boot. I needed a compatible U-Boot version that correctly initialized the hardware and passed control to the OS. For instance, certain U-Boot builds failed to recognize the SD card interface due to missing device tree configurations
• I evaluated Armbian and Tow-Boot, both of which support Allwinner-based devices. Armbian seemed promising for broader functionality, while Tow-Boot provided a lightweight alternative that simplifies booting external media
• Running FEL mode for external firmware loading allowed safe experimentation with different U-Boot versions before making permanent changes. This method was particularly useful when my SD card failed to boot due to an incorrect bootloader configuration
• I also explored alternative Allwinner A64-based SoCs, which share similar hardware and firmware compatibility with the Remix Mini:
  • Pine64 / Pine 64 Plus – Community-supported, with mainline U-Boot and Linux support
  • Pine64 LTS – Industrial-focused, longer support cycle
  • BananaPi M64 – Similar A64 SoC but with additional peripheral support
  • NanoPi A64 – Compact form factor, known for good mainline kernel support
  • OlimexA64 - OLinuXino – Fully open-source hardware design
  • SopineA64 Compute Module – Modular compute approach, similar to Raspberry Pi CM
  • OrangePi3 – More powerful but uses the same A64 SoC architecture
  • Pine H64 – More advanced, but some differences in bootloader configurations Lessons learned from this project could be extended to these devices, making this effort valuable for a broader community

---

🔹 Bootloader Modifications and Troubleshooting

💾 Erasing and Modifying the eMMC

• I attempted to wipe the existing firmware using standard Linux tools like dd, blkdiscard, and flash_erase, but ran into write protection and locked eMMC sectors. Even forcing a secure erase via mmc-utils failed due to hardware-level protections
• Exploring Odin4 as a potential flashing tool was another step, but its compatibility with Allwinner hardware was limited, leading me to focus on direct SD card modifications instead. The main limitation was that Odin is more tailored for Samsung devices and lacked Allwinner-specific NAND flashing support

🚀 Booting from an SD Card

• Successfully setting up a bootable Armbian image ensured that the system had all the necessary kernel components and drivers. A key step was ensuring the correct uEnv.txt configuration was present to direct the kernel to the right storage device
• A key milestone was flashing a custom U-Boot to the SD card, as the stock bootloader wasn’t designed to prioritize SD boot when no eMMC was present. Some builds resulted in kernel panic due to missing device tree configurations
• I manually modified U-Boot environment variables to force SD card boot, ensuring that mmc0 was always the first boot target. This was done using:

  setenv boot_targets mmc0 usb0 pxe dhcp
  saveenv

However, saveenv failed due to missing storage, leading to additional troubleshooting

🔒 Making U-Boot Environment Changes Persistent

• The absence of eMMC meant that saveenv was failing due to a missing FAT partition. U-Boot typically stores its environment in the first available bootable FAT partition, which had to be manually created
• I fixed partition table corruption by recreating partitions in Linux with fdisk and ensuring correct filesystem formatting (vfat for boot, ext4 for root filesystem). Without a properly formatted boot partition, U-Boot would fail to recognize saved environment variables
• GPT vs MBR partitioning was tested, and MBR proved more reliable for compatibility with legacy U-Boot versions. Some U-Boot builds struggled with GPT, especially older versions lacking EFI support

---

🔹 Hardware Limitations and Potential Physical Solutions

🚧 The Problem: Locked or Corrupted NAND/eMMC

• The Remix Mini PC's eMMC is either locked, corrupted, or not recognized by conventional erasing methods. Attempts to read/write the device using fdisk resulted in I/O errors
• Standard erasure tools (dd, blkdiscard, flash_erase, FEL mode) have failed to restore full write functionality. This suggests either hardware damage or deeply embedded firmware-level restrictions
• This means I can’t store persistent U-Boot changes or format the internal storage from within the OS. Even attempting a forced format via mke2fs -F /dev/mmcblk0p1 returned write protection errors

🔌 The Physical Solution: JTAG, OpenOCD, and External NAND Programming

• JTAG Debugging: By connecting a JTAG interface, I could gain direct access to the NAND storage, bypassing firmware-level restrictions. This would allow reading/writing at the lowest level possible
• OpenOCD: The Open On-Chip Debugger (OpenOCD) may allow unlocking or reflashing the NAND chip at a low level by interfacing directly with the SoC’s debug pins
• Physical NAND Removal and Reprogramming:
  • If all else fails, I may need to desolder the NAND chip and reprogram it externally using a specialized NAND adapter
  • Using a NAND adapter and programmer, I could fully erase and reflash the chip before resoldering it
  • While extreme, this would give me full control over the storage device, ensuring it can be formatted and rewritten. A similar approach has been used for reprogramming locked bootloaders on older embedded devices

---

Enjoying the content? If you'd like to support my work and keep the ideas flowing, consider buying me a coffee! Your support means the world to me!