1. 05 7月, 2016 1 次提交
    • O
      powerpc/boot: Add OPAL console to epapr wrappers · 656ad58e
      Oliver O'Halloran 提交于
      This patch adds an OPAL console backend to the powerpc boot wrapper so
      that decompression failures inside the wrapper can be reported to the
      user. This is important since it typically indicates data corruption in
      the firmware and other nasty things.
      
      Currently this only works when building a little endian kernel. When
      compiling a 64 bit BE kernel the wrapper is always build 32 bit to be
      compatible with some 32 bit firmwares. BE support will be added at a
      later date. Another limitation of this is that only the "raw" type of
      OPAL console is supported, however machines that provide a hvsi console
      also provide a raw console so this is not an issue in practice.
      Actually-written-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NOliver O'Halloran <oohall@gmail.com>
      [mpe: Move #ifdef __powerpc64__ to avoid warnings on 32-bit]
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      656ad58e
  2. 10 11月, 2014 1 次提交
  3. 28 4月, 2014 2 次提交
  4. 22 10月, 2008 1 次提交
  5. 17 4月, 2008 1 次提交
  6. 28 1月, 2008 1 次提交
  7. 24 1月, 2008 1 次提交
  8. 11 12月, 2007 2 次提交
  9. 03 10月, 2007 2 次提交
  10. 22 9月, 2007 1 次提交
  11. 13 9月, 2007 1 次提交
  12. 22 8月, 2007 6 次提交
  13. 28 6月, 2007 2 次提交
  14. 12 5月, 2007 1 次提交
  15. 30 4月, 2007 1 次提交
  16. 24 4月, 2007 1 次提交
  17. 13 4月, 2007 4 次提交
  18. 26 3月, 2007 2 次提交
  19. 21 3月, 2007 3 次提交
  20. 13 3月, 2007 3 次提交
    • S
      [POWERPC] bootwrapper: Add stddef.h to ops.h · ce3edb30
      Scott Wood 提交于
      ops.h references NULL, so include stddef.h, so files including ops.h
      don't have to.
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Acked-by: NMark A. Greer <mgreer@mvista.com>
      Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ce3edb30
    • D
      [POWERPC] zImage: Cleanup and improve zImage entry point · cd197ffc
      David Gibson 提交于
      This patch re-organises the way the zImage wrapper code is entered, to
      allow more flexibility on platforms with unusual entry conditions.
      After this patch, a platform .o file has two options:
      
      1) It can define a _zimage_start, in which case the platform code gets
         control from the very beginning of execution.  In this case the
         platform code is responsible for relocating the zImage if necessary,
         clearing the BSS, performing any platform specific initialization, and
         finally calling start() to load and enter the kernel.
      
      2) It can define platform_init().  In this case the generic crt0.S
         handles initial entry, and calls platform_init() before calling
         start().  The signature of platform_init() is changed, however, to
         take up to 5 parameters (in r3..r7) as they come from the platform's
         initial loader, instead of a fixed set of parameters based on OF's
         usage.
      
         When using the generic crt0.S, the platform .o can optionally
         supply a custom stack to use, using the BSS_STACK() macro.  If this
         is not supplied, the crt0.S will assume that the loader has
         supplied a usable stack.
      
      In either case, the platform code communicates information to the
      generic code (specifically, a PROM pointer for OF systems, and/or an
      initrd image address supplied by the bootloader) via a global
      structure "loader_info".
      
      In addition the wrapper script is rearranged to ensure that the
      platform .o is always linked first.  This means that platforms where
      the zImage entry point is at a fixed address or offset, rather than
      being encoded in the binary header can be supported using option (1).
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cd197ffc
    • D
      [POWERPC] zImage: Cleanup and improve prep_kernel() · 79c85419
      David Gibson 提交于
      This patch rewrites prep_kernel() in the zImage wrapper code to be
      clearer and more flexible.  Notable changes:
      
      	- Handling of the initrd image from prep_kernel() has moved
      into a new prep_initrd() function.
      	- The address of the initrd image is now added as device tree
      properties, as the kernel expects.
      	- We only copy a packaged initrd image to a new location if it
      is in danger of being clobbered when the kernel moves to its final
      location, instead of always.
      	- By default we decompress the kernel directly to address 0,
      instead of requiring it to relocate itself.  Platforms (such as OF)
      where doing this could clobber still-live firmware data structures can
      override the vmlinux_alloc hook to provide an alternate place to
      decompress the kernel.
      	- We no longer pass lots of information between functions in
      global variables.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      79c85419
  21. 04 12月, 2006 1 次提交
    • D
      [POWERPC] Cleanup zImage handling of kernel entry with flat device tree · 35af89eb
      David Gibson 提交于
      This makes 2 changes to clean up the flat device tree handling
      logic in the zImage wrapper.
      
      First, there were two callbacks from the dt_ops structure used for
      producing a final flat tree to pass to the kerne: dt_ops.ft_pack()
      which packed the flat tree (possibly a no-op) and dt_ops.ft_addr()
      which retreived the address of the final blob.  Since they were only
      ever called together, this patch combines the two into a single new
      callback, dt_ops.finalize().  This new callback does whatever
      platform-dependent things are necessary to produce a final flat device
      tree blob, and returns the blob's addres.
      
      Second, the current logic calls the kernel with a flat device tree if
      one is build into the zImage wrapper, otherwise it boots the kernel
      with a PROM pointer, expecting the kernel to copy the OF device tree
      itself.  This approach precludes the possibility of the platform
      wrapper code building a flat device tree from whatever
      platform-specific information firmware provides.  Thus, this patch
      takes the more sensible approach of invoking the kernel with a flat
      tree if the dt_ops.finalize callback provides one (by whatever means).
      
      So, the dt_ops.finalize callback can be NULL, or can be a function
      which returns NULL.  In either case, the zImage wrapper logic assumes
      that this is a platform with OF and invokes the kernel accordingly.
      Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      35af89eb
  22. 18 10月, 2006 1 次提交
  23. 20 9月, 2006 1 次提交