CSC Armbian for RK3318/RK3328 TV box boards

[Dario Murgia]

I tried to search for a way to extract the dtb from my android box, but without success. 

 

I tried to use the procedure from this post, but I can't login via ssh, I always get this error:

 

dario@thinkcentre:~$ ssh -oHostKeyAlgorithms=+ssh-dss  ssh@192.168.1.112 -p 2222                                                                                                                                                                                                   
ssh@192.168.1.112's password:                                                                                                                                                                                                                                                           
PTY allocation request failed on channel 0                                                                                                                                                                                                                                              
shell request failed on channel 0    

 

I also tried to search for a way to extract the file from the backup done with multitool, but I could not find it.

 

any hint?

[Dario Murgia]

some updates with the dump.

 

using the tool rkDumper_1.1.0.0 i managed to obtain single files in .img format

 

 

i tried to extract dtb from all of them with this tool, I got some from dtbo.img and uboot.img only, uploaded them here

 

after obtaining the .dts out of them, I had a look but I could not find anything related to audio nodes in general. the 4 dts extracted from uboot.img are identical

[jock]

@Dario Murgia u-boot dtbs are not really useful because are stripped down versions of the kernel dtb (not dtbo), which is the right one to inspect.

I usually extract manually with hex editor finding the signature 0xd00dfeed, but perhaps that tool is way easier or there is another tool from Sergio Poverony that maybe @fabiobassa can help with!

[Dario Murgia]

any hint is more than welcome!

[fabiobassa]

@Dario Murgia

try googling for

RK3xxx_firmware_tools_5.23.1_by_SergioPoverony


EDIT


https://chinagadgetsreviews.com/download-rk3xxx-firmware-tools-v-5-78-35-00-by-sergio-poverony.html

Edited January 29, 2023 by fabiobassa

[Dario Murgia]

hi Fabio,

 

I tried to use the tool from Sergio Poverony, as you suggested.

 

I tried to load the full dump done with Multitool, but when I load the image I get this error; "Error unpack Firmware!"

 

so I went to the "Single Tool" section, loading the files extracted with  rkDumper_1.1.0.0

 

I managed to extract the file "boot.img", I obtained a .cfg file with the below text and three binary files (kernel, ramdisk, second), but unfortunately no dtb

 

[ABOOT]

KernelAddr:0x10008000
RamdiskAddr:0x11000000
SecondFAddr:0x10f00000
TagsAddr:0x10000100
PageSize:0x00000800
Name:
CmdLine:console=ttyFIQ0 androidboot.baseband=N/A androidboot.wificountrycode=US androidboot.veritymode=enforcing androidboot.hardware=rk30board androidboot.console=ttyFIQ0 androidboot.verifiedbootstate=orange firmware_class.path=/vendor/etc/firmware init=/init rootwait ro loop.max_part=7 androidboot.selinux=permissive buildvariant=userdebug
SecondFile:1

 

I also tried to extract the file "recovery.img", but the output folder was empty.

 

I could not extract the "system.img" file because I don't have it with the rkDumper extracted files.

 

I could not extract the "resources.img"  file because I don't have it with the rkDumper extracted files.

 

I tried to extract the "backup.img" file, the tool never finished the task. I let it run for more than one hour, the "please wait" popup is still there.

 

 

 

I'm again stuck, I will try to flash the original android image on the device and get the UART log out of it, maybe I'll get some info from it.

 

 

 

 

 

[Dario Murgia]

here I am with the UART dump from the original android image.

 

I could not find any reference to any dtb loaded at the beginning, only some text mentioning the offset of the flattened Device Tree blob

 

 

## Booting Android Image at 0x0027f800 ...
Kernel load addr 0x00280000 size 29899 KiB
RAM disk load addr 0x0a200000 size 819 KiB
## Flattened Device Tree blob at 08300000
   Booting using the fdt blob at 0x8300000
   XIP Kernel Image from 0x00280000 to 0x00280000 ... OK
  'reserved-memory' ramoops@110000: addr=110000 size=f0000
   Using Device Tree in place at 0000000008300000, end 00000000083162a9
soc is rk3318

 

a few lines later, I could find this string, mentioning the machine model

 

[    0.000000] Machine model: Rockchip RK3328 box liantong avb

 

with a quick google search, I've found the same string in this github repo

 

