callegar Posted July 5, 2022 Posted July 5, 2022 After more tests, what makes the difference is probably not the kernel (5.15 vs 5.18) but the dtb: with linux-dtb-current-rockchip64_22.08.0-trunk_arm64.deb and kernel linux-image-current-rockchip64_22.08.0-trunk_arm64.deb (5.15) the system does not boot, but with the same kernel and the former linux-dtb-current-rockchip64_22.05.0-trunk_arm64.deb the system works fine. 1 Quote
callegar Posted July 8, 2022 Posted July 8, 2022 (edited) The relevant difference seems to be in the `board-tvbox-rk3318.patch` file that is updated also for the 5.15 kernel sources in the *22.08* packages. The latest git commit is "rk3318: use 666mhz ddrbin, reduce cpu and gpu voltages". It is unclear to me which part of it is playing badly with my board, whether the "use 666MHz" or the "reduce cpu voltage". I understand that both of them can lead to erratic behavior and code segfaulting (either because the CPU is operating incorrectly as its voltage is too low for the given frequency or because incorrect data is exchanged with the memory if the latter cannot work at 666MHz). My suspect is that the issue is with the reduced cpu voltage, since other users in this thread report instability and it looks like they "fixed" it by reducing the cpu frequency (that is finding a sweet spot wrt the voltage-frequency trade off at a lower voltage). Because reducing the CPU frequency is not all that desirable performance wise, I would like to ask about the reason for the cpu voltage reduction. Was the cpu incorrectly run out of specs wrt its voltage until 22.08 so that had to be fixed? Edited July 8, 2022 by callegar 0 Quote
jock Posted July 8, 2022 Author Posted July 8, 2022 5 hours ago, callegar said: The relevant difference seems to be in the `board-tvbox-rk3318.patch` file that is updated also for the 5.15 kernel sources in the *22.08* packages. The latest git commit is "rk3318: use 666mhz ddrbin, reduce cpu and gpu voltages". It is unclear to me which part of it is playing badly with my board, whether the "use 666MHz" or the "reduce cpu voltage". I understand that both of them can lead to erratic behavior and code segfaulting (either because the CPU is operating incorrectly as its voltage is too low for the given frequency or because incorrect data is exchanged with the memory if the latter cannot work at 666MHz). My suspect is that the issue is with the reduced cpu voltage, since other users in this thread report instability and it looks like they "fixed" it by reducing the cpu frequency (that is finding a sweet spot wrt the voltage-frequency trade off at a lower voltage). Because reducing the CPU frequency is not all that desirable performance wise, I would like to ask about the reason for the cpu voltage reduction. Was the cpu incorrectly run out of specs wrt its voltage until 22.08 so that had to be fixed? Actually it looks like all the hints are pointing to such cpu voltage issue, but that patch is for kernel 5.15 but issues are related to kernel 5.18. Working for support for another board, I discovered a patch that was only in kernel 5.18 armbian patchset that was breaking rk3318/rk3328 PWM regulation (in turn it broke voltage regulation on our tvboxes that use PWM to modulate cpu and gpu voltages), but the latest compilation should already have that patch removed. I'll try to rebuild things and provide images and debs from scratch as soon as I can. edit: I forgot to add that the PWM breakage is not consisting with @MX10.AC2N experience, since he has an rk3328 board with "proper" voltage regulator chip (rk805) and thus does not use the cheaper PWM regulation for cpu voltage... 🤨 0 Quote
callegar Posted July 9, 2022 Posted July 9, 2022 (edited) 14 hours ago, jock said: that patch is for kernel 5.15 but issues are related to kernel 5.18 Indeed, I found because a few people were reporting issues with 5.18, but at the very same time I was encountering quite similar issues on 5.15, which seemed to me a weird coincidence. I saw there is no similar patch for 5.18, so I thought that maybe that 5.15 patch was meant at porting into 5.15 some change that was already in built in 5.18 and maybe help at confining the search for the actual problem. I do not have enough knowledge about the inner matters, though. 14 hours ago, jock said: I discovered a patch that was only in kernel 5.18 armbian patchset that was breaking rk3318/rk3328 PWM regulation Is there some way to find out if a tvbox has aproper power regulation or not (apart from breaking that open)? In addition to that, should I also test the 333MHz idbloader? Is there an easy way to switch back and forth from the 333 and 666MHz idbloader? I've seen that changing the idboader is a matter of dd-ing a file onto the machine, but it is unclear to me which file is for 333 and which one for 666 MHz. Looking forward to the new build to test. Edited July 9, 2022 by callegar 0 Quote
jock Posted July 9, 2022 Author Posted July 9, 2022 23 minutes ago, callegar said: In addition to that, should I also test the 333MHz idbloader? Is there an easy way to switch back and forth from the 333 and 666MHz idbloader? I've seen that changing the idboader is a matter of dd-ing a file onto the machine, but it is unclear to me which file is for 333 and which one for 666 MHz. No, there is no easy way other than doing dd. As long as you have no issues if your cpu runs at 1.1 Ghz (actual 1.0Ghz...) there is no reason to blame DDRs at 666 MHz. I will double check the voltages and compare them against a previous edition, maybe the bug could be just there... 0 Quote
jock Posted July 9, 2022 Author Posted July 9, 2022 @callegar@Willy Moto@MX10.AC2N Ok, I double checked the cpu voltage supply and effectively it seems that in the latest device tree I pushed it way too low... The original device tree of my box said 1.375v@1.3Ghz, the voltage in mainline kernel says 1.300v@1.3Ghz and I set 1.200v@1.3Ghz. That is very good for temperatures and power consumption, but maybe it is a bit too low for stable operations. I will rebuild the whole set of images, but in the meantime I updated the dtb deb package you can install that should fix issues: https://users.armbian.com/jock/rk3318/upgrade/linux-dtb-edge-rockchip64_22.08.0-trunk_arm64.deb 3 Quote
callegar Posted July 9, 2022 Posted July 9, 2022 2 hours ago, jock said: I updated the dtb deb package you can install that should fix issues Tried with that and the edge kernel packages. Now I have 5.18.6 and everything seems fine. Just one question: I now have both the -current and -edge kernel packages installed and the system boots the -edge kernel. I think I should remove the -current packages, right? Some armbian threads seems to state that switching kernel from legacy to current, from current to edge or the other ways round should be done with the assistance of `armbian-config` for the removal of the unused packages. I do not have such option in `armbian-config` though. Is it OK to just remove the -current packages? 0 Quote
jock Posted July 9, 2022 Author Posted July 9, 2022 28 minutes ago, callegar said: Tried with that and the edge kernel packages. Now I have 5.18.6 and everything seems fine. Just one question: I now have both the -current and -edge kernel packages installed and the system boots the -edge kernel. I think I should remove the -current packages, right? Some armbian threads seems to state that switching kernel from legacy to current, from current to edge or the other ways round should be done with the assistance of `armbian-config` for the removal of the unused packages. I do not have such option in `armbian-config` though. Is it OK to just remove the -current packages? AFAIK normally the packages are configured to "conflict" when the same package is installed for another current/edge flavour. Ie: if you install the "current" kernel flavour, it first removes the "edge" or "legacy" kernel flavour and then installs the "edge" one. So in theory if you reinstall the "edge" set of packages, apt should automatically remove the "current" set. In theory. Anyway your mileage may vary, since the process is a bit "tricky" and may hang in every corner. Personally, I would go manual first removing the "current" packages and then reinstalling the "edge" packages just after to be sure all the files, symlinks and dtbs goes in the proper place. Anyway I'm in the process of rebuilding the images and packages for kernel 5.18.10, I think I will upload them in minutes... 0 Quote
jock Posted July 9, 2022 Author Posted July 9, 2022 @callegar Ok, finally I uploaded all the packages and refreshed images with 5.18.10 kernel. I didn't test them though, so be wise... 0 Quote
Vittorio Mori Posted July 10, 2022 Posted July 10, 2022 (edited) Edited July 10, 2022 by Vittorio Mori wrong thread 0 Quote
fabiobassa Posted July 10, 2022 Posted July 10, 2022 (edited) edit Edited July 10, 2022 by fabiobassa 0 Quote
Seth Posted July 10, 2022 Posted July 10, 2022 (edited) Ok, waited a bit before posting. i got myself an h96 max box to play around with and did some preliminary testing with the stock android firmware, installed terminal and copied the device tree using hexdump's script as well as dmesg log. will upload photos of the board soon as well as the device's relevant part numbers. dmesg.log device-tree-copy.tar.gz Edited July 10, 2022 by Seth 2 Quote
fabiobassa Posted July 10, 2022 Posted July 10, 2022 (edited) unfortunately x96 max ...mini.. half sized 🤣 are so useless categories. they use the same name for 322x and 3318 and even amlogic Thank you @Seth for your apport and support 👍 looking forward for photos and further infos Edited July 10, 2022 by fabiobassa 1 Quote
callegar Posted July 10, 2022 Posted July 10, 2022 (edited) On 7/9/2022 at 4:02 PM, jock said: uploaded all the packages and refreshed images with 5.18.10 kernel Just installed them and they seem totally fine. A big thank you!!! When you ssh onto the machine you find it at 60°. With the 22.05 build I think it was at 61°, so maybe there is also a little advantage here. Also got rid of the previous `-current` dtb, kernel and headers packages. One final question: the correct u-boot to use is the one from the previous 5.15 branch, namely `linux-u-boot-current-rk3318-box_22.08.0-trunk_arm64.deb`, right? Edited July 10, 2022 by callegar 0 Quote
jock Posted July 10, 2022 Author Posted July 10, 2022 5 hours ago, callegar said: Just installed them and they seem totally fine. A big thank you!!! When you ssh onto the machine you find it at 60°. With the 22.05 build I think it was at 61°, so maybe there is also a little advantage here. Also got rid of the previous `-current` dtb, kernel and headers packages. One final question: the correct u-boot to use is the one from the previous 5.15 branch, namely `linux-u-boot-current-rk3318-box_22.08.0-trunk_arm64.deb`, right? They are exactly the same, actually I noticed that I didn't upload the u-boot "edge" package but using the "current" u-boot is right the same since the difference is in the kernel package. Hopefully this mess about manual upgrades will end soon on next armbian release cycle or even before when new packages will be rebuilt! 😌 1 Quote
Seth Posted July 11, 2022 Posted July 11, 2022 (edited) hi, i have since tried installing @jock's latest 5.18 kernel on my h96 max box. multitool boots fine and functions, i tried flashing armbian minimal but it fails to initialize hdmi display, the red led is solid and the blue led is blinking, so the kernel seems to boot fine and is waiting for user input for initial setup. i was also able to backup and restore the firmware successfully. i also do not recognize the sdio wifi module attached, will have to scour the net to check out part number and datasheet. pics and multitool dmesg log attached. i will also attach a serial to it tonight and upload logs with the armbian installed. board version is rk3318_v1.4 with date 2020/06/29 evening: i was about to solder uart header when i realized that i forgot to try kernel 5.15 minimal build, so i downloaded it and lo and behold, it booted fine and initialized the hdmi perfectly, everything works even the wifi. i will try the desktop build next and continue to update this post. dmesg.multitool.log Edited July 11, 2022 by Seth added board version and tested kernel 5.15 build 0 Quote
JMCC Posted July 11, 2022 Posted July 11, 2022 @jock I got some X88 pro 10 laying around, and tried your solution. It works great, I was able to boot from the multitool, and flash Armbian to the emmc. However, I am wondering if there is any possibility to keep the original Android on the emmc, and boot Armbian when plugged on a SD card/USB. After all, if it can boot the multitool with the original firmware on emmc, there must be some way to boot the full Armbian image, right? Maybe an issue with Mainline U-Boot, and you are using BSP u-boot for the multitool? 0 Quote
jock Posted July 11, 2022 Author Posted July 11, 2022 1 hour ago, JMCC said: After all, if it can boot the multitool with the original firmware on emmc, there must be some way to boot the full Armbian image, right? Maybe an issue with Mainline U-Boot, and you are using BSP u-boot for the multitool? Yes, you can. Actually the choice to remove any Android code from the board is a deliberate choice by me 😝 but has some performance and compatibility reasons, since this way the user is in control of the ddrbin, miniloadloader/SPL and trustos. The explanation is not exactly simple because these three pieces then cause unwanted behaviours, especially the proprietary trustos does not allow rk3318 to run above 1.1GHz. I guess rockchip put an artificial cap because the chip can run fine at 1.3GHz or even overclocked at 1.5GHz. A pro of the proprietary trustos is that it allows DDR frequency scaling, that is not allowed by the opensource trustos, but to overcome this I patched the ddrbin to use ram at 667MHz with great benefits in terms of multimedia and general performance. If you run stock Android you are forced to use the "stock" ddrbin at 300/333 MHz because the rockchip boot always happens from internal flash... so it's a chain of issues and to avoid all of these hassles I prefer to erase Android and start fresh. If you still want to go the "Android" mixed way, @hexdump wrote a document on his github on how to do, but I always forget the bookmark the link... That's still something that should be exclusive for the power user because that belong to the same class of those I explained above are around the corner. 2 Quote
jock Posted July 11, 2022 Author Posted July 11, 2022 @Seth good job! That's a pity and way strange HDMI does not work on 5.18 kernel; nothing actually changed there and there is no real reason for such wrong behaviour. The board is unknown to me, maybe whenever you can just post a dmesg of the mainline kernel; the original device tree or even the original firmware are pretty interesting to understand why the wifi chip (8934, that a new number...) is not detected. 1 Quote
Seth Posted July 11, 2022 Posted July 11, 2022 (edited) 1 hour ago, jock said: @Seth good job! That's a pity and way strange HDMI does not work on 5.18 kernel; nothing actually changed there and there is no real reason for such wrong behaviour. The board is unknown to me, maybe whenever you can just post a dmesg of the mainline kernel; the original device tree or even the original firmware are pretty interesting to understand why the wifi chip (8934, that a new number...) is not detected. yeah, that got me scratching my head too. anyway, the sdio wifi is now detected as ampak ap6330 specifically brcm43342 and it works on mainline 5.15 even with full desktop when i tested it earlier. i reverted back to minimal since i have no need for the desktop, i'll consolidate the logs here as well as android device tree. i'm really having fun with these tv boxes especially when i got one to work as klipper host for my 3d printer... also the price of raspberry pi's are ridiculous nowadays. orange pi's are just fine though but i find this helter skelter of armbian tv box zoo so fascinating minus the gpio headers of course. thanks again @jock and @fabiobassa for all your effort. you guys are awesome! after updating. kernel and headers held using apt hold. http://ix.io/445q device-tree-copy-android.tar.gz device-tree-copy-kernel-5.15.tar.gz dmesg.multitool.log dmesg-5.15-kernel.log dmesg-android10.log Edited July 11, 2022 by Seth 1 Quote
JMCC Posted July 11, 2022 Posted July 11, 2022 @jock Thanks for the info. On a side note, I found a small bug: when making the emmc backup, if the resulting file is bigger than 4Gb it will just stop there (because of the FAT size limit) and you will get a broken backup. Probably could be solved by splitting the backup, for example along these lines: # Split backup in 2Gb parts, with two-character suffixes dd if=/dev/mmcblk1 | gzip -c | split -b 2000m - tvbox-backup.img.gz. # Restore the backup cat tvbox-backup.img.gz.* | gzip -dc | dd of=/dev/mmcblk1 3 Quote
hexdump Posted July 11, 2022 Posted July 11, 2022 (edited) @jock and JMCC: i think this is what you ment: https://github.com/hexdump0815/u-boot-misc/blob/master/readme.rk3328#L43-L53 - right? i think you had it initially in your rk322x instructions, but dropped it at some point. best wishes - hexdump Edited July 11, 2022 by hexdump 0 Quote
jock Posted July 11, 2022 Author Posted July 11, 2022 2 hours ago, JMCC said: @jock Thanks for the info. On a side note, I found a small bug: when making the emmc backup, if the resulting file is bigger than 4Gb it will just stop there (because of the FAT size limit) and you will get a broken backup. Probably could be solved by splitting the backup, for example along these lines: # Split backup in 2Gb parts, with two-character suffixes dd if=/dev/mmcblk1 | gzip -c | split -b 2000m - tvbox-backup.img.gz. # Restore the backup cat tvbox-backup.img.gz.* | gzip -dc | dd of=/dev/mmcblk1 Yes, there is this "little" bug. Actually split could be useful, but I would like to solve the issue at the root and probably use an NTFS or exFAT partition rather than old FAT32 Also because splitting does not play well in the current command line (the last dd is to avoid write cache, I find it more reliable): (pv -n "/dev/$BLK_DEVICE" | pigz | dd of="$BACKUP_PATH" iflag=fullblock oflag=direct bs=512k 2>/dev/null) 0 Quote
JMCC Posted July 11, 2022 Posted July 11, 2022 Sorry, anybody has a stock-android flash backup for X88 Pro 10, made with jock's Multitool? I have been trying to use the official Rockchip tool to flash the firmware, but no luck, these devices are so crappy... (More info: I made a backup, but it is corrupted due to the 4Gb bug) 0 Quote
MX10.AC2N Posted July 12, 2022 Posted July 12, 2022 (edited) Hi everyone, @jock I upgrade with kernel 5.18.10. on SD-Card There is again an error while install headers Setting up linux-headers-edge-rockchip64 (22.08.0-trunk) ... Compiling headers - please wait ... scripts/sign-file.c: In function ‘display_openssl_errors’: scripts/sign-file.c:89:9: warning: ‘ERR_get_error_line’ is deprecated: Since Ope nSSL 3.0 [-Wdeprecated-declarations] 89 | while ((e = ERR_get_error_line(&file, &line))) { | ^~~~~ In file included from scripts/sign-file.c:29: /usr/include/openssl/err.h:411:15: note: declared here 411 | unsigned long ERR_get_error_line(const char **file, int *line); | ^~~~~~~~~~~~~~~~~~ scripts/sign-file.c: In function ‘drain_openssl_errors’: scripts/sign-file.c:102:9: warning: ‘ERR_get_error_line’ is deprecated: Since Op enSSL 3.0 [-Wdeprecated-declarations] 102 | while (ERR_get_error_line(&file, &line)) {} | ^~~~~ In file included from scripts/sign-file.c:29: /usr/include/openssl/err.h:411:15: note: declared here 411 | unsigned long ERR_get_error_line(const char **file, int *line); | ^~~~~~~~~~~~~~~~~~ scripts/sign-file.c: In function ‘read_private_key’: scripts/sign-file.c:142:17: warning: ‘ENGINE_load_builtin_engines’ is deprecated : Since OpenSSL 3.0 [-Wdeprecated-declarations] 142 | ENGINE_load_builtin_engines(); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from scripts/sign-file.c:30: /usr/include/openssl/engine.h:358:28: note: declared here 358 | OSSL_DEPRECATEDIN_3_0 void ENGINE_load_builtin_engines(void); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/sign-file.c:144:17: warning: ‘ENGINE_by_id’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 144 | e = ENGINE_by_id("pkcs11"); | ^ In file included from scripts/sign-file.c:30: /usr/include/openssl/engine.h:336:31: note: declared here 336 | OSSL_DEPRECATEDIN_3_0 ENGINE *ENGINE_by_id(const char *id); | ^~~~~~~~~~~~ scripts/sign-file.c:146:17: warning: ‘ENGINE_init’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] 146 | if (ENGINE_init(e)) | ^~ In file included from scripts/sign-file.c:30: /usr/include/openssl/engine.h:620:27: note: declared here 620 | OSSL_DEPRECATEDIN_3_0 int ENGINE_init(ENGINE *e); | ^~~~~~~~~~~ scripts/sign-file.c:151:25: warning: ‘ENGINE_ctrl_cmd_string’ is deprecated: Sin ce OpenSSL 3.0 [-Wdeprecated-declarations] 151 | ERR(!ENGINE_ctrl_cmd_string(e, "PIN", key_pass, 0), | ^~~ In file included from scripts/sign-file.c:30: /usr/include/openssl/engine.h:479:5: note: declared here 479 | int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char * arg, | ^~~~~~~~~~~~~~~~~~~~~~ scripts/sign-file.c:153:17: warning: ‘ENGINE_load_private_key’ is deprecated: Si nce OpenSSL 3.0 [-Wdeprecated-declarations] 153 | private_key = ENGINE_load_private_key(e, private_key_nam e, | ^~~~~~~~~~~ In file included from scripts/sign-file.c:30: /usr/include/openssl/engine.h:638:11: note: declared here 638 | EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id, | ^~~~~~~~~~~~~~~~~~~~~~~ Processing triggers for initramfs-tools (0.140ubuntu13) ... update-initramfs: Generating /boot/initrd.img-5.18.10-rockchip64 update-initramfs: Converting to u-boot format N: Download is performed unsandboxed as root as file '/root/kernel_update/5.18.y /armbian-bsp-cli-rk3318-box_22.08.0-trunk_arm64.deb' couldn't be accessed by use r '_apt'. - pkgAcquire::Run (13: Permission denied) Reboot fine, so I switch CPU freq to 1,3ghz And system seem to be stable.. Wait and see.. EDIT: Freeze after 1H07 uptime.. Go back to 1ghz.. Great work has always.. Thank @jock 🥇 root@MX10-TvBox:~# uname -a Linux MX10-TvBox 5.18.10-rockchip64 #trunk SMP PREEMPT Sat Jul 9 12:47:45 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux root@MX10-TvBox:~# neofetch root@MX10-TvBox --------------- █ █ █ █ █ █ █ █ █ █ █ OS: Armbian (22.08.0-trunk) aarch64 ███████████████████████ Host: Rockchip RK3318 BOX ▄▄██ ██▄▄ Kernel: 5.18.10-rockchip64 ▄▄██ ███████████ ██▄▄ Uptime: 31 mins ▄▄██ ██ ██ ██▄▄ Packages: 1390 (dpkg) ▄▄██ ██ ██ ██▄▄ Shell: bash 5.1.16 ▄▄██ ██ ██ ██▄▄ Terminal: /dev/pts/1 ▄▄██ █████████████ ██▄▄ CPU: (4) @ 1.296GHz ▄▄██ ██ ██ ██▄▄ Memory: 510MiB / 3973MiB ▄▄██ ██ ██ ██▄▄ ▄▄██ ██ ██ ██▄▄ ▄▄██ ██▄▄ ███████████████████████ █ █ █ █ █ █ █ █ █ █ █ root@MX10-TvBox:~# Edited July 12, 2022 by MX10.AC2N 0 Quote
jock Posted July 12, 2022 Author Posted July 12, 2022 11 hours ago, JMCC said: Sorry, anybody has a stock-android flash backup for X88 Pro 10, made with jock's Multitool? I have been trying to use the official Rockchip tool to flash the firmware, but no luck, these devices are so crappy... (More info: I made a backup, but it is corrupted due to the 4Gb bug) If you have the "upgrade image" (or whatever they call it), probably you may use the Android Tool for windows to restore the firmware. You can find the Android Tool in the rockchip github repositories (maybe rkbin-tools...) That image is not a plain image/dump , but rather made of segments that Android Tool can interpret and upload in the correct places. Sorry for the bad experience 😥 0 Quote
paradigman Posted July 12, 2022 Posted July 12, 2022 (edited) On 7/2/2022 at 12:29 PM, jock said: There is such 2734C chip, a google search would have confirmed that to you easily. The chipset under the hood is an ampak AP6334 which is in turn made of a couple of broadcom chips. The wireless part is a bcm4334. Probably your issue is not the dtb but the wifi chip firmware or, more in particular, the nvram /lib/firmware/brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt which is not suitable for your board setup. The wifi depends on how the board is build for important things like reference frequency, antenna setup, sideband gpio, etc... If the nvram does not specify these params correctly, it will not perform well or will not work at all. The best thing you could do is mount the vendor partition of your Android firmware and search for a suitable firmware for your board or extract from the live Android system. Tthat could be easy but could also require various steps to get access to the partition, it depends and how the firmware is built. Otherwise you could look around in google, download new nvrams for bcm4334/ap6334 and try and see if they work for you. edit: BTW the wifi chip is fully supported by linux kernel and works wonderfully well on my board; when I say don't buy tv boxes if you want supported hardware I mean exactly this. I finally managed to solve the problem, my box can connect to wifi with that new 2734C chip. Thanks to @jock for directing my attention to the nvram file, I was wrong, dtb was not needed to solve it. However, Google didn't help with the solution (I don't even understand how it could have helped), but I contacted the Chinese manufacturer of the box and they helped. I have attached the correct nvram file, the content of which I overwrote the brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt file that comes with the current image. I recommend that you integrate it into the kernel, because the current kernel does not, or at least does not, support this widely used wireless chip. nvram_2734c.txt Edited July 12, 2022 by paradigman 4 Quote
Gausus Posted July 12, 2022 Posted July 12, 2022 (edited) Simple memory tests to compare 333Mhz vs 666MHz 666MHz / CPU @ 1,3 Ghz kernel 5.18 uboot eMMc dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.41804 s, 307 MB/s 333 ? Mhz (Androide uboot) / CPU @ 1,3 Ghz dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.95373 s, 265 MB/s Edited July 12, 2022 by Gausus 0 Quote
jock Posted July 13, 2022 Author Posted July 13, 2022 @Gausus You'd better try a specialized memory benchmark application like mbw rather than involving the linux filesystem subsystem and dd to do such kind of benchmarks. 0 Quote
jock Posted July 13, 2022 Author Posted July 13, 2022 On 7/12/2022 at 4:54 PM, paradigman said: I finally managed to solve the problem, my box can connect to wifi with that new 2734C chip. Thanks to @jock for directing my attention to the nvram file, I was wrong, dtb was not needed to solve it. However, Google didn't help with the solution (I don't even understand how it could have helped), but I contacted the Chinese manufacturer of the box and they helped. I have attached the correct nvram file, the content of which I overwrote the brcm/brcmfmac4334-sdio.rockchip,rk3318-box.txt file that comes with the current image. I recommend that you integrate it into the kernel, because the current kernel does not, or at least does not, support this widely used wireless chip. nvram_2734c.txt 2.59 kB · 2 downloads Glad to hear that you solved the issue; I will put this nvram in the armbian firmware repository as well, thanks! 3 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.