CSC Armbian for RK3318/RK3328 TV box boards

[jock]

@Netraam31 hello! You're in the right direction, dr_mode="otg" simply can't work without a micro/typec usb connector. The main feature of the OTG port is the capability to switch on the fly in host or peripheral mode, but to do that a fifth pin in required. Regular USB-A ports have only 4 pins, so when you get them you surely cannot exploit the OTG feature.

The USB port is still called OTG because it is "dual role" (host vs. peripheral), but simply cannot switch automatically, hence you have to change it in the device tree.

 

Finally what is true for the rk322x is true also for rk3318: during my tests the peripheral mode was not behaving correctly without disabling the clock gating and adjusting the core reset timing. The clock gating issue has been fixed in kernel 6.8 (the patch addresses the issue on 6.6), but the reset timing can still give some trouble.

 

Mass storage mode was my testbed, along ethernet emulation; what is still not working at all is the audio gadget which, I guess, uses isochronous mode which is still buggy.

 

Anyway you surely have to set the OTG port as device mode you have to use dr_mode="peripheral" in the device tree. On rk322x there is a quick device tree overlay to do that, without editing and fiddling with details. I don't remember if there is a similar overlay for rk3318/rk3328, but I guess not.

 

Notice also that you will not see any USB device connected on the other side when USB2 port is in peripheral mode until a gadget is set up.

There are several guides around (especially for raspberry pi) on how to setup a gadget, you can use them to actually test the port.

 

 

 

[Netraam31]

Hi @jock, thanks for your quick reply. I originally used dr_mode="peripheral" as I indeed read earlier that the auto-switching otg wouldn't work on standard old USB A interfaces. So that it didn't work properly in dr_mode="otg" confirms my understanding.

But even when I have it in dr_mode="peripheral", and while kvmd is running and in its logs says something about configuring the gadgets (keyboard, mouse), the USB A - USB A connection to the other host seems to be "dead". Nothing to be seen at either end. Tried with only ground/data+/data- and with ground/data+/data-/5v connected. Neither seems to work.

 

In the documentation, there's also something about adding "overlays=usbhost0 usbhost1 usbhost2 usbhost3" to /boot/armbianEnv.txt but unclear if that applies to rk3318 as well. Tried with and without, but that also doesn't seem to help.

I'm comfortable with editing dts/dtb files, but don't have enough knowledge about all the details in there.

 

As I've been trying to tinker with too many things over the past days, I think I'll first revert back to a fresh img to make sure there's nothing from older xe5700 kvmd-armbian in the way blocking srepac's version from working properly.

 

One last question for now: the changes you backported from 6.8 to 6.6 for rk322x, are those also already included in the 6.6.23 (306) image for rk3318-box? Or should I expect clock gating issue to still be present in the rk3318-box files?

 

 

Edited April 4 by Netraam31

[jock]

1 hour ago, Netraam31 said:

One last question for now: the changes you backported from 6.8 to 6.6 for rk322x, are those also already included in the 6.6.23 (306) image for rk3318-box? Or should I expect clock gating issue to still be present in the rk3318-box files?

 

Actually the issue was fixed only for rk322x in 6.6; if you take a look to the patches, I didn't backport but made a special case for rk322x on my own: I was not aware if other rockchip chips were affected by the issue. A few days after, the same clock gating fix materialized in the 6.8 kernel for all the rockchip chips. Anyway, this is just for the chronicles; about your specific question the answer is yes, the issue is still present for rk3318/rk3328 in kernel 6.6.

 

I'd like to take a look this evening and do some tests and in case make a patch for rk3318 too, stay tuned for news!

 

[jock]

@Netraam31 I did a quick check on a board with rk3328 (not rk3318, but should be the same) and you can use both the USB2 OTG port or the USB3 port as peripheral.

in the device tree the device usb@ff580000 is the USB2 OTG port controller and usb@ff600000 is the USB3 port controller.

 

I quickly tried ethernet gadget to check if it works. This command loads the USB ethernet gadget module. which is a bit of "deprecated" in favor of configfs, but it is handy for tests (run it with the USB cables connected):

 modprobe g_ether iSerialNumber=0x00000001

 

