Something interesting I found, seems broadcom is building the driver in this strange way precisely because of the GPL:
/* Where to get the declarations for mem, str, printf, bcopy's? Two basic approaches. * * First, use the Linux header files and the C standard library replacmenent versions * built-in to the kernel. Use this approach when compiling non hybrid code or compling * the OS port files. The second approach is to use our own defines/prototypes and * functions we have provided in the Linux OSL, i.e. linux_osl.c. Use this approach when * compiling the files that make up the hybrid binary. We are ensuring we * don't directly link to the kernel replacement routines from the hybrid binary. * * NOTE: The issue we are trying to avoid is any questioning of whether the * hybrid binary is derived from Linux. The wireless common code (wlc) is designed * to be OS independent through the use of the OSL API and thus the hybrid binary doesn't * derive from the Linux kernel at all. But since we defined our OSL API to include * a small collection of standard C library routines and these routines are provided in * the kernel we want to avoid even the appearance of deriving at all even though clearly * usage of a C standard library API doesn't represent a derivation from Linux. Lastly * note at the time of this checkin 4 references to memcpy/memset could not be eliminated * from the binary because they are created internally by GCC as part of things like * structure assignment. I don't think the compiler should be doing this but there is * no options to disable it on Intel architectures (there is for MIPS so somebody must * agree with me). I may be able to even remove these references eventually with * a GNU binutil such as objcopy via a symbol rename (i.e. memcpy to osl_memcpy). */ On Sun, Nov 3, 2013 at 2:25 AM, James Hilliard <james.hillia...@gmail.com>wrote: > That patch included a bit more than just the modifications needed to > support the wl driver, that patch should be for the new broadcom ARM > architecture. I think most of the dependencies for the wl driver and the > ARM wl driver should be in here > http://sourceforge.net/projects/routertesting/files/ea6900%20patches/src.tar.bz2/downloadwhich > is a bit cleaner than the patch. > The .ko files are sometimes precompiled along with the .o files in GPL > tarballs and sometimes there are only .o files, usually there are just the > .o files though. It varies slightly between manufacturers. The ones in that > tarball are pulled from the ea6900 source. Maybe ABI compatibility layer > wasn't exactly the best way the phrase that. What method would you use to > go about getting the driver working? I don't see a reason the ABI can't be > fixed, all that information is in the broadcom components that are open > source, at least as far as I can tell. I'm trying to figure out where start > on all of this. Most of this seems to be just merging existing code and > configuration changes. How would you go about getting a working broadcom > driver on new devices? > > > On Sun, Nov 3, 2013 at 1:55 AM, Felix Fietkau <n...@openwrt.org> wrote: > >> On 2013-11-02 23:47, James Hilliard wrote: >> > I'm not actually trying to use a fully compiled .ko file, the file is a >> > .o file such as wl_apsta.o(tools indicate it is a relocatable ELF for >> > ARM) that gets compiled into a .ko when you build GPL tarballs. Seems to >> > be the same as the wl_prebuilt.o files we have for the most part in the >> > current driver implementation. >> There's not that much difference between linking all those .o files into >> one .ko and just using the prebuilt .ko. >> >> I realize that the driver depends on >> > these data structures in the kernel, but we know exactly what these >> > structures look like from the hnd kernel patch right? In the patch here >> > >> https://sourceforge.net/projects/routertesting/files/ea6900%20patches/linux-2.6.36.4-f70_000_BSP.patch/download >> > it seems that there are changes to the sk_buff and net_device in the >> > kernel to match the driver. I see that there are ABI differences but I >> > don't see why we can't just change the kernel's ABI to be compatible, we >> > have the patch-set for that. The way i'm looking at this is since we >> > can't recompile the driver to fit the kernel we recompile the kernel to >> > fit the driver. >> Good luck... Given how much you're already struggling with understanding >> the really simple parts, I'm not sure how you will be able to solve the >> more complex problems related to the ABI/API issues. >> >> Either way, the result of such work will most likely not be acceptable >> for merging into OpenWrt, since it'll break with every single kernel >> upgrade and will create nasty kernel maintenance issues. >> I know that, because I've done that sort of thing before... >> >> > One thing odd I noticed is that a mips .ko driver has >> > the function names removed when compiled from the .o driver, while it >> > appears the ARM one does not, both the ARM .ko and .o are very similar >> > with symbol names intact. Both start out as .o files with all the >> > function names. >> You forgot to mention, what .ko files you looked at and where you got >> them from. >> >> > From what I can tell wl_glue in the current driver is >> > the ABI compatability layer used currently rather than making the kernel >> > directly compatible, is that correct? >> "ABI compatability layer"? That doesn't make much sense. >> >> - Felix >> _______________________________________________ >> 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
