During the implementation of the Vuplus multiboot I studied how the other OEM's implemented the multiboot on hisilicon platform.
So I dumped the partition of my sf8008 with dd command and looked at the content with a hex viewer.
So there is a boot partition, a bootargs partition, a kernel partition (recovery), the logo partition, and a couple of other partitions.
Using binwalk I uncompressed the recovery partition to look at it deeper... it is a kernel with linked a small compressed ramfs with a custom developed recovery program.
The boot partition instead contains some initialisation logic and the code that read the bootargs partition and dynamically read the boot options from STARTUP file.
Someone told me that on linuxsat a guy published a modified recovery to activate the multiboot on Amiko Viper 4k v40.
I was pretty interested in the solution but I didn't trust it so much, so I dissected the implementation.
From the post description it required a different remote so probably the guy took the bootloader and the recovery from a dinobot box and changed some stuff to adapt it for the v40.
But then you need the dinobot remote to use the recovery.
The recovery application can manage up to 2 partitions and after passing it on "ghidra" I compared it with the original recovery and the one extracted from the zgemma/pulse4k/hd61 recovery.
Funny that the recovery for zgemma is able to manage the Viper 4k v40 remote.
But how that guy created the usb_update.bin file?
Easy, he used "https://github.com/oe-alliance/oe-a...o/recipes-bsp/amiko-buildimage/buildimage.zip".
I manually dissected the usb_update... it has a header, then the partitioned data with a crc or something similar...
I carefully constructed the xml by reading the bootargs
So by modifying a few lines of code I was able to reproduce exactly the same binary as the one from that guy...
Since I read that a few guys applied the multiboot recovery and they wanted to rollback, I tried to do the opposite.
To rollback there are two ways, using rs232 and HiTool-stb or using the same procedure as used to add multiboot.
To create the usb_recovery I dumped the flash partitions from my viperv40:
I copied them on my dev pc.
then constructed a new xml...
....and the usb_update_bin is cooked.
Few comments from a conversation with a guy that tested it:
OK I have now fully tested this having found the 'rough' V40...
Great success!
1) Flash usb_update.bin (needs Dinobot remote for this and green button - guess there is no way around this for now, this is only remote code multiboot bootloader knows)
2) usb_update.bin is seen and goes through the usual motions with usual success message at the end and then reboots
3) Box boots up as normal and now BOTH tuners are working again, excellent!
4) Only slight thing I can see if eth0 mac is set to 00:11:AD:01:02:03... I use Network MAC settings to change to original (in my case 00:11:AD:*:*:*) so means first 6 are correct now anyway, just last 6 to change...
5) Make a full reboot at this point just to see all settings including mac etc. stick and sure enough they do, so no real problem here...
6) Both tuners still working etc. full scans made, ABM scan made, check with signal finder just to make sure we have a lock on both tuners, all working!
7) Final test, reflash firmware again direct from USB with green button method at boot to see if Amiko remote is now picked up again, it is! Fully working now, Amiko remote at boot for flashing firmware with green button, standard directory structure (e2/update) and flashing process starts and completes, VERY NICE! Great work, many thanks!
If you don't have the dinobot remote maybe it is possible to emulate it with an android phone with the IR Consumer port. I'll update the thread if and when I will able to locate the right application and the remote code.
If you want to fully restore the mac address and the serial of the box:
Download it and modify it with a hex editor, then upload it again.
So I dumped the partition of my sf8008 with dd command and looked at the content with a hex viewer.
So there is a boot partition, a bootargs partition, a kernel partition (recovery), the logo partition, and a couple of other partitions.
Using binwalk I uncompressed the recovery partition to look at it deeper... it is a kernel with linked a small compressed ramfs with a custom developed recovery program.
The boot partition instead contains some initialisation logic and the code that read the bootargs partition and dynamically read the boot options from STARTUP file.
Someone told me that on linuxsat a guy published a modified recovery to activate the multiboot on Amiko Viper 4k v40.
I was pretty interested in the solution but I didn't trust it so much, so I dissected the implementation.
From the post description it required a different remote so probably the guy took the bootloader and the recovery from a dinobot box and changed some stuff to adapt it for the v40.
But then you need the dinobot remote to use the recovery.
The recovery application can manage up to 2 partitions and after passing it on "ghidra" I compared it with the original recovery and the one extracted from the zgemma/pulse4k/hd61 recovery.
Funny that the recovery for zgemma is able to manage the Viper 4k v40 remote.
But how that guy created the usb_update.bin file?
Easy, he used "https://github.com/oe-alliance/oe-a...o/recipes-bsp/amiko-buildimage/buildimage.zip".
I manually dissected the usb_update... it has a header, then the partitioned data with a crc or something similar...
Code:
diff -u -N -r binew/ modded
diff -u -N -r binew/mkupdate.c modded/mkupdate.c
--- binew/mkupdate.c 2020-04-28 10:34:21.000000000 +0200
+++ modded/mkupdate.c 2023-04-23 00:43:12.510586365 +0200
@@ -30,8 +30,8 @@
#define HIFILE_D_ALIGN_LEN 16
-#define HI_LOADER_PROTOCOL_VER3
-#define HI_IMAGE_FILE_ALIGN_SUPPORT
+#define HI_LOADER_PROTOCOL_VER2
+//#define HI_IMAGE_FILE_ALIGN_SUPPORT
#define HI_WRITE_64BIT(pcByte, Result, Length) \
{ \
Code:
<?xml version="1.0" encoding="GB2312" ?>
<Partition_Info>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="0" Length="1M" SelectFile="usb_update_mmcblk0p1_boot"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="1M" Length="1M" SelectFile="usb_update_mmcblk0p2_bootargs"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="2M" Length="1M" SelectFile="usb_update_mmcblk0p3_bootoptions"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="3M" Length="4M" SelectFile="usb_update_mmcblk0p4_baseparams"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="7M" Length="4M" SelectFile="usb_update_mmcblk0p5_pqparam"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="11M" Length="4M" SelectFile="usb_update_mmcblk0p6_logo"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="19M" Length="32M" SelectFile="usb_update_mmcblk0p8_loader"/>
</Partition_Info>
Code:
make
./mkupdate -s 00000003-00000001-01010101 -f ./emmc_partitions.xml -d ./usb_update.bin
Since I read that a few guys applied the multiboot recovery and they wanted to rollback, I tried to do the opposite.
To rollback there are two ways, using rs232 and HiTool-stb or using the same procedure as used to add multiboot.
To create the usb_recovery I dumped the flash partitions from my viperv40:
Code:
dd if=/dev/block/by-name/.... of=/tmp/partitionname
then constructed a new xml...
Code:
<?xml version="1.0" encoding="GB2312" ?>
<Partition_Info>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="0" Length="1M" SelectFile="mmcblk0p1_boot_1M"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="1M" Length="1M" SelectFile="mmcblk0p2_bootargs_1M"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="2M" Length="4M" SelectFile="mmcblk0p3_baseparam_4M"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="6M" Length="4M" SelectFile="pqparam"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="10M" Length="4M" SelectFile="logo-viper4kv40.img"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="14M" Length="4M" SelectFile="deviceinfo"/>
<Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="18M" Length="32M" SelectFile="loader"/>
</Partition_Info>
Code:
./mkupdate -s 00000003-00000001-01010101 -f ./emmc_partitions.xml -d ./usb_update.bin
....and the usb_update_bin is cooked.
Few comments from a conversation with a guy that tested it:
OK I have now fully tested this having found the 'rough' V40...
Great success!
1) Flash usb_update.bin (needs Dinobot remote for this and green button - guess there is no way around this for now, this is only remote code multiboot bootloader knows)
2) usb_update.bin is seen and goes through the usual motions with usual success message at the end and then reboots
3) Box boots up as normal and now BOTH tuners are working again, excellent!
4) Only slight thing I can see if eth0 mac is set to 00:11:AD:01:02:03... I use Network MAC settings to change to original (in my case 00:11:AD:*:*:*) so means first 6 are correct now anyway, just last 6 to change...
5) Make a full reboot at this point just to see all settings including mac etc. stick and sure enough they do, so no real problem here...
6) Both tuners still working etc. full scans made, ABM scan made, check with signal finder just to make sure we have a lock on both tuners, all working!
7) Final test, reflash firmware again direct from USB with green button method at boot to see if Amiko remote is now picked up again, it is! Fully working now, Amiko remote at boot for flashing firmware with green button, standard directory structure (e2/update) and flashing process starts and completes, VERY NICE! Great work, many thanks!
If you don't have the dinobot remote maybe it is possible to emulate it with an android phone with the IR Consumer port. I'll update the thread if and when I will able to locate the right application and the remote code.
If you want to fully restore the mac address and the serial of the box:
Code:
dd if=/dev/block/by-name/bootargs of=/tmp/bootargs.bin
Download it and modify it with a hex editor, then upload it again.
Code:
dd if=/tmp/bootargs.bin of=/dev/block/by-name/bootargs