Ooops .. Looks like I bricked my cam ....

q1) where does tftp find the img components?
it will tftp from the IP defined in the 'serverip' environment variable.

q2) where does flwrite output the contents to?
the default location.

q3) are these "lines" actually processed or is it more like setting a variable to hold the commands for later? (ie da is a list of these commands and will be run later)
these lines are indeed 'processed' when you do the 'run dc' command, for example. think of them as macros.

so, now that you've id'd the partitions that need to be updated, you would do 'run dc' (for example), after setting the server variable. watch it do it's thing, then repeat for the other partitons you need to replace (as Alastair warned, DO NOT 'run da' or otherwise mess with the boot loader!)
 
  • Like
Reactions: alastairstevenson
WHOOHOO … YIPEE ….. I went ahead and rand the "run" commands (by mistake I ran dd but since file was not there it err'd out without causing any damage). Completed the run commands and did a reset and SUCCESS … the camera is once again working .... THANK YOU THANK YOU for all your help and patience and guidance ....

Appreciate the work all the members do and will try to keep current with what is happening and MAYBE … someday I can answer a question. Until then … keep up the good work all ...

Dave W
 
so u-boot is really like the old IPL deck that we used to feed into the card reader to get the system going.
Yes indeed - that beats even the RIM loader that was input with switches that loaded up the binary loader on the paper tape reader.

SORRY for all the questions but really want to understand and ensure I don't mess it up worse.
You've actually got it sussed, well done!

Let's see if I can answer your queries -
And according to the "install" instructions,
1) The upgrade command sequence must be executed in order.

2) The burn command of the flash partition.
"Commands": [ "burn u-boot-all.bin.img boot", "burn custom-x.cramfs.img custom", "burn romfs-x.cramfs.img romfs", "burn user-x.cramfs.img user", "burn web-x.cramfs.img web"]
These will be associated with the normal web GUI update process as opposed to handling the steps manually using the bootloader.

q1) where does tftp find the img components?
As files in the folder that the tftp server is running in.
q2) where does flwrite output the contents to?
That's not defined in the command line - I can only assume that the bootloader has access to a defined partition table that holds the flash block starting numbers and sizes.
are these "lines" actually processed
When you 'run' them, they are executed immediately.
And what about these lines that are later. Is tftp looking for more files? Or again, is it setting variables that "could" be used if needed?
There will be a variant of the supplied firmware that just does the whole flash in one go.
bootargs=init=linuxrc mem=${osmem} console=ttyAMA0,115200 root=/dev/mtdblock1 rootfstype=squashfs mtdparts=hi_sfc:0x40000(boot),0x2E0000(romfs),0x420000(user),0x40000(web),0x30000(custom),0x50000(mtd)
It appears that the mtdparts=hi_sfc: part aligns with the da (boot), dr (romfs), du (user), dw (web), dc (custom), dd (mtd) lines. What about the rest of them - dd,de,dl ? are they not needed to be defined?
That commandline is for the Linux kernel - it doesn't need to have any info on how the main application works.

type "run da" and all the others? Should I try it? Will I mess anything up?
There is some uncertainty as to what the result will be.
The 'update' button should have not done any harm, the cause of that problem seems unknown.
It all depends on whether the firmware file is valid for the hardware.
But by leaving the bootloader untouched there is an escape route that would allow another recovery activity.
I don't think it's common that the bootloader is updated, so it's unlikely in my view that there would be any version dependencies between it and the main application areas.

if I run these manually this time, will they need to be run again next time
Once the data has been written to the flash partitions, that's it done, no need to repeate.

Good luck!
I hope it works.
 
Thank you very much guys!!!
I've made these same steps like Dave did and I could make my chinese ip cam work again!
My cam is a Besder cam, either from xiongmaitech.
Some problem happened when I was updating the firmware from ICsee app and the cam died.
Having as base what Dave did, I could find the uart pins on the cam's board and connected it to a nodemcu (esp8266) that was not working too rsrs.
I've removed the broken esp8266 module from the nodemcu and soldered the wires to the gnd, tx and rx in respectives pins.
To me it was like Incredible, rsrs,but worked very well connecting to a ubuntu 20.04 using minicom.
Later I am create a vídeo about this. Maybe it can help someone else.

