development tree for U-Boot: Changes to 'stable'

[git at git.openmoko.org]

 common/cmd_terminal.c        |   13 +++++++++++++
 common/serial.c              |    2 +-
 cpu/arm920t/s3c24x0/serial.c |    3 ++-
 drivers/usb/usbdfu.c         |   42 +++++++++++++++---------------------------
 include/serial.h             |    4 ++++
 5 files changed, 35 insertions(+), 29 deletions(-)

New commits:
commit 414367bf5b65942947dd5d569c27d2a8e8e5e562
Author: Harald Welte <laforge at openmoko.org>
Date:   Tue Oct 7 18:49:49 2008 +0100

    u-boot: Fix DFU upload in u-boot
    
    Fix DFU upload in u-boot
    
    The existing USB DFU upload (read firmware from device to USB host) code
    was a big mess and probably only ever worked by accident.
    
    specifically, there were three bugs described in
    http://docs.openmoko.org/trac/ticket/1843 :
    
    * when it copies a new blockful of data, it copies it into the same buffer that
      urb->buffer was already pointing to, thus overwriting the beginning of the
      last buffer before it is sent back to the requestor
    
    * it then calls memcpy() to copy the beginning of the newly-read block to after
      the end of the buffer that urb->buffer is pointing to. If ds->nand->erasesize
      is the same as the _buf[] array, then this will write past the end of the
      _buf[] array and smash some other item in RAM.
    
    * if a requested buffer exactly reaches the end of the block that's been
      buffered in ds->buf, then handle_upload() will read a new NAND block into the
      buffer even though it is not needed. (The test for (len > remain) should
      probably go before the test for ds->ptr, not after?)
    
    So instead of fixing those issues individually, I rewored the logic
    for how to deal with DFU upload. Much simpler, and without those bugs.
    
    Signed-off-by: Harald Welte <laforge at openmoko.org>

commit 1746c3657337018a3f14688ed4793be2ed609733
Author: Harald Welte <laforge at openmoko.org>
Date:   Tue Oct 7 18:49:34 2008 +0100

    Enable hardware flow control for GSM/GPS
    
    GTA02 >= v3: Enable hardware flow control for GSM and GPS serial ports
    
    Without this patch, s3ser0 (GSM) and s3ser1 (GPS) will not properly
    work on GTA02 >= v3 hardware.
    
    Together with the previous patch, this fixes bug
    https://docs.openmoko.org/trac/ticket/1595
    
    Signed-off-by: Harald Welte <laforge at openmoko.org>

commit 017271c84a1f5b8dc7a8869b2bf4d77347cce647
Author: Harald Welte <laforge at openmoko.org>
Date:   Tue Oct 7 18:49:18 2008 +0100

    Fix init of non-console serial lines
    
    [serial]: Fix initialization of non-console serial lines
    
    When using a serial port for something that is not console operation
    (like the 'terminal' mode with GSM or GPS on Openmoko GTA02), then
    the serial port needs to be initialized properly.
    
    Signed-off-by: Harald Welte <laforge at openmoko.org>