JioRouter AX6000 (JIDU6101): Workaround for initramfs kernel panic during installation

I wanted to document my installation experience in case anyone else runs into the same issue.

Background

Initially, I assumed the router had a hardware fault because the exact same Wi-Fi errors were also present in the stock firmware .

With a UART connected, the stock firmware would spend a long time repeatedly trying to initialize the Wi-Fi subsystem, producing messages such as:

mt798x-wmac 18000000.wifi: Retry message 00000002
mt798x-wmac 18000000.wifi: Message 00000002 timeout
mt798x-wmac 18000000.wifi: Failed to start WA firmware

Eventually, the stock firmware would finish booting, but without any working Wi-Fi.

Because of that, my first assumption was that the wireless hardware itself had failed.

UART was the actual trigger

After quite a bit of debugging, I discovered that the presence of the UART connection itself was causing the Wi-Fi initialization failures .

After searching around, I found that this is a known quirk on a number of MediaTek-based routers, where having the UART attached can interfere with Wi-Fi initialization.

Without UART connected, the stock firmware booted normally with working Wi-Fi.

Unfortunately, UART is required for the initial OpenWrt installation process, so this still left me unable to boot the initramfs image successfully.

The problem with the OpenWrt initramfs

Following the installation guide, I booted the initramfs over TFTP:

setenv ipaddr 192.168.1.1
setenv serverip 192.168.1.2
tftpboot 0x46000000 openwrt-mediatek-filogic-jiorouter_ax6000-jidu6101-initramfs-kernel.bin
fdt addr $(fdtcontroladdr)
fdt rm /signature
bootm

Unlike the stock firmware, the OpenWrt initramfs didn't simply continue without Wi-Fi—it crashed with a kernel panic during Wi-Fi initialization.

The UART log ended with:

mt798x-wmac 18000000.wifi: Failed to start WA firmware

Kernel panic - not syncing: Oops: Fatal exception in interrupt

This meant I couldn't even reach the initramfs shell to run sysupgrade .

Workaround

To get past this, I built a custom initramfs image with Wi-Fi disabled in the device tree.

I only added the following to mt7986a-jiorouter-ax6000-jidu6101.dts :

&wifi {
        status = "disabled";
};

No other changes were made.

With this modified initramfs:

  • the router booted successfully
  • Ethernet worked normally
  • I was able to copy the sysupgrade image to /tmp
  • sysupgrade completed successfully

The Wi-Fi-disabled initramfs is only used as a temporary installer, so losing wireless support in that environment isn't an issue.

Flashing the normal OpenWrt image

I flashed the standard OpenWrt sysupgrade image (with Wi-Fi enabled), not a modified one.

After installation, UART is no longer needed, so the Wi-Fi initialization issue caused by having the serial connection attached is no longer relevant.

One thing to keep in mind

In my case, the installation wasn't complete after the first successful sysupgrade .

After rebooting, the router didn't boot into OpenWrt. Instead, U-Boot entered its web failsafe path and dropped me back to the U-Boot prompt.

I simply repeated the process:

  1. Boot the Wi-Fi-disabled initramfs over TFTP.
  2. Flash the standard sysupgrade image again.
  3. Reboot.

After the second flash, the router booted normally into OpenWrt and everything worked as expected.

I'm not sure why the first flash wasn't sufficient in my case, but if someone else runs into the same behaviour, it's worth trying the sysupgrade a second time before assuming the installation has failed.

Hopefully this saves someone else a few hours of debugging if they encounter the same combination of UART-induced Wi-Fi failures and initramfs kernel panic during installation.

Is there a bootargs variable ?

Tried adding/setting modprobe.blacklist=mt7986 in bootargs prior to bootm ?

Don't do saveenv, you don't want the change to be permanent.

I tried creating a temporary bootargs variable before bootm, but it doesn't appear to be used

For example:

setenv bootargs "TEST123"

After booting, /proc/cmdline is still:

boot_param.boot_image_slot=1 boot_param.upgrade_image_slot=0 boot_param.dual_boot