OpenWRT auf dem Sophos SD-RED 20 installieren

Ein Community-Projekt zur Befreiung erstklassiger Enterprise-Hardware

Autor: DevOps Community Project
Datum: April 2026
Status: Phase 1 — Hardware-Reconnaissance
Zielgruppe: Erfahrene Linux-Administratoren mit Embedded-Erfahrung
Schwierigkeitsgrad: Fortgeschritten (U-Boot, Serial-Konsole, Cross-Compilation)

Warum dieses Projekt?

Tausende Sophos SD-RED 20 Geräte landen auf eBay oder im Elektroschrott, weil sie ohne eine kostenpflichtige Sophos Firewall als Gegenstelle nicht funktionieren. Das ist schade, denn die Hardware ist hervorragend: Ein NXP LS1012A ARM Cortex-A53 Prozessor mit Hardware-Paketbeschleunigung, 4x Gigabit-LAN, WAN mit SFP-Combo-Port, USB 3.0, Expansion Bay — und das alles bei unter 10 Watt Leistungsaufnahme.

Unter der proprietären Oberfläche läuft bereits ein modifiziertes OpenWRT. Sophos stellt die GPL-Quellen öffentlich zur Verfügung. Die Hardware verdient ein zweites Leben als vollwertiger Open-Source-Router, VPN-Gateway oder Edge-Device.

Dieser Artikel dokumentiert den systematischen Weg dorthin — ehrlich, mit allen bekannten Hürden und ohne falsche Versprechen.

Rechtliche Grundlage

Warum du das legal tun darfst

OpenWRT steht unter der GNU General Public License Version 2 (GPLv2). Sophos nutzt diese Freiheit: Sie bauen auf einer angepassten OpenWRT-Basis auf (Linux 4.14.x mit OpenWrt GCC 7.4.0), fügen ihre proprietären Tunnel- und Management-Komponenten hinzu und halten diese geschlossen. Das ist legal, solange die modifizierten GPL-Teile offengelegt werden.

Sophos erfüllt diese Pflicht: Auf der offiziellen Download-Seite unter https://www.sophos.com/en-us/support/downloads/firewall-installers liegt das Paket opensource_gpl_sd_red.tar.gz (Version 11), das die Quellen der OpenWRT-/Linux-Basis für alle RED-Modelle enthält.

Als Eigentümer der Hardware darfst du die Firmware komplett ersetzen. Die GPLv2 schützt dieses Recht ausdrücklich. Die Herstellergarantie erlischt allerdings beim Flashen.

Hardware-Spezifikation des SD-RED 20

Bevor wir loslegen, müssen wir die Hardware genau kennen. Viele Anleitungen im Netz scheitern, weil sie die Spezifika dieses Boards ignorieren.

Verifizierte Spezifikationen

Kritische Hardware-Details für den OpenWRT-Port

1. Packet Forwarding Engine (PFE): Der LS1012A verwendet für die Ethernet-Ports keine einfachen MAC-Controller, sondern eine Hardware-Paketbeschleunigung namens PFE (Packet Forwarding Engine). OpenWRT benötigt dafür die Pakete layerscape-ppfe und kmod-ppfe sowie einen proprietären Firmware-Blob (pfe.itb). Ohne diese Komponente funktioniert kein Netzwerk — das ist der häufigste Grund, warum naive Flash-Versuche scheitern.

2. Duales Flash-Layout: U-Boot und die Boot-Chain liegen im 2 MB QSPI-NOR-Flash. Das Root-Filesystem liegt im 128 MB NAND-Flash. Diese Trennung ist fundamental für die Boot-Strategie und muss beim Image-Build berücksichtigt werden.

3. Switch-Chip: Die vier LAN-Ports laufen über einen externen Switch-Chip (Hersteller und Modell müssen in Phase 1 identifiziert werden). Dieser braucht DSA-Treiber (Distributed Switch Architecture) im Linux-Kernel. Ohne korrekte Identifikation: kein LAN.

