14

I have a inexpensive Chinese IP-Camera that runs a linux (busybox, to be precise) off a 8-MB SPI flash IC.

I'm trying to get access to the device.

It has a hardware serial port, and I've gotten access to it, but the linux terminal appears to be disabled or simply turned off. Basically, I get the "loading linux kernel" message, and then the serial port becomes unresponsive.

Is there any way to retrieve the firmware image on a device using U-Boot?

U-Boot log:

U-Boot 2010.06-svn (Jun 16 2014 - 09:36:52)

DRAM:  256 MiB
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x17 0xC2 0x20 0x17
Spi(cs1): Block:64KB Chip:8MB Name:"MX25L6406E"
envcrc 0x5878e4b2
ENV_SIZE = 0xfffc
In:    serial
Out:   serial
Err:   serial
Press Ctrl+C to stop autoboot
CFG_BOOT_ADDR:0x58040000
8192 KiB hi_sfc at 0:0 is now current device

### boot load complete: 1884992 bytes loaded to 0x82000000
### SAVE TO 80008000 !
## Booting kernel from Legacy Image at 82000000 ...
   Image Name:   linux
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1884928 Bytes = 1.8 MiB
   Load Address: 80008000
   Entry Point:  80008000


load=0x80008000,_bss_end=80829580,image_end=801d4300,boot_sp=807c71d8
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

And the u-boot environment:

hisilicon # printenv
bootcmd=fload;bootm 0x82000000
baudrate=115200
bootfile="uImage"
da=mw.b 0x82000000 ff 1000000;tftp 0x82000000 u-boot.bin.img;sf probe 0;flwrite
du=mw.b 0x82000000 ff 1000000;tftp 0x82000000 user-x.cramfs.img;sf probe 0;flwrite
dr=mw.b 0x82000000 ff 1000000;tftp 0x82000000 romfs-x.cramfs.img;sf probe 0;flwrite
dw=mw.b 0x82000000 ff 1000000;tftp 0x82000000 web-x.cramfs.img;sf probe 0;flwrite
dc=mw.b 0x82000000 ff 1000000;tftp 0x82000000 custom-x.cramfs.img;sf probe 0;flwrite
up=mw.b 0x82000000 ff 1000000;tftp 0x82000000 update.img;sf probe 0;flwrite
ua=mw.b 0x82000000 ff 1000000;tftp 0x82000000 upall_verify.img;sf probe 0;flwrite
tk=mw.b 0x82000000 ff 1000000;tftp 0x82000000 uImage; bootm 0x82000000
dd=mw.b 0x82000000 ff 1000000;tftp 0x82000000 mtd-x.jffs2.img;sf probe 0;flwrite
ipaddr=192.168.1.10
serverip=192.168.1.107
netmask=255.255.255.0
ethaddr=00:12:12:4b:6b:b6
HWID=8043420004048425
ob_start=0
ob_data=7b
appSystemLanguage=SimpChinese
appVideoStandard=PAL
bootdelay=5
bootargs=mem=40M console=ttyAMA1,115200 console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=cramfs mtdparts=hi_sfc:256K(boot),3520K(romfs),2560K(user),1280K(web),256K(custom),320K(mtd)
stdin=serial
stdout=serial
stderr=serial
verify=n
ver=U-Boot 2010.06-svn (Jun 16 2014 - 09:36:52)

Environment size: 1272/65532 bytes

U-Boot help prompt (I think you can build u-boot with optional modules. This shows what's built into this instance of u-boot?):

hisilicon # help
?       - alias for 'help'
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
fload   - fload  - load binary file from a filesystem image for system boot

flwrite - SPI flash sub-system
getinfo - print hardware information
go      - start application at address 'addr'
help    - print command description/usage
lip     - lip      - set local ip address but not save to flash

loadb   - load binary file over serial line (kermit mode)
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
mac     - mac      - set mac address and save to flash

md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing address)
mtest   - simple RAM read/write test
mw      - memory write (fill)
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
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
sf      - SPI flash sub-system
sip     - sip      - set server ip address but not save to flash

tftp    - tftp  - download or upload image via network using TFTP protocol
version - print monitor version

Note that the consoles specified in the bootargs variable are from my experimentation. I've tried both ttyAMA0, ttyAMA1, tty0, and lots of other similar variables.

