-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Monday 12 January 2009 17:00:13 Andy Green wrote: |> No, it's a less than happy-making situation there are no updates and no |> redistributable Linux firmware update tool. | | 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?
I think at some point we ended up with a copy somehow but it was a Windows app and not redistributable, personally I never saw it even. |> | It seems possible to read the device RAM in the boot stage and that |> also seems to work |> | fine. But I didn't see a way to read the PROM. I didn't even find a |> way to write the PROM |> | actually. Except this runtime patching thing. So I was wondering if |> that runtime patching |> | stuff can be used to read the ROM step by step (into RAM). |> | Does somebody have some information on the CPU and/or instruction set |> used in the wireless device? |> |> I don't have anything. | | Ok thanks anyway. | I'm interested in any available information about the firmware. Somebody else? :) Samuel Oritz worked on AR6001 driver for a while, he may be able to point to stuff that is already available and doesn't hurt NDA-wise. |> Right, but I mean the direct implication of (only) killing TX is that |> association state and the other network layer states change too. So I | | Are you talking about IFF_* from linux/if.h? | I think we usually don't change them much at all on wireless devices, as most of | them don't make sense for wireless. | I don't know about any device changing these flags on rfkill. No, I'm just saying killing RF TX, just like a killswitch does --> the device can't talk on the air any more --> then you know it is going to lose association --> big trashing of upper layers state. So rfkill is inherently destructive of all kinds of network state (intentionally, and it's fine). |> don't think we need to sweat possibility of rfkill changing state like |> essid when it has definitely trashed the association and all that will |> need to be set up again from scratch. If it does turn out to be |> objectionable, we can reload old essid from just before we rfkilled it |> when we un-rfkill it. | | 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). Sounds like everyone has the same idea. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklrc70ACgkQOjLpvpq7dMp/6wCfQgkyGC0ScB4gDV9heUnOcYfZ 16YAnRMrWIPwzerQN8klFnz3CYlQi3Cf =mrZO -----END PGP SIGNATURE----- _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
