It's a very confusing way of building a package, but the reason seems to come down to how the GPL works. The GPL prohibits statically linking any closed source packages into the kernel, that however is how drivers are often built. Broadcom came up with another way that gets around the problem by creating the hnd shared libraries that allow them to customize the way the driver interacts with the kernel while at this same time allowing them to legally build a closed source relocatable driver that links the open source hnd components. The current way openwrt builds the broadcom-wl seems to quite a bit different than normal, it appears that rather than building hnd components into the kernel hnd was turned into an abstraction layer of some sort that provides an interface layer for the driver without making major kernel changes. The issue with this seems to be that maintaining the driver with this method is very difficult since broadcom does not release drivers that support this method of integration. IMO the easiest and most maintainable way of using the broadcom-wl driver is to patch the kernel at compliation with the hnd shared libraries if the wl driver is selected for installation. The patches I have are the patches broadcom uses to add hnd to a stock kernel as well as other platform modifications. I could be wrong about some of this but there should be a way to get this driver working since it is relocatable.
On Fri, Nov 1, 2013 at 6:08 PM, Chirag Chhatriwala <cchha...@gmail.com>wrote: > Without looking at any patches at all, I can safely say that this (your > email) is the best explanation I have found so far with respect to progress > with the Broadcom ARM based SoC's. Its very well articulated. Something > that I could actually follow in these dev discussions. > Thank you for the write up. > I'm sorry I don't have any technical to contribute here, I'm fairly noob > when it comes to patching drivers/kernels. > > Chirag > > > On Fri, Nov 1, 2013 at 3:21 PM, James Hilliard > <james.hillia...@gmail.com>wrote: > >> From what I can tell the way the openwrt broadcom-wl is compiled makes it >> extremely difficult to patch in any upstream changes from broadcom. The >> broadcom-wl binary module distributed with stock routers does not appear to >> be kernel version specific since it is not statically linked, however it is >> kernel configuration specific, and by that I mean it requires a few >> non-default packages be built directly into the kernel, mainly it seems to >> require the hnd shared dependencies be included. Adding these dependencies >> appears to be the method one would use to make broadcom-wl maintainable in >> newer ARM and even MIPS devices. Basically hnd needs to be patched into any >> kernel that we want to use on a broadcom device with broadcom drivers. We >> can't simply patch the driver to work with the kernel, instead we have to >> patch the kernel to work with the driver. This way we can use relocatable >> binary drivers pulled directly from GPl tarballs rather than having to rely >> on customized compiles, and both mips and arm binary drivers are >> relocatable. Luckily I have the patches broadcom uses to add the >> dependencies on the newer 2.6.36 kernel for ARM which should be easy enough >> to port to openwrt in addition to necessary packages specific patches. >> Basically the method currently used to handle the mips broadcom-wl driver >> should be scrapped since it is nearly impossible to keep up to date and >> maintain as it attempts to provide an interface layer rather than simply >> building in the kernel dependencies directly. I've uploaded the kernel >> patches as well as the current driver set for the ea6900 here >> https://sourceforge.net/projects/routertesting/files/ea6900%20patches/ . >> Ethernet drivers seems to be fully open source although the wireless driver >> is a relocatable ELF but it should be compatible assuming we patch in the >> needed kernel changes. The main patch that adds the neccesary hnd >> dependencies to the kernel is the linux-2.6.36.4-f70_000_BSP.patch , I'm >> fairly sure it should just be patched in directly of course dealing with >> any kernel version change breaks. Mostly it is adding files to the kernel >> build rather than actually changing files that already exist so breaks due >> to kernel version changes should be minimal. The rest of the patches are >> package specific patches for the broadcom ARM platform and ea6900. The src >> tarball in that folder includes the wireless and ethernet drivers >> themselves as well as some other dependencies. Ive also uploaded the >> toolchain buildroot in the same directory which includes a number of >> platform specific patches. Let me know if there are any patches you think >> might be missing and I can also try get the patches for other Broadcom ARM >> devices and boards. Some of these patches may be unneeded as they are used >> for the stock configuration. The patch set is fairly extensive as it >> encompasses multiple packages as well as significant kernel >> changes/additions. >> >> James >> >> >> On Fri, Nov 1, 2013 at 10:26 AM, Hauke Mehrtens <ha...@hauke-m.de> wrote: >> >>> On 11/01/2013 01:22 PM, James Hilliard wrote: >>> > I noticed that there is a broadcom ARM build option but it only seems >>> to >>> > build for the r6250 and I'm not sure if its actually making installable >>> > builds. I have a number of very large patches that are part of the >>> build >>> > system for these routers. Has anyone been working on these recently? >>> The >>> > broadcom-wl arm driver for this appears to be relocatable to any kernel >>> > provided the kernel is patched properly with the open source hnd >>> > dependencies. >>> >>> Hi James, >>> >>> The Broadcom ARM target is for the Northstar BCM470{7,8,9} and BCM5310X >>> Chips. I am working on that when I find some time. It currently >>> generates only images for the Netgear R6250 because this is the only >>> device with this SoC I have, the code should also work on other devices >>> with this SoC. >>> >>> Images from this target are only booting, currently Ethernet, flash, >>> wireless, pci and so on are not working. >>> >>> The broadcom-wl in OpenWrt does not have a ARM binary blob just Mips >>> blobs and it does not support the BCM4331 or any ieee80211ac chip from >>> Broadcom, this has to be replaced with a more recent one, but >>> broadcom-wl is relocatable on MIPS, we use it with various different >>> kernel versions and configurations. >>> >>> What patches do you have for this SoC? >>> >>> Hauke >>> >> >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> >> >
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
