没有合适的资源?快使用搜索试试~ 我知道了~
Booting ARM Linux
5星 · 超过95%的资源 需积分: 9 91 下载量 162 浏览量
2008-03-10
10:32:11
上传
评论
收藏 61KB PDF 举报
温馨提示
试读
22页
This document defines in clear concise terms, with implementation guidance and examples, the requirements and procedures for a bootloader to start an ARM Linux kernel.<br>
资源推荐
资源详情
资源评论
Booting ARM Linux
Vincent Sanders <vince@arm.linux.org.uk>
Review and advice, large chunks of the ARM Linux kernel, all around good guy: Russell
King
Review, advice and numerous clarifications.: Nicolas Pitre
Review and advice: Erik Mouw, Zwane Mwaikambo, Jeff Sutherland, Ralph Siemsen,
Daniel Silverstone, Martin Michlmayr, Michael Stevens, Lesley Mitchell, Matthew Richard-
son
Review and referenced information (see bibliography): Wookey
Copyright © 2004 Vincent Sanders
• This document is released under a GPL licence.
• All trademarks are acknowledged.
While every precaution has been taken in the preparation of this article, the pub-
lisher assumes no responsibility for errors or omissions, or for damages resulting
from the use of the information contained herein.
2004-06-04
Revision History
Revision 1.00 10th May 2004 VRS
Initial Release.
Revision 1.10 4th June 2004 VRS
Update example code to be more complete.
Improve wording in places, changes suggested by Nicolas Pitre.
Update Section 2, “Other bootloaders”.
Update acknowledgements.
Table of Contents
1. About this document .......................................................................................... 2
2. Other bootloaders .............................................................................................. 2
3. Overview ......................................................................................................... 2
4. Configuring the system's memory ......................................................................... 3
5. Loading the kernel image .................................................................................... 3
6. Loading an initial RAM disk ................................................................................ 4
7. Initialising a console ........................................................................................... 4
8. Kernel parameters .............................................................................................. 5
9. Obtaining the ARM Linux machine type ................................................................ 7
10. Starting the kernel ............................................................................................ 7
A. Tag Reference .................................................................................................. 8
B. Complete example ............................................................................................18
Bibliography .......................................................................................................21
Abstract
This document defines in clear concise terms, with implementation guidance and examples, the re-
quirements and procedures for a bootloader to start an ARM Linux kernel.
1. About this document
This document describes the "new" booting procedure which all version 2.4.18 and later kernels use.
The legacy "struct" method must not be used.
This document contains information from a wide variety of sources (see the Bibliography) and au-
thors, you are encouraged to consult these sources for more information before asking questions of
the Maintainers, or on the ARM Linux mailing lists. Most of these areas have been covered re-
peatedly in the past and you are likely to be ignored if you haven't done at least basic research.
Additionally it should be noted that provided the guidance in this document is followed, there
should be no need for an implementor to understand every nuance of the assembler that starts the
kernel. Experience has shown on numerous occasions that most booting problems are unlikely to be
related to this code, said code is also quite tricky and unlikely to give any insight into the problem.
2. Other bootloaders
Before embarking on writing a new bootloader a developer should consider if one of the existing
loaders is appropriate. There are examples of loaders in most areas, from simple GPL loaders to full
blown commercial offerings. A short list is provided here but the documents in the Bibliography of-
fer more solutions.
Table 1. Bootloaders
Name URL Description
Blob Blob bootloader
[http://www.sf.net/projects/blob/]
GPL bootloader for SA11x0 (StrongARM) plat-
forms.
Bootldr Bootldr
[http://www.handhelds.org/sources.
html]
Both GPL and non-GPL versions available,
mainly used for handheld devices.
Redboot Redboot
[http://sources.redhat.com/redboot/]
Redhat loader released under their eCos licence.
U-Boot U-Boot
[http://sourceforge.net/projects/u-bo
ot/]
GPL universal bootloader, provides support for
several CPUs.
ABLE ABLE bootloader
[http://www.simtec.co.uk/products/
SWABLE/]
Commercial bootloader with comprehensive fea-
ture set
3. Overview
ARM Linux cannot be started on a machine without a small amount of machine specific code to ini-
tialise the system. ARM Linux requires the bootloader code to do very little, although several boot-
loaders do provide extensive additional functionality. The minimal requirements are:
Configure the memory system.
Load the kernel image at the correct memory address.
Optionally load an initial RAM disk at the correct memory address.
Initialise the boot parameters to pass to the kernel.
Obtain the ARM Linux machine type
Enter the kernel with the appropriate register values.
It is usually expected that the bootloader will initialise a serial or video console for the kernel in ad-
dition to these basic tasks. Indeed a serial port is almost considered mandatory in most system con-
figurations.
Each of these steps will be examined in the following sections.
4. Configuring the system's memory
The bootloader is expected to find and initialise all RAM that the kernel will use for volatile data
storage in the system. It performs this in a machine dependent manner. It may use internal al-
gorithms to automatically locate and size all RAM, or it may use knowledge of the RAM in the ma-
chine, or any other method the bootloader designer sees fit.
In all cases it should be noted that all setup is performed by the bootloader. The kernel should have
no knowledge of the setup or configuration of the RAM within a system other than that provided by
the bootloader. The use of machine_fixup() within the kernel is most definitely not the correct place
for this. There is a clear distinction between the bootloaders responsibility and the kernel in this
area.
The physical memory layout is passed to the kernel using the ATAG_MEM parameter. Memory
does not necessarily have to be completely contiguous, although the minimum number of fragments
is preferred. Multiple ATAG_MEM blocks allow for several memory regions. The kernel will co-
alesce blocks passed to it if they are contiguous physical regions.
The bootloader may also manipulate the memory with the kernels command line, using the 'mem='
parameter, the options for this parameter are fully documented in linux/Document-
ation/kernel-parameters.txt
The kernel command line 'mem=' has the syntax mem=<size>[KM][,@<phys_offset>]
which allows the size and physical memory location for a memory area to be defined. This allows
for specifying multiple discontigous memory blocks at differing offsets by providing the mem=
parameter multiple times.
5. Loading the kernel image
Kernel images generated by the kernel build process are either uncompressed "Image" files or com-
pressed zImage files.
The uncompressed Image files are generally not used, as they do not contain a readily identifiable
magic number. The compressed zImage format is almost universally used in preference.
The zImage has several benefits in addition to the magic number. Typically, the decompression of
the image is faster than reading from some external media. The integrity of the image can be as-
sured, as any errors will result in a failed decompress. The kernel has knowledge of its internal
structure and state, which allows for better results than a generic external compression method.
The zImage has a magic number and some useful information near its beginning.
Table 2. Useful fields in zImage head code
Offset into
zImage
Value Description
0x24 0x016F2818 Magic number used to identify this is an ARM
Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
The start and end offsets can be used to determine the length of the compressed image (size = end -
start). This is used by several bootloaders to determine if any data is appended to the kernel image.
This data is typically used for an initial RAM disk (initrd). The start address is usually 0 as the zIm-
age code is position independent.
The zImage code is Position Independent Code (PIC) so may be loaded anywhere within the avail-
able address space. The maximum kernel size after decompression is 4Megabytes. This is a hard
limit and would include the initrd if a bootpImage target was used.
Note
Although the zImage may be located anywhere, care should be taken. Starting a com-
pressed kernel requires additional memory for the image to be uncompressed into. This
space has certain constraints.
The zImage decompression code will ensure it is not going to overwrite the compressed
data. If the kernel detects such a conflict it will uncompress the image immediately after
the compressed zImage data and relocate the kernel after decompression. This obviously
has the impact that the memory region the zImage is loaded into must have up to
4Megabytes of space after it (the maximum uncompressed kernel size), i.e. placing the zI-
mage in the same 4Megabyte bank as its ZRELADDR would probably not work as expec-
ted.
Despite the ability to place zImage anywhere within memory, convention has it that it is loaded at
the base of physical RAM plus an offset of 0x8000 (32K). This leaves space for the parameter block
usually placed at offset 0x100, zero page exception vectors and page tables. This convention is very
common.
6. Loading an initial RAM disk
An initial RAM disk is a common requirement on many systems. It provides a way to have a root
filesystem available without access to other drivers or configurations. Full details can be obtained
from linux/Documentation/initrd.txt
There are two methods available on ARM Linux to obtain an initial RAM disk. The first is a special
build target bootpImage which takes an initial RAM disk at build time and appends it to a zImage.
This method has the benefit that it needs no bootloader intervention, but requires the kernel build
process to have knowledge of the physical address to place the ramdisk (using the INITRD_PHYS
definition). The hard size limit for the uncompressed kernel and initrd of 4Megabytes applies. Be-
cause of these limitations this target is rarely used in practice.
The second and much more widely used method is for the bootloader to place a given initial ramdisk
image, obtained from whatever media, into memory at a set location. This location is passed to the
kernel using ATAG_INITRD2 and ATAG_RAMDISK.
Conventionally the initrd is placed 8Megabytes from the base of physical memory. Wherever it is
placed there must be sufficient memory after boot to decompress the initial ramdisk into a real ram-
disk i.e. enough memory for zImage + decompressed zImage + initrd + uncompressed ramdisk. The
compressed initial ramdisk memory will be freed after the decompression has happened. Limitations
to the position of the ramdisk are:
It must lie completely within a single memory region (must not cross between areas defined by dif-
ferent ATAG_MEM parameters)
It must be aligned to a page boundary (typically 4k)
It must not conflict with the memory the zImage head code uses to decompress the kernel or it will
be overwritten as no checking is performed.
7. Initialising a console
A console is highly recommended as a method to see what actions the kernel is performing when
initialising a system. This can be any input output device with a suitable driver, the most common
cases are a video framebuffer driver or a serial driver. Systems that ARM Linux runs on tend to al-
most always provide a serial console port.
The bootloader should initialise and enable one serial port on the target.This includes enabling any
hardware power management etc., to use the port. This allows the kernel serial driver to automatic-
ally detect which serial port it should use for the kernel console (generally used for debugging pur-
poses, or communication with the target.)
As an alternative, the bootloader can pass the relevant 'console=' option to the kernel, via the com-
mand line parameter specifying the port, and serial format options as described in linux/
Documentation/kernel-parameters.txt
8. Kernel parameters
The bootloader must pass parameters to the kernel to describe the setup it has performed, the size
and shape of memory in the system and, optionally, numerous other values.
The tagged list should conform to the following constraints
The list must be stored in RAM and placed in a region of memory where neither the kernel decom-
presser nor initrd manipulation will overwrite it. The recommended placement is in the first 16KiB
of RAM, usually the start of physical RAM plus 0x100 (which avoids zero page exception vectors).
The physical address of the tagged list must be placed in R2 on entry to the kernel, however histor-
ically this has not been mandatory and the kernel has used the fixed value of the start of physical
RAM plus 0x100. This must not be relied upon in the future.
The list must not extend past the 0x4000 boundary where the kernel's initial translation page table is
created. The kernel performs no bounds checking and will overwrite the parameter list if it does so.
The list must be aligned to a word (32 bit, 4byte) boundary (if not using the recommended location)
The list must begin with an ATAG_CORE and end with ATAG_NONE
The list must contain at least one ATAG_MEM
Each tag in the list consists of a header containing two unsigned 32 bit values, the size of the tag (in
32 bit, 4 byte words) and the tag value
struct atag_header {
u32 size; /* legth of tag in words including this header */
u32 tag; /* tag value */
};
Each tag header is followed by data associated with that tag, excepting ATAG_NONE which has no
data and ATAG_CORE where the data is optional. The size of the data is determined by the size
field in header, the minimum size is 2 as the headers size is included in this value. The
ATAG_NONE is unique in that its size field is set to zero.
A tag may contain additional data after the mandated structures provided the size is adjusted to cov-
er the extra information, this allows for future expansion and for a bootloader to extend the data
provided to the kernel. For example a bootloader may provide additional serial number information
in an ATAG_SERIAL which could them be interpreted by a modified kernel.
The order of the tags in the parameter list is unimportant, they may appear as many times as re-
quired although interpretation of duplicate tags is tag dependant.
The data for each individual tag is described in the Appendix A, Tag Reference section.
Table 3. List of usable tags
Tag name Value Size Description
ATAG_N
ONE
0x00000000 2 Empty tag used to end list
ATAG_C 0x54410001 5 (2 if First tag used to start list
剩余21页未读,继续阅读
资源评论
- xecle2014-07-29全英文看的很吃力,不过确实是我要的文档,写的挺好的。
- Sheng_Jiang2013-01-23挺好的,是我要找的资料。
- chencl20132015-05-05挺好的,是我要找的资料。
sleep_linux
- 粉丝: 0
- 资源: 2
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功