CSC Armbian for RK3318/RK3328 TV box boards

[jock]

@Matteo Venturi

This post may be somehow helpful. Post the logs and the results of the get-edid command

 

[hexdump]

@jock - i can confirm that those old mx10 boxes were rk3328 and they were the only ones i saw, which had a proper cpu voltage control ... i once had one of those some time ago

 

@Matteo Venturi - i think there are at least two versions of this box: an older rk3328 one which should work very nice out of the box (i have one of those) and a newer rk3318 one which might have a few surprises in it resulting in it no longer working that easily

 

best wishes and good luck - hexdump

[Matteo Venturi]

1 hour ago, jock said:

@Matteo Venturi

This post may be somehow helpful. Post the logs and the results of the get-edid command

 

Thanks @jock
When the box was with Android i used it with hdmi. Also, when i used multiboot i used hdmi monitor. When Ubuntu booted, HDMI stopped work.

Here get-edid result:

This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Only trying 4 as per your request.
128-byte EDID successfully retrieved from i2c bus 4
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
    Identifier "X243H"
    ModelName "X243H"
    VendorName "ACR"
    # Monitor Manufactured week 5 of 2010
    # EDID version 1.3
    # Digital Display
    DisplaySize 530 290
    Gamma 2.20
    Option "DPMS" "true"
    Horizsync 31-83
    VertRefresh 56-76
    # Maximum pixel clock is 180MHz
    #Not giving standard mode: 1280x1024, 60Hz
    #Not giving standard mode: 1152x864, 75Hz
    #Not giving standard mode: 1440x900, 60Hz
    #Not giving standard mode: 1440x900, 75Hz
    #Not giving standard mode: 1600x1200, 60Hz
    #Not giving standard mode: 1680x1050, 60Hz
    Modeline     "Mode 0" 138.50 1920 1968 2000 2080 1080 1082 1087 1111 +hsync -vsync 
EndSection
 

[MX10.AC2N]

8 hours ago, jock said:

@MX10.AC2N Okay, so that's the reason your board works fine with Station M1 device tree.

Your board seems to be better constructed than regular rk3318 boards, maybe is it rk3328? (rk3318-config will tell you)

Another non-common thing is the GL850G USB2 hub chip, but that should not be a problem.

 

I need a bit of time to study and prepare an appropriate overlay specific for your board, so you have to be patient...

@jock

Thank a lot,

There is indeed an rk3328 in my mx10 box, rk3318-config detects it as being an rk3328 ..

I don't know about GL850G USB2, but on the box there is 3 USB2 port and 1 USB3

No worries, I will be patient ... thank you again for this great work you have done ...
Regarding the wifi on this MX10 there is an SV6051P chip, I have already read some parts in the forum that this chip does not have the drivers to work well under armbian ..? (I can use the "FORGET" function in the internet section of armbian-config, it disables all wireless connection ..?)
Thanks again and have a nice day

[jock]

@MX10.AC2N The sv6051p  has a driver only in the legacy kernel. In terms of source code, the driver is quite ugly so noone tried to fix or rewrite it for mailnine kernel; the chinese company that manufactured the chip disappeared some years ago, so at the moment there is no support on mainline kernel. It will just not work, no need to handle that manually.

 

[jock]

12 hours ago, Matteo Venturi said:

Thanks @jock
When the box was with Android i used it with hdmi. Also, when i used multiboot i used hdmi monitor. When Ubuntu booted, HDMI stopped work.

Here get-edid result:

This is read-edid version 3.0.2. Prepare for some fun.
Attempting to use i2c interface
Only trying 4 as per your request.
128-byte EDID successfully retrieved from i2c bus 4
Looks like i2c was successful. Have a good day.
Checksum Correct

