Re: Animation/Python/PyGames vs battery charge
Hi I suspect that the best thing you can do to reduce power is to make sure that your game doesn't do anything when it isn't the frontmost thing on the screen. I.e. if the window that you're drawing in is totally obscured, then don't run ANYTHING -- no game animations, but also no background world-simulating stuff, and little or no network activity. Resume activity once the user brings your game to the front again. Don't wake up periodically and do anything; be sure to do NOTHING. Ensuring this background-idle behavior will not only allow the activity that's frontmost to get 100% of the CPU cycles. It will also allow the XO to suspend and power down if that frontmost activity goes idle. (If you're chewing up CPU in the background, the system won't auto-suspend.) Maybe sugar could suspend those activities which are in the background so the activities don't have to worry about it. Also it would be fool proof. -- Rózsás Gödény ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: free firmware for 88W8388
Hi first short term goal is to connect the emulator to linux host as if the 8388 running inside the emulator were plugged into the host this requires emulating an usb device from user space after some googleing I found that this feature exists and it's called gadgetfs also I found that developers of openmoko use this gadgetfs feature to connect qemu running openmoko firmware (as an arm machine) to the linux host, it is that very feature that we need so , hurray it's documented here: http://wiki.openmoko.org/wiki/Qemu#Setting_up_USB_connection -- Rózsás Gödény ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
free firmware for 88W8388
Hello I started to modify qemu to emulate 88W8388. Now it can load the firmware ( usb8388.bin) into ram and starts the firmware, albeit it drops an error after some time. So it is very simple so far, I worked on it for a couple of hours so far. My short term goals: - emulate the usb device of the 8388 and create a connection between the linux kernel driver and the emulator so from linux pow starting the emulator looks as plugging in the usb device - 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. Anyway, if we want to write the free firmware, a good emulator of 8388 is handy. Anybody interested ? I took many info from http://wiki.laptop.org/go/Marvell_microkernel and http://wiki.laptop.org/go/88W8388 so kudos to all who created it. -- Rózsás Gödény ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: free firmware for 88W8388
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
