[UNOFFICIAL][Le11-10][RK3228/RK3229][box]Libreelec builds

oneillb · April 12, 2022 at 6:33 PM

Quote from jock2

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.

fabiobassa · April 13, 2022 at 7:38 PM

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

jock2 · April 15, 2022 at 12:05 PM

Quote from oneillb

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.

oneillb · April 16, 2022 at 10:57 PM

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?

oneillb · April 17, 2022 at 11:34 AM

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?

**ilmich** · April 17, 2022 at 3:21 PM

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

oneillb · April 17, 2022 at 5:44 PM

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

oneillb · April 18, 2022 at 8:30 PM

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

**Da Flex** · April 18, 2022 at 11:16 PM

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

**ilmich** · April 19, 2022 at 9:13 AM

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.

**ilmich** · April 21, 2022 at 8:40 AM

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.

oneillb · April 22, 2022 at 8:07 AM

Hi ilmich ,

I've again needed to blacklist the ssv6051 to make things stable, as otherwise things crash after a few minutes.

There are still some Kodi crashes, I've attached some logs . I hope this helps.

logs_20220422.zip

**ilmich** · April 22, 2022 at 9:57 AM

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.

oneillb · April 23, 2022 at 1:10 PM

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?

Code

dmc-opp-table {                                              
                compatible = "operating-points-v2";                  
                phandle = <0x06>;                                        
                                                                     
                opp-330000000 {                                      
                        opp-hz = <0x00 0x13ab6680>;                  
                        opp-microvolt = <0x100590 0x100590 0x124f80>;
                        status = "okay";                             
                };                                                       
                                                                     
                opp-534000000 {                                      
                        opp-hz = <0x00 0x1fd43180>;                  
                        opp-microvolt = <0x100590 0x100590 0x124f80>;
                        status = "disabled";                         
                };                                                       
                                                                     
                opp-660000000 {                                          
                        opp-hz = <0x00 0x2756cd00>;                  
                        opp-microvolt = <0x10c8e0 0x100590 0x124f80>;
                        status = "disabled";                         
                };                                                       
                                                                     
                opp-786000000 {                                      
                        opp-hz = <0x00 0x2ed96880>;                  
                        opp-microvolt = <0x10c8e0 0x100590 0x124f80>;
                        status = "disabled";                         
                };                                                       
        };

Display More

jock2 · April 23, 2022 at 3:03 PM

Quote from oneillb

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 dmc@11200000 node in the device tree is disabled:

Code

dmc@11200000 {
                compatible = "rockchip,rk3228-dmc\0rockchip,rk322x-dram";
                reg = <0x11200000 0x400>;
                clocks = <0x02 0x40>;
                clock-names = "ddr_sclk";
                operating-points-v2 = <0x06>;
                rockchip,dram_timing = <0x07>;
                rockchip,grf = <0x05>;
                devfreq-events = <0x08>;
                upthreshold = <0x0f>;
                downdifferential = <0x0a>;
                #cooling-cells = <0x02>;
                status = "disabled";
                logic-supply = <0x09>;
                phandle = <0x6a>;
        };

Display More

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

**ilmich** · April 23, 2022 at 5:26 PM

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.

oneillb · April 24, 2022 at 12:24 PM

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.

jock2 · April 24, 2022 at 7:37 PM

oneillb ilmich This looks very very suspicious (journal log):

Code

Apr 24 11:24:41 YNWA kernel: ------------[ cut here ]------------
Apr 24 11:24:41 YNWA kernel: WARNING: CPU: 3 PID: 1012 at drivers/gpu/drm/drm_atomic_helper.c:1512 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
Apr 24 11:24:41 YNWA kernel: [CRTC:41:crtc-0] vblank wait timed out
Apr 24 11:24:41 YNWA kernel: Modules linked in: snd_soc_spdif_tx fuse
Apr 24 11:24:41 YNWA kernel: CPU: 3 PID: 1012 Comm: kodi.bin Not tainted 5.10.111 #1
Apr 24 11:24:41 YNWA kernel: Hardware name: Generic DT based system
Apr 24 11:24:41 YNWA kernel: [<c010ff44>] (unwind_backtrace) from [<c010c040>] (show_stack+0x10/0x14)
Apr 24 11:24:41 YNWA kernel: [<c010c040>] (show_stack) from [<c0c4c2d0>] (dump_stack+0x94/0xa8)
Apr 24 11:24:41 YNWA kernel: [<c0c4c2d0>] (dump_stack) from [<c01321fc>] (__warn+0xec/0x148)
Apr 24 11:24:41 YNWA kernel: [<c01321fc>] (__warn) from [<c0c49064>] (warn_slowpath_fmt+0x98/0xbc)
Apr 24 11:24:41 YNWA kernel: [<c0c49064>] (warn_slowpath_fmt) from [<c074d770>] (drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8)
Apr 24 11:24:41 YNWA kernel: [<c074d770>] (drm_atomic_helper_wait_for_vblanks.part.0) from [<c074f1e8>] (drm_atomic_helper_commit_tail_rpm+0x78/0x88)
Apr 24 11:24:41 YNWA kernel: [<c074f1e8>] (drm_atomic_helper_commit_tail_rpm) from [<c074f730>] (commit_tail+0x9c/0x184)
Apr 24 11:24:41 YNWA kernel: [<c074f730>] (commit_tail) from [<c07508a0>] (drm_atomic_helper_commit+0x134/0x158)
Apr 24 11:24:41 YNWA kernel: [<c07508a0>] (drm_atomic_helper_commit) from [<c0785050>] (drm_mode_atomic_ioctl+0x92c/0xa8c)
Apr 24 11:24:41 YNWA kernel: [<c0785050>] (drm_mode_atomic_ioctl) from [<c075b120>] (drm_ioctl+0x1f8/0x3d4)
Apr 24 11:24:41 YNWA kernel: [<c075b120>] (drm_ioctl) from [<c0313b4c>] (sys_ioctl+0x3ac/0xa38)
Apr 24 11:24:41 YNWA kernel: [<c0313b4c>] (sys_ioctl) from [<c0100060>] (ret_fast_syscall+0x0/0x54)
Apr 24 11:24:41 YNWA kernel: Exception stack(0xc8135fa8 to 0xc8135ff0)
Apr 24 11:24:41 YNWA kernel: 5fa0:                   01c64778 be93f9b0 00000000 c03864bc be93f9b0 00000000
Apr 24 11:24:41 YNWA kernel: 5fc0: 01c64778 be93f9b0 c03864bc 00000036 01a0ce08 01c80480 01c80498 01a0ce14
Apr 24 11:24:41 YNWA kernel: 5fe0: b48fa114 be93f984 b48f0568 b475f11c
Apr 24 11:24:41 YNWA kernel: ---[ end trace 400a0e8366cbd1c6 ]---

Display More