[widgetii]

The second half of #225: the ROM fallback's Ethernet stage is now the NA51089 ROM's own DHCP and TFTP client, as read from the ROM dump and seen on an NT98562 on a real LAN.

ROM behaviour modelled:

• MAC 00:00:00:xx:xx:xx, new every boot.
• It takes only a broadcast offer and drops a unicast one.
• One TFTP request for loader.bin from port 2962, sent to the offering MAC.
• No timeout and no retransmission while it waits for data.
• The console letters match silicon's.

Emulator change: a small nvt-eqos hook lets the ROM drive the MAC before any loader runs.

Tests:

• defib burn --nic (novatek: recover over Ethernet, the ROM's own fallback, for boards with flash straps defib#170, novatek: SPI NOR controller and flash boot; the SDK firmware boots #171) runs unmodified over a tap. U-Boot from RAM answers at its prompt on nt98562 and nt98566.
• test-novatek-recovery.sh gains that third way in, and CI runs it with defib pinned to 74e1bcc.
• test-novatek.py checks the ROM's DHCP and TFTP behaviour over a UDP socket netdev, without root. All 802 checks pass.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Emulate Novatek mask ROM Ethernet recovery over DHCP and TFTP

✨ Enhancement 🧪 Tests 📝 Documentation 🕐 40+ Minutes

AI Description

• Model the mask ROM’s DHCP and TFTP boot so Ethernet recovery can load a first-stage loader.
• Let the ROM use nvt-eqos before handing the MAC back to the loader.
• Cover packet behavior and defib recovery in tests, CI, and documentation.

Diagram

graph TD
  ROM["ROM fallback"] --> MAC["nvt-eqos hook"] --> DISC["DHCP discover"] --> OFFER{"Broadcast offer?"} -->|yes| REQ["DHCP request"] --> TFTP["ARP and TFTP"] --> SRAM["SRAM loader"] --> HANDOFF["Loader handoff"]
  OFFER -->|no| DISC

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Drive EQOS registers and DMA rings from the ROM model

• ➕ Exercises the same MAC path used by the loader
• ➕ Could model lower-level ROM hardware behavior more closely
• ➖ Substantially expands the emulation surface
• ➖ Adds register and descriptor complexity to a boot-stage protocol model

Recommendation: Keep the temporary nvt-eqos hook: it models the observable network exchange while preserving the loader’s existing MAC path after handoff. Register-level MAC operation is worth considering only if recovery needs hardware-level fidelity.

Files changed (9) +543 / -31

Enhancement (4) +359 / -4

novatek.cConnect the machine’s MAC to the boot ROM +6/-0

Connect the machine’s MAC to the boot ROM

• Retains the nvt-eqos device reference and links it to the ROM when creating the ROM device.

qemu/hw/arm/novatek.c

nvt-bootrom.cImplement mask ROM DHCP and TFTP boot +305/-4

Implement mask ROM DHCP and TFTP boot

• Adds Ethernet frame construction and a DHCP-to-TFTP recovery sequence, including the ROM’s broadcast-offer behavior, console output, and SRAM loader transfer. Attaches the ROM to the MAC during Ethernet boot and detaches on timeout, reset, or loader handoff.

qemu/hw/arm/nvt-bootrom.c

nvt-eqos.cProvide temporary ROM access to the MAC +32/-0

Provide temporary ROM access to the MAC

• Routes received frames to the ROM callback instead of DMA rings while attached and lets the ROM transmit on the NIC queue. Flushes queued packets when attachment changes so a paused backend can resume receiving.

qemu/hw/net/nvt-eqos.c

nvt-bootrom.hDeclare ROM network state and MAC hook +16/-0

Declare ROM network state and MAC hook

• Adds the callback and send interfaces used by nvt-eqos, plus the ROM state needed to track DHCP and TFTP transfers.

qemu/include/hw/arm/nvt-bootrom.h

Documentation (2) +30 / -7

CLAUDE.mdDocument ROM Ethernet boot support +2/-2

Document ROM Ethernet boot support

• Updates the repository guidance to describe DHCP/TFTP through nvt-eqos and recovery with defib’s NIC mode.

CLAUDE.md

novatek.mdDescribe ROM network behavior and Ethernet recovery +28/-5

Describe ROM network behavior and Ethernet recovery

• Documents the ROM’s DHCP offer handling, TFTP transfer, console output, and behavior without a server. Adds a tap-based defib recovery example.

docs/novatek.md

Other (3) +154 / -20

ci.ymlRun Ethernet recovery with a pinned defib version +6/-4

Run Ethernet recovery with a pinned defib version

• Renames the recovery job to include Ethernet and pins a defib commit with NIC recovery support. The existing recovery script now exercises the additional path in CI.

.github/workflows/ci.yml

test-novatek-recovery.shExercise defib recovery over a tap device +37/-14

Exercise defib recovery over a tap device

• Adds Ethernet as a third recovery path alongside the two UART paths. Configures a tap device, runs defib in NIC mode, and checks that U-Boot answers at its prompt.

qemu-boot/test-novatek-recovery.sh

test-novatek.pyTest ROM Ethernet packets without a tap device +111/-2

Test ROM Ethernet packets without a tap device

• Adds a UDP socket-backed network test for DHCP offer selection, ARP and TFTP requests, waiting without retransmission, console output, and loader handoff. Extends the serial test helper to accept network arguments.

qemu/tests/test-novatek.py

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Recovery stalls with a separate TFTP server ✓ Resolved

Description

eth_dhcp() writes s->srv_ip into DHCPREQUEST option 54, although the offer parser sets that
value from the BOOTP next-server field whenever it is nonzero. If the next-server differs from the
DHCP server identified by the offer’s option 54, the request identifies the wrong DHCP server; a
server that rejects it leaves recovery retrying discovery instead of reaching TFTP.

---

2. Existing tap settings are left changed ✓ Resolved

Description

The Ethernet test path assigns 192.168.77.1/24 and brings $TAP up even when the interface
already existed, while cleanup() acts on it only when this invocation created it. Running the
default recovery test with a pre-existing nvt-rec0, or with a caller-supplied TAP, leaves that
interface’s address and link state modified after the test.

---

Tip of the day

💡 Did you know, you can commit Qodo's fix in one click with committable suggestions (GitHub & GitLab)

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