Then a device usb0 should spawn on both the machines, which is nothing more and nothing less than a regular network interface. You have to give an address to both the endpoints and then you should be able to ping and exchange data.

 

The result is that, at the current state of the kernel 6.1 I have right now (but 6.6 is exactly the same, since nothing changed), the USB 3.0 port is working plenty well, instead the USB 2.0 port is suffering the same problems experienced for rk322x, which disconnection and system freeze.

 

Things seems to have changed with kernel 6.8, where also the USB 2.0 ports seems to work, thanks to the upstreamed fix for clock gating. You should be able to upgrade to kernel 6.8 installing the linux-image-rockchip64-edge package or, more appropriately, via armbian-config.

 

Don't forget to put kernel and dtb packages in hold if you modify them manually, otherwise updates will overwrite your modifications!

 

 

 

[Netraam31]

It appears that the

overlays=usbhost0 usbhost1 usbhost2 usbhost3

mentioned in the readme at https://github.com/srepac/kvmd-armbian is not necessary for rk3318-box.

As you said, setting dr_mode to peripheral works for both the usb2 port and the usb3 port. Not tried both in peripheral mode at the same time, as the other port would be in use for the usb hdmi capture 😉 

Behaviour is the same (or at least while running the 6.8.4 edge kernel) when using usb2 or usb3 port for otg hid.

It appears the two sets of kvmd files (parts in /usr/local/lib/python3.11/ and parts in /usr/lib/python3/) didn't go too well together and I just had to restart from clean image and only use srepac version.

 

Sometimes the hid keyboard/mouse don't survive a host reboot.

I've seen the same when using pikvm on an older pi3b with the pico hid, if you connect the pico to the pi's 5v line through a diode.

Disconnecting otg cable's 5v wire appears to make this more reliable here as well, and also wouldn't backfeed the rk3318-box through the host's usb ports. That gives random weird issues anyway, and the rk3318-box would even continue running when you disconnect the rk3318-box's barrel plug. But some parts would probably fail due to lack of stable power supply, and random issues would arise until powercycled properly.

 

So thanks a lot @jock for your assistance!

[jock]

Hello, for anyone who is having difficulties with HDMI, I made an experimental 6.6.25 kernel with a very small number of patches from LibreELEC project available here.

I can't test by myself because the rk3318 board I have was already working with my monitor, yet the patched kernel did no harm on my setup.

 

If there are some successful reports, the patches will be merged into armbian and hopefully the HDMI issues will be fixed once and for all.

Thanks!

[astrosky]

@J Black KatI'll try it.  Hoping it fixes things     @jock

Edited April 7 by astrosky

[astrosky]

@jock so basically i tried to install your patch and this broke my setup and all i see is a red led.  not sure why i cant seem to get this working with a newer kernal.  but i guess i need to go back to what i did before or try to fix it  no hdmi and now no way to ssh as the board is in some kind of frozen state  i rebooted after applying the patches   

 

I prepared for the installation by ensuring that the necessary .deb files were in my Documents directory. These files were named linux-image-current-rockchip64_24.5.0-trunk_arm64__6.6.25-Se475-D0618-P53bb-Ca832H66b1-HK01ba-Vc222-B2804-R448a.deb and linux-dtb-current-rockchip64_24.5.0-trunk_arm64__6.6.25-Se475-D0618-P53bb-Ca832H66b1-HK01ba-Vc222-B2804-R448a.deb.

I ran the command sudo dpkg -i for each .deb file to install the new kernel and DTB packages. The output indicated that the installation process included preparing, unpacking, and setting up the new packages over the old versions.

During the kernel package setup, an update-initramfs process was executed, generating a new initial ramdisk for the 6.6.25-current-rockchip64 kernel and converting it to U-Boot format. The system then updated symlinks for /boot/Image, /boot/initrd.img, and /boot/uInitrd to point to the new versions.

For the DTB package installation, it was similarly unpacked and set up, with a symlink from /boot/dtb to the new DTB directory for the 6.6.25-current-rockchip64 kernel being created.

I concluded the update process by rebooting my system to apply the changes. This was done using the sudo reboot command.  but now red led is shown and no signs of life 

