Missing "run" command on hisilicon U-Boot 2010.6

Paul Kuhn

n3wb
Apr 26, 2018
18
0
Hey Folks,

searched lots of threads but did not find an answer yet...

have two bricked IPCAMs from ieGeek 1080p which I try to update via UART Interface:

System startup


U-Boot 2010.06 (Nov 27 2017 - 16:15:12)

Check Flash Memory Controller v100 ... Found
SPI Nor(cs 0) ID: 0xc8 0x40 0x18
Block:64KB Chip:16MB Name:"GD25Q128"
SPI Nor total size: 16MB
Cannot found a valid SPI Nand Device
MMC:
EMMC/MMC/SD controller initialization.
Card did not respond to voltage select!
No EMMC/MMC/SD device found !
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
hisilicon #
hisilicon # help
? - alias for 'help'
base - print or set address offset
bootm - boot application image from memory
bootp - boot image via network using BOOTP/TFTP protocol
bootss - boot from snapshot image
cmp - memory compare
cp - memory copy
crc32 - checksum calculation
ddr - ddr training function
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls - list files in a directory (default /)
getinfo - print hardware information
go - start application at address 'addr'
help - print command description/usage
loadb - load binary file over serial line (kermit mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
md - memory display
mii - MII utility commands
mm - memory modify (auto-incrementing address)
mmc - MMC sub system
mmcinfo - mmcinfo <dev num>-- display MMC info
mtest - simple RAM read/write test
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nm - memory modify (constant address)
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
saveenv - save environment variables to persistent storage
setenv - set environment variables
sf - SPI flash sub-system
tftp - tftp - download or upload image via network using TFTP protocol
usb - USB sub-system
usbboot - boot from USB device
version - print monitor version


...found some articles that show a way via "run up" - but this command seems to be missing here?!

--> run = run commands in an environment variable

Thank you in advance for a hint :)

Regards,
Paule
 
--> run = run commands in an environment variable
All this does is to gather together all the commands you would otherwise do manually.
So there is nothing lost apart from convenience.
But I'm assuming that what would be in the 'up' definition is known.
For writing the flash memory the tftp and sf commands would be used.

What do you see if you allow u-boot to continue without interruption?
 
hisilicon # printenv
bootdelay=1
baudrate=115200
ethaddr=00:00:23:34:45:66
netmask=255.255.255.0
bootfile="uImage"
phyaddru=0
phyaddrd=1
bootcmd=sf probe 0;sf read 0x82000000 0x60000 0x170000;bootm 0x82000000
bootargs=mem=43M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:384K(boot),1472K(kernel),14528K(rootfs)
serverip=192.168.100.101
ipaddr=192.168.100.144
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Nov 27 2017 - 16:15:12)

Environment size: 467/65532 bytes
 
ah, I am sorry WITHOUT interruption you mean:

jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00570010: 0xe728 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00570014: 0xeba7 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00570018: 0x24f7 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0057001c: 0x4b54 instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00570020: 0xf84e instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00570024: 0x3ebe instead
jffs2: Further such events for this erase block will not be printed
jffs2: Old JFFS2 bitmask found at 0x0057d9b8
jffs2: You cannot use older JFFS2 filesystems with newer kernels
VFS: Mounted root (jffs2 filesystem) on device 31:2.
Freeing init memory: 100K
/bin/sh: can’t load library ‚libm.so.0‘
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00001000
 
Last edited:
what I did meanwhile: tried to upload a renamed Firmware.bin via TFTP as uImage

sf probe0
sf erase 0x3e0000 0xa00000
tftp uImage
sf write 0x80008000 0x3e0000 0x36ff18
reset