Section "Monitor"
    Identifier "X243H"
    ModelName "X243H"
    VendorName "ACR"
    # Monitor Manufactured week 5 of 2010
    # EDID version 1.3
    # Digital Display
    DisplaySize 530 290
    Gamma 2.20
    Option "DPMS" "true"
    Horizsync 31-83
    VertRefresh 56-76
    # Maximum pixel clock is 180MHz
    #Not giving standard mode: 1280x1024, 60Hz
    #Not giving standard mode: 1152x864, 75Hz
    #Not giving standard mode: 1440x900, 60Hz
    #Not giving standard mode: 1440x900, 75Hz
    #Not giving standard mode: 1600x1200, 60Hz
    #Not giving standard mode: 1680x1050, 60Hz
    Modeline     "Mode 0" 138.50 1920 1968 2000 2080 1080 1082 1087 1111 +hsync -vsync 
EndSection
 

Uhm, I see that you have and old full-hd monitor. It should not be an issue, but apparently it is.

From the hints about your experiences (working on Android, working on multitool, not working with armbian), I guess you installed armbian with mainline kernel: there are some tweaks in the mainline kernel that alter the HDMI timings, thus they may be better with some monitors and worse with others. In your case it may be that your monitor does not like those timings.

You may give a chance to the legacy kernel image, you can just put in on sdcard, plug the sdcard and boot: the box should automatically boot from sdcard, so you can easily test if HDMI is properly working with legacy kernel at least.

[Matteo Venturi]

2 minutes ago, jock said:

Uhm, I see that you have and old full-hd monitor. It should not be an issue, but apparently it is.

From the hints about your experiences (working on Android, working on multitool, not working with armbian), I guess you installed armbian with mainline kernel: there are some tweaks in the mainline kernel that alter the HDMI timings, thus they may be better with some monitors and worse with others. In your case it may be that your monitor does not like those timings.

You may give a chance to the legacy kernel image, you can just put in on sdcard, plug the sdcard and boot: the box should automatically boot from sdcard, so you can easily test if HDMI is properly working with legacy kernel at least.

Great, thank you very much!

[MX10.AC2N]

18 hours ago, jock said:

@MX10.AC2N The sv6051p  has a driver only in the legacy kernel. In terms of source code, the driver is quite ugly so noone tried to fix or rewrite it for mailnine kernel; the chinese company that manufactured the chip disappeared some years ago, so at the moment there is no support on mainline kernel. It will just not work, no need to handle that manually.

 

Thank you @jock that's what it seemed to me, too bad for the wifi, anyway I use a wired connection ..

Another small remark, on my install station-M1 I had succeeded in modifying the use of the leds

thanks to this thread

but with your image, I can not find the leds, nor to modify their operation, I only have the red led which remains on all the time.

ju@rk3328-MX10-TVbox:/sys/class/leds/working$ sudo du -a /sys | grep led | grep trigger
0       /sys/kernel/tracing/events/libata/ata_qc_complete_failed/trigger
0       /sys/kernel/tracing/events/dma_fence/dma_fence_signaled/trigger
0       /sys/kernel/tracing/events/kyber/kyber_throttled/trigger
0       /sys/kernel/tracing/events/btrfs/btrfs_failed_cluster_setup/trigger
0       /sys/kernel/tracing/events/ext4/ext4_journalled_write_end/trigger
0       /sys/kernel/tracing/events/ext4/ext4_journalled_invalidatepage/trigger
0       /sys/kernel/tracing/events/xdp/mem_return_failed/trigger
0       /sys/kernel/debug/tracing/events/libata/ata_qc_complete_failed/trigger
0       /sys/kernel/debug/tracing/events/dma_fence/dma_fence_signaled/trigger
0       /sys/kernel/debug/tracing/events/kyber/kyber_throttled/trigger
0       /sys/kernel/debug/tracing/events/btrfs/btrfs_failed_cluster_setup/trigger
0       /sys/kernel/debug/tracing/events/ext4/ext4_journalled_write_end/trigger
0       /sys/kernel/debug/tracing/events/ext4/ext4_journalled_invalidatepage/trigger
0       /sys/kernel/debug/tracing/events/xdp/mem_return_failed/trigger
0       /sys/devices/platform/gpio-leds/leds/working/trigger
0       /sys/firmware/devicetree/base/gpio-leds/working/linux,default-trigger

And here is the result of the same command launched when I run with the image station-m1

root@station-mx10:~# du -a /sys | grep led | grep trigger
0       /sys/devices/platform/leds/leds/led2/trigger
0       /sys/devices/platform/leds/leds/led1/trigger
0       /sys/firmware/devicetree/base/leds/led2/linux,default-trigger
0       /sys/firmware/devicetree/base/leds/led1/linux,default-trigger

 

[jock]

8 hours ago, MX10.AC2N said:

Another small remark, on my install station-M1 I had succeeded in modifying the use of the leds

thanks to this thread but with your image, I can not find the leds, nor to modify their operation, I only have the red led which remains on all the time.

There is only one led (called working) in the base dtb because that led is commonly attached to the same GPIOs on (presumably) all boards.

Other leds will spawn once rk3318-config is run, because every board type has a different led configuration. The dtb must describe the GPIOs of the leds correctly, otherwise they won't work.

 

Your board is not yet in the list, so you may want to give a shot the the existing two boards until I make a specific overlay for yours. Chances are very low though.

[jock]

@MX10.AC2N

Here it is, I prepared a DTBO following the Station M1 and the original device tree of the board from the firmware you shared.

Put the file in /boot/dtb/rockchip/overlay directory, then as usual add rk3318-box-led-conf3 to overlays= in /boot/armbianEnv.txt

 

Reboot and hope...!

 

rockchip-rk3318-box-led-conf3.dtbo

Edited October 16, 2021 by jock
changed minor thing

[Gausus]

DTB SDCARD mode up to 104 MB/s

 

Have tried to squeeze some more performance out of my H96 max + RK3328.

 

SDCARD speed runs at sd high-speed mode / max 24MB/s R∕W on rk3318-box.dtb

Its possible to get higher speed from sd-card

 

 

# Org  DTB

sudo cat /sys/kernel/debug/mmc0/ios
clock:        50000000 Hz
actual clock:    50000000 Hz
vdd:        21 (3.3 ~ 3.4 V)
bus mode:    2 (push-pull)
chip select:    0 (dont care)
power mode:    2 (on)
bus width:    2 (4 bits)
timing spec:    2 (sd high-speed)
signal voltage:    0 (3.30 V)
driver type:    0 (driver type B)

 

Have modified the dtb to support up to hr104 (104 MB/s)

rk3318 image will not boot , but Armbian_21.11.0-trunk_Station-m1_hirsute_edge_5.14.11_xfce_desktop.img are booting using this modified DTB  DTS

 

# Mod DTB Station m1 image

sudo cat /sys/kernel/debug/mmc0/ios
clock:        150000000 Hz
actual clock:    150000000 Hz
vdd:        21 (3.3 ~ 3.4 V)
bus mode:    2 (push-pull)
chip select:    0 (dont care)
power mode:    2 (on)
bus width:    2 (4 bits)
timing spec:    6 (sd uhs SDR104)
signal voltage:    1 (1.80 V)
driver type:    0 (driver type B)

 

Using gnome-disks performance tool , i get 70+ read 40+ write speed.  about 2-3X performance boost on sdcard.

 

If y like to test this DTB disable all overlays in /boot/extlinux/extlinux.conf

 

Have tried to enable modules  in rk3318 image to boot.

APPEND root= xxx yyy ....   ADD to end    mmc_block sdhci tifm_sd

 

Dont know if kernel need a patch to boot from sdacrd when sd-uhs-XX modes enabled.

 

SOME links about sdcard mode i DTB

https://android.googlesource.com/kernel/msm/+/android-wear-5.1.1_r0.6/Documentation/devicetree/bindings/mmc/mmc.txt

https://patchwork.kernel.org/project/linux-arm-kernel/patch/87imkryz5t.fsf@vany.ca/

https://tinkerboarding.co.uk/forum/archive/index.php/thread-310.html

 

Changed i  rk3318-box.dtb

 

mmc@ff500000 {

compatible = "rockchip,rk3328-dw-mshc\0rockchip,rk3288-dw-mshc";

reg = <0x00 0xff500000 0x00 0x4000>;

interrupts = <0x00 0x0c 0x04>;

clocks = <0x02 0x13d 0x02 0x21 0x02 0x4a 0x02 0x4e>;

clock-names = "biu\0ciu\0ciu-drive\0ciu-sample";

fifo-depth = <0x100>;

max-frequency = <0x8f0d180>;

resets = <0x02 0x6d>;

reset-names = "reset";

status = "okay";

bus-width = <0x04>;

cap-mmc-highspeed;

cap-sd-highspeed;

disable-wp;

pinctrl-names = "default";

pinctrl-0 = <0x49 0x4a 0x4b 0x4c>;

sd-uhs-sdr12;  <--------------------------

sd-uhs-sdr25;  <--------------------------

sd-uhs-sdr50; <--------------------------

sd-uhs-sdr104; <--------------------------

vmmc-supply = <0x4d>;

vqmmc-supply = <0xd4>;  <-------------------------- DISABLED phandle = d4 spdif-2 could not find l free phandle to use

card-detect-delay = <0x320>;       


// Diff / Disabled

// phandle = <0x9a>;

// card-detect-delay = <0x320>;

// cd-gpios = <0x48 0x05 0x01>;

// no-sdio;

// supports-sd;

};


sdmmc-regulator {

compatible = "regulator-fixed";

gpio = <0x6b 0x1e 0x01>;

pinctrl-names = "default";

pinctrl-0 = <0x6c>;

regulator-name = "vcc_sd";

regulator-always-on;

regulator-boot-on;

regulator-min-microvolt = <0x325aa0>;

regulator-max-microvolt = <0x325aa0>;

vin-supply = <0x1e>;

phandle = <0x4d>;

};


//  ADD high speed sdcard 1,8v mode

sdmmcio-regulator {

compatible = "regulator-gpio";

gpios = <0x68 0x00 0x00>;

states = <0x1b7740 0x01 0x325aa0 0x00>;

regulator-name = "vcc_sdio";

regulator-type = "voltage";

regulator-min-microvolt = <0x1b7740>;

regulator-max-microvolt = <0x325aa0>;

regulator-always-on;

// vin-supply = <0x2b>;

vin-supply = <0x6e>;

phandle = <0xd4>;

};




// spdif-2 {

//

// spdifm2-tx {

// rockchip,pins = <0x00 0x02 0x02 0x5f>;

// phandle = <0xd4>;

// };

// };

 

[jock]

@Gausus thank for sharing that tip.

 

The main problem I see with your approach is that the vqmmc supply is wired to sdmmcio-regulator, which in turn is not really wired to a proper gpio pin controller.

 

This line:

gpios = <0x68 0x00 0x00>;

 

Converts into:

gpios = <&pcfg-pull-none-2ma RK_PA0 GPIO_ACTIVE_HIGH>;

which does not make sense, since pcfg-pull-none-2ma is not a GPIO controller.

There is not real voltage switching to 1.8v for the sdcard controller part as required by UHS modes, in your case the sdcard is incidentally working in UHS mode with 3.3v for the signalling part, but another card may not work or may not be stable.

 

By the way, looking into rk3328-roc-cc device tree there is some reference about sdmmcio regulator, and it is wired to the SoC General Register File (GRF), so it could be possible for any rk3318/rk3328 board to achieve UHS speed modes.

This is a good catch, because any rk3318 original firmware allows this, thus the original dtbs never expose such capability.

I will look into!

 

edit:

hmmm, this definitely looks like a red herring.

I followed the rk3328-roc-cc approach but, after measuring the voltage on the sdcard pins, the regulator is not really changing voltage.

In fact, some sdcard are happily recognized and work in UHS mode with 3.3v, some others absolutely don't (a couple of Sandisk ones) because require the 1.8v, as specs say.

 

Then I found this discussion: https://www.spinics.net/lists/arm-kernel/msg783365.html where is stated that Firefly (the guys behind roc-cc board) rewired the GRF gpio pin (which is normally used to mute the analog audio) to the sdmmc_io pin.

That's it, the roc-cc (which is the same board in station m1) has a custom design for that pin that switches between 1.8v and 3.3v.

So on tv boxes that pin enables and disables analog audio signal, on the roc-cc switches the sdmmc io regulator.

[Gausus]

2 hours ago, jock said:

@Gausus thank for sharing that tip.

 

The main problem I see with your approach is that the vqmmc supply is wired to sdmmcio-regulator, which in turn is not really wired to a proper gpio pin controller.

 

This line:

gpios = <0x68 0x00 0x00>;

 

Converts into:

gpios = <&pcfg-pull-none-2ma RK_PA0 GPIO_ACTIVE_HIGH>;

which does not make sense, since pcfg-pull-none-2ma is not a GPIO controller.

There is not real voltage switching to 1.8v for the sdcard controller part as required by UHS modes, in your case the sdcard is incidentally working in UHS mode with 3.3v for the signalling part, but another card may not work or may not be stable.

 

By the way, looking into rk3328-roc-cc device tree there is some reference about sdmmcio regulator, and it is wired to the SoC General Register File (GRF), so it could be possible for any rk3318/rk3328 board to achieve UHS speed modes.

This is a good catch, because any rk3318 original firmware allows this, thus the original dtbs never expose such capability.

I will look into!

 

 

Thank y for the quick respond , your excellent work!!

 

I dont understand to much about how DTB syntax works.

Trying to learn , where are good sources for learning?

Maybe if you have time you can set up a little guide.

 

I also tried to undervolt CPU.

Converted HEX to DES for easier reading.

Found this setting to working well up to 1.5Ghz

 

Tried to tweak some RAM and GPU settings , but dont think they work.

Do you know a way to show RAM frequency from terminal ? dmesg ?.

 

I do DD benchmark on /tmp   and  sysbench --test=memory   run from sysbench tool.

No changes in performance enable /disabling settings for RAM and GPU.

 

I recommend hardinfo to show HWinfo.

 

Are RAM frequency set by uboot ?

If yes , how can I test different setting for RAM in uboot ?

 

Links to DTB and DTS.

 

		opp-1200000000 {
			opp-hz = <0x00 0x47868c00>;
			opp-microvolt = <1200000>;
			clock-latency-ns = <0x9c40>;
			status = "okay";
		};

		opp-1296000000 {
			opp-hz = <0x00 0x4d3f6400>;
			opp-microvolt = <1225000>;
			clock-latency-ns = <0x9c40>;
			status = "okay";
		};

		 opp-1392000000 {
			opp-hz = <0x00 0x52f83c00>;
							
            		opp-microvolt =  <1250000>;
        		clock-latency-ns = <0x9c40>;
			status = "okay";
        	};
		
		opp-1512000000 {
			opp-hz = <0x00 0x5a1f4a00>;
			opp-microvolt = <1350000>;
		//	opp-microvolt = <0x149970>;
			clock-latency-ns = <0x9c40>;
		};

 

 

 

 

 

 

[jock]

17 minutes ago, Gausus said:

 

Thank y for the quick respond , your excellent work!!

Look at the post edit I made a little after, clarifies why the thing can't work on our tv boxes.

 

18 minutes ago, Gausus said:

 I dont understand to much about how DTB syntax works.

Trying to learn , where are good sources for learning?

I learned things are and there on the internet, could not find a proper guide.

Anyway google reports this forum thread, which is a good starting point:

 

20 minutes ago, Gausus said:

 

I also tried to under volt CPU.

Converted HEX to DES for easier reading.

Found this setting working well up to 1.5Ghz

 

Tried to tweak some RAM and GPU , but dont think they work.

Do you know a way show RAM frequency from terminal ? dmesg ?.

 

Yeah, undervolting is cool, but results vary a lot depending on the cpu sample.

GPU can be tweaked too. RAM can't be tweaked for three reasons:

• the dmc (dram memory controller) node in the dtb is disabled
• the dmc driver in the kernel is a bit broken
• the piece of code that does the dram frequency scaling is not present

The dram frequency is fixed by a thing which is called ddrbin, and it is the very first thing that boots (even before u-boot).

It is fixed to 330 Mhz currently, but probably I will push it to a higher yet safe value.

 

27 minutes ago, Gausus said:

If yes , how can i test different setting for RAM in uboot ?

You need to put together an idbloader, which is composed of ddrbin + u-boot SPL.

You can inspect armbian sources for that, but if you're not an expert in compiling u-boot, I would rather suggest you to stay away from that to avoid lose mental sanity.

 

[Ben N Voutour]

I Don't Know if this will work but please try this

if it doesn't help, then i'm out of ideas for now...

rk3318-box_1.5Ghz_SDCARD_v1a_ST_sdhr104.dts

[MX10.AC2N]

On 10/15/2021 at 10:45 PM, jock said:

@MX10.AC2N

Here it is, I prepared a DTBO following the Station M1 and the original device tree of the board from the firmware you shared.

Put the file in /boot/dtb/rockchip/overlay directory, then as usual add rk3318-box-led-conf3 to overlays= in /boot/armbianEnv.txt

 

Reboot and hope...!

 

rockchip-rk3318-box-led-conf3.dtbo 8.06 kB · 0 downloads

Hi @jock,
This morning I tested adding rockchip-rk3318-box-led-conf3 on your freshly reflashed bullseye image and just apt update && apt upgrade
But this bug during the reboot, here is what I have in visual on my tv

 

I'm wondering if I didn't write the line wrong in the armbianEnv.txt file?

verbosity=1
bootlogo=false
overlay_prefix=rockchip
fdtfile=rockchip/rk3318-box.dtb
rootdev=UUID=6ab7fbb0-02a0-407f-9130-a64052ab3c0d
rootfstype=ext4
console=both
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
overlays=rk3318-box-led-conf3

 

And if I delete the overlays line the startup ends without problem ..

Thank you again for everything and for your responsiveness, this is really very generous.
Good Sunday to all.

[jock]

@MX10.AC2NWell I guess I missed something

Most probably it is something related to the emmc/sdcard, depending upon what is your booting device actually.

That behaviour is common when the booting device is not detected, thus the initramfs can't find the root filesystem.

 

increase verbosity to 7 and you should also get some kernel messages on screen and a full boot dump on UART.

The full boot dump would be very useful to find what is missing there.

[MX10.AC2N]

30 minutes ago, jock said:

@MX10.AC2NWell I guess I missed something

Most probably it is something related to the emmc/sdcard, depending upon what is your booting device actually.

 

increase verbosity to 7 and you should also get some kernel messages on screen and a full boot dump on UART.

The full boot dump would be very useful to find what is missing there.

Here is the result screen output with verbosity = 7, on the other hand I never looked too much at the UART, suddenly I would first have to learn a little about the subject ...

[jock]

@MX10.AC2Nwell at least some error is showing up: Failed to register regulator: -517

I will try to find what's wrong with that.

[jock]

@MX10.AC2N  Hmm, would try with this other dtbo?

rockchip-rk3318-box-led-conf3.dtbo

[MX10.AC2N]

10 minutes ago, jock said:

@MX10.AC2N  Hmm, would try with this other dtbo?

rockchip-rk3318-box-led-conf3.dtbo 7.97 kB · 0 downloads

sorry same result ..

[jock]

@MX10.AC2N Here it is another attempt, last one for today

 

I rewrote the overlay and double checked anything I could simulate on my board.

If the system boots, please send back a dmesg log!

rockchip-rk3318-box-led-conf3.dtbo

[MX10.AC2N]

1 hour ago, jock said:

@MX10.AC2N Here it is another attempt, last one for today

 

I rewrote the overlay and double checked anything I could simulate on my board.

If the system boots, please send back a dmesg log!

rockchip-rk3318-box-led-conf3.dtbo 7.76 kB · 0 downloads

 

This time it starts, congratulations great work.
I have the Blue led which lights up at startup
Here is the copy of dmesg

https://paste.yunohost.org/wuzasonule.vbs

 

[MX10.AC2N]

system diagnosis information http://ix.io/3C3k

I try to set CPU governor with armbian-config but error..

[jock]

@MX10.AC2N

Thanks for the dmesg log and the whole diagnostic

Despite I said the previous dtbo was the latest for today, here I propose another one.

I spotted a subtle error in the dtb that I fixed: I was too zealant to give a voltage to the ddr regulator, while documentation says I should not do that.

 

Install this other dtbo whenever you want, reboot and please post again diagnostics.

I will check dmesg for any residual errors.

 

I hope this is the last time.

 

I don't know what's wrong with armbian-config.

You may try to update it with apt install armbian-config and see if the error disappears, but from what I read you already updated packages.

It could however be a side effect of the slightly wrong dtb, so maybe try again with this other one and then try again to change the governor.

 

 

 

rockchip-rk3318-box-led-conf3.dtbo

[MX10.AC2N]

10 hours ago, jock said:

so maybe try again with this other one and then try again to change the governor.

 

Hi and Thanks again,

so here is dmseg => https://paste.yunohost.org/vawijabuga.erl

system diagnosis information => http://ix.io/3C6s

the option to choose the CPU governor is functional again (well seen ..) on the other hand I still only have 1000MHz as max value ..

Thank you again @jock you are great..

[jock]

@MX10.AC2N Great, happy that we're very close to the solution

To get 1.3Ghz, just add rk3318-box-cpu-hs overlay.

If I read the dtb correctly, also the wifi is attached to the extra sdio bus on your board, so you'd better add rk3318-box-wlan-ext overlay too!

 

Reboot and you should get these two other things.

 

BTW: you can also use rk3318-config to do all the necessary overlay configuration with the comfy menu interface. Just need to manually edit armbianEnv.txt before rebooting and set rk3318-box-led-conf3 in place of any other led-conf (there must be only one led-conf overlay). In the next update I will add the led-conf3 to rk3318-config so coming people with boxes like yours will find the recipe ready-made

[MX10.AC2N]

1 hour ago, jock said:

@MX10.AC2N Great, happy that we're very close to the solution

To get 1.3Ghz, just add rk3318-box-cpu-hs overlay.

If I read the dtb correctly, also the wifi is attached to the extra sdio bus on your board, so you'd better add rk3318-box-wlan-ext overlay too!

 

Reboot and you should get these two other things.

 

BTW: you can also use rk3318-config to do all the necessary overlay configuration with the comfy menu interface. Just need to manually edit armbianEnv.txt before rebooting and set rk3318-box-led-conf3 in place of any other led-conf (there must be only one led-conf overlay). In the next update I will add the led-conf3 to rk3318-config so coming people with boxes like yours will find the recipe ready-made

Great, I did find 1300MHz as the maximum value for the CPU, for the wifi I will have to look because I use the box connected by wire (and then it's an SV6051P chip ..)
thanks again, and again

[MX10.AC2N]

Little feedback
I was able to build bat https://github.com/sharkdp/bat and dust https://github.com/bootandy/dust from sources without any particular problem..

Really happy with your great work, I will test the overlay for 1.4GHz because during the construction phase the temperature was not that high, around 60 ° C ..

 

[jock]

Of course, fell free to try and report