Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 20 8月, 2009 1 次提交
  3. 16 6月, 2009 1 次提交
  5. 11 3月, 2009 1 次提交
  7. 11 2月, 2009 1 次提交
  9. 31 10月, 2008 1 次提交
  11. 21 10月, 2008 1 次提交
    • P
      powerpc: Revert CHRP boot wrapper to real-base = 12MB on 32-bit · 0dcd4401
      由 Paul Mackerras 提交于 
      Commit 9b09c6d9 ("powerpc: Change the
default link address for pSeries zImage kernels") changed the
real-base value in the CHRP note added by addnote to the zImage from
12MB to 32MB.  It turns out that this causes unnecessary extra reboots
on old 32-bit CHRP machines.  This therefore adds a -r flag to addnote
to allow us to specify what real-base value it should put in the CHRP
note, and adjusts the wrapper script to pass -r c00000 to addnote when
making a zImage for a CHRP machine.  Also, CHRP machines ignore the
RPA note, so we don't need to arrange for it to be the same as the
kernel's.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      0dcd4401
  13. 10 10月, 2008 1 次提交
    • P
      powerpc: Sync RPA note in zImage with kernel's RPA note · 91a00302
      由 Paul Mackerras 提交于 
      Commit 9b09c6d9 ("powerpc: Change the
default link address for pSeries zImage kernels") changed the
real-base value in the CHRP note added by the addnote program from
12MB to 32MB to give more space for Open Firmware to load the zImage.
(The real-base value says where we want OF to position itself in
memory.)  However, this change was ineffective on most pSeries
machines, because the RPA note added by addnote has the "ignore me"
flag set to 1.  This was intended to tell OF to ignore just the RPA
note, but has the side effect of also making OF ignore the CHRP note
(at least on most pSeries machines).

To solve this we have to set the "ignore me" flag to 0 in the RPA
note.  (We can't just omit the RPA note because that is equivalent to
having an RPA note with default values, and the default values are not
what we want.)  However, then we have to make sure the values in the
zImage's RPA note match up with the values that the kernel supplies
later in prom_init.c with either the ibm,client-architecture-support
call or the process-elf-header call in prom_send_capabilities().

So this sets the "ignore me" flag in the RPA note in addnote to 0, and
adjusts the RPA note values in addnote.c and in prom_init.c to be
consistent with each other and with the values in ibm_architecture_vec.

However, since the wrapper is independent of the kernel, this doesn't
ensure that the notes will stay consistent.  To ensure that, this adds
code to addnote.c so that it can extract the kernel's RPA note from
the kernel binary and put that in the zImage.  To that end, we put the
kernel's fake ELF header (which contains the kernel's RPA note) into
its own section, and arrange for wrapper to pull out that section with
objcopy and pass it to addnote, which then extracts the RPA note from
it and transfers it to the zImage.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      91a00302
  15. 21 8月, 2008 1 次提交
  17. 04 7月, 2008 2 次提交
  19. 01 7月, 2008 1 次提交
  21. 10 6月, 2008 1 次提交
  23. 03 6月, 2008 1 次提交
  25. 17 4月, 2008 1 次提交
  27. 03 4月, 2008 1 次提交
  29. 01 4月, 2008 1 次提交
    • G
      [POWERPC] PS3: Bootwrapper improvements · 5761eaa3
      由 Geoff Levand 提交于 
      Improve the debugging support of the PS3 bootwraper code:

 o Increase the size of the PS3 bootwrapper overlay from 256 to 512 bytes to
   allow for more debugging code in the overlay.
 o Use the dot symbol to set the size of __system_reset_overlay.  The
   assembler will then emit an error if the overlay code is too big.
 o Remove some unused instructions.
 o Update the text describing the PS3 bootwrapper overlay.
 o Add a check for null pointer writes.
 o Change hcall return value from s64.
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5761eaa3
  31. 27 3月, 2008 1 次提交
  33. 20 3月, 2008 1 次提交
  35. 07 3月, 2008 1 次提交
  37. 07 2月, 2008 1 次提交
    • G
      [POWERPC] bootwrapper: Build multiple cuImages · 25431333
      由 Grant Likely 提交于 
      Currently, the kernel uses CONFIG_DEVICE_TREE to wrap a kernel image
with a fdt blob which means for any given configuration only one dts
file can be selected and so support for only one board can be built

This moves the selection of the default .dts file out of the kernel
config and into the bootwrapper makefile.  The makefile chooses which
images to build based on the kernel config and the dts source file
name is taken directly from the image name.  For example "cuImage.ebony"
will use "ebony.dts" as the device tree source file.

In addition, this patch allows a specific image to be requested from the
command line by adding "cuImage.%" and "treeImage.%" targets to the list
of valid built targets in arch/powerpc/Makefile.  This allows the default
dts selection to be overridden.

Another advantage to this change is it allows a single defconfig to be
supplied for all boards using the same chip family and only differing in
the device tree.

Important note: This patch adds two new zImage targets; zImage.dtb.% and
zImage.dtb.initrd.% for zImages with embedded dtb files.  Currently
there are 5 platforms which require this: ps3, ep405, mpc885ads, ep88xc,
adder875-redboot and ep8248e.  This patch *changes the zImage filenames*
for those platforms.  ie. 'zImage.ps3' is now 'zImage.dtb.ps3'.

This new zImage.dtb targets were added so that the .dts file could be
part of the dependancies list for building them.
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      25431333
  39. 24 1月, 2008 2 次提交
  41. 24 12月, 2007 1 次提交
  43. 20 12月, 2007 1 次提交
  45. 06 12月, 2007 3 次提交
  47. 08 11月, 2007 1 次提交
  49. 01 11月, 2007 2 次提交
  51. 05 10月, 2007 1 次提交
  53. 10 7月, 2007 1 次提交
    • 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
  55. 02 6月, 2007 1 次提交
  57. 08 5月, 2007 1 次提交
  59. 02 5月, 2007 1 次提交
  61. 24 4月, 2007 1 次提交
  63. 13 4月, 2007 1 次提交
  65. 21 3月, 2007 1 次提交
  67. 13 3月, 2007 1 次提交
    • 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
  69. 13 11月, 2006 1 次提交