Search the Community

Hi everybody, I'm using the Armbian Buster mainline based kernel 5.10.y image on https://www.armbian.com/orange-pi-zero-plus-2-h3/ but I also tried the Focal one. I searched the forum deeply and I saw that someone in the past (forum post closed, otherwise I would have continued there) managed to have BT working by "faking" the /lib/firmware/brcm/brcmfmac43430-sdio.bin, that boot tries to load having error -2, copying the ap6212/fw_bcm43438a1.bin in its place. But it seems that it only works with legacy images, infact, with my mainline image I keep failing. Which legacy image should I look for? I was thinking that https://www.armbian.com/orange-pi-zero-plus-2-h3 already lists customized images, but I think I completely misunderstood. Thank you for any help

broadcom ap6212a like on most of the others. You can see it on the photo:

Hi all, Recently I tried to replace the wireless module on NanoPi Neo Air and met some very strange phenomenon. I just solder off the AP6212 module and then replace it with an AP6234 module. When I use the factory FriendlyCore system with brcmfmac43340-sdio.bin & brcmfmac43340-sdio.txt in /lib/firmware/brcm, everything works ok. But when I use armbian system, the wifi just not work. It always down after about 10 seconds when the bcm43340 firmware load. And I remember previously armbian system works fine for AP6212, but AP6212A not work and has the similar problem with AP6234. I just build the the armbian use the mainline 4.14.52 kernel too. I also try hardly to modify the the diffrences positions between the kernel from frendlyelec(https://github.com/friendlyarm/linux) and linux mainline v4.14.52 in armbian. But no matter how I tried to patch the kernel , the wireless module dosen't work ever. I also tried to replace zImage and modules in a armbian system with the the kernel build using https://github.com/friendlyarm/linux and everything works fine again.(dtb not replaced but also works fine) So I guess there must be some important differences between the kernel from frendlyelec and the mainline kernel from armbian. Could someone kind to infrom me the changes made by frendlyelec in the kernel? Thanks! The following are my log: [ 4.738978] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43340-sdio.bin for chip 0x00a94c(43340) rev 0x002 [ 4.985436] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Jun 17 2014 11:48:43 version 6.10.190.49 (r48582 [ 29.114569] brcmfmac: brcmf_sdio_kso_control: max tries: rd_val=0x0 err=0 [ 29.114727] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 29.114855] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 29.114978] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 29.115060] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation [ 29.115079] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [ 29.115089] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110) [ 30.789332] brcmfmac: brcmf_sdio_kso_control: max tries: rd_val=0x0 err=0 [ 30.789499] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 30.789617] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 44.695981] brcmfmac: brcmf_sdio_kso_control: max tries: rd_val=0x0 err=0 [ 44.696144] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 44.696262] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 44.697108] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 44.697201] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation [ 44.697211] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [ 44.697221] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110) [ 44.697436] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 44.697570] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 44.697725] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 56.718439] brcmfmac: brcmf_sdio_kso_control: max tries: rd_val=0x0 err=0 [ 56.718577] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 56.718685] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 56.718787] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 56.718857] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation [ 56.718867] brcmfmac: brcmf_proto_bcdc_query_dcmd: brcmf_proto_bcdc_msg failed w/status -110 [ 56.718875] brcmfmac: brcmf_cfg80211_get_channel: chanspec failed (-110) [ 56.718949] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 56.719052] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame [ 56.719153] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame

I changed the wifi_pwrseq outside, and the "dmesg | grep mmc" changed a bit: [ 0.000000] Kernel command line: root=UUID=aee206b3-d10b-44e7-af35-710d9422045d rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 loglevel=1 ubootpart=e3d022de-01 ubootsource=mmc usb-storage.quirks= sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 [ 2.766391] sunxi-mmc 1c0f000.mmc: Linked as a consumer to regulator.2 [ 2.767303] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 2.792927] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB [ 2.793785] sunxi-mmc 1c10000.mmc: Linked as a consumer to regulator.2 [ 2.796379] sunxi-mmc 1c11000.mmc: Linked as a consumer to regulator.2 [ 2.821823] sunxi-mmc 1c11000.mmc: initialized, max. request size: 16384 KB [ 2.829776] mmc0: host does not support reading read-only switch, assuming write-enable [ 2.831765] mmc0: Problem switching card into high-speed mode! [ 2.832007] mmc0: new SDHC card at address 0001 [ 2.834762] mmcblk0: mmc0:0001 00000 7.45 GiB [ 2.854128] mmcblk0: p1 [ 2.921841] mmc1: new DDR MMC card at address 0001 [ 2.924439] mmcblk1: mmc1:0001 8GND3R 7.28 GiB [ 2.926419] mmcblk1boot0: mmc1:0001 8GND3R partition 1 4.00 MiB [ 2.928280] mmcblk1boot1: mmc1:0001 8GND3R partition 2 4.00 MiB [ 2.930201] mmcblk1: p1 [ 4.325992] sunxi-mmc 1c10000.mmc: allocated mmc-pwrseq [ 4.349817] sunxi-mmc 1c10000.mmc: initialized, max. request size: 16384 KB [ 5.827870] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 8.151766] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 16.469981] EXT4-fs (mmcblk0p1): resizing filesystem from 276480 to 1911684 blocks [ 16.628910] EXT4-fs (mmcblk0p1): resized filesystem to 1911684 as shown above, "sunxi-mmc 1c10000.mmc" allocated mmc-pwrseq, and is initialized. but there's no any output if i ran the command "dmesg | grep -i sdio", still no "high speed sdio card" recognized. By the way, the boot information show those lines: U-Boot 2019.04-armbian (Apr 13 2019 - 14:24:38 +0800) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi PC Plus DRAM: 1 GiB MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000' mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 the mmc@1c11000, which connected a eMMC, is recognized as 1 while mmc@1c10000, which connected to a ap6212a chip, is recognized as 2

