CSC Armbian for RK3318/RK3328 TV box boards

[ANKH]

@jock, here is another log

https://pastebin.com/pGU6rLah

Here are errors:

 3957	[    2.804106] mmc_host mmc4: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
  3958	[    2.804204] mmc4: error -84 whilst initialising SDIO card
  3959	[    2.804404] dwmmc_rockchip ff5f0000.mmc: card claims to support voltages below defined range
  3960	[    2.808379] mmc4: error -110 whilst initialising MMC card
  3961	[    2.831332] mmc_host mmc4: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)

 

Edited July 22, 2023 by ANKH

[jock]

Here come another, I hope this is the last one 🤞

rockchip-rk3318-box-led-conf5.dtbo

[ANKH]

@jock, here is the new one

similar errors - http://ix.io/4BoF

 

Spoiler

[    2.927180] mmc_host mmc4: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    2.927306] mmc4: error -84 whilst initialising SDIO card
[    2.927495] dwmmc_rockchip ff5f0000.mmc: card claims to support voltages below defined range
[    2.931495] mmc4: error -110 whilst initialising MMC card
[    2.954850] mmc_host mmc4: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
[    3.106182] mmc_host mmc4: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    3.106285] mmc4: error -84 whilst initialising SDIO card
[    3.106518] dwmmc_rockchip ff5f0000.mmc: card claims to support voltages below defined range
[    3.110491] mmc4: error -110 whilst initialising MMC card
[    3.137021] mmc_host mmc4: Bus speed (slot 0) = 100000Hz (slot req 100000Hz, actual 100000HZ div = 0)
[    3.400741] mmc_host mmc4: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
[    3.400865] mmc4: error -84 whilst initialising SDIO card
[    3.401092] dwmmc_rockchip ff5f0000.mmc: card claims to support voltages below defined range
[    3.405216] mmc4: error -110 whilst initialising MMC card
[    3.767559] input: adc-keys as /devices/platform/adc-keys/input/input2

sorry for bothering you

 

upd:

added a new full log file( pasted file seems to be not full)

devicelog2

Edited July 25, 2023 by ANKH
add new log

[dicky soeliantoro]

Hi @jock

sorry for the trouble..

But I have tried your suggestion, even using the latest one :

Armbian_23.8.0-trunk.89_Rk3318-box_bookworm_edge_6.3.13_xfce_desktop.img.xz

I got armbian running ok.

But I still cannot get wifi and bluetooth working.

Processor = Rockchip RK3328
Wifi + BT = Realtek RTL8723CS

Please help.

if you need any log files or anything, can you please inform me.

thanks,

Edited July 25, 2023 by dicky soeliantoro

[jock]

@ANKH This is the last thing that can be changed, so try this other one and let's hope 🤞

rockchip-rk3318-box-led-conf5.dtbo

[ANKH]

@jock, maybe we should take a pause and get back to it later? no signs of wifi chip, log attached

 

 

rk3328log

[jock]

@ANKH I think there are no other things to try, so either we want or we don't, it's a dead end.

[Slash402]

I recently run an apt-upgrade and noticed there's a package held back: armbian-bsp-cli-rk3318-box. Is there a way to find out what the package is, why it was held back and if I should force upgrade it or not? Thanks.

[mkultra]

i must have been bored cos I decided to update to bookworm

which worked ok but somehow I ended up going from kernel 6.1.11 to 5.15.93 after I did an 'unhold' 

[LFPoulain]

Hi @jock,

Thank you so much for your hard work !

 

