Jump to content

CSC Armbian for RK3318/RK3328 TV box boards

jock

By jock
in Rockchip CPU Boxes

 Share

Recommended Posts

jock

jock

Posted
  • Author
Posted

@ercans probably the eMMC is gone and is in read-only mode: multitool or other tools write to eMMC, the eMMC says "ok!", but actually nothing is really written.

That's a common condition when flash memories break.

Your chances are:

1) short circuit the eMMC clk pin forever

2) desolder the eMMC from the board (<--- you have to be very skilled for this)

3) substitute the eMMC with another one (<--- you have to be very very skilled for this)

 

you may also try to use dd from multitool command line shell and see if you can zero-fill the emmc or at least the first few hundred sectors to force boot from sdcard.

 

 

 

0
Link to comment
Share on other sites
ercans

ercans

Posted
Posted (edited)

@jock

 

Thank you very much for your reply.
I'm using windows, how can I switch to command line while running multitools on tvbox? I couldn't see an option for the multitools command line window.

 

edit: I think he had the same problem as me. Since the topic is closed, I can't ask how it rained. I want to run linux here somehow, even through the sd card. Can you help me do this?

 

 

 

Edited by ercans
0
Link to comment
Share on other sites
Alex ThreeD

Alex ThreeD

Posted
Posted (edited)

Hi @jock.

I've found my rk3328 box have stability issues on 1.2-1.3 GHz with default voltage in rk3318-box.dtb. It hangs out every few days with kernel oops or something alike.

It works fine with opp-microvolt values for 1.2-1.3 GHz taken from rk3318-a95x-z2.dtb (i.e +0.025V).

I'm not sure whether such increase are bad for other boards, probably you could consider making it a default in rk3318-box.dtb.

 

I've found a simple way to trigger stability issues: connect a display, run `glmark2`/`glmark2-wayland`/`glmark2-drm` and `armbianmonitor -z` in infinite loop simultaneously.

With `rk3318-box.dtb` voltages system hangs up in 5-10 minutes. With `rk3318-a95x-z2.dtb` voltages it runs for hours without issues.

Edited by Alex ThreeD
0
Link to comment
Share on other sites
jock

jock

Posted
  • Author
Posted
On 8/26/2023 at 5:34 PM, Alex ThreeD said:

I'm not sure whether such increase are bad for other boards, probably you could consider making it a default in rk3318-box.dtb.

Hello, sure it won't harm other boards, but your specific problem may be due to slow voltage regulation from low to high frequency state.

0.025v increase is very minimal that may not solve your stability issues in all cases, but just enough for a limited stress testing.

I'm not minimizing your finding, but perhaps the matter may be investigated a bit if you're curious you can:

1) raise the voltage only of the one or two lower frequency bins (600mhz and 800mhz) and then run the stress test and see if you gets issues

2) run the tests with "stock" voltages blocking the cpu to the highest frequency (cpufreq-set will do the job)

 

What I have seen on different boards is that some of them have a "lazy" power regulation that takes too long to raise the voltage to reach the right level, so when there is the frequency shift, it just gets unstable.

0
Link to comment
Share on other sites
Alex ThreeD

Alex ThreeD

Posted
Posted (edited)

Yeah, I've seen suggestions to lock cpufreq here on forum and checked it before starting voltage experiments.

Here are my observations (on RK3328 box):

1) I have not seen stability issues with stock rk3318-box install with default 1.1 GHz limit

2) Stability issues appear after enabling "RK3328 (max 1.3GHz)" option in rk3318-config

3) Locking cpufreq to 1.3GHz in armbian-config does not help to mitigate issues (I've verified that cpu frequency are actually locked in `htop` output)

4) I've changed boot dtb to rk3318-a95x-z2.dtb and disabled rockchip-rk3318-box-cpu-hs.dtbo overlay. With this setup there was no issues.

5) Finally I've changed back boot dtb to rk3318-box.dtb and activated a patched rockchip-rk3318-box-cpu-hs.dtbo overlay with increased voltages only for 1.2-1.3GHz. No stability issues both for a few hours of stress test and for a few weeks of common use.

 

Here is my patched rockchip-rk3318-box-cpu-hs.dtbo source: 

/dts-v1/;

/ {

	fragment@0 {
		target-path = "/opp_table0/opp-1200000000";

		__overlay__ {
			opp-microvolt = <0x12b128>;
			status = "okay";
		};
	};

	fragment@1 {
		target-path = "/opp_table0/opp-1296000000";

		__overlay__ {
			opp-microvolt = <0x13d620>;
			status = "okay";
		};
	};
	fragment@2 {
		target-path = "/opp_table0";
		__overlay__ {
			opp-408000000 {
				opp-hz = <0x00 0x18519600>;
				opp-microvolt = <0xe7ef0>;
				clock-latency-ns = <0x9c40>;
				opp-suspend;
			};
		};
	};
};

 

