Re: [OpenWrt-Devel] Broadcom ARM Status
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 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 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
Re: [OpenWrt-Devel] Broadcom ARM Status
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 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
Re: [OpenWrt-Devel] Broadcom ARM Status
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
Re: [OpenWrt-Devel] Broadcom ARM Status
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. 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/downloadit 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. 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. 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? On Sat, Nov 2, 2013 at 4:39 PM, Felix Fietkau wrote: > On 2013-11-02 08:59, James Hilliard wrote: > > Well, maybe they didn't create the shared code because of the GPL but > > they can't link a binary directly to a GPL component, only a LGPL > > component I think or something like that. I've object dumped and ran > > decompilers on the broadcom-wl object files and I don't see anything > > statically linked or any indication of anything that would be specific > > to a kernel version > You won't see the parts that matter in whatever tools you used to pick > apart the binary. When compiling, the code includes header files from > the kernel, which contain data structures, some of the most important > ones being sk_buff and net_device. > Stuff like that doesn't show up as symbols, and you won't find it by > name in a disassembler. > If you take a look at the data structures in the header files in a > kernel tree, you might notice, that they even change depending on the > kernel configuration. > This makes attempts to reuse the prebuilt .ko file futile. > > > I see plenty of needed symbols though, but those > > all appear to be available to build into the kernel. > > > I don't see a > > reason why wl_linux.c can't be compiled from source > > > http://sourceforge.net/projects/routertesting/files/ea6900%20patches/wl_linux.c/download > > , its not like its closed source as far as I can tell, is that the only > > thing preventing us from using these tarball drivers? > Did you actually look at that file? This is not even driver code. > > > Relocatable means > > its not tied to any specific memory addresses right and that any memory > > address are referenced only internally? All the decompilers I used > > indicated the drivers were relocatable ELF's and I didn't see any > > external memory addresses referenced from any functions. > Memory addresses aren't the only thing that matter, there are other ABI > issues, e.g. the one I described above. > > - 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
Re: [OpenWrt-Devel] Broadcom ARM Status
On 2013-11-02 08:59, James Hilliard wrote: > Well, maybe they didn't create the shared code because of the GPL but > they can't link a binary directly to a GPL component, only a LGPL > component I think or something like that. I've object dumped and ran > decompilers on the broadcom-wl object files and I don't see anything > statically linked or any indication of anything that would be specific > to a kernel version You won't see the parts that matter in whatever tools you used to pick apart the binary. When compiling, the code includes header files from the kernel, which contain data structures, some of the most important ones being sk_buff and net_device. Stuff like that doesn't show up as symbols, and you won't find it by name in a disassembler. If you take a look at the data structures in the header files in a kernel tree, you might notice, that they even change depending on the kernel configuration. This makes attempts to reuse the prebuilt .ko file futile. > I see plenty of needed symbols though, but those > all appear to be available to build into the kernel. > I don't see a > reason why wl_linux.c can't be compiled from source > http://sourceforge.net/projects/routertesting/files/ea6900%20patches/wl_linux.c/download > , its not like its closed source as far as I can tell, is that the only > thing preventing us from using these tarball drivers? Did you actually look at that file? This is not even driver code. > Relocatable means > its not tied to any specific memory addresses right and that any memory > address are referenced only internally? All the decompilers I used > indicated the drivers were relocatable ELF's and I didn't see any > external memory addresses referenced from any functions. Memory addresses aren't the only thing that matter, there are other ABI issues, e.g. the one I described above. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broadcom ARM Status
Well, maybe they didn't create the shared code because of the GPL but they can't link a binary directly to a GPL component, only a LGPL component I think or something like that. I've object dumped and ran decompilers on the broadcom-wl object files and I don't see anything statically linked or any indication of anything that would be specific to a kernel version, I see plenty of needed symbols though, but those all appear to be available to build into the kernel. I don't see a reason why wl_linux.c can't be compiled from source http://sourceforge.net/projects/routertesting/files/ea6900%20patches/wl_linux.c/download, its not like its closed source as far as I can tell, is that the only thing preventing us from using these tarball drivers? Relocatable means its not tied to any specific memory addresses right and that any memory address are referenced only internally? All the decompilers I used indicated the drivers were relocatable ELF's and I didn't see any external memory addresses referenced from any functions. On Sat, Nov 2, 2013 at 2:05 AM, Felix Fietkau wrote: > On 2013-11-02 00:30, James Hilliard wrote: > > 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. > I think you're misunderstanding the purpose of the shared code. It was > not created because of GPL issues at all. It's an OS abstraction layer > that they use to port their drivers to different operating systems. The > portability only works on a *source* level. Compiled binaries are still > highly kernel version specific (at least in the wl_linux.o parts). > > > 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. > It wasn't 'turned into an abstraction layer'. The code was simply moved > someplace else. This was done because the loads of crappy code were only > needed for broadcom-wl and nothing else. > The part that allows broadcom-wl to be version independent is that all > kernel ABI dependent files are provided with source code. > > > 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. > That only solves the easiest problem of all (unresolved symbols). You > still need wl_linux.c to be compiled from source. > > > 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. > I think you're confused about what the word 'relocatable' means. > > - 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
Re: [OpenWrt-Devel] Broadcom ARM Status
On 2013-11-02 00:30, James Hilliard wrote: > 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. I think you're misunderstanding the purpose of the shared code. It was not created because of GPL issues at all. It's an OS abstraction layer that they use to port their drivers to different operating systems. The portability only works on a *source* level. Compiled binaries are still highly kernel version specific (at least in the wl_linux.o parts). > 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. It wasn't 'turned into an abstraction layer'. The code was simply moved someplace else. This was done because the loads of crappy code were only needed for broadcom-wl and nothing else. The part that allows broadcom-wl to be version independent is that all kernel ABI dependent files are provided with source code. > 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. That only solves the easiest problem of all (unresolved symbols). You still need wl_linux.c to be compiled from source. > 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. I think you're confused about what the word 'relocatable' means. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Broadcom ARM Status
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 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 > 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
Re: [OpenWrt-Devel] Broadcom ARM Status
>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 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
Re: [OpenWrt-Devel] Broadcom ARM Status
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] Broadcom ARM Status
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. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