[jock]

@astrosky mmmh, pretty weird that it broke your setup, it is a quite standard 6.6 kernel, also it does not touch the bootloader.

Did you perhaps alter a device tree and changed it in /boot/armbianEnv.txt? because the /boot/dtb directory is replaced when the new dtb package gets installed.

[astrosky]

@jock this im not sure ........  can you recommend a image i can just install and then work from there? preferably something that starts out with things not as broken then i can simply configure it and install your patched kernal stuff AFTER?  im thinking a fresh install then straight to the patch could be the ticket  then ill disable kernel updates  straight after, even if it breaks hdmi out as long as it lets me ssh in ill be ok 

 

 

well i installed Armbian-unofficial_24.5.0-trunk_Rk3318-box_bullseye_current_6.6.23_minimal.tar  no hdmi output but i could ssh in   then i installed your patch.   setup the default config stuff now i got a blue  led and red      no hdmi out still    also could not install armbian config or run it as it does not exist for some reason in this build.... its just super confusing  as my box is a x 88 pro  like everyone else 

Edited April 10 by astrosky

[jock]

@astrosky I can't recommend you an image you can just install and everything works... tvboxes have this little problem about the changing hardware and that's not so easy.

I have repeated dozen of times that tvboxes are not the way to go, buy an SBC if you need reliability.

 

About 6.6.25 kernel, now I understand that you repeated the procedure starting from 6.6.23 image and this time the board rebooted fine but still without HDMI, am I right?

[lucky62]

Hi all,
I have a problem with OpenVFD compilation with the kernel 6.7.4-edge-rockchip64.
Seems the gpiochip_find() was removed...

Can someone help?

 

[astrosky]

@jock yeah basically no HDMI out on any Verizon 6 and above kernal based on what I tested.    The older 5 kernal works on basic desktop though. 

[jock]

@lucky62 looking with elixir, it turns out that the function was already deprecated in 6.6: https://elixir.bootlin.com/linux/v6.6.27/source/drivers/gpio/gpiolib.c#L1022

 

You could copy the body of the deprecated function in place of gpiochip_find

 

About of_get_named_gpio_flags you should see if you can afford to use the suggested function

[tERBO]

Anyone running gnome on this chip?
I have 3318 paired with 4Gb of RAM and the GUI is very slow. Choppy mouse movements, loading youtube front page with chromium takes forever, cant play videos without stutters even at 480p.
Is it supposed to be like that or do I have to enable 3D accel somewhere/somehow?

 

I know stock android fw renders at 720p (even tho you can select 4k resolution for your display) so it wont surprise me this chip just have a bad graphics core...

[astrosky]

@tERBO I run xfce4 when my HDMI works and I find it runs ok.   But yeah YouTube videos play very bad for me in general. Maybe hardware acceleration isn't working? 

[pocosparc]

@lucky62 Change your line 736 to

pin->pin = of_get_named_gpio(pdev->dev.of_node, name, 0);

 

[jock]

@astrosky @tERBO this may help you getting hardware decoded videos, but don't expect your browser work with them.

Mixing hardware video decoding into browsers compositors is not an easy task.

[s1cx]

Installed this on an old Heltec Helium miner

Any idea how to enable SPI so spidev shows in /dev/?

 

[pessimism]

Hello, wanted to post up a success note and thank you to Jock and everyone else who has contributed to this work.  I bought myself a stack of four tv boxes to play with each with different processors.  Started with the H96 Max V11 RK3318 4GB/64GB.  I read up on this thread and this person's guide and opted to build myself a trunk image from mainline to see how its doing, using the non-edge 6.6 kernel.  So far its been the most painless bringup on a TV box I've done so far (owned a couple of older amlogic ones in the past that were pretty rough to work with), the tooling has come a long way in the past few years.  I found a copy of the vendor firmware and used AmlogicKitchen to unpack it and retrieve the nvram file for the broadcom-based wifi to work, its an HS2734C, with the proper nvram file I have 2.4 and 5ghz wifi working.  I've attached a copy if its of any use, I see now that there are a few versions floating around the internet already.

 

