CSC Armbian for RK322x TV box boards

[fabiobassa]

@audio kees

for me too is strange libreelec is bricking your board.  Sure this don't happen on emmc and old nand with legacy kernel , but you have ecmp so maybe devil is in details.

On this same thread and on libreelec forum there is a man @ilmich .

He is the libreelec' s MASTER (lol),  he is a friend  and always prone to answer and find solutions.

Let's ear directly from him his opinion. So I find usefull now you move on libreelec forum since here is more specific to armbian, linux and hardware problems related, all problems that seems to be solved

Anyway I guess it should boot and work smoothless even libreelec on this ecmp , but I'm not the one that can answer

Edited February 24 by fabiobassa

[HurlingSand]

Hi,

Has anyone ever managed to get SV6158 Wi-Fi chip working?

The original ssv6x5x driver in the 4.4 legacy kernel didn't seem to do the trick.

I've tried switching between the mainline, legacy, and edge kernel to no avail.

 

Here's the chip dataset for reference: http://www.icomm-semi.com/Uploads/Temp/files/2022-08-18/SV6158 Datasheet V1.2.pdf

 

Looking forward to your answer, thank you.

[audio kees]

@hurlingsand I have a sv6256p chip, do not work also.

 

@fabiobassa I have read your tips. I have install armbian, different images, do boot

just fine, but is not a desk top, I do not like command line versions, I am to green for that.

 

Mine goal is a player who has spdif and build a dac for high end. Need a good board.

 

Maybe here somebody can tip me what board I can use best for 4k video hevc and spdif out

and very good audio out, maybe a opamp output I can replace for a high end one or connect 

the dac there.

 

yes it is some big question but the box I have now, the rt3318 has none of that, the box is gleu shot

and is very tiny and get ver4y hot, it does not 4k, it just plays bad, again a promise on ali who

do not work.

 

I am better of with a good board, and you guys do now.

 

Another question, yes I have a lot, I did try to connect the 905w box to the network and give a ip  from

what I tought it was the right one, I have done something wrong making mine computer see only a unkwown

network, reset of the bios did not work, starting a test linux also can not start the network adapter on bios,

give error, I can test the network in bios, it give length of cable and speed, but do miss dns.

 

Somewhere the network is connected with, and it is somewhere in hardware.

 

So now I am on wifi.

 

regards

 

 

 

 

 

 

[audio kees]

Hi there

 

 

I get a tip to ask here the question about a tv box rt3229 mxq 4k, I have a libre elec image who do work on SD, but when I install

it on Emc (I have the dreadfull nand/ram chip) the box is bricked, I have set it back to maskrom mode with a wire after tips from here

how to find these,  thanks for that.

 

When I install arm, it boot just fine from Emc by the way.

 

I am busy build a tube output high end dac, who needs a digital out, the sound from the rockschips are bad.

 

Maybe buy a very good pcb with a modern arm or amlogic chip is an idea, it needs to be quality 4 k hevc capable and sound needs

to get out through a opamp soi I can chnage that for a good opamp like burr brown.

 

I need high end because I have a hybrid designed who is a high end amp tube/mosfet.

 

thanks in advance.

 

 

Edited February 25 by audio kees

[jock]

@audio kees if your need is just play video at 4k you probably won't go with armbian but rather with libreelec; if your goal is playing music you'd probably want to go with volumio either. Armbian is suited mostly for linux desktop replacement and server-like tasks.

Said so, tv boxes are the worst choice around in any case, especially if you choose among the lowest budget.

Much better if you go with properly supported Single Board Computer (SBC) and, as said, you'd better take a look to what libreelec suggests as preferred hardware (probably Raspberry Pi) if you want/need an out-of-the-box working system.

 

 

 

[jock]

2 hours ago, HurlingSand said:

Has anyone ever managed to get SV6158 Wi-Fi chip working?

From the datasheet it seems interesting, but no, never seen such chip and never seen a driver for it

 

[fabiobassa]

@audio kees
 I do agree with @jock

libreelec is not a bad idea, it works fine with tv, iptv ( LEGAL contents) , with dvb usb tuner dongle and with all media .

