Is it possible to run libreelec on zidoo h6 pro?

    Zidoo h6 is probably the first allwinner h6 tv box on market. Zidoo abandoned it just half a year later and left many blocking issues in the stock firmware.

    HW is: Allwinner H6 soc, 2gb ram, 16gb emmc, axp805 pmic, ap6255 wifi+bt, rtl8211e gigalan

    Product link: https://www.zidoo.tv/Product/spec/m…FMcQ%3D%3D.html

    Latest stock firmware: http://forum.zidoo.tv/index.php?thre…-release.45219/

    The HW spec looks very much like Beelink GS1, except for the wifi chip.

    Here is picture of circuit board:

    ZIDOO H6 PRO Android 7.0 Allwinner H6 2/16GB AC WiFi Gig Lan BT4 L1 Widevine
    Today something new and little different ZIDOO H6 PRO Android 7.0 Allwinner H6 2/16GB AC WiFi Gig Lan BT4 Has been a long while since we have had a Allwinner…
    forum.xda-developers.com

    The stock firmware update guide indicates it is able to boot from tf card.

    https://www.zidoo.tv/Support/support_guide/guide_target/JT4n%2Bv0V3qHeq7k9e%5Bld%5D3ulg%3D%3D.html

    Quote from jernej

    Then try that image? Zidoo won't gain official support.

    I have had a try, it does not boot from the libreelec tf card.

    Press the reset button at end of AV socket will make it restore factory firmware..

    What's the difference between Libreelec SD creator and phoenixcard?

    They use completely different image format. LE SD creator uses raw image whereas phoenixcard uses proprietary AW format.

    In any case, try to use some other tool to write LE image like Etcher, since some users had issues with LE SD creator.

    Thanks Jernej, I see your post of TX6.

    Since Tanix TX6 can boot from the SD card
    Tanix TX6 is H6 based Android TV Box and it can boot from SD cards prepared with PhoenixCard. It should be possible to make it work with Armbian too, right? I…
    forum.armbian.com

    I think maybe I am facing the same problem. Zidoo H6 is equipped with DDR4 RAM.

    I will have a try to see whether these 4 pads are uart pins when I have time. It looks there is no other test points possible to be uart on this board.

    It turns out Zidoo changed design in 2018...

    Those 2017 pictures are with DDR4 ram, but my "China Version" has DDR3 ram, exactly same chip as Beelink GS1.

    UART is already popped out so I saved some soldering work. BTW, TX/RX are actually reversed.

    This is the uart log:

    Insert LE tf card will get me same uart output and still boot into Android on internal emmc at /dev/block/mmcblk0.

    The LE card is recognized by the stock firmware at /dev/block/mmcblk1. It is not mounted in the console display printed by "df -h", but can be seen in Android file manager.

    I am going to create a card with phoenixcard and see what's the magic there..

    stock firmware image tf card written by phoenixcard will get this boot message:

    It gives "sdc0 spd mode error, 2", then turn to boot from mmc0(tf card) instead of mmc2(emmc).

    @jernej Any clue?

    Edited once, last by permheaddamage: Merged a post created by permheaddamage into this post. (June 23, 2023 at 12:49 PM).

    There is a usb2.0 type a port marked by "USB/OTG" on the box shell.

    By pressing “2” in serial console or pressing the hardware button on the board next to flash chip while power on, it can enter the fel mode.

    With a usb a-c cable to my computer, Windows device manager shows an unknown device "USB\VID_1F3A&PID_EFE8&REV_02;3"

    Studying how to install sunxi-tools to windows..

    maybe I can use my nanopc-t4 with armbian to run sunxi-tools

    Correction, your board uses LPDDR3 RAM, which is slightly different than DDR3. At least enough that you can't interchangeably use images. Fortunately, Beelink GS1 also uses LPDDR3.

    In any case, either there is issue with writing images (did you unzip it before flashing?) or your board is secured and it would need special crafted image. I think you can determine if board is secured via FEL, but I forgot how already. Check linux-sunxi.org for clues.

    What I find today:

    1. sunxi-fel can get this information by "version" command:

    AWUSBFEX soc=00001728(H6) 00000001 ver=0001 44 08 scratchpad=00027e00 00000000 00000000

    "version" command only works once after power on, then board is dead and do not accept any next command. Replug usb will get error saying device is not reporting its id.

    Any other command will put it into same state even when 1st time I run it. Wondering whether this is because I am using windows 11.

    2. Stock firmware TF card has TOC0 header uboot. I built a H6 LE 11.0.1 image and find the u-boot-sunxi-with-spl.bin in build folder(It seems to be tanix tx6 bin because it is compiled last and has overwritten all previous ones). I tried to convert it to TOC0 header using scripts at:

    TOC0 - linux-sunxi.org

    With this Sd card, it stopped booting from emmc and went into fel mode...

    Does this mean zidoo has enabled secure boot in efuse and it is not worthy to dig deeper...

    Well, it still might not be completely secured, but it's up to you if you want to play with it further or not. I don't have any experience with TOC0 booting...

    Last try：

    Built a beelink gs1 image with one line "CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y" attached to uboot config:

    LibreELEC.tv/projects/Allwinner/bootloader/config at master · LibreELEC/LibreELEC.tv
    Just enough OS for KODI. Contribute to LibreELEC/LibreELEC.tv development by creating an account on GitHub.
    github.com

    Plus a patch file to make the TOC0 key item has the same vendor id I extracted from stock fw upgrade tf card.

    Diff
    --- /tools/sunxi_toc0.c    2023-06-26 13:28:52.150080327 +0000
