Restore the original bootloader on Amiko Viper 4k v40

Liquid

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

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 !!!
 
MihaiP said:
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 !!!
Click to expand...
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)
 
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 !
 
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 ?

 
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.
 
Can this procedure be done in a v40 without multiboot? The only step I think is not needed is the Dinobot remote part, since the bootloader recognizes the Amiko RC.
 
tmac said:
Can this procedure be done in a v40 without multiboot? The only step I think is not needed is the Dinobot remote part, since the bootloader recognizes the Amiko RC.
Click to expand...
Yes, but why you should want to restore the same bootloader you should already have?

Avoid playing with bootloaders if not strictly needed
 
Liquid said:
Yes, but why you should want to restore the same bootloader you should already have?

Avoid playing with bootloaders if not strictly needed
Click to expand...
Well I am having a problem with the sat tuner, it doesn't get any signal even with the simplest configuration, used other box on the same setup and no problem, so I thought it could be something disabled at the bootloader level.
Just got it and the previous owner only used C/T2 tuner, don't know if he got the box configured to have S2 tuner disabled or something.
 
Hi @Liquid ! can I have "deviceinfo" you are using ?

&lt;Part Sel="1" PartitionName="" FlashType="emmc" FileSystem="none" Start="14M" Length="4M" SelectFile="deviceinfo"/&gt;
 
Well solved !
I've connected Viper V40 via HiTool and downloaded the image using a
similar XML partition table ! then using the same HiTool I've built
usb_update.bin ! Both are working !
 
You must log in or register to reply here.
Back
Top