TODO: Get HDMI audio to work.  Don't see an HDMI audio output and haven't had time to investigate.  Will report back.

 

I applied your 1.3ghz CPU tweaks in rk3318-config along with both EMMC tweaks (DDR and HS200) and they appear to be holding.  I see an HS200 message in dmesg about the EMMC and the CPU is boosting to 1.296ghz.  I'm currently burn-in testing it by bootstrapping a gentoo prefix inside the armbian environment, she's been maxed out for an hour now and holding strong, core temps are peaking at 82C maximum load then settle into the low to mid 60s, which is pretty good for this QC reject chip from what I've been reading about how leaky they are

 

One question:  When I did the installation, I opted to do a full emmc backup.  I am able to see that the resulting (60GB!) image has a GPT and named partitions inside.  I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount.  The rest seem to have no recognizable file system.  AmlogicKitchen won't work as it doesn't start out as a rockchip packed image like the recovery firmware from the vendor's website.  Do you have a script or tool to fully unpack the backups that multitool creates? (for grabbing nvram, firmware, dtb etc.)

 

Anyhow, sketchy TV box made of reject parts now a functioning desktop computer compiling software for itself.... awesome! 

brcmfmac4334-sdio.rockchip,rk3318-box.txt

Edited April 26 by pessimism

[ThaisTaki]

Hello, I am a user of your version, my English is quite bad, I am using a TVbox T9 series and it uses rk3328
it's fine in the file version
Armbian_22.05.0 wlan is fine but I use upgrade or use file version
Armbian_23.08.0 no longer recognizes wlan, some unimportant things like LEDs are not recognized when I use rk3318-config, hope to be supported soon ^^

The picture I sent is quite similar to my device, sorry for not being able to take a photo of my device.

[jock]

On 4/26/2024 at 2:18 PM, pessimism said:

One question:  When I did the installation, I opted to do a full emmc backup.  I am able to see that the resulting (60GB!) image has a GPT and named partitions inside.  I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount.  The rest seem to have no recognizable file system.  AmlogicKitchen won't work as it doesn't start out as a rockchip packed image like the recovery firmware from the vendor's website.  Do you have a script or tool to fully unpack the backups that multitool creates? (for grabbing nvram, firmware, dtb etc.)

Hello!

 

First of all, multitool creates a 1 to 1 image of the content of the eMMC; no bits are changed and nothing is rearranged in any way.

What you get in the backup is the exact content of the eMMC, some of those partitions are raw partitions that does not contain a filesystem, but rather just raw data. For example the uboot and trust partitions normally contain binary data, so you won't be able to mount them in any way because they are not filesystems. You could inspect with a hex editor though.

[jock]

@ThaisTaki Hello! I did not remove any particular driver or feature from earlier versions.

Perhaps you were using the older vendor kernel 4.4 in the previous installation? In such case, it is not supported anymore, so some device may have lose support.

 

