Talk:XO-1/Software specification: Difference between revisions
(Replacing page with 'I've got to kick somebody's butt.') |
(rv bully) |
||
| Line 1: | Line 1: | ||
Xavi, Ortiz: please don't change this page before Tuesday at the earlies: I'm doing major work on it, and your edits are causing me to lose work again, and again. Thanks - Jim |
|||
I've got to kick somebody's butt. |
|||
We need an easy way to measure power usage. Then we can determine what gcc options give the best power usage. (gcc has "-Os" for size and "-O2" for speed; it could have "-Op" for power) [[User:AlbertCahalan|AlbertCahalan]] 18:53, 2 March 2007 (EST) |
|||
If an SD memory card is plugged in and is mounted into the file system, it should still be possible to power |
|||
down the SD slot, by first sync-ing the file system into a clean status, and then powering down the slot. Whenever |
|||
it is next accessed, it can be powered-up. Whenever it is next written, the "clean" bits in the superblock can |
|||
be unset, then the write can take place. In addition, to avoid frequent wakeups if something is looking at the |
|||
root inode where the SD card is mounted, that inode (and possibly other info, such as its directory contents) can |
|||
be cached read-only in RAM. They are guaranteed not to change while the card is powered down :-). This is |
|||
completely independent of CPU power (unless the mobo is wired to depend). -- gnu 7 May 2007 |
|||
The same strategy can be employed for USB memory sticks: If mounted, they can be sync'd to a clean filesystem |
|||
state, and then powered down. This can be done independently from CPU power (but I don't know if it's actually |
|||
wired that way). -- gnu 7 May 2007 |
|||
I don't understand why "an ebook reader" would ask the system for "aggressive power management". Why wouldn't the system always be aggressively managing its power? Would we instruct students to start up the ebook reader to reduce the power consumption of their systems? |
|||
I suspect that in B1 and B2 prototypes, it will be possible to suspend for a period of a second or two (if the user allows this to be done), power-up long enough to figure out whether any key has been held down on the keyboard, and go back to sleep if not. Yes, the screen might glitch; some users will not care. This will give the suspend code about 100x as much testing as it would get on B3 systems only, and will also reduce power for the 3500+ users of B1 and B2 systems. |
|||
Revision as of 19:07, 5 June 2007
Xavi, Ortiz: please don't change this page before Tuesday at the earlies: I'm doing major work on it, and your edits are causing me to lose work again, and again. Thanks - Jim
We need an easy way to measure power usage. Then we can determine what gcc options give the best power usage. (gcc has "-Os" for size and "-O2" for speed; it could have "-Op" for power) AlbertCahalan 18:53, 2 March 2007 (EST)
If an SD memory card is plugged in and is mounted into the file system, it should still be possible to power
down the SD slot, by first sync-ing the file system into a clean status, and then powering down the slot. Whenever
it is next accessed, it can be powered-up. Whenever it is next written, the "clean" bits in the superblock can
be unset, then the write can take place. In addition, to avoid frequent wakeups if something is looking at the
root inode where the SD card is mounted, that inode (and possibly other info, such as its directory contents) can
be cached read-only in RAM. They are guaranteed not to change while the card is powered down :-). This is
completely independent of CPU power (unless the mobo is wired to depend). -- gnu 7 May 2007
The same strategy can be employed for USB memory sticks: If mounted, they can be sync'd to a clean filesystem
state, and then powered down. This can be done independently from CPU power (but I don't know if it's actually
wired that way). -- gnu 7 May 2007
I don't understand why "an ebook reader" would ask the system for "aggressive power management". Why wouldn't the system always be aggressively managing its power? Would we instruct students to start up the ebook reader to reduce the power consumption of their systems?
I suspect that in B1 and B2 prototypes, it will be possible to suspend for a period of a second or two (if the user allows this to be done), power-up long enough to figure out whether any key has been held down on the keyboard, and go back to sleep if not. Yes, the screen might glitch; some users will not care. This will give the suspend code about 100x as much testing as it would get on B3 systems only, and will also reduce power for the 3500+ users of B1 and B2 systems.