no luck :(

so: is it possible to get the needed mtdblocks splitted from Firmware.bin file?
 
Last edited:
so, this should be the layout for HI3518 IPCAM:

Flash memory partitions layout
Address (position) Name Size (KiB) MTD file
0x000000 Boot 1024 /dev/mtdblock0
0x100000 Kernel 2944 /dev/mtdblock1
0x3e0000 Rootfs 10112 /dev/mtdblock2
0xdc0000 Config 1280 /dev/mtdblock3
0xf00000 Key 64 /dev/mtdblock4


but do they match to this:

bootcmd=sf probe 0;sf read 0x82000000 0x60000 0x170000;bootm 0x82000000
bootargs=mem=43M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfstype=jffs2 mtdparts=hi_sfc:384K(boot),1472K(kernel),14528K(rootfs)[3~


could you please advise how to extract needed blocks from orig. firmware and write them back via "sf write" etc.?

meanwhile I compiled "binwalk" on MacOS by homebrew...
 
could you please advise how to extract needed blocks from orig. firmware
If the 'original firmware' is a flash image file? As opposed to firmware files?
In a Linux environment - dd is a powerful tool for splitting files.
Here is an example of original extracted flash partitions being concatenated such that they could be used with a flash programmer, then dd used to split out one specific section :
Code:
alastair@PC-I5 ~/tmp $ ll
total 16336
drwxr-xr-x  2 alastair alastair    12288 May 13 12:56 ./
drwxr-xr-x 82 alastair alastair     4096 May 13 12:32 ../
-rw-r--r--  1 alastair alastair    65536 Feb 12  2017 mtd0ro
-rw-r--r--  1 alastair alastair   196608 Feb 12  2017 mtd1ro
-rw-r--r--  1 alastair alastair    65536 Feb 12  2017 mtd2ro
-rw-r--r--  1 alastair alastair  1769472 Feb 12  2017 mtd3ro
-rw-r--r--  1 alastair alastair 14614528 Feb 12  2017 mtd4ro
alastair@PC-I5 ~/tmp $ cat mtd0ro mtd1ro mtd2ro mtd3ro mtd4ro > mtdall.bin
alastair@PC-I5 ~/tmp $ dd if=mtdall.bin of=mtd3 bs=1 count=1769472 skip=327680
1769472+0 records in
1769472+0 records out
1769472 bytes (1.8 MB, 1.7 MiB) copied, 2.73329 s, 647 kB/s
alastair@PC-I5 ~/tmp $ openssl md5 mtd3ro mtd3
MD5(mtd3ro)= beba0742e39eba6b26e44fcb752f39cc
MD5(mtd3)= beba0742e39eba6b26e44fcb752f39cc
alastair@PC-I5 ~/tmp $
write them back via "sf write" etc.
That's the risky bit.
You really would need to be sure where the relevant mtdblocks were located.
Does a bootup transcript show that the (or maybe 'a') kernel is intact? And that it's an app partition that's corrupt?
 
bootup sequence looks like this:

16384 KiB hi_fmc at 0:0 is now current device

## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.4.35
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1832528 Bytes = 1.7 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Linux version 3.4.35 (root@localhost.localdomain) (gcc version 4.8.3 20131202 (p rerelease) (Hisilicon_v300) ) #9 Tue May 17 15:56:51 HKT 2016
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: hi3518ev200
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 48768
Kernel command line: mem=192M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfst ype=jffs2 mtdparts=hi_sfc:384K(boot),1792K(kernel),14208K(rootfs)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 192MB = 192MB total
Memory: 189936k/189936k available, 6672k reserved, 0K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xcc800000 - 0xff000000 ( 808 MB)
lowmem : 0xc0000000 - 0xcc000000 ( 192 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc044a000 (4360 kB)
.init : 0xc044a000 - 0xc0465ea0 ( 112 kB)
.data : 0xc0466000 - 0xc0492280 ( 177 kB)
.bss : 0xc04922a4 - 0xc04c65c0 ( 209 kB)

btw: found some Youtube "run up" command procedure documentations; from where do this command get the needed mtdblock infos to restore the whole systen from frimware BIN file?
 
bootup sequence looks like this:
Well, that kernel looks intact.
What makes it crash out?
Do you believe it's the correct kernel for the camera, or is it a consequence of a failed firmware update?
I don't think you've said how the cameras were bricked.

By the way - check out the '+' code tags in the Edit menu - it makes reading transcripts so much easier.
from where do this command get the needed mtdblock infos
If you can get to a stable command shell, you can get the partition info using :

cat /proc/mtd
provided the environment is sufficiently initialised. Even if not - some additional commands can get it there.

To get to a command shell may be possible by modifying bootargs.
First, preserve the as-is u-boot environment variables.
Then try something like
setenv bootargs mem=43M console=ttyAMA0,115200 init=/bin/sh
saveenv

*edit* I just noticed that your bootup transcript has a different mem= value
That's pretty big for a camera.
"Kernel command line: mem=192M console=ttyAMA0,115200 root=/dev/mtdblock2 rootfst ype=jffs2 mtdparts=hi_sfc:384K(boot),1792K(kernel),14208K(rootfs)"

I'm assuming that root=/dev/mtdblock2 rootfstype=jffs2 is missing or invalid, so best omitted, but also try keeping it in.
 
First of all: thank you to help me on this bricked stuff!!

short review: my ieGeek 1080p was flashed with most current firmware v11.x from official ieGeek site (!) because motion detection was not as good as needed and after a reboot there is NO webinterface, even NO configuration can be done cause the IPCAM was DEAD indeed!

To get to a command shell may be possible by modifying bootargs.
First, preserve the as-is u-boot environment variables.
Then try something like
setenv bootargs mem=43M console=ttyAMA0,115200 init=/bin/sh
saveenv

result is:

VFS: Cannot open root device „(null)“ or unknown-block(0,0): error -6
Please append a correct „root=„ boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

modification:

Code:
U-Boot 2010.06 (Nov 27 2017 - 16:15:12)

Check Flash Memory Controller v100 … Found
SPI Nor(cs 0) ID: 0xc8 0x40 0x18
Block:64KB Chip:16MB Name:“GD25Q128“
SPI Nor total size: 16MB
Cannot found a valid SPI Nand Device
MMC:   
EMMC/MMC/SD controller initialization.
Card did not respond to voltage select!
No EMMC/MMC/SD device found !
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  1 0
hisilicon # <INTERRUPT>
hisilicon # <INTERRUPT>
hisilicon # printenv
bootdelay=1
baudrate=115200
ethaddr=00:00:23:34:45:66
bootfile=„uImage“
phyaddru=0
phyaddrd=1
bootcmd=sf probe 0;sf read 0x82000000 0x60000 0x170000;bootm 0x82000000
filesize=60CB0A
fileaddr=80008000
netmask=255.255.255.0
ipaddr=192.168.100.144
serverip=192.168.100.101
bootargs=mem=43M console=ttyAMA0,115200 init=/bin/sh
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Nov 27 2017 - 16:15:12)

Environment size: 417/65532 bytes
hisilicon #
 
Last edited:
okay... after a while I was so frustrated and decided to write "u-boot-200MHZ.bin" (from: Hi3518_SDK_V1.0.7.0) via "sf write 0x80008000 0 0x100000" to Flash - now the device is gone completly and not even booting anymore... :(
 
now the device is gone completly and not even booting anymore...
Oh dear, that's not good.

Not relevant now, but I was going to comment that the boot failure with the init=/bin/sh is a pity as it shows that the kernel does not have an in-built initramfs as a start point. A consequent shell access would have provided a foothold for some flash operations.

For any future similar activities - the bootloader u-boot was working OK, a kernel was working OK, what appeared to be missing or invalid was the rootfs data.

If you have the HiSilicon SDK, there is the 'fastboot' facility that should deal with a full erase flash state.
I have never used it though, so I can't comment on it's usefulness.
It does require that the board is built to enable that possibility.
 
  • Like
Reactions: Paul Kuhn
now... is there any chance to boot from prepared SDCARD in integrated slot?
No - it seems you've written over the bootloader.

I think there are only 2 options for you to consume more time on:
The 'fastboot' facility in the HiSilicon SDK.
If the camera has a 24 / 25 series SPI flash in an 8-pin DIP package - it just might be possible to program in-situ with a flash programmer, give a valid flash image of course.
 
oh my dear... lets say this is really "china crap" and I will invest time & money in a Hikvision IPCAM now...

Thank you very much again for your effort !!

BTW: and Yes -> it has a 24 / 25 series SPI flash in an 8-pin DIP package!

BUT: do I have to unsolder it? ist a SMD device and what flashing device do I need for that?
 
Last edited:
BUT: do I have to unsolder it? ist a SMD device and what flashing device do I need for that?
No guarantees that this would work for this camera - but I have successfully programmed an SOP8 DIP8 24/25 series 16MB SPI NOR flash chip with a CH341A programmer and an 8-pin test clip. Both of which cost almost nothing on Aliexpress. While it was still on the board.
But a full flash image would be needed for that.
 
me again - the tinkerer ;)

I'll give it a try: just ordered the CH341A programmer and the SOP8 clip at ALiExpress; will take some time to deliver

Question: does this eprom only contain the boot loader or the whole firmware?

got another working IPCAM with HI3516 and U-Boot running fine - flash programmer should able to read from that chip to copy over to bad eprom, isnt it?