Unable to apply the hack on YI Dome U Pro 2K - h60ga #270
Comments
|
You might try control-q at the start to stop the auto boot and enter at the => prompt to get more detail and you might need to do it more than once if the hack resets the camera. Example with debug output enabled[38]HELLO! BOOT0 is starting Nov 14 2019 20:01:31! U-Boot 2018.05 (Jan 20 2021 - 20:35:47 +0800) Allwinner Technology [00.202]DRAM: 64 MiB => setenv loglevel 8 start: 0x2e0, len: 0x1 Booting kernel from Legacy Image at 45000000 ...Image Name: ARM OpenWrt Linux-4.9.118 ** 2 printk messages dropped ** [ 0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=50c5387d BusyBox v1.27.2 () built-in shell (ash) vm.dirty_expire_centisecs = 500 Welcome to XiaoYi Linux.root@(none):/# fs.mqueue.msg_max = 256 checkdisk.c(main-477)[00:00:15.671]:Need update tf_status.stat, and so on....... |
|
Well it says hack script init.sh that was copied to the backup partition is missing a chunk off the end so it doesn't get executed thus leaving the system bricked. The question is do you have a faulty init.sh on your SDCard or did something go wrong when the hack was initiated. Your putty.log only shows details once bricked, not the details when the hack was applied which might help explain the why. If after checking the hack file init.sh on the SDCard is okay then run the hack from an unbricked state using control-q to stop the auto boot before the hack is applied and enter the commands to show logging as in previous post. The hack will reset the camera and then another control-q would be needed to show the output after the hack was applied which will probably be the same as your previous putty log if nothing has been changed. P.S. Please make sure there aren't any carriage returns in the script as the system chokes on these. Can check file with hex editor for 0x0d. |
This is very important. |
|
@0-Al , @roleoroleo , thank you for your answers. Previously I was decompressing the .tgz file with the hack on Mac OS and I was moving the uncompressed files to Windows in order to be able to insert them on the MicroSD card. I have tried to apply the hack again, but this time I have decompressed the .tgz file on Windows (with 7zip). Unfortunately the result of the hack is the same - bricked cam 🙁 Here is the Putty log, which I took when I have applied the hack: putty.log Here is the portion of the log, which is related with the hack: Any suggestions where the problem can be? |
|
Seems there's a space issue (not enough), init.sh got corrupted and seems wifidhcp.sh somehow got wiped too. I tried copying init.sh direct on my cam and got the same error, then deleted one of the bigger files (rsa...) and tried to copy it back (the same rsa... file) but failed again! Perhaps roleo will shed some light on the linux way of things and how to fix it. I will recover mine later on. I'm using the Aug firmware update, not sure if that makes a difference. Edit: |
|
backup partition runs with very little free space. When "No space left on device" happens it's very hard to recover the partition without rewrite it completely. Or, I could create a "hack like" procedure that rewrites the partition without the need of a serial adapter. |
I was thinking the same think when I wasn’t able to find the RX and TX pads on my cam in order to unbrick it, but now I’m communicating with the cam via the USB port so the unbricking procedure is not an issue. Regarding the hack - is there anything that I can try in order to solve the “No space left on device” issue and successfully apply the hack? One solution could be to add the modified files directly in the .bin file (which contains the backup partition) and then to insert it in the cam by following the steps in the unbricking procedure. |
This could be a solution. But I think it's not necessary. |
I received my U Pro on the 1st Oct. I backed up the data before allowing it a network connection. After connecting to the internet it downloaded the August update and again I made another backup, all done on the day I received it. I used the official Android and PC Yi app to check it was working okay and wasn't until the 7th that I installed the Yi-Hack as a means to maybe help @kyutov. It should be noted that extra files are added to /backup by the firmware, "wpa_supplicant.conf", "upgrade_conf" which perhaps is enough to push the system over the edge due to space issue. Partial Yi-Hack log on Aug firmware, no previous Yi-Hack. Partial Yi-Hack log on Aug firmware, no previous Yi-Hack but using a smaller init.sh hack file as suggested A lot of stuff in that file that's not pertinent to the h60ga. The 4k block erase size seems to waste too much space, 8k works better to provide 50k of free space but unfortunately does't seem compatible with the firmware as is. Maybe could have used a big chunk of that128k from env that's wasted too. I agree the unhack may cause issues so should warn users about this otherwise they might face bricked camera's like @SmartM-ui or possibly have problems with getting updates to work after the hack is installed, again due to the space problem. Note that the actual update only updates the home partition and possibly conf. |
|
@0-Al I will add 3 tasks to the todo list:
|
|
@0-Al |
|
@0-Al , thank you for your assistance! I have tried to reduce the size of the |
Try to enable swap space. |
Yes, it boot looped. I also built with 4k erase size to check if I had maybe built wrongly and that worked fine. I didn't try replacing the init.sh and wifidhcp.sh files and then build, should work I think but perhaps not suitable either way.
You have it already, 9.0.27.20_202108161046 downloaded from @Rocket200 #247 (comment) Pretty much the same as mine but slightly different data sizes for the added stuff at the end. From my observation possibly the update mechanism adds data to the backup partition block 4 from offset 0x11ee3c, there's also a gap and some more added data at 0x123000 which extends on mine to 0x1231fd, Rockets' is a little longer. After installing the hack with 3.2k init.sh the original is presumably marked deleted but not erased and appears that there is an entry for each 4k page with 3 entries total for the data part of init.sh. The new init.sh is appended to the end of 0x1231fd and only uses one data entry with data compressed to 0x41c, 0x460 with header. Add some more for file name section. wifidhcp.sh is appended to the end of that. So now data extends to 0x1238a7. Don't know what all this means if another upgrade comes along? Don't know what those remaining blocks (124000-12ffff) are seemingly being reserved for? Seem to be 12 extra, 48k of which only one (4k) is left as free. I think if you mount the partition on a Linux PC using 4k erase size setting and total size setting equal to the partition size 0x130000 it will act much the same as if in the camera. Well it seemed to for me. Makes testing easier. @kyutov , snapshot crashed the camera for me without swap file enabled. I haven't used it much though as I'm after outdoor camera's, preferably wired. Bought a 2MP Yiiot but turned out to be a 1MP sensor with output encoded from 720p to 1080p. So I bought a 3MP outdoor Yiiot, very different looking but inside the same JX-H63 1MP sensor! Unfortunately seems I have to look for non Yi camera. I was curious with the dome pro but don't really have any plans for indoor camera's. |
|
I'm not completely sure but I think update only contains home partition. Comparing the files posted by Rocket200, they differ only in the presence of upgrade.conf and wpa_supplicant.conf So, probably these 2 files are added at runtime by a running process and not added by the update. |
I already said this at the end of #270 (comment)
I can only assume I have confused you, sorry, I am not so good with explaining.
I would assume the camera is notified of the update and stores the information to update in the backup partition. The "back.bin" file is added early IIRC synced to some info in conf or mfg idk. The file date probably implies the time has not yest been set. Original files in Rocket firmware are dated 8th Mar, the update information was stored on 18th Sep, url file was marked deleted but still exists on the SPI chip, not unusual.
But even before this the chmod setting of wifidhcp.sh fails on an earlier version, things get worse when the extra files are introduced and free space is reduced further. Anyway this isn't important anymore now that you know about it. Great project, keep up the good work and sorry for being confusing. |
Sorry I didn't understand what you meant.
I removed wifidhcp.sh from the hack to avoid unnecessary writes to the flash: b984c1f |
|
Please remember I'm new to this so mistakes are likely. init.sh#!/bin/sh
SUFFIX=h60ga
enable_4g=
PATH="/usr/bin:/usr/sbin:/bin:/sbin:/home/base/tools:/home/app/localbin:/home/base"
LD_LIBRARY_PATH="/lib:/usr/lib:/home/lib:/home/qigan/lib:/home/app/locallib:/tmp/sd:/tmp/sd/gdb"
export PATH
export LD_LIBRARY_PATH
NETWORK_IFACE=wlan0
ulimit -c unlimited
ulimit -s 1024
echo 100 > /proc/sys/vm/dirty_writeback_centisecs
echo 50 > /proc/sys/vm/dirty_expire_centisecs
if [ "${pix}" = "2m" ];then
echo 2048 > /proc/sys/vm/extra_free_kbytes
fi
echo 400 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/vm/drop_caches
echo 256 > /proc/sys/vm/min_free_kbytes
sysctl -w vm.dirty_background_ratio=2
sysctl -w vm.dirty_expire_centisecs=500
sysctl -w vm.dirty_ratio=2
sysctl -w vm.dirty_writeback_centisecs=100
sysctl -w fs.mqueue.msg_max=256
mkdir /dev/mqueue
mount -t mqueue none /dev/mqueue
mount tmpfs /tmp -t tmpfs -o size=32m
mkdir /tmp/sd
mkdir /dev/shm
mkdir /tmp/var
mkdir /tmp/var/run
mkdir /tmp/run
checkdisk
rm -fr /tmp/sd/FSCK*.REC
umount -l /tmp/sd
mount -t vfat /dev/mmcblk0p1 /tmp/sd
mkdir /tmp/ko/
mkdir /tmp/app/
mkdir /tmp/tools/
if [ -f /home/home_${SUFFIX}m ]; then
dd if=/home/home_${SUFFIX}m of=/tmp/newver bs=22 count=1
newver=$(cat /tmp/newver)
if [ -f /home/homever ]; then
curver=$(cat /home/homever)
else
curver=0
fi
echo check version: newver=$newver, curver=$curver
if [ $newver != $curver ]; then
### cipher ###
sleep 1
mkdir /tmp/update
cp -rf /home/base/tools/extpkg.sh /tmp/update/extpkg.sh
/tmp/update/extpkg.sh /home/home_v429m
rm -rf /tmp/update
rm -rf /home/home_${SUFFIX}m
#sync
reboot -f
fi
rm -rf mv /home/home_${SUFFIX}m
elif [ -f /tmp/sd/home_${SUFFIX}m ]; then
dd if=/tmp/sd/home_${SUFFIX}m of=/tmp/newver bs=22 count=1
newver=$(cat /tmp/newver)
if [ -f /home/homever ]; then
curver=$(cat /home/homever)
else
curver=0
fi
echo check version: newver=$newver, curver=$curver
if [ $newver != $curver ]; then
### cipher ###
sleep 1
mkdir /tmp/update
cp -rf /tmp/sd/home_${SUFFIX}m /tmp/update/
cp -rf /backup/tools/extpkg.sh /tmp/update/extpkg.sh
/tmp/update/extpkg.sh /tmp/sd/home_${SUFFIX}m
rm -rf /tmp/update
mv /tmp/sd/home_${SUFFIX}m /tmp/sd/home_${SUFFIX}m.done
sync
reboot -f
fi
mv /tmp/sd/home_${SUFFIX}m /tmp/sd/home_${SUFFIX}m.done
fi
if [ -f /backup/url ];then
if [ -f /home/base/wifi/8188fu.ko ];then
insmod /home/base/wifi/8188fu.ko
elif [ -f /home/base/wifi/8189fs.ko ];then
insmod /home/base/wifi/8188fs.ko
elif [ -f /backup/ko/8188fu.ko ];then
insmod /backup/ko/8188fu.ko
elif [ -f /backup/ko/8189fs.ko ];then
insmod /backup/ko/8189fs.ko
elif [ -f /backup/ko/atbm603x_wifi_usb.ko ];then
insmod /backup/ko/atbm603x_wifi_usb.ko
elif [ -f /backup/ko/ssv6x5x.ko ];then
if [ -f /home/base/ko/icplus.ko ];then
insmod /home/base/ko/icplus.ko
elif [ -f /backup/ko/icplus.ko ];then
insmod /backup/ko/icplus.ko
fi
sleep 1
ifconfig lo up
ifconfig ${NETWORK_IFACE} up
ethmac=d2:`ifconfig ${NETWORK_IFACE} |grep HWaddr|cut -d' ' -f10|cut -d: -f2-`
ifconfig eth0 hw ether $ethmac
fi
/backup/tools/upgrade.sh
reboot -f
fi
/usr/sbin/telnetd &
if [ -f /tmp/sd/lower_half_init.sh ];then
source /tmp/sd/lower_half_init.sh
elif [ -f /home/app/lower_half_init.sh ];then
source /home/app/lower_half_init.sh
else
source /backup/lower_half_init.sh
fiBut I think you meant help for testing your version 😁 |
Both, the content of the file and the test. |
I would remove the following line @roleoroleo - let me know how I can help you with the tests |
|
I will prepare a kit... |
|
Here it is. This is a new version of the hack: I removed the changes to wifidhcp.sh |
|
Will try this later. Did have a quick look and wonder why there's a zero'd back.bin file, this should contain the hw and gpio settings IIRC. Maybe those settings cannot be guaranteed across all cameras though so will try removing the back.bin and see if the system will add a new one. Busy at this time but will get to it. |
|
Many backups I have received contain a zero-filled back.bin. |
Stops dead at that line, is it supposed to be there or is yi-hack folder needed too? |
|
It's only the environment. |
line removed### Unbricking
killall: wpa_supplicant: no process killed
umount: can't unmount /home/app/script/wifidhcp.sh: Invalid argument
umount: can't unmount /backup: Resource busy
1216+0 records in
1216+0 records out
1245184 bytes (1.2MB) copied, 14.989870 seconds, 81.1KB/s
### Disabling for next reboot
starting pid 654, tty '': '/etc/init.d/rcK'
mount: mounting /dev/mtdblock3 on /home failed: Resource busy
mount: mounting /dev/mtdblock4 on /backup failed: Resource busy
sh: you need to specify whom to kill
mount: mounting /dev/mtdblock3 on /home failed: Resource busy
mount: mounting /dev/mtdblock4 on /backup failed: Resource busy
sh: you need to specify whom to kill
killall: udevd: no process killed
starting pid 677, tty '': '/sbin/swapoff -a'
starting pid 678, tty '': '/bin/umount -a -r'
umount: devtmpfs busy - remounted read-only
The system is going down NOW!
<reboot snip>
root@(none):/# ls -l /backup/
-rwxr-xr-x 1 root root 364 Oct 13 18:26 back.bin
-rwxr-xr-x 1 root root 3536 Oct 13 18:26 init.sh
drwxr-xr-x 2 root root 0 Oct 13 18:26 isp
drwxr-xr-x 2 root root 0 Oct 13 18:26 ko
-rwxr-xr-x 1 root root 1513 Oct 13 18:26 lower_half_init.sh
drwxr-xr-x 2 root root 0 Oct 13 18:26 tools
root@(none):/# ls -l /backup/tools/
-rwxr-xr-x 1 root root 4755 Oct 13 18:26 default.script
-rwxr-xr-x 1 root root 65 Oct 13 18:26 ethdhcp.sh
-rwxr-xr-x 1 root root 1818 Oct 13 18:26 extpkg.sh
-rwxr-xr-x 1 root root 103 Oct 13 18:26 mem_update_pack.sh
-rwxr-xr-x 1 root root 366284 Oct 13 18:26 rsa_pub_dec
-rwxr-xr-x 1 root root 639 Oct 13 18:26 set_wifi.sh
-rwxr-xr-x 1 root root 657 Oct 13 18:26 update_homefs.sh
-rwxr-xr-x 1 root root 5567 Oct 13 18:26 upgrade.sh
-rwxr-xr-x 1 root root 9668 Oct 13 18:26 upgrade_firmware
-rwxr-xr-x 1 root root 238 Oct 13 18:26 wificonnect.sh
-rwxr-xr-x 1 root root 67 Oct 13 18:26 wifidhcp.sh
-rwxr-xr-x 1 root root 121 Oct 13 18:26 wifitest.sh
-rwxr-xr-x 1 root root 613112 Oct 13 18:26 wpa_supplicant
root@(none):/# hexdump -C /backup/back.bin
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000160
root@(none):/# |
|
Probably it's a race condition. |
When I tested mine I had these set automatically so I could have software monitor the serial port for reboots, haven't tried it without! |
|
Hello guys. I'm going to buy a DOME U PRO today and I will be available to test it if you need help. I see the last release is dated August.. |
|
I could send you a new method to try, if you agree. |
|
Ok, is that the one you put in the Wiki? Or a new one? EDIT: i will receive them tomorrow. |
|
No, a new one. |
|
Fine. I'll give it a try. Do I need to do some stuff to give you a feedback? |
|
Simply check if it works. |
Hello. What I noticed is that "Factory" is missing. Can I proceed? |
|
Yes, Factory is missing because the upgrade procedure is made by the bootloader. |
|
You are great! Tell me if you need some data or what...😁 |
|
Hello @roleoroleo, I have some troubles with the hack. But only on one of the two Dome U Pro I bought. In the second one the RTSP method is not working. It gives me authentication error both on vlc and frigare... |
|
Check if you are using special chars (some not allowed char) in username or password. |
|
I don't have any user or psw configured. I'll try with a reset |
|
Perfect, the reset worked! Ty! |
I was able to successfully hack my can with this file as well. With the new hack procedure, the cam works without issues after I have applied the hack. It doesn't go in restart loops as when I have hacked it with the other hack procedure 👍 |
|
Happy to have solved the problem. |
|
Hey @roleoroleo, I've just ordered two of these cameras. Is this procedure with h60ga_0.1.9_u.tar.gz preferred over the one in the wiki? |
|
Yes, use this archive. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Hi @roleoroleo, tried to install the hack on my Yi Dome U Pro 2K and it works but I'm having a problem: if I go to the Snapshot tab of the web interface it shows the snapshot correctly but after a couple of seconds the yicam reboot itself. |
|
Read the faq page in the wiki. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Hello, Is this compatible with version LFUS 12.0.27* ? |
|
You need a beta release: |
I have tried to perform the hack on my YI Dome U Pro 2K cam (which is h60ga) twice, but in both cases I ended up bricking it. The second time I have applied the hack while the cam was connected to Putty via serial connection.
Here is the complete log, which I have extracted while I was trying to apply the hack:
[133]HELLO! BOOT0 is starting Nov 14 2019 20:01:31!
[138]BOOT0 commit : 81c18ee
[141]board init start
[143]set pll start
[146]set pll end
[147][pmu]: bus read error
[150]board init ok
[152]chip id check OK
[154]DRAM BOOT DRIVE INFO: V0.41
[157]DRAM CLK = 528 MHz
[159]DRAM Type = 2 (2:DDR2,3:DDR3)
[163]DRAMC read ODT off.
[165]DRAM ODT off.
[168]DRAM SIZE =64 M
[174]DRAM simple test OK.
[177]rtc standby flag is 0x0, super standby flag is 0x0
[182]dram size =64
[185]spinor id is: c8 40 17, read cmd: 03
[189]Succeed in reading toc file head.
[193]The size of toc is 4c000.
[246]Entry_name = optee
[249]Entry_name = u-boot
[253]Entry_name = dtb
[256]Jump to secend Boot.
MESSAGE: [0x0] TEE-CORE: OP-TEE version: sun8iw19p1_v0.6.0-12-g97f2688 #1 2019年 11月 08日 星期五 08:26:51 UTC arm
ERROR: [0x0] TEE-CORE:platform_standby_fdt_parse:126: no pmu node
ERROR: [0x0] TEE-CORE:sunxi_twi_parse_from_dt:84: no pmu node
U-Boot 2018.05 (Mar 08 2021 - 23:23:22 +0800) Allwinner Technology
[00.300]DRAM: 64 MiB
[00.303]Relocation Offset is: f9f94000
[00.314]secure enable bit: 0
[00.316]CPU=816 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=132Mhz
[00.323]gic: sec monitor mode
[00.325]flash init start
[00.328]workmode = 0,storage type = 3
SF: Detected gd25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
[00.344]sunxi flash init ok
[00.347]Loading Environment from SUNXI_FLASH... start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x3e00, len: 0x100
OK
[00.408]try sprite_led_gpio config
xxxxxxxxxxxxxxlijun uboot xiaoyiledinit
[00.416]sprite_led_gpio start
00.419update dtb dram start
[00.423]update dtb dram end
[00.425]update dts
root_partition is rootfs
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
set root to /dev/mtdblock2
[00.488]update part info
[00.491]update bootcmd
mmc driver ver uboot2018:2019-8-15 16:34:00
get mem for descripter OK !
[00.503]get sdc_wipe fail.
[00.505]get sdc0 sdc_erase fail.
[00.508]get sdc0 sdc_boot fail.
[00.511]get sdc0 sdc_odly_50M fail.
[00.514]get sdc0 sdc_sdly_50M fail.
[00.518]get sdc0 sdc_odly_50M_ddr fail.
[00.521]get sdc0 sdc_sdly_50M_ddr fail.
[00.525]get sdc0 sdc_freq fail.
[00.527]get sdc0 sdc_b0p fail.
[00.530]get card0_boot_para:sdc_ex_dly_used fail
[00.535]get card-pwr-gpios handler:1119307360
[00.539]get card0_boot_para:time_pwroff:200ms
[00.545]Using default timing para
[00.748]init mmc 0 clock and io
devnum 0, prv 43fbd42c, bdesc 42b74844
SUNXI SD/MMC: 0
[00.755]==================== work mode: 0 0, sample_mode:0
[00.761]=============== start mmc_init_boot...
card_caps:0x3000000a
host_caps:0x3000003f
[00.825]unable to read ssr
[00.828]unable to read ssr
[00.831]the mode SD Legacy (freq : 25 MHz)
check_file [/one_h60ga.bin] exsit
check_file [/one_h60ga.bin] exsit
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:boot start_offset:0x20 part_size:1900544
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:rootfs start_offset:0xea0 part_size:1179648
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:home start_offset:0x17a0 part_size:3407872
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:backup start_offset:0x31a0 part_size:1245184
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:env start_offset:0x3b20 part_size:131072
Nothing updated, start normal boot
Hit ctrl + q to stop autoboot: 0
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
[01.959]partinfo: name boot, start 0x20, size 0xe80
start: 0x300, len: 0x40
start: 0x340, len: 0xe10
[02.436]android.hardware = sun8iw19p1
Booting kernel from Legacy Image at 45000000 ...
Image Name: ARM OpenWrt Linux-4.9.118
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1875896 Bytes = 1.8 MiB
Load Address: 40008000
Entry Point: 40008000
[02.502]Starting kernel ...
[106]HELLO! BOOT0 is starting Nov 14 2019 20:01:31!
[111]BOOT0 commit : 81c18ee
[114]board init start
[116]set pll start
[119]set pll end
[120][pmu]: bus read error
[123]board init ok
[125]chip id check OK
[127]DRAM BOOT DRIVE INFO: V0.41
[130]DRAM CLK = 528 MHz
[132]DRAM Type = 2 (2:DDR2,3:DDR3)
[136]DRAMC read ODT off.
[138]DRAM ODT off.
[141]DRAM SIZE =64 M
[147]DRAM simple test OK.
[150]rtc standby flag is 0x0, super standby flag is 0x0
[155]dram size =64
[158]spinor id is: c8 40 17, read cmd: 03
[162]Succeed in reading toc file head.
[166]The size of toc is 4c000.
[218]Entry_name = optee
[222]Entry_name = u-boot
[226]Entry_name = dtb
[229]Jump to secend Boot.
MESSAGE: [0x0] TEE-CORE: OP-TEE version: sun8iw19p1_v0.6.0-12-g97f2688 #1 2019年 11月 08日 星期五 08:26:51 UTC arm
ERROR: [0x0] TEE-CORE:platform_standby_fdt_parse:126: no pmu node
ERROR: [0x0] TEE-CORE:sunxi_twi_parse_from_dt:84: no pmu node
U-Boot 2018.05 (Mar 08 2021 - 23:23:22 +0800) Allwinner Technology
[00.272]DRAM: 64 MiB
[00.275]Relocation Offset is: f9f94000
[00.287]secure enable bit: 0
[00.289]CPU=816 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz MBus=132Mhz
[00.295]gic: sec monitor mode
[00.298]flash init start
[00.300]workmode = 0,storage type = 3
SF: Detected gd25q64 with page size 256 Bytes, erase size 4 KiB, total 8 MiB
[00.317]sunxi flash init ok
[00.320]Loading Environment from SUNXI_FLASH... start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x3e00, len: 0x100
OK
[00.381]try sprite_led_gpio config
xxxxxxxxxxxxxxlijun uboot xiaoyiledinit
[00.388]sprite_led_gpio start
00.391update dtb dram start
[00.396]update dtb dram end
[00.398]update dts
root_partition is rootfs
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
set root to /dev/mtdblock2
[00.461]update part info
[00.463]update bootcmd
mmc driver ver uboot2018:2019-8-15 16:34:00
get mem for descripter OK !
[00.476]get sdc_wipe fail.
[00.478]get sdc0 sdc_erase fail.
[00.481]get sdc0 sdc_boot fail.
[00.484]get sdc0 sdc_odly_50M fail.
[00.487]get sdc0 sdc_sdly_50M fail.
[00.490]get sdc0 sdc_odly_50M_ddr fail.
[00.494]get sdc0 sdc_sdly_50M_ddr fail.
[00.497]get sdc0 sdc_freq fail.
[00.500]get sdc0 sdc_b0p fail.
[00.503]get card0_boot_para:sdc_ex_dly_used fail
[00.508]get card-pwr-gpios handler:1119307360
[00.512]get card0_boot_para:time_pwroff:200ms
[00.517]Using default timing para
[00.720]init mmc 0 clock and io
devnum 0, prv 43fbd42c, bdesc 42b74844
SUNXI SD/MMC: 0
[00.728]==================== work mode: 0 0, sample_mode:0
[00.733]=============== start mmc_init_boot...
card_caps:0x3000000a
host_caps:0x3000003f
[00.800]unable to read ssr
[00.802]unable to read ssr
[00.806]the mode SD Legacy (freq : 25 MHz)
check_file [/one_h60ga.bin] exsit
check_file [/one_h60ga.bin] exsit
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:boot start_offset:0x20 part_size:1900544
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:rootfs start_offset:0xea0 part_size:1179648
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:home start_offset:0x17a0 part_size:3407872
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:backup start_offset:0x31a0 part_size:1245184
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
part_name:env start_offset:0x3b20 part_size:131072
Nothing updated, start normal boot
Hit ctrl + q to stop autoboot: 0
start: 0x2e0, len: 0x1
start: 0x2e1, len: 0x1
start: 0x2e2, len: 0x2
[01.933]partinfo: name boot, start 0x20, size 0xe80
start: 0x300, len: 0x40
start: 0x340, len: 0xe10
[02.410]android.hardware = sun8iw19p1
Booting kernel from Legacy Image at 45000000 ...
Image Name: ARM OpenWrt Linux-4.9.118
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1875896 Bytes = 1.8 MiB
Load Address: 40008000
Entry Point: 40008000
[02.476]Starting kernel ...
Any suggestions what is causing the bricking of the cam and why the hack cannot be applied to it?
The text was updated successfully, but these errors were encountered: