MikroTik Chateau 5G R17 ax

The MikroTik Chateau 5G R17 ax is a 5G LTE router with an IPQ6010 SoC, Wi-Fi 6 on both bands, four gigabit ports, one 2.5 GbE port and an internal Quectel RG650E-EU 5G modem on USB.

Ordering code S53UG+5HaxD2HaxD&RG650E-EU. The marketing name “Chateau 5G R17 ax” is what the product is sold under; the ordering code is what the device reports in RouterBOOT's hard_config.

This is the first MikroTik device on the qualcommax target.

MikroTik sells the same board under two ordering codes, S53UG+5HaxD2HaxD&RG650E-EU and S53UG+5HaxD2HaxD-TC&RG650E-EU. The first of the two is what this page was written on. Caveats highlighted in Common Procedures for MikroTik RouterBoard Products apply.

There is no dedicated WAN port. All five sockets are LAN by default; the uplink is the modem.

All LEDs are plain GPIO LEDs and can be driven from /sys/class/leds.

Under RouterOS the five LTE bars are driven by the firmware's signal strength indicator. OpenWrt has no equivalent trigger; the LEDs are exposed as ordinary LEDs so a connection manager or a shell script can drive them.

The reset button also triggers RouterBOOT's etherboot when held during power-up, see below.

The modem's power enable and reset lines are exported as GPIOs:

# cut power to the modem
echo 0 > /sys/class/gpio/modem-power/value
# power it back on (1 is the boot default)
echo 1 > /sys/class/gpio/modem-power/value
 
# or reset it without cutting power
echo 1 > /sys/class/gpio/modem-reset/value; sleep 1
echo 0 > /sys/class/gpio/modem-reset/value

The modem takes a while to come back: expect the USB device to reappear somewhere between one and two minutes after powering it on.

Useful when the RG650E gets stuck: the module does not always recover from a USB reset alone.

Not required for installation, but the fastest way to see what RouterBOOT and the kernel are doing.

The header is silkscreened SPI/UART on the board, with LD12 next to it. The case has to be opened to reach it.

                  SPI/UART            (viewed from the BACK)

        1     2     3     4     5
        o     o     o     o     o     <- top row
        o     o     o     o     #     <- bottom row
        6     7     8     9    10     # = square pad

The square pad is pin 10, bottom right. That identifies the orientation even when the silkscreen is unreadable.

115200 8N1, no flow control, 3.3 V TTL.

With TX (pin 3) connected you get an interactive console (Please press Enter to activate this console.). With RX alone you get the boot log, which is enough for most troubleshooting.

RouterBOOT prints no text at all on the serial console. No banner, no version, no menu, and no “press any key” prompt to interrupt the boot. Do not go looking for a RouterBOOT shell here - boot settings are changed either with the reset button or from a running OpenWrt through /sys/firmware/mikrotik/soft_config/.

What you do see, in order:

1. The Qualcomm PBL/SBL1 log (Format: Log Type …, the B - / D - / S - lines). That comes from the SoC boot ROM, not from MikroTik.
2. Booting from NAND: terse stage markers L1, L2, L3, … and nothing else. That is RouterBOOT's entire contribution.
3. Netbooting: nothing at all between the SBL log and the loaded image.
4. The LZMA loader's own output, prefixed [chateau-lzma], reporting its load address, the unpack source and target, the DTB magic and the watchdog handoff.
5. The kernel, starting with earlycon.

Captured from the device, elisions marked …:

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
S - QC_IMAGE_VERSION_STRING=BOOT.XF.0.3-00090-IPQ60xxLZB-2
S - IMAGE_VARIANT_STRING=IPQ6018LA
S - OEM_IMAGE_VERSION_STRING=crm-ubuntu47
S - Boot Interface: SPI
S - Secure Boot: Off
S - Boot Config @ 0x000a602c = 0x000002e1
S - JTAG ID @ 0x000a607c = 0x0013a0e1
…
B -      3413 - PBL, Start
B -       592 - bootable_media_detect_entry, Start
B -      4339 - bootable_media_detect_success, Start
…
B -   1539396 - SBL1, End
D -   1244034 - SBL1, Delta
S - Flash Throughput, 1000 KB/s  (1612581 Bytes,  852922 us)
S - Core 0 Frequency, 800 MHz
S - DDR Frequency, 466 MHz

L1
L2
L3
…
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x51af8014]
[    0.000000] earlycon: msm_serial_dm0 at MMIO 0x00000000078b1000 (options '115200n8')

Three lines from the SBL header are worth knowing:

• Secure Boot: Off - the secure-boot fuses are not blown. That is why RouterBOOT accepts unsigned ELF images at all.
• Boot Interface: SPI - RouterBOOT lives in the SPI-NOR, not in the NAND that installation overwrites.
• Core 0 Frequency, 800 MHz / DDR Frequency, 466 MHz - the state at SBL time; the kernel raises the CPU to 1.8 GHz later. SBL1 itself accounts for about 1.25 s of the roughly 60 s a flash boot takes.

