Restore the original bootloader on Amiko Viper 4k v40

Liquid

Staff member
Administrator
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...

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)   \
     {                                           \
I carefully constructed the xml by reading the bootargs
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
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:
Code:
dd if=/dev/block/by-name/.... of=/tmp/partitionname
I copied them on my dev pc.

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
 

Attachments

  • viper4k_v40_usb_update.zip
    7.8 MB · Views: 29

MihaiP

New member
First of all ... congratulations ! if I had your posting the life should be easier !!!
Now is history ... basically by my mistake ... I've should copy by "dd" a longer
portion of the other STB ... what was in my mind ?

A question ! what if , at the time I've been used the recovery image from
GB Trio 4K ? of course ... after reboot he will not understand the RC !
but ... for the rest ? I have both RC's ... Amiko and Dinobot as well !!!
 

Liquid

Staff member
Administrator
A question ! what if , at the time I've been used the recovery image from
GB Trio 4K ? of course ... after reboot he will not understand the RC !
but ... for the rest ? I have both RC's ... Amiko and Dinobot as well !!!
All these boxes come from the same application notes, so basically you can use a bootloader and a kernel from another vendor and the box should boot...(the ram amount of the donator box should be less or the same lake the running box). But the application note let the OEM small variation.. if the running box uses different tuner combination WiFi, etc this hardware coundn't work. (Indeed on multiboot mod for V40 the DVB-t tuner stopped to work)
 

MihaiP

New member
Thanks ! at the time when Dinobot changed the dvbt2/c drivers
I've tested for them on a V30 the changes ! they enabled DVB-T !
who need that ? and broke the DVB-C ! but I have a usb_update.bin
for V30 witch was OK ! except he does not recreate the original
partitions map !
 

MihaiP

New member
What you need to remake your usb_update.bin for Amiko Viper 4K V30 ?
I could make further test om the Guy multiboot in a safer way !!!
Eventually replacing fastboot with the one from Zgemma witch
understands Amiko RC. A EMMC dump from V30 will help ?

 

MihaiP

New member
BTW ... I've tried on Zgemma H9S SE ... enters into Boot Menu
if I press any button on Amiko RC ... but for the rest needs the
original RC ! Closest Zgemma Multiboot seem to be the one from
Zgema H9 Combo ... also have 8 Gb Flash as Amiko V30.
 
Top