Nightly images for A64, H3, H5, H6 and R40 boards

  • jernej I finally compiled LE from master branch with a specific old commit, I downloaded the package sources first. I just prepared my SD card and that's it, the board works again. BTW I don't know why the compilation failed at the u-boot installation, and I don't really know why latest builds doesn't work on my tx6 mini.
    So I have to open the box and connect it via UART to see what the problem is?

  • I can't get past the splash screen on the latest nightly for Orange Pi PC. On the first boot everything went fine, filesystem is written, all check marks passed with OK but after the reboot I'm stucked on the LE logo. Tried another sd card, downloaded image twice but no change. Does anyone have older nightly version for Orange Pi PC for download?

  • I can't get past the splash screen on the latest nightly for Orange Pi PC. On the first boot everything went fine, filesystem is written, all check marks passed with OK but after the reboot I'm stucked on the LE logo. Tried another sd card, downloaded image twice but no change. Does anyone have older nightly version for Orange Pi PC for download?

    Same with Tanix TX6. I solved by compiling an old build because I didn't have a .img backup. I don't know if anyone here can help you by sharing an old build, they ignored me a few days ago when I asked the same question as you, so I did it myself. This is the best way! :)
    Good luck!

  • Hello, thanks the work on supporting allwinner devices!

    I have upgraded recently to

    LibreELEC-H3.arm-9.80-nightly-20201009-45d6ccb-orangepi-pc.img
    and the GUI audio is late, there other audio issues as well during playback, anyone else encountered it?

  • Yes, that's the correct way to do it. You should instantly get a log if you did it right.

    Thank you!

    I was able to do it and I can confirm the issue is the same and hasn't been fixed as of version 10.10.


    hastebin


    EDIT: I played around a bit and it seems to happen with a fresh install too (first boot decompresses the image, second boot hangs up). On a side note, something similar has been happening with Armbian for a while now, not sure if it's the same cause or not.


    EDIT2: So I tried SPI with a different image (one that works), and it has the same "couldn't map SRAM to device" error, but after that it loads the kernel...

  • Thank you!

    I was able to do it and I can confirm the issue is the same and hasn't been fixed as of version 10.10.


    hastebin


    EDIT: I played around a bit and it seems to happen with a fresh install too (first boot decompresses the image, second boot hangs up). On a side note, something similar has been happening with Armbian for a while now, not sure if it's the same cause or not.

    At first glance it doesn't seem to be related to Armbian's problem, the logs attached there show that the kernel at least boots, in our case the kernel fails to boot because of that SRAM mapping error.

  • At first glance it doesn't seem to be related to Armbian's problem, the logs attached there show that the kernel at least boots, in our case the kernel fails to boot because of that SRAM mapping error.

    I edited my last post, but it was after you had posted this (that's the risk involved with having to approve all replies).


    I tried SPI with a different image (one that works), and it has the same "couldn't map SRAM to device" error, but after that it loads the kernel...

    I think the problem is not related to those messages and instead happens when uboot tries to load the kernel... but alas, I think there is no way see what happens.

  • I edited my last post, but it was after you had posted this (that's the risk involved with having to approve all replies).


    I tried SPI with a different image (one that works), and it has the same "couldn't map SRAM to device" error, but after that it loads the kernel...

    I think the problem is not related to those messages and instead happens when uboot tries to load the kernel... but alas, I think there is no way see what happens.

    The problem maybe related to UBoot, the weird thing is that a freshly compile nightly of Armbian works but a LibreELEC one doesn't, I don't know of they are using different UBoot sources. I would compile myself an older version of LibreELEC but I don't know which commit broke things.

  • The problem maybe related to UBoot, the weird thing is that a freshly compile nightly of Armbian works but a LibreELEC one doesn't, I don't know of they are using different UBoot sources. I would compile myself an older version of LibreELEC but I don't know which commit broke things.

    Thanks for the hint about Armbian nightlies, I didn't know those things existed.

    Currently I don't have a Linux desktop, but once I get some free time on my hands I will try and set something up, so that I can also compile things from source (and hopefully I can provide more info about the bugs that way).

  • Could the cifs.ko become part of to the testing images?

    Yes, it will be part of Linux 5.9 update. It will be built-in, not a module, though.

    Where can i find old builds for Tanix tx6?

    There is no official archive of old nightly images, so you have to build it yourself from (older) sources.

    I managed to get a log, UBoot seems to work fine but the kernel throws a nasty error:

    Note that SRAM mapping error can be ignored. It's present because driver dependencies are not loaded at the time. It gets loaded again later, with all dependencies satisfied. If that wouldn't work, display would be blank.

    I would like to compile the 9.2.4 branch for tx6, wich is the "UBOOT_SYSTEM"?

    None. Tanix TX6 board wasn't supported at the time 9.2 was branched. In any case, no Allwinner fixes were merged in 9.2 stable and no stable images are provided for Allwinner at this time. You can expect them with LibreELEC 10. For now, use master branch.

    I don't really know why latest builds doesn't work on my tx6 mini.
    So I have to open the box and connect it via UART to see what the problem is?

    Yes, UART is mandatory for such problems. First you have to determine if U-Boot even runs (by monitoring UART). If so, there are additional steps that needs to be taken. But we'll discuss them once you do first step.

    on my bananapi A20 I now have a problem playing h.264 movies.

    After some time of playback (~ 1 minute) the screen freezes, but sound continues.

    It seems VPU runs out of memory. A20 can use only part of memory for video decoding. What is the resolution of your video? Can you test smaller and/or just another videos?

    I can't get past the splash screen on the latest nightly for Orange Pi PC. On the first boot everything went fine, filesystem is written, all check marks passed with OK but after the reboot I'm stucked on the LE logo. Tried another sd card, downloaded image twice but no change. Does anyone have older nightly version for Orange Pi PC for download?

    Systemd update caused some issues which should be fixed in new nightly image tomorrow. Can you test it once it's updated? Not sure if this is the cause of your issue or not, just a hunch.

    (that's the risk involved with having to approve all replies).

    Most posts are not moderated. I suggest you remove links from your signature, it's probably the reason why system puts your posts in moderation queue.

  • Systemd update caused some issues which should be fixed in new nightly image tomorrow. Can you test it once it's updated? Not sure if this is the cause of your issue or not, just a hunch.

    Just tried today's nightly LibreELEC-H6.arm-9.80-nightly-20201014-fede07e-orangepi-lite2.img and the result is the same. First boot completes and expands the filesystem, second boot is stuck LE logo.


    If this is of any help:

    LibreELEC:/ # dmesg


    LibreELEC:/ # connmanctl


    Please ask for any other info I might be able to provide.

  • I am having the same problem/behavior on my RPi 3+ with LibreELEC-RPi2.arm-9.80-nightly-20201014-fede07e and any of the nightly builds available on Index of /. First boot works, reboot stuck at LE splash.


    Thanks.

  • Please ask for any other info I might be able to provide.

    What about output of journalctl? Anyway, there is one issue present in nightly image where boot is delayed for 25 seconds. How long did you leave it running?


    BTW, next nightly will have Linux 5.9 and H6 DDR3 RAM init fix for some boards.

  • It seems VPU runs out of memory. A20 can use only part of memory for video decoding. What is the resolution of your video? Can you test smaller and/or just another videos?

    Latest try with LibreELEC-A20.arm-9.80-nightly-20201014-74eb09f-bananapi:


    Yes, I tested several videos H264 HD, SD XviD, AVC. (XviD videos are also jerky). In general, when I switch from a running video to another, playback switches to that new video, but the image is a still image from the original, only the audio from the new one continues. Same when I jump forward or backward during playback.

    Logs on such jump:

    http://ix.io/2ALJ

    http://ix.io/2ALH


    First I have to say that LibreELEC-A20.arm-9.80-nightly-20200426-65f515b-bananapi (oldest I have) works quite well. These test videos mostly play well (H264 SD HD) I can jump in a video, switch to another video during playback. There is only a problem: DVB-S2 H264 Full HD channels have delayed audio and fail after a while. O.K playback is on H264 SD channels.