4. SFP-Combo-Port: Der geteilte WAN/SFP-Port braucht korrekte PHY-Konfiguration im Device Tree, um zwischen Kupfer und Glasfaser umschalten zu können.

5. Expansion Bay: Vermutlich ein Mini-PCIe- oder M.2-Slot — braucht PCIe-Konfiguration im Device Tree für die optionalen Wi-Fi- oder 3G/4G-Module.

6. Hardware-Watchdog: Enterprise-Geräte haben typischerweise einen Hardware-Watchdog, der das System automatisch neustartet, wenn die Software den Watchdog-Timer nicht regelmäßig zurücksetzt. Bei einem alternativen OS muss dieser entweder korrekt bedient oder deaktiviert werden.

OpenWRT und der NXP LS1012A — Aktueller Stand

Die gute Nachricht

OpenWRT unterstützt den NXP LS1012A offiziell seit Release 19.07.0 auf dem Layerscape-Target (layerscape/armv8_64b). Aktuell unterstützt (Stand OpenWrt 24.10.x) sind drei NXP-Referenzboards:

• LS1012A-RDB — Reference Design Board (QSPI NOR boot)
• LS1012A-FRDM — Freedom Board (QSPI NOR boot)
• FRWY-LS1012A — FreewayBoard (QSPI NOR boot)

Alle drei verwenden denselben SoC wie der SD-RED 20. Die CPU-Architektur, das PFE-Subsystem und die grundlegende Boot-Chain sind identisch. Das ist die Basis, auf der wir aufbauen.

Die Herausforderung

Der SD-RED 20 ist nicht im OpenWRT Table of Hardware gelistet. Die Unterschiede zu den Referenzboards liegen in:

• Anderer Ethernet-Switch-Chip und PHY-Konfiguration (4+1 Ports statt 2 Ports)
• Anderes Flash-Partitionslayout
• Andere GPIO-Belegung (LEDs, Reset-Button, Expansion Bay)
• Möglicherweise anderer U-Boot-Build mit Secure-Boot oder Passwortschutz
• Eigener Device Tree, der erst erstellt werden muss

NXP selbst bietet eine offizielle OpenWRT-basierte Broadband Home Router Application für den LS1012A an. In Kombination mit den Sophos GPL-Quellen haben wir damit zwei Referenzpunkte für die Portierung.

Voraussetzungen

Hardware

• Sophos SD-RED 20 (Rev. 1 oder höher)
• Micro-USB-Kabel (für Serial-Konsole, kein Standard-Datenkabel — es muss den USB-Serial-Chip ansprechen)
• Ethernet-Kabel (Cat5e oder besser, direkt vom PC zum SD-RED 20 LAN-Port)
• Optional: USB-zu-TTL-Serial-Adapter als Backup, falls der Micro-USB-Konsol-Zugang nicht funktioniert

Software auf deinem Arbeitsrechner

• Linux-Workstation (Debian 12 oder Ubuntu 24.04 empfohlen)
• Serial-Terminal: minicom, screen oder picocom
• TFTP-Server: tftpd-hpa
• OpenWRT Build-System: git, build-essential, libncurses-dev, gawk, flex, bison, etc.
• Cross-Compiler: Wird vom OpenWRT-Build-System automatisch gebaut (aarch64-openwrt-linux-musl)

Installation der Werkzeuge

# Debian 12 / Ubuntu 24.04
sudo apt update && sudo apt install -y \
    minicom screen picocom \
    tftpd-hpa \
    git build-essential libncurses-dev zlib1g-dev \
    gawk gettext libssl-dev xsltproc rsync wget unzip \
    python3 python3-distutils file

# TFTP-Server konfigurieren
sudo mkdir -p /srv/tftp
sudo chown -R $USER:$USER /srv/tftp
sudo systemctl enable --now tftpd-hpa

# Prüfen ob TFTP läuft
sudo systemctl status tftpd-hpa

Kenntnisse