As you see I've also added 408MHz setting, but it is probably not needed. I've seen no measurable difference in power consumption at 400MHz vs 600MHz.

 

29.08.2023 в 22:13, jock сказал:

1) raise the voltage only of the one or two lower frequency bins (600mhz and 800mhz) and then run the stress test and see if you gets issues

I haven't tried it yet. I could check it if you find it useful

Edited by Alex ThreeD
0
Link to comment
Share on other sites
mkultra

mkultra

Posted
Posted (edited)

ok so I played with my RK3318 box yesterday...

first I switched to 'beta repository' in armbian-config and ended up with 6.4.13-edge-rockchip64

then I updated to bookworm.....all good

today I changed the sources.list.d as I noticed docker was still pointing at bullseye

after an update I ended up with:

Welcome to Armbian 23.11.0-trunk.15 Bullseye with Linux 6.1.51-current-rockchip64

it was on trunk.7 yesterday but can't recall if that said Bullseye or Bookworm, doh

I went back into armbian-config, changed to stable build, back to beta build but it's still on 6.1.51

any way to get back to 6.4.13?

not urgent, it's more for learning as much as anything else :)

thanks

EDIT: update next day.....back to working, must have been a glitch in the matrix :mellow:

Welcome to Armbian 23.11.0-trunk.18 Bookworm with Linux 6.4.14-edge-rockchip64

Edited by mkultra
0
Link to comment
Share on other sites
jock

jock

Posted
  • Author
Posted
4 hours ago, Seth said:

hello, i got a new rk3328/3318 box and it is an MX10 box. board is MXQ-RK3328-D4_A ver: 2.0 date:20181219. i was wondering if anyone has the same board as mine and got armbian running on it. here are pics of the board.

I got it, I don't remember if it is v2.0, but perhaps it is a v1.4; anyway it works flawlessy on my case, it has a specific led-conf because it carries the rk805 pmic that is required to make operational before trying to raise cpu frequency

1
Link to comment
Share on other sites
Seth

Seth

Posted
Posted
15 hours ago, jock said:

I got it, I don't remember if it is v2.0, but perhaps it is a v1.4; anyway it works flawlessy on my case, it has a specific led-conf because it carries the rk805 pmic that is required to make operational before trying to raise cpu frequency

thanks, will try it out and upload serial logs after i solder the wires on it. got a bit distracted since i'm currently cleaning up the other box from junk and trying to reflash and reinstall pihole.

0
Link to comment
Share on other sites
markst

markst

Posted
Posted (edited)

I have a X88 pro 10 box with a RK3318 chip. I have installed Armbian_22.05.0-trunk_Rk3318-box_bullseye_current_5.15.35_minimal.img using the Multitool to the internal eMMC.

This Installation worked fine.

 

Question#1
I'm having a problem rebooting. If I use at the cli 'sudo reboot' the box will not reboot. If I physically power cycle the box it reboots ok.

After installing I used the following that i found in the forums 'sudo apt-mark hold linux-image-current-rockchip64 linux-dtb-current-rockchip64' then i updated with apt-get update and apt-get upgrade 

Is anyone having the cannot reboot problem. Anyone have a fix?

 

Question #2

When the box initially boots there is a delay form the time I plug in the power till the time Armbian starts its onscreen load of the OS. This time seems long. Can i somehow shorten this?

Edited by markst
0
Link to comment
Share on other sites
mkultra

mkultra

Posted
Posted (edited)

hi folks, I've ended up with a difference of opinion with my 2 boxes somehow lol

how do I change from 'untested automated build' to 'community creations' and vice versa?

tried armbian-config and it doesn't seem to do anything....cheers

Exhibits:

BOX1 - this is an RK3318

Welcome to Armbian 23.11.0-trunk.41 Bookworm with Linux 6.5.2-edge-rockchip64

No end-user support: untested automated build
BOX2 - this is an RK3328 - a H96 Max+

Welcome to Armbian 23.8.1 Bookworm with Linux 6.4.13-edge-rockchip64

No end-user support: community creations
 

Edited by mkultra
0
Link to comment
Share on other sites
Павел Иванов

Павел Иванов

Posted
Posted