But, I did wire eMMC on MMC2 and ap6212a on MMC1, as the schematic shown below, and the eMMC works fine right now, but the ap6212a is not detected by armbian. 1.png 2.png

yes, i wired WL_REG_ON of ap6212a chip to PL7 of H3. I got the following content while running "dmesg | grep -i mmc" [ 0.000000] Kernel command line: root=UUID=f63dff6a-7de3-4946-b0b0-45be11430249 rootwait rootfstype=ext4 console=ttyS0,115200 console=tty1 hdmi.audio=EDID:0 disp.screen0_output_mode=1920x1080p60 panic=10 consoleblank=0 loglevel=1 ubootpart=7502a43b-01 ubootsource=mmc usb-storage.quirks= sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_fb_mem_reserve=16 cgroup_enable=memory swapaccount=1 [ 2.766162] sunxi-mmc 1c0f000.mmc: Linked as a consumer to regulator.2 [ 2.767046] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 2.792658] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB [ 2.793489] sunxi-mmc 1c10000.mmc: Linked as a consumer to regulator.2 [ 2.795769] sunxi-mmc 1c11000.mmc: Linked as a consumer to regulator.2 [ 2.821547] sunxi-mmc 1c11000.mmc: initialized, max. request size: 16384 KB [ 2.829297] mmc0: host does not support reading read-only switch, assuming write-enable [ 2.831268] mmc0: Problem switching card into high-speed mode! [ 2.831508] mmc0: new SDHC card at address 0001 [ 2.834257] mmcblk0: mmc0:0001 00000 7.45 GiB [ 2.837102] mmcblk0: p1 [ 2.945548] mmc1: new DDR MMC card at address 0001 [ 2.948113] mmcblk1: mmc1:0001 8GND3R 7.28 GiB [ 2.950114] mmcblk1boot0: mmc1:0001 8GND3R partition 1 4.00 MiB [ 2.951981] mmcblk1boot1: mmc1:0001 8GND3R partition 2 4.00 MiB [ 2.953990] mmcblk1: p1 [ 5.806869] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null) [ 8.214922] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro [ 16.329986] EXT4-fs (mmcblk0p1): resizing filesystem from 277504 to 1911684 blocks [ 16.478819] EXT4-fs (mmcblk0p1): resized filesystem to 1911684 and i got nothing while running "dmesg | grep -i sdio", the attachment dmesg.log contains the whole output. And finally, the schematic.png illustrates the connection between H3 and ap6212a. Thank you for your help! dmesg.log

