Posts by intelmorino

    intelmorino I think you need to trigger "recovery" mode on the box again. This will trigger the factory u-boot to search for boot scripts and read them, and the important bit - store/overwrite the file-search routines. If you've simply switched the SD card the stored config will be set to look for CE/Legacy files, hence LE bootscripts are not automatically found and read. It's also interesting to see the file rename approach, I wouldn't have thought it would work (but then I don't test with Legacy images or CE at all). Also good to hear the A95XF3 dtb is okay.. I've submitted it upstream and it should be merged for Linux 5.18.

    No dice. I took your comment on board and reflashed the stock Android image. Then reflashed the LE image and set up the dtb in uEnv.ini. Then tried to recover from Android using the "update" app but that failed and took me to the boot menu. Powered down and repowered with the toothpick method, but that took me into a boot loop. So I think I've excluded the possibility that I've missed something.

    Hi Chewitt, some feedback on these January 2022 postings regarding a95x F3 Air. I never did get it to boot then, but since you reinstated the chainload boot into the boot scripts, this device now boots fine. I used a u-boot.bin from a previous Libreelec compilation and changed the extension to "ext".

    intelmorino I think you need to trigger "recovery" mode on the box again. This will trigger the factory u-boot to search for boot scripts and read them, and the important bit - store/overwrite the file-search routines. If you've simply switched the SD card the stored config will be set to look for CE/Legacy files, hence LE bootscripts are not automatically found and read. It's also interesting to see the file rename approach, I wouldn't have thought it would work (but then I don't test with Legacy images or CE at all). Also good to hear the A95XF3 dtb is okay.. I've submitted it upstream and it should be merged for Linux 5.18.

    No dice. I took your comment on board and reflashed the stock Android image. Then reflashed the LE image and set up the dtb in uEnv.ini. Then tried to recover from Android using the "update" app but that failed and took me to the boot menu. Powered down and repowered with the toothpick method, but that took me into a boot loop. So I think I've excluded the possibility that I've missed something.

    Thanks - that information provides useful clues. However after more machinations (checking script differences between LE and Armbian etc) I still had no result. Finally out of desperation, I burnt a current CoreELEC image to sd, and did the following on the FAT partition:

    - deleted CE kernel.img replaced it with LE KERNEL and renamed it as kernel.img

    - replaced CE SYSTEM with LE SYSTEM

    - copied LE meson-sm1-a95xf3-air.dtb to partition and renamed it as dtb.img

    Thereafter LibreELEC-AMLGX.arm-11.0-nightly-20220110 boots and runs perfectly!

    So I deduce that the LE dtb is fine, and the issue is within the LE scripts somewhere.

    A95X F3 Air (S905X3)..has anyone had any success booting with one of these?

    I have tried 10.85.0 and nightly 220110 box images to no avail. I've tried pretty much every sm1 dtb. Device RGB lights on and attempts to boot but A95X is permanently displayed on the screen. I can't provide UART logs since I'm not sure which pads are correct on the board.

    This device does use "ENC" bootloader images so the bootloader may be considered encrypted.. However..latest Armbian images (5.10 and 5.15 kernels) and Coreelec (4.9 kernel) boot with no issue from sd card. Therefore I suspect that either the LibreELEC dtbs are not correct, or the LE aml_autoscript commands are not compatible for some reason.

    AMLGX looks very promising as the future basis for LibreELEC on Amlogic devices. However I primarily use my TV boxes (H96 /A95X) for projector application. Some features that work on PC based Kodi and also exist in the 3.14 based Amlogic kernel have proven invaluable and I would like to flag them as highly desirable for the future platform:

    • Rotation - Although rotation is not consistently supported across all file types, it is currently possible to rotate certain media using metadata. I do not see any capabilities in mainline kernel or in the LibreELEC DRM AMLGX implementation to allow for rotation. Users of TV boxes for portrait signage applications would appreciate this too.
    • Non-linear stretch (works on CoreELEC currently with wide zoom setting) - Subjective opinion , but extremely good for watching 4:3 material on a big screen. This function is embedded in 3.14 kernel but would not likely be in future LibreELEC without special work using GL or GLES
    • Brightness and Contrast (available currently on player GUI) - Crucial in setting a watchable environment especially to enhance the so called “artistic cinematography” of movies which results in exceptionally low contrast/brightness on dark scenes. I can speak from experience since I previously used an RPI3 which did not have these settings and the Amlogic player was like a breath of fresh air. The usual feedback on this request is that the end device (eg. TV/projector/monitor) settings should be used, but it is my experience that the result is never quite the same - analogous perhaps to turning up the volume on a radio with a weak station signal. However I note that newer STBs and SBCs like the N2 do not appear to have the required register capability in the SOC - seems to be a retrograde step.