Volumio is interesting, too

Armbian is for ssh, nas, voip pbx, vpn, servers, and all the stuffs network related that  linux is capable of.

If you want high level media performances, just leave  in a corner the 15 dollars tv box ( that work lovely thought) and go on well supported platforms as jock is suggesting you.

But again , please open a new thread if you like, so we can keep this discussion about rk322X hardware/booting/hdmi and so on  related problems.

And thank you for spotting the emc/nand clock pin

[audio kees]

THis was also the intention, I have install armbian to check the boot capabilities.

 

the Libreelec is what I want to use for that, however it does not boot from emc,

it boot from sd, after power off it does not wake up, and when I let it boot again

(the first time it go fine) I get errors and gargabe need correct, what it does with a lot of

tekst, it is like windows hd check utility.

 

regards

[audio kees]

This libreelec do boot on sd, but copy it to internal is rule two, doing it with multitool

it does not boot at all. do first armbian and then libre, things go even more bad.

 

I go think about a raspberry pi are there levels in this? like 4 and what cpu,s is best.

 

Yes these tv boxes are nice playtools.

Edited February 25 by audio kees

[SteeMan]

@audio kees  You really need to take your questions elsewhere.  You are off topic for this thread.  Please take your libreelec questions to to their support channels.  If you want to talk armbian on raspberry pi then open a new thread in the proper location in these forums. 

[audio kees]

Hi

 

You are right, maybe best to go to libreelec forum also.

 

I do not use armbian, but the multitool only, armbian is indeed for network

I do just entertainment at home like movies. I do think about a raspberry 4 or

5 for this purpose, but I see not a board who has also digital audio out on 

this boards.

 

thanks all.

Edited February 25 by audio kees

[svdmk]

Tv box mxq pro 4k 5g, pcb zq01-v1.3 rk3228a and kingston 08emcp08-el3cv100, wifi esp8265.
Multitool boots properly but after a minute the box turns off(Libreelec has same behavior).
This minute is enough to erase emms but not enough to flash img on board and bricks the device.
Rkdeveloptool works great in maskrom mode and I managed to burn loader and image.
I tried Armbian_21.02.1_Rk322x-box_buster_legacy_4.4.194.img , Armbian_23.08.0-trunk_Rk322x-box_buster_edge_6.5.5_minimal, Armbian_23.11.1_Rk322x-box_jammy_current_6.1.63_minimal and self compiled Armbian-unofficial_24.2.0-trunk_Rk322x-box_bookworm_edge_6.7.5_minimal on emmc and sd card with no success.
Every time booting process stops and every time on different point despite of so many reboots, and after a minute the box turns off.
I noticed with fresh written on emmc Armbian_21.02.1 , Multitool works properly (libreelec too). So I decided to try Armbian-unofficial_24.2.0-trunk on sd card and after more than 20 reboots I managed to set root password and Armbian works fine on sd card. Multutool , Armbian and Libreelec works from sd card on this strange decice only if there is partitision with filesystem on emms,  othervice it turns off after a minute.
I tried to install Armbian from sd card to emmc with armbian-config with no luck, box does not boot from emmc and from sd card again turns off after 1 minute.
Any suggestions how to install Armbian on internal flash?
Why Armbian needs so many reboots to reach finish point?

[audio kees]

I had also a problem with this kind of board, using multitoool to burn libereelec on it, seems it has to do 

with what kind of kernel is used, I have now done LibreELEC-RK322x.arm-10.0-nightly-20230925-65bd849-rk322x.img

on the box with multitool and suprisenly it start fine from emmc now, while a other did brick the box and need 

perform the clock ground tactic..

 

This img is not good also, but it is nightly so not formal, I can watch video very nicely, whole evening hevc. Good

sound.

 

I did also Arbian before, to test box, and these did boot fine, but it is a command tool environment for other purposes.

 

regards

[RaptorSDS]

vor 21 Stunden schrieb svdmk:

Every time booting process stops and every time on different point despite of so many reboots, and after a minute the box turns off.

thats look like a power or thermal problem maybe , did you managed to try (sdcard or usb) with cpu-stability to overlays= line in /boot/armbianEnv.txt

or verbosity=7 and look in the Serial log maybe still always same step where it break

 

hope you have a serial adapter at the box

[svdmk]

On 2/26/2024 at 9:24 PM, RaptorSDS said:

thats look like a power or thermal problem maybe , did you managed to try (sdcard or usb) with cpu-stability to overlays= line in /boot/armbianEnv.txt

It is not power or thermal issue, if there is partition with filesystem on emmc, Multitool  Armbian and Libreelec works from sd card flawlessly.
I have resolved problem running Armbian on sd card, I still can't install Armbian on internal emmc.
I tried different overlays: cpu-stability, emmc, emmc-hs200, ddr3 and other with no success.
Probably that is wrong settings of emmc, I will check internal flash with mmc-utils.

[jock]

@svdmk what you found is very interesting.

The issues regarding the automatic shutdown after 1 minute are probably related to a piece of closed source blob (the "Trust OS"). Most of the time it never causes issues, but on some systems it looks like it triggers this automatic shutdown or suspend state for unknown reasons.

 

Normally you don't need to do all this hassle to install armbian, neither there is the necessity for any reboot. It is the combination of the Trust OS and your board that triggers this unexpected behaviour.

 

Also your board is totally new on this forum, I have never seen such zq01-v1.3 board, if you can please post photos of the board and the original device tree (or the whole firmware, if you can).

 

So if I understand correctly, you flashed a piece of Armbian 21.02.1 on the eMMC, then you were able to boot armbian 24.2.0 from sdcard and it tooks 20 reboots to finally reach the user creation phase and login, but once you get there, it finally works for and indefinite time and does not reboot/turn off?

 

[mydeardiary]

On 2/20/2024 at 9:56 PM, mydeardiary said:

Installed sway and lima gpu is being utilized. But before I can access the lima gpu, I have to add my login to render group.

Update: glmark2-es2-wayland scores for lima mali400 gpu running on sway headless session is around 115.

 

=======================================================
    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      lima
    GL_RENDERER:    Mali400
    GL_VERSION:     OpenGL ES 2.0 Mesa 22.3.6
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   800x600 windowed
=======================================================
[build] use-vbo=false: FPS: 144 FrameTime: 6.952 ms
[build] use-vbo=true: FPS: 185 FrameTime: 5.430 ms
[texture] texture-filter=nearest: FPS: 212 FrameTime: 4.737 ms
[texture] texture-filter=linear: FPS: 207 FrameTime: 4.838 ms
[texture] texture-filter=mipmap: FPS: 226 FrameTime: 4.435 ms
[shading] shading=gouraud: FPS: 123 FrameTime: 8.195 ms
[shading] shading=blinn-phong-inf: FPS: 109 FrameTime: 9.250 ms
[shading] shading=phong: FPS: 84 FrameTime: 11.953 ms
[shading] shading=cel: FPS: 60 FrameTime: 16.719 ms
[bump] bump-render=high-poly: FPS: 49 FrameTime: 20.620 ms
[bump] bump-render=normals: FPS: 202 FrameTime: 4.973 ms
[bump] bump-render=height: FPS: 171 FrameTime: 5.853 ms
[effect2d] kernel=0,1,0;1,-4,1;0,1,0;: FPS: 56 FrameTime: 18.176 ms
[effect2d] kernel=1,1,1,1,1;1,1,1,1,1;1,1,1,1,1;: FPS: 22 FrameTime: 46.372 ms
[pulsar] light=false:quads=5:texture=false: FPS: 281 FrameTime: 3.561 ms
[desktop] blur-radius=5:effect=blur:passes=1:separable=true:windows=4: FPS: 29 FrameTime: 34.857 ms
[desktop] effect=shadow:windows=4: FPS: 92 FrameTime: 10.950 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 40 FrameTime: 25.293 ms
[buffer] columns=200:interleave=false:update-dispersion=0.9:update-fraction=0.5:update-method=subdata: FPS: 40 FrameTime: 25.563 ms
[buffer] columns=200:interleave=true:update-dispersion=0.9:update-fraction=0.5:update-method=map: FPS: 52 FrameTime: 19.344 ms
[ideas] speed=duration: FPS: 64 FrameTime: 15.756 ms
[jellyfish] <default>: FPS: 62 FrameTime: 16.169 ms
[terrain] <default>: Unsupported
[shadow] <default>: FPS: 57 FrameTime: 17.550 ms
[refract] <default>: FPS: 10 FrameTime: 100.697 ms
[conditionals] fragment-steps=0:vertex-steps=0: FPS: 219 FrameTime: 4.579 ms
[conditionals] fragment-steps=5:vertex-steps=0: FPS: 117 FrameTime: 8.591 ms
[conditionals] fragment-steps=0:vertex-steps=5: FPS: 221 FrameTime: 4.540 ms
[function] fragment-complexity=low:fragment-steps=5: FPS: 159 FrameTime: 6.322 ms
[function] fragment-complexity=medium:fragment-steps=5: FPS: 77 FrameTime: 13.067 ms
[loop] fragment-loop=false:fragment-steps=5:vertex-steps=5: FPS: 153 FrameTime: 6.570 ms
[loop] fragment-steps=5:fragment-uniform=false:vertex-steps=5: FPS: 150 FrameTime: 6.690 ms
[loop] fragment-steps=5:fragment-uniform=true:vertex-steps=5: FPS: 57 FrameTime: 17.550 ms
=======================================================
                                  glmark2 Score: 115
