I’m building a custom kernel for my newly purchased Jetson tk1 and I noticed that support for Broadcom dual WiFi/BT bcm4352 was added to the tegra12_android_defconfig. Since I am building for aosp android does this mean this bcm chip is supported?
The module design is based on the bcm4352 and bcm20702 solution.
I haven’t played with this, but that would be the driver side. There may be other requirements for firmware or user space configuration, but this looks like at least the starting point for making that card work.
Well this is good news for sure! From all the forums and google searching the bcm4352 is a proprietary kernel driver. I’ve got the bcm4352 coming in the mail tomorrow so ill be sure to post some dmesg logs after i test a kernel with support.
I do not believe R23.1 will work on a TK1. No doubt it could be adapted, but I’m going to guess the effort would be extreme. If the case is that a kernel driver/module is what is needed, then back-porting this individual module from R23.1 to R21.4 would likely be a signifcant but more reasonable effort. So a big question is what would you want to bring to TK1 which is in TX1? This would give a more precise idea of what you would need to do (and how difficult it is).
My ultimate goal would be to back-port the bcm4352 WiFi module support to the tk1 kernel branch. What would be the first steps? I’m comfortable editing code and applying patches so any help on this is greatly appreciated.
In general, there would be an architecture independent directory in the kernel source for that driver (somewhere under “drivers/”). Some Kconfig files would make this available for config setup. One would copy that driver directory branch into the older kernel source, and set up Kconfig.
Firmware would be an additional step for wireless, which has an architecture dependent directory somewhere in the “arch/” subdirectory tree, and would need to be copied into “arm” subdirectory from the “arm64” directory.
There is no telling what would be required to support making the driver compile, as changes from this older kernel to the newer one may make some features used by the driver non-existent when put in the older environment. Basically, the newer infrastructure the module depends upon may require modifying the driver to run on older infrastructure. This could include differences in compilers, and not just code in the driver (especially where arm versus aarch64 is concerned).
The firmware would have to be adjusted for whatever changes are needed in the driver.
To make things more difficult, sometimes there is more than one driver for a device. For example, some wireless devices also have bluetooth…the bluetooth would have its own driver and firmware. If I were you I’d start by learning to back port a simple driver from the same 32-bit ARMv7 driver as close to the near future of the 3.10.40 kernel as possible. Then I would try to just get the driver you are actually working on to compile…but not necessarily be able to load or run. To get further you’d then have to port the firmware. Once the firmware is done, you could work on getting the module to load and then to run.
Tried my first compile just copying the bcmdhd directory to the 3.10.40 kernel source and here is my first error:
CC [M] drivers/net/wireless/bcmdhd/wl_cfgp2p.o
CC [M] drivers/net/wireless/bcmdhd/wl_cfg_btcoex.o
CC [M] drivers/net/wireless/bcmdhd/wldev_common.o
CC [M] drivers/net/wireless/bcmdhd/wl_linux_mon.o
CC [M] drivers/net/wireless/bcmdhd/dhd_linux_platdev.o
CC [M] drivers/net/wireless/bcmdhd/hnd_pktq.o
CC [M] drivers/net/wireless/bcmdhd/hnd_pktpool.o
CC [M] drivers/net/wireless/bcmdhd/dhd_pcie.o
CC [M] drivers/net/wireless/bcmdhd/dhd_pcie_linux.o
drivers/net/wireless/bcmdhd/dhd_pcie_linux.c: In function 'dhdpcie_suspend_dev':
drivers/net/wireless/bcmdhd/dhd_pcie_linux.c:222:2: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
dhdpcie_info_t *pch = pci_get_drvdata(dev);
^
drivers/net/wireless/bcmdhd/dhd_pcie_linux.c: In function 'dhdpcie_pci_probe':
drivers/net/wireless/bcmdhd/dhd_pcie_linux.c:369:2: error: implicit declaration of function 'dma_set_mask_and_coherent' [-Werror=implicit-function-declaration]
if (!dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64))) {
^
cc1: some warnings being treated as errors
make[4]: *** [drivers/net/wireless/bcmdhd/dhd_pcie_linux.o] Error 1
The dma_set_mask_and_coherent() would be either a feature which exists and just isn’t enabled, or the next thing to copy from the newer kernel and port to the current kernel. This could possibly have had a variation and instead of copy from one kernel to the other it may be that you want to adapt your driver to use something already existing.
The warning won’t hurt, but if you want to get rid of that try:
Thanks linuxdev! I appreciate all the input on this! Ill give that a try right now. Also when it comes to firmware files and nvram.txt would it be possible to adapt the 4354 firmware from the l4t x1 driver package (nvidia_drivers) files:
So far as firmware goes, how firmware is divided among the kernel and device would probably help for understanding how to port it. Devices requiring extra firmware tend to download some of that firmware into the device at some binary offset in the device, and then the driver depends on the interface to that device through its own naming…a named value at the kernel side, a binary value at the device side.
An example would be a variable for a voltage setting changing the actual device behavior to increase or decrease power output on the RF end. The device may not care what you name that voltage in the kernel, but the firmware files which the kernel reads will assign the name to value if the driver needs to know about that value. If the name is used by the driver and corresponds to something which is architecture independent, it’ll “just work”. If instead the variable were say 32-bit type in older kernels and 64-bit type in the kernel it is being ported from, then you have a problem and would need to adjust for the 64/32-bit change (suppose the kernel being ported to could not handle that variable as 64-bit, you’d have to make it 32-bit…if 32-bit is enough to contain any value the variable holds, then you don’t have a problem…if the variable needs 64-bit, then you need to redesign a large part of the driver).
So one task would be to track any names in the firmware and see where they are used in the driver (you could just try it first and see if it works, and then if not go through this step). Then see what depends on that naming.