Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 7
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 6月, 2007 3 次提交
    • D
      [POWERPC] Derive ebc ranges property from EBC registers · b2ba34f3
      由 David Gibson 提交于 
      In the device tree for Ebony, the 'ranges' property in the node for
the EBC bridge shows the mappings from the chip select / address lines
actually used for the EBC peripherals into the address space of the
OPB.  At present, these mappings are hardcoded in ebony.dts for the
mappings set up by the OpenBIOS firmware when it configures the EBC
bridge.

This replaces the hardcoded mappings with code in the zImage to
read the EBC configuration registers and create an appropriate ranges
property based on them.  This should make the zImage and kernel more
robust to changes in firmware configuration.  In particular, some of
the Ebony's DIP switches can change the effective address of the Flash
and other peripherals in OPB space.  With this patch, the kernel will
be able to cope with at least some of the possible variations.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      b2ba34f3
    • D
      [POWERPC] Factor zImage's 44x reset code out of ebony.c · 11123346
      由 David Gibson 提交于 
      The ebony_exit() function which resets the Ebony board should in fact
be common to most if not all 44x boards.  This moves the function out
into 44x.c, renaming it, so it can be used by other 44x platforms.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      11123346
    • 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
  3. 07 6月, 2007 1 次提交
    • P
      [POWERPC] Fix building of COFF zImages · f40e524e
      由 Paul Mackerras 提交于 
      The COFF zImage (for booting oldworld powermacs) wasn't being built
correctly because the procedure descriptor in crt0.S for the zImage
entry point wasn't declared as .globl, and therefore wasn't getting
pulled in from wrapper.a by the linker.  This adds the necessary
.globl statement.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f40e524e
  5. 02 6月, 2007 4 次提交
  7. 23 5月, 2007 1 次提交
  9. 17 5月, 2007 8 次提交
  11. 12 5月, 2007 7 次提交
    • 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 DTS file for the Motorola PrPMC2800 platform · 3f456cc1
      由 Mark A. Greer 提交于 
      Add the device tree source file for the prpmc2800 line of processor PMCs.
Several of the property values are updated by the bootwrapper but sane
defaults have been chosen in case the bootwrapper can't determine the
exact processor board variant.  The defaults should allow the kernel
to boot despite having non-optimal device tree property values.
Signed-off-by: NMark A. Greer <mgreer@mvista.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3f456cc1
    • 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
    • S
      [POWERPC] U-boot passes the initrd as start/end, not start/size. · dab4d798
      由 Scott Wood 提交于 
      The boot wrapper platform init code on 83xx and 85xx using the cuboot
platform type was incorrectly assuming that u-boot supplied the size
of the initrd, whereas it actually supplies the end address.  This
fixes it.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      dab4d798
  13. 10 5月, 2007 2 次提交
  15. 08 5月, 2007 4 次提交
  17. 07 5月, 2007 4 次提交
  19. 02 5月, 2007 2 次提交
  21. 30 4月, 2007 2 次提交
  23. 27 4月, 2007 2 次提交