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 <[email protected]> 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 > [email protected] > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
