<div class="gmail_quote">On Mon, Aug 29, 2011 at 7:36 PM, Larry Finger <span dir="ltr"><<a href="mailto:Larry.Finger@lwfinger.net">Larry.Finger@lwfinger.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">The firmware has its own private memory and it shares some memory with the host CPU, but it does not have access to the SPROM.</div></blockquote><div><br></div><div>Good to know, thanks for the explanation!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Most of the code you need is already there. Use the SPROM fallback mechanism. You will need to call the ssb_arch_register_fallback_<u></u>sprom() routine to specify the routine that loads an alternative SPROM contents. This mechanism will work to compensate for your broken hardware.</div>
</blockquote><div><br></div><div>Yeah, something along those lines. Hopefully I can make it use sprom_extract to fill in the internal structures. It's gonna be quite tricky, voodoo black magic :)</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">And another side question: do you usually run the wireless-next kernel<br>
when doing driver development and recompile the whole thing every time<br>
you change something? Or rebuild just the targets/modules you're<br>
interested in, and the whole kernel when changing data structures used<br>
outside the module?<br>
</blockquote>
<br></div>
Fiddling around with modules to get them to load is too much work. I always use the wireless-testing kernel. Whenever changes are made. I use 'make -jX' to rebuild, where X is the number of cpu's + 1. It only does what is necessary. As I use openSUSE, this is followed by 'sudo make install_modules' and if bzImage was rebuilt, this is followed by 'sudo make install'. The latter command also updates the GRUB menu if the new kernel is not already in the list. If your distro is Debian-based, those simple commands may not work, but someone on the list will tell us how the do it. I don't think that long process of building a ".deb" file is needed.<font color="#888888"><br>
</font></blockquote></div><div><br></div><div>I found that it works to just do: make -C /lib/modules/`uname -r`/build M=`pwd` drivers/net/wireless/b43/b43.ko</div><div>but I do have to be careful and build the modules in order of their dependencies, otherwise the dependent module will have wrong versions of the symbols it needs and it won't work.</div>
<br clear="all"><div>On Tue, Aug 30, 2011 at 12:42 AM, Nicolas de Pesloüan <span dir="ltr"><<a href="mailto:nicolas.2p.debian@free.fr">nicolas.2p.debian@free.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
The clean way is make deb-pkg from the root of the kernel tree. It will build whatever need to be build (normal build), then build several .deb files you can install using dpkg -i. The normal build takes "normal build time", but building the .deb files takes several minutes. I don't consider this a problem, but...<br>
<br>The fastest way is to simply make, then copy the changed modules into /lib/modules/..., but from a debian point of view, it is very dirty.<br></blockquote><div><br></div><div>Yeah, I guess I prefer the very quick and dirty way. I added them to /lib/modules/.../updates/ and ran depmod. Good enough for me. As long as I don't dig too deep in b43 I probably won't need to do full kernel builds.</div>
<div><br></div><div>My biggest concern right now is that the modules I build cannot be rmmod-ed after being inserted. This happens with any custom built modules, including the dkms built ones (eg. nvidia).</div><div><br>
</div>
</div><div>What happens is that after inserting them they show with a huge ref number in lsmod, and there is a dependency on [permanent], which I understand appears when the module doesn't have a registered exit function -- which it should have, because CONFIG_MODULE_UNLOAD is y. Precompiled modules from .debs work fine.</div>
<div><br></div><div>It's the same problem as described here [1]. Any thoughts on this? Is it an ubuntu thing? I'm guessing that if I recompile the kernel problem might get fixed, but do the Ubuntu guys have some special patch that prevents unloading custom built modules?</div>
<div><br></div><div><div>$ lsmod | egrep 'ssb|b4|802'</div><div>ssb_sprom_override 12467 3343385879 [permanent]</div><div>b43 332274 842478592 [permanent]</div><div>mac80211 301993 937372790 b43,[permanent]</div>
<div>cfg80211 197510 1895908598 b43,mac80211,[permanent]</div><div>b44 35793 2191473215 [permanent]</div><div>ssb 51848 4218871345 b43,b44,[permanent]</div></div><div>
...</div><div><div>nvidia 11905275 0 [permanent]</div></div><div><br></div><div>rmmod and modprobe -r (even with --force) fail.</div><div><br></div><div>Just imagine having to do a restart after each test of the module...</div>
<div><br></div><div>Octavian</div><div><br></div><div>[1] <a href="http://kerneltrap.org/node/16886">http://kerneltrap.org/node/16886</a></div><div><br></div>