Hello everyone and thanks for the answers! I have a H96MAX RK3318 v.1.4 board. I have a question about the boot process: kernels above 5.15 do not work on this board or am I doing something wrong? I compile using ./compile.sh and after recording there is a black screen and nothing works? Another question: does anyone know the process of clean assembly of a separate uboot for this board?

0
Link to comment
Share on other sites
jock

jock

Posted
  • Author
Posted
21 hours ago, Hacktarus13 said:

I hope Jock/armbian could repair users.armbian.com server ?

I can't repair the server, as like as the community images are not getting produced regularly.

They are not under my control.

0
Link to comment
Share on other sites
timfischbach

timfischbach

Posted
Posted

I had a feeling, that anything could happen to the server and nobody will have access to the files anymore.
I temporary reuploaded the following files on my download server, till the originals are back online:
Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img.xz
multitool.img.xz
nvram_2734c.txt

Link:
https://dl.timfischbach.com/dlc/RK3318 Files Reupload/

1
Link to comment
Share on other sites
Dwarfy27

Dwarfy27

Posted
Posted (edited)

Great Tahnks to @Hacktarus13 , multitool is now mine.

@jock Could U post images that worked for LFPulain somewhere ?

 

Edit : Armbian_23.08.0-trunk_Rk3318-box_bookworm_edge_6.3.13_minimal.img.xz has been upoladed by timfichbach. Thanks him, Great guy ! I will test tomorrow, late time here ...

Edited by Dwarfy27
0
Link to comment
Share on other sites
Hacktarus13

Hacktarus13

Posted
Posted

Thanks



The best are the config files + restrictions (like which kernel works/validate), persons could do it themself

Today, I try to compile mpv/ffmpeg with HWaccel, it is hard (no Mali source from RockChip, files/explanations are for old OS, many compilations errors...)

If @jock or other could share MPV/FFplay/FFmpeg which work, it will help many persons here

0
Link to comment
Share on other sites
ddrmax

ddrmax

Posted
Posted

Hello, has anyone tried (for X88pro10 owners) to restore the front panel clock?

