Jump to content

CSC Armbian for RK3318/RK3328 TV box boards


jock

Recommended Posts

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.

Link to comment
Share on other sites

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 by callegar
Link to comment
Share on other sites

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... 🤨

Link to comment
Share on other sites

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 by callegar
Link to comment
Share on other sites

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...

Link to comment
Share on other sites

@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

 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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 by Seth
Link to comment
Share on other sites

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 by fabiobassa
Link to comment
Share on other sites

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 by callegar
Link to comment
Share on other sites

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 :rolleyes: 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! 😌

Link to comment
Share on other sites

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.

IMG_20220711_120208.jpg

IMG_20220711_120242.jpg

dmesg.multitool.log

Edited by Seth
added board version and tested kernel 5.15 build
Link to comment
Share on other sites

@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?

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

@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.

 

Link to comment
Share on other sites

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 by Seth
Link to comment
Share on other sites

@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

 

Link to comment
Share on other sites

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)

 

 

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 by MX10.AC2N
Link to comment
Share on other sites

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 😥

Link to comment
Share on other sites

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 by paradigman
Link to comment
Share on other sites

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 by Gausus
Link to comment
Share on other sites

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!

Link to comment
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines