(SOLVED) - hi3516d chipset missing /etc/init.d/rcs - UART/TTY connected

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
I have a hisilicon hi3516d. It seems to suffer from a missing file. I believe i rm -rf it on accident lol.

i have thousands of cameras identical with root shell access, firmwares, and tty access. I am trying to learn to restore it from the hisilicon uboot and tftp.


Code:
baudrate=115200
ethaddr=00:00:23:34:45:66
bootfile="uImage"
filesize=B2AED8
fileaddr=82000000
netmask=255.255.255.0
configFlag=ok
cpuFlag=ok
cpuType=3516a
sensorFlag=no
sensorType=57
ipaddr=192.168.0.66
serverip=192.168.0.58
bootargs=mem=128M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=jffs2 mtdparts=hi_sfc:3M(boot),13M(rootfs)
bootcmd=sf probe 0;sf read 0x82000000 0x80000 0x280000;bootm 0x82000000
bootdelay=8
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06 (Aug 26 2015 - 13:52:10)
mdio_intf=rmii
hisicpu=hi3516d

Environment size: 549/262140 bytes

Code:
U-Boot 2010.06 (Aug 26 2015 - 13:52:10)

NAND:  Check nand flash controller v610. found
Special NAND id table Version 1.36
Nand ID: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
No NAND device found!!!
0 MiB
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
16384 KiB hi_sfc 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:    2138968 Bytes = 2 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@roadjun) (gcc version 4.8.3 20131202 (prerelease) (Hisilicon_v300) ) #43 Thu Jan 28 17:51:04 CST 2016
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: hi3516a
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: mem=128M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=jffs2 mtdparts=hi_sfc:3M(boot),13M(rootfs)
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 124340k/124340k available, 6732k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc0503000   (5100 kB)
      .init : 0xc0503000 - 0xc0526094   ( 141 kB)
      .data : 0xc0528000 - 0xc0557360   ( 189 kB)
       .bss : 0xc0557384 - 0xc056e4d0   (  93 kB)
SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:128
sched_clock: 32 bits at 49MHz, resolution 20ns, wraps every 86767ms
Console: colour dummy device 80x30
Calibrating delay loop... 1196.85 BogoMIPS (lpj=5984256)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys freezer
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x803e11b8 - 0x803e1210
dummy:
NET: Registered protocol family 16
Serial: AMBA PL011 UART driver
uart:0: ttyAMA0 at MMIO 0x20080000 (irq = 40) is a PL011 rev2
console [ttyAMA0] enabled
uart:1: ttyAMA1 at MMIO 0x20090000 (irq = 41) is a PL011 rev2
uart:2: ttyAMA2 at MMIO 0x200a0000 (irq = 42) is a PL011 rev2
bio: create slab <bio-0> at 0
SCSI subsystem initialized
hi-spi-master hi-spi-master.0: with 1 chip select slaves attached
hi-spi-master hi-spi-master.1: with 3 chip select slaves attached
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
cfg80211: Calling CRDA to update world regulatory domain
Switching to clocksource timer0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
NFS: Registering the id_resolver key type
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
fuse init (API version 7.18)
msgmni has been set to 242
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
io scheduler cfq registered
brd: module loaded
Spi id table Version 1.22
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
SPI nor flash boot mode is 3 Bytes
Spi(cs1):
Block:64KB
Chip:16MB
Name:"MX25L128XX"
spi size: 16MB
chip num: 1
2 cmdlinepart partitions found on MTD device hi_sfc
2 cmdlinepart partitions found on MTD device hi_sfc
Creating 2 MTD partitions on "hi_sfc":
0x000000000000-0x000000300000 : "boot"
0x000000300000-0x000001000000 : "rootfs"
Higmac dma_sg_phy: 0x87a00000
higmac_mdio_bus: probed
ETH0: rmii, phy_addr=1, mii_name=mdio0
usbcore: registered new interface driver zd1201
usbcore: registered new interface driver rt2800usb
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
hiusb-ehci hiusb-ehci.0: HIUSB EHCI
hiusb-ehci hiusb-ehci.0: new USB bus registered, assigned bus number 1
hiusb-ehci hiusb-ehci.0: irq 53, io mem 0x100b0000
hiusb-ehci hiusb-ehci.0: USB 0.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
hiusb-ohci hiusb-ohci.0: HIUSB OHCI
hiusb-ohci hiusb-ohci.0: new USB bus registered, assigned bus number 2
hiusb-ohci hiusb-ohci.0: irq 54, io mem 0x100a0000
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 1 port detected
usbcore: registered new interface driver cdc_wdm
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mousedev: PS/2 mouse device common for all mice
i2c /dev entries driver
hisi_i2c hisi_i2c.0: Hisilicon [i2c-0] probed!
hisi_i2c hisi_i2c.1: Hisilicon [i2c-1] probed!
hisi_i2c hisi_i2c.2: Hisilicon [i2c-2] probed!
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP: cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
lib80211: common routines for IEEE802.11 drivers
Registering the dns_resolver key type
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
VFS: Mounted root (jffs2 filesystem) on device 31:1.
Freeing init memory: 140K
can't run '/etc/init.d/rcS': No such file or directory
getty: can't open '/dev/null': No such file or directory
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
Also have the available commands

Code:
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
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
ddr     - ddr training function
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)
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
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,962
Reaction score
6,794
Location
Scotland
Well done for getting there.
This is intended to be helpful - not a criticism :
I pulled this from an existing working camera.
Just a thought - as you've cloned the entire flash memory, you will also have copied the MAC address, which will give networking problems if both donor and clone are on the same network.
You might be lucky and the MAC address may be defined in the bootloader environment variables - I haven't looked - in which case you can readily alter it.
If not, it will be in a configuration file probably in the root file system, again could be altered, but would need root access, might be fiddly depending on the file system.

