Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 5月, 2007 3 次提交
  3. 12 5月, 2007 5 次提交
    • 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
    • M
      [POWERPC] Add bootwrapper support for Marvell MPSC · e12deb84
      由 Mark A. Greer 提交于 
      The bootwrapper requires a serial driver to allow cmdline editing
and information reporting on the console.  This driver is required
by platforms that boot a zImage and use the MPSC for the console.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e12deb84
    • M
      [POWERPC] Add bootwrapper support for Marvell/mv64x60 hostbridge · 0f81b11d
      由 Mark A. Greer 提交于 
      The mv64x60 host bridge has many windows between its various components
(cpu, system memory, ethernet ctlr, MPSC, DMA ctlr, PCI MEM, PCI I/O).
Unfortunately, the firmware on some of mv64x60-based platforms do not
properly or completely configure those windows (e.g., MPSC->system memory
windows not configured or CPU->PCI MEM space not configured).

So, the missing configuration needs to be done in either the bootwrapper
or in the kernel.  To keep the kernel as clean as possible, it is done
in the bootwrapper.  Note that I/O controller configuration is NOT being
done, its only the windows to allow the I/O controllers and other components
to access memory, etc. that is being done--drivers assume that their
controllers can already access system memory).

Table of routines and the windows they configure:
	mv64x60_config_ctlr_windows()	ENET->System Memory
					MPSC->System Memory
					IDMA->System Memory

	mv64x60_config_pci_windows()	PCI MEM->System Memory
					PCI I/O->Bridge's Registers

	mv64x60_config_cpu2pci_window()	CPU->PCI MEM
					CPU->PCI I/O
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0f81b11d
    • M
      [POWERPC] Add Makefile rules to wrap dts file in zImage · 916066d5
      由 Mark A. Greer 提交于 
      Add 'zImage.dts' and 'zImage.dts_initrd' build rules that automatically
compile and wrap a dts file from arch/powerpc/boot/dts into the zImage file.
The resulting zImage will be arch/powerpc/boot/zImage.dts.<platform> and
arch/powerpc/boot/zImage.dts_initrd.<platform>, respectively.

Having separate rules allows the user to choose whether to include a device
tree--and which device tree--at build time.  This is useful when one Makefile
target builds a zImage that runs on several platforms except for differing
device trees.  By just setting CONFIG_DEVICE_TREE and running "make zImage.dts"
the exact zImage you want is built without Makefile bloat or manually running
the wrapper script.

The dts file is expected to be arch/powerpc/boot/dts/$(CONFIG_DEVICE_TREE)
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      916066d5
  5. 08 5月, 2007 2 次提交
  7. 07 5月, 2007 2 次提交
  9. 02 5月, 2007 1 次提交
  11. 30 4月, 2007 1 次提交
  13. 27 4月, 2007 2 次提交
  15. 24 4月, 2007 2 次提交
  17. 13 4月, 2007 3 次提交
  19. 26 3月, 2007 3 次提交
  21. 21 3月, 2007 1 次提交
  23. 13 3月, 2007 2 次提交
    • 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: Add more flexible gunzip convenience functions · ad9d2716
      由 David Gibson 提交于 
      At present, arch/powerpc/boot/main.c includes a gunzip() function
which is a convenient wrapper around zlib.  However, it doesn't
conveniently allow decompressing part of an image to one location,
then the remainder to a different address.

This patch adds a new set of more flexible convenience wrappers around
zlib, moving them to their own file, gunzip_util.c, in the process.
These wrappers allow decompressing sections of the compressed image to
different locations.  In addition, they transparently handle
uncompressed data, avoiding special case code to handle uncompressed
vmlinux images.

The patch also converts main.c to use the new wrappers, using the new
flexibility to avoid decompressing the vmlinux's ELF header twice as
we did previously.  That in turn means we avoid extending our
allocations for the vmlinux to allow space for the extra copy of the
ELF header.
Signed-off-by: NDavid Gibson <dwg@au1.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      ad9d2716
  25. 07 2月, 2007 1 次提交
  27. 20 12月, 2006 1 次提交
  29. 05 12月, 2006 1 次提交
  31. 04 12月, 2006 3 次提交
  33. 13 11月, 2006 1 次提交
  35. 25 10月, 2006 1 次提交
  37. 24 10月, 2006 1 次提交
  39. 23 10月, 2006 4 次提交