Help with UART/TFTP flashing rebranded TVT DVR

[coopser]

I have an HA-9216 DVR which I believe is rebranded TVT that is hanging on boot.

I've found firmware for it online that has 3 files krn3531a, rfs3531a, ubt3531a. The instructions say to place it at the root of a fat32 usb and turn the device on and this will flash the firmware, but that doesn't work.

I connected to UART port on the board and it seems that the system doesn't recognize the files on the usb to flash. Interestingly enough it looks like the kernel is booting but errors with a permission denied for the boot.sh. The login prompt afterward does not accept my actual username and password or any of the default ones I could find like admin 123456.

I'm ready to completely flash this from scratch with the available files from tftp if someone could help me with that.

Here is the log of it finding the usb device and not flashing those images.

1 Storage Device(s) found

usb_stor_scan number = 1

no check usb update device

[info]Uboot can not find any valid image to update!

Hit any key to stop autoboot:  0

And here's where boot.sh gets a permission denied error and the login doesn't work with my credentials

[RCS]: /etc/init.d/S00devs

[RCS]: /etc/init.d/S01udev

[RCS]: /etc/init.d/S80network

[RCS]: /etc/init.d/S99user

yaffs: dev is 32505859 name is "mtdblock3" rw

yaffs: passed flags ""

/etc/init.d/S99user: line 18: /mnt/mtd/boot.sh: Permission denied

scsi 3:0:0:0: Direct-Access     SanDisk  Cruzer Glide     1.27 PQ: 0 ANSI: 6

sd 3:0:0:0: [sda] 30529536 512-byte logical blocks: (15.6 GB/14.5 GiB)

sd 3:0:0:0: [sda] Write Protect is off

sd 3:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

 sda: sda1

sd 3:0:0:0: [sda] Attached SCSI removable disk



(none) login:

 

[coopser]

Well I managed to fix it by adding "single init=/bin/sh" to the bootargs environmental variables to get a shell. Then I reset the root password with the passwd cmd and changed the permissions of /mnt/mtd/boot.sh with chmod to make it executable again. Not sure where or why this nasty little bug came about but hopefully that helps anyone else who might experience this issue.

I still would love to hear opinions about why the initial 3 files wouldn't flash from usb and learn the process of converting those files into some tftp bootable img just to help me learn more about uboot and embedded linux, but for now the problem is solved.

 

[alastairstevenson]

why the initial 3 files wouldn't flash from usb

Did they come zipped / did you unzip them?
I've seen, admittedly not often, a device that prefers it's firmware files still in the original zipped form.

Grepping the firmware files (maybe just the ubt* one) for any references to the prefix of their filenames might yield a file name required clue.

 

[coopser]

They came in a flash .rar and the instructions specifically said to unpack them and put them on the root of a usb. After that there is a separate .tar update that's supposed to be left packed and updated through the gui after first boot. I pulled the firmware from here: Support > Firmware AHD DVR 9200 Series [Engine by iGetWeb.com] which appears to be a legit local vendor page despite the shoddy website design and lack of ssl/tls in 2024.

The weird part is the files from the flash.rar don't have any extension at all like .bin .img .iso etc they are just files. Opened them in a hex editor and they clearly are binaries though. Looking through the ubt file I see all the names mentioned without extensions in it (krn3531a, rfs3531a, ubt3531a). The ubt flash file has a different bootargs mem value than my current printenv does (MEM=64M vs my current MEM=344M)

I'm just wondering if I did want to flash is there a way to do it over usb or tftp over uboot console? Would I have to recalculate all the nand address offsets because it's a different size than the current one? Also is there a way to dump all the current settings and not touch the bootloader at all just to make sure I don't brick anything? I'm very green with this embedded arm linux stuff.

 

[alastairstevenson]

The weird part is the files from the flash.rar don't have any extension at all like .bin .img .iso etc they are just files.

These are the Linux kernel, the root file system, and u-boot in uImage format. They are not encoded, but can have compressed contents.
If you use something like 'file *a' you'll get some detail.
For firmware updating these will be directly written to the start of each relevant flash partition which will be size defined to be larger than the file sizes.

Despite that there will be loads of mismatched detail, it can be instructive to use the binwalk utility to get an idea of the contents, and potentially extract some parts of interest.
Or even write an unpack script, though that's a bigger topic.

I'm very green with this embedded arm linux stuff.

Well, you do seem to have jumped down the rabbit hole with some speed!

 

[alastairstevenson]

I still would love to hear opinions about why the initial 3 files wouldn't flash from usb and learn the process of converting those files into some tftp bootable img just to help me learn more about uboot and embedded linux, but for now the problem is solved.

Too risky at this point in the learning curve, but I suspect the 3 files could be manually directly written to their relevant flash partitions to achieve the update.
I don't recommend that you do this ... but for info :

At the root shell that you managed to get -
cat /proc/mtd
to show the flash partitions.
And check out the contents of the init scripts with potential references to updates starting
ls -alr /etc/init.d
and use 'cat' to show their contents such as
cat /etc/init.d/rcS

 

[coopser]

Just wanted to reach out and say thank you again. After having some more time to sit down with it I think I've learned more about linux in the past couple weeks than I have in 20 years of using it. Your comments on other threads here too were seriously very insightful as someone just starting out trying to understand the bootloaders on these devices.