Posts by jock2

Quote from SN33KY

...

So total costs were already €90, without the problems solved. Therefore all additional devices returned to the selling parties and I bought a Dell Optiplex 3060 SFF as the solution. Set up LibreElec there and put the media on the internal HDD. Cost me €120,- Euro. (€again 30 extra)

No hassle, fast, user-friendly and good remote control (which I still had lying around), USB ports work, etc. So all plus points.

Sometimes we just want something that works, without all the hassle. And mostly cheap.... but i learned my lesson here

That is, cheap chinese crap works that way.

It is mostly garbage that pollutes the world, and you pay for that too.

Quote from Da Flex

Is there a RAM testing tool available? Maybe this should be the first thing to run.

On armbian you can install and use memtester. I guess the binary would work on libreelec too, but I don't know if there is the need for some dependencies.

oneillb did you try to keep only a single CPU operating point in the device tree?

On armbian I had many issues and crashes on a board of mine because the transition between the slowest (600 mhz) and highest (1.4 ghz) operating points was "too fast"; actually the legacy 4.4 kernel worked plenty well, but the mainline kernels crashed a lot in a matter of minutes or seconds.

That what pretty strange on my case, but I solved by either using a single cpu frequency (thus not allowing the frequency switching), or raising enough the voltage of the slowest operating points to reduce the voltage gap between slowest and highest operating points.

That board now runs pretty well with uptimes of several weeks! (this is the device tree overlay for the modifications I used in my case)

Quote from oneillb

The board will boot from SD (which I'm using to test out the LE10 builds) and fall back to NAND without issue when the SD card is removed... My problem is with stability once things are up and running... If the bootloader puts the board into 1T mode at startup, is that mode maintained through u-boot and kernel startup, or can the kernel driver switch the mode later on?

Uhm, this makes my hypothesis invalid as the answer to your question is no: the kernel driver can't swtich from 1T to 2T.

Once your box boots in 1T mode it can't switch to 2T mode.

oneillb

[    3.520762] rk3228-dmc 11200000.dmc: memory type DDR3, timings (tCL, tRCD, tRP, tRAS): CL10-10-10-25 command rate: 1T (mcfg register: 0x50021)
[    3.535269] rk3228-dmc 11200000.dmc: detected DDR3 memory

The 1T Command Rate may be the reason you get your issue.

DDR memories have this Command Rate parameter which specifies how many clock cycle are required to send a command to the DRAM banks. It can be 1 clock (1T) or 2 clocks (2T). 1T is faster but less compatible, 2T is slower but more compatible.

Most boards works fine with 2T, but 1T may let the system become unstable.

On the contrary, a very small set of boards (like my r329q v3.0 and some other boards out there) works fine with 1T Command Rate, but don't boot with 2T Command Rate. This is way disappointing because the board freezes during initial boot with no other chances to interact with it.

Long story short: if you install a bad loader on NAND/eMMC on a small set of boards (like my r329q), you may brick it and you have to force maskrom mode (the serial console will print the infamous "Err!" message).

If you used my 660MHz loader that I posted on armbian forum, I may have set it CR incorrectly to 1T. I shall remove that loader which is not exactly stable for all boards.

Now, since the dram memory controller driver is available for mainline kernel, using that 660MHz loader is less than ideal for many reasons. I may suggest to you to erase the NAND using rkdeveloptool and let the LibreELEC image boot with its own loader (which uses 2T Command Rate, as like as LE9.2 builds) and see if your board is stable that way.

If it is stable, I can give you a properly compatible loader for your board so you could also install and boot libreelec from internal NAND.

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

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 ]---

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:

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>;
        };

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

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.

Quote from oneillb

Hi, I'm a complete newbie so please be patient...

I've been experimenting with the 20220329 LE 10 nightly build on my TV box booting from SD card, and it's been really stable, I'm really impressed with it, performance is so muhc better than Kodi on the Android 7.1 installation previously. Even the remote and wifi worked out of the box ( for some reason I cannot SSH into the box over wifi yet, but that may be and issue on my network tbh. possibly wireless isolation is on )

My TV box is branded as SMBOX SM1, but I've has a look inside and it looks like the R329Q v3.0 board seen in many of the others e.g. MXQ 4k

I'd like to burn the image to internal memory. I have a Multitool image on another SD card, which reports that the device is equipped with NAND, rather than eMMC

