1. 02 Sep, 2012 3 commits
  2. 01 Sep, 2012 1 commit
  3. 12 Jul, 2012 1 commit
  4. 09 Jul, 2012 1 commit
  5. 06 Jul, 2012 1 commit
  6. 23 May, 2012 2 commits
  7. 15 May, 2012 1 commit
  8. 25 Apr, 2012 2 commits
    • Liu Gang's avatar
      powerpc/corenet_ds: Slave reads ENV from master when boot from SRIO · 0a85a9e7
      Liu Gang authored
      When boot from SRIO, slave's ENV can be stored in master's memory space,
      then slave can fetch the ENV through SRIO interface.
      NOTE: Because the slave can not erase, write master's NOR flash by SRIO
      	  interface, so it can not modify the ENV parameters stored in
      	  master's NOR flash using "saveenv" or other commands.
      Master needs to:
      	1. Put the slave's ENV into it's own memory space.
      	2. Set an inbound SRIO window covered slave's ENV stored in master's
      	   memory space.
      Slave needs to:
      	1. Set a specific TLB entry in order to fetch ucode and ENV from master.
      	2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV.
      Signed-off-by: default avatarLiu Gang <Gang.Liu@freescale.com>
      Signed-off-by: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
    • Liu Gang's avatar
      powerpc/corenet_ds: Slave module for boot from SRIO · 292dc6c5
      Liu Gang authored
      For the powerpc processors with SRIO interface, boot location can be configured
      from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
      for u-boot image. The image can be fetched from another processor's memory
      space by SRIO link connected between them.
      The processor boots from SRIO is slave, the processor boots from normal flash
      memory space and can help slave to boot from its memory space is master.
      They are different environments and requirements:
      	1. NOR flash for its own u-boot image, ucode and ENV space.
      	2. Slave's u-boot image in master NOR flash.
      	3. Normally boot from local NOR flash.
      	4. Configure SRIO switch system if needed.
      	1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
      	2. Boot location should be set to SRIO1 or SRIO2 by RCW.
      	3. RCW should configure the SerDes, SRIO interfaces correctly.
      	4. Slave must be powered on after master's boot.
      	5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
      For the slave module, need to finish these processes:
      	1. Set the boot location to SRIO1 or SRIO2 by RCW.
          2. Set a specific TLB entry for the boot process.
      	3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
      	4. Slave's u-boot image should be generated specifically by
      	   make xxxx_SRIOBOOT_SLAVE_config.
      	   This will set SYS_TEXT_BASE=0xFFF80000 and other configurations.
      Signed-off-by: default avatarLiu Gang <Gang.Liu@freescale.com>
      Signed-off-by: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
  9. 19 Apr, 2012 1 commit
  10. 11 Apr, 2012 1 commit
  11. 02 Apr, 2012 1 commit
    • Daniel Schwierzeck's avatar
      MIPS: fix endianess handling · 6cb461b4
      Daniel Schwierzeck authored and Marek Vasut's avatar Marek Vasut committed
      Make endianess of target CPU configurable. Use the new config
      option for dbau1550_el and pb1000 boards.
      Adapt linking of standalone applications to pass through
      endianess options to LD.
      Build tested with:
       - ELDK 4 mips_4KC- and mips4KCle
       - Sourcery CodeBench Lite 2011.03-93
      With this patch all 26 MIPS boards can be compiled now in one step by
      running "MAKEALL -a mips".
      Signed-off-by: Daniel Schwierzeck's avatarDaniel Schwierzeck <daniel.schwierzeck@googlemail.com>
  12. 30 Mar, 2012 2 commits
    • Marek Vasut's avatar
      BOOT: Add RAW ramdisk support to bootz · 017e1f3f
      Marek Vasut authored and Wolfgang Denk's avatar Wolfgang Denk committed
      This patch allows loading RAW ramdisk via bootz command. The raw ramdisk is
      loaded only in case it's size is specified:
        bootz <kernel addr> <ramdisk addr>:<ramdisk size> <fdt addr>
      For example:
        bootz 0x42000000 0x43000000:0x12345 0x44000000
      Signed-off-by: Marek Vasut's avatarMarek Vasut <marex@denx.de>
      Signed-off-by: default avatarRob Herring <rob.herring@calxeda.com>
      Cc: Tom Warren <TWarren@nvidia.com>
      Cc: albert.u.boot@aribaud.net
      Cc: afleming@gmail.com
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Detlev Zundel <dzu@denx.de>
    • Marek Vasut's avatar
      BOOT: Add "bootz" command to boot Linux zImage on ARM · 44f074c7
      Marek Vasut authored and Wolfgang Denk's avatar Wolfgang Denk committed
      This command boots Linux zImage from where the zImage is loaded to. Passing
      initrd and fdt is supported.
      Tested on i.MX28 based DENX M28EVK
      Tested on PXA270 based Voipac PXA270.
      NOTE: This currently only supports ARM, but other architectures can be easily
      added by defining bootz_setup().
      Signed-off-by: default avatarMarek Vasut <marek.vasut@gmail.com>
      Cc: Tom Warren <TWarren@nvidia.com>
      Cc: albert.u.boot@aribaud.net
      Cc: afleming@gmail.com,
      Cc: Simon Glass <sjg@chromium.org>,
      Cc: Stephen Warren <swarren@nvidia.com>
      Cc: Nicolas Pitre <nico@fluxnic.net>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Detlev Zundel <dzu@denx.de>
  13. 29 Mar, 2012 1 commit
  14. 28 Mar, 2012 1 commit
    • Vipin KUMAR's avatar
      Enable high speed support for USB device framework and usbtty · f9da0f89
      Vipin KUMAR authored
      This patch adds the support for high speed in usb device framework and usbtty
      driver. This feature has been kept within a macro CONFIG_USBD_HS, so the board
      configuration files have to define this macro to enable high speed support.
      Along with that specific peripheral drivers also need to define a function to
      let the framework know that the enumeration has happened at high speed.
      This function prototype is "int is_usbd_high_speed(void)"
      Signed-off-by: default avatarVipin Kumar <vipin.kumar@st.com>
      Signed-off-by: default avatarAmit Virdi <amit.virdi@st.com>
  15. 26 Mar, 2012 2 commits
  16. 23 Mar, 2012 1 commit
  17. 18 Mar, 2012 1 commit
    • Simon Glass's avatar
      bootstage: Implement core microsecond boot time measurement · 3a608ca0
      Simon Glass authored and Wolfgang Denk's avatar Wolfgang Denk committed
      This defines the basics of a new boot time measurement feature. This allows
      logging of very accurate time measurements as the boot proceeds, by using
      an available microsecond counter.
      To enable the feature, define CONFIG_BOOTSTAGE in your board config file.
      Also available is CONFIG_BOOTSTAGE_REPORT which will cause a report to be
      printed just before handing off to the OS.
      Most IDs are not named at this stage. For that I would first like to
      renumber them all.
      Timer summary in microseconds:
             Mark    Elapsed  Stage
                0          0  reset
          205,000    205,000  board_init_f
        6,053,000  5,848,000  bootm_start
        6,053,000          0  id=1
        6,058,000      5,000  id=101
        6,058,000          0  id=100
        6,061,000      3,000  id=103
        6,064,000      3,000  id=104
        6,093,000     29,000  id=107
        6,093,000          0  id=106
        6,093,000          0  id=105
        6,093,000          0  id=108
        7,089,000    996,000  id=7
        7,089,000          0  id=15
        7,089,000          0  id=8
        7,097,000      8,000  start_kernel
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  18. 27 Feb, 2012 1 commit
    • Shawn Guo's avatar
      common/image.c: align usage of fdt_high with initrd_high · fa34f6b2
      Shawn Guo authored
      The commit message of a28afca5
       (Add uboot "fdt_high" enviroment variable)
      states that fdt_high behaves similarly to the existing initrd_high.
      But fdt_high actually has an outstanding difference from initrd_high.
      The former specifies the start address, while the later specifies the
      end address.
      As fdt_high and initrd_high will likely be used together, it'd be nice
      to have them behave same.  The patch changes the behavior of fdt_high
      to have it aligned with initrd_high.
      The document of fdt_high in README is updated with an example to
      demonstrate the usage of this environment variable.
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Acked-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
  19. 12 Feb, 2012 2 commits
  20. 19 Jan, 2012 1 commit
  21. 05 Jan, 2012 1 commit
  22. 17 Dec, 2011 1 commit
    • Sonny Rao's avatar
      Add safe vsnprintf and snprintf library functions · 046a37bd
      Sonny Rao authored and Wolfgang Denk's avatar Wolfgang Denk committed
      From: Sonny Rao <sonnyrao@chromium.org>
      These functions are useful in U-Boot because they allow a graceful failure
      rather than an unpredictable stack overflow when printf() buffers are
      Mostly copied from the Linux kernel. I copied vscnprintf and
      scnprintf so we can change printf and vprintf to use the safe
      implementation but still return the correct values.
      (Simon Glass <sjg@chromium.org> modified this commit a little)
      Signed-off-by: default avatarSonny Rao <sonnyrao@chromium.org>
  23. 16 Dec, 2011 1 commit
  24. 09 Dec, 2011 1 commit
    • Simon Glass's avatar
      Add board_pre_console_putc to deal with early console output · 295d3942
      Simon Glass authored and Stefano Babic's avatar Stefano Babic committed
      This patch adds support for console output before the console is inited.
      The main purpose of this is to deal with a very early panic() which would
      otherwise cause a silent hang.
      A new board_pre_console_putc() function is added to the board API. If
      provided by the board it will be called in the event of console output
      before the console is ready. This function should turn on all UARTs and
      spray the character out if it possibly can.
      The feature is controlled by a new CONFIG_PRE_CONSOLE_PUTC option.
      Signed-off-by: Simon Glass's avatarSimon Glass <sjg@chromium.org>
      Acked-by: default avatarGraeme Russ <graeme.russ@gmail.com>
  25. 08 Dec, 2011 1 commit
  26. 07 Dec, 2011 1 commit
    • Vadim Bendebury's avatar
      Introduce generic TPM support in u-boot · 5e124724
      Vadim Bendebury authored and Wolfgang Denk's avatar Wolfgang Denk committed
      TPM (Trusted Platform Module) is an integrated circuit and
      software platform that provides computer manufacturers with the
      core components of a subsystem used to assure authenticity,
      integrity and confidentiality.
      This driver supports version 1.2 of the TCG (Trusted Computing
      Group) specifications.
      The TCG specification defines several so called localities in a
      TPM chip, to be controlled by different software layers. When
      used on a typical x86 platform during the firmware phase, only
      locality 0 can be accessed by the CPU, so this driver even while
      supporting the locality concept presumes that only locality zero
      is used.
      This implementation is loosely based on the article "Writing a
      TPM Device Driver" published on http://ptgmedia.pearsoncmg.com
      Compiling this driver with DEBUG defined will generate trace of
      all accesses to TMP registers.
      This driver has been tested and is being used in three different
      functional ChromeOS machines (Pinetrail and Sandy Bridge Intel
      chipsets) all using the same Infineon SLB 9635 TT 1.2 device.
      A u-boot cli command allowing access to the TPM was also
      implemented and is being submitted as a second patch.
      Change-Id: I22a33c3e5b2e20eec9557a7621bd463b30389d73
      Signed-off-by: default avatarVadim Bendebury <vbendeb@chromium.org>
      CC: Wolfgang Denk <wd@denx.de>
  27. 29 Nov, 2011 1 commit
    • Timur Tabi's avatar
      powerpc/85xx: clean up and document the QE/FMAN microcode macros · f2717b47
      Timur Tabi authored
      Several macros are used to identify and locate the microcode binary image
      that U-boot needs to upload to the QE or Fman.  Both the QE and the Fman
      use the QE Firmware binary format to package their respective microcode data,
      which is why the same macros are used for both.  A given SOC will only have
      a QE or an Fman, so this is safe.
      Unfortunately, the current macro definition and usage has inconsistencies.
      For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman
      firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address
      of NAND.  There's no way to know by looking at a variable how it's supposed
      to be used.
      In the future, the code which uploads QE firmware and Fman firmware will
      be merged.
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
  28. 15 Nov, 2011 1 commit
    • Heiko Schocher's avatar
      arm, davinci_emac: fix driver bug if more then 3 PHYs are detected · dc02bada
      Heiko Schocher authored
      since commits:
      davinci: emac: add support for more than 1 PHYs
      davinci: remove obsolete macro CONFIG_EMAC_MDIO_PHY_NUM
      I get following warning on the enbw_cmc board:
      Err:   serial
      Net:    5 ETH PHY detected
      miiphy_register: non unique device name 'KSZ8873 @ 0x01'
      Hit any key to stop autoboot:  0
      Also I see some debug printfs:
      => run load
      + emac_close
      + emac_ch_teardown
      - emac_ch_teardown
      + emac_ch_teardown
      - emac_ch_teardown
      - emac_close
      + emac_open
      - emac_open
      Using DaVinci-EMAC device
      reason is 062fe7d3
       new define MAX_PHY.
      This is set to 3! I get on this board 5 active phys, so
      this leads in wrong memory writes ...
      so I changed:
        the MAX_PHY value, add a description in README
        for the new CONFIG_SYS option.
      - print an error message if more then MAX_PHYs are
      - fill the active_phy_addr array in a for loop with
      - changed printf() in debug_emac()
      Signed-off-by: Heiko Schocher's avatarHeiko Schocher <hs@denx.de>
      Cc: Sandeep Paulraj <s-paulraj@ti.com>
      Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Manjunath Hadli <manjunath.hadli@ti.com>
      Cc: Prabhakar Lad <prabhakar.csengg@gmail.com>
      Cc: Mike Frysinger <vapier@gentoo.org>
      Cc: Tom Rini <tom.rini@gmail.com>
      Signed-off-by: default avatarSandeep Paulraj <s-paulraj@ti.com>
  29. 04 Nov, 2011 1 commit
  30. 03 Nov, 2011 2 commits
  31. 27 Oct, 2011 2 commits
    • Kyle Moffett's avatar
      e1000: Allow direct access to the E1000 SPI EEPROM device · ce5207e1
      Kyle Moffett authored and Wolfgang Denk's avatar Wolfgang Denk committed
      As a part of the manufacturing process for some of our custom hardware,
      we are programming the EEPROMs attached to our Intel 82571EB controllers
      from software using U-Boot and Linux.
      This code provides several conditionally-compiled features to assist in
      our manufacturing process:
          This is a basic "e1000" command which allows querying the controller
          and (if other config options are set) performing EEPROM programming.
          In particular, with CONFIG_E1000_SPI this allows you to display a
          hex-dump of the EEPROM, copy to/from main memory, and verify/update
          the software checksum.
          Build a generic SPI driver providing the standard U-Boot SPI driver
          interface.  This allows commands such as "sspi" to access the bus
          attached to the E1000 controller.  Additionally, some E1000 chipsets
          can support user data in a reserved space in the E1000 EEPROM which
          could be used for U-Boot environment storage.
          The core SPI access code used by the above interfaces.
      For example, the following commands allow you to program the EEPROM from
      a USB device (assumes CONFIG_E1000_SPI and CONFIG_CMD_E1000 are enabled):
        usb start
        fatload usb 0 $loadaddr 82571EB_No_Mgmt_Discrete-LOM.bin
        e1000 0 spi program $loadaddr 0 1024
        e1000 0 spi checksum update
      Please keep in mind that the Intel-provided .eep files are organized as
      16-bit words.  When converting them to binary form for programming you
      must byteswap each 16-bit word so that it is in little-endian form.
      This means that when reading and writing words to the SPI EEPROM, the
      bit ordering for each word looks like this on the wire:
        Time >>>
        ... [7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8], ...
        (MSB is 15, LSB is 0).
      Signed-off-by: default avatarKyle Moffett <Kyle.D.Moffett@boeing.com>
      Cc: Ben Warren <biggerbadderben@gmail.com>
    • Helmut Raiger's avatar
      cosmetic: s/BOARD_LATE_INIT/CONFIG_BOARD_LATE_INIT · 9660e442
      Helmut Raiger authored and Wolfgang Denk's avatar Wolfgang Denk committed
      Along the way it removes some leftover
       #define BOARD_LATE_INIT		1
      and adds some basic documentation for board specific
      callbacks in README.
      Signed-off-by: default avatarHelmut Raiger <helmut.raiger@hale.at>
      Acked-by: Stefano Babic's avatarStefano Babic <sbabic@denx.de>