Two caveats about this capture: every L1…L9 cycle in it is a failed NAND boot from a debugging session, so it does not show at which marker a good boot ends. And the loader messages in it still carry their earlier German wording - the sequence is unchanged, the strings have since been reworded.

RouterBOOT loads bare, unsigned ARM64 ELF images only - no FIT, no uImage. The kernel partition is an 8 MiB yaffs filesystem, while the raw arm64 kernel is around 14 MiB. OpenWrt therefore wraps the kernel in a self-extracting LZMA loader that carries the DTB with it.

Two consequences:

• mtd write does not work on the kernel partition. yaffs keeps its metadata and ECC in the OOB area, which mtd does not write. sysupgrade uses yafut instead. This is handled automatically; it only matters if you try to flash by hand.
• Recovery is always available. RouterBOOT lives in a separate SPI-NOR flash that is never touched during installation, so etherboot and Netinstall stay reachable even after a failed write.

RouterBOOT obtains an address over BOOTP and then loads an ELF image over TFTP into RAM. Nothing is written to flash, so a power cycle returns the device to its previous state. This is the safe way to try an image before committing to it.

Connect a machine directly to ether1 of the Chateau. Make sure there is no second DHCP server on that segment.

IFACE=eth1            # the interface facing the Chateau
IMAGE=openwrt-qualcommax-ipq60xx-mikrotik_chateau-5g-r17-ax-initramfs-kernel.bin
 
mkdir -p /srv/tftp && cp "$IMAGE" /srv/tftp/chateau.elf
ip addr flush dev "$IFACE"
ip addr add 192.168.1.10/24 dev "$IFACE"
ip link set "$IFACE" up
 
dnsmasq --no-daemon --port=0 \
        --interface="$IFACE" --bind-interfaces --except-interface=lo \
        --dhcp-range=192.168.1.100,192.168.1.200,12h \
        --dhcp-boot=chateau.elf --bootp-dynamic --dhcp-authoritative \
        --enable-tftp --tftp-root=/srv/tftp --tftp-no-blocksize \
        --log-dhcp --log-facility=-

--port=0 disables the DNS part so dnsmasq does not fight with an existing resolver on the machine.

Works in any state, including a device with no working system:

1. Disconnect power
2. Press and hold the reset button
3. Reconnect power, keep holding
4. Release after the beep

No physical access needed. OpenWrt carries a RouterBOOT driver that exposes the bootloader's settings in sysfs:

echo ethonce > /sys/firmware/mikrotik/soft_config/boot_device
echo 1       > /sys/firmware/mikrotik/soft_config/commit
reboot

ethonce boots over Ethernet once and then falls back to flash by itself, so a failed netboot needs no intervention.

Other useful values in the same directory: boot_delay, boot_proto, baud_rate, cpu_freq. hard_config next to it is read-only and holds the factory MAC addresses, the WLAN calibration data and the serial number.

The dnsmasq log then shows a BOOTP exchange followed by the TFTP transfer. After roughly a minute OpenWrt answers on 192.168.1.1 over SSH, with no password set.

A successful run looks like this (captured on a German-locale dnsmasq, MAC masked):

dnsmasq-dhcp: 1617143478 "Vendor class": ARM64__boot
dnsmasq-dhcp: 1617143478 Marken: bootp, enx000ec78e1f00
dnsmasq-dhcp: 1617143478 BOOTP(enx000ec78e1f00) 192.168.1.163 04:f4:1c:xx:xx:xx
dnsmasq-dhcp: 1617143478 Name der Bootdatei: chateau-initramfs.elf
dnsmasq-dhcp: 1617143478 naechster Server: 192.168.1.10
dnsmasq-tftp: /srv/tftp/chateau-initramfs.elf an 192.168.1.163 verschickt

Three things worth reading out of it:

