1. 04 8月, 2014 1 次提交
  2. 23 7月, 2014 2 次提交
    • S
      sandbox: Support pre-relocation malloc() · 29afe9e6
      Simon Glass 提交于
      Set up and zero global data before board_init_f() is called so that we can
      remove the need for CONFIG_SYS_GENERIC_GLOBAL_DATA.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      29afe9e6
    • S
      Add a simple malloc() implementation for pre-relocation · d59476b6
      Simon Glass 提交于
      If we are to have driver model before relocation we need to support some
      way of calling memory allocation routines.
      
      The standard malloc() is pretty complicated:
      
      1. It uses some BSS memory for its state, and BSS is not available before
      relocation
      
      2. It supports algorithms for reducing memory fragmentation and improving
      performace of free(). Before relocation we could happily just not support
      free().
      
      3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
      this has been loaded anyway this is not really a problem.
      
      The simplest way to support pre-relocation malloc() is to reserve an area
      of memory and allocate it in increasing blocks as needed. This
      implementation does this.
      
      To enable it, you need to define the size of the malloc() pool as described
      in the README. It will be located above the pre-relocation stack on
      supported architectures.
      
      Note that this implementation is only useful on machines which have some
      memory available before dram_init() is called - this includes those that
      do no DRAM init (like tegra) and those that do it in SPL (quite a few
      boards). Enabling driver model preior to relocation for the rest of the
      boards is left for a later exercise.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      d59476b6
  3. 08 7月, 2014 4 次提交
  4. 03 7月, 2014 1 次提交
  5. 21 6月, 2014 2 次提交
    • S
      dm: Update README to encourage conversion to driver model · 2eb31b13
      Simon Glass 提交于
      Add a note to encourage people to convert drivers to use driver model.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      2eb31b13
    • S
      Add an I/O tracing feature · aa53233a
      Simon Glass 提交于
      When debugging drivers it is useful to see what I/O accesses were done
      and in what order.
      
      Even if the individual accesses are of little interest it can be useful to
      verify that the access pattern is consistent each time an operation is
      performed. In this case a checksum can be used to characterise the operation
      of a driver. The checksum can be compared across different runs of the
      operation to verify that the driver is working properly.
      
      In particular, when performing major refactoring of the driver, where the
      access pattern should not change, the checksum provides assurance that the
      refactoring work has not broken the driver.
      
      Add an I/O tracing feature and associated commands to provide this facility.
      It works by sneaking into the io.h heder for an architecture and redirecting
      I/O accesses through its tracing mechanism.
      
      For now no commands are provided to examine the trace buffer. The format is
      fairly simple, so 'md' is a reasonable substitute.
      
      Note: The checksum feature is only useful for I/O regions where the contents
      do not change outside of software control. Where this is not suitable you can
      fall back to manually comparing the addresses. It might be useful to enhance
      tracing to only checksum the accesses and not the data read/written.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      aa53233a
  6. 06 6月, 2014 2 次提交
  7. 02 6月, 2014 1 次提交
    • S
      usb: hub: remove CONFIG_USB_HUB_MIN_POWER_ON_DELAY · 77b83e6d
      Stephen Warren 提交于
      Now that we wait the correct specification-mandated time at the end of
      usb_hub_power_on(), I suspect that CONFIG_USB_HUB_MIN_POWER_ON_DELAY has
      no purpose.
      
      For cm_t35.h, we already wait longer than the original MIN_POWER_ON_DELAY,
      so this change is safe.
      
      For gw_ventana.h, we will wait as long as the original MIN_POWER_ON_DELAY
      iff pgood_delay was at least 200ms. I'm not sure if this is the case or
      not, hence I've CC'd relevant people to test this change.
      
      Cc: Igor Grinberg <grinberg@compulab.co.il>
      Cc: Tim Harvey <tharvey@gateworks.com>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      77b83e6d
  8. 31 5月, 2014 1 次提交
  9. 23 5月, 2014 1 次提交
    • P
      eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command · 1fd93c6e
      Pierre Aubert 提交于
      This sub-command adds support for the RPMB partition of an eMMC:
      * mmc rpmb key <address of the authentication key>
        Programs the authentication key in the eMMC This key can not
        be overwritten.
      * mmc rpmb read <address> <block> <#count> [address of key]
        Reads <#count> blocks of 256 bytes in the RPMB partition
        beginning at block number <block>. If the optionnal
        address of the authentication key is provided, the
        Message Authentication Code (MAC) is verified on each
        block.
      * mmc rpmb write <address> <block> <#count> <address of key>
        Writes <#count> blocks of 256 bytes in the RPMB partition
        beginning at block number <block>. The datas are signed
        with the key provided.
      * mmc rpmb counter
        Returns the 'Write counter' of the RPMB partition.
      
      The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB
      Acked-by: NPantelis Antoniou <panto@antoniou-consulting.com>
      Signed-off-by: NPierre Aubert <p.aubert@staubli.com>
      CC: Wolfgang Denk <wd@denx.de>
      1fd93c6e
  10. 20 5月, 2014 2 次提交
  11. 13 5月, 2014 2 次提交
  12. 10 5月, 2014 1 次提交
  13. 08 5月, 2014 1 次提交
    • S
      usb/gadget: add the fastboot gadget · 3aab70af
      Sebastian Siewior 提交于
      This patch contains an implementation of the fastboot protocol on the
      device side and documentation. This is based on USB download gadget
      infrastructure. The fastboot function implements the getvar, reboot,
      download and reboot commands. What is missing is the flash handling i.e.
      writting the image to media.
      
      v3 (Rob Herring):
      This is based on http://patchwork.ozlabs.org/patch/126798/ with the
      following changes:
      - Rebase to current mainline and updates for current gadget API
      - Use SPDX identifiers for licenses
      - Traced the history and added missing copyright to cmd_fastboot.c
      - Use load_addr/load_size for transfer buffer
      - Allow vendor strings to be optional
      - Set vendor/product ID from config defines
      - Allow Ctrl-C to exit fastboot mode
      v4:
      - Major re-write to use the USB download gadget. Consolidated function
      code to a single file.
      - Moved globals into single struct.
      - Use puts and putc as appropriate.
      - Added CONFIG_USB_FASTBOOT_BUF_ADDR and CONFIG_USB_FASTBOOT_BUF_SIZE to
      set the fastboot transfer buffer.
      v5:
      - Add CONFIG option documentation to README
      - Rebase using new downloader registration
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NRob Herring <robh@kernel.org>
      3aab70af
  14. 05 5月, 2014 1 次提交
    • M
      usb: dfu: fix boards wo USB cable detection · 75504e95
      Mateusz Zalega 提交于
      Former usb_cable_connected() patch broke compilation of boards which do
      not support this feature.
      
      I've renamed usb_cable_connected() to g_dnl_usb_cable_connected() and added
      its default implementation to gadget downloader driver code. There's
      only one driver of this kind and it's unlikely there'll be another, so
      there's no point in keeping it in /common.
      
      Previously this function was declared in usb.h. I've moved it, since
      it's more appropriate to keep it in g_dnl.h - usb.h seems to be intended
      for USB host implementation.
      
      Existing code, confronted with default -EOPNOTSUPP return value,
      continues as if the cable was connected.
      
      CONFIG_USB_CABLE_CHECK was removed.
      
      Change-Id: Ib9198621adee2811b391c64512f14646cefd0369
      Signed-off-by: NMateusz Zalega <m.zalega@samsung.com>
      Acked-by: NMarek Vasut <marex@denx.de>
      Acked-by: NLukasz Majewski <l.majewski@samsung.com>
      75504e95
  15. 23 4月, 2014 6 次提交
  16. 20 4月, 2014 2 次提交
  17. 18 4月, 2014 3 次提交
  18. 08 4月, 2014 2 次提交
  19. 03 4月, 2014 1 次提交
    • P
      new commands: uuid and guid - generate random unique identifier · 89c8230d
      Przemyslaw Marczak 提交于
      Those commands basis on implementation of random UUID generator version 4
      which is described in RFC4122. The same algorithm is used for generation
      both ids but string representation is different as below.
      
      char:  0        9    14   19   24         36
             xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      UUID:     be     be   be   be       be
      GUID:     le     le   le   be       be
      
      Commands usage:
      - uuid [<varname>]
      - guid [<varname>]
      
      The result is saved in environment as a "varname" variable if argument is given,
      if not then it is printed.
      
      New config:
      - CONFIG_CMD_UUID
      Signed-off-by: NPrzemyslaw Marczak <p.marczak@samsung.com>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: trini@ti.com
      89c8230d
  20. 23 3月, 2014 1 次提交
    • H
      usb: dfu: introduce dfuMANIFEST state · 001a8319
      Heiko Schocher 提交于
      on nand flash using ubi, after the download of the new image into
      the flash, the "rest" of the nand sectors get erased while flushing
      the medium. With current u-boot version dfu-util may show:
      
      Starting download: [##################################################] finished!
      state(7) = dfuMANIFEST, status(0) = No error condition is present
      unable to read DFU status
      
      as get_status is not answered while erasing sectors, if erasing
      needs some time.
      
      So do the following changes to prevent this:
      
      - introduce dfuManifest state
        According to dfu specification
        ( http://www.usb.org/developers/devclass_docs/usbdfu10.pdf ) section 7:
        "the device enters the dfuMANIFEST-SYNC state and awaits the solicitation
         of the status report by the host. Upon receipt of the anticipated
         DFU_GETSTATUS, the device enters the dfuMANIFEST state, where it
         completes its reprogramming operations."
      
      - when stepping into dfuManifest state, sending a PollTimeout
        DFU_MANIFEST_POLL_TIMEOUT in ms, to the host, so the host
        (dfu-util) waits the PollTimeout before sending a get_status again.
      Signed-off-by: NHeiko Schocher <hs@denx.de>
      Cc: Lukasz Majewski <l.majewski@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marek Vasut <marex@denx.de>
      Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
      001a8319
  21. 22 3月, 2014 1 次提交
  22. 05 3月, 2014 1 次提交
  23. 27 2月, 2014 1 次提交
    • T
      arm: Switch to -mno-unaligned-access when supported by the compiler · 1551df35
      Tom Rini 提交于
      When we tell the compiler to optimize for ARMv7 (and ARMv6 for that
      matter) it assumes a default of SCTRL.A being cleared and unaligned
      accesses being allowed and fast at the hardware level.  We set this bit
      and must pass along -mno-unaligned-access so that the compiler will
      still breakdown accesses and not trigger a data abort.
      
      To better help understand the requirements of the project with respect
      to unaligned memory access, the
      Documentation/unaligned-memory-access.txt file has been added as
      doc/README.unaligned-memory-access.txt and is taken from the v3.14-rc1
      tag of the kernel.
      
      Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
      Cc: Mans Rullgard <mans@mansr.com>
      Signed-off-by: NTom Rini <trini@ti.com>
      1551df35