I backed up the Android image, then erased the flash using Multitool options 1 and 3. I then burned the LibreELEC-RK322x.arm-10.0-nightly-20220329-c3a59e9-rk322x.img.gz image file using Multitool (option 4 - skipping the idbloader area as recommended by Multitool) , which completes in about 45 seconds, but afterwards the device does not boot from the internal storage.

The .gz image was burned very quickly to the internal storage (when compared with a restore of the android image)... Do I need to unpack / ungzip the image before writing to NAND?

Restoring the original Android from backup was successful but took approximately 20 minutes.

Am I doing something wrong?

Thanks,

Barry

Display More

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)

Quote from dale

Hi,

Please take a look at miniloader. I got it from jock2 on armbian forum. Trust & uboot from your tar version which also don't work for me. Here are trust & uboot for your reference link

Since you apparently removed the original idbloader (of which the miniloader is part), you have to follow two procedures I described in the armbian forum first post under the paragraphs:

1. first restore a working idbloader: "NAND bootloader upgrade"
2. install a special u-boot that allows USB boot: "Installation (without SD card, board with NAND)"

Then you finally can put multitool and libreelec image on a USB stick and boot from there, using the "Burn image to flash" menu item.

It's a longer procedure, but unfortunately you have the worst combo ever (no sdcard slot and NAND flash chip).

A serial adapter attached to the box UART is very welcome, otherwise you're blind in case of issues.

Quote from alexwhites

Hi,

I tested the new build and I can confirm that it works (also ssv6051p wifi is ok, even if, quite strangely, I cannot ping the device and I cannot access via ssh over wlan interface, but outbound Internet connection is ok)

Thank you

Regards

It is my opinion that it is strangely refusing to answer ARP "whois" network requests; once the 6051p successfully sends a packet onto the network, other network hosts discovers the MAC address of the 6051p and switches can finally route packets correctly.

Quote from alexwhites

Hi ilmich,

the legacy image that I'm using is the LE 9.2 image by Knaerzche, but I tested this image:

LibreELEC-RK322x.arm-9.2-devel-20220124165557-3ce5dd4-rk3229-v88mars.img.gz

and it also works.

Also the very first build of LE10 works (but no wifi)

Do you have the chance to post a link to the original firmware or an upgrade firmware for your box?

Quote from alexwhites

Hi ilmich ,

no it seems that the box gets stuck and cannot finish booting since I don't see dhcp requests coming from its mac address

Thank you
Regards

Seems rather a crash to me.

Is the screen just a monotone green or there is some kind of visible image?

I Just want to notify that ilmich provided a beta LibreELEC 10.x image in its own thread with Kodi Matrix and mainline kernel!

chewitt thanks for the moral support

It would be a nice pet project, it could be useful to learn how to write a wireless driver for linux, yet I need to figure out where to start from; mostly I miss the background knowledge of kernel context, with its rules and function helpers. I would really love to read a valid book about kernel programming, but I just found ancient resources from 10 years old ago or even more. Kernel is a moving target, 10 years are quite too much...

BTW icomm company seems to have took over SSV and they show ssv6256p on their site, but not ssv6051p; I guess the ssv6051p is just a so old and discontinued part that it is not interesting at all for the company. For my point of view, it is still a valid chip that deserve a decent driver.

About the realtek clone, I heard about that for other chips, but never for ssv ones. I inspected the ssv source code but never found any hint about realtek compatibility. It looks to me that it is an ancient style code wrote by kernel newbies because there is tons and tons of boilerplate code that is totally useless nowadays and could be just thrashed away with no pain. I'll keep you updated if I try this feat

I adjusted the ssv6x5x driver to work on armbian with legacy 4.4 rockchip kernel only. The driver is a huge mess. When compiled it turned out to be several megabytes, which is just wrong since a wifi driver should not be bigger than 50-100 kbytes.

I would really like to start a project to rebuild a fresh new simple driver for ssv6256p and ssv6051p as knaerzche suggested to me some months ago, but yet I'd like to introduce myself to kernel wifi module programming first, which may take a looong time...

The chip, although, proved to work pretty fine with nice throughput even with the onboard antenna!

jimjack12 incredible! They messed the signature on the chip! I have heard about faking the strings in Android to let the box appear with other SoCs, but this fake is another level!

The board is clearly a dusty rk322x board. r329q boards are well known out there.