• Sicherer Umgang mit U-Boot-Bootloader (printenv, setenv, tftpboot, bootm)
• Grundverständnis von Device Trees (.dts/.dtsi)
• Erfahrung mit dem OpenWRT Build-System (make menuconfig)
• Bereitschaft, das Gerät im schlimmsten Fall unbrauchbar zu machen (Brick-Risiko)

Phase 1: Hardware-Reconnaissance

Ziel: Die Hardware vollständig dokumentieren, ohne irgendetwas zu überschreiben. Alle Informationen sammeln, die für den Device-Tree-Bau und den OpenWRT-Port benötigt werden.

Schritt 1.1: Serial-Konsole anschließen

Verbinde das Micro-USB-Kabel vom COM-Port des SD-RED 20 mit deinem Linux-Rechner.

# USB-Serial-Chip identifizieren
dmesg | tail -20
# Erwartete Ausgabe (Beispiel):
# usb 1-2: new full-speed USB device
# usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0
# ODER: cp210x converter now attached to ttyUSB0
# ODER: ch341-uart converter now attached to ttyUSB0

# Den erkannten Chip notieren! Er bestimmt den Treiber.
# Falls kein ttyUSB* erscheint, Treiber manuell laden:
sudo modprobe ftdi_sio    # für FTDI-Chips
sudo modprobe cp210x      # für Silicon Labs CP2102/CP2104
sudo modprobe ch341       # für CH340/CH341

# Serial-Terminal starten
# Baudrate: 115200, 8 Data Bits, No Parity, 1 Stop Bit, No Flow Control
screen /dev/ttyUSB0 115200

# TIPP: Gesamten Output mitschneiden für spätere Analyse:
screen -L -Logfile sdred20-bootlog.txt /dev/ttyUSB0 115200

Wichtig: Starte die Serial-Konsole bevor du das Gerät einschaltest. So fängst du die komplette Boot-Sequenz ab, inklusive U-Boot-Version, Speichertest und Kernel-Meldungen.

Schritt 1.2: U-Boot unterbrechen

Schalte das Gerät ein und beobachte die Serial-Konsole. U-Boot zeigt typischerweise eine Countdown-Meldung:

Hit any key to stop autoboot: 3

Drücke sofort Enter (oder die in der Meldung genannte Taste). Du solltest den U-Boot-Prompt sehen:

=>

Falls der Autoboot-Interrupt nicht funktioniert: Mögliche Ursachen sind ein sehr kurzes Timeout (0-1 Sekunde), ein Passwortschutz, oder Secure Boot. In diesem Fall:

• Versuche verschiedene Tasten: Enter, Leertaste, ESC, beliebige Buchstaben
• Halte die Taste vor dem Einschalten gedrückt
• Falls ein Passwort abgefragt wird: Die Sophos-Standard-Credentials sind möglicherweise dokumentiert oder aus dem GPL-Quellcode ableitbar

Dokumentiere die vollständige U-Boot-Bannermeldung: Sie enthält Version, Build-Datum und Board-Identifikation.

Schritt 1.3: U-Boot-Environment komplett dokumentieren

=> printenv

Kopiere die gesamte Ausgabe. Besonders wichtig sind:

• bootcmd — Die Standard-Boot-Sequenz
• bootargs — Kernel-Parameter (zeigt Root-Partition, Console-Device)
• ethaddr, eth1addr — MAC-Adressen (für spätere Konfiguration sichern!)
• baudrate — Bestätigung der Serial-Geschwindigkeit
• mtdparts — Flash-Partitionslayout (falls gesetzt)
• fdtfile oder fdt_file — Device-Tree-Dateiname (zeigt welchen DTS Sophos verwendet)

Schritt 1.4: Board-Informationen auslesen

=> bdinfo

Liefert: DRAM-Größe und -Adressen, Boot-Device, Relocation-Adresse, etc.

=> version

U-Boot-Version und Compiler-Informationen.

Schritt 1.5: Flash-Layout dokumentieren

QSPI-NOR (2 MB):

=> sf probe
=> sf probe 0:0

Zeigt den NOR-Flash-Chip und seine Größe.

NAND (128 MB):

