Posts by bumerc

    Hi again!

    I've been using the latest "box" stable image this week without issues so far. I would like to know if there is a way to completely turn off the USB ports, because when I turn off the tv box, the USB ports still active. Mainly to save energy and prevent the flash drives from running unnecessarily (since some tend to get warm).

    This is normal. GXL suspend_fw doesn't provide for complete USB power down. The voltage is simply reduced to the value defined by the 'CONFIG_VDDEE_SLEEP_VOLTAGE' constant. Interrupt autoboot in u-boot and run 'gpio status -a'. Check if something like 'hdmi_5v' (input) appears in the log. If not, then vcc5v is not supplied to USB at all. Then run 'usb start' and then 'gpio status -a' again, and check the log. If you see something like 'hdmi_v5' (gpioh_3, output 1), then you've supplied 5V to USB.

    Also i noticed that with this u-boot (or maybe because now i use the p281.dtb instead the tx3 mini?) I have more RAM available. Before, it appeared I had 1GB. Now, it shows 2GB.

    What build do you recommend for daily use? I was thinking of giving the box to my dad, since he has an old non-smart LED TV, and it will be useful for him to watch movies and series on it.

    Oh, that's confusing. I'm assuming it's u-boot (although both recognize 2048mb), since the 'memory' node is the same for tx3 mini and p281 dtb (1024mb). Only in VIM1 dtb is the 'memory' node = 2048mb.
    So if you were to use AML-u-boot again, the dtb 'memory' node should be corrected to 2028mb. But anyway, ask chewitt if he would add a p281_2g dtb for your device.
    Since I haven't used LE/CE for several years, I can't really recommend anything, but I would still switch to the builds with the latest kernel and Kodi. Oh yes, I partially retract post #38 :)

    Sniperassault

    I added a link in #43 above. If the vendor custom code matches, you'll be able to wake the box from deep sleep by double-pressing the power button. The easiest way to find the custom code is from the original remote.conf file, which you unfortunately don't have, or from the Android kernel log (the output of the meson-ir driver). You don't have that either.

    Last question: I was able to get the remote control to work(If it's usefull for someone the x96max toml file works perfectly) but I'd like to know if it's possible to turn the box on with the power button. I can easily turn it off or suspend with the remote, but I haven't found a way to turn it on or wake up. Not even with the keyboard i can wake up the box. If there is any fix for this let me know, since the only way so far is to unplug the DC cable and plug it again.

    Your remote's factory_code and power key code must be included in the u-boot suspend-fw (bl301). Find them and post them here.

    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?

    This is probably because you connected the box to the USB port instead of using the original power supply. Depending on which USB port you were using to power the box, the u-boot will automatically boot into ‘burn mode’ because the eMMC module was removed. Another reason, of course, could be a lack of power. Not a good idea :)

    Use the original power supply or something similar.

    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.

    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 )

    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.

    So sorry fot that! I didn't want to make the post so long and I couldn't think of a better idea than to upload .pdf files.^^


    I tried that image and least now the uart output is ever the same:D. This code repeats in loop while the box is on:

    From what I read in another thread you also participated in, you mentioned that this means the u-boot is partially functional.
    Am I correct, or did I misunderstand?

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

    This message also appears on an s905l board when attempting to run a standard boot FIP on it.

    An acs.bin for p281 with VIM u-boot should be used here to ensure the 2G of RAM is fully initialized.

    Hi Bumerc,

    The first option sounds ok my end to process.

    1). What are the steps to add this source code file commands into which file / folder in the box? I only see the file/folder options from android recovery as per previous photos attached in posts.

    Thanks

    Bob

    Hi.

    Please follow the instructions in this PDF file for manual installation. For installation you need these files. Then try to establish the connection to the box via cmd.exe. Hold the reset button and run update.exe identify

    I will explain the remaining steps once you have established the connection to the box.

    You don't need any files on the box. The update.exe interacts directly with the u-boot via worldcup protocol and the u-boot writes the commands directly into the env partition of the eMMC, as if you were writing directly in the u-boot prompt via uart.

    A typical indication that the vendor u-boot is too old. It lacks the ability to run aml_autoscript in the environment.

    A more complicated but safe method:

    You can install the Amlogic USB Burning Tool on your computer, connect the box to the computer via USB cable and manually add the commands from the source file in the Windows cmd window to the u-boot environment.

    Another option would be to upgrade the Android to a higher version, but there is a risk that you will get an unsuitable firmware that will brick the box.