Hi,

As you may be aware, we're reverse engineering the Broadcom driver in order to use the chipset. Please see http://bcm-specs.sipsolutions.net/ for more information.

To help complete(*) this, I'm currently looking for help and testers on the wrt platform. Essentially, I'd like to obtain logs of accesses that the driver does to the memory mapped space of the chip. The idea is simple:
1) hack ioremap to return some unmapped address for the wl driver
2) in do_page_fault(), "catch" the access fault to that address range
3) call a copy of the unaligned handler that printk's the accesses, their size and whether it was read or write
4) also have the pci config space accessor functions printk what they do

Then, having netconsole configured into the kernel, one should be able to log what the driver is doing to the chip.

I'm doing something similar inside MOL (mac-on-linux) but I need DMA for the loopback test which doesn't work in PIO mode, and I cannot run the OSX driver inside MOL in DMA mode.

If anyone is interested in helping I'd appreciate a note via email.

Thanks,
Johannes

(*) we can currently transmit frames, but we don't know why not receive

Hello johill,

I am interested in helping you. When I come back home on wednesday, I will set up a netconsole enabled kernel and give you SSH access to the box if it seems ok to you ?

I saw on your website that the driver intends to support 2.6 kernels, you know that the OpenWrt one is running a 2.4 one ? It may be a hard work patching the 2.6 kernel with the 2.4 hacks the openwrt developpers are using, but as explained here : http://wiki.openwrt.org/Kernel26Firmwar … =%282.6%29

Hi RItalMan,

Yes, the driver is specifically targetted for 2.6 kernels, and I doubt it'll be easy to backport it. However, right now I'm not much interested in running the new driver on the wrt, but rather patching the 2.4 kernel with what I wrote above to see what their driver is doing.

However, I'd also need help with that, as I haven't really worked on kernel code for mips so far. Steps 1-4 of what I wrote above is what I want to do on the box, but before that someone would obviously need to write those kernel patches...

johannes

I tried cooking up a patch. It compiles, but I have no idea if it runs. Also, the hardware address of the broadcom device is hardcoded to (0x400something) in the patch so if it's different for you you'll have to adjust that.

http://johannes.sipsolutions.net/files/ … -try.patch

Please enable netconsole if you try running it. And don't attempt unless you can reflash your device easily if  the kernel breaks etc etc etc.

I'd still appreciate if someone were to test that patch because it might be useful for other things, but right now I'm not really interested in it on this chipset any more. Got what I wanted another way.