Thanks a lot guys!
 
Hi.
I am having trouble unbricking my IPCam.
I tried upgrading the firmware by renaming a different package to V20.1.23.6.x, as my original release was.
I connected UART to CH340G chip and I have access to U-Boot:
(pass HI2105CHIP)
U-Boot 2016.11 (Apr 03 2019 - 18:54:33 +0800)hi3516ev200
Block:64KB Chip:8MB Name:"XM25QH64AHIG"

When I plug the power, kernel fails:
SF: 1703936 bytes @ 0x40000 Read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image

So, I read a lot through the forums, but I still cannot figure out how can I find a working kernel to upload via tftp.
I can get files using tftpboot, to the camera memory, but most of the tutorials talk about "run" command, which I do not have in my U-Boot. Also I have tftpboot instead of tftp.


It seems this might help obtaining a kernel file:
hisilicon # version

U-Boot 2016.11 (Apr 03 2019 - 18:54:33 +0800)hi3516ev200
arm-himix100-linux-gcc (HC&C V100R002C00B032_20190114) 6.3.0
GNU ld (GNU Binutils) 2.29

But,this is were I got stuck. I don't seem to find a working uImage.bin to upload to memory and boot it from memory first, then transfer it to flash.
Also I saw that the flash organization is different depending on the Chip size (mine is the smallest: 8MB)

Can someone please help me find/build a kernel or find a working firmware to upload through tftp/UART?
 
Hello again,

I managed to copy on SPI NOR uImage and rootfs, like this:

sf probe 0

mw.b 0x42000000 ff 1000000

tftp 0x42000000 uImage

sf erase 0x50000 0x200000

sf write 0x42000000 0x50000 ${filesize}


mw.b 0x42000000 ff 1000000

tftp 0x42000000 rootfs.squashfs

sf erase 0x250000 0x500000

sf write 0x42000000 0x250000 ${filesize}

And then setenv:

bootargs=mem=40M console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs
bootcmd=sf probe 0;sf read 0x42000000 0x50000 0x250000;bootm 0x42000000
mtdparts=hi_sfc:256K(boot),2M(kernel),5M(rootfs)

BUT, after the kernel starts, it does not find the rootfs. Here is the log:

hisilicon # printenv
=serverip 192.168.1.132
arch=arm
baudrate=115200
board=hi3516ev200
board_name=hi3516ev200
bootargs=mem=40M console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs
bootcmd=sf probe 0;sf read 0x42000000 0x50000 0x250000;bootm 0x42000000
bootdelay=1
bootfile=u-boot.bin
cpu=armv7
ethact=eth0
ethaddr=1a:35:0a:2f:eb:e6
fileaddr=42400000
filesize=4f2000
ipaddr=192.168.1.10
mtdparts=hi_sfc:256K(boot),2M(kernel),5M(rootfs)
osmem=32M
server=192.168.1.159
serverip=192.168.1.132
soc=hi3516ev200
stderr=serial
stdin=serial
stdout=serial
totalmem=46M
vendor=hisilicon
verify=n

Environment size: 629/65532 bytes
hisilicon # bdinfo
arch_number = 0x00001F40
boot_params = 0x40000100
DRAM bank = 0x00000000
-> start = 0x40000000
-> size = 0x04000000
eth0name = eth0
ethaddr = 1a:35:0a:2f:eb:e6
current eth = eth0
ip_addr = 192.168.1.10
baudrate = 115200 bps
TLB addr = 0x43FF0000
relocaddr = 0x43F5E000
reloc off = 0x0375E000
irq_sp = 0x43F1DEE0
sp start = 0x43F1DED0
Early malloc usage: 70 / 2000
hisilicon # getinfo spi
Block:64KB Chip:8MB*1
ID:0x20 0x70 0x17
Name:"XM25QH64AHIG"
hisilicon # reset
resetting ...



