Chris' Blog

Repairing a Roborock S5 Max Robot Vacuum

2026-01-25T00:00:00+00:00

so, a few weeks ago my sister bought a used Roborock S5 Max robot vacuum cleaner. it worked perfectly - for a few days. then it started to have problems with navigation, simply turning in circles in open spaces.


Robot Activities (symbolic)

after some failed troubleshooting attempts (updating firmware, cleaning sensors, etc) she decided to ask me for help.

Basic Troubleshooting

Back to the original Firmware

of curse, my first step was to reset the robot to factory settings and firmware version. after all, this is a chinese product, so who knows what kind of firmware update they may have pushed (after the warranty period, of course).

to do this:

press the home button for 5 seconds
the “reset” button (located under the top cover), while keeping the home button pressed
release the “reset” button, keeping the home button pressed for another 5 seconds

(see this guide)

sadly, this did not help

Checking general motion and LIDAR mapping ability

the robot offers a joystick mode for manual movement. in this mode, the robot will also use the LIDAR to map the environment.

i’ve driven the robot around the room using the joystick mode, and observed the LIDAR map being built in real-time in the app. everything worked perfectly, and the map looked good.

sadly, as soon as i commanded the robot to move autonomously, it started to spin in circles again.

to me, this suggested like either a software issue - which is unlikely, given the firmware reset - or a hardware issue related to the movement sensor or feedback.

Entering the BIT Mode

Roborock vacuums have a hidden BIT (Built-In Test) mode, which (on this model) can be accessed as follows:

power off the robot
press and hold the power button
while holding the power button, press the home button 5 times
release the power button

from here, you can cycle through various tests using the home and power buttons. these tests range from simple switch tests - indicating whether e.g. the bumper inputs are pressed using the leds, to more complex tests like motor movement and LIDAR operation.

more details on the BIT mode can be found at various places online. here’s some i found useful:

https://www.youtube.com/watch?v=c6mxG5HYA70
https://www.youtube.com/watch?v=Fcea7dd7DFI
https://www.youtube.com/watch?v=Iq74XT-jIDw
https://cleanerstalk.com/roborock-error-codes/#t-1649313234742 (not in my case, but good to know)

Results

after running all tests and - suprisingly - all passed. well, that’s unexpected.

weirdly enough, running the tests on a different day, i’ve finally got a failed test: the robot reports an error with the left wheel movement test.

this would make sense, an encoder on the motor failing would cause the robot to see weird feedback when moving autonomously, certainly enough to throw off its navigation algorithms. with the test only failing intermittently, i’d also suspect something simpler - a loose connector, dirty contacts, or corrosion on the encoder itself.

Disassembly and Repair

disassembling the Roborock S5 Max is relatively straightforward, although a bit tedious. i’ve used this video teardown as reference, though i didn’t follow every step exactly: https://www.youtube.com/watch?v=0vLa4-iikzM

after removing the left wheel assembly, i could inspect the motor and encoder. and sure enough, there was something wrong with it, though not what i expected.


Left Wheel Motor Assembly

as you can see, two of the wires going to the motor assembly were broken. one wire was completely severed, while the other was only partially broken.

taking a closer look and, sure enough, the wires were wired to the motor encoder. so the robot could move, but had no feedback from the left wheel encoder, causing the freak out during autonomous navigation.

The Repair

since the wires are at a point where they flex a lot, i’ve decided to replace the wires from the motor assembly PCB to the mainboard connector. that way, no stress would be applied to the solder joints splicing the wires together.

sadly, i didn’t take pictures of the repair, but imagine two wires soldered together. i’m sure you can picture it.

since i had the robot disassembled, i also took the opportunity to clean all the dust and dirt from the internals. i also added some fresh grease to the motor gearboxes, since they looked a bit dry.

that’s it, after reassembling the robot, it works perfectly again.

Notes

since originally writing this post, the robot has been working perfectly. i also ended up getting my hands on a Roborock S7 with the exact same issue, and the same repair process applied as well. so it seems like this is a common issue with roborock vacuums using this kind of motor assembly / chassis.

since the fault results in a very specific symptoms, it should be easy to remote-diagnose this issue by checking:

does the robot exit the charging dock correctly? -> want yes
- the initial movement out of the dock is done without using the wheel encoders, so if this works then the motors and drivers are fine.
does mapping work? -> want yes
- if this works then the LIDAR and mainboard are fine.
does the robot stop when bumpers are actuated? -> want yes
- if this works then the bumper sensors are fine.
does the robot fail to navigate autonomously (going in circles)? -> want no
- the main symptom described in this post. if only this happens, then the issue is likely with the wheel encoder feedback.
does the robot have (about) 800-1000 hours of use? -> want yes
- this is the lifespan i’ve observed (sample-size of only 2!).

if you have (or for the more adventurous, want to buy) a roborock vacuum with these symptoms, you can be fairly confident that the issue is a fairly simple repair.

as a side note, a complete stop in movement in one of the wheels could also be caused by broken wires, in that case the robot would fail to exit the dock as well. however, that symptom could also be caused by a failed motor driver, so it would be less conclusive than the symptoms described above.

On the T45

2025-10-18T00:00:00+00:00

as already rumored, the T45 is basically a beefed-up T40, with some parts substituted for (likely) cheaper alternatives. i wanted to check that myself, so i decided ask on the OpenWrt forum if anyone had a T45 they could provide flash dumps from.

Acquiring Dumps

to figure out the difference, i knew i needed the following:

at least the first 256 bytes of the spi flash, containing PBI and RCW
the kernel and device tree blob, on watchguard firmwares usually bundled in a u-boot .itb file
output of mdio list from u-boot, to double-check the PHY configuration

assuming watchguard doesn’t do some crazy initialization in either u-boot or the linux kernel itself, that should be enough information to figure out the hardware differences.

the very kind user @hmartin on the OpenWrt forum provided me with the first and third items. as for the kernel and device tree, well… it turns out you can just extract them from the official firmware update files. simply download the update image for use from the web-ui, and open it with a tool like 7-zip. nothing special there.

sadly (or luckily, if you’re watchguard), there’s some checks in the firmware updater that prevent us from using a modified update image.

Differences and Findings

first of, i also ask for the same information from a T40, just to be sure that my T40 matches what others have. luckily, it does.

now, let’s get to the differences between the T40 and T45:

the RCW has no significant differences, only some pin muxing changes. and, of course, the PLL ratio of the cpu cores is changed.
MDIO assignments as reported by u-boot are identical
the LAN1-4 PHYs are likely the same, but the WAN0 PHY differs (Qualcomm AR8035 vs RealTek RTL8211F). Both are RGMII tho, so likely not significant.
the device tree is fairly similar, with some differences here and there. i’m not fully sure, but i think that the ethernet PHY configuration should still be close enough to make the T40 dts work on the T45.

i think that you’d just need to add the kernel driver for the Realtek PHY to my T40 Linux in order to get WAN0 working on the T45.

Details

RCW:
- CGA_PLL1_RAT: 10:1 -> 16:1 (1GHz -> 1.6GHz CPU)
- UART_BASE: 0x07 -> 0x06: UART pinmux differs
- SDHC_BASE: 0x01 -> 0x00: SDHC pinmux differs
- SPI_BASE: 0x02 -> 0x01: SPI pinmux differs
- IFC_GRP_E1_EXT: 0x00 -> 0x02: IFC pinmux differs
- IFC_GRP_E1_BASE: 0x01 -> 0x00: IFC pinmux differs
- IIC2_EXT: 0x02 -> 0x00: IIC2 Pinmux differs
Device Tree:
- esdhc@1560000 is enabled, bus-width is changed to 8 bits and cap-mmc-highspeed is added
- tpm@29 (atmel,at97sc3204t) node is replaced by tpm@2e (tcg,tpm)
- PWM controller pwm0@2a30000 is added on T45
- compatible = "ethernet-phy-id001c.c984", "ethernet-phy-ieee802.3-c22" and compatible = "ethernet-phy-id001c.c916"; are added to PHY nodes on T45, absent on T40

RCW Dump Output for T40 and T45

T40:

-- System Info --
 Flash dump: t45\t40_flashstart_mm.bin
 Initial QSPI endianess: QWORD_LITTLE_ENDIAN
 Assumed SOC Model: LS1043A

-- PBI Parser Messages ---
ALTCBAR set to 00002200 by PBI write
ALTCBAR set to 00000300 by PBI write
QSPI Endianess set to DWORD_LITTLE_ENDIAN due to QUADSPI_MCR write

-- RAW PBI Frames --
WRITE @ DCFG_CCSR_RCWSR0 (0x01EE0100): 0610000a0a0000000000000000000000455800020000001240044000c10020000000000000000000000000000003fffe200045040418320a0000009600000001 (CCSR)
WRITE @ SCFG_QSPI_CFG (0x0157015C): 40100000 (CCSR)
WRITE @ SCFG_SCRATCHRW0 (0x01570600): 00000000 (CCSR)
WRITE @ SCFG_SCRATCHRW1 (0x01570604): 40100000 (CCSR)
WRITE @ LNDSSCR1 (0x01EA08DC): 00502880 (CCSR)
WRITE @ CCI_UNKN_BARRIER_DISABLE (0x01570178): 0000e010 (CCSR)
WRITE @ CCI_400_Control_Override (0x01180000): 00000008 (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR1 (0x01570418): 0000009e (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR2 (0x0157041C): 0000009e (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR3 (0x01570420): 0000009e (CCSR)
WRITE @ DCFG_CCSR_RSTRQMR1 (0x01EE00C0): 00004400 (CCSR)
WRITE @ SCFG_ALTCBAR (0x01570158): 00002200 (CCSR)
WRITE @ PEX_OUTBOUND_WRITE_HANG_ERRATUM (0x22008040): 00000001 (ACS)
WRITE @ LNDSSCR1 (0x01EA08DC): 00502880 (CCSR)
WRITE @ SCFG_ALTCBAR (0x01570158): 00000300 (CCSR)
WRITE @ PEX1_GEN3_RElATED_OFF_ERRATUM (0x03400890): 01000100 (ACS)
WRITE @ PEX2_GEN3_RElATED_OFF_ERRATUM (0x03500890): 01000100 (ACS)
WRITE @ PEX3_GEN3_RElATED_OFF_ERRATUM (0x03600890): 01000100 (ACS)
WRITE @ QUADSPI_MCR (0x01550000): 000f400c (CCSR)
COMMAND @ PBI_CRC: 0x06DE05A9 (current) == 0x06DE05A9 (calculated) -> PASS

-- RCW Fields --
             SYS_PLL_CFG: 0x0    | 0      | 0b0                | OK
             SYS_PLL_RAT: 0x3    | 3      | 0b11               | 3:1
             MEM_PLL_CFG: 0x0    | 0      | 0b0                | OK
             MEM_PLL_RAT: 0x10   | 16     | 0b10000            | 16:1
            CGA_PLL1_CFG: 0x0    | 0      | 0b0                | OK
            CGA_PLL1_RAT: 0xA    | 10     | 0b1010             | 10:1
            CGA_PLL2_CFG: 0x0    | 0      | 0b0                | OK
            CGA_PLL2_RAT: 0xA    | 10     | 0b1010             | 10:1
              C1_PLL_SEL: 0x0    | 0      | 0b0                | CGA_PLL1 /1
           SRDS_PRTCL_S1: 0x4558 | 17752  | 0b100010101011000  | 
             FM1_MAC_RAT: 0x1    | 1      | 0b1                | 
 SRDS_PLL_REF_CLK_SEL_S1: 0x0    | 0      | 0b0                | 
              HDLC1_MODE: 0x0    | 0      | 0b0                | 
              HDLC2_MODE: 0x0    | 0      | 0b0                | 
          SRDS_PLL_PD_S1: 0x0    | 0      | 0b0                | 
            SRDS_DIV_PEX: 0x0    | 0      | 0b0                | 
          DDR_REFCLK_SEL: 0x1    | 1      | 0b1                | 
         LYNX_REFCLK_SEL: 0x0    | 0      | 0b0                | 
           DDR_FDBK_MULT: 0x2    | 2      | 0b10               | 
                 PBI_SRC: 0x4    | 4      | 0b100              | QSPI
                 BOOT_HO: 0x0    | 0      | 0b0                | All cores expect core 0 in hold off
                   SB_EN: 0x0    | 0      | 0b0                | Secure Boot Disabled
                IFC_MODE: 0x44   | 68     | 0b1000100          | 
      HWA_CGA_M1_CLK_SEL: 0x6    | 6      | 0b110              | Async mode, Cluster Group A PLL 2 /3 is clock
                DRAM_LAT: 0x1    | 1      | 0b1                | 8-8-8 or higher latency DRAMs
                DDR_RATE: 0x0    | 0      | 0b0                | 
                DDR_RSV0: 0x0    | 0      | 0b0                | 
             SYS_PLL_SPD: 0x1    | 1      | 0b1                | 
             MEM_PLL_SPD: 0x0    | 0      | 0b0                | 
            CGA_PLL1_SPD: 0x0    | 0      | 0b0                | 
            CGA_PLL2_SPD: 0x0    | 0      | 0b0                | 
            HOST_AGT_PEX: 0x0    | 0      | 0b0                | 
                 GP_INFO: 0x0    | 0      | 0b0                | 
                UART_EXT: 0x0    | 0      | 0b0                | See UART_BASE
                 IRQ_EXT: 0x0    | 0      | 0b0                | 
                 SPI_EXT: 0x0    | 0      | 0b0                | See SPI_BASE
                SDHC_EXT: 0x0    | 0      | 0b0                | See SDHC_BASE
               UART_BASE: 0x7    | 7      | 0b111              | { UART1_SOUT, UART1_SIN, UART3_SOUT,UART3_SIN, UART2_SOUT, UART2_SIN, UART4_SOUT, UART4_SIN }
                  ASLEEP: 0x1    | 1      | 0b1                | 
                     RTC: 0x1    | 1      | 0b1                | 
               SDHC_BASE: 0x1    | 1      | 0b1                | GPIO2[4:9]
                 IRQ_OUT: 0x1    | 1      | 0b1                | 
                IRQ_BASE: 0x1FF  | 511    | 0b111111111        | 
                SPI_BASE: 0x2    | 2      | 0b10               | GPIO2[0:3]
           IFC_GRP_A_EXT: 0x1    | 1      | 0b1                | 
           IFC_GRP_D_EXT: 0x0    | 0      | 0b0                | 
          IFC_GRP_E1_EXT: 0x0    | 0      | 0b0                | See IFC_GRP_E1_BASE
           IFC_GRP_F_EXT: 0x1    | 1      | 0b1                | 
           IFC_GRP_G_EXT: 0x0    | 0      | 0b0                | 
         IFC_GRP_E1_BASE: 0x1    | 1      | 0b1                | GPIO2[10:12]
          IFC_GRP_D_BASE: 0x1    | 1      | 0b1                | 
          IFC_GRP_A_BASE: 0x1    | 1      | 0b1                | 
             IFC_A_22_24: 0x0    | 0      | 0b0                | 
                     EC1: 0x0    | 0      | 0b0                | RGMII1
                     EC2: 0x1    | 1      | 0b1                | GPIO3, GPIO3[19:23]
                     EM1: 0x0    | 0      | 0b0                | MDC/MDIO (EM1)
                     EM2: 0x0    | 0      | 0b0                | MDC/MDIO (EM2)
              EMI2_DMODE: 0x1    | 1      | 0b1                | 
              EMI2_CMODE: 0x1    | 1      | 0b1                | 
             USB_DRVVBUS: 0x0    | 0      | 0b0                | USB_DRVVBUS
            USB_PWRFAULT: 0x0    | 0      | 0b0                | USB_PWRFAULT
               TVDD_VSEL: 0x1    | 1      | 0b1                | 2.5V
               DVDD_VSEL: 0x2    | 2      | 0b10               | 3.3V
          QE_CLK_OVRRIDE: 0x0    | 0      | 0b0                | 
              EMI1_DMODE: 0x1    | 1      | 0b1                | 
               EVDD_VSEL: 0x0    | 0      | 0b0                | 1.8V
               IIC2_BASE: 0x0    | 0      | 0b0                | OK
              EMI1_CMODE: 0x1    | 1      | 0b1                | 
                IIC2_EXT: 0x2    | 2      | 0b10               | GPIO4_2, GPIO4_3
             SYSCLK_FREQ: 0x258  | 600    | 0b1001011000       | 100.000 MHz (100000200 Hz)
      HWA_CGA_M2_CLK_SEL: 0x1    | 1      | 0b1                | Async mode, Cluster Group A PLL 2 /1 is clock

-- Effective Clocks --
 SYSCLK:                       100.00 MHz
 System (Bus):                 300.00 MHz
 CGA (Cores):                  1000.00 MHz
 MEM (Memory):                 1600.00 MHz
 HWA_CGA_M1 (FMAN):            500.00 MHz
 HWA_CGA_M2 (eSDHC & QuadSPI): 1000.00 MHz

-- Erratum Workarounds --
 Erratum A-009859 workaround: Yes
 Erratum A-009929 workaround: Yes

-- CRC Results --
 CRC Frame Present: Yes
 CRC Offset:     0x00DC
 In-File CRC:    0x06DE05A9
 Calculated CRC: 0x06DE05A9
 CRC Valid?:     Yes

T45:

-- System Info --
 Flash dump: t45\t45_flashstart_mm.bin
 Initial QSPI endianess: QWORD_LITTLE_ENDIAN
 Assumed SOC Model: LS1043A

-- PBI Parser Messages ---
ALTCBAR set to 00002200 by PBI write
ALTCBAR set to 00000300 by PBI write
QSPI Endianess set to DWORD_LITTLE_ENDIAN due to QUADSPI_MCR write

-- RAW PBI Frames --
WRITE @ DCFG_CCSR_RCWSR0 (0x01EE0100): 061000100a0000000000000000000000455800020000001240044000c100200000000000000000000000000000036ffd20044104041832080000009600000001 (CCSR)
WRITE @ SCFG_QSPI_CFG (0x0157015C): 40100000 (CCSR)
WRITE @ SCFG_SCRATCHRW0 (0x01570600): 00000000 (CCSR)
WRITE @ SCFG_SCRATCHRW1 (0x01570604): 40100000 (CCSR)
WRITE @ LNDSSCR1 (0x01EA08DC): 00502880 (CCSR)
WRITE @ CCI_UNKN_BARRIER_DISABLE (0x01570178): 0000e010 (CCSR)
WRITE @ CCI_400_Control_Override (0x01180000): 00000008 (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR1 (0x01570418): 0000009e (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR2 (0x0157041C): 0000009e (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR3 (0x01570420): 0000009e (CCSR)
WRITE @ DCFG_CCSR_RSTRQMR1 (0x01EE00C0): 00004400 (CCSR)
WRITE @ SCFG_ALTCBAR (0x01570158): 00002200 (CCSR)
WRITE @ PEX_OUTBOUND_WRITE_HANG_ERRATUM (0x22008040): 00000001 (ACS)
WRITE @ LNDSSCR1 (0x01EA08DC): 00502880 (CCSR)
WRITE @ SCFG_ALTCBAR (0x01570158): 00000300 (CCSR)
WRITE @ PEX1_GEN3_RElATED_OFF_ERRATUM (0x03400890): 01000100 (ACS)
WRITE @ PEX2_GEN3_RElATED_OFF_ERRATUM (0x03500890): 01000100 (ACS)
WRITE @ PEX3_GEN3_RElATED_OFF_ERRATUM (0x03600890): 01000100 (ACS)
WRITE @ QUADSPI_MCR (0x01550000): 000f400c (CCSR)
COMMAND @ PBI_CRC: 0x67AAF2F5 (current) == 0x67AAF2F5 (calculated) -> PASS

-- RCW Fields --
             SYS_PLL_CFG: 0x0    | 0      | 0b0                | OK
             SYS_PLL_RAT: 0x3    | 3      | 0b11               | 3:1
             MEM_PLL_CFG: 0x0    | 0      | 0b0                | OK
             MEM_PLL_RAT: 0x10   | 16     | 0b10000            | 16:1
            CGA_PLL1_CFG: 0x0    | 0      | 0b0                | OK
            CGA_PLL1_RAT: 0x10   | 16     | 0b10000            | 16:1
            CGA_PLL2_CFG: 0x0    | 0      | 0b0                | OK
            CGA_PLL2_RAT: 0xA    | 10     | 0b1010             | 10:1
              C1_PLL_SEL: 0x0    | 0      | 0b0                | CGA_PLL1 /1
           SRDS_PRTCL_S1: 0x4558 | 17752  | 0b100010101011000  | 
             FM1_MAC_RAT: 0x1    | 1      | 0b1                | 
 SRDS_PLL_REF_CLK_SEL_S1: 0x0    | 0      | 0b0                | 
              HDLC1_MODE: 0x0    | 0      | 0b0                | 
              HDLC2_MODE: 0x0    | 0      | 0b0                | 
          SRDS_PLL_PD_S1: 0x0    | 0      | 0b0                | 
            SRDS_DIV_PEX: 0x0    | 0      | 0b0                | 
          DDR_REFCLK_SEL: 0x1    | 1      | 0b1                | 
         LYNX_REFCLK_SEL: 0x0    | 0      | 0b0                | 
           DDR_FDBK_MULT: 0x2    | 2      | 0b10               | 
                 PBI_SRC: 0x4    | 4      | 0b100              | QSPI
                 BOOT_HO: 0x0    | 0      | 0b0                | All cores expect core 0 in hold off
                   SB_EN: 0x0    | 0      | 0b0                | Secure Boot Disabled
                IFC_MODE: 0x44   | 68     | 0b1000100          | 
      HWA_CGA_M1_CLK_SEL: 0x6    | 6      | 0b110              | Async mode, Cluster Group A PLL 2 /3 is clock
                DRAM_LAT: 0x1    | 1      | 0b1                | 8-8-8 or higher latency DRAMs
                DDR_RATE: 0x0    | 0      | 0b0                | 
                DDR_RSV0: 0x0    | 0      | 0b0                | 
             SYS_PLL_SPD: 0x1    | 1      | 0b1                | 
             MEM_PLL_SPD: 0x0    | 0      | 0b0                | 
            CGA_PLL1_SPD: 0x0    | 0      | 0b0                | 
            CGA_PLL2_SPD: 0x0    | 0      | 0b0                | 
            HOST_AGT_PEX: 0x0    | 0      | 0b0                | 
                 GP_INFO: 0x0    | 0      | 0b0                | 
                UART_EXT: 0x0    | 0      | 0b0                | See UART_BASE
                 IRQ_EXT: 0x0    | 0      | 0b0                | 
                 SPI_EXT: 0x0    | 0      | 0b0                | See SPI_BASE
                SDHC_EXT: 0x0    | 0      | 0b0                | See SDHC_BASE
               UART_BASE: 0x6    | 6      | 0b110              | { UART1_SOUT, UART1_SIN, UART1_RTS_B, UART1_CTS_B, UART2_SOUT, UART2_SIN, UART2_RTS_B, UART2_CTS_B }
                  ASLEEP: 0x1    | 1      | 0b1                | 
                     RTC: 0x1    | 1      | 0b1                | 
               SDHC_BASE: 0x0    | 0      | 0b0                | { SDHC_CMD, SDHC_DAT[0:3], SDHC_CLK }
                 IRQ_OUT: 0x1    | 1      | 0b1                | 
                IRQ_BASE: 0x1FF  | 511    | 0b111111111        | 
                SPI_BASE: 0x1    | 1      | 0b1                | SDHC_DAT[4:7] for 8-bit MMC card support
           IFC_GRP_A_EXT: 0x1    | 1      | 0b1                | 
           IFC_GRP_D_EXT: 0x0    | 0      | 0b0                | 
          IFC_GRP_E1_EXT: 0x2    | 2      | 0b10               | { FTM7_CH0, FTM7_CH1, FTM7_EXTCLK }
           IFC_GRP_F_EXT: 0x1    | 1      | 0b1                | 
           IFC_GRP_G_EXT: 0x0    | 0      | 0b0                | 
         IFC_GRP_E1_BASE: 0x0    | 0      | 0b0                | IFC_CS_B[1:3]
          IFC_GRP_D_BASE: 0x1    | 1      | 0b1                | 
          IFC_GRP_A_BASE: 0x1    | 1      | 0b1                | 
             IFC_A_22_24: 0x0    | 0      | 0b0                | 
                     EC1: 0x0    | 0      | 0b0                | RGMII1
                     EC2: 0x1    | 1      | 0b1                | GPIO3, GPIO3[19:23]
                     EM1: 0x0    | 0      | 0b0                | MDC/MDIO (EM1)
                     EM2: 0x0    | 0      | 0b0                | MDC/MDIO (EM2)
              EMI2_DMODE: 0x1    | 1      | 0b1                | 
              EMI2_CMODE: 0x1    | 1      | 0b1                | 
             USB_DRVVBUS: 0x0    | 0      | 0b0                | USB_DRVVBUS
            USB_PWRFAULT: 0x0    | 0      | 0b0                | USB_PWRFAULT
               TVDD_VSEL: 0x1    | 1      | 0b1                | 2.5V
               DVDD_VSEL: 0x2    | 2      | 0b10               | 3.3V
          QE_CLK_OVRRIDE: 0x0    | 0      | 0b0                | 
              EMI1_DMODE: 0x1    | 1      | 0b1                | 
               EVDD_VSEL: 0x0    | 0      | 0b0                | 1.8V
               IIC2_BASE: 0x0    | 0      | 0b0                | OK
              EMI1_CMODE: 0x1    | 1      | 0b1                | 
                IIC2_EXT: 0x0    | 0      | 0b0                | IIC2_SCL, IIC2_SDA
             SYSCLK_FREQ: 0x258  | 600    | 0b1001011000       | 100.000 MHz (100000200 Hz)
      HWA_CGA_M2_CLK_SEL: 0x1    | 1      | 0b1                | Async mode, Cluster Group A PLL 2 /1 is clock

-- Effective Clocks --
 SYSCLK:                       100.00 MHz
 System (Bus):                 300.00 MHz
 CGA (Cores):                  1600.00 MHz
 MEM (Memory):                 1600.00 MHz
 HWA_CGA_M1 (FMAN):            500.00 MHz
 HWA_CGA_M2 (eSDHC & QuadSPI): 1000.00 MHz

-- Erratum Workarounds --
 Erratum A-009859 workaround: Yes
 Erratum A-009929 workaround: Yes

-- CRC Results --
 CRC Frame Present: Yes
 CRC Offset:     0x00DC
 In-File CRC:    0x67AAF2F5
 Calculated CRC: 0x67AAF2F5
 CRC Valid?:     Yes

Overclocking the WatchGuard T40

2025-10-12T00:00:00+00:00

with linux mostly running (and me still procrastinating continuing further work on it), i figured i’d try and solve my last hang-up with the T40. the T40’s SOC is a NXP QorIQ LS1043A, and that supports up to 1.6GHz. however, the T40 is clocked at only 1.0GHz.

only when springing for the T45, which is mostly the same device but clocked higher, do you get the 1.6GHz clockspeed. that’s unfair! i paid for the full LS1043A, so i want to use all of it.

How The CPU Speed Is Set

linux has a cpu frequency driver for the LS1043A (specifically, all QorIQ SoCs). however, that can only scale down from the maximum frequency. setting that maximum frequency is done even before the bootloader is run, by something appropriately named the “Pre-Boot Loader” (PBL), which loads something called a “Reset Configuration Word” (RCW) from memory on boot.

Something Familiar

i was already familiar with the concept of an RCW, as the HC32F460 microcontroller (that i ported Arduino and Marlin to) uses something similar. it just so happens that NXP made their boot ROM much more flexible, allowing not just a fixed register to be loaded, but instead allowing writes to any register. these writes are called “Pree-Boot Initialization” (PBI) commands, and are stored in a binary data structure at the start of the memory device configured by some GPIOs.

the structure of these commands is super simple, it’s just a bite count field (up to 64 bytes), a target address (at least 24 bits of it), and the data itself. everything the PBL does, from the RCW to doing a CRC on the PBI data, is done through these commands.

as for why NXP choose to do it this way, has a fairly clever reason. simply by changing the PBI data, you can do all sorts of stuff, but importantly: you can fix errata simply by changing the SDK source code that generates the PBI data. this isn’t just in theory either: NXP has fixed two PCIe-related errata (A-009859 and A-009929) in the LS1043A this way, simply by writing magic values to otherwise undocumented registers. all-in-all, pretty cool.

Understanding and Parsing the PBI Data

to change the CPU clock speed, we need to change part of the PBI (specifically, the RCW) that sets up the PLLs for the CPU core cluster. however, the PBI includes a CRC-32 checksum at the end, so we can’t just change the data and expect it to work.

to make this whole process easier, and to understand how everything works, i decided to write a small tool to parse and print the PBI data, as well as calculating the CRC-32 checksum needed. that shouldn’t be too hard, especially since NXP provides a comprehensive reference manual for the LS1043A, which includes everything we need to know about.

as for why i decided to go this overboard, well… let’s just say that it’ll help us for what i plan to do later.


it’s a suprise tool that’ll help us later

if you’re interested, i published the code of the tool on GitHub. just note that it’s far from perfect, and very much not meant for production use.

for that, you should probably use NXP’s rcw tool instead. i only found this after writing my own tool, so… oh well. luckily (at least so i can tell myself that i didn’t waste my time), NXP’s tool isn’t able to handle the weird stuff that WatchGuard does, so mine is still useful.

The Weird Stuff WatchGuard Does

WatchGuard does something really weird - and frankly incredibly stupid - in their PBI. to cut an incredibly long, and frustrating, story short: they for some reason decided to use the PBI to switch the QuadSPI peripheral’s endianness from 64-bit little-endian to 32-bit big-endian. now, you could excuse this if this was some default setting of the SoC, but no: you can freely choose the on-reset configuration for this using strapping pins. the engineers at WatchGuard just… decided to do this for some reason.


WatchGuard deciding on data endianness

what that meant for me is that i had to handle the behaviour of the QuadSPI peripheral in my PBI parser, and handle when the PBI write switches the endianness. figuring all that out was a huge pain, and took way too long. but i eventually did it, and now my PBI parser can handle the T40’s PBI data. take a look:

The Output is pretty long, so click here to expand it

-- System Info --
 Flash dump: ../rcwmod/spiflash.20251012.1000mhz.bin
 Initial QSPI endianess: QWORD_LITTLE_ENDIAN
 Assumed SOC Model: LS1043A

-- PBI Parser Messages ---
ALTCBAR set to 00002200 by PBI write
ALTCBAR set to 00000300 by PBI write
QSPI Endianess set to DWORD_LITTLE_ENDIAN due to QUADSPI_MCR write

-- RAW PBI Frames --
WRITE @ DCFG_CCSR_RCWSR0 (0x01EE0100): 0610000a0a0000000000000000000000455800020000001240044000c10020000000000000000000000000000003fffe200045040418320a0000009600000001 (CCSR)
WRITE @ SCFG_QSPI_CFG (0x0157015C): 40100000 (CCSR)
WRITE @ SCFG_SCRATCHRW0 (0x01570600): 00000000 (CCSR)
WRITE @ SCFG_SCRATCHRW1 (0x01570604): 40100000 (CCSR)
WRITE @ LNDSSCR1 (0x01EA08DC): 00502880 (CCSR)
WRITE @ CCI_UNKN_BARRIER_DISABLE (0x01570178): 0000e010 (CCSR)
WRITE @ CCI_400_Control_Override (0x01180000): 00000008 (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR1 (0x01570418): 0000009e (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR2 (0x0157041C): 0000009e (CCSR)
WRITE @ SCFG_USB_REFCLK_SELCR3 (0x01570420): 0000009e (CCSR)
WRITE @ DCFG_CCSR_RSTRQMR1 (0x01EE00C0): 00004400 (CCSR)
WRITE @ SCFG_ALTCBAR (0x01570158): 00002200 (CCSR)
WRITE @ PEX_OUTBOUND_WRITE_HANG_ERRATUM (0x22008040): 00000001 (ACS)
WRITE @ LNDSSCR1 (0x01EA08DC): 00502880 (CCSR)
WRITE @ SCFG_ALTCBAR (0x01570158): 00000300 (CCSR)
WRITE @ PEX1_GEN3_RElATED_OFF_ERRATUM (0x03400890): 01000100 (ACS)
WRITE @ PEX2_GEN3_RElATED_OFF_ERRATUM (0x03500890): 01000100 (ACS)
WRITE @ PEX3_GEN3_RElATED_OFF_ERRATUM (0x03600890): 01000100 (ACS)
WRITE @ QUADSPI_MCR (0x01550000): 000f400c (CCSR)
COMMAND @ PBI_CRC: 0x06DE05A9 (current) == 0x06DE05A9 (calculated) -> PASS

-- RCW Fields --
             SYS_PLL_CFG: 0x0    | 0      | 0b0                | OK
             SYS_PLL_RAT: 0x3    | 3      | 0b11               | 3:1
             MEM_PLL_CFG: 0x0    | 0      | 0b0                | OK
             MEM_PLL_RAT: 0x10   | 16     | 0b10000            | 16:1
            CGA_PLL1_CFG: 0x0    | 0      | 0b0                | OK
            CGA_PLL1_RAT: 0xA    | 10     | 0b1010             | 10:1
            CGA_PLL2_CFG: 0x0    | 0      | 0b0                | OK
            CGA_PLL2_RAT: 0xA    | 10     | 0b1010             | 10:1
              C1_PLL_SEL: 0x0    | 0      | 0b0                | CGA_PLL1 /1
           SRDS_PRTCL_S1: 0x4558 | 17752  | 0b100010101011000  |
             FM1_MAC_RAT: 0x1    | 1      | 0b1                |
 SRDS_PLL_REF_CLK_SEL_S1: 0x0    | 0      | 0b0                |
              HDLC1_MODE: 0x0    | 0      | 0b0                |
              HDLC2_MODE: 0x0    | 0      | 0b0                |
          SRDS_PLL_PD_S1: 0x0    | 0      | 0b0                |
            SRDS_DIV_PEX: 0x0    | 0      | 0b0                |
          DDR_REFCLK_SEL: 0x1    | 1      | 0b1                |
         LYNX_REFCLK_SEL: 0x0    | 0      | 0b0                |
           DDR_FDBK_MULT: 0x2    | 2      | 0b10               |
                 PBI_SRC: 0x4    | 4      | 0b100              | QSPI
                 BOOT_HO: 0x0    | 0      | 0b0                | All cores expect core 0 in hold off
                   SB_EN: 0x0    | 0      | 0b0                | Secure Boot Disabled
                IFC_MODE: 0x44   | 68     | 0b1000100          |
      HWA_CGA_M1_CLK_SEL: 0x6    | 6      | 0b110              | Async mode, Cluster Group A PLL 2 /3 is clock
                DRAM_LAT: 0x1    | 1      | 0b1                | 8-8-8 or higher latency DRAMs
                DDR_RATE: 0x0    | 0      | 0b0                |
                DDR_RSV0: 0x0    | 0      | 0b0                |
             SYS_PLL_SPD: 0x1    | 1      | 0b1                |
             MEM_PLL_SPD: 0x0    | 0      | 0b0                |
            CGA_PLL1_SPD: 0x0    | 0      | 0b0                |
            CGA_PLL2_SPD: 0x0    | 0      | 0b0                |
            HOST_AGT_PEX: 0x0    | 0      | 0b0                |
                 GP_INFO: 0x0    | 0      | 0b0                |
                UART_EXT: 0x0    | 0      | 0b0                | See UART_BASE
                 IRQ_EXT: 0x0    | 0      | 0b0                |
                 SPI_EXT: 0x0    | 0      | 0b0                | See SPI_BASE
                SDHC_EXT: 0x0    | 0      | 0b0                | See SDHC_BASE
               UART_BASE: 0x7    | 7      | 0b111              | { UART1_SOUT, UART1_SIN, UART3_SOUT,UART3_SIN, UART2_SOUT, UART2_SIN, UART4_SOUT, UART4_SIN }
                  ASLEEP: 0x1    | 1      | 0b1                |
                     RTC: 0x1    | 1      | 0b1                |
               SDHC_BASE: 0x1    | 1      | 0b1                | GPIO2[4:9]
                 IRQ_OUT: 0x1    | 1      | 0b1                |
                IRQ_BASE: 0x1FF  | 511    | 0b111111111        |
                SPI_BASE: 0x2    | 2      | 0b10               | GPIO2[0:3]
           IFC_GRP_A_EXT: 0x1    | 1      | 0b1                |
           IFC_GRP_D_EXT: 0x0    | 0      | 0b0                |
          IFC_GRP_E1_EXT: 0x0    | 0      | 0b0                | See IFC_GRP_E1_BASE
           IFC_GRP_F_EXT: 0x1    | 1      | 0b1                |
           IFC_GRP_G_EXT: 0x0    | 0      | 0b0                |
         IFC_GRP_E1_BASE: 0x1    | 1      | 0b1                | GPIO2[10:12]
          IFC_GRP_D_BASE: 0x1    | 1      | 0b1                |
          IFC_GRP_A_BASE: 0x1    | 1      | 0b1                |
             IFC_A_22_24: 0x0    | 0      | 0b0                |
                     EC1: 0x0    | 0      | 0b0                | RGMII1
                     EC2: 0x1    | 1      | 0b1                | GPIO3, GPIO3[19:23]
                     EM1: 0x0    | 0      | 0b0                | MDC/MDIO (EM1)
                     EM2: 0x0    | 0      | 0b0                | MDC/MDIO (EM2)
              EMI2_DMODE: 0x1    | 1      | 0b1                |
              EMI2_CMODE: 0x1    | 1      | 0b1                |
             USB_DRVVBUS: 0x0    | 0      | 0b0                | USB_DRVVBUS
            USB_PWRFAULT: 0x0    | 0      | 0b0                | USB_PWRFAULT
               TVDD_VSEL: 0x1    | 1      | 0b1                | 2.5V
               DVDD_VSEL: 0x2    | 2      | 0b10               | 3.3V
          QE_CLK_OVRRIDE: 0x0    | 0      | 0b0                |
              EMI1_DMODE: 0x1    | 1      | 0b1                |
               EVDD_VSEL: 0x0    | 0      | 0b0                | 1.8V
               IIC2_BASE: 0x0    | 0      | 0b0                | OK
              EMI1_CMODE: 0x1    | 1      | 0b1                |
                IIC2_EXT: 0x2    | 2      | 0b10               | GPIO4_2, GPIO4_3
             SYSCLK_FREQ: 0x258  | 600    | 0b1001011000       | 100.000 MHz (100000200 Hz)
      HWA_CGA_M2_CLK_SEL: 0x1    | 1      | 0b1                | Async mode, Cluster Group A PLL 2 /1 is clock

-- Effective Clocks --
 SYSCLK:                       100.00 MHz
 System (Bus):                 300.00 MHz
 CGA (Cores):                  1000.00 MHz
 MEM (Memory):                 1600.00 MHz
 HWA_CGA_M1 (FMAN):            500.00 MHz
 HWA_CGA_M2 (eSDHC & QuadSPI): 1000.00 MHz

-- Erratum Workarounds --
 Erratum A-009859 workaround: Yes
 Erratum A-009929 workaround: Yes

-- CRC Results --
 CRC Frame Present: Yes
 CRC Offset:     0x00DC
 In-File CRC:    0x06DE05A9
 Calculated CRC: 0x06DE05A9
 CRC Valid?:     Yes

Going to 1.6GHz

changing the CPU clock is fairly simple, once you have a way to actually create a valid PBI. the SoC runs on a single 100MHz reference clock (SYSCLK), and the CPU clock is derived from that using a PLL. the PLL for the CPU (and actually everything else) is configured using the CGA_PLL1_RAT (Cluster Group A PLL 1 Ratio) field in the RCW. well, actually there is a second PLL (CGA_PLL2_RAT), and you can freely choose which one to use for the CPU cores, but that’s not important right now.

there’s some other things to keep in mind, mainly since the CGA_PLLn clock is also used for the hardware accceleration engines (FMAN = Frame Manager) and the eSDHC and QuadSPI peripherals. the clocks of those can be derived from either of the CGA_PLLn PLLs. luckily, in the T40’s RCW, they use PLL2 while the CPU cores use PLL1, so we can change the CPU clock without affecting those peripherals.

other than that, there’s also the option to divide the PLL clock by either 1 or 2 depending on the C1_PLL_SEL field, but we’ll simply leave it at PLL1 /1.

with that, we can start overlocking the CPU as follows:

set CGA_PLL1_RAT to the desired multiplier (5 - 40). the field is at offset 0x0C in the SPI flash dump. For 1.0GHz, it’s set to 0xA (10:1), for 1.6GHz, set it to 0x10 (16:1).
run pbidump to check the changes, and to calculate the new CRC-32 checksum.
write the new CRC-32 checksum at offset 0xDC in the SPI flash dump.
run pbidump again to verify that everything is correct.
flash the modified image to the T40’s SPI flash.
cross fingers and boot.

do all that, and you should be greeted by u-boot reporting 1600MHz CPU clock:

U-Boot 2018.09 (Dec 05 2019 - 10:13:47 -0800)

SoC:  LS1043AE Rev1.1 (0x87920011)
Clock Configuration:
       CPU0(A53):1600 MHz  CPU1(A53):1600 MHz  CPU2(A53):1600 MHz
       CPU3(A53):1600 MHz
       Bus:      300  MHz  DDR:      1600 MT/s  FMAN:     500  MHz
Reset Configuration Word (RCW):
       00000000: 06100010 0a000000 00000000 00000000
       00000010: 45580002 00000012 40044000 c1002000
       00000020: 00000000 00000000 00000000 0003fffe
       00000030: 20004504 0418320a 00000096 00000001
Model: LS1043A QDS Board - T40/T20
Board: LS1043AQDS, boot from vBank: 0

success!

But What If We… Went faster?

technically, we haven’t yet overclocked the SoC (1.6GHz is still supported, after all), so why not see how far we can push it? as you’ll see, this doesn’t go quite as smoothly.

2.0 GHz

well, nothing happens. doesn’t even boot.

1.8 GHz ?

let’s take it back a notch and try 1.8GHz. aand… it crashes. while u-boot does come up briefly, it quickly crashes with a “synchronous abort” error.

Maybe just 1.7 GHz

ok, i really was hoping to reach 2 GHz here, but let’s go back to 1.7GHz.

this actually looked kinda promising at first, but nope, not stable. it does get to linux, and even runs the first coremark run, but then the kernel just panics.

What About RAM?

sadly, the T40 uses pretty basic DDR4-2666 memory (Nanya NT5AD1024M8A3-HR), with incredible 19-19-19 timings - at 2666 MT/s. At the 3200 MT/s we’re running, that decreases to 22-22-22 timings. ouch. no wonder Nanya doesn’t even list it on their website anymore. that means there isn’t really much room for improvement here, as a clock any higher than 1600 MHz will not work stable (i tried).

Benchmark Results

to see how much of a difference this makes, i threw together a quick test using both coremark and coremark-pro. the results are really promising, showing almost linear scaling with the increased clock speed.

Run	CoreMark	CoreMark-Pro (SingleCore)	CoreMark-Pro (MultiCore)
T40 @ 1.0 GHz	3276 (+0%)	686 (+0%)	2178 (+0%)
T40 @ 1.6 GHz	5268 (+61%)	1097 (+60%)	3326 (+53%)

Click for benchmark details

`benchmark.sh`:

#!/bin/sh
# standard benchmark script for T40
# assumes to be run as root, in a directory where coremark and coremark-pro are cloned (and built) already
set -e

echo "-- CPU Freq Config --"
cpupower frequency-set -g performance
cpupower frequency-info

echo "-- CoreMark --"
cd coremark/
./coremark.exe
cd ..

echo "-- CoreMark-Pro --"
cd coremark-pro/
make -s XCMD='-c4' certify-all
cd ..

echo "-- Done --"

T40 @ 1.0GHz:

-- CPU Freq Config --
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
analyzing CPU 0:
  driver: qoriq_cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 41 ns
  hardware limits: 500 MHz - 1000 MHz
  available frequency steps:  1000 MHz, 500 MHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 500 MHz and 1000 MHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: 1000 MHz (asserted by call to hardware)

-- CoreMark --
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 12209
Total time (secs): 12.209000
Iterations/Sec   : 3276.271603
Iterations       : 40000
Compiler version : GCC14.2.1 20250207
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0x25b5
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 3276.271603 / GCC14.2.1 20250207 -O2 -DPERFORMANCE_RUN=1  -lrt / Heap

-- CoreMark-Pro --
WORKLOAD RESULTS TABLE

                                                 MultiCore SingleCore
Workload Name                                     (iter/s)   (iter/s)    Scaling
----------------------------------------------- ---------- ---------- ----------
cjpeg-rose7-preset                                  113.64      29.33       3.87
core                                                  0.81       0.20       4.05
linear_alg-mid-100x100-sp                            39.18      10.19       3.84
loops-all-mid-10k-sp                                  1.27       0.45       2.82
nnet_test                                             2.68       0.80       3.35
parser-125k                                          18.78       6.90       2.72
radix2-big-64k                                      123.11      72.61       1.70
sha-test                                            192.31      57.47       3.35
zip-test                                             57.14      15.38       3.72

MARK RESULTS TABLE

Mark Name                                        MultiCore SingleCore    Scaling
----------------------------------------------- ---------- ---------- ----------
CoreMark-PRO                                       2177.64     686.01       3.17

T40 @ 1.6GHz:

-- CPU Freq Config --
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
analyzing CPU 0:
  driver: qoriq_cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 41 ns
  hardware limits: 500 MHz - 1.60 GHz
  available frequency steps:  1.60 GHz, 1000 MHz, 800 MHz, 500 MHz
  available cpufreq governors: conservative ondemand userspace powersave performance schedutil
  current policy: frequency should be within 500 MHz and 1.60 GHz.
                  The governor "performance" may decide which speed to use
                  within this range.
  current CPU frequency: 1.60 GHz (asserted by call to hardware)
-- CoreMark --
2K performance run parameters for coremark.
CoreMark Size    : 666
Total ticks      : 18981
Total time (secs): 18.981000
Iterations/Sec   : 5268.426321
Iterations       : 100000
Compiler version : GCC14.2.1 20250207
Compiler flags   : -O2 -DPERFORMANCE_RUN=1  -lrt
Memory location  : Please put data memory location here
                        (e.g. code in flash, data on heap etc)
seedcrc          : 0xe9f5
[0]crclist       : 0xe714
[0]crcmatrix     : 0x1fd7
[0]crcstate      : 0x8e3a
[0]crcfinal      : 0xd340
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 5268.426321 / GCC14.2.1 20250207 -O2 -DPERFORMANCE_RUN=1  -lrt / Heap
-- CoreMark-Pro --
WORKLOAD RESULTS TABLE

                                                 MultiCore SingleCore
Workload Name                                     (iter/s)   (iter/s)    Scaling
----------------------------------------------- ---------- ---------- ----------
cjpeg-rose7-preset                                  181.82      47.17       3.85
core                                                  1.31       0.33       3.97
linear_alg-mid-100x100-sp                            62.97      16.40       3.84
loops-all-mid-10k-sp                                  1.84       0.70       2.63
nnet_test                                             4.30       1.29       3.33
parser-125k                                          28.99      10.99       2.64
radix2-big-64k                                      147.43     113.48       1.30
sha-test                                            312.50      92.59       3.38
zip-test                                             88.89      24.39       3.64

MARK RESULTS TABLE

Mark Name                                        MultiCore SingleCore    Scaling
----------------------------------------------- ---------- ---------- ----------
CoreMark-PRO                                       3325.58    1096.57       3.03

Conclusion

this was really fun to do, and i’m super happy that it worked out. although i’m a bit bummed that i couldn’t really push the SoC any further than 1.6GHz, it’s still a nice improvement. i really would’ve thought that there’d be more headroom, but oh well.

cracking the T40's U-Boot

2025-10-05T00:00:00+00:00

with linux mostly running (and me procrastinating continuing work on the last ethernet PHY), there still was a little hangup for me: on the T40, it’s easy enough to get into U-Boot by simply removing the SSD. but wouldn’t it be nice to have a way to get into U-Boot without having to open the case?

The Hidden Password Prompt

that’s exactly what the engineers at WatchGuard thought too, so they added a hidden password prompt to the U-Boot build. you can access it by pressing CTRL-C at the SysA / SysB prompt.


Hidden Password Prompt

sadly, the password isn’t “WatchGuard!” this time around. would’ve been funny though.

The Elusive U-Boot Patch

on the OpenWRT forum thread about the T40, there was some discussion about a possible patch to bypass the password. this was posted by neggles on the OpenWRT IRC:

12:02 stintel: I binpatched the u-boot on my T20 to get into it 12:02 changed one cbz to cbnz

sadly, no further details were given on where to patch the binary. so I set out to figure it out myself. how hard could it be?

Loading The U-Boot Binary Into Ghidra

this first step is where i hit my first issues, really making me reconsider if this was worth the effort. dumping the U-Boot binary was easy enough using the working linux system, as the MTB partition is simply exposed as /dev/mtd1 (even with a nice label “U-Boot”).

that is where the easy part ends, though.

i spend forever trying to find the base address to load the binary at. all this was made 100x harder by me being an idiot and choosing the wrong ARM architecture in Ghidra.

eventually, i stumbled upon binbloom, which is a really neat tool for analysing raw firmware binaries. i had never heard of it before, but it worked really well for this purpose:

$ binbloom -e be mtd1_uboot.bin
[i] Selected big-endian architecture.
[i] File read (1048576 bytes)
[i] Endianness is BE
[i] 3318 strings indexed
[i] Found 31351 base addresses to test
[i] Base address seems to be 0x00f8b000 (not sure).

loading the binary at 0x00f8b000 in Ghidra looked really promising, so i think it’s correct.

Figuring Out The Password Check

before we can patch anything, we need to understand what is happening. as a quick start, i decided to search for references to the header string we saw in the password prompt, and got to a function that likely handles drawing the prompt. single caller is a function that looks suspiciously like it handles the bootdelay count down, as well as having a direct reference to the string “password>”. suspicious indeed.

cleaning stuff up (a lot!), here’s some snippets of the relevant code (function’s really long, so just the relevant parts):

// (...)
  password_entered_ok_maybe = false;
  scrambled_correct_password = SCRAMBLED_CORRECT_PASSWORD;
  // (...)
  printf_ish("Hit any key to stop autoboot: %2d",bootdelay);
redraw_bootdelay_countdown_maybe:
  if (/* (...) */) {
    // (...)
    do {
      iVar3 = ControlCPressed_likely();
      if (iVar3 != 0) goto do_password_check;
      // (...)
    } while (ms_delay_counter < 1000);
    // (...)
  }
  // (...)
  if (password_entered_ok_maybe) {
    return;
  }
  // (...)

do_password_check:
  while (read_char != `\r`) {
    while( true ) {
      read_char = maybe_read_serial_char();
      // (...)

      // get_password_text_with_prompt displays the string as a prompt,
      // then reads input from serial input until ENTER is pressed.
      // input is stored in PASSWORD_INPUT global.
      pwdlen = get_password_text_with_prompt("password>");
      if (0 < pwdlen) {
        scramble_password(&PASSWORD_INPUT,pwdlen,scrambled_password);
        pwdlen = memcmp(&scrambled_correct_password,scrambled_password,0x14);
        if (pwdlen == 0) {
          password_entered_ok_maybe = true;
          goto boot_or_redraw;
        }
      }
      // (...)
    }
  }
  password_entered_ok_maybe = false;
// (...)

i think we have a winner here. best part: the if (pwdlen == 0) check is implemented using a CBZ instruction, which is exactly what neggles mentioned in the IRC. patching this to a CBNZ should make it so that any entered password (well, except for the correct one) is accepted.

to patch your binary the same way that neggles likely did, simply open the binary in a hex editor, search for the hex pattern e32f0194c0000034, and replace the last byte 34 with 35. the byte should be at offset 0x199C3 in /dev/mtd1, or 0x1199C3 in the whole flash dump. note that these offsets are specific to the T40’s U-Boot binary, and may differ in other devices or U-Boot versions.

after flashing the patched binary back, simply press CTRL-C at the boot selection, enter any password (cannot be empty), and you’re dropped into U-Boot.

Cracking the Password

nope, didn’t do that. though i’m curious, scamble_password is a rather long and annoying function to reverse. maybe someone else wants to give it a try?

Reverse-Engineering the Front Panel of a WatchGuard T40

2025-10-04T00:00:00+00:00

with linux mostly working on the T40, i decided to take a look at getting the front panel LEDs and buttons working.

Preparation

to prepare for this, we first need to dump the file system and figure out what controls the front panel. the ssd is easily dumpable from the - now - working linux system.

as for what controls the front panel, the boot log mentions a S51armled script, which probably does something with the front panel (just a hunch). looking at that script, it just runs /usr/bin/armled -arm, so let’s look at that binary.

The armled Binary

i didn’t actually look much at this binary, as i suspected it would work similar to how the T70’s front panel works, meaning theres a library doing the actual work. and i was right, the armled binary links agains libwgpanel.so. that seems promising, so let’s look at that library.

libwgpanel.so

after loading and analyzing the library in ghidra, there’s a bunch of functions exported. that’s really nice.


exports of libwgpanel.so

while write_led, getResetButton, and read_reset would be obvious candidates to look at, i decided to start with gpio_initialize. for now, i care more about understanding how things work generally, not specifically how to do stuff. the rest i can hopefully figure out from that.

so, let’s look at gpio_initialize.

gpio_initialize and friends

gpio_initialize calls two functions, which i don’t care too much what they do right now. digging a bit in the first one tho, we see some familiar looking code (post clean-up here):

bool export_gpio_pin(char *gpio_pin)
{
  bool fn_rc;
  int rc;
  size_t len;
  stat *stat_buf;
  char gpio_path [84];
  undefined4 local_c;
  FILE *fhandle;

  sprintf(gpio_path,s_/sys/class/gpio/gpio%s/value_00114240,gpio_pin);
  rc = xstat(gpio_path,&stat_buf);
  if (rc == 0) {
    fn_rc = true;
  }
  else {
    fhandle = fopen(s_/sys/class/gpio/export_00114198,"wb");
    if (fhandle == (FILE *)0x0) {
      fn_rc = true;
    }
    else {
      len = strlen(gpio_pin);
      len = fwrite(gpio_pin,len,1,fhandle);
      local_c = (undefined4)len;
      fclose(fhandle);
      fn_rc = false;
    }
  }
  return fn_rc;
}

this function seems to handle exporting a gpio pin, using the standard sysfs gpio interface.

the parent function, the only one calling export_gpio_pin, seems to take a list of gpio pins (as a flat string of all things!) to export. i suspect the parameter type is wrong tho, probably it should be an array of some struct. this is also true for export_gpio_pin.

bool export_gpio_pin_list(char *gpio_list_maybe)
{
  bool bVar1;
  char *gpio_name_i;

  gpio_name_i = gpio_list_maybe;
  while( true ) {
    if (*gpio_name_i == '\0') {
      return false;
    }
    if (((*gpio_name_i != '-') && (*(int *)(gpio_name_i + 0x14) == 0)) &&
       (bVar1 = export_gpio_pin(gpio_name_i), bVar1)) break;
    gpio_name_i = gpio_name_i + 0x20;
  }
  return true;
}

doing the same for the other function called by gpio_initialize, we see it also uses the sysfs gpio interface, this time to initialize the direction (and pull-ups?) of the pins. from the code, we also get a lot of clues as to what the misterious structure actually is:

bool set_gpio_mode(s_gpio_pin_entry *gpio_pin)
{
  int strncmp_result;
  size_t len;
  char acStack_70 [8];
  char s_none [8];
  char file_path [84];
  undefined4 local_c;
  FILE *fhandle;

  builtin_strncpy(s_none,"none",5);
  if (gpio_pin->pin_name[0] == '-') {
    return false;
  }
  if (gpio_pin->unkn1 == 0) {
    sprintf(file_path,s_/sys/class/gpio/gpio%s/direction_001141d0,gpio_pin);
    fhandle = fopen(file_path,"wb");
    if (fhandle == (FILE *)0x0) {
      return true;
    }
    len = strlen(gpio_pin->direction);
    len = fwrite(gpio_pin->direction,len,1,fhandle);
    local_c = (undefined4)len;
    fclose(fhandle);
                    // gpio_pin->direction == "in"
    strncmp_result = strcmp(gpio_pin->direction,"in");
    if (strncmp_result == 0) {
      sprintf(file_path,s_/sys/class/gpio/gpio%s/active_lo_00114218,gpio_pin);
      fhandle = fopen(file_path,"wb");
      if (fhandle == (FILE *)0x0) {
        return true;
      }
      sprintf(acStack_70,"%d",(ulong)(uint)gpio_pin->active_lo);
      len = fwrite(acStack_70,1,1,fhandle);
      local_c = (undefined4)len;
      fclose(fhandle);
      sprintf(file_path,s_/sys/class/gpio/gpio%s/edge_001141f8,gpio_pin);
      fhandle = fopen(file_path,"wb");
      if (fhandle == (FILE *)0x0) {
        return true;
      }
      len = strlen(s_none);
      len = fwrite(s_none,len,1,fhandle);
      local_c = (undefined4)len;
      fclose(fhandle);
    }
                    // gpio_pin->direction == "out"
    strncmp_result = strcmp(gpio_pin->direction,"out");
    if (strncmp_result == 0) {
      write_led(gpio_pin,gpio_pin->initial_level);
    }
  }
  else if (gpio_pin->unkn1 == 1) {
    write_led(gpio_pin,gpio_pin->initial_level);
  }
  return false;
}

from the clues, i think the struct looks something like this:

struct s_gpio_pin_entry {
  char pin_name[16]; // as you'd write to /sys/class/gpio/export
  char direction[4]; // "in" or "out"
  int unkn1; // 1 or 0, idk what it does
  int active_lo; // 1 or 0, if the pin is active low. "in" direction only
}

the calling function also makes a lot of sense with that struct in mind:

bool set_gpio_mode_list(s_gpio_pin_entry *gpio_pins)
{
  bool fail;
  s_gpio_pin_entry *pin;

  pin = gpio_pins;
  while( true ) {
    if (pin->pin_name[0] == '\0') {
      return false;
    }
    fail = set_gpio_mode(pin);
    if (fail) break;
    pin = pin + 1;
  }
  return true;
}

those findings also check out with the previous export_gpio_pin and export_gpio_pin_list functions:

bool export_gpio_pin(s_gpio_pin_entry *gpio_pin)
{
  bool fn_rc;
  int rc;
  size_t len;
  stat *stat_buf;
  char gpio_path [84];
  undefined4 local_c;
  FILE *fhandle;

                    // exports a gpio pin using /sys/class/gpio/export
  sprintf(gpio_path,s_/sys/class/gpio/gpio%s/value_00114240,gpio_pin);
  rc = xstat(gpio_path,&stat_buf);
  if (rc == 0) {
    fn_rc = true;
  }
  else {
    fhandle = fopen(s_/sys/class/gpio/export_00114198,"wb");
    if (fhandle == (FILE *)0x0) {
      fn_rc = true;
    }
    else {
      len = strlen(gpio_pin->pin_name);
      len = fwrite(gpio_pin,len,1,fhandle);
      local_c = (undefined4)len;
      fclose(fhandle);
      fn_rc = false;
    }
  }
  return fn_rc;
}

bool export_gpio_pin_list(s_gpio_pin_entry *gpio_pins)
{
  bool fail;
  s_gpio_pin_entry *pin;

  pin = gpio_pins;
  while( true ) {
    if (pin->pin_name[0] == '\0') {
      return false;
    }
    if (((pin->pin_name[0] != '-') && (pin->unkn1 == 0)) && (fail = export_gpio_pin(pin), fail))
    break;
    pin = pin + 1;
  }
  return true;
}

with that, we arrive at a pretty good understanding of what gpio_initialize does:

bool gpio_initialize(s_gpio_pin_entry *gpio_list)
{
  bool fail;

  fail = false;
  if (gpio_initialize_ran == 0) {
    gpio_initialize_ran = 1;
    fail = export_gpio_pin_list(gpio_list);
    if (!fail) {
      fail = set_gpio_mode_list(gpio_list);
    }
  }
  return fail;
}

A THUNK to remember

all that we need now is to find who calls gpio_initialize, and what parameter it uses. if we find that parameter, we have everything we need.

at first this seems bad, gpio_initialize only has one caller, and that’s all messed up:

void gpio_initialize(void)
{
  gpio_initialize();
  return;
}

that matches nothing of what we expect.

but fear not, this is just some weirdness with how ghidra decompiled the code. looking at the disassemly, there’s a big label calling this thing a “THUNK FUNCTION”. now, what is that?!


me when thunk function

a quick search reveals that, simply put, a thunk function is just a intermediate function that does nothing but call another function. it’s a bit special tho, as it only branches to the target, without messing with the stack or registers. thus, ghidra doesn’t show any parameters or return value, as there technically aren’t any. instead, they are just passed through.

gpio_initialize was likely thunked because it’s an export symbol, but that’s just speculation on my part.

Discovering The Button GPIOs

anyway, going to the single caller of the thunked gpio_initialize, we luckily find something that makes more sense:

void FUN_00101d44(void)

{
  gpio_initialize(&DAT_00114128);
  read_reset(&DAT_00114128);
  return;
}

looks like we found our parameter!

cleaning it up (and adding the global as a dummy), we get:

void something_gpio_initialize_and_read_reset(void)
{
  gpio_initialize(&G_GPIO_LIST);
  read_reset(G_GPIO_LIST);
  return;
}

s_gpio_pin_entry G_GPIO_LIST[/*?*/] = {
  // ...
};

from the read_reset call, we can also guess that the first entry will be the reset button, and the rest will be leds. now we just have to type the global, and we’re done.


wait, there’s only one?

of course, it would’ve been to easy if it actually contains all entries. there must be another global where the leds are defined, and this is just the buttons.

but first, let’s note what we’ve found here:

Pin #	Direction	Active Low?	Initial Level	Description
396	in	yes	-	Reset Button

A Small Problem

So, GPIO pin 396 is the reset button, active low, input only. That makes sense, only one problem: the first GPIO number in linux is 512. writing to 396 will just error out.

something must have changed to the GPIO numbering scheme from Linux 4.6 (Stock OS) to 6.16 (what I’m using)…

another issue is that i cannot find any other globals that look like a list of s_gpio_pin_entry structs, or another call to gpio_initialize. i think with a bit more time, i could figure this out, but for now i’ll try something else.

Poking Around

because the LS1043a only has 128 GPIO lines, i guessed that the gpio numbers in the older kernel would have some offset, and that my reset button was on the lower end. i also took a guess that the leds would be nearby, because why would you route the signals all over the place?

with that, i started poking around the GPIOs, randomly writing stuff to them, in the hopes that i don’t kill something important. and suddenly, one of the leds changed!

weirdly, when i toggled the same GPIO (539) again, a different led changed. what the heck?

Figuring Out the LEDs and their Shift Register

a look at the board revealed that near the front panel leds, there’s a LV164A shift register. and we’ve just found the clock pin!

let’s just guess and assume that the data pin is either one up or one down from the clock pin. trying both, we find that indeed, GPIO 540 is the data pin!

with that, we can now control the front panel leds, by bit-banging the shift register:

#!/bin/bash

SHIFT_CLOCK_PIN=539
DATA_OUT_PIN=540
PATTERN="$1"

if [ -z "$PATTERN" ]; then
  echo "Usage: $0 <bitpattern>"
  exit 1
fi

[ ! -d /sys/class/gpio/gpio$SHIFT_CLOCK_PIN ] && echo "$SHIFT_CLOCK_PIN" > /sys/class/gpio/export
[ ! -d /sys/class/gpio/gpio$DATA_OUT_PIN ]   && echo "$DATA_OUT_PIN"   > /sys/class/gpio/export

echo out > /sys/class/gpio/gpio$SHIFT_CLOCK_PIN/direction
echo out > /sys/class/gpio/gpio$DATA_OUT_PIN/direction

for ((i=0; i<${#PATTERN}; i++)); do
  bit=${PATTERN:i:1}
  if [ "$bit" != "0" ] && [ "$bit" != "1" ]; then
    echo "Invalid bit '$bit' in pattern"
    exit 2
  fi

  echo "$bit" > /sys/class/gpio/gpio$DATA_OUT_PIN/value

  echo 0 > /sys/class/gpio/gpio$SHIFT_CLOCK_PIN/value
  echo 1 > /sys/class/gpio/gpio$SHIFT_CLOCK_PIN/value
done

here’s the patterns for the different leds. note however that the pattern is shifted MSB first, so the first value in the pattern ends up on the last led. secondly, the leds are active low, so a 0 lights up the led.

Pattern	LED
x000	Mode
0x00	Status
00x0	Attention
000x	Failover

why the hardware is setup with a shift register, when there’s plenty of GPIOs available, is beyond me. must’ve been cheaper than a bunch of transistors…

Finding the Reset Button

for the reset button, i simply dumped the current GPIO state for all GPIOs not set to output, once with and once without pressing the button. i then passed the outputs into diff, and voila, GPIO 620 is the reset button!

#!/bin/bash
for pin in {512..640}; do
  [ ! -d /sys/class/gpio/gpio$pin ] && echo "$pin" > /sys/class/gpio/export

  dir=$(cat /sys/class/gpio/gpio$pin/direction)
  if [ "$dir" != "in" ]; then
    continue
  fi

  val=$(cat /sys/class/gpio/gpio$pin/value)
  echo "#$pin = $val"
done

TL;DR Pin Mapping

the pin mapping is:

Pin #	Direction	Description
539	out	LED Shift Register Clock
540	out	LED Shift Register Data
620	in	Reset Button, low when pressed

the leds are controlled by a LV164A shift register, the first four outputs connect to the front panel leds. outputs of the leds are inverted, so a low level lights up the led.

LV164A Pin	LED
$Q_A$	Failover
$Q_B$	Attention
$Q_C$	Status
$Q_D$	Mode

Controlling the Front Panel from U-Boot

after doing all that, i noticed that the U-Boot of the T40 has a convenient 74lv164 command for controlling the shift register, and with that, the front panel leds. would’ve been nice to know that earlier, but oh well.

command usage is simple:

=> 74lv164 low  #-> all leds on
=> 74lv164 high #-> all leds off
=> 74lv164 qa 0 #-> failover
=> 74lv164 qb 0 #-> attn
=> 74lv164 qc 0 #-> status
=> 74lv164 qd 0 #-> mode

Conclusion

while i would’ve liked to fully reverse-engineer the libwgpanel.so library, but even if i found the pin mapping there, they wouldn’t map to the current kernel’s GPIO numbering anyway. while my final solution isn’t very elegant, it works, and so i think i’ll leave it at that.

Running Linux on a WatchGuard T40

2025-10-03T00:00:00+00:00

as if my obsession with watchguard firewalls wasn’t bad enough already, i recently got my hands on a WatchGuard T40. since i have no use for them as just an appliance, i decided it would be fun to get linux running on it. oh, how wrong i was…

Hardware Overview

the T40 is already discussed in the OpenWRT forums, with the general consensus being that it’d make a great OpenWRT device, if only it was supported. the hardware information claimed on the forums (as to whether they’re correct, we’ll see later) is as follows:

Board: LS1043a QDS
- LS1043A Layerscape SOC
Storage: mSATA 16GB
Bootloader: Custom U-Boot for WatchGuard, locked down to only boot from internal storage
Stock device tree is available in a post
- “it’s pretty much the LS1043A-RDB one from upstream linux”

now, here’s what i found after investigating my own T40:

LS1043A CPU, as expected
4GB RAM, also expected
16GB M.2 SATA SSD (idk how they got mSATA…)
1 x Atheros AR8035 GbE PHY (WAN port)
1 x Marvell 88E1510 Quad GbE PHY (LAN1-4 ports)
Bootloader is indeed a custom U-Boot, but easy to bypass (see below)

Accessing the U-Boot Shell

while the U-Boot is indeed locked down and only allows booting from the internal SATA SSD, there’s a little quirk: if - for any reason - U-Boot fails to boot the OS, it will drop to the U-Boot shell. if only we could make the boot fail…

one thing to make the boot fail is to simply remove the SSD. boot it up without the SSD, and it will drop to the U-Boot shell. from there, we can simply override the boot command to something else. i chose to set it to true, which does nothing and drops me into a shell immediately.

funnily enough, the boot option for SysB is called Recovery / Diagnostic Mode. a unprotected shell is a diagnostic mode, right?

env set wgBootSysB 'true'
env save
reset

from here on, the SSD can be reinserted, as we have a persistent way to drop into the U-Boot shell.

on the T20, i believe the boot device is a NAND flash chip soldered to the board. thus, it’s not really feasible to remove it. however, maybe something similar to the technique used for hacking the Nintendo Wii (see: Team Twiizers and the tweezer attack for the Wii) could work here - i.e. shorting some pins on the NAND flash to make it temporarily unreadable.

Initial Linux Boot

we have a U-Boot shell, so what now? one way i previously tackled this was to build a custom buildroot distro, put it on a USB stick, and boot from that. but that is kind of annoying, and also means i have to recompile every time i want to add some new software.

instead, i opted to boot Arch Linux ARM and the generic ARM64 image they provide. this gives me a full linux distro, with a package manager and everything, without having to recompile anything myself. well, except for a few caveats:

while the generic ARM64 kernel image kinda works, it doesn’t really have the driver support for the LS1043A. Things like the SATA controller or networking won’t work.
there is no device tree for the T40 included. luckily, we can just use the stock one - either extracted from the original firmware, or the one uploaded on the OpenWRT forums.
the initramfs format is not compatible with U-Boot. we can fix this by converting it to a uImage format using mkimage.

to summarize, prepare a USB stick as follows:

download the generic Arch Linux ARM image
extract to a usb stick using bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/my_usb_stick
convert initramfs using mkimage -A arm64 -O linux -T ramdisk -C gzip -d /mnt/my_usb_stick/boot/initramfs-linux.img /mnt/my_usb_stick/boot/initramfs.uImage.
(compile and) copy the T40 device tree to /mnt/my_usb_stick/boot/wg_t40.dtb.

now, we can plug the usb stick into the T40, and boot from it using U-Boot:

# start and scan usb
usb start

# ensure correct load addresses
env set kernel_addr_r 0x80080000
env set fdt_addr_r 0x90000000
env set ramdisk_addr_r 0x94000000

# load kernel, dtb and initramfs from usb
load usb 0:1 ${kernel_addr_r} /boot/Image
load usb 0:1 ${fdt_addr_r} /boot/wg_t40.dtb
load usb 0:1 ${ramdisk_addr_r} /boot/initramfs.uImage

# ensure bootargs are correct. can theoretically be omitted
env set bootargs console=ttyS0,115200 earlycon=uart8250,mmio,0x21c0500 root=/dev/sda1 rw rootwait

# boot the kernel image
booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

with that, linux should boot up kinda fine. of course, without proper drivers and a outdated device tree, not much more can be done. there’s no networking, no sata, and everything is kinda limited.

but it does run linux!

A Custom Device Tree

for the custom device tree, i started with the work done by @neggles. i still think this was the right move, even tho it caused me a lot of headaches later on. what didn’t make things better was that at this point in time, i also used a custom compiled kernel, which of course had a different configuration than the one provided by Arch Linux ARM.

A First Hiccup: OP-TEE

running a custom kernel and device tree, i thought i’d get at least as far as i did before. but nope, it simply crashes early during boot.


this is fine?

[ 4.220318] optee: probing for conduit method.
[ 4.231807] Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
[ 4.239559] Modules linked in:
[ 4.242619] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc6-00266-gcd89d487374c #1 PREEMPT
[ 4.257512] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.264481] pc : __arm_smccc_smc+0x4/0x30
[ 4.268504] lr : optee_smccc_smc+0x1c/0x2c
[ 4.272605] sp : ffff800081aabac0
[ 4.275917] x29: ffff800081aabad0 x28: ffff8000815c9068 x27: ffff8000814f00b0
[ 4.283069] x26: ffff8000819c2000 x25: ffff000800100810 x24: 0000000000000000
[ 4.290220] x23: ffff000800100800 x22: 0000000000000000 x21: ffff800081aabb28
[ 4.297370] x20: ffff80008198f4c0 x19: ffff800080cdd550 x18: 0000000000000006
[ 4.304519] x17: ffff80008194dfc0 x16: 0000000014d92057 x15: ffff800081aab500
[ 4.311668] x14: ffffffffffffffff x13: 0000000000000038 x12: 0101010101010101
[ 4.318819] x11: 7f7f7f7f7f7f7f7f x10: 00007fff7e1fa464 x9 : 0000000000000018
[ 4.325969] x8 : ffff800081aabb28 x7 : 0000000000000000 x6 : 0000000000000000
[ 4.333119] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 4.340267] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000bf00ff01
[ 4.347418] Call trace:
[ 4.349862] __arm_smccc_smc+0x4/0x30 (P)
[ 4.353881] optee_probe+0xd4/0x970
[ 4.357373] platform_probe+0x5c/0x98
[ 4.361044] really_probe+0xbc/0x29c
[ 4.364624] __driver_probe_device+0x78/0x12c
[ 4.368987] driver_probe_device+0xd8/0x15c
[ 4.373176] __driver_attach+0x90/0x19c
[ 4.377017] bus_for_each_dev+0x7c/0xe0
[ 4.380857] driver_attach+0x24/0x30
[ 4.384436] bus_add_driver+0xe4/0x208
[ 4.388188] driver_register+0x5c/0x124
[ 4.392028] __platform_driver_register+0x24/0x30
[ 4.396740] optee_smc_abi_register+0x1c/0x28
[ 4.401102] optee_core_init+0x28/0x68
[ 4.404858] do_one_initcall+0x80/0x1c8
[ 4.408699] kernel_init_freeable+0x204/0x2e0
[ 4.413066] kernel_init+0x20/0x1d8
[ 4.416565] ret_from_fork+0x10/0x20
[ 4.420148] Code: d53cd045 d53cd042 d53cd043 d503245f (d4000003)
[ 4.426247] ---[ end trace 0000000000000000 ]---
[ 4.430910] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 4.438576] SMP: stopping secondary CPUs
[ 4.442507] Kernel Offset: disabled
[ 4.445993] CPU features: 0x000000,00080000,20002000,0400421b
[ 4.451742] Memory Limit: none
[ 4.454797] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--

what the heck is optee? this is were my inexperience with linux, especially on ARM, got really apparent to me. i spent forever on this, trying to figure out what the heck is going on.

well, turns out that linux expected to be booted by a trusted execution environment (TEE), essentially secure boot for ARM. but u-boot does not do that.

because the way that OP-TEE in linux works, it calls into the TEE using a special SMC instruction. without the TEE actually there, and the CPU not configured for it, this instruction is undefined instead, and the kernel panics.

so, why is OP-TEE even enabled? well, the culprit is in the base device tree fragment for LS1043a, defined by the linux kernel (fsl-ls1043a.dtsi):

/ {
  // (...)
  firmware {
  	optee {
  		compatible = "linaro,optee-tz";
  	  	method = "smc";
  	};
  };
};

this basically tells the kernel that there’s a TEE available, and it should use it. removing this node makes the kernel boot just fine, and is easily done by adding the following to our custom device tree:

/delete-node/ &{/firmware/optee};

with that, the kernel at least boots without panicking. however, we still not back to where we were before, as now usb enumeration doesn’t work anymore.

The Pain of USB Enumeration Issues

normally, usb enumeration not working wouldn’t be that much of a dealbreaker. sure, i’d like to have usb working, but it’s not essential.

except in this case, it is. with SATA still not working, the place i put my root filesystem was on a usb stick. and that usb stick is not being detected at all. so, no usb = no root filesystem = no linux.

:: mounting '/dev/sdb1' on real root
mount: /new_root: fsconfig() failed: /dev/sdb1: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.
ERROR: Failed to mount '/dev/sdb1' on real root
You are now being dropped into an emergency shell.

so what’s going on here? the LS1043a has tree build-in usb controller, all of which are based on the Synopsys DesignWare Core 3 USB controller IP (snps,dwc3). this controller supports both USB2 and USB3, is configurable as host or device, and is handled by the USB_DWC3 linux kernel driver.

all of that is completely irrelevant here, as the issue was something completely unrelated to the usb controller itself. this took me forever to figure out, at least two weeks of research and trial-and-error. nothing worked, until i randomly decided to remove the dma-coherent property from the soc node in the device tree. no idea why, but that made usb enumeration work again.

the watchguard dts also doesn’t have that property, so maybe this is a bug in the upstream dts file? i don’t know, but at least it works now.

in the custom device tree, we add the following and continue - confused as to why it works:

&soc {
    /delete-property/ dma-coherent;
};

there’s one good thing about this whole ordeal: i now am a lot more comfortable with device trees, decompiled and in source form.

Custom Linux Kernel Configuration

until now, i simply used the ARM64 defconfig of linux. with that, lots of things don’t work, things as simple as usb network adapters.

to fix this, i extracted the kernel config from the Arch Linux ARM image, and used that as a base for my own custom kernel config. with this, i have a sensible base to start from, and can now enable things as needed. first on that list is the SATA controller, so i can access the internal SSD.

The SATA Controller

this is super simple. the device tree already has the correct node for the SATA controller, and it’s not even broken. we simply need to enable the QORIQ AHCI kernel driver with CONFIG_AHCI_QORIQ=y, and the SATA controller gets detected.

Note: QORIQ is NXP’s marketing name for some of their SoCs, including the LS1043a.

Thermals

it’d be nice to have thermal monitoring, but by default the sensors are not picked up. for this, we again simply need to enable the QORIQ thermal driver with CONFIG_QORIQ_THERMAL=y. with this, the thermal sensors are detected and available in /sys/class/thermal/.

Networking I: Quad PHY (LAN1-4)

this one’s easy, as the T40 borrows the quad ethernet PHY from the LS1043A-RDB reference design.

on both the RDB as well as the T40, four of the ethernet ports are handled by a Quad Ethernet PHY - in the case of the T40, a Marvell 88E1510. simply copying over the ethernet-related parts of the RDB’s device tree over to our custom T40 device tree, replacing the mdio stuff done by neggles, makes these four ports work just fine.

of course, we also need to enable the corresponding kernel drivers for Freescale’s FMan (CONFIG_FSL_FMAN=y), but that’s it. four of five ethernet ports working, not bad.

Networking II: Atheros PHY (WAN0)

remember the OpenWRT forum post from earlier, the one claiming the T40 is basically just a LS1043A-RDB? well, when it comes to the WAN port, that’s not true at all.

the LS1043A-RDB uses an (kinda impressive tbh) Marvell AQR105 10GBASE-T PHY in place of the T40’s Atheros AR8035. that means that, understandably, this part of the device tree doesn’t match at all. different PHY, protocols, driver, everything.

luckily, the AR8035 is supported by the linux kernel out of the box, and thanks to being a pretty common PHY, there’s some other boards (even Layerscape ones) using it as well. one such board is the Kontron SMARC-sAL28. although it uses the LS1028a, that doesn’t matter much since both share the same networking infrastructure. that’s enough to give the clues that we need phy-mode = "rgmii-id";, as well as defining eee-broken-1000t and eee-broken-100tx to work around some [email protected]/">issues with Energy Efficient Ethernet. i initally also included qca,clk-out-frequency and related properties, but after closer inspection of the board it turns out that the clock output of the AR8035 is not connected to anything, so those properties are not needed.

now just a single question remains: where to put this in the device tree? here, u-boot can actually help us out. running mdio list in u-boot shows us how the PHYs are connected from u-boot’s POV:

=> mdio list
FSL_MDIO0:
4 - Generic PHY <--> FM1@DTSEC1
5 - Generic PHY <--> FM1@DTSEC2
6 - Generic PHY <--> FM1@DTSEC5
7 - Generic PHY <--> FM1@DTSEC6
FM_TGEC_MDIO:
1 - AR8035 <--> FM1@DTSEC3

the AR8035 is connected to FM1@DTSEC3, which is the third ethernet port of the first FMan instance, or ethernet@e4000 in the device tree. with a bit of guess-work (and consulting the stock T40 device tree), we can then figure out that the MDIO is mdio@fd000 (xmdio0).

adding all that, and we finally get a link working on the WAN port as well.

as for if the link also runs at gigabit speeds, i have no idea. my current setup is so janky that i can only test with 100Mbit/s. that, however, works just fine.

Overclocking the CPU

the LS1043a SoC of the T40 is clocked at only 1.0GHz, but would be capable of running at up to 1.6GHz. sadly, the clock speed cannot be increased directly from linux - the clock scaling drive can only go down. to change the clock speed, the RCW (Reset Configuration Word) values in flash need to be modified. see this follow-up post for my journey into that.

The Front-Panel

the T40 has a “front” panel (technically, parts of it are at the back) consisting of the reset button, and four status LEDs (Failover, ATTN, Status, Mode). theres of course also the many leds for the ethernet link status, but they’re controlled by the PHYs themselves and are not really interesting. to get the front-panel leds to work, we need to control the correct GPIOs. see this follow-up post for more information on that.

Conclusion and Next Steps

linux now works pretty well on the T40. i still need to confirm that the PHYs can actually do gigabit speeds, but other than that, everything seems to be in order.

as for next steps, i might try to do a proper port of OpenWRT to the T40. but that will probably take a bit, as i’m not very familiar with the OpenWRT build system.

if you want to try it out yourself, you can find my linux fork with the custom kernel config and device tree on github. for the rootfs, i recommend using the generic AARCH64 Arch Linux ARM image, as described above.

Reverse-Engineering the Front Panel of a WatchGuard T70

2025-09-18T00:00:00+00:00

in the previous posts, we explored how to jailbreak a watchguard t70 and run linux on it. sadly, by default the front panel (leds, reset button) are not functional in linux. let’s change that by reverse-engineering the custom kernel module that watchguard uses in their own os.

Finding the Module

Note:
for whatever reason, i decided to do this on a T55 first. since it’s basically the same hardware, everything applies to the T70 as well.

just by taking a quick look at the bootlog of the stock os we find a very interesting line:

LED/Reset Button Driver for MB-UP2010W...

that sounds like exactly what we are looking for! searching a bit around the line, we can see that the module seems to be loaded by a init script /etc/runlevel/1/S09sled_drv, as well as some debug output from the module itself:

[   17.023341] Running /etc/runlevel/1/S09sled_drv...
[   16.645496] sled_drv_t55: loading out-of-tree module taints kernel.
[   16.652895] <chv_pinctrl_probe> Invoked!
[   16.657302] <chv_pinctrl_probe>: probe res check, IORESOURCE_MEM: start=00000000fed80000, end=00000000fed87fff, name=INT33FF:00
[   16.670182] <chv_pinctrl_probe>: probe res check pctrl->regs = ffffc90000430000
[   16.678364] <chv_pinctrl_probe>: probe res check, IORESOURCE_MEM: start=00000000fed88000, end=00000000fed8ffff, name=INT33FF:01
[   16.691219] <chv_pinctrl_probe>: probe res check pctrl->regs = ffffc90000440000
[   16.699397] LED/Reset Button Driver for MB-UP2010W...

looking at the init script, it’s fairly simple and just loads a kernel module /lib/drivers/sled_drv-t55.ko or /lib/drivers/sled_drv-t70.ko depending on the model. the following is pseudo-code of the script, as i’m not quite sure about the copyright status.

dir="/lib/drivers"

model=wg.get_model()

if (model == "T70") then
  wg.insmod(dir .. "sled_drv-t70.ko")
elseif (model == "T55" or model == "T55-W") then
  wg.insmod(dir .. "sled_drv-t55.ko")
end

so, the module we are looking for is /lib/drivers/sled_drv-t70.ko and /lib/drivers/sled_drv-t55.ko (both are present on both models, as they use the same firmware image). now, let’s extract the module and load it into ghidra.

Understanding the Module

looking at the (what i assume to be) entry point of the module, we can see that it maps some (I/O) memory regions, then calls a function sled_init. this already is very useful information, as on intel braswell (the cpu), gpio is handled through memory-mapped i/o. even better, referencing iomap.h of the coreboot project, we can see that the start addresses of the mapped regions correspond to the gpio controllers, specifically the GPIO Communities SouthWest (at 0xfed80000) and North (at 0xfed88000).

ulong likely_entry_point(long param_1)
{
  // (...)
  printk("<%s> Invoked!\n","chv_pinctrl_probe");
  // (...)

                  // for each resource
  do {
    printk("<%s>: probe res check, IORESOURCE_MEM: start=%p, end=%p, name=%s\n",
    "chv_pinctrl_probe",*current_res,current_res[1],current_res[2]);
                  // -> <chv_pinctrl_probe>: probe res check, IORESOURCE_MEM:
                  // start=00000000fed80000, end=00000000fed87fff, name=INT33FF:00
                  // -> <chv_pinctrl_probe>: probe res check, IORESOURCE_MEM:
                  // start=00000000fed88000, end=00000000fed8ffff, name=INT33FF:01
    rc = devm_ioremap_resource(dev,current_res);
    *res_ptr = rc;

    printk("<%s>: probe res check pctrl->regs = %p\n","chv_pinctrl_probe",rc);
                  // -> <chv_pinctrl_probe>: probe res check pctrl->regs = ffffc90000430000
                  // -> <chv_pinctrl_probe>: probe res check pctrl->regs = ffffc90000440000

    current_res = current_res + 8;
  } while ((ledmappings_entry *)current_res != ledmappings);

  // (...)
  sled_init((undefined *)likely_pctrl);
}

next, looking at sled_init, we see a character device is registered. that must be how the front panel is controlled from userspace. (side-note: there’s actually a whole library, t55-libwgpanel.so, that abstracts the ioctl calls to the character device, but we won’t look at that here.)

int sled_init(undefined *likely_pctrl)
{
  int err;

  printk("\x015LED/Reset Button Driver for MB-UP2010W...\n");
  err = __register_chrdev(0xf0,0,0x100,"sled_drv",&chrdev_fops);
  // (...)
}

(partially) defining the file_operations struct and correctly typing the chrdev_fops global, we see that compat_ioctl, flush and fsync are implemented. the latter two aren’t really interesting, but compat_ioctl is where the actual functionality is implemented. basically, it boils down to calling one of two functions (set_led_off and set_led_on), depending on the command and argument passed to the ioctl.


`chrdev_fops` global

we’re almost there! set_led_on and set_led_off are quite simple, they just call a lookup function findled to (presumably) convert an led id to a gpio pin, then call a write function to actually write to the pin.

void set_led_on(undefined *pinctl,int led_no)
{
  ledmappings_entry *led = findled(led_no);
  if (led != nullptr) {
    likely_write_led_gpio(pinctl,led->gp_pad,led->led_on_level);
  }
}

finally, let’s look at how findled figures out the mapping. it’s actually quite simple, it just iterates over a static array of mappings (ledmappings) and returns the one that matches the given id.

the original code may have looked something like this:

// ... foreshadowing ...
#define WG_LED_STATUS 0
#define WG_LED_ATTN 2
#define WG_LED_MODE 3
#define WG_LED_FAILOVER 4

struct ledmappings_entry {
  int led_no;
  int gp_pad;
  int led_on_level;
};

struct ledmappings_entry ledmappings[] = {
  { WG_LED_STATUS, 7, 0 },
  { WG_LED_ATTN, 3, 0 },
  { WG_LED_MODE, 1, 0 },
  { WG_LED_FAILOVER, 5, 0 },
}

ledmappings_entry* findled(int led_no)
{
  for (int i = 0; i < COUNT_OF(ledmappings); i++) {
    if (ledmappings[i].led_no == led_no) {
      return &ledmappings[i];
    }
  }

  return nullptr;
}

and now, we (almost) have the pins mapped out! only one problem remains: the driver maps two gpio controllers, but we don’t know which pin belongs to which controller.

while i could probably spend a lot of time figuring that out too, i opted to simply try out both options and see what happens. what’s the worst that could happen, right?


let’s gambling

Note on Reverse-Engineering Steps

the steps shown above are very high-level and skip a lot of details, and are also in a different order than i actually did them.

for example, the chain leading to ledmappings was basically in reverse, as ledmappings, findled, set_led_on and set_led_off were actually exported symbols (thus i knew their names). also, there were some “side-quests”, like taking a quick look at ``t55-libwgpanel.so` and other binaries, to understand how the leds are controlled from userspace.

still, i think the above rendering makes it easier to understand the overall flow, even if it doesn’t quite match the actual steps taken.

Finalizing the Pin Mapping for Linux

looking at the gpio implementation in linux, we see that gpio communities SouthWest and North are mapped to gpiochip0 (GPIOs 512-609) and gpiochip1 (610-682) respectively.

# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 512-609, parent: platform/INT33FF:00, INT33FF:00:
gpiochip1: GPIOs 610-682, parent: platform/INT33FF:01, INT33FF:01:
gpiochip2: GPIOs 683-709, parent: platform/INT33FF:02, INT33FF:02:
(...)

using the gp_pad values from the ledmappings array as an offset to the first pin of each chip, we get some potential linux GPIOs. poking those pins and observing, we can finally figure out which pin does what.

`led_no`	`gp_pad`	# when on GP_SouthWest (@ 512)	Reaction when Poked	# when on GP_North (@ 610)	Reaction when Poked
3	1	513	None	611	Mode LED
2	3	515	None	613	ATTN LED
4	5	517	None	615	Fail Over LED
0	7	519	None	617	Status LED

and there we have it, we can now control the front panel leds from linux! to be honest, i don’t really understand why they mapped GP_SouthWest at all, but seeing how the T70 driver only maps GP_North, maybe it was just an oversight.

What about the Reset Button?

while sled_drv probably also somehow implements the reset button, i decided to just keep gambling and poke nearby pins on GP_North. that should be a safe bet, as it’s generally convenient to place similar components close to each other when creating a schematic (at least that’s what i would do).

turns out, the first pin i tried (610) was indeed the reset button! testing the other pins (612, 614, 616), the first two seem to handle some internal functions (indicated by status leds on the board), while 616 does nothing.

How to try it out

if you want to try it yourself, you can use the following commands (as root; tested on ubuntu server 24.04):

gpio=611  # Mode LED

echo "$gpio" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio$gpio/direction

echo "1" > /sys/class/gpio/gpio$gpio/value
# or
echo "0" > /sys/class/gpio/gpio$gpio/value

and for the reset button:

gpio=610  # Reset Button

echo "$gpio" > /sys/class/gpio/export
echo "in" > /sys/class/gpio/gpio$gpio/direction

level=$(cat /sys/class/gpio/gpio$gpio/value)
echo "$level"

a full mapping of the pin functions is as follows:

Supported Model	GPIO Pin	Function	Notes
T55 & T70	610	Reset Button	0=Pressed, 1=Released
T55 & T70	611	Mode LED	0=ON, 1=OFF
T70	612	LED near backplane NIC	0=OFF, 1=ON
T55 & T70	613	ATTN LED	0=ON, 1=OFF
T55	614	LED near switch IC	0=OFF, 1=ON
T70	614	LED near network ports / power switch	0=OFF, 1=ON
T55 & T70	615	Fail Over LED	0=ON, 1=OFF
T55 & T70	617	Status LED	0=ON, 1=OFF

(Somewhat) Cursed WatchGuard T55 / T70 Hardware Mods

2025-09-13T00:00:00+00:00

with both of my watchguards fully jailbroken and behaving (mostly) like a normal linux box, but still waiting on some smaller details before actually utilizing them, i decided to poke around the hardware a bit more.

my motivation on this was straight-forward: both of my units have some unpopulated components on the pcb, so i wanted to see if i could get them working. also, there’s the issue with the switch ports beign disabled by default, as the original os configured them in software…

T55 & T70: Enabling the switch ports

this one’s an already well known mod, but i figured i’d document it here anyway.

the switch chip on both the t55 and t70 is, by default, set to be configured by the main cpu via an mdio interface (connected to the backplane NIC’s mdio port). only issue is, you’d need a custom kernel module to do that, and there isn’t one available outside of the original firmware.

luckily, by simply removing a single resistor (R607 on both the T55 and T70), you can force the switch into “dumb” mode, where it just acts like a regular unmanaged switch. credits to @konus on the OpenWRT forums for figuring this out.


removing R607 makes the switch dumb

T55: Adding a WiFi module

besides the T55, watchguard also offers a T55-W model, which has WiFi capabilities - but is otherwise identical to the regular T55. to save costs, watchguard simply removed the mini-PCIe slot and the associated components from the regular T55 model. nothing we can’t fix, though!

to restore the mini-PCIe slot, we simply need to add the inline capacitors of the pcie lanes (C271 and C272), as well as some in-line resistors for mpcie control lines (R8547 and R8551). oh, and of course, the mini-PCIe slot itself.

annoyingly, watchguard also omits the power supply components for the mini-PCIe slot. but we can simply steal power from the switch’s power rail (@ TP61), as both use 3.3V, and a mini-PCIe card probably won’t draw that much power anyway.


Not pretty, but it works

T70: Adding HDMI Output

both the T55 and T70 have an unpopulated HDMI port near in the bottom left corner of the PCB. however, curiously, on the T70 they did not omit the associated components to actually make use of it.

meaning, we can simply solder a HDMI port onto the board, and get video output!


HDMI port soldered onto the T70

with this alone, we still don’t get any output, as the iGPU is disabled by default in the BIOS. however, since we have full BIOS access, we can simply enable it there, and voilà - we have video output!

now, what to do with it …

Windows 11 on the T70 ?!

with a video output, there’s nothing stopping us from installing Windows 11 on the T70. surely some random firewall appliance is a supported platform, right Microsoft?

installation and usage went pretty effortlessly (albeit quite slow, as theres only 2GB of RAM and the rest of the hardware is not exactly high-end either).

only quirk: for some reason, the OEM logo embedded into the BIOS is really messed up.


Booting Windows 11 on the T70

Hello, World!

2025-09-09T00:00:00+00:00

hi there!

if you’re reading this, you’ve found my page. i’ve set this up to have a place to write about the random stuff i do, and maybe share some of my thoughts. idk how much i’ll actually write, but we’ll see.

this page is built using Lanyon, a theme for Jekyll. find out more by visiting the project on GitHub.

Patching the BIOS of a WatchGuard T70 to Remove the Password

2025-08-31T00:00:00+00:00

in the last post, we explored how to run linux on a watchguard t70. while it’s quite useable as is, the bios password is a bit of an annoyance. so, let’s patch the bios to remove the password check entirely.

Recap

from the previous post, we already have the bios image extracted and loaded into ghidra. we also already found the password check function, which is how we know the password in the first place.


the password check function

Removing the Password Check

looking a bit closer at the function, we can see some convenient details that make our job easier:

the function only has a single call site
the function doesn’t have a return value
the function doesn’t take any parameters
the function doesn’t have any relevant side effects (other than showing a prompt on the screen)

that means we can simply NOP out the entire function call, and be good to go.


password check call site	nop it out

i found that patching and exporting with ghidra was a bit finnicky, so i just noted the pattern of bytes to patch, and used a hex editor to do the actual patching.

the modified BdsDxe module is then re-inserted into the bios using H2OEZE - which correctly recalculates the checksums for us. the patched bios binary is then flashed back to the device and voila - no more password prompt!

How You can Jailbreak Your T70

while i’d love to share the patched bios image, i can’t in good conscience do that.

however, with the knowledge in these posts, you can jailbreak your own T70 - without even opening the case. Watchguard will surely still honor the warranty - right?

prepare your hardware:
1. plug in a bootable usb stick with, for example, ubuntu server 24.04
2. connect a network cable OR a wifi adapter (i used a network cable)
3. plug in a serial console cable and configure your terminal to 115200 8N1
interrupt the boot process using <ESC> and enter the setup utility (something we can do now that we have the password)
in the setup utility, set the following settings:
1. Boot > Boot Mode to UEFI (needed for ubuntu server)
2. Boot > USB Boot to Enabled (boot from usb)
3. Advanced > Chipset Configuration > Misc Configuration > BIOS Lock to Disabled (allow flashing the bios)
save changes and reboot, you should now see grub on the serial console
edit the grub entry to add console=ttyS0,115200 to the kernel command line so you can see the installer output
continue until you see the installer prompt, then exit to the shell via the “help” menu
install flashrom via apt install flashrom
dump your current bios via flashrom -p internal -r bios.bin (do this twice and compare hashes to be sure everything went well), then transfer to a windows computer
open the dumped bios in H20EZE and extract the BdsDxe module as a .ffs
open the .ffs in a hex editor, find and replace the pattern to the function call with NOPs (refer to table below)
save the modified .ffs
use “replace module” in H20EZE to insert the modified BdsDxe module back into the bios
export the modified bios as a .fd and transfer back to the T70
flash the modified bios via flashrom -p internal -w bios.patched.fd
reboot and enter setup utility to verify the password prompt is gone
(optionall) re-enable BIOS Lock to prevent accidental flashing

Product	BIOS Version String	BIOS Dump SHA256 (`Get-FileHash bios.fd`)	Password Check Call Pattern	Replace With
T55	77.05	`1B13A7CD8D8CBDAEC6C3158AEBF74F8CC3B2D3519202A516A152F3F1FDDBD8A2`	`e8 31 d3 ff ff`	`90 90 90 90 90` (5x NOP)
T70	1.16	`A180292ABD17466B789A437B2758BA702FADB5EA226BCADBDD2DD6266F0D7AEE`	`e8 31 d3 ff ff`	`90 90 90 90 90` (5x NOP)

Running Linux on a WatchGuard T70

2025-08-29T00:00:00+00:00

so, i’ve recently got my hands on an old WatchGuard T70 firewall, and i thought it would be a fun project to see if i could get Linux running on it. while it may not be the most powerful, it should still be interesting for running some basic stuff like DNS or network monitoring. since some people managed to boot OpenWRT on it, i figured it couldn’t be that difficult - right?

We do this not because it is easy, but because we thought it would be easy.
- Programmer’s Credo

Hardware Overview

the T70 is based on a Intel Celeron N3160 from ~2016. for a small server, this is still quite usable and most importantly with only 4-6 W TDP, it should be quite power efficient and silent. the 2GB ram is a little limiting, but should still be fine

as for software, the stock OS is some embedded linux variant, but it’s quite locked down and thus not really useful to me. the bios is an more-or-less standard Insyde H20 one, but it’s password protected. sadly, clearing the cmos doesn’t reset the password and most tools online cannot bypass it either. also, as a further annoyance, the bios only allows booting from the internal MSATA ssd (according to some sources online, the spare sata port also works, but i haven’t tested that).

full specs:

Intel Celeron N3160 CPU (4 cores @ 1.6 GHz)
2 GB RAM (DDR3L-1600 soldered to the board)
16 GB MSATA SSD
a spare SATA port
4x Intel 1911BFP NICs
- 3x connected directly to GBE ports
- 1x connected to a internal 88E6176 switch IC, which has 5x GBE ports connected to it
2x USB 2.0 ports
Insyde H20 BIOS, password protected, only boots from internal SSD in legacy mode


pcb top	pcb bottom

First Steps: Booting Alpine Linux from USB

this first attempt actually worked pretty easily. while the bios is locked down, i do happen to have a SPI flash programmer, so i simply dumped the bios. from there, a tool called H20EZE can be used to simply change the default settings of the bios. for a start, i simply enabled booting from usb devices. once flashed back, the clear CMOS jumper is used to load the defaults, and thus i could finally boot from a USB stick.

now, since there’s only a serial console, i had to modify the bootloader config and kernel command line, but that’s easy enough (see this guide).

so far so good, but alpine is still quite limited, and i’d rather run something more full featured like Ubuntu Server.

Booting Ubuntu Server from USB

turns out the bios does support UEFI boot, but it’s simply not enabled in the default settings. using the same methods as before, i set the bios to UEFI mode, enabled usb boot, and disabled secure boot. flashed it back, cleared CMOS, and voila - the T70 boots the Ubuntu Server installer from USB just fine.

again, serial console needs to be enabled in grub, but other than that, everything works just fine.

still, i’d rather not have to mess with flashing the bios every time i want to modify a setting. it’s not really practical, is it? so, next step is to bypass the bios password protection or figure out the password.

Accessing the BIOS Setup

WatchGuard, being a seasoned IT security company with hundreds of millions in revenue, of course did their homework here and locked down the bios quite well. they even went out of their way to implement their own password protection, instead of using the built-in Insyde H20 password protection. thus, clearing the CMOS doesn’t reset the password, and the normal backdoor passwords for Insyde H20 don’t work either.


the dreaded password prompt

so, how do we get around this?

First Attempt: Poking at the BIOS Modules

yes, this first attempt was a bit naive.

H20EZE has a function to remove bios modules, so i thought

hey, maybe i can just remove the password checking module, and then the bios won’t ask for a password at all
- naive past me

predictably, that didn’t work out. for some modules, there seems to be no effect at all, while for others, the bios simply refuses to boot.

so, onto the next idea.

Second Attempt: Brute Forcing the Password

in hindsight, i think i was just looking for an excuse to not do anything the right way. so, instead of simply booting up ghidra, i wrote a crappy python script that attempts to brute-force the password - over a serial connection at 115200 baud.

yeah, that was a bad idea. since each attempt takes ~0.5 seconds, i’d be sitting here for a bazillion years (estimate) until it finds the password.


Ain’t nobody got time for that

so, no way around it, let’s do things properly now.

Third Attempt: Reverse Engineering the Password Check

searching for the string “Input Password” that appears at the password prompt using UEFITool tells me the string appears in two modules: BdsDxe and SetupUtility.

SetupUtility is a false lead here, since the string is actually a sub-string of the help text for the stock password protection feature of Insyde H20, which is not used.
BdsDxe is what we’re after. it contains the actual password checking code, which is custom made by Watchguard.

UEFITool has a feature to extract the PE image of a uefi module. So let’s load that into Ghidra for analysis.

The Password Check Function

after initial analysis by ghidra, searching for the “Input Password” string gives us a single match - with a single cross-reference to it. that cross reference brings us right to the function that prompts for - and checks - the password.


cross reference for “Input Password” in ghidra

this function truely is a sight to behold. take a look for yourself:


the password check function	the developer who reviewed it

as you can see, it’s highly secure… well, almost. to be fair, it’s not like this is highly critical to the security of the device, since misusing it requires physical access anyway. but still, i at least expected something involving the serial number of the device or something like that.

let’s clean it up a bit, and see what it does:

void password_check(void)
{
  longlong n;
  short *user_input [4];
  char the_password [16];
  char user_input_ascii [32];

  builtin_strncpy(the_password,"WatchGuard!",0xb);
  (**(code **)(*(longlong *)(DAT_0006b1a8 + 0x40) + 0x30))(*(longlong *)(DAT_0006b1a8 + 0x40));
  do {
    do {
      user_prompt(L"Input Password",user_input);
      likely_utf16_to_ascii(user_input[0],user_input_ascii);
      FUN_0003c424();
      n = strlen(user_input_ascii);
    } while (n != 0xb);
    n = strncmp_with_identity_check(user_input_ascii,the_password,0xb);
  } while (n != 0);
  return;
}

so, how does this work? to figure that out is left as an exercise to the reader. hope you can figure out the password ;)

if you don’t like random passwords sticking around, check out part 2 where i patch the bios to remove the password check entirely.

Exploring the Setup Utility

now we can access the bios setup, so what’s next?


i didn’t think i’d get this far

let’s take a quick look around to see what options are available. turns out, quite a lot of options are available - this is a fairly unlocked InsydeH20 bios. it seems like noone at WatchGuard expected anyone to get this far, so they didn’t bother limiting the options.


the bios setup main screen	what the hell is a PDM/Dfx?

also fun: the two OS choices are “Windows” and “Android”. not quite what i’d expect on a firewall appliance (imagine the horror of a Windows firewall).


ah yes, the two OSses you’d expect on a firewall	my reaction to the thought of a windows-based firewall

Side Note: WatchGuard T50

all of the above also applies to the T50, which is basically a T70 with some cut down hardware specs. it uses the same general platform and very similar bios (with the same password). only difference is the CPU (Celeron N3060 instead of N3160) and 3 less GBE ports (on the T50, all 5 ports are handled by a switch IC)

Voxelab Aquila V1.0.1 (and V1.0.2) Trimatic Stepper Control Mod

2025-02-10T00:00:00+00:00

This post describes how to modify the Aquila V1.0.2 HC32 mainboard in order to add TMC Stepper UART control lines. Doing this allows changing stepper driver parameters (e.g. stepping mode, current) from Marlin firmware.

NOTICE:
This post was written for the Aquila V1.0.2 mainboard.
However, since the Aquila V1.0.1 mainboard is fairly similar, it should still work.

Preword

Having the option to control the parameters of the stepper drivers is quite useful. For one, you’ll be able to enable the otherwise unavailable 1/256 microstepping mode that the TMC2208 and clones provide. Additionally, you can adjust the motor current more precisely than by using the “classic” analog pot.

However, the biggest advantage is to change the stepping mode, for example to disable StealthChop (quiet) mode. By doing this, advanced motion features like Linear Advance and Input Shaping are said to work better.

Hardware

On my mainboard, the following ICs were used:

HDSC HC32F460 MCU
- this is the main processor. If you have a different one, the information in this document could still be useful but the pins will not match.
KalixChips MS35775 Stepper Drivers
- These four ICs drive the stepper motors. These ICs are close to exact clones of the TMC2208 (see the datasheet (mirror) to see yourself), including the UART control mode. Main difference is the horrible lack of documentation.
- If you have different stepper drivers, and they don’t happen to be original TMC2208, do not continue with this mod until you’ve confirmed they support the UART control mode.
- If your board has TMC2209 stepper drivers, consider combining this document with another one specifically for those drivers. They support connecting to a single UART line, so require less pins and less cabling. However, this exact mod should still mostly apply.

VERY IMPORTANT:
double-check that your mainboard matches the hardware described here

Modification

This modification will set the mainboard up in such a way that each stepper driver is connected to one pin of the MCU, allowing half-duplex software-serial to be used. To ensure that a error while soldering or a broken stepper driver will not immediately damage the MCU, a 1k series resistor is added to each line.

NOTICE:
this mod leaves the PDN_UART 10k pull-up resistor in place.
this way, the modified mainboard will behave as before, unless the software takes control to drive the pins.

Requirements

sharp hobby knife
soldering iron with fine tip
thin, isolated wire
4x 1k SMD resistor
current Marlin firmware (with HC32 arduino core version 1.3.1 or newer)

Choosing the Pins

On this mainboard, there aren’t many pins left free for use. The free pins are (assuming you’ve installed a BLTouch probe):

Useable	Pin	Function / Connection	Note
⚠️	PA8	CH340G DTR	connected to CH340G DTR; otherwise useable
✅	PB2	Screen header #2	free for DWIN screen
✅	PB10	R90
❌	PB11	MD	multiplexed with MODE selection logic; input-only pin
✅	PC6	Screen header #1	free for DWIN screen
✅	PC14	XTAL32	can use GPIO
❌	PC15	XTAL32	datasheet says this pin works as GPIO, but in my testing input function didn’t work
✅	PH2	R101

I used pins PA8, PB10, PC14 and PH2 for my connections. This is what the rest of this document will describe too

Cutting trace PA8 -> CH340G DTR

As you can see in the table, PA8 is connected to the CH340G’s DTR pin. Luckily, DTR is not used for anything in this printer, so we can just cut the trace.


Cut trace PA8 to CH340G with a hobby knife

After cutting the trace, ensure there’s no copper sticking up that could short out to the case and measure with a multimeter that the trace is actually cut completely. To protect the area, place a bit of kapton tape over it.

Soldering the Wires

Solder the wires as shown in the following image.


Modification Wiring Plan

to ensure the wires don’t come loose, secure them with a bit of hot glue. for the PA8 connection, scrape away the solder mask on one of the wires near the HC32 before soldering.


Finished Modification

Configuring Marlin

Change the Marlin configuration to the following:

In Configuration.h, in @section stepper drivers:
- Change the stepper driver types from TMC2208_STANDALONE to TMC2208 for X,Y,Z,E0
in Configuration_adv.h, in the @section tmc/config section:
- add the pin definitions (RX is automatically set to TX if not defined):
  - #define X_SERIAL_TX_PIN PB10
  - #define Y_SERIAL_TX_PIN PA8
  - #define Z_SERIAL_TX_PIN PC14
  - #define E0_SERIAL_TX_PIN PH2
- add #define TMC_BAUD_RATE 19200 to use 19200 baud for serial communication
- update the RSENSE of all axis to #define [X]_RSENSE 0.15 (this board uses 150 mOhm current sense resistors)
- update the CHOPPER_TIMING to #define CHOPPER_TIMING CHOPPER_DEFAULT_24V
- optionally enable MONITOR_DRIVER_STATUS
- enable TMC_DEBUG until you’ve confirmed that everything works

Now, flash the firmware onto your modified mainboard. For initial testing, only the power cables have to be connected.

Confirm everything works

to confirm the mod was sucessfull, send a M122 command to show the status of the stepper drivers. there should be no errors, and the output should look something like this:

		X	Y	Z	E
Enabled		false	false	false	false
Set current	800	800	800	800
RMS current	760	760	760	760
MAX current	1072	1072	1072	1072
Run current	17/31	17/31	17/31	17/31
Hold current	8/31	8/31	8/31	8/31
CS actual	8/31	8/31	8/31	8/31
PWM scale
vsense		0=.325	0=.325	0=.325	0=.325
stealthChop	true	true	true	false
msteps		16	16	16	16
interp		true	true	true	true
tstep		max	max	max	max
PWM thresh.
[mm/s]
OT prewarn	false	false	false	false
OTPW trig.		false	false	false	false
pwm scale sum	10	10	10	10
pwm scale auto	0	0	0	0
pwm offset auto	36	36	36	36
pwm grad auto	14	14	14	14
off time	4	4	4	4
blank time	24	24	24	24
hysteresis
 -end		2	2	2	2
 -start		1	1	1	1
Stallguard thrs
uStep count	72	72	856	40
DRVSTATUS	X	Y	Z	E
sg_result
stst
olb					*
ola					*
s2gb
s2ga
otpw
ot
157C
150C
143C
120C
s2vsa
s2vsb
Driver registers:
		X	0xC0:08:00:00
		Y	0xC0:08:00:00
		Z	0xC0:08:00:00
		E	0x80:08:00:C0


Testing X connection... OK
Testing Y connection... OK
Testing Z connection... OK
Testing E connection... OK

if any of the last four tests fail, or if any of the driver registers show all zeros, double-check your wiring. additionally, you may want to double-check that the used pins are actually not connected to anything else (different mainboard revisions may differ here).

if everything seems right, try different values for TMC_BAUD_RATE. Lower values may help with signal integrity issues, while higher values can help with the stepper drivers having issues detecting that there’s a UART signal present. 19200 baud should be a good starting point.