=> nand info
=> nand device

Zeigt den NAND-Flash-Chip, Seitengröße und Blockgröße.

MTD-Partitionen (falls konfiguriert):

=> mtdparts

Falls mtdparts nicht gesetzt ist, suche in bootcmd oder bootargs nach Partitions-Hinweisen.

Schritt 1.6: Original-Firmware sichern

Dies ist der wichtigste Schritt. Ohne ein Backup der Original-Firmware gibt es keinen Weg zurück.

QSPI-NOR Backup (2 MB = 0x200000 Bytes):

=> sf probe 0:0
=> sf read 0x96000000 0x0 0x200000

Das liest den gesamten NOR-Flash in den RAM an Adresse 0x96000000. Nun muss der Inhalt auf den PC übertragen werden. Optionen:

Option A — über TFTP (schnell, aber braucht funktionierendes Netzwerk im U-Boot):

=> setenv ipaddr 192.168.1.1
=> setenv serverip 192.168.1.2
=> tftpput 0x96000000 0x200000 nor-backup.bin

Option B — über Serial-Dump (langsam, aber funktioniert immer):

=> md.b 0x96000000 0x200000

Die Hex-Ausgabe über Serial mitschneiden und später mit einem Script in eine Binärdatei konvertieren. Bei 2 MB dauert das über Serial mehrere Minuten.

NAND Backup (128 MB = 0x8000000 Bytes):

=> nand read 0x96000000 0x0 0x8000000

Hinweis: 128 MB in den RAM lesen funktioniert nur, wenn genug RAM verfügbar ist (512 MB vorhanden, also machbar). Übertragung per TFTP bevorzugt.

Schritt 1.7: Netzwerk-Hardware identifizieren

Aus dem U-Boot heraus:

=> mii info
=> mii dump 0
=> mii dump 1

Zeigt die angeschlossenen Ethernet-PHYs und deren Adressen. Für den Switch-Chip:

=> mii device

Falls U-Boot einen MDIO-Bus zeigt, notiere alle PHY-Adressen. Dies ist entscheidend für den Device Tree.

Schritt 1.8: Von der Sophos-Firmware booten und analysieren

Falls du die Original-Firmware noch starten kannst (was du zu diesem Zeitpunkt solltest), lass sie booten und untersuche das laufende System über die Serial-Konsole:

