[UNOFFICIAL][RK3228/RK3229]Libreelec 10.x builds

  • The gzipped libreelec image is burned very quickly because the uncompressed libreelec image is quite small (500 megabytes circa); the backup of the existing Android is the same of the whole NAND (8 gigabytes I guess).


    Multitool is quite capable to handle gzip and other compressed formats: it will decompress them on the fly while burning is in progress, so no need to do that manually.


    A possible issue that may come from your steps is the Flash Erase step you said you did. I don't remember if it is so, but it may be that the Erase Flash step completely erases the NAND, idbloader included. idbloader can't be installed again by multitool because of the NAND rockchip driver limitation and you may need to do that manually using rockchip upgrade_tool (see this post on armbian forum, paragraph
    NAND Bootloader Upgrade)


    I don't think I've removed the idbloader, I can reinstate the Android backup image using Multitool, and return everything back to as it was. Does that mean that idbloader is still intact?


    Is there a good place to read up on that part uboot, idbloader and the kernel play in the boot process...


    Thanks again.

  • oneillb

    This is for general culture and it is how basically works the boot flow in rockchip. Biggest limitation is that is not possible ON NANDS write under 0x2000 with new tools unless you use a old way to burn idbloader ( and multitool is capable of do it)

    http://opensource.rock-chips.com/wiki_Boot_option

    Reinstalling android with windows AndroidTool ( AndroidTool_Release_v2.1.7z ) also could be a good starting point and after android is in place again do the procedure as ilmich suggests. Unfortunately nands are a very pita !!

    DISCLAIMER : android uses some internal " partitions " called rkparameters...... consider this when going to install libreelec because it is different from master boot record and even gpt. Reinstall android and came back here to ask enlightment to ilmic or jock

  • I don't think I've removed the idbloader, I can reinstate the Android backup image using Multitool, and return everything back to as it was. Does that mean that idbloader is still intact?

    That's a point, you're right, the idbloader is still there if you're able to restore Android with multitool. So the issue is probably related to libreelec and a serial adapter is absolutely the way to go to debug.

  • I've continued to work with the 10.x builds and if found that the sv6051p wifi driver is a the likely cause of many of the random lockups and crashes I've been seeing. I've blacklisted the module now completely, and stability seems to be much much better. I'm going to leave the box running for a soak test for several hours to check


    I'd like to use the board with a wireless network... Does anyone have any recommendations for a reliable and preferably cheap USB dongle I can use with these Libreelec 10.x builds, preferably one already supported buy the available kernel builds?

  • I've made a little discovery which may be important to understand the root of the problem I have booting from NAND... on my r329q v3.0 board, which has DDR2 RAM, NAND and sv6051p wifi.


    I re-wrote the NAND using Multitool and the latest LE 10.x image, as before and didn't boot.. exactly the same as before. However, I then booted off an SD card using the same 10.x image... It booted the kernel from SD, but mounted the rootfs from NAND.


    Also, I still have a lot of instability with LE10.x even after I've blacklisted the ssv6051 wifi module, which may be down to dram timing / voltages. I've also been using the LE9.2 build , with the Alfawise a8.dtb (LibreELEC-RK322x.arm-9.2-devel-20200427213246-b7186bc-rk3228b-a8.img.gz ) stability on this build seems much better, with less frequent lockups.


    How easy would it be to build a LE10.x dtb file for my board based on the dram configuration from the LE9.2 dtb file?

  • hi oneillb,


    i'm away from home for a little vacation.

    but, wich kind of issue?! freeze or crash?!

    Freeze are often voltage/power.. but crash maybe is another thing.

    Can you share some logs?? Are you using some addons?! Crash is with some particular file formats?! For example I've noticed some crash with xvid files (maybe lack of MPEG4 hardware decoding)


    regarding dtb.. alfawise is similar to v88mars.. try and let me know.


    thanks a lot for testing

  • Hi again,


    I'd say freeze, rather than crash there's no kernel panic or reboot ... with LE10.x, generally within 30-60mins of idling the box will freeze, sometimes more quickly. I'd originally put it down possibly to heat, but I've cemented a much bigger 20x20x10mm heat sink, to the CPU, and generally Kodi reports a temp in mid 60s and up to about 75C when more heavily loaded, which I think is OK.


    By comparison the LE9.2 build for Alfawise A8 seems to be bullet proof... I've been running the box with Kodi idling for > 6 hours, playing some low res 360p mp4s over nfs. I have some 1080p .ts files also which it manages, although things struggle when the GUI overlayed.


    The LE9.2 build for v88Mars freezes after about 30seconds after I get Kodi up. I don't get through the initial setup wizard.


    I'm having a go a building myself from sources on a Ubuntu 21.04 x86_64 machine but I'm having issues with building m4-1.4.18 .


    Have a great vacation.


    Barry

  • Updating the loader using rkdeveloptool and rk322x_loader_v1.10.256.bin has sorted all the booting from NAND issues out.. I must have had a very old / unusual idbloader.


    I've also successfully blacklisted ssv6051, I now also have more stable wireless networking (using a wifi dongle now based using a realtek 5390 chipset i think.. which I used previously on an early raspberry Pi) , and I've managed to get a trace in dmesg for a lockup, which was only kodi freeze, not a freeze of the Kernel / OS.


    Actually I ran the r329q v3.0 board without Kodi (systemctrl stop kodi after boot) for several hour without issue, so I expect my issues no are with the kodi binary, not the underlying kernel and OS.


    dmesg_202204181321.log

  • oneillb It's still a kernel issue, maybe triggered by accessing higher memory regions while running Kodi.

    DNB music-addicted finger drummer.

  • oneillb,


    this is partially a good news.

    Because the system is stable as hardware, but unfortunately there are some software bugs(kernel in this case). Looking at the dmesg it looks like a null reference while trying to do filesystem operations.

    I'm preparing a new build with the latest 5.10.x kernel, hopefully it will fix.

  • Hi all,


    new build available with:


    - linux 5.10.111

    - mesa 21.0.1


    oneillb this build was tested for some days without particular freezes/issues. Try it and let me know.

  • Hi oneillb ,


    the driver for 6051p does not exist in the mainline kernel, but with the help of fabiobassa and jock2 we have made a revised version.

    Unfortunately, it never worked well for me, not even the legacy one (I discovered it also depends on the accesspoint).

    But I've never quite understood the cause, and in any case I know that it works well for some.

    I'll see what I can do.


    Regarding the crashes can you try to keep the gui at 720p?! I have seen a couple of errors in the dmesg due to insufficient CMA memory. And it could be due to some bug in the gpu opensource driver.

    I'm usually use the 720p gui (it's much smoother), but I'll do some tests too.


    In any case also try to increase the CMA memory by adding the kernel parameter

    Code
    cma = 256M


    in the extlinux.conf file.


    If you are booting from sd it is easy. You find it in the fat partition.

    Otherwise from an ssh session you can

    Code
    mount -o remount,rw /flash
    nano /flash/extlinux/extlinux.conf
    mount -o remount,ro /flash


    thanks a lot.

  • I limited the GUI resolution and changed the cma settings as recommended, but it didn't change things really, but I've left it that way anyway for now.

    However, I think i have resolved the crashing I've been having with my box... which has DDR2 ram. I was using the v88mars.dtb , that board I think has DDR3... and the minimum enabled ram speed in the .dtb file is set to 533MHz

    I've rebuilt a dtb specifically for my board, based on the v88mars one, but setting the max freq to 330MHz, by toggling the status= values in the dts and re-compiling. Initial impressions are good, I'll run with this for a day or 2 and see how things go.

    Does this sound reasonable?

  • Does this sound reasonable?

    Well, not really to me... I mean, memory scaling is only for DDR3 boards; if your board comes with DDR2 chips then memory scaling is not supported and the kernel driver is instructed to bypass. Modifying that table should do no difference to your board.


    Also I'm using v88mars dtb too and I see that the [email protected] node in the device tree is disabled:

    So any change to the dram frequency table surely won't affect anything.

  • hi oneillb,


    jock2 is right. As I tried to write in the first post, the v88mars has the dmc driver disabled so what you have done has no effect.

    However in the last build I introduced a visual feedback (flashing of power led) when using the remote control. This is not only cute but also useful to understand if the box has frozen or not.


    In fact, based on my experience, freezes can depend on an incorrect hardware configuration (too high frequency, voltage problems ... etc etc). But your crashes look like software, probably related to some particular case where kodi and the software stack in general fail.


    Just to give you an example, I have an sftp folder linked to my nas. Kodi if the nas is turned off becomes slow/unstable, because it tries to connect to something that does not exist.


    So what I can do is try to reproduce your problems and keep the software updated.

    My suggestion is to try to understand if it may depend on some usb device connected, addon, .. etc etc

    And post other logs (also with libreelec debug active). Maybe something comes from there too.

  • jock2  ilmich


    Thanks for all the info, I'm learning a lot... I've gone back to the base v88mars build, and removed everything I don't need, as you've recommended.

    * svv6051 disabled

    * no USB wifi dongle

    * using ethernet only,

    * no usb keyboard & mouse,

    * cec disabled (not sure board has cec)

    * avahi switched off

    * samba switched off


    In approx 60 minutes had 3 os lockups, and 3 other kodi crashes.


    The kodi crash logs are attached as is the OS journal, which unfortunately leaves very little about the OS crashes.


    logs_20220424.zip


    Hopefully this is useful to you.

  • oneillb  ilmich This looks very very suspicious X/ (journal log):