I recently purchased an X88 Pro 10 (X88 Pro-b-RK3318-d4-V1.6 board) and a T9 box (which I haven't opened yet).
Both seem to work great, but only with the stable images you provided and not the nightly or archived images.
With those, nothing happens - the box doesn't display anything on the screen, and I don't even get an HDMI signal.

Do you have any idea why this might be happening?

 

Thank you,

LFP

P.S : I have the backup file, how could I send you the DTB if needed ? 

Edited July 28, 2023 by LFPoulain

[jock]

3 hours ago, LFPoulain said:

Do you have any idea why this might be happening?

Yes, it seems that recent kernels have some kind of HDMI issue that makes them not displaying anything.

Unfortunately my rk33x8 boards are both working fine with current and edge kernels, so I can't replicate the issue and can't fix it.

 

Some people reported that there are patches from libreelec project that fix the problem, but as long as I can't try it myself, I can't selectively incorporate them into armbian. I tried in the past to import the whole libreelec patches, which include many fixes and better support, and also did a lot of patch rebasing work, but some maintainers where not happy, so I gave up.

[mkultra]

8 hours ago, jock said:

some maintainers where not happy, so I gave up.

oh no!

how can I update to the latest kernel? I looked here but no mention of rockchip https://github.com/armbian/community

I've got a fast arch PC so can I compile my own kernel using that?

thanks!

PS oh yeah, how do I change motd? I've got a 3328 (as well as a 3318)

[LFPoulain]

16 hours ago, jock said:

it seems that recent kernels have some kind of HDMI issue

So the board is booting right ? Is there anyway to apply SSH on boot ? I don't need HDMI as I'd like to use the board with docker and portainer

 

16 hours ago, jock said:

but as long as I can't try it myself

I'm ok to send you one of the 2 boards to try yourself ! That's seem fair to me with all the work you've done so far  



 

[jock]

54 minutes ago, LFPoulain said:

So the board is booting right ? Is there anyway to apply SSH on boot ? I don't need HDMI as I'd like to use the board with docker and portainer

You should try to access via ssh if you have a way to discover the IP address.

Some cases that have been discusses in the past, the board was reactive, just HDMI was not working right

 

54 minutes ago, LFPoulain said:

I'm ok to send you one of the 2 boards to try yourself ! That's seem fair to me with all the work you've done so far  

Actually I have to correct myself: I think that the real problem is related to the HDMI timings of the HDMI device and not exactly to the board itself. I don't know if this is exactly your case, but in the past reports people reported that the experimental image based upon a 5.19 kernel with the libreelec patches was working, where other kernels where not working at all.

 

Perhaps I could give a look into this weekend, and propose a minimal image with some tailored patches to see if they address the issue. This could be useful for other people with Orange Pi 4 LTS board (rk3399) that have lamented the same HDMI issues.

[LFPoulain]

5 hours ago, jock said:

You should try to access via ssh if you have a way to discover the IP address.

I'll try this as soon as I can !
 

5 hours ago, jock said:

that the experimental image

Where could I find it ? Is it a specific branch ?  

 

5 hours ago, jock said:

Perhaps I could give a look into this weekend, and propose a minimal image with some tailored patches to see if they address the issue.

I'll be glad to test the image if needed ! 

I have another question in mind, and I am greatly interested in the answer. I use Armbian because the power of these boxes is sufficient, their price is very reasonable, and also because the original Android firmware is riddled with malicious code. I am having a bit of trouble understanding the bootloader that allows the Multitool to start. Is it native to the CPU, or can it be modified by the box manufacturer ? I read that the Armbian image comes with U-Boot. Does this completely replace the original one? And most importantly, can there be malicious code at this level ? Thank you
 

[jock]

11 hours ago, LFPoulain said:

Where could I find it ? Is it a specific branch ?  

Yes, there is the old branch on my fork: https://github.com/paolosabatino/armbian-build/tree/rockchip64-patch-series , but your mileage may vary, I don't update it anymore.

 

11 hours ago, LFPoulain said:

I have another question in mind, and I am greatly interested in the answer. I use Armbian because the power of these boxes is sufficient, their price is very reasonable, and also because the original Android firmware is riddled with malicious code. I am having a bit of trouble understanding the bootloader that allows the Multitool to start. Is it native to the CPU, or can it be modified by the box manufacturer ? I read that the Armbian image comes with U-Boot. Does this completely replace the original one? And most importantly, can there be malicious code at this level ? Thank you
 

There are various stages chained together to boot the boards.

The armbian bootloader completely replaces the board bootloader, the only rockchip proprietary thing is the DDR memory initialization, which is the very first step.

All the further steps (U-boot SPL, Trust OS, U-boot and finally the kernel) are binaries compiled from opensource code by armbian scripts during image building.

 

In the android original image, instead, malicious code can be injected in any of the steps; the Trust OS is the most dangerous piece of code, because it runs with highest security level in a piece of memory even the kernel does not have access to. Whatever code is inside the Trust OS binary, you can't know anything about of what it does.

 

On armbian images, both Trust OS and U-boot are compiled from the mainline open source code available on github.

[LFPoulain]

Thank you very much for all these explanations ! 
I'll stick with the working image, and if you release the minimal image, I'll try a soon as possible  

[jock]

Here it is the experimental minimal image based upon kernel 6.3 with some video patches: https://users.armbian.com/jock/rk3318/Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img.xz

I did not test it at all, but should be sufficient to put it on a sdcard and boot with the sdcard inserted.

[LFPoulain]

Hi there !

It works ! But I have green lines jumping on the screen sometimes . But it's ok for configuring
Why is it 6.3 kernel instead of 6.4.7 ? And also 23.08 instead of 23.5 ?

Sorry if I bother you with my question ^^

Thank you very much for this minimal image

[ANKH]

Hello, @jock

After a bit of researching i found out that actually rockchip devices initialize wifi in rfkill and there are even some special drivers in kernel for it. I studied a source code of rfkill and saw there hardcoded names of device tree properties that are present in original device tree. There is armbian/linux-rockchip repository where those drivers are present. Maybe that's somehow could help with my case? Does your kernel image have them? Or is it dead end too?

Best regards)

