Openmoko Bug #1843: u-boot's DFU upload garbles data at block boundary

[Openmoko Public Trac]

#1843: u-boot's DFU upload garbles data at block boundary
--------------------------------+-------------------------------------------
    Reporter:  wiml             |        Owner:  laforge 
        Type:  defect           |       Status:  assigned
    Priority:  normal           |    Milestone:          
   Component:  System Software  |      Version:  GTA02v6 
    Severity:  major            |   Resolution:          
    Keywords:  dfu              |    Blockedby:          
Reproducible:                   |     Blocking:  676     
--------------------------------+-------------------------------------------
Changes (by laforge):

  * blocking:  => 676


Comment:

 thanks for the detailed analyisis, it really describes well why many
 people have been experiencing various upload related problems (and it was
 never working, at least not on GTA02 where the erazeblock size is much
 bigger than on GTA01).

 I'm right now working on altering the code.  It's not as straight-forward
 as you may think. We are under tight constraints by the DFU spec, i.e.
 whatever amount of bytes the host asks us for, we need to deliver it.  If
 we'd return less than what was asked for, this would implicitly mean
 the end of a transmission.  I also do not want to introduce a second
 buffer (for the URB), since
 that would mean we always need to memcpy() and it would further increase
 the memory requirements
 of u-boot.

 The current code structure is a result from trying to implement UPLOAD
 based on the infrastructure that DOWNLOAD provided.  For download it makes
 sense to think in terms of nand
 erase blocks.  For upload it actually makes much more sense to think in
 terms of whatever amount
 of bytes the host requests.

 I'll try to rework the logic accordingly.

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/1843#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac