Allwinner A133 Firmware Work File

A standard Allwinner A133 firmware image (e.g., for Android or Tina Linux) follows a fixed partition scheme. The sys_partition.fex file defines the layout:

| Partition | Offset | Size | Content | |-------------|--------|--------|-----------------------------| | boot0 | 8KB | 24KB | First stage bootloader | | boot0-rescue| 32KB | 24KB | Backup boot0 | | env | 64KB | 16KB | U-Boot environment | | boot | 16MB | 32MB | Linux kernel + DTB | | rootfs | 48MB | 512MB+ | SquashFS/ext4 root filesystem| | recovery | - | 32MB | Recovery kernel | | UDISK | - | Remainder | User data |

Writing this layout can be done via FEL (using live-suit or sunxi-fel spiflash commands), via fastboot (fastboot flash), or by directly writing raw images to the eMMC/SD card with dd. allwinner a133 firmware work

There is an ongoing effort to mainline A133 support in Linux kernel 6.x. However, for firmware work, stick to the BSP.

Verdict: Use the BSP for production devices. Use mainline only for learning or headless servers.

After DRAM is initialized, boot0 loads U-Boot (or a vendor-modified fork) from the storage device into DRAM and jumps to it. U-Boot on the A133 is highly customized and includes: | Tool | Purpose | Availability | |

A typical U-Boot environment on an A133 tablet might look like:

baudrate=115200
bootcmd=mmc dev 0; load mmc 0:1 0x40000000 boot.scr; source 0x40000000
bootdelay=1
stdin=serial,usbkbd
stdout=serial,vidconsole

The boot script (boot.scr) ultimately loads the Linux kernel (zImage or Image.gz) and the board DTB into memory and calls bootz or bootm.

Every Allwinner chip wakes up staring into the void. The first piece of firmware, the BootROM, is etched into the silicon during manufacturing. Its only job is to look for a storage medium (like an SD card or eMMC) and load the next stage. Verdict: Use the BSP for production devices

For years, developers relied on a tool called sunxi-tools. It was the skeleton key for Allwinner chips. If you bricked a device, you held a button, plugged in a USB, and sunxi-fel would put the device into FEL mode, allowing you to upload code to RAM and resurrect the tablet.

When the A133 arrived, the workflow that had worked for the A64, H3, and H6 suddenly failed.

The A133 introduced a secure boot mechanism that was far more aggressive than its predecessors. The BootROM expected a specific header structure, often encrypted with a secure key (TOC0 header). For the factory engineers in Shenzhen, this was a minor inconvenience—they had the keys. For the open-source community and repair technicians, this was a wall.

The first hurdle in A133 firmware work was simply getting the computer to recognize the tablet. The "FEL" mode identifier changed. Drivers had to be patched. The initial weeks of A133 work were spent not writing code, but simply shouting into the void of the USB bus, waiting for the chip to shout back.