Recovered Night Owl DVR-BTD2-8-V2 Boot Loop Using UART and Targeted ROMFS Repair

[vhalas]

Summary: I recovered a Night Owl DVR-BTD2-8-V2 that entered a boot loop after an apparently incomplete firmware update. The processor, RAM, NAND, Ethernet, HDMI, and U-Boot were still operational, but the ROMFS SquashFS partition was truncated.

After making complete NAND backups, I restored only the damaged ROMFS partition using a verified official firmware image. The DVR subsequently booted normally, connected to the network, completed an online firmware update, and returned to normal operation.

Device Information​

Component	Identification
Model	Night Owl DVR-BTD2-8-V2
Mainboard	AHB8008RA-NB-N68C-OWL V1.01, dated 20200629
SoC	Novatek NA51068
Memory	512 MiB DRAM
NAND	Winbond W25N01GV, 128 MiB SPI NAND
Original firmware found in flash	1.4.0
Final firmware after recovery	DVR-BTD2-8-V2_1.5.7

​

Mainboard AHB8008RA-NB-N68C-OWL V1.01, showing the CN1 UART header, NAND, HDMI, SATA connector, and video-decoder hardware.

Original Symptoms​

The DVR had worked recently and had performed firmware updates, but afterward it would no longer operate normally.

• No Night Owl interface
• No usable HDMI output
• No DHCP lease or visible network client
• Ethernet PHY lights remained active
• Blue Bluetooth indicator remained illuminated
• Removing the HDD made no difference
• Two known-good official 12 V power adapters made no difference
• CMOS battery removal and normal power resets did not help

From the outside, the DVR looked like it had suffered a failed mainboard, SoC, or other major hardware failure.

UART Connection​

The board has a three-pin UART header marked CN1:


CN1 UART header used for recovery. The board labels RX, TX, and GND directly beside the header.

• RX — Receive
• TX — Transmit
• GND — Ground

I used a CP2102 USB-to-TTL adapter.

Serial Settings​

Baud rate	115200
Data bits	8
Parity	None
Stop bits	1
Flow control	None

Wiring​

CP2102 Adapter	DVR CN1 Header
TXD	RX
RXD	TX
GND	GND
VCC / Red wire	Do not connect

Important: Do not connect adapter VCC.

The red wire on my adapter supplied 5 V and remained taped off. Only TX, RX, and GND were connected.

The U-Boot autoboot delay was zero seconds, but sending Ctrl+C through the UART console could still interrupt boot.

What the UART Log Revealed​

The board was not dead. U-Boot successfully initialized:

• CPU
• 512 MiB DRAM
• SPI NAND
• USB
• Ethernet
• HDMI
• Boot-logo partition

The failure occurred when U-Boot attempted to extract boot/uImage from the ROMFS SquashFS partition.

The repeated errors included:

Input is not in the XZ format (wrong magic bytes)
xz uncompress failed with error code 5
read_block: failed to read block
prefetch abort
data abort

The DVR would then reset and repeat the process.

The damaged ROMFS partition produced the same CRC32 every time: 52dcfded.

That showed the failure was deterministic rather than random UART noise, unstable RAM, or an intermittent NAND read.

Root Cause​

Offline examination showed that the ROMFS SquashFS filesystem was incomplete.

The meaningful programmed data stopped at a NAND-page boundary, leaving approximately 130 KB of required filesystem metadata missing.

The missing portion included critical:

• Inode tables
• Directory tables
• Fragment tables
• Lookup tables
• ID tables

The embedded Linux kernel itself was still valid:

Image	Linux-4.9.118
Payload size	2,572,896 bytes
Load address	0x00008000
Entry point	0x00008000

Both the U-Boot image-header CRC and kernel payload CRC were valid.

The evidence strongly suggested that an interrupted or incomplete firmware update had left the ROMFS partition truncated.

Spoiler: NAND partition layout

0x0000000  loader
0x0040000  fdt
0x0080000  fdt.restore
0x00C0000  boot
0x02C0000  env
0x0340000  priv
0x03A0000  rsvd
0x0400000  logo
0x0500000  romfs, size 0xA00000
0x0F00000  usr
0x4000000  work
0x7800000  mtd

The failure was isolated to the ROMFS partition beginning at 0x500000.

Backups Made Before Repair​

Before writing anything, I created and verified:

• A complete 128 MiB logical NAND backup
• A complete raw NAND backup including OOB data
• A separate backup of the damaged ROMFS partition
• SHA-256 hashes for the backup files

