jock Posted October 13, 2021 Author Posted October 13, 2021 @Matteo Venturi This post may be somehow helpful. Post the logs and the results of the get-edid command 0 Quote
hexdump Posted October 13, 2021 Posted October 13, 2021 @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 1 Quote
Matteo Venturi Posted October 13, 2021 Posted October 13, 2021 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 0 Quote
MX10.AC2N Posted October 14, 2021 Posted October 14, 2021 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 0 Quote
jock Posted October 14, 2021 Author Posted October 14, 2021 @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. 0 Quote
jock Posted October 14, 2021 Author Posted October 14, 2021 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. 1 Quote
Matteo Venturi Posted October 14, 2021 Posted October 14, 2021 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! 1 Quote
MX10.AC2N Posted October 15, 2021 Posted October 15, 2021 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 0 Quote
jock Posted October 15, 2021 Author Posted October 15, 2021 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. 0 Quote
jock Posted October 15, 2021 Author Posted October 15, 2021 (edited) @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 0 Quote
Gausus Posted October 16, 2021 Posted October 16, 2021 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>; // }; // }; 1 Quote
jock Posted October 16, 2021 Author Posted October 16, 2021 @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. 0 Quote
Gausus Posted October 16, 2021 Posted October 16, 2021 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>; }; 0 Quote
jock Posted October 16, 2021 Author Posted October 16, 2021 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. 2 Quote
Ben N Voutour Posted October 17, 2021 Posted October 17, 2021 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 0 Quote
MX10.AC2N Posted October 17, 2021 Posted October 17, 2021 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. 0 Quote
jock Posted October 17, 2021 Author Posted October 17, 2021 @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. 0 Quote
MX10.AC2N Posted October 17, 2021 Posted October 17, 2021 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 ... 0 Quote
jock Posted October 17, 2021 Author Posted October 17, 2021 @MX10.AC2Nwell at least some error is showing up: Failed to register regulator: -517 I will try to find what's wrong with that. 1 Quote
jock Posted October 17, 2021 Author Posted October 17, 2021 @MX10.AC2N Hmm, would try with this other dtbo? rockchip-rk3318-box-led-conf3.dtbo 0 Quote
MX10.AC2N Posted October 17, 2021 Posted October 17, 2021 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 .. 0 Quote
jock Posted October 17, 2021 Author Posted October 17, 2021 @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 1 Quote
MX10.AC2N Posted October 17, 2021 Posted October 17, 2021 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 0 Quote
MX10.AC2N Posted October 17, 2021 Posted October 17, 2021 system diagnosis information http://ix.io/3C3k I try to set CPU governor with armbian-config but error.. 0 Quote
jock Posted October 17, 2021 Author Posted October 17, 2021 @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 0 Quote
MX10.AC2N Posted October 18, 2021 Posted October 18, 2021 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.. 1 Quote
jock Posted October 18, 2021 Author Posted October 18, 2021 @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 1 Quote
MX10.AC2N Posted October 18, 2021 Posted October 18, 2021 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 1 Quote
MX10.AC2N Posted October 18, 2021 Posted October 18, 2021 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 .. 0 Quote
jock Posted October 18, 2021 Author Posted October 18, 2021 Of course, fell free to try and report 0 Quote
Recommended Posts
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.