the content is quite limited, but it points out to this dtsi file

 

no  big progress for me with this info

 

 

 

 

 

[jock]

@Dario Murgia Mmmh, I had the chance to try an image with latest 6.1 kernel on a rk3328 box and audio was not properly working in any case.

Analog audio is working with speaker-test/aplay but not with pulseaudio on xfce, SPDIF was completely not working. Pulseaudio also was missing one of the three audio devices.

 

Definitely I need to take a look to this, I recently received a rk3328 board with SPDIF coaxial connector and thus I can try, but you have to be patient. The nodes in the device tree seems to be in place, but perhaps some setting is wrong or a gpio that enables/disables the spdif output is missing. I need to check that.

[Dario Murgia]

thanks for having a look. 

 

anyhow, I have SPDIF working now (on kernel 5.15.90)!

 

digging a bit into the dts generated from your rk3318-box.dtb and the rk3328 datasheet, I realized there are three pins capable of being set as SPDIF-out

 

		spdif-0 {

			spdifm0-tx {
				rockchip,pins = <0x00 0x1b 0x01 0x66>;
				phandle = <0x13>;
			};
		};

		spdif-1 {

			spdifm1-tx {
				rockchip,pins = <0x02 0x11 0x02 0x66>;
				phandle = <0xd8>;
			};
		};

		spdif-2 {

			spdifm2-tx {
				rockchip,pins = <0x00 0x02 0x02 0x66>;
				phandle = <0xd9>;
			};
		};

 

in your DTB the first one was selected, in the pinctrl-0 declaration

 

	spdif@ff030000 {
		compatible = "rockchip,rk3328-spdif";
		reg = <0x00 0xff030000 0x00 0x1000>;
		interrupts = <0x00 0x1d 0x04>;
		clocks = <0x02 0x2e 0x02 0x13a>;
		clock-names = "mclk\0hclk";
		dmas = <0x12 0x0a>;
		dma-names = "tx";
		pinctrl-names = "default";
		pinctrl-0 = <0x13>;
		#sound-dai-cells = <0x00>;
		status = "okay";
		phandle = <0x10>;
	};

 

so I tried to replace 0x13 (corresponding to spdifm0) with 0xd8 (corresponding to spdifm1), rebuilt the DTB and then I had SPDIF up and running on my x88pro-10!

 

 

[jock]

@Dario Murgia Very, cool thanks for reporting! In fact I had no chance to test SPDIF when I originally worked on rk3318-box dts because my old board had no spdif. I will check on the newer board if the spdif is working selecting the other pin configuration and put a general fix for the dts!

[Dario Murgia]

just as a clarification, SPDIF was workning on another TV-Box, with the unmodified dtb and kernel from your image. In that device, the SPDIF out was most probably routed to the physical pin spdifm0-tx.

 

in my x88pro-10 the SPDIF out is connected to the pin spdifm1-tx, so the default dtb was not working.

 

i think you can leave the dtb as-it-is, i suppose some overlay can be added to eventually select spdifm1-tx or spdifm2-tx as output pins, depending on what the manufacturer selected in the PCB

Edited January 30, 2023 by Dario Murgia

[jock]

@Dario Murgia ok thanks also for this other clarification and yes, that's exactly the way you describe: so, only the X88 Pro overlay will receive this fix 👍

 

edit: do you remember the other board signature on the pcb?

[Dario Murgia]

Hi jock,

 

no, I don't remember... I borrowed it from my cousin, for some experiments. I can ask him to open the device and shot some pictures.

[jock]

@Dario Murgia Don't worry, it is not essential, it was just good to know. However the fix has been mainlined in armbian

[nome cognome]

@jock : how come multitool will boot from an sd card no matter what while the armbian image needs the flash to be erased first?

[jock]

6 hours ago, nome cognome said:

@jock : how come multitool will boot from an sd card no matter what while the armbian image needs the flash to be erased first?

That's a deliberate choice to avoid proprietary rockchip binaries as most as possible or use "tested" binaries, use mainline u-boot and keep the bootloader part "tiny".

In reality, these assumptions were made initially for rk322x images, where the bootloader has been compacted into the first 2 megabytes of emmc, but on the rk3318 images this is partially true.

 

To make the long story short, the multitool uses the rockchip proprietary boot layout, while on armbian there is a custom layout and custom binaries.

