Interchangeability of flash memory; XT25F128B replaced with W25Q128FV

Lucky G.

Lucky G.

n3wb
Nov 1, 2020
10
7
Slovakia
Hi all,
I have a chinese IP Camera (PN BRIP5AF) with Hi3516EV300 + SONY IMX335 on board marked as 85H50AI. I think these are common cameras.
One day the camera stopped working, I found out the data on flash is corrupt and the system cannot boot. I tried reflashing it via U-Boot, but turns out the memory chip was damaged (verification errors, very slow write...). The original chip was XT25F128B, I couldn't find any source for this so I replaced it with Winbond's W25Q128FV. I flashed U-Boot into it, soldered it on board and flashed the firmware via TFTP. But the camera always hangs after loading the kernel:

Code: 
System startup

Uncompress Ok!

U-Boot 2016.11-g2fc5f58-dirty (Sep 06 2019 - 15:28:14 +0800)hi3516ev300

Relocation Offset is: 0771b000
Relocating to 47f1b000, new gd at 47edaef0, sp at 47edaed0
SPI Nor:  eFlashType: 3.
Flash Name: XM_W25Q128FV, W25Q128JV{0xEF4018), 0x1000000.
@hifmc_spi_nor_probe(), XmSpiNor_ProtMgr_probe(): OK.
@XmSpiNor_enableQuadMode(), Disable Quad Failed, SRx: [2, 0x2].
CONFIG_CLOSE_SPI_8PIN_4IO = y.
read->iftype[0: STD, 1: DUAL, 2: DIO, 3: QUAD, 4: QIO]: 1.
Current level[0], lock_level_max:7.
unlock all.
SRx val: {[1, 0x20], [1, 0x2], [1, 0x80], [0, 0x0]}.
In:    serial
Out:   serial
Err:   serial
Net:   eth0
Hit ctrl+c to stop autoboot:  0
@do_spi_flash_probe() flash->erase_size:65536
device 0 offset 0x40000, size 0x550000

SF: 5570560 bytes @ 0x40000 Read: OK
srcAddr 0x43000000, dstAddr 0x42000000
created_inode 0x47edb800
find_squashfs_file: name bin, start_block 0, offset 2001, type 1
find_squashfs_file: name boot, start_block 0, offset 2197, type 1
read inode: name boot, sb 0, of 2197, type 1
find_squashfs_file: name uImage, start_block 0, offset 2033, type 2
read inode: name uImage, sb 0, of 2033, type 2
write_file: regular file, blocks 33
len 2117248
### FS load complete: 2117248 bytes loaded to 0x42000000
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux-4.9.37
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2117184 Bytes = 2 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Loading Kernel Image ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

I tried many firmware files marked as follows: General_IPC_HI3516EV300_85H50AI.Nat.dss.OnvifS.HIK_V5.00.R02.20200102_all.bin, with different release dates, but the result is the same.
I successfully flashed the OpenIPC firmware, it was working. I take it as a proof that the hardware is OK. I wouldn't mind keeping the OpenIPC, but I can't figure out how to set the automatic night mode - the correct combination of GPIOs for switching the IR LEDs and IRcut filter. I tried all the combinations from OpenIPC wiki, it just doesn't work for me. Also the image parameters setting in OpenIPC is just basic compared to stock FW.
I've done this procedure a couple of times with different IP cameras (hi3516ev100 etc.) with success (although the flash chip wasn't changed or the same type was used).
Does anyone know if the exchange of SPI flash for different type can cause this issue and if so, is there a way how to make it work with W25Q128?
Or any other idea how to make this work again?
 
Lucky G. said:
Hi all,
I have a chinese IP Camera (PN BRIP5AF) with Hi3516EV300 + SONY IMX335 on board marked as 85H50AI. I think these are common cameras.
One day the camera stopped working, I found out the data on flash is corrupt and the system cannot boot. I tried reflashing it via U-Boot, but turns out the memory chip was damaged (verification errors, very slow write...). The original chip was XT25F128B, I couldn't find any source for this so I replaced it with Winbond's W25Q128FV. I flashed U-Boot into it, soldered it on board and flashed the firmware via TFTP. But the camera always hangs after loading the kernel:

Code: 
System startup

Uncompress Ok!

U-Boot 2016.11-g2fc5f58-dirty (Sep 06 2019 - 15:28:14 +0800)hi3516ev300

Relocation Offset is: 0771b000
Relocating to 47f1b000, new gd at 47edaef0, sp at 47edaed0
SPI Nor:  eFlashType: 3.
Flash Name: XM_W25Q128FV, W25Q128JV{0xEF4018), 0x1000000.
@hifmc_spi_nor_probe(), XmSpiNor_ProtMgr_probe(): OK.
@XmSpiNor_enableQuadMode(), Disable Quad Failed, SRx: [2, 0x2].
CONFIG_CLOSE_SPI_8PIN_4IO = y.
read->iftype[0: STD, 1: DUAL, 2: DIO, 3: QUAD, 4: QIO]: 1.
Current level[0], lock_level_max:7.
unlock all.
SRx val: {[1, 0x20], [1, 0x2], [1, 0x80], [0, 0x0]}.
In:    serial
Out:   serial
Err:   serial
Net:   eth0
Hit ctrl+c to stop autoboot:  0
@do_spi_flash_probe() flash->erase_size:65536
device 0 offset 0x40000, size 0x550000

SF: 5570560 bytes @ 0x40000 Read: OK
srcAddr 0x43000000, dstAddr 0x42000000
created_inode 0x47edb800
find_squashfs_file: name bin, start_block 0, offset 2001, type 1
find_squashfs_file: name boot, start_block 0, offset 2197, type 1
read inode: name boot, sb 0, of 2197, type 1
find_squashfs_file: name uImage, start_block 0, offset 2033, type 2
read inode: name uImage, sb 0, of 2033, type 2
write_file: regular file, blocks 33
len 2117248
### FS load complete: 2117248 bytes loaded to 0x42000000
## Booting kernel from Legacy Image at 42000000 ...
   Image Name:   Linux-4.9.37
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2117184 Bytes = 2 MiB
   Load Address: 40008000
   Entry Point:  40008000
   Loading Kernel Image ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

I tried many firmware files marked as follows: General_IPC_HI3516EV300_85H50AI.Nat.dss.OnvifS.HIK_V5.00.R02.20200102_all.bin, with different release dates, but the result is the same.
I successfully flashed the OpenIPC firmware, it was working. I take it as a proof that the hardware is OK. I wouldn't mind keeping the OpenIPC, but I can't figure out how to set the automatic night mode - the correct combination of GPIOs for switching the IR LEDs and IRcut filter. I tried all the combinations from OpenIPC wiki, it just doesn't work for me. Also the image parameters setting in OpenIPC is just basic compared to stock FW.
I've done this procedure a couple of times with different IP cameras (hi3516ev100 etc.) with success (although the flash chip wasn't changed or the same type was used).
Does anyone know if the exchange of SPI flash for different type can cause this issue and if so, is there a way how to make it work with W25Q128?
Or any other idea how to make this work again?
Click to expand...
Uh oh, I probably found the mistake, the board is actually IVG-85HG50PYA-S. I'm going to try to find a suitable firmware and try it.
EDIT: So no, the manufacturer's product site links to the same FW I've used. I'm out of ideas.
 
I have an answer to my own question:
Lucky G. said:
Does anyone know if the exchange of SPI flash for different type can cause this issue?
Click to expand...
In this case - NO.
After I tried at least 5 different firmware files, I gave up and disassembled another IP camera with the same board and same flash (XT25F128B), dumped the whole 16MB of flash content and flashed it into "broken" camera with W25WQ128FV. It immediately worked.
Btw. the dumping of SPI flash was quite a task, since the U-Boot in the working camera didn't have any TFTP command available to upload file to TFTP server. It has only TFTPBOOT, which works only for download. So I had to use the md.b command and convert the log from my serial console to BIN file. It took a couple of hours over 115200 baud. You can probably find a lot of tutorials how to do it, but here's the short tutorial of how I did it, just in case if anyone needs to get the content of SPI FLASH out of camera and doesn't have the TFTP command:

1. load the content of SPI FLASH into RAM:
For 128Mb (16MB) chips:
Code: 
mw.b 0x42000000 ff 0x1000000; sf probe 0; sf read 0x42000000 0x0 0x1000000
For 64Mb (8MB) chips:
Code: 
mw.b 0x42000000 ff 0x800000; sf probe 0; sf read 0x42000000 0x0 0x800000

2. turn on logging in your serial console. I use Putty:
Putty logging.png

3. display the loaded content in RAM - it will take A LOT of time:
Code: 
md.b 0x42000000 0x1000000

4. Open the logfile in a text editor (Notepad++), delete the unwanted lines at the beginning, so the first line will be the actual data:
Code: 
42000000: 15 05 00 ea fe ff ff ea fe ff ff ea fe ff ff ea    ................
Save the file.

5. Now comes the tricky part. I quickly wrote an PHP script for converting the dumped text file with HEX values into pure binary file:

Code: 
<?PHP
$file_name = "20220811_hi3516ev300.log";

$file = fopen($file_name,"r");
$bin_file_name = realpath(dirname(__FILE__)) . "/" . substr($file_name, 0, -4) . '.bin';
$bin_file = fopen($bin_file_name, 'wb');

$line_counter = 0;
$binary_counter = 0;

while ($line = fgets($file)) {
    $line = trim($line);
    $line = substr($line, 10, 47);    /* get only the hex bytes */
  
    $i = 0;
    while ($i < 16) {
        fwrite($bin_file, pack("C*", hexdec(substr($line, $i * 3, 2))));
        $binary_counter++;
        $i++;
    }
    $line_counter++;
}
fclose($file);
fclose($bin_file);

echo $line_counter . "\r\n";
echo $binary_counter;
?>

6. OPTIONAL:
I just wanted to be sure, that the data retrieved over serial port is consistent and no errors/data loss occured during slow transfer, I repeated the above procedure one more time with different file names and compared the to BIN files (Linux command line):
Code: 
cmp -l 20220810_hi3516ev300.bin 20220811_hi3516ev300.bin
In my case the two files were identical so I was confident to use it for flashing.
 
  • Like
Reactions: tangent and alastairstevenson
Lucky G. said:
So I had to use the md.b command and convert the log from my serial console to BIN file.
Click to expand...
I did the same a few years back - takes a while, but it worked.

As the camera is now cloned, it will likely have the same MAC address as the donor.
Will you be using them both on the same LAN?
May be worth seeing if the MAC address is defined in a bootloader environment variable.
 
  • Like
Reactions: tangent
alastairstevenson said:
I did the same a few years back - takes a while, but it worked.

As the camera is now cloned, it will likely have the same MAC address as the donor.
Will you be using them both on the same LAN?
May be worth seeing if the MAC address is defined in a bootloader environment variable.
Click to expand...
You're right. The MAC address is defined in env variable (ethaddr), but changing has effect only while in U-Boot, after starting the main system it gets overwritten. I cannot figure out, where else it's saved. I suspected the MTD partition, I tried to wipe it, no help. It still gets the MAC from the donor.

When I change the ethaddr in U-Bot, I get this warning:

Code: 
Warning: eth0 MAC addresses don't match:
Address in SROM is         00:12:31:71:xx:xx
Address in environment is  00:12:31:5a:xx:xx

00:12:31:5a:xx:xx is the donor's addres, 00:12:31:71:xx:xx is the desired address.

This is the flash partition list:

Code: 
start       end      size
0x000000 - 0x040000 0x040000(boot),
0x040000 - 0x580000 0x540000(romfs),
0x580000 - 0xCC0000 0x740000(user),
0xCC0000 - 0xE40000 0x180000(web),
0xE40000 - 0xEC0000 0x080000(custom),
0xEC0000 - 0xFFFFFF 0x140000(mtd)

