Confirmed fix: downgrading from Firmware 4/Kernel 1.05 back to Firmware 3 (tested & working)
Note: I used Claude AI to help to articulate this write-up more clearly than my English allows. All technical findings and the patch itself are real and verified on hardware.
I got tired of waiting for EZ-Flash to acknowledge this issue, so I reverse-engineered the Kernel 1.04 binary to understand why a normal reflash doesn't restore the firmware and found a way to force the downgrade. Games that were freezing on both GBA and DS Lite are stable again on my unit.
Understanding the problem
When you reflash the stock Kernel 1.04 over the broken 1.05, you'll notice the kernel menu updates (K:1.04 shows up), but the firmware stays at FW4. This is what wolfmanvid01 reported, and it's not a glitch, it's by design. The kernel and the FPGA firmware are two separate things: the kernel is the menu software (ARM Thumb code running on the GBA's CPU), while the firmware is the FPGA bitstream that controls the cart's hardware (NOR flash, SD interface, etc). The kernel always gets written to the cart, but the FPGA firmware goes through a version check first.
What the reverse engineering revealed
The FPGA firmware (FW3, ~454KB) is embedded inside ezairkernel.bin as a binary blob starting at offset 0x195000. During boot, the function Check_FW_update at offset 0x0A1160 decides whether to flash it. Here's the logic, disassembled from the actual binary:
0x0A1162: BL Read_FPGA_ver ; read current FW version from the FPGA
0x0A1170: R3 = version & 0xF000 ; extract hardware revision nibble
0x0A117A: CMP R3, 0xC000 ; check if it's the expected revision
0x0A117C: BNE exit ; wrong hardware revision → skip
0x0A117E: R3 = version & 0xFF ; extract firmware version number
0x0A1182: CMP R3, #2 ; ← GATE CHECK: compare against 2
0x0A1184: BHI exit ; if current FW > 2 → skip, don't flash
0x0A118E: MOV R1, #3 ; ← VERSION LABEL: "we're installing FW3"
0x0A1192: (load blob address, size, CRC32)
0x0A1198: BL FW_update ; actually write the firmware
There are
two protections preventing the downgrade:
- The gate check (offset 0x0A1182): CMP R3, #2 followed by BHI exit. This reads the firmware version currently on the FPGA. If it's greater than 2, the function exits without even attempting to flash. This was originally set to 2 so that FW3 would install over FW1 and FW2 but wouldn't redundantly reflash over itself (FW3). With FW4 on the cart, 4 > 2 is true, so it bails out — the FW_update function is never called.
- The version label (offset 0x0A118E): MOV R1, #3 sets the version number passed to FW_update. Even if you got past the gate, FW_update would see "installing FW3 over FW4" and could reject it as a downgrade.
This is also why the kernel portion always updates regardless — the kernel write has no version gate. Only the FPGA firmware does.
The fix: 3 bytes
Starting from the official Kernel 1.04 binary (ezairkernel.bin, SHA1 dd3c9e089d8142193d08b71555ba3cec68cbc03f, available on the GBATemp downloads page), change exactly 3 bytes:
| Offset | Original | Patched | Instruction change | Purpose |
|---|
| 0x0A01A3 | 34 | 36 | — | Version string: "K:1.04" → "K:1.06" (cosmetic only) |
| 0x0A1182 | 02 | 05 | CMP R3, #2 → CMP R3, #5 | Raises the gate threshold — FW4 (4 > 5 = false) now passes through instead of being blocked |
| 0x0A118E | 03 | 05 | MOV R1, #3 → MOV R1, #5 | Version label passed to FW_update — now "V05", higher than the installed FW4, so the flash routine accepts it |
Nothing else is modified. The embedded FPGA firmware blob (the actual FW3 payload at offset 0x195000, 464,544 bytes) and its CRC32 checksum (0x0BE63A59) are completely untouched. The kernel verifies this CRC before writing anything to the FPGA, so integrity is preserved.
You can verify the patch yourself with any hex editor — only these 3 bytes should differ from the stock 1.04 file.
Step-by-step instructions
Step 1 — Flash the patched kernel to force the downgrade:
- Copy the patched ezairkernel.bin to the root of your SD card
- Power off the console completely
- Hold R and power on — keep holding until the firmware update screen appears
- You will see: "Current firmware version: V04 — Will be updated to version: V05" — this is correct and expected. Press A to proceed
- Wait for the process to complete
- Go to the last page of the kernel menu and check the version
- It should now read FW:3 K:1.06 — this confirms the FPGA firmware has been successfully downgraded from FW4 back to FW3
If it still shows FW:4, the downgrade did not take on your unit, do not retry repeatedly (see disclaimer below).
Step 2 — Reflash the original unpatched Kernel 1.04:
This step is important. After the downgrade, you will notice that
every time you power on the console, the firmware update screen pops up again, showing "V04 will be updated to V05". This happens because the patched kernel's gate threshold (5) is higher than the now-installed FW3 (3), so it keeps trying to reflash FW3 over itself in an infinite loop on every boot.
To stop this:
- Delete the patched ezairkernel.bin from your SD card
- Copy the original unpatched Kernel 1.04 ezairkernel.bin (the one from the GBATemp downloads page) to the root of your SD card
- Hold R and power on to reflash the kernel
- The boot loop will stop — the stock 1.04 kernel sees FW3 already installed (3 > 2 = true), correctly determines there's nothing to update, and skips straight to the menu
Your final state will be
FW:3 K:1.04 — exactly what the cart had before the broken 1.05 update ruined everything.
Step 3 — Format your NOR and rewrite ROMs:
Before playing, format/delete all ROMs from the NOR and rewrite them from scratch. The FW4 firmware used a different NOR management scheme (free-order deletion, real-time usage tracking), and ROMs written under FW4 may not be readable by FW3.
Disclaimer
This worked on my unit. Back up your SD card before attempting. Be aware that some users have documented NOR degradation on the Air from repeated firmware writes, each flash wears the NOR slightly. If the patch doesn't work on your cart, do not retry in a loop.
I'll upload the pre-patched binary file as soon as I can so you don't have to hex-edit it yourself. In the meantime, the 3-byte patch is simple enough to apply with any hex editor.
Would love to hear confirmation from other affected users, anyone else stuck on FW4. The more confirmations, the harder it is for EZ-Flash to keep ignoring this.