# Im laufenden Sophos-Linux (falls Shell-Zugang möglich):
cat /proc/cpuinfo
cat /proc/mtd
cat /proc/device-tree/model
cat /proc/device-tree/compatible
ls /proc/device-tree/
dmesg | head -100
dmesg | grep -i pfe
dmesg | grep -i switch
dmesg | grep -i phy
dmesg | grep -i mdio
dmesg | grep -i gpio
dmesg | grep -i led
dmesg | grep -i watchdog
dmesg | grep -i pci
ip link show
ifconfig -a
lspci
lsusb
cat /sys/class/net/*/address

Falls kein Shell-Zugang im laufenden System möglich ist: Nicht schlimm — die GPL-Quellen enthalten den Device Tree und die Kernel-Konfiguration.

Phase 2: GPL-Quellen analysieren

Schritt 2.1: Quellen herunterladen und entpacken

mkdir -p ~/sdred20-project && cd ~/sdred20-project

# Sophos GPL-Quellen herunterladen (ca. 891 MB)
wget https://download.sophos.com/network/RED/GPL_source/opensource_gpl_sd_red.tar.gz

# Entpacken
tar xzf opensource_gpl_sd_red.tar.gz

Schritt 2.2: Device Tree finden

# Nach LS1012A Device Tree Sourcen suchen
find . -name "*.dts" -o -name "*.dtsi" | xargs grep -l "ls1012a" 2>/dev/null

# Nach Sophos/RED-spezifischen Anpassungen suchen
find . -name "*.dts" -o -name "*.dtsi" | xargs grep -l -i "red\|sophos" 2>/dev/null

# Allgemeine Board-Definitionen
find . -name "*.dts" | head -20

Der Device Tree Source (DTS) ist das wichtigste Artefakt in den GPL-Quellen. Er beschreibt exakt welche Hardware an welchen Adressen hängt: Switch-Chip, PHYs, GPIOs für LEDs, Reset-Button, Watchdog, PCIe-Slot — alles.

Schritt 2.3: Kernel-Konfiguration extrahieren

# Kernel .config oder defconfig finden
find . -name ".config" -o -name "*defconfig*" | xargs grep -l "LS1012A\|LAYERSCAPE" 2>/dev/null

# Aktivierte Treiber identifizieren
grep -E "^CONFIG_(PFE|DSA|NET_SWITCHDEV|PHYLIB|MDIO)" /pfad/zur/.config

Schritt 2.4: PFE-Firmware und Switch-Treiber identifizieren

# PFE-Firmware-Blob suchen
find . -name "pfe*" -o -name "*.itb" | head -20

# Switch-Chip-Treiber in der Kernel-Config
grep -i "SWITCH\|DSA\|MARVELL\|REALTEK\|MEDIATEK" /pfad/zur/.config

Phase 3: OpenWRT Custom-Build vorbereiten

Schritt 3.1: OpenWRT-Quellcode klonen

cd ~/sdred20-project

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt

# Stabilen Release-Branch verwenden
git checkout v24.10.4

# Feeds aktualisieren
./scripts/feeds update -a
./scripts/feeds install -a

Schritt 3.2: Bestehendes LS1012A-Target verstehen

Bevor du ein neues Device hinzufügst, studiere die bestehenden LS1012A-Definitionen:

# Image-Build-Definition
cat target/linux/layerscape/image/armv8_64b.mk

# Kernel-Patches
ls target/linux/layerscape/patches-*

# Device Tree Sourcen
ls target/linux/layerscape/files/arch/arm64/boot/dts/freescale/fsl-ls1012a*

# PFE-Firmware-Paket
cat package/firmware/layerscape/ls-pfe/Makefile

# U-Boot-Konfiguration
cat package/boot/uboot-layerscape/Makefile

Schritt 3.3: Neues Device-Profil anlegen

Basierend auf den Erkenntnissen aus Phase 1 und 2 erstellst du:

a) Device Tree Source: fsl-ls1012a-sdred20.dts

Dieser wird abgeleitet vom nächstliegenden Referenzboard (vermutlich fsl-ls1012a-rdb.dts) und angepasst mit den Informationen aus den Sophos GPL-Quellen. Mindestens benötigt:

• Ethernet-PHY-Adressen und Switch-Chip-Konfiguration
• Flash-Partitionslayout (QSPI-NOR + NAND)
• GPIO-Definitionen für LEDs (System, Router, Internet, Tunnel)
• USB-Controller-Konfiguration
• PCIe/Expansion-Bay-Konfiguration
• Watchdog-Konfiguration

b) Image-Build-Definition in armv8_64b.mk:

define Device/sophos_sd-red-20
  $(Device/fix-sysupgrade)
  DEVICE_VENDOR := Sophos
  DEVICE_MODEL := SD-RED 20
  DEVICE_PACKAGES += \
    layerscape-ppfe \
    kmod-ppfe
  # Flash-Layout muss an SD-RED 20 angepasst werden
  IMAGE/firmware.bin := \
    ls-clean | \
    ls-append $(1)-bl2.pbl | pad-to 1M | \
    ls-append $(1)-fip.bin | pad-to 5M | \
    ls-append $(1)-uboot-env.bin | pad-to 10M | \
    ls-append pfe.itb | pad-to 15M | \
    ls-append-dtb $$(DEVICE_DTS) | pad-to 16M | \
    append-kernel | pad-to $$(BLOCKSIZE) | \
    append-rootfs | pad-rootfs | check-size
endef
TARGET_DEVICES += sophos_sd-red-20

Hinweis: Das obige ist ein Ausgangspunkt, der auf dem existierenden LS1012A-RDB-Profil basiert. Das Flash-Layout muss zwingend an die reale Partitionstabelle des SD-RED 20 angepasst werden (Erkenntnis aus Phase 1, Schritt 1.5).

Schritt 3.4: Initramfs-Image bauen

Für den ersten Test im RAM — ohne den Flash zu überschreiben:

make menuconfig
# Navigiere zu:
# Target System → NXP Layerscape
# Subtarget → ARMv8 64b (64 bit)
# Target Profile → Sophos SD-RED 20 (oder alternativ
#   NXP LS1012A-RDB als Ausgangspunkt für erste Tests)
# Target Images → [*] ramdisk (aktivieren für initramfs)

make -j$(nproc)

Das erzeugt unter bin/targets/layerscape/armv8_64b/ ein initramfs-Image.

Phase 4: RAM-Boot und Hardware-Verifikation

Schritt 4.1: TFTP vorbereiten

# Initramfs-Image in TFTP-Verzeichnis kopieren
cp bin/targets/layerscape/armv8_64b/openwrt-*-initramfs*.itb /srv/tftp/

# PC-Netzwerk konfigurieren (statische IP)
sudo ip addr add 192.168.1.2/24 dev eth0
sudo ip link set eth0 up

Schritt 4.2: U-Boot-Netzwerk konfigurieren und Image laden

Verbinde ein Ethernet-Kabel direkt vom PC zu einem LAN-Port des SD-RED 20. In der U-Boot-Konsole:

=> setenv ipaddr 192.168.1.1
=> setenv serverip 192.168.1.2
=> saveenv
=> ping 192.168.1.2

Falls der Ping fehlschlägt: Firewall auf dem PC deaktivieren, Kabel prüfen, anderen LAN-Port versuchen. Bei LS1012A-Boards muss möglicherweise zuerst die PFE initialisiert werden:

=> pfe start
=> ping 192.168.1.2

Image laden und booten:

=> tftpboot 0x96000000 openwrt-layerscape-armv8_64b-...-initramfs.itb
=> bootm 0x96000000

Wichtig: Die Load-Adresse 0x96000000 ist der OpenWRT-Standard für Layerscape-Boards. Die Adresse 0x82000000, die in einigen Anleitungen kursiert, ist für andere ARM-Plattformen und funktioniert hier möglicherweise nicht. Prüfe im Zweifelsfall mit printenv den Wert von loadaddr oder kernel_addr_r.

Schritt 4.3: Hardware im laufenden OpenWRT verifizieren

Falls das System bootet (auch wenn nicht alle Ports funktionieren), verbinde dich über die Serial-Konsole und dokumentiere:

# System-Identifikation
cat /proc/device-tree/model
cat /proc/cpuinfo
uname -a

# Netzwerk-Hardware
ip link show
dmesg | grep -i pfe
dmesg | grep -i switch
dmesg | grep -i phy
dmesg | grep -i mdio
cat /sys/class/net/*/address