On 0x30000 I can see the U-Boot Env variables.

After a couple of hours:

Clearing the Boot ENV and MTD partition at the same time doesn't help, it still gets the "wrong" mac address on reboot from somewhere. It's probably saved in romfs and on kernel start it rewrites the "wrong" value into boot env and into mtd.

OK, I managed to change the MAC address. I wiped the Boot-env, MTD and romfs partitions, reflashed the romfs, forced the ethaddr into bootargs and it worked.
But then I found out the camera doesn't output any RTSP stream! In WEB UI settings in "Encode" I can select only H264 and D1 resolution for channel 1 and CIF for channel 2. I repeated the entire procedure; when running the cloned firmware, everything works (H265 @ 5M), but the MAC address is wrong.

I even have a backup from the original FLASH, when it stopped booting, but it was after I changed the bootloader for the one from OpenIPC and because it's larger and stores the ENV variables at 0x40000 instead of 0x30000, it wiped the part of romfs partition (0x40000 - 0x50000). I tried flashing the remaining "good" part of FLASH backup into the cloned FLASH, but it didn't help, still only H264@D1.

I don't know what else I should try.
 
Lucky G. said:
OK, I managed to change the MAC address. I wiped the Boot-env, MTD and romfs partitions, reflashed the romfs, forced the ethaddr into bootargs and it worked.
Click to expand...
Sometimes there is a whole stack of camera-specific settings held in configuration files in the romfs.
Not all of them may be accessible from the camera web GUI.
Presumably the romfs is held in a single dedicated partition.
If you want to zip it and and attach, we could do a search for it.
 
alastairstevenson said:
Sometimes there is a whole stack of camera-specific settings held in configuration files in the romfs.
Not all of them may be accessible from the camera web GUI.
Presumably the romfs is held in a single dedicated partition.
If you want to zip it and and attach, we could do a search for it.
Click to expand...
Thank you. Meanwhile I moved forward a bit. After a lot of trials/errors I found out, that the critical part is the data located in the last 1024 bytes of U-Boot partition. If I erase the whole U-Boot partition and write a new (or the same) bootloader, it lets me to change the MAC address in U-Boot and that change persist. But the missing 1kB of data contains some sort of signature or parameters without which the camera refuses to stream the video, or maybe it can't detect the sensor, I don't know. Once I put the data back, the streaming works again, but the bootloader rewrites the MAC address.
I'd like to stress that this data IS NOT U-Boot Environment, that's stored on another partition (on address 0x30000).
So the extended map of SPI FLASH looks like this:

Code: 
start       end      size
0x000000 - 0x02A6E6 0x02A6E6(boot),
0x02FC00 - 0x030000 0x000400 (THE MAGIC DATA)
0x030000 - 0x03FFFF 0x010000 (u-boot.env)
0x040000 - 0x580000 0x540000(romfs),
0x580000 - 0xCC0000 0x740000(user),
0xCC0000 - 0xE40000 0x180000(web),
0xE40000 - 0xEC0000 0x080000(custom),
0xEC0000 - 0xFFFFFF 0x140000(mtd)

The format of these 1024 bytes is unknown to me, the values don't make any sense, the MAC address (if it's there) is somehow encoded or encrypted, therefore I'm unable to edit the data.
So if you or anyone knows what this data is, how can I change it or make a new one, I would be very happy. The data is attached.
Thanks a lot!
 

Attachments

  • Like
Reactions: alastairstevenson
alastairstevenson said:
Yes, I agree. Some sort of coding scheme. Not practical to second-guess it though.
Click to expand...

I found that the Ipctool from OpenIPC project detects this data as "xmcrypto", so as I thought it seems to be some vendor specific encrypted data.
At this point I give up, I already spent too much time with this. I am going to try OpenIPC for one last time and if the IRcut still doesn't work, I will swap the camera with cloned MAC for another one that's in different network.
But at least I learned how important is to backup all the data before meddling with firmware.
 
  • Like
Reactions: alastairstevenson
You must log in or register to reply here.
Top Bottom