Since rockchip socs always boot from eMMC first, the stock bootloader is fired first and it does not like custom layouts. To run armbian from sdcard you need to remove the stock bootloader, thus the fastest way is to erase the eMMC.

[Dario Murgia]

On 1/30/2023 at 10:43 PM, jock said:

edit: do you remember the other board signature on the pcb?

 

I finally got pictures of the PCB from my cousin

 

[tommy]

Today, I play around my RK3318 box. I modified rockchip-rk3328-opp-1.5ghz.dtbo and add to armbianEnv.txt but the problem is cpu voltage could not pass 1400 mV or config does not work .

 

I feel xfce desktop is more responsive. I did a geekbench benchmark that look like top of Rk3318 cpu compare to other systems. -> https://browser.geekbench.com/v5/cpu/compare/20470717

 

Thanks mans for a great armbian.

[otus]

Hello
I wanted to thank you for a great job.😃
My H96 Max RK3318 4gb ram and damaged emmc memory got a new life.
I have two questions:
How to check ram speed in armbian and why video on youtube plays very poorly?

 

And I already know, on the console it shows the speed

Edited February 17, 2023 by otus
And I already know, on the console it shows the speed

[jock]

8 hours ago, otus said:

How to check ram speed in armbian and why video on youtube plays very poorly?

You can check the dpll core clock in linux, it tells you the clock used by the dram controller.

 

cat /sys/kernel/debug/clk/dpll/clk_rate

 

It should tell you 666Mhz or 1333Mhz, I don't remember if it accounts for double-data rate or not (but I think not, probably will tell 666Mhz).

 

edit: about the poor youtube performance, it is due to the fact that the cpu is not powerful enough, there is no hardware video decoding yet for videos in the browser and the graphics pipeline is not really well optimized for general purpose desktop environments.

[MattWestB]

# cat /sys/kernel/debug/clk/dpll/clk_rate
1332000000

with 660Mhz set in rk3318-config.

Edited February 17, 2023 by MattWestB
Mzh

[jock]

@MattWestB beware that rk3318-config does not let choose DDR frequency, that's for rk322x.

rk3318 requires proprietary trust os to enable the ddr scaling, but the proprietary os does not allow frequencies above 1.1ghz artificially crashing the system.

For this reason, on rk3318 I'm using the mainline opensource trust os, which allows to run the cpu above 1.1ghz without issues, but does not support ddr scaling.

 

That's it, closed source code 🙄

[pakos96]

Hello,

i successfully installed the latest official armbian, everything works fine except the leds. I have a continuous red and blue led flash. I used one of the very first CSC versions in the past and the leds worked correctly. I also tried other configurations in "rk3318-config" but I didn't find any valid configuration, also it "breaks" the wifi chip.

I remembered in the past to use the config1 correctly.

 

This is the OS version "Armbian 23.02.0-trunk Lunar with bleeding edge Linux 6.1.7-rockchip64"

 

Do you have any suggestions?

 

Thank you!

Edited February 17, 2023 by pakos96

[jock]

 @pakos96 That's right, the flashing leds are made on purpose to have a visual feedback that the kernel is alive.

 

Once you setup the led-config suitable for your board, you can change the led behaviour writing to /sys/class/leds/working/trigger. You can even read that file to know which are the available triggers.

[gerotmf]

Hi,

I have a rk3318_v.14 box, which has kingston emmc and some micron ddr memory which should be brand new but looks tired ... well i've installed armbian (minimal/cli, 23.02) on it (emmc), it boots up and i have wifi, eth, usb, hdmi working, i can even apt install amrbian-config, configure it and everything seems to work ok, until there is some serious load, like f.e. apt install gcc-arm-none-eabi .. that will start gunziping and just freezes, i can log into other ssh session, but any command i issue is blocked.  I'm trying to find uart on this board but no luck so far. I've also extracted dtb/dts from original android firmware, under which it looks like box is working ok (tried copying 4GB files to emmc and such, no problems) which is located here https://drive.google.com/drive/folders/1a_lbHo4umDN56KeOWw0elDGhz6VE1LGF?usp=share_link but since my dtc guru is nonexistent i really can't make anything out of it. I've tried diffing with armbian's rk318-box.dtb but like i wrote, can't figure out what to look for... my first suspect was emmc so i also tried running from sd card with similar results. second guess is cpu power supply, where there are some diffs in dtb,

 

