[S905L] Xiaomi Mi Box 4 Community Builds

    Hello guys,

    Recently, I extracted and ported the DTS for the Mi Box 4 (MDZ-21-AA) from the stock image, adding support for the internal Wi-Fi module.

    Some kernel patches are also required for the Wi-Fi driver. By default, the driver reads the MAC address from the Wi-Fi chip's eFuse, while on the Mi Box 4 the MAC address is actually stored in the SoC's eFuse.

    The images, guides, and patches have all been uploaded to GitHub:

    GitHub - Raspberry-Monster/MiBox4-LibreELEC
    Contribute to Raspberry-Monster/MiBox4-LibreELEC development by creating an account on GitHub.
    github.com

    Feel free to ask questions or point out any issues.

    I'm still learning, so any feedback is welcome. I'll try my best to help.

    Have a good day!

    raspberry_kan If intending to upstream the device-tree to the kernel:

    * Drop most of the comments from the dts; discussion should be done in a cover-letter or commit description, not code

    * Commits need a 'Signed-off-by' with a real name/email

    * You need to update bindings with information too; learn to run a bindings check against the dts to find errors

    Please note that emmctool support is intentionally for devices that have upstream u-boot support. I'm not inclined to accept any changes that manipulate vendor boot code; there are too many opportunities for 'bricking' devices.

    @chewitt

    I see. So, if the goal is to eventually add Mi Box 4 support to the official LibreELEC builds and upstream the relevant changes, there are several things that need to be done first.

    The device tree and the rtw88 patches should go through the proper Linux upstream process, including following the kernel commit requirements and running the relevant DT binding/schema checks.

    For emmctool support, the device would also need proper upstream U-Boot support rather than relying on modifications to the vendor bootloader, so that installing LibreELEC to the internal eMMC can be done through a supported boot chain.

    Did I understand this correctly?

    Anyway, thank you very much for the advice. Have a great day!

    As a general rule we have no problem picking patches submitted to mailing lists into LE kernels as there's a visible commitment to upstream things and we'll be able to drop patches in future kernel bumps. This is all good and normal.

    For boot things, proper u-boot support would be desirable. If the box has a signed bootloader? then that becomes difficult, but I'd look to solve those kind of packaging issues via amlogic-boot-fip and projects/Amlogic/bootloader/{install,release,mkimage} scripts than do on-box assembly with emmctool. I have no knowledge of these boxes though. I did see there's no SD card interface so I guess you are booting from a USB stick?

    Yes. The current setup boots from a USB drive. I found the information that allowed me to boot from external drives through adb shell reboot update on a TV box enthusiast forum, in a post about the Mi Box 4C.

    However, if I want it to boot more like a normal SBC, there are still some patches and bootloader work to be done. In particular, the replacement U-Boot is not compatible with the vendor boot chain, so at the moment an autoscript is needed to boot from USB. Interestingly, if the goal is to install LibreELEC to the internal eMMC, the new boot chain seems to work fine.

    As soon as I managed to boot into LibreELEC, I made a full backup image of the stock Android installation.

    Secure Boot is not enabled by default, which seems to be good news for loading an external U-Boot. Codex has already helped me extract the FIP from the full disk image, and I am now working on implementing U-Boot with its help.

    There are still a few glitches that need to be resolved, though. The most important one is the cold-boot behavior: some hardware, including Wi-Fi and USB, does not power up as expected.

    I'm still working on it. :)

    Hello chewitt ,

    I'm very happy to report that the custom U-Boot built with LibreELEC's amlogic-boot-fip has successfully booted on the Mi Box 4.

    After replacing the stock U-Boot, it seems that we can boot pretty much any system we want. We can also "dd" an image directly to the eMMC.

    However, when using the stock FIP, we still need an autoscript to boot the system before replacing the stock U-Boot.

    Most features are working fine, including Wi-Fi, hardware video decoding, HDMI, and CEC. I haven't been able to test the analog AV port since I don't have the necessary equipment. Bluetooth is also currently unavailable because the required firmware is missing from linux-firmware.

    Meanwhile, I've backported a change from the upstream LTS kernel that allows the MAC address to be read from the SoC's eFuse.

    I'll post more updates as soon as I make further progress.

    The workflow that's documented in the wiki is for users to boot from the "box" image (which contains autoscript files that should hook vendor u-boot) then download a device-specific image to eMMC to /storage and write using emmctool. It's also possible to create a combined .img file that has mainline u-boot + extlinux + autoscript boot files to handle users who see 'mibox4' in the image filename and attempt to use that first. It works because vendor u-boot ignores the extlinux files and mainline u-boot ignores the autoscript files. The combined .img type is what the buildsystem creates by default when the amlogic-boot-fip device name e.g. 'mibox4' falls-through the case statement in projects/Amlogic/bootloader/mkimage. Does the "box" image boot from USB once a device-tree dtb has been added to the /amlogic folder?

    For testing you can add WiFi/BT firmware locally https://wiki.libreelec.tv/how-to/add-firmware - You can also hack files into the image using projects/Amlogic/filesystem/usr/lib/firmware/xxx - not something I'll accept in our main repo but fine to save effort during development.

    NB: It would be easier to review things if you cloned https://github.com/LibreELEC/LibreELEC.tv and pushed a topic branch with the changes. Same for https://github.com/torvalds/linux and https://github.com/u-boot/u-boot respectively.

    Hi chewitt ,

    I have organized the repositories and am now working on upstreaming the changes. The current work has been split across the following repositories:

    GitHub - Raspberry-Monster/linux: Linux kernel source tree
    Linux kernel source tree. Contribute to Raspberry-Monster/linux development by creating an account on GitHub.
    github.com
    GitHub - Raspberry-Monster/amlogic-boot-fip: Firmware Image Package (FIP) sources to sign Amlogic u-boot binaries in LibreELEC, Armbian and meta-meson
    Firmware Image Package (FIP) sources to sign Amlogic u-boot binaries in LibreELEC, Armbian and meta-meson - Raspberry-Monster/amlogic-boot-fip
    github.com
    GitHub - Raspberry-Monster/LibreELEC.tv: Just enough OS for KODI
    Just enough OS for KODI. Contribute to Raspberry-Monster/LibreELEC.tv development by creating an account on GitHub.
    github.com
    GitHub - Raspberry-Monster/u-boot: "Das U-Boot" Source Tree
    "Das U-Boot" Source Tree. Contribute to Raspberry-Monster/u-boot development by creating an account on GitHub.
    github.com

    Specifically, in the Linux repository:

    • rtw88-dt-mac contains the rtw88 patches that allow the driver to read the MAC address from nvmem.
    • mibox4-dt contains the device-tree changes for the Mi Box 4.
    • mibox4-bringup combines both sets of changes to produce a usable kernel for testing.

    Due to the type-system changes, some additional patch is needed to provide the u128 type, for example:

    packages: libbpf: Fix missing u128 type · Raspberry-Monster/LibreELEC.tv@e60ff90
    Signed-off-by: YuChia-Kan <[email protected]>
    github.com

    At the moment, I am working on upstreaming the Linux kernel changes. Once those changes have been merged, I plan to submit the corresponding U-Boot patches upstream as well.

    I hope this organization meets LibreELEC's requirements.

    Thank you again for your patience and guidance!

    It's best to allow a week between iterations of kernel patches unless it's a final 'one last thing..' respin. Maintainers have crazy busy inboxes and work up them in date/time order so it's annoying to spend time reviewing something only to discover there are another three iterations of the same thing on the same day that need to be reviewed, with only minor adjustments in each. Allow time for people to send feedback, then send one next version that incorporates all that feedback. Also, when replying to messages always reply to the comments inline and never top-post as this loses context/conversation threading. The maintainers on the Amlogic list are pretty relaxed folks about such offences, but others can get rather irate about it. The same comments apply to u-boot and most upstream projects where the reviewer/maintainers are also kernel people.

    That said, most people (self included) learn what's acceptable on kernel lists though trial and error, so annoying a few devs and being told off is just a normal rite of passage :)