[Trac #836] Gen 1.5 wishlist

[Zarro Boogs per Child]

#836: Gen 1.5 wishlist
-------------------------+--------------------------------------------------
 Reporter:  mlj          |        Owner:  mlj     
     Type:  enhancement  |       Status:  assigned
 Priority:  normal       |    Milestone:  Gen1-5  
Component:  distro       |   Resolution:          
 Keywords:  Gen1.5       |  
-------------------------+--------------------------------------------------
Comment (by gnu):

 Put SD slot in an accessible place.  Perhaps add a MiniSD or MicroSD slot
 under the ears, while retaining the full size SD slot in hiding.

 Upgrade 4-bit to 8-bit (13-wire) SD/MMC interface -- doubles the data rate
 to MMCplus cards, and eventually to wide SD cards once they publish the
 spec.

 Figure out a way to make the DRAM expandable.  Or make someplace to page
 or swap to.  SD can
 be used for that, but writing to flash is slow.  (I have a 200 MHz Pentium
 Pro PC with 64MB of SIMM RAM.  It's is about six times as fast and usable
 as the 128MB OLPC today, because it pages to a hard drive.  It has half
 the "bogomips" but 8x as much CPU cache.  Also, it has a real window
 manager and runs standard Knoppix X window system apps.)

 Perhaps we could make a combination DRAM+Flash SD/MMC card, containing two
 independent or almost-independent devices.  SD cards can have sub-devices;
 WiFi and Flash combo cards exist,
 for example.  It would accept writes and rewrites and re-re-writes very
 quickly to DRAM, as well as accepting the usual kind of writes to non-
 volatile flash.  But if we got fancy, it might be able to transfer subsets
 of the DRAM information to flash under software control (can it sense
 while the user is ejecting the card, and do it quickly?), or during a
 power failure.  If non fancy, it would just be some volatile DRAM and some
 nonvol Flash, with no connection between.

 If we used the DRAM on such a dual SD card solely for swap space, and the
 Flash for long-term mass storage, then as long as the user never ejected
 the card, this would function very well without any software changes.
 Software would have to keep the card powered (but idle, so at low wattage)
 as long as there was anything valuable stored in the DRAM.  But it could
 power the whole card down by moving that information into Flash (on-chip,
 or in & out over the SD bus), or back into main board DRAM, if it desired.
 (When the system goes to sleep, it can afford to fill up
 all its spare DRAM pages with copies of pages from the swap device, if
 that reduces power consumption.)

 Reading from the current JFFS seems to be quite slow, compared to reading
 from a hard drive; this is unexpected.  Do we need to do something to
 speed up the decompression of disk blocks?  Or have we characterized the
 low speed as being caused by some other fixable problem?

 Get AMD to fix the most egregious bugs in the GX chipset.  It's hard to
 believe they're stamping out millions of chips for us, yet they won't
 insert any design tweaks to e.g. eliminate the bug that loses 20% of CPU
 performance.  Merely increasing the on-chip cache from 32k would probably
 win; my old PPro has 256kb and seems substantially faster.  Rolling our
 high speed flash controller into the CPU chipset, where it should have
 been in the first place, would be a nice thing.

-- 
Ticket URL: <http://dev.laptop.org/ticket/836#comment:9>
One Laptop Per Child <http://laptop.org/>