[S905X3] How to correctly compile own DTS

  • Hi.

    I would like to try compile dts for x96 Max Plus (S905X3 with IP1001N ethernet).
    I have dts for it, but I'm still fighting with compilation.
    The box is able to start with meson-sm1-x96-air-gbit.dtb, but without any network.

    I have working build environment and I made first image build without any changes (12.2).
    Now I'm struggling with the dts compilation (I'm pretty new to compiling whole Linux).
    I found steps for coreelec, but it doesn't work with LibreElec: https://discourse.coreelec.org/t/step-by-step…e-files/18792/3

    When I tried to build the dtb manually (using cpp and dtc), even the air-gbit.dtb doesn't work for me (bootlooping, no display output).

    Can you please share right steps to do it? I tried to search online but without success :/

    Thank you

  • Fork my amlogic-6.16.y branch on GitHub then checkout a branch for your change, and then add your device tree file to arch/arm64/boot/dts/amlogic/ with a matching entry in the Makefile. Commit the change to your branch and then generate a patch with “git format-patch HEAD~1” and then rename from 0001-* to 9999-* and copy the patch file to projects/Amlogic/devices/AMLGX/patches/linux/ .. then rebuild the image and it should be compiled. If there are issues compile will fail with line/char references to the first failing problem. Note that you will not be able to just reuse a dts from CE as their kernels are diverged from upstream.

  • Thank you for the reply!

    I see, I will test it out :)

    Yes, I noticed that Coreelec has some custom dtb, but there is also unifreq kernel, which has dts for Max+, so I will try it out.
    I will also try to pull original dtb from the Android system to check it.

  • Ok, I have partial success :)

    IP1001M works, but only in 100Mbit. What I found, it's common problem (in 1Gbit mode the eth looks working but it's not linking).

    Now I fight with the wifi. From dmesg it's correctly detected (BCM4354), but it fails with
    brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac4354-sdio.bin failed with error -2
    which I found is also common and it should load default driver, which is not happening :/

  • The brcmfmac driver needs to load a firmware (.bin) and nvram (.txt) file from /usr/lib/firmware/brcm but we have no firmware files for BCM4354 in the AMLGX image. If you find files, add them manually: https://wiki.libreelec.tv/how-to/add-firmware

    Most mentions of IP1001M found via Google seem to point back at either unifrequ/ophub device-trees, which look to be a hack job that only partially works, or CE forum threads which fizzle out with the recommendation to avoid X' boxes.

    I did also find https://blog.csdn.net/zuiaikg703/article/details/120350194 which (translated) has some hacky changes for an IP1001C variant, but Google AI claims the difference between IP1001C and IP1001M is that C is multi-mode (copper/optical) while M is single-mode (copper). The current ICPLUS PHY kernel driver only implements a relatively basic level of support for registers, so I would assume it was written around the M variant, but AI also flagged some differences in support for Jumbo frames and other items between C and M that I don't see registers being defined for, which leaves scope for unknown defaults that could leave the PHY misconfigured.

    One thing I did notice is the current kernel driver does not support the 0x02430d91 hardware identifier that I see mentioned in the unifreq dts, so the MDIO bus will not auto-discover and configure the chip automatically.

    This should add the identifier: https://github.com/chewitt/linux/…9d8517b2529ebd4 but no guarantees that helps? You may also need to undo some of the ethernet_phy/mdio hackery from ophub dts files.

    The latest AMLGX images in my test share have a kernel with that patch, but not a dts for the X96-max-plus box.