=======================================================

 

 

The cpu temperature hits 75 degree during glmark2-es2-wayland test run.

Edited February 28 by mydeardiary
fix formatting

[svdmk]

22 hours ago, jock said:

So if I understand correctly, you flashed a piece of Armbian 21.02.1 on the eMMC, then you were able to boot armbian 24.2.0 from sdcard and it tooks 20 reboots to finally reach the user creation phase and login

That's right.
I use multitool only to erase internal flash and then use rkdeveloptool to flash loader and image as it is described in first page.
The device boots from sdcard in both cases, blank or flashed emmc but if there is a proper partition on internal flash Armbian works right, otherwise turns off(I heve tried to erase emmc and create partition with fdisk tool in Armbian, and OS works properly ). Armbian boots from internal flash too.
I think booting issue and turning off after minute are two different cases. Turning off probably is some kind of interaction between RAM and EMMC into EMCP chip itself(kingston 08emcp08-el3cv100).
This is dumped android firmware:
https://drive.google.com/file/d/1ZLl-KCvGS47SAO8tY1YDvCHDv6YWIWRP/view?usp=sharing

Edited February 28 by svdmk

[MattWestB]

@svdmk Thanks for sharing the knollage !!

Did you also finding the console comport on the PCB ?

[jock]

@svdmk Thanks for posting the photos and the firmware!

I took a look to the device tree and found something that could be somehow intersting. I'm not absolutely sure it may be related to your issue, but there the device tree contains this gpio switch which is not usual:

 

gpio_poweroff {
                compatible = "gpio-poweroff";
                gpios = <0xb3 0x11 0x01>;
                status = "okay";
        };

it maps to gpio3 bank and pin 17 (PC1, in the rockchip documentation). That string says that the pin is active low, it means that when it is 0, the poweroff is active; when it is 1 the poweroff is inactive.

 

I may assume that gpio pin is used by the operating system to power off the system.

On other board that pin is not mapped in the device tree, so I may also assume it is not used anywhere.

In your case may (or may not) be related to the weird behaviour you're experiencing.

 

With this command (to be run as root), you can see how the pins is configured. In my case, the pin is set to output at 0 level, but since it is not wired on my board it just does not do anything. Could you please execute the same command on your board?

# grep 'gpio3-17' /sys/kernel/debug/pinctrl/pinctrl-rockchip-pinctrl/pinconf-pins
pin 113 (gpio3-17): input bias pull down (1 ohms), output drive strength (8 mA), pin output (0 level)

 

You can also control that pin:

# cd /sys/class/gpio
# echo 113 > export
# cd gpio113

# cat direction
in

# cat value
0

# echo out > direction
# cat direction
out

# echo 1 > value
# cat value
1

