Linux Driver Project Status Report as of April 2008
seerfar at gmail.com
Sat Apr 12 23:04:21 PDT 2008
On Tue, Apr 8, 2008 at 9:59 PM, John W. Linville <linville at tuxdriver.com> wrote:
> On Mon, Apr 07, 2008 at 11:42:52PM -0700, Greg KH wrote:
> > On Tue, Apr 08, 2008 at 11:46:48AM +0530, JoJo jojo wrote:
> > > e) wireless is a mess because of FCC regulations, they want
> > > manufacturers to limit the operating capabilities of the
> > > device(frequencies), manufacturers figure that its cheaper to do this
> > > in s/w rather than h/w, by making a closed source firmware. I don't
> > > see how we can improve this situation unless you can help EU legislate
> > > it away (assuming US is a lost cause)
> > The whole FCC thing is, in my personal opinion, a big excuse that some
> > companies are using to not release the code for their hardware. If you
> > notice, other companies do not believe this and have released code.
> I think it is actually some of both. Regulators (particularly the
> FCC) have failed to eliminate the spectre of threat that might come
> from opening specs and/or source code from vendors. Further, they
> continue to countenance the notion that closed-source software is
> somehow equivalent to locking-down a hardware device. This provides
> enough "cover" for vendors to "run home" to an unfriendly stance
> against open source if they have any desire to do so for whatever
> other reasons may exist (embarassment about sloppy specs, perceived
> competitive advantage, etc).
> > Either way, the very capable, and active developers of the
> > linux-wireless projects are working to resolve all of the wireless
> > driver issues. If you have questions or concerns about these types of
> > devices, please contact them.
> On behalf of my developers (who do all the work), I appreciate your
> vote of confidence!
> While I'm here, let me invite any budding reverse engineers to
> join us on linux-wireless at vger.kernel.org. As Greg mentioned the
> reverse-engineered ath5k and b43 (and b43legacy) drivers continue
> to develop, but both projects could use more help. In particular
> the b43 folks need help reverse engineering the 802.11n devices.
> Also, there is a project underway to reverse-engineer support for
> Airgo devices. I regret that I haven't spent much time with that
> project, but I think it is well underway.
Is the reverse engneer of Airgo device taken charge by Jeff Williams
We refer to it to developed the driver, however the driver is unstable.
Jeff said the reverse engneer is carried out by hard research.
Now I am reversing engneer the driver of Airgo device on Window.
By the way, there is a strange assembly code from IDA Pro(a disassemble tool).
I can not understand it. Where should the Windows assembly code be discussed?
The assembly code is very simple, just write a value to ioremap space and check
whether it take affect. However it is different between the value
the value checked(10h).
The assembly code(from IDA Pro 5.0):
sub_13C00 proc near
var_4= dword ptr -4
arg_0= dword ptr 8
mov esi, [esp+arg_0]
mov al, [esi+24Ah]
test al, al
jz short loc_13C71
mov eax, [esi+31F4h]
push 100h ; Value
add eax, 3000h
push eax ; Register
mov eax, [esi+31F4h]
mov ecx, [eax+3000h]
mov [esp+arg_0], ecx
mov edx, [esp+arg_0]
and edx, 10h
cmp dl, 10h
jnz short loc_13C71
mov edi, ds:KeStallExecutionProcessor
lea esp, [esp+0]
loc_13C50: ; MicroSeconds
call edi ; KeStallExecutionProcessor
mov eax, [esi+31F4h]
mov eax, [eax+3000h]
mov [esp+4+arg_0], eax
mov ecx, [esp+4+arg_0]
and ecx, 10h
cmp cl, 10h
jz short loc_13C50
> Beyond that there are projects underway for Marvell PCI hardware,
> both the older 83xx and the newer 86xx stuff. The 83xx support
> (using the mrv8k driver) is farther along, while the 86xx stuff
> has made little progress. Marvell is at least somewhat friendly to
> having these supported, although their documentation is a bit lax.
> There are however (unmergeable) sample drivers available for each.
> Also lurking out there is support for the USB-based Prism2 devices.
> The linux-wlan project had support for these, but the kernel.org
> kernels do not. Hardware can be a bit hard to find...
> Well, enough food for thought for one message... :-)
> John W. Linville
> linville at tuxdriver.com
> devel mailing list
> devel at linuxdriverproject.org
More information about the devel