Also - for future reference - I'd strongly hold back from flashing the bootloader, as it's obviously working OK.
To flash the bootloader using the bootloader is a bit risky - it's a bit like pulling the rug from under your feet trying to swap in another one.
If it goes wrong the board would need a re-flash at the chip hardware level.
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
I was not sure on what exactly I was copying. I do not have the original files including the bootloader. The firmware update files I have just update the html pages/onvif parts of the device. I should have stated, we have these cameras manufactured for us and they provide most of everything we need, including root username and password. Its just easier to fix a problem that can be solved then to ship it back overseas. I am a newb by all means. I am surprised I got that far, first time and all with UART.

I did not know where the FS was at within the hex/firmware dump. If that is the correct terminology.

But I have the tool from the factory that allows me to change the MAC and all sorts of other stuff.

mac.PNG
Well done for getting there.
This is intended to be helpful - not a criticism :

Just a thought - as you've cloned the entire flash memory, you will also have copied the MAC address, which will give networking problems if both donor and clone are on the same network.
You might be lucky and the MAC address may be defined in the bootloader environment variables - I haven't looked - in which case you can readily alter it.
If not, it will be in a configuration file probably in the root file system, again could be altered, but would need root access, might be fiddly depending on the file system.

Also - for future reference - I'd strongly hold back from flashing the bootloader, as it's obviously working OK.
To flash the bootloader using the bootloader is a bit risky - it's a bit like pulling the rug from under your feet trying to swap in another one.
If it goes wrong the board would need a re-flash at the chip hardware level.
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
I do have a question if you have time.

How would I find out the hex offset/address if I wanted to just copy the filesystem from the bootloader?

sf read 0x82000000 0x0 0x1000000
0000000000000000 (^Where do these numbers come into play)

The dump I took from the working camera was imported into HxD and just seems to be all garbled.

That's really handy, no problem then with a duplicate MAC address.
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,962
Reaction score
6,794
Location
Scotland
How would I find out the hex offset/address if I wanted to just copy the filesystem from the bootloader?
Your serial console transcript has that info, in 2 places :
Code:
Kernel command line: mem=128M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=jffs2 mtdparts=hi_sfc:3M(boot),13M(rootfs)
Code:
Name:"MX25L128XX"
spi size: 16MB
chip num: 1
2 cmdlinepart partitions found on MTD device hi_sfc
2 cmdlinepart partitions found on MTD device hi_sfc
Creating 2 MTD partitions on "hi_sfc":
0x000000000000-0x000000300000 : "boot"
0x000000300000-0x000001000000 : "rootfs"
sf read 0x82000000 0x0 0x1000000
0000000000000000 (^Where do these numbers come into play)
"Serial flash read to RAM starting at address 0x82000000 from flash offset 0x0 for 0x1000000 bytes"
0x1000000 is 16MB, the entire flash memory.
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
Your serial console transcript has that info, in 2 places :
Code:
Kernel command line: mem=128M console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=jffs2 mtdparts=hi_sfc:3M(boot),13M(rootfs)
Code:
Name:"MX25L128XX"
spi size: 16MB
chip num: 1
2 cmdlinepart partitions found on MTD device hi_sfc
2 cmdlinepart partitions found on MTD device hi_sfc
Creating 2 MTD partitions on "hi_sfc":
0x000000000000-0x000000300000 : "boot"
0x000000300000-0x000001000000 : "rootfs"

"Serial flash read to RAM starting at address 0x82000000 from flash offset 0x0 for 0x1000000 bytes"
0x1000000 is 16MB, the entire flash memory.
I guess I could have just done,

sf read 0x82000000 0x300000 0x1000000

and that would have just been the filesystem?

Was confusing at first but looking back I am beginning to understand more.
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
I guess I could have just done,

sf read 0x82000000 0x300000 0x1000000

and that would have just been the filesystem?

Was confusing at first but looking back I am beginning to understand more.
I think I got it lol

1 MB = 1 Megabyte = 1024 * 1 KB = 1,048,576 bytes

Using a decimal to hex converter we get

0010 0000 = 1,048,576

So

1,048,576 * 16 = 16,777,216

then converted it is

0100 0000 = 16,777,216


I was confused on where the it came from in the beginning lol
 

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,962
Reaction score
6,794
Location
Scotland
I guess I could have just done,

sf read 0x82000000 0x300000 0x1000000

and that would have just been the filesystem?
Not quite correct.
You'd run off the end of the flash.

Unusual though that the device only has 2 partitions.
Usually there are separate ones at least for the app files, and the configuration files.
 

hsstech

n3wb
Joined
May 19, 2020
Messages
9
Reaction score
4
Location
USA
You'd run off the end of the flash.
What do you mean by this?


Is this not the correct formula?

second_add - first_add + 1

0100 0000 - 0030 0000 + 1 = 00d0 0001 ?

16777216 - 3145728 + 1 = 13631489 ?


Unusual though that the device only has 2 partitions.
Usually there are separate ones at least for the app files, and the configuration files.
Yeah not sure why it is. But here is filesystem with everything it has.

Capture.PNG
 
Last edited:

alastairstevenson

Staff member
Joined
Oct 28, 2014
Messages
15,962
Reaction score
6,794
Location
Scotland
What do you mean by this?
What I almost missed in your candidate command line -
0x000000000000-0x000000300000 : "boot"
0x000000300000-0x000001000000 : "rootfs"
The above are the 'from - to' offset values.
So the number of bytes to read when starting from the end of the bootloader/start of the rootfs partition boundary is
0x1000000 - 0x300000 which is 0xd00000 or 13,631,488 in decimal or 13MB.
 
Top