CSC support for discontinued rk3288 tv box?

[jock]

Hello,

 

before even thinking about arranging a CSC board bring up pull request to armbian, I would be pleased to know if it sensible to do that for a TV Box which is not sold anymore but still quite powerful because of its rk3288 SoC.

I made my own fork of armbian (see here). I tried to do things the most tidy way, following the best practices learnt from the documentation. The box has very good support now, but requires some initial setup to clean the eMMC.

Also I made some customizations to kernel configs which, I guess, should be moved away (mali driver compiled by default, devfreq support, brcmfmac driver for AP6330 wifi, maybe other things...)

 

Any opinion is welcome!

[Igor]

Why not? If you are willing to take care of its content of the armbian.com/download page. Prepare a PR to the build script, then I will sent you access credentials for the page management and you can do all things on your own - add images, select which images are available, ... (this is enough). Manual how to add a new device is written when you log-in to there.

Only images are rebuild manually - you have to notify me here and they will be added ASAP.

[chwe]

looking through the diff at least kernelconfig needs some polishing...

https://github.com/armbian/build/compare/master...paolosabatino:master

adding @TonyMac32 here.. Maybe it can be partly set as modules?

[jock]

My plan is to reset the kernelconfigs from common base and enable brcmfmac and IR (and ancillary config options) as modules when possible.

Devfreq support and other things were just test bits that can be left out.

 

If AP6330 firmware binaries could make into armbian firmware repository I can remove the copy work in rockchip.conf - I can arrange a pull request myself for that.

[Igor]

1 hour ago, jock said:

I can arrange a pull request myself for that.

Do it.
 

[TonyMac32]

Agreed.  I was working through the changes slowly (along with some other stuff).  If you can do as you said above, go for it. 

[jock]

I made some changes to my fork, in particular I reverted back kernel configs to current mainline and just enabled brcmfmac and remote GPIO IR drivers, both as modules.

 

I'm a bit puzzled by brcmfmac firmware handling, in particular the place the driver looks into for the firmware and nvram.

Currently I add extraargs=brcmfmac.alternative_fw_path=ap6330 in armbianEnv.txt and firmware files are put in /lib/firmware/ap6330/brcm path.

I'm still studying a way to be consistent with armbian-firmware ampak drivers approach, so any suggestion in this sense is appreciated.

[jock]

I delved into brcmfmac sources but eventually ended up with this: https://github.com/paolosabatino/firmware/tree/master/ap6330

 

I'm a bit concerned about the brcm symbolic link to self directory, but it is needed for brcmfmac driver compatibility

It does not mess up with the existing directory structure and, if needed, bcmdhd driver can use it with proper module parameters.

Still requires alternative_fw_path=ap6330, but I think it is could be reasonable to put it into a .conf file in /etc/modules.d

[Igor]

8 hours ago, jock said:

Still requires alternative_fw_path=ap6330, but I think it is could be reasonable to put it into a .conf file in /etc/modules.d

That's one option. Another is to adjust path in kernel sources, like this: https://github.com/armbian/build/blob/master/patch/kernel/rk3399-default/adjust_wireless_firmware_path.patch

[jock]

Well, another solution is to patch brcmfmac kernel module to add ap6330 chip and revision. It's a very small patch, just adding another item to the list:

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index a907d7b06..ec71996c7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -619,13 +619,17 @@ BRCMF_FW_DEF(4354, "brcmfmac4354-sdio");
 BRCMF_FW_DEF(4356, "brcmfmac4356-sdio");
 BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
 
+/* AMPAK */
+BRCMF_FW_DEF(AP6330, "brcmfmac-ap6330-sdio");
+
 static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
 	BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0xFFFFFFFF, 43143),
 	BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x0000001F, 43241B0),
 	BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x00000020, 43241B4),
 	BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0xFFFFFFC0, 43241B5),
 	BRCMF_FW_ENTRY(BRCM_CC_4329_CHIP_ID, 0xFFFFFFFF, 4329),
-	BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFFF, 4330),
+	BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0xFFFFFFEF, 4330),
+	BRCMF_FW_ENTRY(BRCM_CC_4330_CHIP_ID, 0x10, AP6330),
 	BRCMF_FW_ENTRY(BRCM_CC_4334_CHIP_ID, 0xFFFFFFFF, 4334),
 	BRCMF_FW_ENTRY(BRCM_CC_43340_CHIP_ID, 0xFFFFFFFF, 43340),
 	BRCMF_FW_ENTRY(BRCM_CC_43341_CHIP_ID, 0xFFFFFFFF, 43340),

This will let brcmfmac look for brcmfmac-ap6330-sdio.bin and brcmfmac-ap6330-sdio.txt firmware files, so there is no need for alternative paths. As long as brcmfmac only discriminates among Chip ID and Chip Revision, there is the drawback case where all those devices which have ID:0x4330 and REV:0x4 will be considered as AP6330.

After googling around for "BCM4330/4" (a string the driver produces in dmesg), all the sensible results always bind it to AP6330.

 

Although this looks tidier, my preference goes to the former solution because it seems "safer" (no id/revision clashing)