1. 24 12月, 2007 4 次提交
  2. 20 12月, 2007 1 次提交
  3. 11 12月, 2007 2 次提交
  4. 06 12月, 2007 1 次提交
  5. 09 10月, 2007 1 次提交
  6. 05 10月, 2007 2 次提交
  7. 04 10月, 2007 1 次提交
  8. 03 10月, 2007 3 次提交
  9. 22 9月, 2007 1 次提交
  10. 20 9月, 2007 1 次提交
  11. 13 9月, 2007 1 次提交
  12. 07 9月, 2007 2 次提交
  13. 22 8月, 2007 3 次提交
  14. 20 8月, 2007 2 次提交
  15. 10 7月, 2007 2 次提交
    • T
      [POWERPC] Create a dummy zImage if no valid platform has been selected · 4bb09281
      Tony Breeds 提交于
      This simply prevents a build error if no platform is selected.
      Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4bb09281
    • G
      [POWERPC] PS3: Bootwrapper support. · bafdb645
      Geoff Levand 提交于
      Add support to build the PS3 flash rom image and remove some unneeded
      lmb calls.
      
      The PS3's lv1 loader supports loading gzipped binary images from flash
      rom to addr zero. The loader enters the image at addr 0x100.
      
      In this implementation a bootwrapper overlay is use to arrange for the
      kernel to be loaded to addr zero and to have a suitable bootwrapper
      entry at 0x100.  To construct the rom image, 0x100 bytes from offset
      0x100 in the kernel is copied to the bootwrapper symbol
      __system_reset_kernel.  The 0x100 bytes at the bootwrapper symbol
      __system_reset_overlay is then copied to offset 0x100.  At runtime the
      bootwrapper program copies the 0x100 bytes at __system_reset_kernel to
      addr 0x100.
      
      zImage.ps3 is a wrapped image that contains a flat device tree, an lv1
      compatible entry point, and an optional initrd.  otheros.bld is the gzip
      compresed rom image built from zImage.ps3.  otheros.bld is suitable for
      programming into the PS3 boot flash memory.
      Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      bafdb645
  16. 25 6月, 2007 3 次提交
  17. 14 6月, 2007 2 次提交
    • D
      [POWERPC] Consolidate cuboot initialization code · 85aecac8
      David Gibson 提交于
      The various cuboot platforms (i.e. pre-device tree aware u-boot for
      83xx, 85xx and Ebony) share a certain amount of code for parsing the
      boot parameters.  To a certain extent that's inevitable, since they
      platforms have different definitions of the bd_t structure.  However,
      with some macro work and a helper function, this patch improves the
      situation a bit.
      
      In the process, this fixes a bug on Ebony, which was incorrectly
      handling the parameters passed form u-boot for the command line (the
      bug was copied from 83xx and 85xx which have subsequently been fixed).
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      85aecac8
    • D
      [POWERPC] Split low-level OF-related bootloader code into separate files · 2e601613
      David Gibson 提交于
      Currently, all OF-related code in the bootloader is contained in of.c.
      of.c also provides the platform specific things necessary to boot on
      an OF platform.
      
      However, there are platforms (such as PReP) which can include an OF
      implementation, but are not bootable as pure OF systems.  For use by
      such platforms, this patch splits out the low-level parts of the OF
      code (call_prom() and various wrappers thereof) into a new oflib.c
      file.  In addition, the code related to bootwrapper console output via
      OF are moved to a new ofconsole.c file.  Both these files are included
      in the wrapper.a library where they can be used by both full-OF and
      partial OF platforms.
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      2e601613
  18. 02 6月, 2007 3 次提交
  19. 17 5月, 2007 3 次提交
  20. 12 5月, 2007 2 次提交
    • M
      [POWERPC] Add bootwrapper support for Motorola PrPMC2800 platform · c368d921
      Mark A. Greer 提交于
      The Motorola PrPMC280 and PrPMC2800 processor modules sit on an F101 or
      PrPMC2800 baseboard, respectively.  There are several variants of each
      type of processor module which can have different amounts of memory,
      amounts of FLASH, cpu frequencies, and an mv64360 or an mv64362.
      
      The bootwrapper code for that platform reads VPD from an I2C EEPROM
      to determine the processor module variant.  From the variant, the
      amount of memory, etc. is determined and the device tree is updated
      accordingly.  If the variant cannot be determined (e.g., corrupted
      VPD or a previously unknown variant), the property values already
      in the device tree are used.
      
      Also, the firmware for those platforms does not completely configure
      the mv64x60 host bridge so that configuration is done here.
      Signed-off-by: NMark A. Greer <mgreer@mvista.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      c368d921
    • M
      [POWERPC] Add bootwrapper support for Marvell/mv64x60 I2C · ae4b3fbc
      Mark A. Greer 提交于
      Some platforms support a variety processor modules with no method of
      determining which exact processor module is being used except by
      examining Vital Product Data (VPD).  The modules may have different
      amounts of memory, clock frequencies, etc. so reading the VPD becomes
      necessary to correctly set properties in the device tree before its
      passed to the kernel.
      
      Often the VPD is stored in I2C EEPROMs so an I2C driver becomes necessary.
      This I2C driver is for the I2C controller that's embedded on the Marvel
      mv64x60 line of host bridges.
      Signed-off-by: NMark A. Greer <mgreer@mvista.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ae4b3fbc