# echo 0 > value
# cat value
0

 

with echo 113 > export you will make the pin available for userspace, then a directory gpio113 will spawn and you can echo to direction and value to change the pin as input or output and switch levels.

If the pin is actually wired to something, it may be that when you switch direction of level the board may suddenly turn off.

 

Now you can also do another test: erase the emmc and verify you still have the shutdown issue. If that is the case, it may be interesting to see what is the pin state in that condition and if switching its condition causes the weird behaviour to stop or does not change anything.

[svdmk]

On 3/1/2024 at 12:43 AM, jock said:

with echo 113 > export you will make the pin available for userspace, then a directory gpio113 will spawn and you can echo to direction and value to change the pin as input or output and switch levels.

If the pin is actually wired to something, it may be that when you switch direction of level the board may suddenly turn off.

Nothing happens when I change direction and value.
When I do software reboot the direction and value remain the same but if I do power reboot the direction and value return to their original state.The issue remains, system still switching off.

But I noticed that deleting the flash partition, the system works normally. I used to think that the system was working because it founds a correct partition in the flash, but when mmcblk2p0 is no longer there,
remains only that part of the armbian image before the root file system, which is before sector 8192. Blank emmc or flashed with newer armbian image cause problem but flashed with armbian 21.02.1 the OS works.

[jock]

@svdmk ok so that gpio-poweroff is a leftover or some copy/paste from another board done by the manufacturer.

 

The more I read the more I think it is related with the trust os: when you leave the first 8192 sectors from armbian 21.02.1 on the eMMC, you actually leave all the boot pieces there. The boot process is made of 4 pieces: ddrbin, u-boot SPL, Trust Os and u-boot.

Rockchip devices always boot from eMMC first, so whatever you put in the sdcard, the boot process always happens in the eMMC, then u-boot steers to the sdcard.

 

My best guess for your problem is that armbian 21.02.1 bootloader still had OPTEE opensource Trust OS I was using in the past (see here for source code); it is the same base that also rockchip uses for its Trust OS, but rockchip proprietary trust os has some closed-source code that is added on top for added features like DDR clock scaling and virtual poweroff and who knows what else... Nowadays I use the rockchip proprietary optee for those added features, but very seldom it causes issues like yours and it is impossible to debug because it is closed source.

 

What you can do in the meantime, hoping it works

• install armbian 24.02 on the emmc via multitool using the regular burn to image function
• then get a shell and do a dd to copy the bootloader from armbian 21.02.1 image over the 24.02

u-boot and Trust Os are "packaged together". The package starts at sector 0x200 AFAIR and is around one megabyte large, but I suggest to you to copy all the bootloader that starts at 0x20

 

A command like this would do the trick: (of course change armbian21.img with the actual image)

dd if=armbian21.img of=/dev/mmcblk2 skip=32 seek=32 count=8160
sync

 

Or, if you have the .xz compressed image:

xz -c -d -k armbian21.img.xz | dd of=/dev/mmcblk2 skip=32 seek=32 count=8160
sync

 

Then you should be able to boot multitool, libreelec and armbian from sdcard and also armbian should boot from eMMC without issues.

I will have some confrontation with @fabiobassa and @ilmich to see if there is a viable general solution.

[fabiobassa]

@jock

I do agree with  you, this is another case of " frankenstein needed! : some pieces from one, other pieces from others ..

Not very clean solution but in might work

Since those days when we starting case study of 322x shutdown and reboot issues were quite always, if not alaways , related to TRUSTOS so using the " legacy-proprietary" trustos and uboot for booting and then pass control to main kernel and rootfs could ipothetically work

[svdmk]

4 hours ago, jock said:

• install armbian 24.02 on the emmc via multitool using the regular burn to image function
• then get a shell and do a dd to copy the bootloader from armbian 21.02.1 image over the 24.02

Everything is OK, strange but working solution.

Now when the box does not turns off I was able to add overlays in armbianEnv.txt ( emmc-hs200 and ddr3-800) and armbian booted at first time.
Now I have armbian on internal flash and can install octoprint server.

Big thanks @jock