Anyone has any suggestions, or can check that dtb if there is something obvious

 

Tnx,

[jock]

@gerotmf You could keep a ssh session with dmesg -w command running while you do the operations that freeze your board. This way you will immediately see kernel issues on dmesg log as soon as they appear, if there is any.

 

After inspecting the dtb, I don't see anything really relevant that may causes crashes.

You can run some benchmark/testing tools like openssl (using the "speed" benchmarking mode) or memtester to chek the ram.

 

Also you may follow the instructions in this post to install an alternative bootloader with memories at 333 MHz (in place of the stock 666 MHz) and see if you get better stability.

[gerotmf]

@jock Thanks for the answer, i did catch this at some point, but it's not the same every time

 

Spoiler

[ 7388.558823] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 7388.566123] Modules linked in: hci_uart(E) brcmfmac(E) btqca(E) brcmutil(E) btrtl(E) btbcm(E) btintel(E) cfg80211(E) gpio_ir_recv(E) bluetooth(E) hantro_vpu(E) rockchip_vdec(CE) snd_soc_rockchip_spdif(E) rc_core(E) rockchip_rga(E) v4l2_vp9(E) snd_soc_simple_card(E) videobuf2_dma_contig(E) snd_soc_spdif_tx(E) v4l2_h264(E) snd_soc_hdmi_codec(E) videobuf2_dma_sg(E) v4l2_mem2mem(E) snd_soc_simple_card_utils(E) snd_soc_rockchip_i2s(E) snd_soc_rk3328(E) videobuf2_memops(E) snd_soc_core(E) videobuf2_v4l2(E) videobuf2_common(E) snd_compress(E) snd_pcm_dmaengine(E) videodev(E) snd_pcm(E) snd_timer(E) rfkill(E) mc(E) snd(E) lz4hc(E) soundcore(E) cpufreq_dt(E) lz4(E) joydev(E) sg(E) zram(E) binfmt_misc(E) ip_tables(E) x_tables(E) autofs4(E) dwmac_rk stmmac_platform hid_logitech_hidpp lima stmmac gpu_sched uas hid_logitech_dj pcs_xpcs dw_hdmi_cec dw_hdmi_i2s_audio drm_shmem_helper gpio_syscon adc_keys
[ 7388.597768] CPU: 1 PID: 3085 Comm: dpkg-split Tainted: G    B    C  E      6.1.11-rockchip64 #23.02.1
[ 7388.604983] Hardware name: Rockchip RK3318 BOX (DT)
[ 7388.611801] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7388.618809] pc : kmem_cache_free+0x84/0x3f0
[ 7388.625570] lr : security_file_free+0x4c/0x60
[ 7388.632296] sp : ffff80000d023c50
[ 7388.638890] x29: ffff80000d023c50 x28: ffff0000013b1d80 x27: 0000000000000000
[ 7388.645861] x26: 0000000000000000 x25: 0000000000000000 x24: 0080000000000000
[ 7388.652839] x23: ffff8000086635bc x22: 0000000000000000 x21: ffff0000047743a8
[ 7388.659773] x20: ffff8000086635bc x19: ffff0000004f4200 x18: ffff80000d023c78
[ 7388.666648] x17: 0000000000000000 x16: 0000000000000000 x15: 000000000000000e
[ 7388.673505] x14: ffff0000048def0c x13: 000000000007266f x12: 0000ffffe161ffff
[ 7388.680332] x11: 0001000000000000 x10: fffffc0000000000 x9 : ffff80000d024000
[ 7388.687156] x8 : ffff80000d020000 x7 : ffff0000013b1d80 x6 : 0000000000000064
[ 7388.694027] x5 : 00000000ffffff6a x4 : 0000000000000000 x3 : 0000000000000490
[ 7388.700846] x2 : 0000000000000001 x1 : 0ffff20000002052 x0 : ffff8000086635bc
[ 7388.707653] Call trace:
[ 7388.713940]  kmem_cache_free+0x84/0x3f0
[ 7388.720347]  security_file_free+0x4c/0x60
[ 7388.726707]  __fput+0xc8/0x250
[ 7388.732947]  ____fput+0x10/0x20
[ 7388.739146]  task_work_run+0x80/0xd8
[ 7388.745357]  do_exit+0x304/0xa80
[ 7388.751464]  do_group_exit+0x34/0x90
[ 7388.757543]  __wake_up_parent+0x0/0x30
[ 7388.763599]  invoke_syscall+0x44/0x108
[ 7388.769620]  el0_svc_common.constprop.3+0x94/0xf8
[ 7388.775664]  do_el0_svc+0x2c/0xc8
[ 7388.781535]  el0_svc+0x20/0x50
[ 7388.787406]  el0t_64_sync_handler+0x98/0xc0
[ 7388.793325]  el0t_64_sync+0x170/0x174
[ 7388.799173] Code: 9a9f12d6 f100031f 9a800294 d503201f (f9401ec0)
[ 7388.805186] ---[ end trace 0000000000000000 ]---
[ 7388.812022] Fixing recursive fault but reboot is needed!
[ 7388.818738] BUG: using smp_processor_id() in preemptible [00000000] code: dpkg-split/3085
[ 7388.825313] caller is debug_smp_processor_id+0x20/0x30
[ 7388.831468] CPU: 3 PID: 3085 Comm: dpkg-split Tainted: G    B D  C  E      6.1.11-rockchip64 #23.02.1
[ 7388.838006] Hardware name: Rockchip RK3318 BOX (DT)
[ 7388.844313] Call trace:
[ 7388.850073]  dump_backtrace+0x140/0x150
[ 7388.856051]  show_stack+0x18/0x28
[ 7388.861953]  dump_stack_lvl+0x68/0x84
[ 7388.867678]  dump_stack+0x18/0x34
[ 7388.873436]  check_preemption_disabled+0xe0/0x118
[ 7388.879342]  debug_smp_processor_id+0x20/0x30
[ 7388.884989]  __schedule+0x4c/0x7c8
[ 7388.890721]  do_task_dead+0x48/0x50
[ 7388.896398]  make_task_dead+0x118/0x168
[ 7388.901950]  die+0x1fc/0x230
[ 7388.907547]  die_kernel_fault+0x26c/0x35c
[ 7388.913147]  __do_kernel_fault+0xe0/0x1b0
[ 7388.918606]  do_page_fault+0xe0/0x4a0
[ 7388.924210]  do_translation_fault+0x4c/0x68
[ 7388.929798]  do_mem_abort+0x40/0x90
[ 7388.935124]  el1_abort+0x44/0x68
[ 7388.940582]  el1h_64_sync_handler+0x68/0x100
[ 7388.946042]  el1h_64_sync+0x64/0x68
[ 7388.951249]  kmem_cache_free+0x84/0x3f0
[ 7388.956623]  security_file_free+0x4c/0x60
[ 7388.961936]  __fput+0xc8/0x250
[ 7388.967000]  ____fput+0x10/0x20
[ 7388.972242]  task_work_run+0x80/0xd8
[ 7388.977480]  do_exit+0x304/0xa80
[ 7388.982251]  do_group_exit+0x34/0x90
[ 7388.986880]  __wake_up_parent+0x0/0x30
[ 7388.991431]  invoke_syscall+0x44/0x108
[ 7388.995672]  el0_svc_common.constprop.3+0x94/0xf8
[ 7388.999731]  do_el0_svc+0x2c/0xc8
[ 7389.003633]  el0_svc+0x20/0x50
[ 7389.007572]  el0t_64_sync_handler+0x98/0xc0
[ 7389.011542]  el0t_64_sync+0x170/0x174

 

[otus]

Thanks
For answering.
My ram runs at 666MHz.

What do you think, video drivers and general graphics will be developed?

Edited February 20, 2023 by otus

[jock]

On 2/19/2023 at 1:02 PM, gerotmf said:

@jock Thanks for the answer, i did catch this at some point, but it's not the same every time

Hmmm, this is interesting, because I experience this also on rockchip 32 bit with kernel 6.1.11 revision. Perhaps we're hitting a kernel bug at this point

[jock]

7 hours ago, otus said:

What do you think, video drivers and general graphics will be developed?

They ARE developed, and are pretty advanced too. The problem is that video acceleration in browsers is far from being a simple task. Consider that it is not so easy to have hardware accelerated videos even with regular x86