Also notice that, depending on your board (I can't read the signature/silkprint on that from the photo), you may have to run rk3318-config twice to enable the correct driver.

[Hqnicolas]

On 4/26/2024 at 9:18 AM, pessimism said:

I am able to see that the resulting (60GB!) image has a GPT and named partitions inside.  I attempted to loopback mount them via kpartx and mount, but only a couple out of the 15 partitions will mount.  The rest seem to have no recognizable file system. 

 

You can use this method: https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/?do=findComment&comment=189369
to shrink your 60gb image onto small file

 

[Netraam31]

Hi again,

 

Quick update for potential other readers, and some questions.

 

I've now also got overlayroot setup to keep the internal flash mounted as readonly for normal operation. So as to not burn through the flash's endurance counters within a year on a device that's writing logs, status information, etc. to flash continuously. And also to protect it against issues when people just pull the plug while it's operational, potentially corrupting flash and making it unusable without physical recovery. Seems to be working great, but had to adjust the initramfs hook and script files (mount -o move instead of mount --move in script, and adding lines to copy_exec /bin/grep, /usr/bin/stat, and /bin/echo to the initramfs.

Seems to be working just great including with pikvm.

 

Two questions:

1. My rk3318 android tv box "H96 Max v11" does have the two red/blue leds on the pcb, but no clock display. There are solder points on the pcb though. Would it be possible to use these pins for GPIO access (maybe even add an I2C RTC module), or would that not be possible within the limits of hardware/firmware? Any pointers on where to start looking, if at all possible?
2. In pikvm config, following generic instructions, I was able to easily add the usb ethernet gadget and do routing/masquerading for the attached device. Yet, when I tried to configure usb mass storage gadget, the result was that the keyboard/mouse stopped responding in pikvm. From the pikvm documentation (unfolding the USB limitations section) it looks like there could be an issue with capabilities of the chip in relation to the number of endpoints needed. Yet, that page mentions mass storage would require 2 endpoints for each msd, and usb ethernet would require 3 endpoints per emulated device. So it's strange that ethernet does work but msd does not. Enabling only one at a time, of course. Is there any data on the number of endpoints available on the rk3318 chip? Or maybe someone knows how to make msd working? Or.. maybe it was intentionally disabled in srepac's kvmd-armbian because it's not working either way? The usb ethernet gadget was disabled in the config as well but works like a charm, so not sure why msd didn't work as expected. Or maybe msd is only supported for the usb3 port and not on the usb2 port that I'm now using for otg connection to the remote? Sorry, too many question marks here... Any pointers would be much appreciated!

 

[jock]

On 5/2/2024 at 4:10 PM, Netraam31 said:

I've now also got overlayroot setup to keep the internal flash mounted as readonly for normal operation. So as to not burn through the flash's endurance counters within a year on a device that's writing logs, status information, etc. to flash continuously. And also to protect it against issues when people just pull the plug while it's operational, potentially corrupting flash and making it unusable without physical recovery. Seems to be working great, but had to adjust the initramfs hook and script files (mount -o move instead of mount --move in script, and adding lines to copy_exec /bin/grep, /usr/bin/stat, and /bin/echo to the initramfs.

Not really needed to do that for wear prevention: armbian is already optimized to write logs in a zram device (so they are kept in ram and compressed on the fly) and also swap space is by default a zswap device.

 

On 5/2/2024 at 4:10 PM, Netraam31 said:

My rk3318 android tv box "H96 Max v11" does have the two red/blue leds on the pcb, but no clock display. There are solder points on the pcb though. Would it be possible to use these pins for GPIO access (maybe even add an I2C RTC module), or would that not be possible within the limits of hardware/firmware? Any pointers on where to start looking, if at all possible?

Don't know, it could be possible if some pins are directly connected to gpios, but for what I know they are connected to another led driver chip which is surely missing on your board, so the answer is probably no.

 

On 5/2/2024 at 4:10 PM, Netraam31 said:

In pikvm config, following generic instructions, I was able to easily add the usb ethernet gadget and do routing/masquerading for the attached device. Yet, when I tried to configure usb mass storage gadget, the result was that the keyboard/mouse stopped responding in pikvm. From the pikvm documentation (unfolding the USB limitations section) it looks like there could be an issue with capabilities of the chip in relation to the number of endpoints needed. Yet, that page mentions mass storage would require 2 endpoints for each msd, and usb ethernet would require 3 endpoints per emulated device. So it's strange that ethernet does work but msd does not. Enabling only one at a time, of course. Is there any data on the number of endpoints available on the rk3318 chip? Or maybe someone knows how to make msd working? Or.. maybe it was intentionally disabled in srepac's kvmd-armbian because it's not working either way? The usb ethernet gadget was disabled in the config as well but works like a charm, so not sure why msd didn't work as expected. Or maybe msd is only supported for the usb3 port and not on the usb2 port that I'm now using for otg connection to the remote? Sorry, too many question marks here... Any pointers would be much appreciated!

I tried msd on the usb2 port for both rk3318 and rk322x socs and it kinda works. The rockchip implementation of the dwc2 IP (the silicon behind the USB2 port) seems to be a bit buggy and the dwc2 driver also seems to be a bit buggy, so the whole thing is a bit buggy. Nonetheless it worked on my side, but had to make some patches for the kernel (see this) that you don't really need if you're running kernel >= 6.8 but definitely if < 6.8. As a note, audio gadget was totally out of reach.

 

Did not try having two or more USB gagdets at the same time. From the uboot dwc2 driver I'm inspecting, I see #define MAX_ENDPOINT 16, but take it with a grain of salt.

 

USB3 port seems to work a bit better.

 

edit: dmesg tells that the 3318/3328 has 10 EPs, so I guess it is an accurate number

[helix]

Hello, I'am recently install Armbian_community 24.5.0-trunk.563 Bookworm with Linux 6.6.30-current-rockchip64 on RKM v3 tv-stick and it works good, excepting wireless:

 

root@rk3318-box:~# dmesg | grep brcmfmac
[   10.596796] brcmfmac: F1 signature read @0x18000000=0x1532a9a6
[   10.609573] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430b0-sdio for chip BCM43430/2
[   10.610733] usbcore: registered new interface driver brcmfmac
[   10.611292] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430b0-sdio.rockchip,rk3318-box.bin failed with error -2
[   10.611486] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430b0-sdio.bin failed with error -2
[   11.619242] brcmfmac: brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50

 

 

RKM v3 is tv-stick with rk3328 cpu 2g ram 16g emmc (https://www.rikomagic.com/en/showgoods/90.html)

Inside the stick has rk805-1 power chip and klmag1jetd emmc chip. Not sure about memory because it under the same heat sink with cpu.

 

Stock image, extracted from eMMC with help of multitool looks like this:

 

/dev/loop0p1     16384    24575     8192     4M
/dev/loop0p2     24576    32767     8192     4M
/dev/loop0p3     32768    40959     8192     4M
/dev/loop0p4     40960    43007     2048     1M
/dev/loop0p5     43008    75775    32768    16M
/dev/loop0p6     75776   141311    65536    32M
/dev/loop0p7    141312   149503     8192     4M
/dev/loop0p8    149504   157695     8192     4M
/dev/loop0p9    157696   190463    32768    16M
/dev/loop0p10   190464   192511     2048     1M
/dev/loop0p11   192512   258047    65536    32M
/dev/loop0p12   258048   389119   131072    64M
/dev/loop0p13   389120   421887    32768    16M
/dev/loop0p14   421888   946175   524288   256M
/dev/loop0p15   946176  9334783  8388608     4G
/dev/loop0p16  9334784  9367551    32768    16M
/dev/loop0p17  9367552 13561855  4194304     2G
/dev/loop0p18 13561856 13692927   131072    64M
/dev/loop0p19 13692928 13693951     1024   512K
/dev/loop0p20 13693952 13698047     4096     2M
/dev/loop0p21 13698048 30535646 16837599     8G

 

some partitions have dtbs:

rkm_android7_dtbs/
├── p1
│  ├── 00_kernel
│  ├── 01_dtbdump_rockchip,rk3328-evb.dtb
│  ├── 02_dtbdump_rockchip,rk3328-evb.dtb
│  ├── 03_dtbdump_rockchip,rk3328-evb.dtb
│  ├── 04_dtbdump_rockchip,rk3328-evb.dtb
│  └── offset
├── p11
│  ├── 00_kernel
│  ├── 01_dtbdump_rockchip,rk3328-evb-avb.dtb
│  └── offset
├── p12
│  ├── 00_kernel
│  ├── 01_dtbdump_rockchip,rk3328-evb-avb.dtb
│  ├── 02_dtbdump_Rockchip_RK3128h_liantong_board.dtb
│  └── offset
└── p8
    ├── 00_kernel
    ├── 01_dtbdump_Rockchip_RK3128h_liantong_board.dtb
    └── offset

 

p1 01..04 files contain the same and look like for bootloader (very brief)

p11 and p12 partition contain bigger one - 01_dtbdump_rockchip,rk3328-evb-avb.dtb (same content in both p11 and p12 partitions as i see).

it contains such nodes:

 

    wireless-bluetooth {
        compatible = "bluetooth-platdata";
        clocks = <0x9a 0x01>;
        clock-names = "ext_clock";
        uart_rts_gpios = <0x76 0x0a 0x01>;
        pinctrl-names = "default\0rts_gpio";
        pinctrl-0 = <0x9b>;
        pinctrl-1 = <0x9c>;
        BT,power_gpio = <0x76 0x15 0x00>;
        BT,wake_host_irq = <0x76 0x1a 0x00>;
        status = "okay";
    };

    wireless-wlan {
        compatible = "wlan-platdata";
        rockchip,grf = <0x1c>;
        wifi_chip_type = "ap6354";
        sdio_vref = <0x708>;
        WIFI,host_wake_irq = <0x76 0x13 0x00>;
        status = "okay";
    };

 

inside the stick there is a chip with metal cap marked AP6212 but in the last_kmsg from stock firmware there is such a line:

 

<6>[    2.304427] [WLAN_RFKILL]: wlan_platdata_parse_dt: wifi_chip_type = ap6354

 

partition 17 have firmwares:

 

ls rkm_v3_p17/etc/firmware/
4343A0.hcd                  fw_bcm4334b1_ag_apsta.bin   fw_RK903_p2p.bin      rtl8723b_fw
awnb108.hcd                 fw_bcm4334b1_ag.bin         monet.bin             rtl8723bs_config
bcm20710a1_24M.hcd          fw_bcm4334b1_ag_p2p.bin     nh660.hcd             rtl8723bs_fw
bcm20710a1_26M.hcd          fw_bcm4339a0_ag_apsta.bin   nvram_4330_oob.txt    rtl8723bs_VQ0_config
bcm20710a1.hcd              fw_bcm4339a0_ag.bin         nvram_4330.txt        rtl8723bs_VQ0_fw
BCM20710A1.hcd              fw_bcm4339a0_ag_p2p.bin     nvram_AP6181.txt      rtl8723bu_config
bcm2076b1.hcd               fw_bcm43436b0_apsta.bin     nvram_AP6210_24M.txt  rtl8723d_config
bcm40183b2.hcd              fw_bcm43436b0.bin           nvram_AP6210.txt      rtl8723d_fw
bcm43241b4.hcd              fw_bcm43436b0_p2p.bin       nvram_ap6212a.txt     rtl8723ds_config
bcm4329.hcd                 fw_bcm43438a0_apsta.bin     nvram_ap6212.txt      rtl8723ds_fw
BCM4330B1.hcd               fw_bcm43438a0.bin           nvram_ap6233f.txt     rtl8761a_config
bcm43341b0.hcd              fw_bcm43438a0_p2p.bin       nvram_AP6234.txt      rtl8761a_fw
bcm4339a0.hcd               fw_bcm43438a1_apsta.bin     nvram_ap6236.txt      rtl8761at8192er_fw
bcm43438a0.hcd              fw_bcm43438a1.bin           nvram_ap6255.txt      rtl8761at_config
bcm43438a1.hcd              fw_bcm43438a1_p2p.bin       nvram_ap62x2.txt      rtl8761at_fw
BCM4343A0.hcd               fw_bcm43455c0_ag_apsta.bin  nvram_AP6330.txt      rtl8761au8192ee_fw
BCM4343A1.hcd               fw_bcm43455c0_ag.bin        nvram_AP6335.txt      rtl8761au8812ae_fw
BCM4343B0.hcd               fw_bcm43455c0_ag_p2p.bin    nvram_ap6354.txt      rtl8761au_fw
BCM4345C0.hcd               fw_bcm4354a1_ag_apsta.bin   nvram_ap6356s.txt     rtl8761aw8192eu_config
bcm4354a1.hcd               fw_bcm4354a1_ag.bin         nvram_ap6356.txt      rtl8761aw8192eu_fw
BCM4354A2.hcd               fw_bcm4354a1_ag_p2p.bin     nvram_ap6398s.txt     rtl8821a_config
BCM4356A2.hcd               fw_bcm4356a2_ag_apsta.bin   nvram_AP6441.txt      rtl8821a_fw
BCM4359C0.hcd               fw_bcm4356a2_ag.bin         nvram_ap6452.txt      rtl8821as_config
fw_awnb108_ap.bin           fw_bcm4356a2_ag_p2p.bin     nvram_AP6476.txt      rtl8821as_fw
fw_awnb108.bin              fw_bcm4359c0_ag_apsta.bin   nvram_AP6493.txt      rtl8821c_config
fw_bcm40181a2_apsta.bin     fw_bcm4359c0_ag.bin         nvram_awnb108.txt     rtl8821c_fw
fw_bcm40181a2.bin           fw_bcm4359c0_ag_p2p.bin     nvram_B23.txt         rtl8821cs_config
fw_bcm40183b2_ag_apsta.bin  fw_info.txt                 nvram_GB86302I.txt    rtl8821cs_fw
fw_bcm40183b2_ag.bin        fw_RK901a0_apsta.bin        nvram_RK901.txt       rtl8822b_config
fw_bcm40183b2_ag_p2p.bin    fw_RK901a0.bin              nvram_RK903_26M.cal   rtl8822b_fw
fw_bcm40183b2_apsta.bin     fw_RK901a2_apsta.bin        nvram_RK903.cal       rtl8822bs_config
fw_bcm40183b2.bin           fw_RK901a2.bin              nvram_RK903.txt       rtl8822bs_fw
fw_bcm40183b2_p2p.bin       fw_RK901a2_p2p.bin          nvram_WL211.txt       ssv6051-sw.bin
fw_bcm43241b4_ag_apsta.bin  fw_RK901.bin                otp.bin.z77           ssv6051-wifi.cfg
fw_bcm43241b4_ag.bin        fw_RK903_ag_apsta.bin       rk903_26M.hcd         TV_Firmware.mk
fw_bcm43241b4_ag_p2p.bin    fw_RK903_ag.bin             rk903.hcd             wifi_efuse_8189e.map
fw_bcm4330_apsta.bin        fw_RK903_ag_p2p.bin         RT2870APCard.dat      wifi_efuse_8723bs-vq0.map
fw_bcm4330.bin              fw_RK903b2_apsta.bin        RT2870AP.dat          wifi_efuse_8723cs.map
fw_bcm43341b0_ag_apsta.bin  fw_RK903b2.bin              RT2870STACard.dat     wifi_efuse_8723ds.map
fw_bcm43341b0_ag.bin        fw_RK903b2_p2p.bin          RT2870STA.dat
fw_bcm43341b0_ag_p2p.bin    fw_RK903.bin                rtl8723b_config

 

I have not yet understood how the kernel determines device to contact at which address and what firmware to load into it and i'm asking for advice on what I should learn to make it work.

 

01_dtbdump_rockchip,rk3328-evb-avb.dts

[helix]

This explains why firmware names does not match:

https://patchwork.kernel.org/project/linux-wireless/patch/20210804231308.576071-1-mike.rudenko@gmail.com/#24397725

 

This will make wlan0 available and the adapter will be able to see networks:

 

ln -s fw_bcm43436b0.bin brcmfmac43430b0-sdio.bin
ln -s nvram_ap6212.txt brcmfmac43430b0-sdio.txt

but there is still an error in the log:

 

[43290.813906] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430b0-sdio.rockchip,rk3318-box.bin failed with error -2
[43290.817278] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430b0-sdio.clm_blob failed with error -2
[43290.967040] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[43290.967061] brcmfmac: brcmf_c_process_txcap_blob: no txcap_blob available (err=-2)
[43290.967934] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/2 wl0: Jul 20 2018 13:31:01 version 9.88.4.16 (d853e07@shgit)  (r) FWID 01-f5575e5 es7.c5.n4.a3

 

[jock]

@helix hello, those "errors" are actually ok for brcmfmac driver. The clm blob is not always necessary and not available for some chips, the .bin file error is an attempt to look for a nvram file, but the driver will later look for other alternative nvram files and does not tell you that finally has found one.

[helix]

Hello, i'am struggling  to add bluetooth support. Perhaps this will need to be described in the device tree? Enabling rk805-1 (with conf3 overlay) has a positive effect, but this overlay unfortunately also disables wifi on sdio. It appears my board is  similar to rk3328-evb, which is correctly described in the mineline  kernel in compact way. Can you give me some advice on how to create the correct device tree for my board?