Updating NVR Firmware in Busybox Shell (flashcp)

[jr218]

I have a QCAM NVR which stopped working after a failed firmware update. I was able to hook up the serial port and get into uboot. However, most of the recovery procedures out there for writing the SPI flash are not working. The primary issue is that that issuing "sf probe" fails:

sf probe 0
Check spi flash controller v350... Found
Can't find a valid spi flash chip.
Can't find a valid spi flash chip.
Failed to initialize SPI flash at 0:0

The same problem happens if I try probing other busses and chip selects.

I did observe however, that Linux will boot all the way up just fine, and thus I have access to the full Linux environment, so I'm thinking that rather than trying to update the flash in uboot, I would try to do it from Linux.

Poking around I noticed in /mnt/app I noticed an "update" executable. This would seem to be the same one that the NVR GUI must call, however when I run it (regardless of the file) I get:

# ./update image.bin
invalid updatingimg.

So then I noticed the BusyBox tools. In particular:

# ./busybox flashcp
BusyBox v1.16.1 (2014-02-27 20:08:01 HKT) multi-call binary.

Usage: flashcp -v FILE MTD_DEVICE

Copy an image to MTD device

Options:
-v Verbose

I’m wondering if I could use this utility to update the flash? Is this possible? If so, how do I know which MTD_DEVICE?

Thanks

 

[alastairstevenson]

# ./update image.bin
invalid updatingimg.

That's telling you that the file you're trying to update with is not valid.

But what's the actual problem?
u-boot is working, uImage (kernel) is booting OK.
So presumably it's the app folders/data that's wrong.
Potentially, given a suitable firmware file, this could be fixed up via the root shell access that you have.
Have you managed to source any valid firmware for the camera?

I have a QCAM NVR which stopped working after a failed firmware update.

What needs done to fix it will depend on what the actual problem is.
Which should be reasonably evident by inspection of the serial console after power on.
What errors do you see?

If so, how do I know which MTD_DEVICE?

To see the flash partitions, use cat /proc/mtd
To see what's mounted and in use and what type of file system, use mount
To see if there is a space issue (maybe due to wrong firmware) use df -h

I’m wondering if I could use this utility to update the flash?

Probably - but generally it's possible to write directly to the flash partition block device with cat or dd.

 

[jr218]

Thanks for the reply, unfortunately, I got a little to eager this morning and used the flashcp command to update the NVR with the correct flash image. Unfortunately, I think I selected the wrong MTD device and wiped out uboot in the process. Now when I power on the NVR, I get just blank characters printing to the screen. I wish I'd seen your message above before I did this, I think inspection of the bootlog and surgically fixing the problem would have been the better option. I assume now I'm probably done, short of pulling the flash off the board and replacing it?

 

[alastairstevenson]

update the NVR with the correct flash image.

It's unusual to get a flash image - it's usually firmware that's distributed.
Do you have a link to the file that you used?

I selected the wrong MTD device

Which one did you target?

I think inspection of the bootlog and surgically fixing the problem would have been the better option.

Too late now, but definitely.

I assume now I'm probably done, short of pulling the flash off the board and replacing it?

It's sometimes possible to program SPI flash in-situ - while still on the board, with a flash programmer and 'test clip'.
But of course you'd need something valid to flash it with.

 

[jr218]

It was the firmware. Got it from Amcrests website (.pak file). MTD4 which I think was the whole flash. At this point it's probably easiest to just scrap the NVR and replace it. Lesson learned...

 

[alastairstevenson]

It was the firmware. Got it from Amcrests website (.pak file).

I don't have an account on that site. And won't be registering.

MTD4 which I think was the whole flash.

That's just one flash partition, and won't be the one u-boot resides in.
So a bit odd that u-boot has been impacted.

*edit*
But a registration isn't required for firmware downloads.
Looking at the products - all the NVRs have .bin files, and the DVRs have .pak files.
I might take a look at one out of curiosity.