On Monday 12 January 2009 18:32:20 Werner Almesberger wrote: > 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.
Yeah that would solve about all issues left :) > 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. I was talking about BMIrompatchInstall and friends. The BMIReadMemory interface seems to work (at least it returns some data that looks like state tables, data structures etc... from RAM), so I guess the rest of the BMI functions would possibly also work. > 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. Hm, that'd be cool. > 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 ? I think it should be handed to the Supplicant. The Supplicant will try to re-establish the connection or drop it. So the real question is, does the firmware implement part of the Supplicant? I guess so. Currently, however, most devices that implement rfkill don't drop any state at all. They simply wait for the Supplicant to notice the connection interruption. This will happen within a few seconds and the Supplicant will re-establish the connection. That's not the ideal solution, however, as it introduces a few seconds delay for the supplicant to notice the interruption. > 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 ? Well, wireless extensions semantics are a little bit crappy. But as far as I understand the semantics, SIWESSID is supposed to associate to the service (except in a few cornercases). So IMO it should fail, because without a transmitter, we can't handshake a connection. > 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. Yeah, as I said. Current mainline drivers don't mess with state at all. They simply depend on the upper MAC to detect the situation and re-establish the connection and states as needed. -- Greetings, Michael. _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