This was important because the NAND contains device-specific information, including:

• Serial information
• TUTK/cloud identifiers
• Private configuration
• Network identity
• Vendor-specific partitions

No bad NAND blocks were reported.

I will not publish the full NAND dumps because they contain private device identifiers and cloud credentials.

Verified Recovery Image​

I obtained the correct official firmware package for the BTD2 hardware family and verified that it matched the device.

Hardware family	AHB80N08R-LME-ND
Flash ID	EF AA 21
Image filename	romfs-x.squashfs.img
File size	3,448,896 bytes
Full-image CRC32	ee7904ce
ROMFS payload CRC32	0981230b

The file contained:

• A 64-byte firmware/update header
• A 0x34A000-byte ROMFS payload

USB and RAM Verification​

The image was placed on a FAT32 USB drive and loaded into RAM:

fatload usb 0:1 0x02000000 romfs-x.squashfs.img

The complete file was verified:

crc32 0x02000000 0x34A040

Expected CRC32: ee7904ce

Because the actual ROMFS payload begins 64 bytes into the file, I also verified:

crc32 0x02000040 0x34A000

Expected CRC32: 0981230b

Important flwrite Note​

The U-Boot environment contained update aliases that referenced flwrite, but running flwrite by itself did not process the image already loaded at 0x02000000.

It returned:

PACK_ID error
DestAddr invalid

No NAND erase or write occurred.

I verified afterward that:

• The RAM image CRC was unchanged
• The original damaged ROMFS CRC was unchanged

Do not assume that standalone flwrite will automatically process an image already loaded into RAM on this U-Boot build.

Targeted ROMFS Repair​

WARNING:

The following offsets and lengths applied to this exact DVR model, board revision, flash layout, and verified firmware image.

Using these commands on another model, hardware revision, or unverified image could permanently destroy the device.

Make complete NAND backups before writing anything.

I first verified the source payload CRC one final time:

crc32 0x02000040 0x34A000

Expected CRC32: 0981230b

I then erased only the damaged ROMFS partition:

nand erase 0x500000 0xA00000

The 64-byte firmware header was skipped, and only the verified ROMFS payload was written:

nand write 0x02000040 0x500000 0x34A000

The write completed successfully:

3448832 bytes written: OK

The written data was then read back and verified:

nand read 0x04000000 0x500000 0x34A000
crc32 0x04000000 0x34A000

Readback CRC32: 0981230b

The readback CRC exactly matched the verified source payload.

First Boot After Repair​

The repaired ROMFS was read successfully, and U-Boot found and extracted boot/uImage:

### get_squashfs_file OK
loaded 2572960 bytes to 0x1D600000

The kernel passed validation:

Image Name: Linux-4.9.118
Verifying Checksum ... OK
Loading Kernel Image ... OK

Linux then started:

Uncompressing Linux... done, booting the kernel.
abce

UART output stopped after abce, but HDMI came up and the normal Night Owl camera grid appeared.

Final Result​

The DVR successfully completed:

• Manual boot after the repair
• Complete cold boot
• HDMI initialization
• Linux startup
• Ethernet initialization
• DHCP and network connectivity
• Automatic online firmware update
• Automatic reboot after the firmware update

Final reported information:

Model	DVR-BTD2-8-V2
Firmware	DVR-BTD2-8-V2_1.5.7
Firmware status	Up to date

The normal camera grid returned after the firmware update, and Ethernet showed a solid link light with active traffic.

Conclusion​

This unit did not have a failed CPU, RAM, HDMI circuit, Ethernet interface, or completely failed NAND chip.

The problem was an incomplete ROMFS SquashFS partition, most likely caused by an interrupted or failed firmware update.

The DVR was recovered by:

• Accessing U-Boot through UART
• Backing up the complete NAND before writing
• Preserving all device-specific partitions
• Verifying the correct official firmware image
• Skipping the firmware-update header
• Rewriting only the damaged ROMFS partition
• Verifying the write by CRC before rebooting

The DVR was restored without erasing its identity, cloud credentials, private configuration, or other working partitions.

Files Retained Privately​

• NAND128.BIN
• NAND128-RAW.BIN
• ROMFS.BIN
• SHA256-HASHES.txt
• Original official firmware package
• Extracted verified ROMFS image

I will not post device-specific NAND dumps because they contain private identifiers and cloud credentials.

I would be interested to hear from anyone with the same board revision, or another BTD2 model, that has experienced the same firmware-update boot loop.