Help to unbrick a TVbox x96 S905x

    Quote from bumerc

    It looks like a fake s905w SoC (S905W) revision 21:b (a2:2). Since the BL30 complains about "Wrong chip a0."

    I suspect the FIP files for p212 were generated before the existence of S905W boards; hence the 'wrong' (unknown) chip error. The VIM1 files are newer and thus accomodate the chip, even if the wrong RAM size is being detected.

    Sniperassault For the sake of a simple test, create an SD card for VIM1 but configure meson-gxl-s905w-p281.dtb as the dtb to use and see if that gets further through boot?

    Well i tried multiples images with the meson-gxl-s905w-p281.dtb as the dtb to use and the results seems to be the same as the other .dtb

    with the VIM1 image always have different outputs but there is always a kernel error. Same with LePotato. These 2 images are the only ones that do not have a code loop on the uart console.

    Quote from chewitt

    See if https://chewitt.libreelec.tv/testing/LibreE…0.1-p212.img.gz works any better?

    with this i have the exactily the same output loop with either of those two .dtb

    I just realized that now, without the eMMC, the USB Burning Tool now detects the box on the PC. Is this useful for anything?

    Edited once, last by Sniperassault: new discover xD (October 17, 2025 at 3:48 AM).

    Quote from chewitt

    I suspect the FIP files for p212 were generated before the existence of S905W boards; hence the 'wrong' (unknown) chip error. The VIM1 files are newer and thus accomodate the chip, even if the wrong RAM size is being detected.

    Hi. Oh yeah, that seems to be it. But the problem is currently with the DDR timing, as two chips are stuck at rank0 (frontside), and the other two at rank1 (backside). Rank1 isn't initialized yet, which is causing the kernel to panic.

    Does mainline u-boot work with LE? I made a test build with acs.bin for p281.

    Quote from bumerc

    Does mainline u-boot work with LE? I made a test build with acs.bin for p281.

    LE official images use 2025.07 while the ones in my test share should be using 2025.10. If you fork the amlogic-boot-fip repo on GitHub and push a branch with a 'p281' fileset containing that acs.bin and share a link, I can build an image using it.

    You guys are amazing! Thank you so much for involving in this thread. I was all night long trying with multiples board images and .dtb files and still no luck.I know that my efforts seems to be futile but I dont want to give up.
    LePotato and VIM1 seems to be the most promising. If you need additional info or photos to check if that box are fake or not let me know. I read the cpu chip and clearly say S905x, but i know that even that might be a fake one.
    Thank you againg for your help.

    Hello Everyone! Well i tried the last image that your build, with different .dtb files and the result appers to be pretty much the same: It ends on a Kernel Panic. The new think is there is no more DDR3 chl: Rank0+1 @ 768MHz - FAIL DDR3 chl: Rank0 @ 768MHz - FAIL. I leave attached two uart outputs in case it helps.


    This second is with p212 .dtb

    Quote from Sniperassault

    Hello Everyone! Well i tried the last image that your build, with different .dtb files and the result appers to be pretty much the same: It ends on a Kernel Panic. The new think is there is no more DDR3 chl: Rank0+1 @ 768MHz - FAIL DDR3 chl: Rank0 @ 768MHz - FAIL. I leave attached two uart outputs in case it helps.


    This second is with p212 .dtb

    This is normal, as this configuration is not used for the p281.

    Please post a HQ-photo of one of the RAM chips. I would like to compare the memory capacity with the specifications to avoid misrepresenting the capacity.


    Edit:

    I've now dug out my old fake T95S1. It was advertised as an S905W/16G eMMC + 2G DDR3 when I purchased it. When I received the device, I tried flashing it with the new p281 bootloader, and I got the previously discussed "Wrong chip c0" error. It wouldn't accept any foreign FIP (except the original one), even though the 'p281' board was already available at the time. So I decided to dabble with bl30 and managed to bypass this "chip check." When it finally booted, it turned out to be a 'p211' (s905l) board. Long story short - it's almost the same board you have, meaning DDR3L chips (16-bit dram bus) and their configuration, Wi-Fi module, eMMC, etc. It boots without problems with Tanix TX3 dtb, but with AML 'U-Boot 2015.01', from the khadas-vims-pie branch.

    p211 boot log


    UPD:

    If it doesn't work with "U-Boot 2025.07 khadas-vim" and "meson-gxl-s905w-tx3-mini.dtb," try "AML U-Boot 2015.01" and the same dtb. Download and install LibreELEC-AMLGX.aarch64-12.2.0-box.img. Then install u-boot 2015.01 on the same SD card.

    Linux install:

    dd if=u-boot.bin.sd.bin of=/dev/sdX conv=fsync,notrunc bs=512 skip=1 seek=1
    dd if=u-boot.bin.sd.bin of=/dev/sdX conv=fsync,notrunc bs=1 count=440

    Windows installation with "AML Boot Card Maker".

    I hope you will be lucky )

    Edited 2 times, last by bumerc (October 19, 2025 at 2:05 PM).

    Hi Burmec! Thank you for that explain.

    I don't know if I'm doing something wrong, but I'll try explain you how I did it, and you can tell me if I'm wrong. First, I burned the image you suggested with the tool I always use (LibreElec USB-SD Creator). Then I used AML Boot Card Maker 1.0.1 (I know there are newer versions, but they don't let me burn .bin files) to install the u-boot 2015.0.
    Here comes my trouble: unlike the "board" images, there's no extlinux folder, so I don't know exactly how to add the correct .dtb. I tried creating the extlinux folder with its corresponding file with the .dtb you suggested. I also created the famous “dtb.img” in the root of the SD card, but in both cases, the result is the same in the UART output. From what I can deduce by reading the code the .dtb file has not been found. I've attached the uart output so it's more easier to understand:

    Uart log

    this repeats in a loop.

    PD: I'm also attaching images of the RAM. It has four modules. What caught my attention is that the two on the back of the board have different codes than the one on the other side. I don't know if this is common.


    S905L is the same CPU (opps) as S905W but omits VP9 codec support in silicon and (the important bit) uses Mali 450-MP2 not the normal Mali 450-MP3 so the kernel will lock-up when trying to bring the GPU online if using S905X/S905W device-tree files. I added support for S905L boards last year so there is a device-tree file (p271) that can be used, but I'm not sure that's the issue because u-boot is reporting S905W when reading chip properties. That kind of thing is commonly faked in vendor u-boot with cheap boxes, but we're using upstream. It's harmless to experiment with the p271 dtb file though.

    I think it's more likely the board just has low-bin (out of spec) RAM chips that need timings to be tweaked to work.

    Quote from chewitt

    It's harmless to experiment with the p271 dtb file though.

    I will do that! But I have a question about how to do it...


    Should I just use the LibreELEC-AMLGX.aarch64-12.2.0-khadas-vim.img image for this experiment?

    Or should I use the "box" image and install the u-boot 2015.0? If so, as I mentioned earlier, I'm not sure how to edit the .dtb file, as it's different from the "board" images.

    Sorry if this is a silly question, but I'm a bit lost right now.:shy:

    I'd experiment with the VIM1 and P281 images in my share with extlinux.conf edited to use the p271 dtb.

    If you mod the 'box' image with the Amlogic u-boot bumerc shared you need to edit uEnv.ini instead of extlinux.conf - You will probably need to trigger recovery boot mode too. The recovery button appears to be down the bottom of the 3.5mm audio jack, hence it's often referred to as the 'toothpick' method. You need to hold the recovery button in as the board is powered on and then release it after 2-3 seconds (once u-boot loads) and this makes u-boot search for recovery files on SD/USB media; and it should find the autoscript files that load the LE kernel.

    Quote from chewitt

    S905L is the same CPU (opps) as S905W but omits VP9 codec support in silicon and (the important bit) uses Mali 450-MP2 not the normal Mali 450-MP3 so the kernel will lock-up when trying to bring the GPU online if using S905X/S905W device-tree files. I added support for S905L boards last year so there is a device-tree file (p271) that can be used, but I'm not sure that's the issue because u-boot is reporting S905W when reading chip properties. That kind of thing is commonly faked in vendor u-boot with cheap boxes, but we're using upstream. It's harmless to experiment with the p271 dtb file though.

    I think it's more likely the board just has low-bin (out of spec) RAM chips that need timings to be tweaked to work.

    aml_autoscript is already loaded by default env (see the log). The problem at the moment is that the eMMC has been removed, and AML u-boot can no longer save the environment (since the default storage location for env is eMMC). It might be sufficient to add the following line to aml_autoscript: "mmc dev 1" so that the environment can now be saved on the SD card and the secondary boot script "s905_autoscript" is loaded after the reboot.
    I can now rule out the DDR timing issue:
    D9PQL = MT41K1G4RH-125
    Configuration: 128 Meg x 4 x 8 banks
    128x4x(8/2)=2048mb
    ddr clk=1600/2=800mhz (currently ~792mhz in acs.bin).
    Everything's fine.
    I just made a little mistake with the rank1.

    you guys are f**king amazing!!

    Thank you for not giving up and helping revive this dead box! I am very grateful for your help.

    I'm new in this LE world, so this OS is new to me. I have a few questions I'd like clarification on:

    The system configuration and the app data... Is it saved on the SD or is everything restore every time I restart?

    In the System info menu, It's say that i have 1gb of RAM. This is because is a Fake Box?

    Is the remote control that comes with the box compatible with this OS?

    In the future, if i want to experiment with other Linux-based systems, like Coreelec or Armbian, can I use this u-boot and this .dtb to get them working, or are they completely different worlds?


    PD: If you need me to run any tests or anything so I can contribute to the LE repo or any other member, let me know. It's the least I can do for you.;)


    PD2: Sometimes when i turn on or restart the box it gets stuck on the Kodi Logo. Is there a fix for that or is it normal since it is not a 100% image made for this box?

    Edited 3 times, last by Sniperassault: possible bug? (October 21, 2025 at 4:56 AM).

    LE mounts the second partition on the SD card as /storage and uses this for persistent data, e.g. Kodi saves to /storage/.kodi - the rest of the filesystem is decompressed from the SYSTEM file on boot and is read-only so it's hard to mess things up.

    See https://wiki.libreelec.tv/configuration/…ration-advanced for instructions on creating and configuring a custom IR keymap. The remote will use the rc6 protocol so there might be existing keymaps that work, but it's normally quicker to transcribe one from scratch than test all the existing ones trying to find the one that exactly matches (there are lots of them).

    It's impossible to guess what might cause Kodi to get stuck on the logo without seeing log files. If there is an issue in the OS it might be visible from the UART output. If there's something in Kodi .. you can enable persistent logging via the LE settings add-on and then check the logs (or look for crash logs) on the next clean boot.

    CE and Armbian should be able to boot using the same u-boot, but their boot files are differently named, e.g. CE uses dtb.img and kernel.img so you might need to rename their files to match LE conventions. Updates would also not work, although GXL devices are no longer supported yb CE so there will be no updates. Armbian will be different again. I'm not sure what changes bumerc has hard-coded in u-boot, but as long as you can boot to the u-boot console via the UART cable changing the scripts stored in the u-boot environment will always be possible.