[openfirmware] [commit] r2193 - cpu/x86/pc/olpc/via

repository service svn at openfirmware.info
Fri Apr 29 07:10:29 CEST 2011


Author: quozl
Date: Fri Apr 29 07:10:28 2011
New Revision: 2193
URL: http://tracker.coreboot.org/trac/openfirmware/changeset/2193

Log:
OLPC XO-1.5 - fs-update, remove erase support because it broke
NANDblaster.  The microSD card is used to hold the received .zd file,
and erasing the card erases the file, causing fs-update to see a zero
filled file beyond a certain point.  This revision tested with sparse
.zd files on NANDblaster and fs-update from USB.

Modified:
   cpu/x86/pc/olpc/via/fsupdate.fth

Modified: cpu/x86/pc/olpc/via/fsupdate.fth
==============================================================================
--- cpu/x86/pc/olpc/via/fsupdate.fth	Wed Apr 27 09:14:27 2011	(r2192)
+++ cpu/x86/pc/olpc/via/fsupdate.fth	Fri Apr 29 07:10:28 2011	(r2193)
@@ -66,24 +66,6 @@
 vocabulary nand-commands
 also nand-commands definitions
 
-\ some cards do not respond in a reasonable time,
-\ some cards lock up and cause a command timeout in get-status,
-\ so split the erase into many parts.
-: erase-blocks
-   [char] ~ emit                        \ visual hint of erase delay
-   #image-eblocks /nand-block h# 200 */ ( #blocks )
-   dup d# 16 / swap                     ( /part #blocks )
-   0 do                                 ( /part )
-      i over " erase-blocks" $call-nand
-      hdd-led-toggle                    \ visual hint of progress
-   dup +loop                            ( /part )
-   drop
-   bs emit space bs emit hdd-led-off    \ visual hint remove
-;
-
-\ : erase-blocks
-\ 0 #image-eblocks /nand-block h# 200 */ " erase-blocks" $call-nand ;
-
 : zblocks:  ( "eblock-size" "#eblocks" ... -- )
    hdd-led-toggle
    ?compare-spec-line
@@ -94,7 +76,6 @@
    " size" $call-nand  #image-eblocks /nand-block um*  d<
    " Image size is larger than output device" ?nand-abort
    #image-eblocks  show-init
-   erase-blocks
    get-inflater
    \ Separate the two buffers by enough space for both the compressed
    \ and uncompressed copies of the data.  4x is overkill, but there



More information about the openfirmware mailing list