#9784 NORM 1.5-fir: firmware-up-to-date rejects XO-1.5 firmware

[Zarro Boogs per Child]

#9784: firmware-up-to-date rejects XO-1.5 firmware
-------------------------------------------+--------------------------------
           Reporter:  dsd                  |       Owner:  wmb at firmworks.com  
               Type:  defect               |      Status:  assigned           
           Priority:  normal               |   Milestone:  1.5-firmware-C1-SMT
          Component:  ofw - open firmware  |     Version:  not specified      
         Resolution:                       |    Keywords:                     
        Next_action:  diagnose             |    Verified:  0                  
Deployment_affected:                       |   Blockedby:                     
           Blocking:  9573                 |  
-------------------------------------------+--------------------------------

Comment(by wmb at firmworks.com):

 I suspect that there is some problem with the test procedure.

 Here is the typescript of how I tested it:

 * Copied the new bootfw.zip file to the root directory of a USB stick

   OLPC D2, 512 MiB memory installed, S/N Unknown
   OpenFirmware  CL1   Q3A18  Q3A

 Thus we see that the new firmware is installed.

   ok dir u:\bootfw.zip
   fat-file-system
   --A-rwxrwxrwx   1048724  2009-12-02 21:51:24  BOOTFW.ZIP

 Thus we see that the bootfw.zip is the correct one.

   ok " u:\bootfw.zip" (boot-read)

 That step completed without aborting, so the file was loaded into memory
 (and had "catch" been used, it would have returned 0 indicating no abort).

   ok img$ .s
   100003b 100000

 The number on the top of the stack is 1 meg, which is the correct size for
 the data.img inside the zip.  With the old firmware, i.e. in the failing
 case, the top of the stack was 0, indicating that the data.img subfile was
 not found.

   ok firmware-up-to-date? .
   ffffffff

 firmware-up-to-date? did not say "Invalid Firmware image", which is the
 error message that appeared in the failing case (because the size was
 wrong, i.e. not 100000).

 To diagnose this further, I will need complete details of the procedure
 that was used to exhibit the failure.  Or perhaps someone else can
 discover the procedural problem.

-- 
Ticket URL: <http://dev.laptop.org/ticket/9784#comment:7>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system