Closed kyutov closed 1 year ago
ghost
commented
3 years ago You might try control-q at the start to stop the auto boot and enter
setenv loglevel 8
setenv console ttyS0,115200
run bootcmd
at the => prompt to get more detail and you might need to do it more than once if the hack resets the camera.
kyutov
commented
3 years ago @0-Al , thanks for your answer.
Here is the detailed log from Putty: putty.log
Does it helps to determine what is causing the failure of the hack?
ghost
commented
3 years ago 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.
roleoroleo
commented
3 years ago 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. Some programs like winrar change the newline from linux to windows: https://stackoverflow.com/questions/1552749/difference-between-cr-lf-lf-and-cr-line-break-types
kyutov
commented
3 years ago @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 :slightly_frowning_face:
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:
############## Starting Hack ##############
############## Starting Hack ##############
############## Starting Hack ##############
############## Starting Hack ##############
### Hacking
Applying hack
### Updating /backup/init.sh
cp: write error: No space left on device
chmod: /backup/init.sh: No space left on device
### Updating /backup/tools/wifidhcp.sh
cp: can't open '/backup/tools/wifidhcp.sh': No space left on device
chmod: /backup/tools/wifidhcp.sh: No such file or directory
### Disabling hack for next reboot
starting pid 644, 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 667, tty '': '/sbin/swapoff -a'
starting pid 668, tty '': '/bin/umount -a -r'
umount: devtmpfs busy - remounted read-only
The system is going down NOW!
Sent SIGTERM to all processes
Sen[ 13.968584] sunxi-mmc sdc0: sdc set ios:clk 0Hz bm PP pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 14.197228] [alarmtimer] have no shutdown alarm! alarmtimer_shutdown 322
[ 14.210606] reboot: Restarting system
[ 14.219060]
[ 14.220736] Restarting Linux version 4.9.118 (yuxibo@dell-PowerEdge-R740) (gcc version 6.4.1 (OpenWrt/Linaro GCC 6.4-2017.11 2017-11) ) #166 PREEMPT Mon Mar 8 15:24:37 UTC 2021Any suggestions where the problem can be?
ghost
commented
3 years ago 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: Well it seems to me only 4k (one erase block?) is free with 64k reserved (16 erase blocks). Could be wrong though, I'm not a Linux guy. I can copy over both files to Jan version mounted on a PC but after init.sh copy on Aug version wifidhcp.sh copy fails however the Aug version does have a little extra due to upgrade and Wifi info. Perhaps reducing init.sh might help some, should be able to reduce it to less than 4k uncompressed from 10k+ but better check with roleo as there may be other issues.
roleoroleo
commented
3 years ago backup partition runs with very little free space. And jffs2 is not reliable in this state. The space seems to be there but when you go to use it it doesn't work...
When "No space left on device" happens it's very hard to recover the partition without rewrite it completely. In this case you need to use the unbricking guide in the wiki and restore the whole partition (only packup partition).
Or, I could create a "hack like" procedure that rewrites the partition without the need of a serial adapter.
kyutov
commented
3 years ago 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.
roleoroleo
commented
3 years ago 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. After a partition restore, the hack should work without errors. I thuink that "No space left on device" problem appears when you runs hack, unhack and hack again.
ghost
commented
3 years ago This could be a solution. But I think it's not necessary. After a partition restore, the hack should work without errors. I thuink that "No space left on device" problem appears when you runs hack, unhack and hack again.
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.
### Hacking
Applying hack
### Updating /backup/init.sh
chmod: /backup/init.sh: No space left on device
### Updating /backup/tools/wifidhcp.sh
cp: can't open '/backup/tools/wifidhcp.sh': No space left on device
chmod: /backup/tools/wifidhcp.sh: No such file or directory
### Disabling hack for next reboot
XXX snip XXX
============================================= home low_half_init.sh... =========================================
============================================= begin to start app... =========================================
mount: mounting /backup/tools/wifidhcp.sh on /home/app/script/wifidhcp.sh failed: No such file or directory
chmod: /tmp/sd/debug.sh: No such file or directory
sh: can't open '/tmp/sd/debug.shPartial Yi-Hack log on Aug firmware, no previous Yi-Hack but using a smaller init.sh hack file as suggested
### Hacking
Applying hack
### Updating /backup/init.sh
### Updating /backup/tools/wifidhcp.sh
### Disabling hack for next reboot
============================================= home low_half_init.sh... =========================================
============================================= begin to start app... =========================================
chmod: /tmp/sd/debug.sh: No such file or directory
sh: can't open '/tmp/sd/debug.sh'A lot of stuff in that file that's not pertinent to the h60ga. The results of using ~3.2k file vs 10k+
ls -la /backup
drwxr-xr-x 6 root root 0 Jan 1 1970 .
drwxrwxr-x 15 root root 209 Jan 12 2021 ..
-rwxr-xr-x 1 root root 364 Jan 1 1970 back.bin
-rwxr-xr-x 1 root root 3211 Jan 1 1970 init.sh
drwxrwxr-x 2 root root 0 Jan 20 2021 isp
drwxrwxr-x 2 root root 0 Jan 20 2021 ko
-rwxrwxr-x 1 root root 1513 Jan 20 2021 lower_half_init.sh
drwxrwxr-x 2 root root 0 Jan 1 1970 tools
-rw-r--r-- 1 root root 448 Oct 1 2021 upgrade_conf
-rwxr-xr-x 1 root root 102 Oct 1 2021 wpa_supplicant.conf
ls -la /backup/tools
drwxrwxr-x 2 root root 0 Jan 1 1970 .
drwxr-xr-x 6 root root 0 Jan 1 1970 ..
-rwxrwxr-x 1 root root 4755 Jan 20 2021 default.script
-rwxrwxr-x 1 root root 65 Jan 20 2021 ethdhcp.sh
-rwxrwxr-x 1 root root 1818 Jan 20 2021 extpkg.sh
-rwxrwxr-x 1 root root 103 Jan 20 2021 mem_update_pack.sh
-rwxrwxr-x 1 root root 366284 Jan 20 2021 rsa_pub_dec
-rwxrwxr-x 1 root root 639 Jan 20 2021 set_wifi.sh
-rwxrwxr-x 1 root root 657 Jan 20 2021 update_homefs.sh
-rwxrwxr-x 1 root root 5567 Jan 20 2021 upgrade.sh
-rwxrwxr-x 1 root root 9668 Jan 20 2021 upgrade_firmware
-rwxrwxr-x 1 root root 238 Jan 20 2021 wificonnect.sh
-rwxr-xr-x 1 root root 190 Jan 1 1970 wifidhcp.sh
-rwxrwxr-x 1 root root 121 Jan 20 2021 wifitest.sh
-rwxrwxr-x 1 root root 613112 Jan 20 2021 wpa_supplicantThe 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.
roleoroleo
commented
3 years ago @0-Al Thank for thes information, very useful.
I will add 3 tasks to the todo list:
roleoroleo
commented
3 years ago @0-Al Did you try to use 8KiB erase size? Could you share a backup of the new firmware version? mtdblock4 is enough. And which version number is?
kyutov
commented
3 years ago @0-Al , thank you for your assistance! I have tried to reduce the size of the init.sh file by removing the unnecessary code (not related to h60ga). With the modified file I was able to successfully apply the hack 🙂
The cam works, the hack is applied (I can access the web interface), but I have noticed that the cam is very unstable - it often restarts and sometimes enters in restart loops. I didn't have time to analyze the Putty logs and see if there are obvious reasons for the restarts, but I will do it and will report back. I don't exclude the possibility that the restarts may be caused but unproperly edited init.sh file.
roleoroleo
commented
3 years ago The cam works, the hack is applied (I can access the web interface), but I have noticed that the cam is very unstable - it often restarts and sometimes enters in restart loops.
Try to enable swap space. When the cam tries to take a snapshot, memory is not enough.
ghost
commented
3 years ago @0-Al Did you try to use 8KiB erase size?
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.
Could you share a backup of the new firmware version? mtdblock4 is enough. And which version number is?
You have it already, 9.0.27.20_202108161046 downloaded from @Rocket200 https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/247#issuecomment-922515349 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.
roleoroleo
commented
3 years ago I'm not completely sure but I think update only contains home partition. If you download the file http://download.eu.xiaoyi.com/yifirmware/smarthomecam/familymonitor-h60ga/9.0.27.20_202108161046home_h60gam and decrypt it as described in extpkg.sh, you will only find the home partition. And I think there is no 9.0.27.20_202108161046backup_h60gam file.
Comparing the files posted by Rocket200, they differ only in the presence of upgrade.conf and wpa_supplicant.conf All other files are the same.
So, probably these 2 files are added at runtime by a running process and not added by the update.
ghost
commented
3 years ago I'm not completely sure but I think update only contains home partition.
I already said this at the end of https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/270#issuecomment-939679599
And I think there is no 9.0.27.20_202108161046backup_h60gam file.
I can only assume I have confused you, sorry, I am not so good with explaining.
So, probably these 2 files are added at runtime by a running process and not added by the update.
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.
roleoroleo
commented
3 years ago I already said this at the end of #270 (comment)
Sorry I didn't understand what you meant.
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.
I removed wifidhcp.sh from the hack to avoid unnecessary writes to the flash: https://github.com/roleoroleo/yi-hack-Allwinner-v2/commit/b984c1fc6548edd2da00d434fdf4db824b6a247e And I created a new unbrick procedure to restore the whole backup partition. @0-Al @kyutov Could you help me with a smaller version of init.sh?
ghost
commented
3 years ago Please remember I'm new to this so mistakes are likely.
But I think you meant help for testing your version :grin:
roleoroleo
commented
3 years ago But I think you meant help for testing your version 😁
Both, the content of the file and the test. Thanks.
kyutov
commented
3 years ago #!/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 fi
I would remove the following line enable_4g= as well, other than that it looks pretty much the same as my version.
@roleoroleo - let me know how I can help you with the tests
roleoroleo
commented
3 years ago I will prepare a kit...
roleoroleo
commented
3 years ago Here it is. This is the unbrick procedure. Use it like a normal hack by copying the Factory folder to your sd card. unbrick_h60ga.tar.gz This will restore the backup partition (mtdblock4) with an already hacked version. The only difference is the init.sh file but it's fully compatible with the original one.
This is a new version of the hack: h60ga_0.1.9.tar.gz If init.sh has not already been hacked this procedure changes it. Otherwise it doesn't change your cam, just boots the hacked firmware.
I removed the changes to wifidhcp.sh
ghost
commented
3 years ago 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.
roleoroleo
commented
3 years ago Many backups I have received contain a zero-filled back.bin. And my working camera y21ga also contains a zero-filled back.bin I think it depends on the model but I don't know if the cam restores it after removing.
ghost
commented
3 years ago ============================================= begin to start app... =========================================
############## Starting Unbrick ##############
############## Starting Unbrick ##############
############## Starting Unbrick ##############
############## Starting Unbrick ##############
### Unbricking
/tmp/sd/Factory/config.sh: .: line 9: can't open '/tmp/sd/yi-hack/script/env.sh'Stops dead at that line, is it supposed to be there or is yi-hack folder needed too?
roleoroleo
commented
3 years ago It's only the environment. Please, try to remove the line and check if it works.
ghost
commented
3 years ago roleoroleo
commented
3 years ago Wow. A disaster... I will check it.
ghost
commented
3 years ago No, not a disaster. The backup was replaced and I went ahead with the hack version but wasn't able to connect to the camera after that either by Yi-Hack or Yi app. Restoring the original backup didn't help but restoring conf did so I'll take another look tomorrow.
roleoroleo
commented
3 years ago The problem is:
umount: can't unmount /backup: Resource busy
Maybe there is a typo in the kill of wpa_supplicant.
ghost
commented
3 years ago Maybe there is a typo in the kill of wpa_supplicant.
Or maybe it doesn't exist yet?
Camera reset on hr snapshot. Swap set, saved and rebooted but not created, no swap file on /tmp/sd.
roleoroleo
commented
2 years ago Or maybe it doesn't exist yet?
Maybe. About umount I found the problem. /backup/init.sh is still running so /backup is busy. The lazy umount is a good idea.
Camera reset on hr snapshot. Swap set, saved and rebooted but not created, no swap file on /tmp/sd.
Yes, a new bug.
Change this line in system.sh
SD_PRESENT=$(mount | grep mmc | grep -c ^)
with
SD_PRESENT=$(mount | grep mmc | grep "/tmp/sd " | grep -c ^)
It should work.
With the sequence you posted above, is the cam ok? Running and hacked?
EDIT
With my y21ga it works. What about back.bin?
ghost
commented
2 years ago After the SD_PRESENT mod it has started intermittently rebooting not sure why, could be coincidence. Will have to check further.
back.bin gets replaced on reboot if removed or added if not part of the jffs2 but the new one also contains ID data as well as hw and gpio settings. Don't now if the original was meant to be just default hw and gpio settings or not. The new one seems to be the first bytes of the mfg partition or maybe it's where it's also in conf partition, idk, would have to modify one set of data to know.
Edit: Looks like a problem with the SD card or corrupt file. 64GB FAT32 out and freshly formatted FAT32 32GB with hack files and modified script in. Will leave it running awhile and see what happens.
Left overnight and no reboots. Before it would only go a few minutes at most before rebooting and often several reboots at a time. Appears to be working as expected, haven't used mqtt though so cant comment on that.
roleoroleo
commented
2 years ago This is the last version of the unbrick procedure, if you want to test it. unbrick_h60ga.tar.gz
I will release it asap.
kyutov
commented
2 years ago I have bricked my cam and after that I have tried to unbrick it with the above files but unfortunately when the cam is bricked, the unbrick procedure doesn't start at all (I'm not able to see any evidences of the unbricking in the logs and the Factory folder name doesn't change to Factory.done). I have manually unbricked the can (by following the current unbrick procedure) and after the restart, the unbrick procedure has started and was executed successfully. Unfortunately after the unbrick, the cam has entered in reboot loops.
I have noticed that when I enter the commands, which was posted above in the thread:
setenv loglevel 8
setenv console ttyS0,115200
run bootcmdthe cam doesn't enter in reboot loops and is fully functional, but I cannot find out what is causing the reboot loops. The same happened when I tried to execute the hack with my lighter version of the init.sh file.
roleoroleo
commented
2 years ago I have bricked my cam and after that I have tried to unbrick it with the above files but unfortunately when the cam is bricked, the unbrick procedure doesn't start at al
This is normal. The unbrick file above is a 1st level unbrick procedure and it works only if /backup/init.sh is ok.
If your init.sh is this https://github.com/roleoroleo/yi-hack-Allwinner-v2/issues/270#issuecomment-942224773 please check near line 100. I think there is a difference with the original init.sh.
kyutov
commented
2 years ago I have bricked my cam and after that I have tried to unbrick it with the above files but unfortunately when the cam is bricked, the unbrick procedure doesn't start at al
This is normal. The unbrick file above is a 1st level unbrick procedure and it works only if /backup/init.sh is ok.
If your init.sh is this #270 (comment) please check near line 100. I think there is a difference with the original init.sh.
I'm afraid that the during the hack procedure, the init.sh file is actually modified, which prevents the unbrick procedure from start.
I have prepared some Putty logs by doing the following:
1) I have started with fully functional cam (without hack). I have executed the hack (the the latest release from the repo - 0.1.9, without making any modifications to the init.sh file in it) and I have bricked the cam.
Here is the logs, which shows the problem with the hack execution and the reason for the bricking - putty_hack.log
2) I have replaced the content of the SD with the content of the unbrick_h60ga.tar.gz file from above.
Here is the log, which shows that the unbrick procedure is not starting - putty_unbrick.log
roleoroleo
commented
2 years ago Yes, the problem is clear:
############## Starting Hack ##############
############## Starting Hack ##############
############## Starting Hack ##############
############## Starting Hack ##############
### Hacking
Applying hack
### Updating /backup/init.sh
cp: write error: No space left on device
chmod: /backup/init.sh: No space left on device
### Updating /backup/tools/wifidhcp.sh
cp: can't open '/backup/tools/wifidhcp.sh': No space left on device
chmod: /backup/tools/wifidhcp.sh: No such file or directory
### Disabling hack for next rebootWhen the hack tries to copy the new init.sh, backup partition is full. The new file is corrupted and the cam doesn't start anymore. In this case you need to use the unbrick procedure with the serial interface to recover the cam.
And I need to find another way to hack the cam...
roleoroleo
commented
2 years ago @kyutov I compared the backup partition of the h60ga with the other models and I can't understand the problem. The raw size is the same (0x130000) and the unused space is bigger. Why does y21ga work and h60ga not?
Could you share your dump?
kyutov
commented
2 years ago Sure, let me know exactly what you need. All the backup files from my cam?
roleoroleo
commented
2 years ago Backup partition is enough, thanks. mtd4
kyutov
commented
2 years ago Here you are: LINK REMOVED
roleoroleo
commented
2 years ago The problem is that the h60ga writes (runtime) on the backup partition 2 files:
and wastes all available space.
kyutov
commented
2 years ago What about the idea, which I mentioned above - to "inject" the hacked files into the backup partition (mtd4) and put that modified backup partition into the cam by following the existing unbrick procedure (via the serial interface) ?
roleoroleo
commented
2 years ago I already prepared a new hack procedure that writes the whole partition. It doesn't copy the file but rewrites the mtd with a dd. I will release asap.
EDIT
If you want to test it (it requires a new device) I can share it with you.
kyutov
commented
2 years ago Sure, if I can, I will assist you with the testing. What new device is required?
roleoroleo
commented
2 years ago Sure, if I can, I will assist you with the testing. What new device is required?
I mean that this procedure does not allow you to restore a bricked cam. It runs only with a working device or a new device. I'll send it to you tonight.
roleoroleo
commented
2 years ago Here it is: LINK REMOVED (ARCHIVE CORRUPTED)
kyutov
commented
2 years ago I have tested it, but the result is not positive.
I think that the hack wasn't applied successfully since I'm seeing the following logs:
============================================= begin to start app... =========================================
############## Starting Unbrick ##############
############## Starting Unbrick ##############
############## Starting Unbrick ##############
############## Starting Unbrick ##############
### Unbricking
dd: writing '/dev/mtdblock4': No space left on device
1217+0 records in
1216+0 records out
1245184 bytes (1.2MB) copied, 12.719449 seconds, 95.6KB/s
### Disabling for next rebootAfter applying the hack, the cam starts, but I cannot connect to it via the Yi App and it doesn't seems to connect to my home network. I have examined the logs and I'm seeing the following logs repeating every second or so:
dispatch.c(do_monitor_wifi-3197)[11:11:17.020]:wifi disconnected, now reconnect wifi
cat: can't open '/proc/timeout_cnt': No such file or directory
ash: 100: unknown operand
ash: 0: unknown operand
killall: hostapd: no process killed
killall: udhcpd: no process killed
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
killall: wpa_supplicant: no process killed
killall: udhcpc: no process killed
killall: p2p_tnp: no process killed
killall: cloud: no process killed
ash: 1: unknown operand
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
watch_process.c(check_watch_info-171)[11:11:17.815]:cloud crashed!
watch_process.c(check_watch_info-171)[11:11:17.815]:p2p_tnp crashed!
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
/home/app/script/wificonnect.sh: line 4: /backup/tools/wpa_supplicant: not found
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() gettime ptz_x_runtime(+ 0 = 16),ptz_y_runtime(+ 0 = 7)
[H60GA_PTZ]p_ptz() selfcheck duration ptz_x_runtime(16 = 16 - 0),ptz_y_runtime(7 = 7 - 0)
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
[H60GA_PTZ]p_ptz() ptz_funtion=0,ptz_function=0,ptz_isruning=0,p2p_viewing_cnt=0
Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directoryHere is the full Putty log (which starts with the hack procedure): putty.log
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?