System startup

Uncompress Ok!

U-Boot 2016.11 (Apr 03 2019 - 18:54:33 +0800)hi3516ev200

Relocation Offset is: 0375e000
Relocating to 43f5e000, new gd at 43f1def0, sp at 43f1ded0
SPI Nor: Check Flash Memory Controller v100 ... Found
SPI Nor ID Table Version 1.0
SPI Nor(cs 0) ID: 0x20 0x70 0x17
Block:64KB Chip:8MB Name:"XM25QH64AHIG"
SPI Nor total size: 8MB
NAND: 0 MiB
In: serial
Out: serial
Err: serial
Net: eth0
Hit any key to stop autoboot: 1 0
device 0 offset 0x50000, size 0x250000

SF: 2424832 bytes @ 0x50000 Read: OK
## Booting kernel from Legacy Image at 42000000 ...
Image Name: Linux-4.9.37
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1857032 Bytes = 1.8 MiB
Load Address: 40008000
Entry Point: 40008000
Loading Kernel Image ... OK

Starting kernel ...

Booting Linux on physical CPU 0x0
Linux version 4.9.37 (runner@fv-az65-809) (gcc version 7.5.0 (Buildroot -gce4dd29) ) #1 Sat Oct 16 10:59:27 UTC 2021
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
CPU: div instructions available: patching division code
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
OF: fdt:Machine model: Hisilicon HI3516EV200 DEMO Board
cmz zone is not set!
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 10160
Kernel command line: mem=40M console=ttyAMA0,115200 root=/dev/mtdblock3 rootfstype=squashfs
PID hash table entries: 256 (order: -2, 1024 bytes)
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 35316K/40960K available (3809K kernel code, 129K rwdata, 840K rodata, 176K init, 179K bss, 5644K reserved, 0K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc3000000 - 0xff800000 ( 968 MB)
lowmem : 0xc0000000 - 0xc2800000 ( 40 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0xc0008000 - 0xc03c0638 (3810 kB)
.init : 0xc0494000 - 0xc04c0000 ( 176 kB)
.data : 0xc04c0000 - 0xc04e04a0 ( 130 kB)
.bss : 0xc04e2000 - 0xc050eefc ( 180 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:16 nr_irqs:16 16
Gic dist init...
arm_arch_timer: Architected cp15 timer(s) running at 50.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
Switching to timer-based delay loop, resolution 20ns
clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
Console: colour dummy device 80x30
Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=500000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x40008200 - 0x40008258
devtmpfs: initialized
VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 5
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Serial: AMBA PL011 UART driver
12040000.uart: ttyAMA0 at MMIO 0x12040000 (irq = 20, base_baud = 0) is a PL011 rev2
console [ttyAMA0] enabled
12041000.uart: ttyAMA1 at MMIO 0x12041000 (irq = 21, base_baud = 0) is a PL011 rev2
ssp-pl022 12070000.spi: ARM PL022 driver, device ID: 0x00800022
ssp-pl022 12070000.spi: mapped registers from 0x12070000 to c306b000
ssp-pl022 12071000.spi: ARM PL022 driver, device ID: 0x00800022
ssp-pl022 12071000.spi: mapped registers from 0x12071000 to c306f000
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
clocksource: Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
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.
workingset: timestamp_bits=30 max_order=14 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
jffs2: version 2.2 (NAND) (ZLIB) (RTIME) (c) 2001-2006 Red Hat, Inc.
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252)
io scheduler noop registered
io scheduler deadline registered (default)
pl061_gpio 120b0000.gpio_chip: PL061 GPIO chip @0x120b0000 registered
pl061_gpio 120b1000.gpio_chip: PL061 GPIO chip @0x120b1000 registered
pl061_gpio 120b2000.gpio_chip: PL061 GPIO chip @0x120b2000 registered
pl061_gpio 120b4000.gpio_chip: PL061 GPIO chip @0x120b4000 registered
pl061_gpio 120b5000.gpio_chip: PL061 GPIO chip @0x120b5000 registered
pl061_gpio 120b6000.gpio_chip: PL061 GPIO chip @0x120b6000 registered
pl061_gpio 120b7000.gpio_chip: PL061 GPIO chip @0x120b7000 registered
pl061_gpio 120b8000.gpio_chip: PL061 GPIO chip @0x120b8000 registered
brd: module loaded
hisi-sfc hisi_spi_nor.0: SPI Nor ID Table Version 1.2
hisi-sfc hisi_spi_nor.0: The ID: 0x20 isn't in the BP table, Current device can't not protect
@spi_nor_scan(), no "m25p,fast-read".
@spi_nor_scan(), modes->rd_modes:0xd.
hisi-sfc hisi_spi_nor.0: (Fast) Read: opcode=BBh, protocol=122, mode=0, wait=8
hisi-sfc hisi_spi_nor.0: nor->read_opcode[3: Read; 0B: Fast Read; 3B: Dual; BB: Dual IO; 6B: Quad; EB: Quad IO]: 0xbb.
hisi-sfc hisi_spi_nor.0: xm25qh64a (Chipsize 8 Mbytes, Blocksize 64KiB)
FEPHY:addr=1, la_am=0xc, ldo_am=0x5, r_tuning=0x1c
libphy: hisi_femac_mii_bus: probed
libphy: Fixed MDIO Bus: probed
Generic PHY 10041100.mdio:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=10041100.mdio:01, irq=-1)
phy_id=0x20669903, phy_mode=mii
hisi-femac 10040000.ethernet: using random MAC address 6e:6b:c5:b7:3a:34
xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
xhci-hcd xhci-hcd.0.auto: hcc params 0x0220fe6c hci version 0x110 quirks 0x20010010
xhci-hcd xhci-hcd.0.auto: irq 115, io mem 0x10030000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
hub 2-0:1.0: USB hub found
hub 2-0:1.0: hub can't support USB3.0
hibvt_rtc 120e0000.rtc: rtc core: registered 120e0000.rtc as rtc0
hibvt_rtc 120e0000.rtc: RTC driver for hibvt enabled
i2c /dev entries driver
hibvt-i2c 12060000.i2c: hibvt-i2c0@100000hz registered
hibvt-i2c 12061000.i2c: hibvt-i2c1@100000hz registered
hibvt-i2c 12062000.i2c: hibvt-i2c2@100000hz registered
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: SDHCI controller on 10010000.sdhci [10010000.sdhci] using ADMA in legacy mode
mmc1: SDHCI controller on 10020000.sdhci [10020000.sdhci] using ADMA in legacy mode
NET: Registered protocol family 10
NET: Registered protocol family 17
hibvt_rtc 120e0000.rtc: setting system clock to 1970-01-01 00:00:33 UTC (33)
VFS: Cannot open root device "mtdblock3" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
0100 65536 ram0 (driver?)
0101 65536 ram1 (driver?)
0102 65536 ram2 (driver?)
0103 65536 ram3 (driver?)
0104 65536 ram4 (driver?)
0105 65536 ram5 (driver?)
0106 65536 ram6 (driver?)
0107 65536 ram7 (driver?)
0108 65536 ram8 (driver?)
0109 65536 ram9 (driver?)
010a 65536 ram10 (driver?)
010b 65536 ram11 (driver?)
010c 65536 ram12 (driver?)
010d 65536 ram13 (driver?)
010e 65536 ram14 (driver?)
010f 65536 ram15 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 0 PID: 1 Comm: swapper Not tainted 4.9.37 #1
Hardware name: Generic DT based system
Backtrace:
[<c0013120>] (dump_backtrace) from [<c0013418>] (show_stack+0x18/0x1c)
r7:c2321000 r6:c042ebe8 r5:00000000 r4:c04e22e8
[<c0013400>] (show_stack) from [<c01909b8>] (dump_stack+0x24/0x28)
[<c0190994>] (dump_stack) from [<c006e0c0>] (panic+0xe4/0x24c)
[<c006dfe0>] (panic) from [<c0495394>] (mount_block_root+0x26c/0x348)
r3:d3053b52 r2:d3053b52 r1:c2039ebc r0:c042ebe8
r7:c2321000
[<c0495128>] (mount_block_root) from [<c04955fc>] (mount_root+0x7c/0x80)
r10:c04b7838 r9:c0494620 r8:c04b7834 r7:c04e2000 r6:c04e2000 r5:c04e2024
r4:00000000
[<c0495580>] (mount_root) from [<c0495784>] (prepare_namespace+0x184/0x1cc)
r5:c04e2024 r4:c04b7858
[<c0495600>] (prepare_namespace) from [<c0494f2c>] (kernel_init_freeable+0x1d0/0x1e0)
r6:c04e2000 r5:00000009 r4:c0492318
[<c0494d5c>] (kernel_init_freeable) from [<c03ba618>] (kernel_init+0x10/0xfc)
r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c03ba608
r4:00000000
[<c03ba608>] (kernel_init) from [<c000fee8>] (ret_from_fork+0x14/0x2c)
r5:c03ba608 r4:00000000
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Please help me figure it out. I think the bootcmd and/or bootargs are wrong, but not sure why.
 
bootcmd=sf probe 0;sf read 0x42000000 0x50000 0x250000;bootm 0x42000000
mtdparts=hi_sfc:256K(boot),2M(kernel),5M(rootfs)
These appear to be inconsistent.
mtdparts are defined as :

hi_sfc:256K(boot)
0x000000 - 0x040000

2M(kernel)
0x040000 - 0x240000

5M(rootfs)
0x240000 - 0x740000

which don't match the bootcmd or the locations written to.
Are you missing an env or similar partition on mtdparts, and maybe a config?
bootargs references mtdblock3 but there are only mtdblock0,1,2 defined.

If the size of uImage fits in a 2M partition, maybe adjust the write locations to match what's in mtdparts.
 
Thanks for the quick reply.
I am not sure what I am doing there. I copied the mtdparts from some other printenv-s, from different forums.
uImage has 1.77 MB (1,857,096 bytes)
rootfs.squshfs has 4.81 MB (5,046,272 bytes)

So, in fact , after the failed firmware upgrade, I messed up bootcmd, bootargs and mtdparts. I am not sure where I can get a working version for these.
I did try also with mtdblock2, but I get the same error.
 
Last edited:
I set these values for bootargs and bootcmd:
setenv bootargs 'mem=40M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 rootfstype=squashfs init=/init mtdparts=hi_sfc:256k(boot),64k(env),2048k(kernel),5120k(rootfs),-(rootfs_data)'
setenv bootcmd 'sf probe 0; sf read 0x42000000 0x50000 0x200000; bootm 0x42000000'

There was another 'env' partition that I missed when I set it before.
My U-Boot version is pretty basic, so I don't have run, or tftp commands. I used tftpboot to copy the uImage and rootfs files to ram and then write them to spi.
 
  • Like
Reactions: alastairstevenson
Olá, após conseguir entrar no minicom, agora pede uma senha, alguma ideia de como resolver ou encontrar essa senha:

U-Boot 2014.04 (25 de agosto de 2021 - 11:31:52)
CPU: XM530
WDT: 300S
DRAM: 64MiB
MMC: arasan: 0
Em: seriado
Fora: série
Erro: série
Rede: dwmac.10010000
Pressione Ctrl+C to stop autoboot
 

Attachments

  • IMG_20220503_145750387.jpg
    IMG_20220503_145750387.jpg
    1.1 MB · Views: 15