Edited July 31, 2023 by ANKH

[jock]

3 hours ago, LFPoulain said:

It works ! But I have green lines jumping on the screen sometimes . But it's ok for configuring

Ok but you should provide some additional info about the display you are using; it could be an HDMI issue (timings, cables, especially with 2K/4K displays) or a box memory issue (unlikely).

I made some cut work against the original libreelec patches, and I really hope that it is not the cause of the issue.

3 hours ago, LFPoulain said:

Why is it 6.3 kernel instead of 6.4.7 ? And also 23.08 instead of 23.5 ?

Because the armbian patches have not yet been adapted to 6.4.x; everytime there is a new kernel it is not trivial to fix all the patches to make all the boards and all the wifi chips work, actually it is quite painful and time consuming task, especially for rockchip64 family which covers a huge amount of boards.

Also the armbian version is 23.08 because it is the next august release; the current release is 23.05 (not 23.5)

[jock]

@ANKH yes that's true what you found, but in mainline kernel there is no such thing like custom drivers for rockchip.

The problem is not the driver, but the communication with the wifi chip itself.

The kernel is not able to communicate the device via SDIO bus, so it is not even able to understand the vendor and device id of the chip.

Your problem is at the very hardware level, so the drivers are not yet involved in your case, and yet I don't understand if I did a mistake setting the GPIO strength values.

 

 

[ANKH]

@jock, but wifi was working with original firmware. Doesn't it implies that there is a kernel that can correctly start wifi? 

[jock]

9 minutes ago, ANKH said:

@jock, but wifi was working with original firmware. Doesn't it implies that there is a kernel that can correctly start wifi? 

Kernel has little to do, the problem lies within the configuration of the hardware part, so it is more a dtb issue rather than kernel/software.

[Seth]

On 7/31/2023 at 6:40 PM, jock said:

Here it is the experimental minimal image based upon kernel 6.3 with some video patches: https://users.armbian.com/jock/rk3318/Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img.xz

I did not test it at all, but should be sufficient to put it on a sdcard and boot with the sdcard inserted.

works like a dream @jock. here's my freshly installed/updated hk1 max box dmesg using latest libreelec hdmi patched 6.3.13 kernel. i hope mainline gets around to updating hdmi timing stuff. brcm 6334 2.4G and 5G works out of the box. using it currently as pi hole box.

 

for those having problems with rtl 2734c (rtl8237cs). wireless module that gets detected but cannot connect to AP, here's a reuploaded nvram you can try out (no guarantees though), it solved my problem way back with the rounded h96 max i am using as klipper host. file is not mine, credits to the original uploader.

