mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-05 16:07:46 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
141
Documentation/powerpc/bootwrapper.txt
Normal file
141
Documentation/powerpc/bootwrapper.txt
Normal file
|
@ -0,0 +1,141 @@
|
|||
The PowerPC boot wrapper
|
||||
------------------------
|
||||
Copyright (C) Secret Lab Technologies Ltd.
|
||||
|
||||
PowerPC image targets compresses and wraps the kernel image (vmlinux) with
|
||||
a boot wrapper to make it usable by the system firmware. There is no
|
||||
standard PowerPC firmware interface, so the boot wrapper is designed to
|
||||
be adaptable for each kind of image that needs to be built.
|
||||
|
||||
The boot wrapper can be found in the arch/powerpc/boot/ directory. The
|
||||
Makefile in that directory has targets for all the available image types.
|
||||
The different image types are used to support all of the various firmware
|
||||
interfaces found on PowerPC platforms. OpenFirmware is the most commonly
|
||||
used firmware type on general purpose PowerPC systems from Apple, IBM and
|
||||
others. U-Boot is typically found on embedded PowerPC hardware, but there
|
||||
are a handful of other firmware implementations which are also popular. Each
|
||||
firmware interface requires a different image format.
|
||||
|
||||
The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
|
||||
it uses the wrapper script (arch/powerpc/boot/wrapper) to generate target
|
||||
image. The details of the build system is discussed in the next section.
|
||||
Currently, the following image format targets exist:
|
||||
|
||||
cuImage.%: Backwards compatible uImage for older version of
|
||||
U-Boot (for versions that don't understand the device
|
||||
tree). This image embeds a device tree blob inside
|
||||
the image. The boot wrapper, kernel and device tree
|
||||
are all embedded inside the U-Boot uImage file format
|
||||
with boot wrapper code that extracts data from the old
|
||||
bd_info structure and loads the data into the device
|
||||
tree before jumping into the kernel.
|
||||
Because of the series of #ifdefs found in the
|
||||
bd_info structure used in the old U-Boot interfaces,
|
||||
cuImages are platform specific. Each specific
|
||||
U-Boot platform has a different platform init file
|
||||
which populates the embedded device tree with data
|
||||
from the platform specific bd_info file. The platform
|
||||
specific cuImage platform init code can be found in
|
||||
arch/powerpc/boot/cuboot.*.c. Selection of the correct
|
||||
cuImage init code for a specific board can be found in
|
||||
the wrapper structure.
|
||||
dtbImage.%: Similar to zImage, except device tree blob is embedded
|
||||
inside the image instead of provided by firmware. The
|
||||
output image file can be either an elf file or a flat
|
||||
binary depending on the platform.
|
||||
dtbImages are used on systems which do not have an
|
||||
interface for passing a device tree directly.
|
||||
dtbImages are similar to simpleImages except that
|
||||
dtbImages have platform specific code for extracting
|
||||
data from the board firmware, but simpleImages do not
|
||||
talk to the firmware at all.
|
||||
PlayStation 3 support uses dtbImage. So do Embedded
|
||||
Planet boards using the PlanetCore firmware. Board
|
||||
specific initialization code is typically found in a
|
||||
file named arch/powerpc/boot/<platform>.c; but this
|
||||
can be overridden by the wrapper script.
|
||||
simpleImage.%: Firmware independent compressed image that does not
|
||||
depend on any particular firmware interface and embeds
|
||||
a device tree blob. This image is a flat binary that
|
||||
can be loaded to any location in RAM and jumped to.
|
||||
Firmware cannot pass any configuration data to the
|
||||
kernel with this image type and it depends entirely on
|
||||
the embedded device tree for all information.
|
||||
The simpleImage is useful for booting systems with
|
||||
an unknown firmware interface or for booting from
|
||||
a debugger when no firmware is present (such as on
|
||||
the Xilinx Virtex platform). The only assumption that
|
||||
simpleImage makes is that RAM is correctly initialized
|
||||
and that the MMU is either off or has RAM mapped to
|
||||
base address 0.
|
||||
simpleImage also supports inserting special platform
|
||||
specific initialization code to the start of the bootup
|
||||
sequence. The virtex405 platform uses this feature to
|
||||
ensure that the cache is invalidated before caching
|
||||
is enabled. Platform specific initialization code is
|
||||
added as part of the wrapper script and is keyed on
|
||||
the image target name. For example, all
|
||||
simpleImage.virtex405-* targets will add the
|
||||
virtex405-head.S initialization code (This also means
|
||||
that the dts file for virtex405 targets should be
|
||||
named (virtex405-<board>.dts). Search the wrapper
|
||||
script for 'virtex405' and see the file
|
||||
arch/powerpc/boot/virtex405-head.S for details.
|
||||
treeImage.%; Image format for used with OpenBIOS firmware found
|
||||
on some ppc4xx hardware. This image embeds a device
|
||||
tree blob inside the image.
|
||||
uImage: Native image format used by U-Boot. The uImage target
|
||||
does not add any boot code. It just wraps a compressed
|
||||
vmlinux in the uImage data structure. This image
|
||||
requires a version of U-Boot that is able to pass
|
||||
a device tree to the kernel at boot. If using an older
|
||||
version of U-Boot, then you need to use a cuImage
|
||||
instead.
|
||||
zImage.%: Image format which does not embed a device tree.
|
||||
Used by OpenFirmware and other firmware interfaces
|
||||
which are able to supply a device tree. This image
|
||||
expects firmware to provide the device tree at boot.
|
||||
Typically, if you have general purpose PowerPC
|
||||
hardware then you want this image format.
|
||||
|
||||
Image types which embed a device tree blob (simpleImage, dtbImage, treeImage,
|
||||
and cuImage) all generate the device tree blob from a file in the
|
||||
arch/powerpc/boot/dts/ directory. The Makefile selects the correct device
|
||||
tree source based on the name of the target. Therefore, if the kernel is
|
||||
built with 'make treeImage.walnut simpleImage.virtex405-ml403', then the
|
||||
build system will use arch/powerpc/boot/dts/walnut.dts to build
|
||||
treeImage.walnut and arch/powerpc/boot/dts/virtex405-ml403.dts to build
|
||||
the simpleImage.virtex405-ml403.
|
||||
|
||||
Two special targets called 'zImage' and 'zImage.initrd' also exist. These
|
||||
targets build all the default images as selected by the kernel configuration.
|
||||
Default images are selected by the boot wrapper Makefile
|
||||
(arch/powerpc/boot/Makefile) by adding targets to the $image-y variable. Look
|
||||
at the Makefile to see which default image targets are available.
|
||||
|
||||
How it is built
|
||||
---------------
|
||||
arch/powerpc is designed to support multiplatform kernels, which means
|
||||
that a single vmlinux image can be booted on many different target boards.
|
||||
It also means that the boot wrapper must be able to wrap for many kinds of
|
||||
images on a single build. The design decision was made to not use any
|
||||
conditional compilation code (#ifdef, etc) in the boot wrapper source code.
|
||||
All of the boot wrapper pieces are buildable at any time regardless of the
|
||||
kernel configuration. Building all the wrapper bits on every kernel build
|
||||
also ensures that obscure parts of the wrapper are at the very least compile
|
||||
tested in a large variety of environments.
|
||||
|
||||
The wrapper is adapted for different image types at link time by linking in
|
||||
just the wrapper bits that are appropriate for the image type. The 'wrapper
|
||||
script' (found in arch/powerpc/boot/wrapper) is called by the Makefile and
|
||||
is responsible for selecting the correct wrapper bits for the image type.
|
||||
The arguments are well documented in the script's comment block, so they
|
||||
are not repeated here. However, it is worth mentioning that the script
|
||||
uses the -p (platform) argument as the main method of deciding which wrapper
|
||||
bits to compile in. Look for the large 'case "$platform" in' block in the
|
||||
middle of the script. This is also the place where platform specific fixups
|
||||
can be selected by changing the link order.
|
||||
|
||||
In particular, care should be taken when working with cuImages. cuImage
|
||||
wrapper bits are very board specific and care should be taken to make sure
|
||||
the target you are trying to build is supported by the wrapper bits.
|
Loading…
Add table
Add a link
Reference in a new issue