7a6cf0485c
The Raspberry Pi can boot a kernel with device tree support. But at the
same time, the RPi folks wante to keep the old-fashioned, ATAG-based way
of booting (don't ask...).
So, the bootloader needs to know whether the kernel it is loading has DT
support or not. For that, it looks at the end of the kernel image for a
magic footer. If found, it loads a device tree and sets the registers
appropriately so that the kernel finds the DTB. If not found, it loads
the kernel with the traditional ATAGS.
Where it becomes a bit tricky, is that the DTB is different for models
A/B and A+/B+ (that is A and B use the same DTB, while the A+ and B+ use
a second DTB). The bootloader is capable to load the correct DTB from a
specially named file. That is:
- on A/B, it loads bcm2708-rpi-b.dtb
- on A+/B+, it loads bcm2708-rpi-b-plus.dtb
If the DTB is differently named, the bootloader won't find it, will not
load any DTB at all, and revert to booting with ATAGS.
It is possible to specify what DTB to load, by adding an new config
option 'device_tree=file.dtb' in config.txt, but then the firmware on
the SDcard is no longer bootable on both the original models and the
Plus models.
So, add a script that appends the appropriate footer to the kernel
image. The script is vampirised from the RPi's tools repository, but a
new package is *not* added just for that script: the whole repository is
300+ MiB, and a checkout is 600+ MiB; it is not pertinent to add this as
a new package for a script that weights a few KiB...
Install that script as a host utility, too.
Notes: lots of information is available in this thread on the RPi forums:
http://www.raspberrypi.org/forums/viewtopic.php?f=29&t=93015
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
||
|---|---|---|
| arch | ||
| board | ||
| boot | ||
| configs | ||
| docs | ||
| fs | ||
| linux | ||
| package | ||
| support | ||
| system | ||
| toolchain | ||
| .defconfig | ||
| .gitignore | ||
| CHANGES | ||
| Config.in | ||
| Config.in.legacy | ||
| COPYING | ||
| Makefile | ||
| Makefile.legacy | ||
| README | ||
To build and use the buildroot stuff, do the following:
1) run 'make menuconfig'
2) select the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) Use your shiny new root filesystem. Depending on which sort of
root filesystem you selected, you may want to loop mount it,
chroot into it, nfs mount it on your target device, burn it
to flash, or whatever is appropriate for your target system.
You do not need to be root to build or run buildroot. Have fun!
Offline build:
==============
In order to do an offline-build (not connected to the net), fetch all
selected source by issuing a
$ make source
before you disconnect.
If your build-host is never connected, then you have to copy buildroot
and your toplevel .config to a machine that has an internet-connection
and issue "make source" there, then copy the content of your dl/ dir to
the build-host.
Building out-of-tree:
=====================
Buildroot supports building out of tree with a syntax similar
to the Linux kernel. To use it, add O=<directory> to the
make command line, E.G.:
$ make O=/tmp/build
And all the output files (including .config) will be located under /tmp/build.
More finegrained configuration:
===============================
You can specify a config-file for uClibc:
$ make UCLIBC_CONFIG_FILE=/my/uClibc.config
And you can specify a config-file for busybox:
$ make BUSYBOX_CONFIG_FILE=/my/busybox.config
To use a non-standard host-compiler (if you do not have 'gcc'),
make sure that the compiler is in your PATH and that the library paths are
setup properly, if your compiler is built dynamically:
$ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine
Depending on your configuration, there are some targets you can use to
use menuconfig of certain packages. This includes:
$ make HOSTCC=gcc-4.3 linux-menuconfig
$ make HOSTCC=gcc-4.3 uclibc-menuconfig
$ make HOSTCC=gcc-4.3 busybox-menuconfig
Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org