Hi all! I make a board base on H3 CPU, I got a 8G EMMC under mmc2, and a ap6212a chip under mmc1. It boots successfully with the "armbian orange-pi-pc-plus", the emmc works fine while the wifi does not work, so, i changed the dts's mmc1 section based on the file 'sun8i-h3-orangepi-pc-plus.dts' in 'arch/arm/boot/dts/' directory, the mmc1 is changed to as follows: &mmc1 { vmmc-supply = <&reg_vcc3v3>; vqmmc-supply = <&reg_vcc3v3>; mmc-pwrseq = <&wifi_pwrseq>; bus-width = <4>; non-removable; status = "okay"; /* * Explicitly define the sdio device, so that we can add an ethernet * alias for it (which e.g. makes u-boot set a mac-address). */ sdio_wifi: sdio_wifi@1 { reg = <1>; compatible = "brcm,bcm4329-fmac"; interrupt-parent = <&pio>; interrupts = <6 10 IRQ_TYPE_LEVEL_HIGH>; /* PG10 / EINT10 */ interrupt-names = "host-wake"; }; wifi_pwrseq: wifi_pwrseq { compatible = "mmc-pwrseq-simple"; pinctrl-names = "default"; reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_HIGH>; post-power-on-delay-ms = <200>; }; }; I refered to the dts file of orangepi-zero-plus2 whose mmc1 got a ap6212 chip too. After i changed it, I compile the new image and burned to the sd card and boot, but the wifi does not work at all. while i got the brcmfmac.ko loaded: # modprobe -a brcmfmac it succeed with no output, but i got nothing when i ran the command "dmesg | grep brcmfmac" Did I write the dts file wrong? or something else? Any advice is much appreciated, Thank you!

