1. 30 Apr, 2012 27 commits
  2. 29 Apr, 2012 3 commits
    • Marek Vasut's avatar
      GCC47: Fix warning in md5.c · b68d63ce
      Marek Vasut authored
      
      
      md5.c: In function ‘MD5Final’:
      md5.c:156:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
      md5.c:157:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
      
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Wolfgang Denk <wd@denx.de>
      Acked-by: default avatarMike Frysinger <vapier@gentoo.org>
      b68d63ce
    • Marek Vasut's avatar
      GCC47: Fix warning in cmd_nand.c · f624dd15
      Marek Vasut authored
      
      
      cmd_nand.c: In function ‘arg_off_size’:
      cmd_nand.c:216:5: warning: ‘maxsize’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Scott Wood <scottwood@freescale.com>
      Cc: Wolfgang Denk <wd@denx.de>
      f624dd15
    • Wolfgang Denk's avatar
      Merge branch 'marex@denx.de' of git://git.denx.de/u-boot-staging · e654fac2
      Wolfgang Denk authored
      * 'marex@denx.de' of git://git.denx.de/u-boot-staging:
        CMD: CONFIG_CMD_SETECPR -> CONFIG_CMD_SETEXPR on omap3_logic
        CMD: Fix CONFIG_CMD_SAVEBP_WRITE_SIZE -> CONFIG_CMD_SPL_WRITE_SIZE
        CMD: Fix typo CMD_FSL -> CMD_MFSL in readme
        HWW1U1A: Fix CMD_SHA1 -> CMD_SHA1SUM
        CMD: Remove CMD_LOG, it's unused
        CMD: Fix typo KGBD -> KGDB on debris board
        CMD: Drop CONFIG_CMD_EMMC, it's not used
        CMD: Drop CONFIG_CMD_DFL, it's not used
        CMD: Drop CMD_DCR, it's not used
        CMD: Drop CMD_CAN, it's not used
        CMD: Remove CMD_AUTOSCRIPT, it's not used
        AT91: Drop AT91_SPIMUX command from cmd_all
      e654fac2
  3. 25 Apr, 2012 10 commits
    • Wolfgang Denk's avatar
      Prepare v2012.04.01 · 415d3868
      Wolfgang Denk authored
      
      
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      415d3868
    • Timur Tabi's avatar
      powerpc/85xx: don't touch MAS7 on e500v1 when relocating CCSR · 822ad60f
      Timur Tabi authored
      
      
      The CCSR relocation code in start.S writes to MAS7 on all e500 parts, but
      that register does not exist on e500v1.
      
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      822ad60f
    • Timur Tabi's avatar
      powerpc/85xx: don't display address map size (32-bit vs. 36-bit) during boot · 5d065c3e
      Timur Tabi authored
      
      
      Most 85xx boards can be built as a 32-bit or a 36-bit.  Current code sometimes
      displays which of these is actually built, but it's inconsistent.  This is
      especially problematic since the "default" build for a given 85xx board can
      be either one, so if you don't see a message, you can't always know which
      size is being used.  Not only that, but each board includes code that displays
      the message, so there is duplication.
      
      The 'bdinfo' command has been updated to display this information, so
      we don't need to display it at boot time.  The board-specific code is
      deleted.
      
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      5d065c3e
    • Timur Tabi's avatar
      cmd_bdinfo: display the address map size (32-bit vs. 36-bit) · 34e210f5
      Timur Tabi authored
      
      
      Some Freescale SOCs support 32-bit and 36-bit physical addressing, and
      U-Boot must be built to enable one or the other.  Add this information
      to the bdinfo command.
      
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
      34e210f5
    • Jerry Huang's avatar
      PowerPC: correct the SATA for p1/p2 rdb-pc platform · befb7d9f
      Jerry Huang authored
      
      
      For p1/p2 rdb-pc platform, use the PCIe-SATA Silicon Image SATA controller.
      Therefore, the SATA driver will use sata_sil, instead sata_sil3114.
      
      Signed-off-by: default avatarJerry Huang <Chang-Ming.Huang@freescale.com>
      CC: Andy Fleming <afleming@gmail.com>
      befb7d9f
    • Liu Gang's avatar
      powerpc/corenet_ds: Slave core in holdoff when boot from SRIO · 5056c8e0
      Liu Gang authored
      
      
      When boot from SRIO, slave's core can be in holdoff after powered on for
      some specific requirements. Master can release the slave's core at the
      right time by SRIO interface.
      
      Master needs to:
      	1. Set outbound SRIO windows in order to configure slave's registers
      	   for the core's releasing.
      	2. Check the SRIO port status when release slave core, if no errors,
      	   will implement the process of the slave core's releasing.
      Slave needs to:
      	1. Set all the cores in holdoff by RCW.
      	2. Be powered on before master's boot.
      
      Signed-off-by: default avatarLiu Gang <Gang.Liu@freescale.com>
      Signed-off-by: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
      5056c8e0
    • 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>
      0a85a9e7
    • Liu Gang's avatar
      powerpc/corenet_ds: Slave uploads ucode when boot from SRIO · 3f1af81b
      Liu Gang authored
      
      
      When boot from SRIO, slave's ucode can be stored in master's memory space,
      then slave can fetch the ucode image through SRIO interface. For the
      corenet platform, ucode is for Fman.
      
      Master needs to:
      	1. Put the slave's ucode image into it's own memory space.
      	2. Set an inbound SRIO window covered slave's ucode stored in master's
      	   memory space.
      Slave needs to:
      	1. Set a specific TLB entry in order to fetch ucode from master.
      	2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode.
      
      Signed-off-by: default avatarLiu Gang <Gang.Liu@freescale.com>
      Signed-off-by: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
      3f1af81b
    • 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:
      
      master:
      	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.
      slave:
      	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
      	   locally.
      
      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>
      292dc6c5
    • Liu Gang's avatar
      powerpc/corenet_ds: Master module for boot from SRIO · 5ffa88ec
      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:
      
      master:
      	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.
      slave:
      	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.
      
      For the master module, need to finish these processes:
      	1. Initialize the SRIO port and address space.
      	2. Set inbound SRIO windows covered slave's u-boot image stored in
      	   master's NOR flash.
      	3. Master's u-boot image should be generated specifically by
      	   make xxxx_SRIOBOOT_MASTER_config
      	4. Master must boot first, and then slave can be powered on.
      
      Signed-off-by: default avatarLiu Gang <Gang.Liu@freescale.com>
      Signed-off-by: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
      5ffa88ec