Also, when installing @timfischbach Armbian 23.08, the display is broken, so I installed the 22.02 from Hyper HDR tutorial mirror and works fine. but i needed to freeze the kernel and install the latest 5.x as all 6.x kernels ends up with no HDMI (because I use it with desktop.

after all the updates, My system reports this:

daniel@X88-Pro10-01

OS: Armbian (23.8.1) aarch64

Host: Rockchip RK3318 BOX

Kernel: 5.15.93-rockchip64

Uptime: 15 hours, 26 mins

Packages: 1294 (dpkg)

Shell: zsh 5.8

Resolution: 1920x1080

Terminal: /dev/pts/0

CPU: (4) @ 1.296GHz

Memory: 1358MiB / 3973MiB

Hardware acceleration seems broken as Minetest 5.3.0 (OpenGL 2.1) at lowest settings run at 6 fps and 0.AD has graphics problems and runs at 7 fps and CPU @ 100%

Anything I have done wrong?

0
Link to comment
Share on other sites
ddrmax

ddrmax

Posted
Posted (edited)

Post of the day:

For now I have 8 X88Pro 10 (4GB RAM / 32GB ROM) and 8 High Speed SD Cards (128GB Sandisk Extreme Pro)

4 of them will not have desktop ( 1 for flightradar24 ADS-B receiver / 2 for Home Assistant (my and my sister's house) / 1 for WebSDR)

2 of them will be spares (or to tinker for patches, I want them in the long run to be retrogaming boxes )

2 of them will have desktop (at least X running) for two magic mirrors

For the tests I have done, going over Kernel 5.15.X (not checked for long time Kernels between 5.16 and 5.18), the 5.19.X Kernel (latest edge kernel) the HDMI at boot works but if sleep is enabled (screen sleep and not whole TV box sleep), Wake-up is broken, I need to SSH and literally kill lightDM to restore the HDMi to working order, but X and Lightdm aren't frozen, because i can run on the display minetest or glxgears via ssh using DISPLAY=:0  app and I have no error opening the app (normally you have an error at launch saying you cant open X).

Here is the dmesg: 

[61671.395705] ------------[ cut here ]------------
[61671.395736] [CRTC:37:crtc-0] vblank wait timed out
[61671.395829] WARNING: CPU: 1 PID: 6903 at drivers/gpu/drm/drm_atomic_helper.c:1540 drm_atomic_helper_wait_for_vblanks.part.23+0x274/0x290
[61671.395863] Modules linked in: brcmfmac brcmutil cfg80211 hantro_vpu(C) rockchip_vdec(C) gpio_ir_recv v4l2_vp9 joydev snd_soc_spdif_tx hci_uart btqca rc_core v4l2_h264 btrtl videobuf2_dma_contig rockchip_rga v4l2_mem2mem btbcm videobuf2_dma_sg btintel videobuf2_memops videobuf2_v4l2 videobuf2_common bluetooth snd_soc_rk3328 videodev snd_soc_hdmi_codec mc snd_soc_rockchip_i2s snd_soc_rockchip_spdif snd_soc_simple_card snd_soc_simple_card_utils snd_soc_core rfkill snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd soundcore cpufreq_dt lz4hc lz4 zram ip_tables x_tables autofs4 dwmac_rk stmmac_platform stmmac pcs_xpcs dw_hdmi_i2s_audio lima dw_hdmi_cec gpu_sched drm_shmem_helper gpio_syscon adc_keys
[61671.396115] CPU: 1 PID: 6903 Comm: Xorg Tainted: G        WC        5.19.16-rockchip64 #22.08.6
[61671.396126] Hardware name: Rockchip RK3318 BOX (DT)
[61671.396134] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[61671.396144] pc : drm_atomic_helper_wait_for_vblanks.part.23+0x274/0x290
[61671.396156] lr : drm_atomic_helper_wait_for_vblanks.part.23+0x274/0x290
[61671.396167] sp : ffff80000da939b0
[61671.396172] x29: ffff80000da939b0 x28: 0000000000000000 x27: 0000000000028c77
[61671.396188] x26: ffff000006958000 x25: 0000000000000000 x24: 0000000000000001
[61671.396204] x23: 0000000000000038 x22: 0000000000000001 x21: ffff00002556e800
[61671.396219] x20: ffff000006908080 x19: 0000000000000000 x18: 0000000000000001
[61671.396235] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000002844
[61671.396250] x14: ffff80000da93760 x13: 00000000ffffffea x12: ffff800009bc3f90
[61671.396267] x11: 0000000000000003 x10: 0000000000051a10 x9 : ffff800009bb7930
[61671.396282] x8 : 000000000000c660 x7 : c000000100000844 x6 : ffff800009b8d090
[61671.396300] x5 : ffff8000f4f92000 x4 : 0000000000000000 x3 : 0000000000000001
[61671.396315] x2 : 0000000000000000 x1 : 6fe815759e855200 x0 : 0000000000000000
[61671.396331] Call trace:
[61671.396337]  drm_atomic_helper_wait_for_vblanks.part.23+0x274/0x290
[61671.396350]  drm_atomic_helper_commit_tail_rpm+0x64/0x80
[61671.396363]  commit_tail+0xa4/0x198
[61671.396374]  drm_atomic_helper_commit+0x160/0x370
[61671.396385]  drm_atomic_commit+0xac/0xe0
[61671.396395]  drm_atomic_helper_dirtyfb+0x190/0x2d0
[61671.396405]  drm_mode_dirtyfb_ioctl+0x174/0x240
[61671.396415]  drm_ioctl_kernel+0xc0/0x178
[61671.396429]  drm_ioctl+0x23c/0x448
[61671.396439]  __arm64_sys_ioctl+0xa8/0xe8
[61671.396454]  invoke_syscall+0x44/0x108
[61671.396468]  el0_svc_common.constprop.3+0x94/0xf8
[61671.396478]  do_el0_svc+0x2c/0xb8
[61671.396487]  el0_svc+0x20/0x50
[61671.396500]  el0t_64_sync_handler+0x98/0xc0
[61671.396510]  el0t_64_sync+0x170/0x174
[61671.396522] ---[ end trace 0000000000000000 ]---

If you want me to check kernels mods to see if Kernels 6.X has working HDMI (all my boxes have the same problem of possible HDMI timing) or test other things, I can do it if full linux images or simply compiled kernel images are provided.

In the near future (need to get better at compiling the X86 kernel before), I could end up only requesting the patches or write my own patches and compile myself the patches to test

Edited by ddrmax
0
Link to comment
Share on other sites
Taz

Taz

Posted
Posted (edited)

I did full "apt-get update && apt-get upgrade" and landed with 6.1.53-current-rockchip64 kernel. I have had two hard crashes of the system in two days with this kernel, edited /etc/default/armbian-ramlog to disable ram /var/log to see if I can track it. Also noticed that the 50MB /var/log is not big enough and it was full.

I have also tested 256 GB SDXC1 (Kingston canvas select plus) on the armbian rk3318 and if there was any doubt of being able to access the whole card, it is working fine.

 

EDIT: found nothing useful in logs.

EDIT2: testing 6.5.3-edge-rockchip64 kernel now

Edited by Aapo Tahkola
0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept