15 Oct, 2013

10 commits


14 Oct, 2013

2 commits


11 Oct, 2013

1 commit


10 Oct, 2013

6 commits

  • The musb driver defines and uses MUSB_CSR0_H_DIS_PING, however this
    bit is reserved on the DM36x. Thus this patch ensures that the
    reserved bit is not accesssed.

    It has been observed that some USB devices will fail to enumerate
    with errors such as 'error in inquiry' without this patch.

    See http://www.ti.com/litv/pdf/sprufh9a for details.

    Cc: Marek Vasut
    Cc: Tom Rini
    Signed-off-by: Andrew Murray
    Acked-by: Marek Vasut

    Andrew Murray
     
  • OMAP5 boards may have both eMMC (on MMC2) and an SD slot (on MMC1). We
    Update the default bootcmd to match what happens on AM335x where we try
    SD first, and then eMMC. In this case however, the hardware layout used
    for powering both of these means that in the kernel eMMC shall be found
    first as it is powered by a fixed regulator and SD found second as SD is
    powered via the palmas which will result in deferred probing.

    Tested-by: Aparna Balasubramanian
    Signed-off-by: Tom Rini

    Tom Rini
     
  • This allows you to write data to an UBI volume when the amount of memory
    available to write that data from is less than the total size of the
    data. For example, you may split a root filesystem UBIFS image into
    parts, provide the total size of the image to the first write.part
    command and then use multiple write.part commands to write the
    subsequent parts of the volume. This results in a sequence of commands
    akin to:

    ext4load mmc 0:1 0x80000000 rootfs.ubifs.0
    ubi write.part 0x80000000 root 0x08000000 0x18000000
    ext4load mmc 0:1 0x80000000 rootfs.ubifs.1
    ubi write.part 0x80000000 root 0x08000000
    ext4load mmc 0:1 0x80000000 rootfs.ubifs.2
    ubi write.part 0x80000000 root 0x08000000

    This would write 384MiB of data to the UBI volume 'root' whilst only
    requiring 128MiB of said data to be held in memory at a time.

    Signed-off-by: Paul Burton
    Acked-by: Stefan Roese

    Paul Burton
     
  • int64_t matches the bytes field in struct ubi_mkvol_req to which the
    size is assigned. With the prior signed 32 bit integer, volumes were
    restricted to being less than 2GiB in size.

    Signed-off-by: Paul Burton
    Acked-by: Stefan Roese

    Paul Burton
     
  • This matches the 64 bit size in struct mtd_info and allows the mtdparts
    command to function correctly with a flash >= 4GiB. Format specifiers
    for size & offset are given the ll length, matching its use in
    drivers/mtd in absence of something like inttypes.h/PRIx64.

    Signed-off-by: Paul Burton
    Acked-by: Stefan Roese

    Paul Burton
     
  • Linux modified the MTD driver interface in commit edbc4540 (with the
    same name as this commit). The effect is that calls to mtd_read will
    not return -EUCLEAN if the number of ECC-corrected bit errors is below
    a certain threshold, which defaults to the strength of the ECC. This
    allows -EUCLEAN to stop indicating "some bits were corrected" and begin
    indicating "a large number of bits were corrected, the data held in
    this region of flash may be lost soon". UBI makes use of this and when
    -EUCLEAN is returned from mtd_read it will move data to another block
    of flash. Without adopting this interface change UBI on U-boot attempts
    to move data between blocks every time a single bit is corrected using
    the ECC, which is a very common occurance on some devices.

    For some devices where bit errors are common enough, UBI can get stuck
    constantly moving data around because each block it attempts to use has
    a single bit error. This condition is hit when wear_leveling_worker
    attempts to move data from one PEB to another in response to an
    -EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
    called to perform the data copy, and after the data is written it is
    read back to check its validity. If that read returns UBI_IO_BITFLIPS
    (in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
    wear_leveling worker, which then proceeds to schedule the destination
    PEB for erasure. This leads to erase_worker running on the PEB, and
    following a successful erase wear_leveling_worker is called which
    begins this whole cycle all over again. The end result is that (without
    UBI debug output enabled) the boot appears to simply hang whilst in
    reality U-boot busily works away at destroying a block of the NAND
    flash. Debug output from this situation:

    UBI DBG: ensure_wear_leveling: schedule scrubbing
    UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
    UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
    UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
    UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
    UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
    UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
    UBI: fixable bit-flip detected at PEB 1027
    UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
    UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
    UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
    UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
    UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
    UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
    UBI: fixable bit-flip detected at PEB 4083
    UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
    UBI DBG: erase_worker: erase PEB 4083 EC 55
    UBI DBG: sync_erase: erase PEB 4083, old EC 55
    UBI DBG: do_sync_erase: erase PEB 4083
    UBI DBG: sync_erase: erased PEB 4083, new EC 56
    UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
    UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
    UBI DBG: ensure_wear_leveling: schedule scrubbing
    UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
    ...

    This patch adopts the interface change as in Linux commit edbc4540 in
    order to avoid such situations. Given that none of the drivers under
    drivers/mtd return -EUCLEAN, this should only affect those using
    software ECC. I have tested that it works on a board which is
    currently out of tree, but which I hope to be able to begin
    upstreaming soon.

    Signed-off-by: Paul Burton
    Acked-by: Stefan Roese

    Paul Burton
     

09 Oct, 2013

6 commits


08 Oct, 2013

11 commits

  • Upon further inspection and review and chatting with kernel folks, what
    happens here is that what mmcblk# a device gets is based on probe order.
    So a system with an SD card inserted with place eMMC on mmcblk1, but
    without an SD card, it will be on mmcblk0. So U-boot can only provide a
    best guess. In this case, if no SD card is present, we would want to
    pass mmcblk0p2 still. If an SD card is present, it woudl be able to
    provide a uEnv.txt that would be loaded (even if the kernel is NOT
    there) which can still update mmcroot variable.

    This reverts commit 827512fb1154c05c6eb1e2259e936df55c98a535.

    Cc: Robert P. J. Day
    Signed-off-by: Tom Rini

    Tom Rini
     
  • Tom Rini
     
  • Tom Rini
     
  • Since SPI register access is so expensive, it is worth transferring data
    a word at a time if we can. This complicates the driver unfortunately.

    Use the byte-swapping feature to avoid having to convert to/from big
    endian in software.

    This change increases speed from about 2MB/s to about 4.5MB/s.

    Signed-off-by: Simon Glass
    Signed-off-by: Rajeshwari S Shinde
    Reviewed-by: Jagannadha Sutradharudu Teki

    Rajeshwari Shinde
     
  • Accessing SPI registers is slow, but access to the FIFO level register
    in particular seems to be extraordinarily expensive (I measure up to
    600ns). Perhaps it is required to synchronise with the SPI byte output
    logic which might run at 1/8th of the 40MHz SPI speed (just a guess).

    Reduce access to this register by filling up and emptying FIFOs
    more completely, rather than just one word each time around the inner
    loop.

    Since the rxfifo value will now likely be much greater that what we read
    before we fill the txfifo, we only fill the txfifo halfway. This is
    because if the txfifo is empty, but the rxfifo has data in it, then writing
    too much data to the txfifo may overflow the rxfifo as data arrives.

    This speeds up SPI flash reading from about 1MB/s to about 2MB/s on snow.

    Signed-off-by: Simon Glass
    Signed-off-by: Rajeshwari S Shinde
    Reviewed-by: Jagannadha Sutradharudu Teki

    Rajeshwari Shinde
     
  • For devices that need some time to react after a spi transaction
    finishes, add the ability to set a delay.

    Implement this as a delay on the first/next transaction to avoid
    any delay in the fairly common case where a SPI transaction is
    followed by other processing.

    Signed-off-by: Simon Glass
    Signed-off-by: Rajeshwari S Shinde
    Reviewed-by: Jagannadha Sutradharudu Teki

    Rajeshwari Shinde
     
  • This function, if implemented by the board, provides a microsecond
    timer. The granularity may be larger than 1us if hardware does not
    support this.

    Signed-off-by: Simon Glass
    Signed-off-by: Rajeshwari S Shinde
    Reviewed-by: Jagannadha Sutradharudu Teki

    Rajeshwari Shinde
     
  • As documented, almost all U-Boot commands expect numbers to be entered
    in hexadecimal input format. (Exception: for historical reasons, the
    "sleep" command takes its argument in decimal input format.)

    This rule was broken for the "load" command; for details please see
    especially commits 045fa1e "fs: add filesystem switch libary,
    implement ls and fsload commands" and 3f83c87 "fs: fix number base
    behaviour change in fatload/ext*load". In the result, the load
    command would always require an explicit "0x" prefix for regular
    (i. e. base 16 formatted) input.

    Change this to use the standard notation of base 16 input format.
    While strictly speaking this is a change of the user interface, we
    hope that it will not cause trouble. Stephen Warren comments (see
    [1]):

    I suppose you can change the behaviour if you want; anyone
    writing "0x..." for their values presumably won't be
    affected, and if people really do assume all values in U-Boot
    are in hex, presumably nobody currently relies upon using
    non-prefixed values with the generic load command, since it
    doesn't work like that right now.

    [1] http://article.gmane.org/gmane.comp.boot-loaders.u-boot/171172

    Acked-by: Tom Rini
    Acked-by: Stephen Warren
    Signed-off-by: Wolfgang Denk

    Wolfgang Denk
     
  • Adding the generated pin mux configuration by Preloader
    Generator tool

    Signed-off-by: Chin Liang See
    Reviewed-by: Pavel Machek
    Acked-by: Dinh Nguyen
    Cc: Wolfgang Denk
    CC: Pavel Machek
    Cc: Dinh Nguyen
    Cc: Tom Rini
    Cc: Albert Aribaud

    Chin Liang See
     
  • Adding System Manager driver which will configure the
    pin mux for real hardware Cyclone V development kit
    (not Virtual Platform)

    Signed-off-by: Chin Liang See
    Reviewed-by: Pavel Machek
    Acked-by: Dinh Nguyen
    Cc: Wolfgang Denk
    CC: Pavel Machek
    Cc: Dinh Nguyen
    Cc: Tom Rini
    Cc: Albert Aribaud

    Chin Liang See
     
  • omap1510inn is orphan and has been for years now.
    Reove it and, as it was the only arm925t target,
    also remove arm925t support.
    Update doc/README.scrapyard accordingly.

    Signed-off-by: Albert ARIBAUD

    Albert ARIBAUD
     

07 Oct, 2013

4 commits