• RouterBOOT identifies itself with the vendor class ARM64boot. If the segment is not exclusively yours, that is a reliable way to serve the image only to the Chateau: --dhcp-vendorclass=set:chateau,ARM64__boot together with --dhcp-boot=tag:chateau,chateau-initramfs.elf. * The request is BOOTP, not DHCP. --bootp-dynamic is therefore mandatory - without it dnsmasq does not answer at all. * Roughly 16 seconds pass between the BOOTP reply and the completed transfer. The image is about 16 MB and the command above disables TFTP blocksize negotiation, so that is normal; do not abort early. The file name itself is arbitrary, it only has to match --dhcp-boot. ^ Symptom ^ Cause ^ | no BOOTP in the log | cable not on ether1, or another DHCP server on the segment | | BOOTP but no TFTP | filename does not match --dhcp-boot | | TFTP completes, device still boots from flash | broken loader ELF - check the boot log on serial | ==== Step 3: write it to flash ==== From the initramfs started over etherboot: <code bash> # on your workstation scp openwrt-*-squashfs-sysupgrade.bin root@192.168.1.1:/tmp/ # on the device sha256sum /tmp/openwrt-*-squashfs-sysupgrade.bin # compare against the source sysupgrade -n /tmp/openwrt-*-squashfs-sysupgrade.bin </code> The checksum is not ceremony: an aborted scp leaves a truncated file that sysupgrade -T may still partially accept. sysupgrade then erases the yaffs kernel partition, writes the loader ELF into it with yafut, and writes the root filesystem to UBI on mtd1. The erase is required rather than optional: from the factory the partition already holds 4.38 of its 8 MiB, and yaffs frees the old blocks only after writing, so without erasing first the write would run out of space halfway. The first boot after flashing takes about 90 seconds. Roughly 60 of those are RouterBOOT itself plus reading the loader ELF from NAND, not OpenWrt. ===== Returning to RouterOS ===== RouterBOOT is never modified, so Netinstall works exactly as it does from the factory: - Get Netinstall from mikrotik.com - Put the device into etherboot with the reset button (see above) - Select the RouterOS NPK and install No backup of the original partitions is needed for this. If you want one anyway, dump the NAND including the OOB area - without it the image cannot be restored byte for byte: <code bash> nanddump --oob -f /tmp/mtd0-oob.bin /dev/mtd0 </code> ===== Flash layout ===== <code> NAND (128 MiB) mtd0 0x00000000-0x00800000 8 MiB “kernel” yaffs, holds the loader ELF mtd1 0x00800000-0x08000000 120 MiB “ubi” rootfs + rootfs_data SPI-NOR - “RouterBoot” partition at 0x2c0000, 512 KiB, 64 KiB erase blocks +0x00000 RouterBOOT loader (ELF32, ARM) +0x20000 hard_config “Hard” MACs, WLAN calibration (LZ77), serial number +0x30000 second bootloader stage +0x40000 soft_config “Soft” boot_device, boot_delay, boot_proto +0x70000 device tree blob </code> ===== Known issues ===== PSGMII calibration fails intermittently. In roughly one boot out of three the link to the four gigabit ports shows a high bit error rate whose loss grows with frame size (64 byte frames: no loss, 1500 byte frames: up to 75 %). Rebooting clears it. A patch that waits for the SerDes VCO PLL to lock before releasing the receive CDR addresses this, but it has not been proven conclusively. The 2.5 GbE port is on a separate PHY and is not affected. PCIe is disabled. Enabling it left the Ethernet transmit path silent. The mPCIe slot is unused on this board - the modem is on USB - so nothing is lost. That measurement rests on a single boot per variant and is not trustworthy given the PSGMII problem above. The modem needs a libqmi based connection manager. The RG650E-EU comes up with its radio disabled (+CFUN: 0). uqmi is not sufficient: it only obtains a client ID for UIM, while DMS, NAS and WDS answer “Failed to connect to service”. qmicli from libqmi reaches all services. The board sensor has no driver. rb-spi-ts on SPI5 reports board temperature and PSU voltage under RouterOS. Neither OpenWrt nor mainline has a driver for it. The bus is enabled in the device tree so it can be wired up later without a DTS change. A stalled boot turns into a reset loop.** The SoC watchdog (qcom,kpss-wdt, timeout-sec = <10>) is built in and fed by procd once it runs. If userspace stalls before that, the board resets within seconds and leaves the UBIFS overlay unclean; the next boot logs recovery needed. When the overlay is damaged badly enough that procd cannot get past its - ubus - stage, every boot repeats the cycle. Symptom: the green status LED keeps blinking, the serial console prints the boot log but accepts no input (the console getty is started by init, which is never reached), and the device never appears on the network. Recovery is to netboot the initramfs, which does not use the overlay, and erase rootfs_data. ===== Notes for developers ===== * WLAN calibration comes from RouterBOOT's hard_config tag 0x16, which is LZ77 compressed. The rb_hardconfig driver decompresses it and exports it under /sys/firmware/mikrotik/hard_config/. The blob is passed to the firmware unmodified - the firmware validates it itself and aborts with phyrf_bdf.c:472 Assertion 0 failed on any change, even when the checksum is corrected to match. * The board data file ships through the ipq-wifi package, keyed on the calibration variant MikroTik-Chateau-5G-R17. * Factory MAC addresses are read per port from hard_config, so all five ports keep the addresses printed on the label across reboots and reflashes. * The LZMA loader lives in target/linux/qualcommax/image/mikrotik-lzma-loader. It builds a single PT_LOAD'' ELF containing code, compressed kernel and DTB, and sets up an identity mapping so decompression runs cached. ===== Tags =====

  MikroTik, IPQ6010, qualcommax, ipq60xx, 5G, LTE, ax, RouterBOOT