1. 03 Aug, 2015 2 commits
  2. 02 Aug, 2015 9 commits
  3. 30 Jul, 2015 1 commit
  4. 28 Jul, 2015 5 commits
  5. 27 Jul, 2015 5 commits
    • Antonio Borneo's avatar
      stm32f429: pass the device unique ID in DTB · 089fddfd
      Antonio Borneo authored
      
      
      Read device unique ID and set environment variable "serial#".
      Value would then be passed to kernel through DTB.
      
      To read ID from DTB, kernel is required to have commit:
      3f599875e5202986b350618a617527ab441bf206 (ARM: 8355/1: arch: Show
      the serial number from devicetree in cpuinfo)
      This commit is already mainline since v4.1-rc1.
      Signed-off-by: default avatarAntonio Borneo <borneo.antonio@gmail.com>
      To: Albert Aribaud <albert.u.boot@aribaud.net>
      To: Tom Rini <trini@konsulko.com>
      To: Kamil Lulko <rev13@wp.pl>
      Cc: u-boot@lists.denx.de
      089fddfd
    • Paul Kocialkowski's avatar
      omap3: Definitions for SYS_BOOT-based fallback boot device selection · cfac3756
      Paul Kocialkowski authored
      
      
      This introduces code to read the value of the SYS_BOOT pins on the OMAP3, as
      well as the memory-preferred scheme for the interpretation of each value.
      Signed-off-by: default avatarPaul Kocialkowski <contact@paulk.fr>
      cfac3756
    • Paul Kocialkowski's avatar
      omap-common: SYS_BOOT-based fallback boot device selection for peripheral boot · ed19bdae
      Paul Kocialkowski authored
      
      
      OMAP devices might boot from peripheral devices, such as UART or USB.
      When that happens, the U-Boot SPL tries to boot the next stage (complete U-Boot)
      from that peripheral device, but in most cases, this is not a valid boot device.
      
      This introduces a fallback option that reads the SYS_BOOT pins, that are used by
      the bootrom to determine which device to boot from. It is intended for the
      SYS_BOOT value to be interpreted in the memory-preferred scheme, so that the
      U-Boot SPL can load the next stage from a valid location.
      
      Practically, this options allows loading the U-Boot SPL through USB and have it
      load the next stage according to the memory device selected by SYS_BOOT instead
      of stalling.
      Signed-off-by: default avatarPaul Kocialkowski <contact@paulk.fr>
      ed19bdae
    • Paul Kocialkowski's avatar
      omap: SPL boot devices cleanup and completion · 62c5674e
      Paul Kocialkowski authored
      
      
      This cleans up the SPL boot devices for omap platforms and introduces support
      for missing boot devices.
      Signed-off-by: default avatarPaul Kocialkowski <contact@paulk.fr>
      62c5674e
    • Paul Kocialkowski's avatar
      omap-common: Common boot code OMAP3 support and cleanup · 60c7c30a
      Paul Kocialkowski authored
      
      
      This introduces OMAP3 support for the common omap boot code, as well as a
      major cleanup of the common omap boot code.
      
      First, the omap_boot_parameters structure becomes platform-specific, since its
      definition differs a bit across omap platforms. The offsets are removed as well
      since it is U-Boot's coding style to use structures for mapping such kind of
      data (in the sense that it is similar to registers). It is correct to assume
      that romcode structure encoding is the same as U-Boot, given the description
      of these structures in the TRMs.
      
      The original address provided by the bootrom is passed to the U-Boot binary
      instead of a duplicate of the structure stored in global data. This allows to
      have only the relevant (boot device and mode) information stored in global data.
      It is also expected that the address where the bootrom stores that information
      is not overridden by the U-Boot SPL or U-Boot.
      
      The save_omap_boot_params is expected to handle all special cases where the data
      provided by the bootrom cannot be used as-is, so that spl_boot_device and
      spl_boot_mode only return the data from global data.
      
      All of this is only relevant when the U-Boot SPL is used. In cases it is not,
      save_boot_params should fallback to its weak (or board-specific) definition.
      save_omap_boot_params should not be called in that context either.
      Signed-off-by: default avatarPaul Kocialkowski <contact@paulk.fr>
      60c7c30a
  6. 25 Jul, 2015 2 commits
  7. 24 Jul, 2015 1 commit
  8. 22 Jul, 2015 3 commits
  9. 20 Jul, 2015 8 commits
  10. 10 Jul, 2015 4 commits