# Flash-Partitionen
cat /proc/mtd

# PCIe (Expansion Bay)
lspci 2>/dev/null

# USB
lsusb

# GPIOs und LEDs
ls /sys/class/leds/ 2>/dev/null
ls /sys/class/gpio/ 2>/dev/null
cat /sys/kernel/debug/gpio 2>/dev/null

# Watchdog
dmesg | grep -i watchdog
ls /dev/watchdog* 2>/dev/null

# Vollständiger dmesg-Log
dmesg > /tmp/openwrt-dmesg.txt

Was hier passieren kann:

• Netzwerk funktioniert nicht → PFE-Firmware fehlt oder Switch-Chip nicht erkannt. Prüfe dmesg auf Fehlermeldungen.
• System bootet nicht → Device Tree passt nicht zur Hardware. Fehlermeldungen im Serial-Log analysieren.
• System bootet, aber startet nach Sekunden neu → Hardware-Watchdog nicht bedient. In den Kernel-Parametern nowatchdog hinzufügen als Test.

Phase 5: Iteratives Debugging und Anpassung

Dieser Abschnitt beschreibt keine feste Anleitung, sondern den realistischen Entwicklungsprozess. Jeder SD-RED-20-Port wird hier anders verlaufen.

Device Tree anpassen

Basierend auf den Erkenntnissen aus Phase 4 wird der Device Tree iterativ angepasst:

# DTS editieren
vim target/linux/layerscape/files/arch/arm64/boot/dts/freescale/fsl-ls1012a-sdred20.dts

# Nur den DTS neu kompilieren (schneller als voller Build)
make target/linux/compile -j$(nproc)

# Neues initramfs bauen
make -j$(nproc)

# Via TFTP laden und testen — Zyklus wiederholen

Typische Iterationsschritte

1. Ethernet zum Laufen bringen — PFE-Firmware laden, PHY-Adressen im DTS korrigieren
2. Switch-Chip konfigurieren — DSA-Treiber aktivieren, VLAN-fähige LAN-Ports
3. WAN-Port und SFP — Separater PHY, Combo-Port-Logik
4. USB 3.0 — Controller im DTS aktivieren
5. LEDs — GPIO-Mapping für die vier Status-LEDs
6. Expansion Bay — PCIe-Konfiguration für Wi-Fi/3G/4G-Module
7. Watchdog — Korrekt bedienen oder kontrolliert deaktivieren

Phase 6: Dauerhaft flashen

Erst wenn Phase 4 und 5 abgeschlossen sind und das System stabil im RAM läuft, wird geflasht.

Sysupgrade-Image bauen

make menuconfig
# Target Images → [*] squashfs (aktivieren)
# Ramdisk kann jetzt deaktiviert werden
make -j$(nproc)

Flash-Vorgang

Der genaue Ablauf hängt vom Flash-Layout ab (Erkenntnis aus Phase 1). Generisch für LS1012A mit QSPI-NOR:

# Im U-Boot:
=> tftpboot 0x96000000 openwrt-...-firmware.bin
=> sf probe 0:0
=> sf erase 0 +$filesize
=> sf write 0x96000000 0 $filesize
=> reset

Warnung: Dieser Schritt überschreibt die Original-Firmware unwiderruflich (außer du hast ein Backup aus Phase 1, Schritt 1.6). Prüfe dreimal, dass du das richtige Image und die richtige Adresse verwendest.

Boot-Konfiguration anpassen

Nach erfolgreichem Flash muss U-Boot wissen, wie es OpenWRT starten soll:

=> setenv bootcmd 'sf probe 0:0; sf read 0x96000000 0x100000 0x...;  bootm 0x96000000'
=> saveenv

Die genauen Offsets und Größen ergeben sich aus dem Image-Layout.

Häufige Probleme und Lösungen

Kein U-Boot-Zugriff

• Falsches oder defektes Micro-USB-Kabel
• USB-Serial-Treiber nicht geladen (dmesg prüfen)
• Falsche Baudrate (115200 ist Standard, aber prüfe auch 9600 und 38400)
• Sophos hat möglicherweise den Autoboot-Interrupt deaktiviert oder ein Passwort gesetzt

TFTP schlägt fehl

• Firewall auf dem PC deaktivieren: sudo iptables -F
• Kabel direkt verbinden (kein Switch dazwischen)
• PFE im U-Boot starten: pfe start (LS1012A-spezifisch)
• IP-Konfiguration prüfen: printenv ipaddr und printenv serverip

Kein Netzwerk nach dem Boot

• PFE-Firmware-Blob (pfe.itb) fehlt im Image
• kmod-ppfe nicht installiert
• PHY-Adressen im Device Tree falsch
• Switch-Chip-Treiber nicht aktiviert

System startet nach Sekunden neu

• Hardware-Watchdog wird nicht bedient
• Kernel-Parameter nowatchdog hinzufügen als Diagnose
• Langfristig: Watchdog-Treiber korrekt konfigurieren

Gerät ist gebrickt