+++ /tools/sunxi_toc0.c    2023-06-26 13:28:25.507170419 +0000
@@ -207,6 +207,7 @@
                 RSA *root_key, RSA *fw_key)
 {
     struct toc0_key_item *key_item = (void *)buf;
+    key_item->vendor_id = 0x00EFE800;
     uint8_t digest[SHA256_DIGEST_LENGTH];
     int ret = EXIT_FAILURE;
     unsigned int sig_len;

    During building it asks for a private key file

    build.LibreELEC-H6.arm-11.0-devel/build/u-boot-2022.10/root_key.pem

    I have to manually generate a RSA key and hope Zidoo left public key empty in efuse.

    The generated image is correctly packed with TOC0 header, and makes the board go into FEL mode...

    So this is a secured board and I give up. Damn.. :cry:

    Thank you jernej

    Another thought: Since that user "petrel-p1" in serial console of stock fw has root previlege, maybe I can compile a Linux executable to play with efuse there.

    If the efuse can be written again, I can write secure boot control bit 0 to disable it.

    Quote from permheaddamage

    Another thought: Since that user "petrel-p1" in serial console of stock fw has root previlege, maybe I can compile a Linux executable to play with efuse there.

    If the efuse can be written again, I can write secure boot control bit 0 to disable it.

    Hi, usually the e-fuse is OTP type ("Electrical Fuse, A one-time programmable memory"), can be write only once. I don't have the documentation of that Allwinner SOC, is not impossible to be in this case is something different, but usually this is the way how the e-fuse works.

    Quote from VLouis

    Hi, usually the e-fuse is OTP type ("Electrical Fuse, A one-time programmable memory"), can be write only once. I don't have the documentation of that Allwinner SOC, is not impossible to be in this case is something different, but usually this is the way how the e-fuse works.

    Tried it. I am not able to access SID in Linux even when I am root. devmem always return 0 for the registers.

    Guess this is expected because OPTEE is designed to act like this..

    There is a key file in root folder but it is a public key and purpose is unknown.

    Code
    petrel-p1:/ $ cat /rsa.pk
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnmf9BzIu+lpk5Kmo3yzh
ZuGGP1pBRmZS1112Q2nEESsdcLlXGKNcAdbWsH+ZAKSXnDecUFJ+kuPvnXUsWNev
QT7vuxEgxBX20wch+CL66RTzMSgtqWy6eO79y2uMVrmv4Kz0tSpzTZs8tVfRvKp4
3wpiofNMxzYjj3X3hWPfSoFpKKWZepbyutla1lveySwhey2Xv6aB7PSXg5xKXGsp
AhE+fuUvBqCfUiit84AGbno5B/oYtgm0/R/7viOeQoooIpBJO3IqRxM1HqVrPepK
OFxA99iybTmJkqatWm8na7ZqTz6/vLYVHVLMNl8/b88KOeLPyVIt3qeM9m7TU8IS
nQIDAQAB
-----END PUBLIC KEY-----