Hi all, I would like to let you know that I successfully added to nexmon (framework to patch broadcom WiFi's driver+fw and add functionalities, like monitor mode) support for Orange Pi Zero 2+ (H3 and H5) running the latest Armbian (kernel next) Both boards have AP6212A as WiFi chipset, that is based on same Broadcom core of Raspberry Pi 3B/0W (bcm43430a1). What I did is basically porting brcmfmac's patches to 4.19 and compiling the Arm toolchain (for firmware cross-compiling) for aarch64. It ain't much but it's honest work I kept airodump running for a few hours and it seems stable. If you want to take a look/try it you can find the code here Greetings

Legacy kernel is on the way to be dropped, development was abandoned long time ago. Old builds are also not supported by definition. I would need to do a research to be able to help you ... which is far away from free technical support. You are on your own here - use search if you can find something in the forum. Bluetooth is in general not very well supported: https://forum.armbian.com/topic/8544-bluetooth-initialization-timed-out-on-ap6212a-orange-pi-zero-plus2-h3/?do=findComment&amp;comment=64632 but for mainline kernel it is also in our interest to sort it out. But there are not enough people for problems that pops up ...

I can only offer to test setup instructions on the boards I have, if anyone has recommendations. I'd be glad to post the results here. If Bluetooth is working on some boards with the same chip (AP6212A) then it should actually work on the Zero Plus2 H3 too.

Hello... I've got an Orange Pi Zero Plus 2 H3 with Armbian Stretch. Kernel: 4.14.70-sunxi armbianEnv.txt: I did: cp -a /lib/firmware/ap6212/fw_bcm43438a1.bin /lib/firmware/brcm/brcmfmac43430-sdio.bin dmesg when searching for "brcm" gives me: [ 8.123186] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43430-sdio.bin for chip 0x00a9a6(43430) rev 0x000001 [ 8.256708] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 8 2016 15:31:47 version 7.46.57.4.ap.r4 (A1 Station/P2P) FWID 01-3621395e es6.c5.n4.a3 In /etc/default/ap6212 I have: PORT=ttyS1 But the script /etc/init.d/ap6212-bluetooth is failing... with the error "Initialization timed out." Is there any "how-to" for the Orange Pi Zero Plus 2 to get Bluetooth working?

Are you 100% sure that OPiPrime has AP6212(A)? In my case I believe it has Realtek 8723 ``` $ lsmod | grep 80211 cfg80211 294912 1 r8723bs rfkill 28672 3 cfg80211 ``` As for OPiWin, my has AP6212A - maybe my experience might be useful to someone here. Mainline. Could not make it work with mainline 5.32 and upgraded 5.41 (both same kernel 4.11.8) It is using brcmfmac module, that I tried with various firmware (/lib/firmware/brcm/brcmfmac43430-sdio.bin and -=-.txt files). All have the same result - system reboot after first wifi frames go - e.g. client get's dhcp address and the system reboots. The only thing in dmesg: ``` [ 9.458442] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 8 2016 15:31:47 version 7.46.57.4.ap.r4 (A1 Station/P2P) FWID 01-3621395e es6.c5.n4.a3 [ 9.741314] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30) [ 9.924496] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30) ``` Tracking similar (freez instead of reboot) issue: https://github.com/raspberrypi/linux/issues/1342 Strange, but have the feeling that it did work with mainline before on 5.32 (card was corrupted and had no backup) but might confuse with prime. Legacy. Could make it work in legacy kernel. First the hostapd was starting fine, but was no ESSID in iwconfig and got some error in dmesg ``` CFG80211-ERROR) check_dev_role_integrity : device role select failed ``` Fixed it with module parameter. (by Igor advice from here http://forum.banana-pi.org/t/how-to-setup-a-wifi-ap/2437) # echo 'options bcmdhd op_mode=2' > /etc/modprobe.d/bcmdhd.conf Iwconfig should show the ESSID name. ``` # iwconfig ... wlan0 IEEE 802.11 ESSID:"ARMBIAN" Mode:Master Frequency:2.432 GHz Access Point: 02:1A:11:F8:B9:12 Bit Rate=96 Mb/s Tx-Power:32 dBm Retry min limit:10 RTS thr:off Fragment thr:off Encryption key:off Power Managementmode:All packets received ... ``` Works fine despite some errors in dmesg ``` CFG80211-ERROR) __wl_cfg80211_scan : Invalid Scan Command at SoftAP mode CFG80211-ERROR) wl_cfg80211_scan : scan error (-22) ``` Will appreciate any ideas with mainline and will try to provide any logs if required.

Hi, What i did in my patch was to port the stuff shown by following video in a more armbian compliant way. http://www.youtube.com/watch?v=kH-1PC7chIU I've live applied changes on 10/01/2018 armbian and tested on my orangepi winplus (barcode dated 20170926) win ap6212A Please note that hciattach trick (a6212-patch) won't work for me as well, but worked brcm40183-patch. firstrun has been modded to enable the new helper, so a new install should get bluetooth by default. @Igor Just installed the new image - can't find changes to brcm40183-patch bring by https://github.com/armbian/build/commit/238072cb55009480c5170a9952d5ee1e83a74473 probably that is the issue...

Not sure if this is relevant to the board in question but I was recently playing with Orange Pi Zero Plus 2. I could get BT running by manually setting BT_RST_N pin HIGH and enabling 32KHz clock from RTC module. Though I never had to touch 'wake' signals, they may just happened to be in correct state for some reason. AP6212 datasheet is not very verbose regarding the purpose of these signals. For now I just have a dumb script to bring BT up and need to figure out a way to properly integrate these changes into the device tree (probably in a form of rfkill-section but I don't have experience with DTS). #!/bin/sh devmem2 0x1f00060 b 1 echo 10 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio10/direction echo 0 > /sys/class/gpio/gpio10/value echo 1 > /sys/class/gpio/gpio10/value sleep 0.1 /usr/bin/hciattach /dev/ttyS1 bcm43xx 1500000 Also my board came with AP6212A so I'm using bcm43430a1.hcd(md5:b95ee9032a723daa25ab9608a515e984) firmware.

Just look at Orange Pi Zero Plus 2: same PCB, one batch with H3 in the reel, the other batch H5. Due to software incompatibility use cases and usability of the two variants differ a lot (and I personally have not the slightest idea why 'we' started here to support the H5 variant at all since IMO no reasonable use case exists -- H3 variant with legacy kernel + Mali and video acceleration is something different) So here we're talking about the same: identical PCB, identical design flaw (SinoVoip 'forgot' voltage regulation) but different SoCs, different DRAM and AP6212 on early Bananas vs. AP6212A here, right?

Maybe not for your use cases but for others. Not everyone has the same needs... I'm well aware of this and as already said IF SINOVOIP WOULD START TO PROVIDE CORRECT HARDWARE DESCRIPTIONS BPi M2 Zero would've been long added as .csc (community supported board variant) so it's at least ensured that hardware settings match so other projects relying on Armbian's build system or using same legacy kernel can easily add support for BPi M2 Zero to their projects (those others are for example H3Droid, RetrOrangePi, Lakka and @jernej's community OpenELEC distro). It would have already happened if the company in question would start to provide correct and not all the time missing or even wrong information. That was talking about most basic support, just describing the hardware so it's useable with legacy kernel (the 3.4 that is unsupported since more than half a year since EOL in April 2017) in a good way. Impossible with SinoVoip since they do not provide the needed information (voltage regulation, if this thing can't switch to 1.1V it will permanently overheat). As soon as this is fixed it's throwing in 2 files into the build system and perfectly working OS images can fall out of it, then @lvmc would already be happy since he doesn't need community, friendlyness and the other stuff but just working OS images for his commercial use cases. Fair enough but not related to 'Armbian support', he and we are missing vendor support. 'Full Armbian' support would mean we actively try to support this device. Armbian wants to move away from legacy kernel so all you have with mainline kernel is then a H2+ device lacking 3 USB ports with a problematic Wi-Fi implementation (AP6212A though referenced as AP6212 by the vendor -- do you start to understand why dealing with them sucks?), only one USB OTG port, no working camera and tinkerers encouraged to solder a MagJack wrongly then then flooding our forum about Ethernet problems. Adding to this: false/misleading advertising. Buyers believe M2 Zero would be compatible to RPi cameras (not true at all) and to RPi software (not true at all). And these people will later end up here in the forum (since they'll realize pretty fast that SinoVoip doesn't support SinoVoip hardware) and complain about incompatibilities. That's the other reason official Armbian support is highly questionable. And may I remind you that all the work done on Armbian is done by volunteers even if the liar who called me already an asshole constantly spreads I would be paid by Xunlong. Seriously: why dealing with this stuff?

Armbian is supporting AP6212A WiFi only (the Non-A version something is working by manually copying firmware, but not on all boards). No body did some work for making BlueTooth working, neither Armbian Devs or Mainline folks, it requires at least some DT additions.

Except of the two R boards all Bananas use the same AP6212/AP6212A which can be considered ultra low end especially for an AP. I second Igor's suggestion but recommend to read it closely and again: a board that will run mainline kernel or at least 4.9LTS with the 8812AU driver included is important (just noting since it seems your last buying decision was a bit precipitously -- if you would've done some research before you would've been warned wrt horrible vendor software support for some of the SBC brands out there, eg. Orange and Banana Pis most probably being the worst)

AP6212 or AP6212A so you need to instruct the driver to switch between normal and AP mode as Igor explained. You should be able to use any of the countless scripts around to deal with these Ampak modules (eg from FriendlyELEC or armbian-config)

It's probably related to AP6212A problem .

https://forum.armbian.com/index.php?/search/&q=AP6212a There were some discussions and AFAIK I made some dirty hack to fix this firmware mess. It looks like it's not working ok.

Well, again talking to myself I put the exchanged firmware files online: http://kaiser-edv.de/tmp/NumpU4/brcmfmac43430-sdio-broadpwn-fix.tar Is anyone here with the following combination able to test whether exchanging this firmware file works or not? Board with AP6212 (not AP6212A as far as I understood) Mainline kernel and everything configured correctly to activate Wi-Fi) test with /lib/firmware/brcm/brcmfmac43430-sdio.bin as it's part of armbian-firmware package and from the link above later (collecting 'dmesg | grep brcm' of course) No idea whether /lib/firmware/brcm/brcmfmac43430-sdio.txt must also be replaced...

On Black Hat 2017 security researcher Nitay Artenstein showed a vulnerability affecting millions of smartphones he called BroadPwn. The bug/vulnerability sits inside the firmware blobs but I didn't pay that much attention since I thought it would be related to recent smartphones and at least the one I use still receives full security fix support now in the 5th year. But when I heard that latest Raspbian release contains a fix for BroadPwn (RPi 3 and Zero W use BCM43438 to provide wireless capabilities) I asked myself immediately a question: http://www.cnx-software.com/2017/08/17/raspbian-for-raspberry-pi-boards-gets-upgraded-to-debian-stretch/#comment-545270 I booted my RPi 3, added the stretch repo, did an apt-update and checked (after updating the kernel): root@raspberrypi:~# apt list --upgradable Listing... Done device-tree-compiler/testing 1.4.4-1 armhf [upgradable from: 1.4.1-1+rpi1] dnsmasq/testing 2.76-5+rpi2 all [upgradable from: 2.76-5+rpi1] dnsmasq-base/testing 2.76-5+rpi2 armhf [upgradable from: 2.76-5+rpi1] libcairo2/testing 1.14.8-1+rpi1 armhf [upgradable from: 1.14.0-2.1+deb8u2+rpi1] libpam-modules/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2+rpi3] libpam-modules-bin/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2+rpi3] libpam-runtime/testing 1.1.8-3.6+rpi1 all [upgradable from: 1.1.8-3.1+deb8u2+rpi3] libpam0g/testing 1.1.8-3.6+rpi1 armhf [upgradable from: 1.1.8-3.1+deb8u2+rpi3] libraspberrypi-bin/testing 1.20170811-1 armhf [upgradable from: 1.20170703-1] libraspberrypi0/testing 1.20170811-1 armhf [upgradable from: 1.20170703-1] openmediavault/erasmus 3.0.87 all [upgradable from: 3.0.85] raspberrypi-bootloader/testing 1.20170811-1 armhf [upgradable from: 1.20170703-1] If I understand correctly a BroadPwn fix has to be applied to firmware blobs. Since the above is an Armbian userland combined with RPi kernel I checked Raspbian's firmware package: https://pastebin.com/bMWqwxcy So if the most common Wi-Fi chips on supported boards are affected (since AP6212 is just a BCM43438 A0 while AP6212A is an A1 BCM43438) we might want to provide an updated armbian-firmware package asapissimo, true?

Obviously, I've missed the clearly visible 8198FTV, I was searching for the AP6212A

Thanks Zaror. The obvious question: Do you know of any plans to implement BT on the AP6212A in the near future? I'll carry on trying to work it out. It seems that some have BT running on the Nano Pi with AP6212/A chip?