Edited March 2 by svdmk

[RaptorSDS]

vor 3 Stunden schrieb fabiobassa:

frankenstein needed!

 

vor 3 Stunden schrieb fabiobassa:

quite always, if not alaways , related to TRUSTOS so using the " legacy-proprietary" trustos

When we now see thats is a moreover need part maybe it is also a good idea to integrate a point in Multitool where a this 2MB part is flash to emmc or nand to replace the bootloader from normal Armbian image

[jock]

36 minutes ago, RaptorSDS said:

When we now see thats is a moreover need part maybe it is also a good idea to integrate a point in Multitool where a this 2MB part is flash to emmc or nand to replace the bootloader from normal Armbian image

The problem with this is that on next bootloader upgrade via apt upgrade, any custom solution will be wiped away and being overwritten by the regular bootloader.

I can reinstate the opensource optee as Trust OS, which seems to be more compatible, but we lose DDR clock scaling - that increases a lot the general performances - and virtual poweroff from the closed source rockchip Trust OS. Which one to choose?

[RaptorSDS]

vor 2 Stunden schrieb jock:

which seems to be more compatible, but we lose DDR clock scaling - that increases a lot the general performances - and virtual poweroff from the closed source rockchip Trust OS. Which one to choose?

thats maybe a point which be can handle by multitool where the user has a option point (choose) ,

 

when have problem be more compatible (perfomance reduce) optee ,

when perfomance (with my incompatiple eg power-off ) flash TrustOS

 

 

maybe with a hint that after a apt-Upgrade procedure has to renew

 

[jock]

1 hour ago, RaptorSDS said:

maybe with a hint that after a apt-Upgrade procedure has to renew

It is not possible unfortunately. The bootloader is built and packaged by armbian scripts, it is not supposed to have two different boot loaders for the same "board".

Once the deb package with the bootloader is downloaded, it is unpacked and a script is run to upgrade it.

The only thing I may think about is a flag somewhere on the filesystem that is checked by the script and avoids the real bootloader upgrade.

 

Or people can manually do apt-mark hold linux-u-boot-rk322x-box-current to avoid the bootloader upgrade and that's it

[RaptorSDS]

vor 38 Minuten schrieb jock:

The only thing I may think about is a flag somewhere on the filesystem that is checked by the script and avoids the real bootloader upgrade.

When a script is possible than uENV.txt should be the best point , also in thinging of rk322x-config where a question for user can be implement 

 

my thought was more that we support Multitool with 2 small xz files extractet  and from 24.xx image and 21.01.01 image ( maybe later get update in newer  multitool version) , and when he has problem he can use a new item point where the bootloader get write like the script above

 

 

 

 

#!/bin/bash

set -e

# Path
UENV_FILE="/boot/uENV.txt"

# read variable out of uENV
UPGRADEBOOT=$(grep -Po '(?<=Upgradeboot=)\d' "$UENV_FILE" || true) 
#or this maybe better 
UPGRADEBOOT=$(grep -Po '(?<=Upgradeboot=)\d' "$UENV_FILE" || echo "1")

# Proof, Upgradeboot=0 
if [ "$UPGRADEBOOT" -eq 0 ]; then
    echo "Upgradeboot is deactive, Installation abort." >&2
    exit 1
fi

preinstall script

Edited March 2 by RaptorSDS

[Wh1t3st4r]

Hello all,

 

I tried making the procedure and it all worked until I erased the flash memory and tried booting up Armbian, I have an MXQ Pro 4k tvbox with a board that uses NAND so I did the procedures that it's recommended for it. However it was stuck in boot and trying to restore the backup I made did not restore it, so I tried following the steps to upgrade the bootloader as it solves not being able to boot images; but when I put the usb-to-usb io the computer and the board, it is not recognized, both red and blue lights turn on but not completely, in contrast when the board is turned on a bright blue light glows, but there instead the dim blue and red light appears. Am I doing something wrong? Am I maybe not in maskroom mode? And finally, I can use the multitool even though the board is stuck on boot, can I do the same procedures of rkflashtool in the local shell or something? 

 

Thank you all in advance and sorry for any inconveniences.