The processor is a HiSilicon Hi3518, which is a ARM SoC.

Right now, the only thing I can think of is to hot-air the flash IC off the board and dump it that way, but that's a lot of work, and I'd rather see if there is a software option first.

Improve this question
4
  • 3
    Desoldering is usually not necessary: digikey.com/product-detail/en/5250/501-1311-ND/745102
    – devttys0
    Sep 24, 2014 at 14:27
  • Author of this topic tell - you have this camera work? In reality, the Kernel is loaded, you can log in to the web interface of the camera?
    – user11964
    Mar 11, 2015 at 11:18
  • Any success on that business yet? :)
    – user12712
    Jun 6, 2015 at 21:11
  • I can confirm that user2177319's approach works. I extracted romfs for my IP camera here. What's not obvious to me is the location for the CGI scripts that serve the web / management interfaces over HTTP. I guess Linux must boot and then mount some more files from Flash?
    – user12917
    Jul 1, 2015 at 14:51

3 Answers 3

Reset to default
6

The way I did it on the Kindle was to load the flash partitions into memory and then using memory dump commands to dump them in hex format (and then some Python script to convert hex back to binary). It was kinda slow but did achieve the goal.

Your U-Boot does not seem to have the bbm command but fload - load binary file from a filesystem image for system boot and sf - SPI flash sub-system sounds promising, I'd suggest exploring them. You may also be able to use tftp to send the images over the network and not have to dump them using the console.

Improve this answer
6
  • I'd be ok with either, really. How do you determine where the flash partition even is?
    – Fake Name
    Sep 24, 2014 at 10:05
  • Ok, issuing a empty fload command appears to have loaded the kernel into RAM. ### boot load complete: 1884992 bytes loaded to 0x82000000, and the kernel is specified as 1884928 in the boot messages.
    – Fake Name
    Sep 24, 2014 at 10:11
  • And fload does not appear to accept parameters. No matter what I pass it, it just loads the kernel.
    – Fake Name
    Sep 24, 2014 at 10:20
  • What about sf?
    – Igor Skochinsky ♦
    Sep 24, 2014 at 10:26
  • AFICT, sf just mounts the SPI flash. The only verb I can find is sf probe, which seems to test for the presence of a device and/or make it available: hisilicon # sf probe 0 8192 KiB hi_sfc at 0:0 is now current device Unfortunately, there seems to be no help, so if it accepts other verbs, I don't know how to discover them.
    – Fake Name
    Sep 24, 2014 at 10:28
6

I use sf read and it works pretty good. It can be called as follows

sf read [addr] [offset] [len]

So for your case, reading romfs would look like this:

sf probe 0; sf read 0x82000000 0x40000 0x370000

Then you can transfer the file to tftp server:

tftp 0x82000000 romfs.cramfs 0x370000

You can also use sf to write to the SPI flash (more info can be found here).

Improve this answer
6
  • I am wondering, is this actually working? Which U-Boot version? tftp in u-boot is one way transfer to upload files into memory. If you mean Busybox, then which vers? Busybox tftp have no such command syntax.
    – Lexx Luxx
    Dec 8, 2017 at 15:12
  • It does! Version "U-Boot 2010.06 (Jan 05 2015 - 15:46:28)", I've just dumped 128M NAND flash from the device using this answer.
    – ogurets
    Nov 6, 2018 at 14:51
  • @triwo tftp u-boot command is bi-directional: if you specify an address and a file name then it downloads the file from tftp server. if you additionally specify length then it uploads the file to a tftp server
    – Serge
    Dec 1, 2018 at 16:52
  • @Serge This depends on u-boot implementation on a particular device. In all CPE modems and routers I used, u-boot supported only one-way file transfer, from external tftp into device memory.
    – Lexx Luxx
    Dec 2, 2018 at 18:12
  • @triwo of course it does: you could customise/remove any part of u-boot's UI. I meant the base version as it comes with SDK for hi35xx for quite a while
    – Serge
    Dec 3, 2018 at 19:40
2

If you are really lucky, you might be able to create a Linux initramfs image from another system (e.g. OpenWrt) if you can find one that supports the chipset, or enough of the chipset, that will boot over TFTP or ymodem to get you a serial console.

There seems to be some kind of support for hisilicon in (or coming to) the kernel, so you may also be able to spin up a buildroot image.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.