dmesg.log nvram_2734c.txt

Edited August 6, 2023 by Seth

[Alex ThreeD]

Hi! I'd like to share my findings on running UxPlay AirPlay Mirror server on rk3328 box.

Default setup with x11 works quite bad on Armbian 23.05 (Armbian_23.5.1_Rk3318-box_bookworm_current_6.1.30_xfce_desktop.img).

Video playback falls behind of realtime both for default video output method (autovideosink) and for -vs xvimagesink/glimagesink.

At the same time uxplay with kmssink or waylandsink video output works without issues:

# chvt 2 
# uxplay -vs kmssink

In all these cases CPU usage are far from 400% and even lower than 100%, so I assume that 1080p h264 video stream are HW-decoded but there are some stalls happening in x11 graphic stack (xorg config 40-serverflags.conf doesn't help).

 

I've also ran glmark2 tests to confirm a problems with x11. OpenGL/GLES are 3-5 times less performant under x11 than under wayland/drm. 

rk3318-box:~:# glmark2 --fullscreen
    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      lima
    GL_RENDERER:    Mali450
    GL_VERSION:     2.1 Mesa 22.3.6
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   1920x1080 fullscreen
=======================================================
[build] use-vbo=false: FPS: 41 FrameTime: 24.919 ms
...
=======================================================
                                  glmark2 Score: 29
=======================================================

rk3318-box:~:# glmark2-wayland --fullscreen
=======================================================
    OpenGL Information
    GL_VENDOR:      lima
    GL_RENDERER:    Mali450
    GL_VERSION:     2.1 Mesa 22.3.6
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
    Surface Size:   1920x1080 fullscreen
=======================================================
[build] use-vbo=false: FPS: 207 FrameTime: 4.832 ms
...
=======================================================
                                  glmark2 Score: 98
=======================================================

 

[mkultra]

On 8/11/2023 at 8:40 PM, Alex ThreeD said:

In all these cases CPU usage are far from 400% and even lower than 100%

hmmmm, CPU usage is always <= 100%........basic maths bruv 

[jock]

On 8/11/2023 at 8:40 PM, Alex ThreeD said:

I've also ran glmark2 tests to confirm a problems with x11. OpenGL/GLES are 3-5 times less performant under x11 than under wayland/drm. 

 

You would try an Ubuntu distro and enable the oibaf repository to get cutting edge mesa.

Default mesa from debian and ubuntu is a bit older and does not contain specific fixes for mali-400/450

 

Oibaf repository is already set in /etc/apt/sources.list.d but the line is commented by default.

Removing the comment and then running apt update && apt upgrade should do the trick.

 

Also note that in X11 you may want to enable the vsync when possible, which turns out to perform much much better because with vsync on the driver will use page flipping, with vsync off will use buffer copy that reduces performances a lot.

[jock]

6 hours ago, mkultra said:

hmmmm, CPU usage is always <= 100%........basic maths bruv 

When you have 4 cores, you can achieve 400% cpu usage; top reports it that way.

[ercans]

@jock

 

i have h96 max plus rk3328 4gb/64gb (b0807). The device was bricked in the previous android rom update. At startup, the google installer runs and stays that way.

I want to install armbian on this device. I followed all the instructions in your first post. The device works very well from sd card with multitool. I copied the armbian version I gave to the image folder of the multitool. I made an erase flash with the multitool. And I burned it again with the multi tool. When I remove the sd card, the android google load screen still opens.

Why is my eMMC not being erased even though I have erased flash with the multitool?
For this reason, armbian cannot be started either. Even when I want to run armbian from the SD card, it does not see it, the google boot screen opens.

All I can do is boot the multitool from the sd card. Erase flash doesn't work.

I even short-circuited two pins on the motherboard in case the maskroom mode might work, but in vain.

I can't even eraseflash this device in maskroom mode with androidtool, or I can't get chip info in maskroom mode with androidtool.

What could be wrong with my device? How can we run this.
I would be very grateful for your support. Now it's a matter of greed