Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 3 年多

通知 13
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 17 5月, 2007 8 次提交
  3. 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
  5. 10 5月, 2007 2 次提交
  7. 08 5月, 2007 4 次提交
  9. 07 5月, 2007 4 次提交
  11. 02 5月, 2007 2 次提交
  13. 30 4月, 2007 2 次提交
  15. 27 4月, 2007 5 次提交
  17. 24 4月, 2007 5 次提交
  19. 13 4月, 2007 1 次提交
    • P
      [POWERPC] Fix detection of loader-supplied initrd on OF platforms · 390cbb56
      由 Paul Mackerras 提交于 
      Commit 79c85419 introduced code to move
the initrd if it was in a place where it would get overwritten by the
kernel image.  Unfortunately this exposed the fact that the code that
checks whether the values passed in r3 and r4 are intended to indicate
the start address and size of an initrd image was not as thorough as the
kernel's checks.  The symptom is that on OF-based platforms, the
bootwrapper can cause an exception which causes the system to drop back
into OF.

Previously it didn't matter so much if the code incorrectly thought that
there was an initrd, since the values for start and size were just passed
through to the kernel.  Now the bootwrapper needs to apply the same checks
as the kernel since it is now using the initrd data itself (in the process
of copying it if necessary).  This adds the code to do that.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      390cbb56