Solange U-Boot im QSPI-NOR intakt ist, kannst du über Serial-Konsole + TFTP immer ein neues Image laden. Ein echter Brick entsteht nur, wenn U-Boot selbst überschrieben wird. Deshalb gilt: Niemals den U-Boot-Bereich im NOR-Flash überschreiben, es sei denn, du weißt exakt was du tust und hast einen JTAG-Zugang als Backup.

Quellen und weiterführende Links

Offizielle Dokumentation

• Sophos GPL-Quellen: opensource_gpl_sd_red.tar.gz auf https://www.sophos.com/en-us/support/downloads/firewall-installers
• Sophos SD-RED 20 Operating Instructions: https://docs.sophos.com/nsg/hardware/operatinginstructions/red/sophos-operating-instructions-sd-red-20-60.pdf
• Sophos SD-RED 20 Quick Start Guide: https://docs.sophos.com/nsg/hardware/quickstart/red/sophos-quick-start-guide-sd-red-20.pdf

OpenWRT

• OpenWRT Layerscape Target README: https://github.com/openwrt/openwrt/blob/master/target/linux/layerscape/README
• OpenWRT LS1012A-FRWY Techdata: https://openwrt.org/toh/hwdata/nxp/nxp_frwy-ls1012a
• OpenWRT Layerscape Image-Build: https://github.com/openwrt/openwrt/blob/master/target/linux/layerscape/image/armv8_64b.mk

NXP

• NXP LS1012A Produktseite: https://www.nxp.com/products/LS1012A
• NXP LS1012A Broadband Home Router ASK: https://www.nxp.com/support/support/nxp-engineering-services/gateway-ask/layerscape-1012a-broadband-home-router-application-solutions-kit:QORIQ-LS1012A-BHR-ASK
• NXP Layerscape SDK: https://www.nxp.com/design/software/embedded-software/linux-software-and-development-tools/layerscape-software-development-kit:LAYERSCAPE-SDK

Community-Threads

• OpenWRT Forum: "Want to install OpenWrt on Sophos SD-RED 20" — https://forum.openwrt.org/t/want-to-install-openwrt-on-sophos-sd-red-20/95218
• Sophos Community: "Sophos RED 50 Recovery / Unbrick Tutorial" — https://community.sophos.com/utm-firewall/f/german-forum/130599/sophos-red-50-recovery-unbrick-tutorial
• OpenWRT HOWTO für Sophos RED 15w: https://forum.openwrt.org/t/howto-installing-openwrt-on-sophos-red-15w/177928

Projektstand und Mitmachen

Dieses Projekt befindet sich in Phase 1 (Hardware-Reconnaissance). Wir suchen Mitwirkende, die einen SD-RED 20 besitzen und bereit sind, die Serial-Konsole anzuschließen und Boot-Logs zu teilen.

Was wir als Nächstes brauchen

1. Vollständige U-Boot-Boot-Logs von mindestens einem SD-RED 20
2. printenv-Dump aus U-Boot
3. Flash-Partitionslayout (mtdparts, cat /proc/mtd)
4. dmesg-Log der Original-Sophos-Firmware
5. Device Tree Source aus den GPL-Quellen (Analyse von opensource_gpl_sd_red.tar.gz)

Wenn du diese Daten beisteuern kannst, poste sie im OpenWRT-Forum unter dem Tag layerscape oder eröffne einen neuen Thread mit dem Titel "Sophos SD-RED 20 — OpenWRT Device Port". Jeder Beitrag bringt das Projekt näher an ein funktionierendes Image.

Haftungsausschluss: Dieser Artikel basiert auf öffentlich verfügbaren technischen Daten, offiziellen Sophos-Dokumentationen, OpenWRT-Quellcode und NXP-Referenzmaterial. Das Flashen alternativer Firmware geschieht auf eigenes Risiko. Die Herstellergarantie erlischt. Keine Haftung für Schäden an Hardware oder Datenverlust.

Lizenz: Dieser Artikel steht unter CC BY-SA 4.0. Teilen und Anpassen ist ausdrücklich erwünscht — mit Namensnennung und unter gleichen Bedingungen.

Namasté. 🙏