WLAN status update

Werner Almesberger werner at openmoko.org
Mon Jan 12 18:32:20 CET 2009


Michael Buesch wrote:
> Ok, but the firmware _is_ flashable? Or is it just "updateable" through the
> life-patching mechanism?
> And by "no redistributeable" you mean there exists a tool, but it's NDA'd?

The firmware can be reflashed and there is a tool for it, but it seems
only Atheros and perhaps very close partners have access to it. Even
we (Openmoko) don't have it, not even for internal use. So when we had
to update the firmware on some modules, we had to return the modules
and get them physically replaced.

There is discussion between Openmoko and Atheros about opening this up
a little, particularly also with the possibility of replacing the
firmware with a leaner version that would support a soft-MAC. But it's
not yet clear if this will actually happen.

Needless to day, a soft-MAC would solve a lot of problems for us, even
if it means that we'd have to write a driver from scratch for it.

You mentioned some runtime patching. Do you mean AR6000_XIOCTL_DIAG_WRITE ?
I'm not aware of anything that uses this interface for "live" updates.
There is drivers/ar6000/miscdrv/common_drv.c:ar6000_reset_device_skipflash,
but that only switches between ROM and Flash.

Read access with wmiconfig --dumpchipmem is a bit disappointing: it
returns that there's plenty of dead beef all over the place in the
memory regions hard-coded in wmiconfig.

"wmiconfig --diagaddr=<addr> --diagread" allows some more inspection.
E.g., there seems to be ROM at 0x1000000 and it can be read.

drivers/ar6000/include/AR6001_regdump.h suggests that there's a MIPS
core in there.

> Ok thanks anyway.
> I'm interested in any available information about the firmware.
> Somebody else? :)

It's pretty much shrouded in mystery. I didn't search for holes that
would let us manipulate the firmware, but if I had spotted anything
promising by accident, I think I would have noticed.

> I think rfkill should be considered to trash all MAC states.
> Even if in reality the time rfkill is triggered matters. But I think no
> Authenticator will support a killed radio for more than a few seconds without
> trashing at least part of the connection.
> So yeah, we should re-load all state (or as you said un-rfkill).

Okay, that's a lot more freedom than the documentation suggests.
Perhaps we should walk through a few examples with the ESSID,
because that's a fairly well-understood configuration item.

Case 1:
- ESSID is set
- rfkill disables the transmitter, then re-enables it
- what states is the ESSID allowed to be in now ?

Case 2:
- rfkill disables the transmitter
- an attempt is made to set the ESSID with SIOCSIWESSID. Does the
  ioctl have to succeed or is it allowed to fail ?
- rfkill enables the transmitter
- if SIOCSIWESSID succeeded, what state is the ESSID in now ?

Also, if rfkill affects the ESSID, who is responsible of informing
user space that the ESSID to be set again, and how is this
accomplished ? A straightforward way may be to take down the whole
interface and then bring it up again, but that may be considered a
little radical.

- Werner



More information about the devel mailing list