Hi
I hope you can make options to start with any of the 3 firmwares. > Perhaps I wish to try writing a boot1 or boot2. yes, that is an option > > > > - modify qemu so that i/o ports of 8388 could be accessed from > > outside of the emulator. I guess that the arm core of 8388 > > communicates with the other parts (the radio interface) via > > io ports so if we can see which ports are read/written by the > > arm core we can do the same from the free firmware. > > "accessed from outside"? (to just view them, to hook them up to > something, etc.?) > what I mean is that whenever the firmware inside the emulator writes an io port the emulator forwards it to a named pipe also the emulator reads that pipe and sends data the other way around, too then a simple perl script can play the "radio part", we can log what the core sends and we can try to inject data into the firmware as if it came from the air interface it may or may not work :) regarding the legality of this: I have the firmware from olpc image and never agreed to Marvell's conditions that are mentioned on the wiki still I don't want to reverse engineer the firmware what I suggest is similar to the approach of the samba team, they listened on the ethernet interface and tried to understand the bits and bytes then they replayed the traffic with their own code. we can listen in the io ports or whatever is necessary and replay it from out own firmware without looking into the firmware itself I guess samba team had a few windows machines (client and server) to generate the traffic so we can use the firmware to generate the traffic, too I'm rather worried about 802.11s, if we implement it following the standard we might have some trouble because of patent trolls. -- Rózsás Gödény
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
