9
0
Fork 0

Merge branch 'for-next/doc'

This commit is contained in:
Sascha Hauer 2014-07-04 17:19:40 +02:00
commit ce1b0d4ae3
186 changed files with 3357 additions and 5223 deletions

2
.gitignore vendored
View File

@ -67,6 +67,8 @@ include/generated
# Generated files # Generated files
Doxyfile.version Doxyfile.version
Documentation/commands/*.rst
doctrees/
# stgit generated dirs # stgit generated dirs
patches-* patches-*

View File

@ -1 +1,2 @@
build
html html

View File

@ -1,126 +0,0 @@
/** @mainpage Barebox
Barebox is a bootloader that initializes hardware and boots Linux and
maybe other operating systems or bare metal code on a variety of
processors. It was initially derived from U-Boot and retains several of
U-Boot's ideas, so users familiar with U-Boot should come into
production quickly with Barebox.
However, as the Barebox developers are highly addicted to the Linux
kernel, its coding style and code quality, we try to stick as closely
as possible to the methodologies and techniques developed in Linux. In
addition we have a strong background in POSIX, so you'll find several
good old Unix traditions realized in Barebox as well.
@par Highlights:
- <b>POSIX File API:</b><br>
@a Barebox uses the the well known open/close/read/write/lseek access
functions, together with a model of representing devices by files. This
makes the APIs familiar to everyone who has experience with Unix
systems.
- <b>Shell:</b><br>
We have the standard shell commands like ls/cd/mkdir/echo/cat,...
- <b>Environment Filesystem:</b><br>
In contrast to U-Boot, Barebox doesn't misuse the environment for
scripting. If you start the bootloader, it gives you a shell and
something that looks like a filesystem. In fact it isn't; it is a very
simple ar archive being extracted from flash into a ramdisk with 'loadenv'
and stored back with 'saveenv'.
- <b>Filesystem Support:</b><br>
When starting up, the environment is mounted to /, followed by a
device filesytem being mounted to /dev in order to make it possible to
access devices. Other filesystems can be mounted on demand.
- <b>Driver Model (borrowed from Linux):</b><br>
Barebox follows the Linux driver model: devices can be specified in a
hardware specific file, and drivers feel responsible for these devices
if they have the same name.
- <b>Clocksource:</b><br>
We use the standard clocksource API from Linux.
- <b>Kconfig/Kbuild:</b><br>
This gives us parallel builds and removes the need for lots of ifdefs.
- <b>Sandbox:</b><br>
If you develop features for @a Barebox, you can use the 'sandbox'
target which compiles @a Barebox as a POSIX application in the Linux
userspace: it can be started like a normal command and even has
network access (tun/tap). Files from the local filesytem can be used
to simulate devices.
- <b>Device Parameters:</b><br>
There is a parameter model in @a Barebox: each device can specify its
own parameters, which do exist for every instance. Parameters can be
changed on the command line with \<devid\>.\<param\>="...". For
example, if you want to access the IPv4 address for eth0, this is done
with 'eth0.ip=192.168.0.7' and 'echo $eth0.ip'.
- <b>Getopt:</b><br>
@a Barebox has a lightweight getopt() implementation. This makes it
unnecessary to use positional parameters, which can be hard to read.
- <b>Integrated Editor:</b><br>
Scripts can be edited with a small integrated fullscreen editor.
This editor has no features except the ones really needed: moving
the cursor around, typing characters, exiting and saving.
@par Directory layout
Most of the directory layout is based upon the Linux Kernel:
@verbatim
arch / * / -> contains architecture specific parts
arch / * / mach-* / -> SoC specific code
drivers / serial -> drivers
drivers / net
drivers / ...
include / asm-* -> architecture specific includes
include / asm-* / arch-* -> SoC specific includes
fs / -> filesystem support and filesystem drivers
lib / -> generic library functions (getopt, readline and the
like)
common / -> common stuff
commands / -> many things previously in common/cmd_*, one command
per file
net / -> Networking stuff
scripts / -> Kconfig system
Documentation / -> Parts of the documentation, also doxygen
@endverbatim
@section license barebox's License
@verbatim
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
@endverbatim
@subpage users_manual
@subpage developers_manual
@subpage supported_boards
*/

View File

@ -1,94 +0,0 @@
/** @page dev_board Adapting a new Board
To add a new board to @a barebox a few steps must be done, to extend and modify
the @a barebox source tree.
@section board_add_files Files/Directories to be added
- arch/\<architecture\>/boards/\<boardname\>
- arch/\<architecture\>/boards/\<boardname\>/Makefile
- arch/\<architecture\>/boards/\<boardname\>/\<boardname\>.c
- arch/\<architecture\>/boards/\<boardname\>/\<boardname\>.dox
- include/configs/\<boardname\>.h
- arch/\<architecture\>/configs/\<boardname\>_defconfig
@subsection board_makefile arch/\<architecture\>/boards/\<boardname\>Makefile
@verbatim
obj-y += all files that builds the BSP (Assembler and/or C files)
@endverbatim
@subsection board_basefile arch/\<architecture\>/boards/\<boardname\>\<boardname\>.c
TBD
@subsection board_doxygen arch/\<architecture\>/boards/\<boardname\>/\<boardname\>.dox
This file should describe in short words your new board, what CPU
it uses, what resources are provided and features it supports.
Use the doxygen style for this kind of documentation. Below you find a
template for this kind of file:
@verbatim
/** @page <boardname> <Manufacturer> <Board's Name>
This board uses an <architecture> based CPU. The board is shipped with:
- many MiB NOR type Flash Memory
- many MiB SDRAM
- a very special network controller
and so on.
*/
@endverbatim
To make your new shiny file visible in the automatically generated
documentation you must sort in the used page lable ("<boardname>" in the
template above) into Documentation/boards.dox as:
@verbatim
...
@subpage <boardname>
...
@endverbatim
at the right architecture.
@note Consider to use an unique page lable.
@subsection board_lscript arch/\<architecture\>/boards/\<boardname\>/barebox.lds.S
If your board needs a special binary @a barebox layout, you can provide a local
board linker script file. This will replace the generic one provided by your
architecture or CPU support.
Add this file with
@verbatim
extra-y += <board_linker_script>
@endverbatim
in your local \b Makefile to the list of files, forwarded to the last linking step.
@section board_defconfig arch/\<architecture\>/configs/\<boardname\>_defconfig
TBD
@section board_mod_files These files needs to be modified:
- modify Documentation/board.dox
- modify arch/\<architecture\>/Kconfig
- add your board (MACH_*) to the list
- add your default text base address for this architecture (ARCH_TEXT_BASE)
- modify arch/\<architecture\>/Makefile:
- add board-$(MACH_*) = \<your board_dir\>
First, the new board should be visible in the menu.
@section board_specific_cpu Porting hints for specific CPUs
@li @subpage dev_s3c24xx_mach
*/

View File

@ -1,74 +0,0 @@
/** @page supported_boards Supported Boards
This is a list of boards that are currently supported by @a barebox.
PowerPC type:
@li @subpage pcm030
ARM type:
@li @subpage pcm037
@li @subpage pcm038
@li @subpage pcm043
@li @subpage imx21ads
@li @subpage imx27ads
@li @subpage tx28
@li @subpage the3stack
@li @subpage mx23_evk
@li @subpage board_babage
@li @subpage board_loco
@li @subpage chumbyone
@li @subpage scb9328
@li @subpage netx
@li @subpage dev_omap_arch
@li @subpage a9m2440
@li @subpage a9m2410
@li @subpage eukrea_cpuimx27
@li @subpage eukrea_cpuimx35
@li @subpage edb9301
@li @subpage edb9302
@li @subpage edb9302a
@li @subpage edb9307
@li @subpage edb9307a
@li @subpage edb9312
@li @subpage edb9315
@li @subpage edb9315a
@li @subpage board_cupid
@li @subpage phycard-a-l1
@li @subpage toshiba-ac100
@li @subpage qil-a9260
@li @subpage tny-a9g20-lpw
@li @subpage tny-a9263
@li @subpage usb-a9g20-lpw
@li @subpage usb-a9263
@li @subpage virt2real
Blackfin type:
@li @subpage ipe337
x86 type:
@li @subpage generic_pc
MIPS type:
@li @subpage dlink_dir_320
@li @subpage loongson_ls1b
@li @subpage qemu_malta
@li @subpage ritmix-rzx50
@li @subpage tplink-mr3020
*/
/* TODO
*
* Add documentation to your boardfile, forward it with doxygen's page
* feature (@page <reference>) and include it here with:
*
* @subpage <reference>
*
*/

10
Documentation/boards.rst Normal file
View File

@ -0,0 +1,10 @@
.. _boards:
Board support
=============
.. toctree::
:glob:
:maxdepth: 2
boards/*

View File

@ -0,0 +1,9 @@
Cirrus Logic edb9xxx
====================
.. toctree::
:glob:
:numbered:
:maxdepth: 1
edb9xxx/*

View File

@ -0,0 +1,10 @@
Cirrus Logic EP9301
===================
This board is based on a Cirrus Logic EP9301 CPU. The board is shipped with:
* 16MiB NOR type Flash Memory
* 32MiB synchronous dynamic RAM on CS3
* 128kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec

View File

@ -0,0 +1,10 @@
Cirrus Logic EDB9302
====================
This board is based on a Cirrus Logic EP9302 CPU. The board is shipped with:
* 16MiB NOR type Flash Memory
* 32MiB synchronous dynamic RAM on CS3
* 128kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec

View File

@ -0,0 +1,10 @@
Cirrus Logic EDB9302A
=====================
This board is based on a Cirrus Logic EP9302 CPU. The board is shipped with:
* 16MiB NOR type Flash Memory
* 32MiB synchronous dynamic RAM on CS0
* 512kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec

View File

@ -0,0 +1,13 @@
Cirrus Logic EDB9307
====================
This board is based on a Cirrus Logic EP9307 CPU. The board is shipped with:
* 32MiB NOR type Flash Memory
* 64MiB synchronous dynamic RAM on CS3
* 512kiB asynchronous SRAM
* 128kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec
* Real-Time Clock
* IR receiver

View File

@ -0,0 +1,13 @@
Cirrus Logic EDB9307A
=====================
This board is based on a Cirrus Logic EP9307 CPU. The board is shipped with:
* 32MiB NOR type Flash Memory
* 64MiB synchronous dynamic RAM on CS0
* 512kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec
* Real-Time Clock
* IR receiver

View File

@ -0,0 +1,13 @@
Cirrus Logic EDB9312
====================
This board is based on a Cirrus Logic EP9312 CPU. The board is shipped with:
* 32MiB NOR type Flash Memory
* 64MiB synchronous dynamic RAM on CS3
* 512kiB asynchronous SRAM
* 128kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec
* Real-Time Clock
* IR receiver

View File

@ -0,0 +1,13 @@
Cirrus Logic EDB9315
====================
This board is based on a Cirrus Logic EP9315 CPU. The board is shipped with:
* 32MiB NOR type Flash Memory
* 64MiB synchronous dynamic RAM on CS3
* 512kiB asynchronous SRAM
* 128kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec
* Real-Time Clock
* IR receiver

View File

@ -0,0 +1,12 @@
Cirrus Logic EDB9315A
=====================
This board is based on a Cirrus Logic EP9315 CPU. The board is shipped with:
* 32MiB NOR type Flash Memory
* 64MiB synchronous dynamic RAM on CS0
* 128kiB serial EEPROM
* MII 10/100 Ethernet PHY
* Stereo audio codec
* Real-Time Clock
* IR receiver

View File

@ -0,0 +1,104 @@
Freescale i.MX
==============
Freescale i.MX is traditionally very well supported under barebox.
Depending on the SoC, there are different Boot Modes supported. Older
SoCs up to i.MX31 support only the external Boot Mode. Newer SoCs
can be configured for internal or external Boot Mode with the internal
boot mode being the more popular mode. The i.MX23 and i.MX28, also
known as i.MXs, are special. These SoCs have a completely different
boot mechanism.
Internal Boot Mode
------------------
The Internal Boot Mode is supported on:
* i.MX25
* i.MX35
* i.MX51
* i.MX53
* i.MX6
With the Internal Boot Mode, the images contain a header which describes
where the binary shall be loaded and started. These headers also contain
a so-called DCD table which consists of register/value pairs. These are
executed by the Boot ROM and are used to configure the SDRAM. In barebox,
the i.MX images are generated with the ``scripts/imx/imx-image`` tool.
Normally it's not necessary to call this tool manually, it is executed
automatically at the end of the build process.
The images generated by the build process can be directly written to an
SD card::
# with Multi Image support:
cat images/barebox-freescale-imx51-babbage.img > /dev/sdd
# otherwise:
cat barebox-flash-image > /dev/sdd
The above will overwrite the MBR (and consequently the partition table)
on the destination SD card. To preserve the MBR while writing the rest
of the image to the card, use::
dd if=images/barebox-freescale-imx51-babbage.img of=/dev/sdd bs=512 skip=1 seek=1
The images can also always be started second stage::
bootm /mnt/tftp/barebox-freescale-imx51-babbage.img
USB Boot
^^^^^^^^
Most boards can be explicitly configured for USB Boot Mode or fall back
to USB Boot when no other medium can be found. The barebox repository
contains a USB upload tool. As it depends on the libusb development headers,
it is not built by default. Enable it explicitly in ``make menuconfig``
and install the libusb development package. On Debian, this can be done
with ``apt-get install libusb-dev``. After compilation, the tool can be used
with only the image name as argument::
scripts/imx/imx-usb-loader images/barebox-freescale-imx51-babbage.img
External Boot Mode
------------------
The External Boot Mode is supported by the older i.MX SoCs:
* i.MX1
* i.MX21
* i.MX27
* i.MX31
(It may be supported on newer SoCs as well, but it is not widely used there.)
The External Boot Mode supports booting only from NOR and NAND flash. On NOR
flash, the binary is started directly on its physical address in memory. Booting
from NAND flash is more complicated. The NAND flash controller copies the first
2kb of the image to the NAND Controller's internal SRAM. This initial binary
portion then has to:
* Set up the SDRAM
* Copy the initial binary to SDRAM to make the internal SRAM in the NAND flash
controller free for use for the controller
* Copy the whole barebox image to SDRAM
* Start the image
It is possible to write the image directly to NAND. However, since NAND flash
can have bad blocks which must be skipped during writing the image and also
by the initial loader, it is recommended to use the :ref:`command_barebox_update`
command for writing to NAND flash.
i.MX boards
-----------
Not supported all boards have a description here. Many newer boards also do
not have individual defconfig files, they are covered by ``imx_v7_defconfig``
or ``imx_defconfig`` instead.
.. toctree::
:glob:
:numbered:
:maxdepth: 1
imx/*
mxs/*

View File

@ -0,0 +1,9 @@
Garz+Fricke Cupid
=================
This CPU card is based on a Freescale i.MX35 CPU. The card is shipped with:
* 256MiB NAND flash
* 128MiB synchronous dynamic RAM
see http://www.garz-fricke.com/cupid-core_de.html for more information

View File

@ -0,0 +1,41 @@
Phytec phyCORE-i.MX31 CPU module PCM-037
========================================
The CPU module
--------------
http://www.phytec.eu/europe/products/modules-overview/phycore/produktdetails/p/phycore-imx31-2.html
This CPU card is based on a Freescale i.MX31 CPU. The card in
configuration -0000REU is shipped with:
* 128 MiB synchronous dynamic RAM (DDR type)
* 64 MiB NAND flash
* 32 MiB NOR flash
* 512 kiB SRAM
* 4kiB EEPROM
* MMU, FPU
* Serial, Ethernet, USB (OTG), I2C, SPI, MMC/SD/SDIO, PCMCIA/CF, RTC
Supported baseboards
--------------------
Supported baseboards are:
* Silica / Phytec PCM-970 via phyMAP-i.MX31, PMA-001
How to get barebox for 'Phytec's phyCORE-i.MX31'
------------------------------------------------
Using the default configuration::
make ARCH=arm pcm037_defconfig
Build the binary image::
make ARCH=arm CROSS_COMPILE=armv5compiler
**NOTE:** replace ''armv5compiler'' with your ARM v5 cross compiler,
e.g.: ''arm-1136jfs-linux-gnueabi-''
The resulting binary image to be flashed will be ``barebox.bin``, whereas
the file named just ``barebox`` is an ELF executable for ARM.

View File

@ -0,0 +1,11 @@
Eukrea CPUIMX27
===============
This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with:
* up to 64MiB NOR type Flash Memory
* up to 256MiB synchronous dynamic RAM
* up to 512MiB NAND type Flash Memory
* MII 10/100 ethernet PHY
* optional 16554 Quad UART on CS3

View File

@ -0,0 +1,10 @@
Synertronixx scb9328
====================
See http://www.synertronixx.de/produkte/scb9328/scb9328.htm
This CPU card is based on a Freescale i.MX1 CPU. The card is shipped with:
* 16MiB NOR type Flash Memory
* 16MiB synchronous dynamic RAM
* DM9000 network controller

View File

@ -0,0 +1,9 @@
MIPS
====
.. toctree::
:glob:
:numbered:
:maxdepth: 1
mips/*

View File

@ -0,0 +1,44 @@
D-Link DIR-320
==============
The D-Link DIR-320 wireless router has
* BCM5354 SoC;
* 32 MiB SDRAM;
* 4 MiB NOR type Flash Memory;
* RS232 serial interface (LV-TTL levels on board!);
* 1xUSB interface;
* 4 + 1 ethernet interfaces;
* 802.11b/g (WiFi) interface;
* JTAG interface;
* 5 LEDs;
* 2 buttons.
The router uses CFE as firmware.
Running barebox
---------------
Barebox can be started from CFE using tftp.
You must setup tftp-server on host 192.168.0.1.
Put your barebox.bin to tftp-server directory
(usual /tftpboot or /srv/tftp).
Connect your DIR-320 to your tftp-server network via
one of four <LAN> sockets.
Next, setup network on DIR-320 and run barebox.bin, e.g.::
CFE> ifconfig eth0 -addr=192.168.0.99
CFE> boot -tftp -addr=a0800000 -raw 192.168.0.1:barebox.bin
Links
-----
* http://www.dlink.com.au/products/?pid=768
* http://wiki.openwrt.org/toh/d-link/dir-320
CFE links:
* http://www.broadcom.com/support/communications_processors/downloads.php#cfe
* http://www.linux-mips.org/wiki/CFE

View File

@ -0,0 +1,56 @@
Loongson LS1B
=============
The LS1B is a development board made by Loongson Technology Corp. Ltd.
The board has
* Loongson LS1B SoC 250 MHz;
* 64 MiB SDRAM;
* 512 KiB SPI boot ROM;
* 128M x 8 Bit NAND Flash Memory;
* 2 x RS232 serial interfaces (DB9 connectors);
* 2 x Ethernet interfaces;
* 4 x USB interfaces;
* microSD card slot;
* LCD display (480x272);
* audio controller;
* beeper;
* buttons;
* EJTAG 10-pin connector.
The board uses PMON2000 as bootloader.
Running barebox
---------------
1. Connect to the boards's UART2 (115200 8N1);
2. Turn board's power on;
3. Wait ``Press <Enter> to execute loading image`` prompt and press the space key.
4. Build barebox and upload ``zbarebox.bin`` via Ymodem to the board:
.. code-block:: none
PMON> ymodem base=0xa0200000
..
5. Run barebox
.. code-block:: none
PMON> g -e 0xa0200000
..
Links
-----
* http://en.wikipedia.org/wiki/Loongson
* http://www.linux-mips.org/wiki/Loongson
* https://github.com/loongson-gz
* http://www.linux-mips.org/wiki/PMON_2000
* http://www.opsycon.se/PMON2000/Main

View File

@ -0,0 +1,19 @@
QEMU Malta
==========
QEMU run string::
qemu-system-mips -nodefaults -M malta -m 256 \
-nographic -serial stdio -monitor null \
-bios barebox-flash-image
Also you can use GXemul::
gxemul -Q -x -e maltabe -M 256 0xbfc00000:barebox-flash-image
Links
-----
* http://www.linux-mips.org/wiki/Mips_Malta
* http://www.qemu.org/
* http://gxemul.sourceforge.net/

View File

@ -0,0 +1,62 @@
Ritmix RZX-50
=============
Ritmix RZX-50 is a portable game console for the Russian market.
The portable game console has
* Ingenic JZ4755 SoC;
* 64 MiB SDRAM;
* 4 GiB microSDHC card / 4 GiB NAND type Flash Memory (internal boot device);
* RS232 serial interface (LV-TTL levels on the board!);
* LCD display (480x272);
* Video out interface;
* 1xUSB interface;
* buttons.
The game console uses U-Boot 1.1.6 as bootloader.
Running barebox
---------------
1. Connect to the game console's UART
(see. http://a320.emulate.su/2012/01/19/uart-na-ritmix-rzx-50/);
2. Unblock U-Boot console
(see. http://a320.emulate.su/2012/01/25/rzx-50-dostup-k-konsoli-u-boot/);
Please note that U-Boot's Zmodem support does not work;
3. Boot Ritmix linux and login;
4. Build barebox and upload ``barebox.bin`` via Zmodem to the board:
.. code-block:: none
# cd /tmp
# rz
..
5. Write barebox to onboard flash:
.. code-block:: none
# dd if=barebox.bin of=/dev/mmcblk0 seek=1048576 bs=1 count=262144
..
6. Reboot RZX-50, next in U-Boot console start barebox:
.. code-block:: none
CETUS # msc read 0xa0800000 0x100000 0x40000; g a0800000
..
Links
-----
* http://www.ritmixrussia.ru/products/252/entertainment/game/rzx-50
* ftp://ftp.ingenic.cn/2soc/4755/JZ4755_ds.pdf
* ftp://ftp.ingenic.cn/3sw/01linux/01loader/u-boot/u-boot-1.1.6-jz-20110719-r1728-add-jz4770.patch.bz2

View File

@ -0,0 +1,67 @@
TP-LINK MR3020
==============
The TP-LINK MR3020 wireless router has
* Atheros ar9331 SoC;
* 32 MiB SDRAM;
* 4 MiB NOR type SPI Flash Memory;
* RS232 serial interface (LV-TTL levels on board!);
* 1 USB interface;
* 1 Ethernet interfaces;
* 802.11b/g/n (WiFi) interface;
* LEDs & buttons.
The router uses U-Boot 1.1.4 as firmware.
Running barebox
---------------
Barebox can be started from U-Boot using tftp.
But you have to encode barebox image in a very special way.
First obtain ``lzma`` and ``mktplinkfw`` utilities.
The ``lzma`` utility can be obtained in Debian/Ubuntu
distro by installing lzma package.
The ``mktplinkfw`` utility can be obtained from openwrt, e.g.::
$ OWRTPREF=https://raw.githubusercontent.com/mirrors/openwrt/master
$ curl -OL $OWRTPREF/tools/firmware-utils/src/mktplinkfw.c \
-OL $OWRTPREF/tools/firmware-utils/src/md5.c \
-OL $OWRTPREF/tools/firmware-utils/src/md5.h
$ cc -o mktplinkfw mktplinkfw.c md5.c
To convert your barebox.bin to U-Boot-loadable image (``6F01A8C0.img``)
use this command sequence::
$ lzma -c -k barebox.bin > barebox.lzma
$ ./FW/mktplinkfw -c -H 0x07200103 -W 1 -N TL-WR720N-v3 \
-s -F 4Mlzma -k barebox.lzma -o 6F01A8C0.img
You must setup tftp-server on host 192.168.0.1.
Put your ``6F01A8C0.img`` to tftp-server directory
(usual ``/tftpboot`` or ``/srv/tftp``).
Connect your board to your tftp-server network via Ethernet.
Next, setup network on MR3020 and run ``6F01A8C0.img``, e.g.::
hornet> set ipaddr 192.168.0.2
hornet> set serverip 192.168.0.1
hornet> tftpboot 0x81000000 6F01A8C0.img
hornet> bootm 0x81000000
Links
-----
* http://www.tp-link.com/en/products/details/?model=TL-MR3020
* http://wiki.openwrt.org/toh/tp-link/tl-mr3020
* https://wikidevi.com/wiki/TP-LINK_TL-MR3020
See also
* http://www.eeboard.com/wp-content/uploads/downloads/2013/08/AR9331.pdf
* http://squonk42.github.io/TL-WR703N/

View File

@ -0,0 +1,54 @@
chumbyone Chumby Industrie's Falconwing
=======================================
This device is also known as "chumby one" (http://www.chumby.com/)
This CPU card is based on a Freescale i.MX23 CPU. The card is shipped with:
* 64 MiB synchronous dynamic RAM (DDR type)
Memory layout when barebox is running:
* 0x40000000 start of SDRAM
* 0x40000100 start of kernel's boot parameters
* below malloc area: stack area
* below barebox: malloc area
* 0x42000000 start of barebox
How to get the bootloader binary image
--------------------------------------
Using the default configuration::
make ARCH=arm chumbyone_defconfig
Build the bootloader binary image::
make ARCH=arm CROSS_COMPILE=armv5compiler
**NOTE:** replace the armv5compiler with your ARM v5 cross compiler.
How to prepare an MCI card to boot the "chumby one" with barebox
----------------------------------------------------------------
* Create four primary partitions on the MCI card
* the first one for the bootlets (about 256 kiB)
* the second one for the persistant environment (size is up to you, at least 256k)
* the third one for the kernel (2 MiB ... 4 MiB in size)
* the fourth one for the root filesystem which can fill the rest of the available space
* Mark the first partition with the partition ID "53" and copy the
bootlets into this partition (currently not part of barebox!).
* Copy the default barebox environment into the second partition
(no filesystem required).
* Copy the kernel into the third partition (no filesystem required).
* Create the root filesystem in the fourth partition. You may copy an
image into this partition or you can do it in the classic way:
mkfs on it, mount it and copy all required data and programs into
it.

View File

@ -0,0 +1,30 @@
Freescale i.MX23 evaluation kit
===============================
This CPU card is based on an i.MX23 CPU. The card is shipped with:
* 32 MiB synchronous dynamic RAM (mobile DDR type)
* ENC28j60 based network (over SPI)
Memory layout when barebox is running:
* 0x40000000 start of SDRAM
* 0x40000100 start of kernel's boot parameters
* below malloc area: stack area
* below barebox: malloc area
* 0x41000000 start of barebox
How to get the bootloader binary image
--------------------------------------
Using the default configuration::
make ARCH=arm imx23evk_defconfig
Build the bootloader binary image::
make ARCH=arm CROSS_COMPILE=armv5compiler
**NOTE:** replace the armv5compiler with your ARM v5 cross compiler.

View File

@ -0,0 +1,53 @@
KARO TX28 CPU module
====================
The CPU module
--------------
http://www.karo-electronics.de/
This CPU card is based on a Freescale i.MX28 CPU. The card is shipped with:
* 128 MiB synchronous dynamic RAM (DDR2 type), 200 MHz support
* 128 MiB NAND K9F1G08U0A (3.3V type)
* PCA9554 GPIO expander
* DS1339 RTC
* LAN8710 PHY
Supported baseboards
--------------------
Supported baseboards are:
* KARO's Starterkit 5
How to get barebox for 'KARO's Starterkit 5'
--------------------------------------------
Using the default configuration::
make ARCH=arm tx28stk5_defconfig
Build the binary image::
make ARCH=arm CROSS_COMPILE=armv5compiler
**NOTE:** replace the armv5compiler with your ARM v5 cross compiler.
**NOTE:** to use the result, you also need the following resources from Freescale:
* the 'bootlets' archive
* the 'elftosb2' encryption tool
* in the case you want to start barebox from an attached SD card
the 'sdimage' tool from Freescale's 'uuc' archive.
Memory layout when barebox is running
-------------------------------------
* 0x40000000 start of SDRAM
* 0x40000100 start of kernel's boot parameters
* below malloc area: stack area
* below barebox: malloc area
* 0x47000000 start of barebox

View File

@ -0,0 +1,41 @@
Texas Instruments OMAP/AM335x
=============================
Texas Instruments OMAP SoCs have a two-stage boot process. The first stage is
known as Xload which only loads the second stage bootloader. barebox can act as
both the first and the second stage loader. To build as a first stage loader,
build the \*_xload_defconfig for your board; for second stage, build the normal
\*_defconfig for your board.
Bootstrapping a PandaBoard
--------------------------
The PandaBoard boots from SD card. The OMAP Boot ROM code loads a file named
'MLO' on a bootable FAT partition on this card. There are several howtos and
scripts on the net which describe how to prepare such a card (it needs
special partitioning). The same procedure can be used for barebox. With such a
card (assumed to be at /dev/sdc), the following can be used to build and install
barebox::
# mount -t fat /dev/sdc1 /mnt
# make panda_xload_defconfig
# make
# cp barebox.bin.ift /mnt/MLO
# make panda_defconfig
# make
# cp barebox.bin /mnt/barebox.bin
# umount /mnt
Bootstrapping a BeagleBoard is the same with the corresponding BeagleBoard defconfigs.
Networking
----------
The original BeagleBoard does not have Ethernet (the newer BeagleBoard-xM does),
but a USB Ethernet dongle can be used for networking. The PandaBoard has an
integrated USB Ethernet converter which behaves exactly like an external dongle.
Barebox does not automatically detect USB devices as this would have bad effects
on boot time when USB is not needed.
So you have to use the [[commands:usb|usb]] command to trigger USB detection.
After this a network device should be present which can be used with the normal
[[commands:dhcp|dhcp]] and [[commands:tftp|tftp]] commands.

View File

@ -0,0 +1,89 @@
DIGI a9m2440
============
This CPU card is based on a Samsung S3C2440 CPU. The card is shipped with:
* S3C2440\@400 MHz or 533 MHz (ARM920T/ARMv4T)
* 16.9344 MHz crystal reference
* SDRAM 32/64/128 MiB
* Samsung K4M563233E-EE1H (one or two devices for 32 MiB or 64 MiB)
* 2M x 32bit x 4 Banks Mobile SDRAM
* CL2\@100 MHz (CAS/RAS delay 19ns)
* 105 MHz max
* column address size is 9 bits
* Row cycle time: 69ns
* Samsung K4M513233C-DG75 (one or two devices for 64 MiB or 128 MiB)
* 4M x 32bit x 4 Banks Mobile SDRAM
* CL2\@100MHz (CAS/RAS delay 18ns)
* 111 MHz max
* column address size is 9 bits
* Row cycle time: 63ns
* 64ms refresh period (4k)
* 90 pin FBGA
* 32 bit data bits
* Extended temperature range (-25°C...85°C)
* NAND Flash 32/64/128 MiB
* Samsung KM29U512T (NAND01GW3A0AN6)
* 64 MiB 3,3V 8-bit
* ID: 0xEC, 0x76, 0x??, 0xBD
* Samsung KM29U256T
* 32 MiB 3,3V 8-bit
* ID: 0xEC, 0x75, 0x??, 0xBD
* ST Micro
* 128 MiB 3,3V 8-bit
* ID: 0x20, 0x79
* 30ns/40ns/20ns
* I2C interface, 100 KHz and 400 KHz
* Real Time Clock
* Dallas DS1337
* address 0x68
* EEPROM
* ST M24LC64
* address 0x50
* 16bit addressing
* LCD interface
* Touch Screen interface
* Camera interface
* I2S interface
* AC97 Audio-CODEC interface
* SD card interface
* 3 serial RS232 interfaces
* Host and device USB interface, USB1.1 compliant
* Ethernet interface
* 10Mbps, Cirrus Logic, CS8900A (on the CPU card)
* SPI interface
* JTAG interface
How to get the binary image
---------------------------
Configure with the default configuration::
make ARCH=arm a9m2440_defconfig
Build the binary image::
make ARCH=arm CROSS_COMPILE=armv4compiler
**NOTE:** replace the armv4compiler with your ARM v4 cross compiler.

View File

@ -0,0 +1,9 @@
Samsung S3C/S5P
===============
.. toctree::
:glob:
:numbered:
:maxdepth: 1
s3c/*

View File

@ -0,0 +1,55 @@
Sandbox
=======
barebox can be run as a simulator on your host to check and debug new non
hardware related features.
Building barebox for simulation
-------------------------------
The barebox sandbox can be built with the host compiler::
ARCH=sandbox make sandbox_defconfig
ARCH=sandbox make
Running the sandbox
-------------------
Once you compile barebox for the sandbox, you can run it with::
$ barebox [<OPTIONS>]
Available sandbox invocation options include:
``-m``, ``--malloc=<size>``
Start sandbox with a specified malloc-space <size> in bytes.
``-i <file>``
Map a <file> to barebox. This option can be given multiple times. The <file>s
will show up as ``/dev/fd0`` ... ``/dev/fdX`` in the barebox simulator.
``-e <file>``
Map <file> to barebox. With this option <file>s are mapped as
``/dev/env0`` ... ``/dev/envX`` and thus are used as default environment.
A clean file generated with ``dd`` will do to get started with an empty environment.
``-O <file>``
Register <file> as a console capable of doing stdout. <file> can be a
regular file or a FIFO.
``-I <file>``
Register <file> as a console capable of doing stdin. <file> can be a regular
file or a FIFO.
``-x``, ``--xres <res>``
Specify SDL width.
``-y``, ``--yres <res>``
Specify SDL height.

View File

@ -0,0 +1,102 @@
.. highlight:: console
Nvidia Tegra
============
Building
--------
All currently supported Tegra boards are integrated in a single
multi-image build (:ref:`multi_image`). Building is as easy as typing:
.. code-block:: sh
make ARCH=arm tegra_v7_defconfig
make ARCH=arm CROSS_COMPILE=arm-v7-compiler-
**NOTE:** replace the arm-v7-compiler- with your ARM v7 cross compiler.
Tegra images are specific to the bootsource. The build will generate images for
all combinations of bootsources and supported boards. You can find the
completed images in the ``images/`` subdirectory.
The naming scheme consists of the triplet tegracodename-boardname-bootsource
Kickstarting a board using USB
------------------------------
The tool needed to transfer and start a bootloader image to any Tegra board
using the USB boot mode is called TegraRCM. Most likely this isn't available
from your distributions repositories. You can get and install it by running the
following commands:
.. code-block:: sh
git clone https://github.com/NVIDIA/tegrarcm.git
cd tegrarcm
./autogen.sh
make
sudo make install
Connect the board to your host via the USB OTG port.
The next step is to bring the device into USB boot mode. On developer boards
this could normally be done by holding down a force recovery button (or setting
some jumper) while resetting the board. On other devices you are on your own
finding out how to achieve this.
The tegrarcm tool has 3 basic options:
.. code-block:: none
--bct : the BCT file needed for basic hardware init,
this can be found in the respective board directory
--bootloader : the actual barebox image
use the -usbloader image
--loadaddr : start address of the barebox image
use 0x00108000 for Tegra20 aka Tegra2 devices
use 0x80108000 for all other Tegra devices
An example command line for the NVIDIA Beaver board looks like this:
.. code-block:: sh
tegrarcm --bct arch/arm/boards/nvidia-beaver/beaver-2gb-emmc.bct \
--bootloader images/barebox-tegra30-nvidia-beaver-usbloader.img \
--loadaddr 0x80108000
You should now see barebox coming up on the serial console.
Writing barebox to the primary boot device
------------------------------------------
**NOTE:** this may change in the near future to work with the standard
barebox update mechanism (:ref:`update`).
Copy the image corresponding to the primary boot device for your board to a
SD-card and plug it into your board.
Within the barebox shell use the standard mount and cp commands to copy the
image to the boot device.
On the NVIDIA Beaver board this looks like this:
.. code-block:: sh
barebox@NVIDIA Tegra30 Beaver evaluation board:/ mount -a
mci0: detected SD card version 2.0
mci0: registered disk0
mci1: detected MMC card version 4.65
mci1: registered disk1.boot0
mci1: registered disk1.boot1
mci1: registered disk1
ext4 ext40: EXT2 rev 1, inode_size 128
ext4 ext41: EXT2 rev 1, inode_size 256
ext4 ext42: EXT2 rev 1, inode_size 256
none on / type ramfs
none on /dev type devfs
/dev/disk0.0 on /mnt/disk0.0 type ext4
/dev/disk0.1 on /mnt/disk0.1 type ext4
/dev/disk1.1 on /mnt/disk1.1 type ext4
barebox@NVIDIA Tegra30 Beaver evaluation board:/ cp /mnt/disk0.0/barebox-tegra30-nvidia-beaver-emmc.img /dev/disk1.boot0
That's it: barebox should come up after resetting the board.

View File

@ -0,0 +1,141 @@
x86
===
Features
--------
barebox can act as a bootloader for PC based systems. In this case a special
binary layout will be created to be able to store it on some media the PC
BIOS can boot from. It can boot Linux kernels stored also on the same boot
media and be configured at runtime, with the possibility to store the changed
configuration on the boot media.
Restrictions
------------
Due to some BIOS and barebox restrictions the boot media must be
prepared in some special way:
* barebox must be stored in the MBR (Master Boot Record) of the boot
media. Currently its not possible to store and boot it in one of
the partition sectors to use it as a second stage loader). This is
no eternal restriction. It only needs further effort to add this
feature.
* barebox currently cannot run a chained boot loader. Also, this is
no external restriction, only further effort needed.
* barebox comes with limited filesystem support. There is currently
no support for the most common and popular filesystems used in the
\*NIX world. This restricts locations where to store a kernel and
other runtime information
* barebox must be stored to the first n sectors of the boot media.
To ensure this does not collide with partitions on the boot media,
the first partition must start at a sector behind the ones barebox
occupies.
* barebox handles its runtime configuration in a special way: It
stores it in a binary way into some reserved sectors ("persistant
storage").
Boot Preparations
-----------------
To store the barebox image to a boot media, it comes with the tool
setupmbr in the directory scripts/setupmbr/ . To be able to use it on
the boot media of your choice, some preparations are required.
Keep Sectors free
-----------------
Build the barebox image and check its size. At least this amount of
sectors must be kept free after the MBR prior the first partition. Do this
simple calulation::
sectors = (\<size of barebox image\> + 511) / 512
To be able to store the runtime configuration, further free sectors are
required. Its up to you and your requirements, how large this persistant
storage must be. If you need 16 kiB for this purpose, you need to keep
additional 32 sectors free.
For this example we are reserving 300 sectors for the barebox image and
additionaly 32 sectors for the persistant storage. So, the first partition on
the boot media must start at sector 333 or later.
Run the fdisk tool to setup such a partition table::
[jb@host]~> fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 20.7 MB, 212680704 bytes
16 heads, 63 sectors/track, 406 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Device Boot Start End Blocks Id System
Change the used units to sectors for easier handling.
::
Command (m for help): u
Changing display/entry units to sectors
Command (m for help): p
Disk /dev/sda: 20.7 MB, 212680704 bytes
16 heads, 63 sectors/track, 406 cylinders, total 409248 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
Now its possible to create the first partition with the required offset::
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First sector (63-409247, default 63): 333
Last sector or +size or +sizeM or +sizeK (333-409247, default 409247): +18M
Command (m for help): p
Disk /dev/sda: 20.7 MB, 212680704 bytes
16 heads, 63 sectors/track, 406 cylinders, total 409248 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda 333 35489 17578+ 83 Linux
That's all. Do whatever is required now with the new partition (formatting
and populating the root filesystem for example) to make it useful.
In the next step, barebox gets installed to this boot media::
[jb@host]~> scripts/setupmbr/setupmbr -s 32 -m ./barebox -d /dev/sda
This command writes the barebox image file './barebox' onto the device
/dev/sda.
The -s option will keep the persistant storage sectors free and untouched
and set flags in the MBR to forward its existance, size and location to
barebox at runtime. setupmbr also does not change the partition table.
The barebox image gets stored on the boot media like this::
sector 0 1 33 333
|---|-------------|--------------- ~~~ ------------|--------------
MBR persistant barebox first
storage main image partition
If the -s option is omitted, the "persistant storage" part simply does
not exist::
sector 0 1 333
|---|--------------- ~~~ ------------|--------------
MBR barebox first
main image partition
**NOTE:** the ``setupmbr`` tool is also working on real image file than on device
nodes only. So, there is no restriction what kind of file will be
modified.

View File

@ -1,60 +0,0 @@
/** @page building Building
<i>This section describes how to build the Barebox bootloader.</i>
@a Barebox uses Kconfig/Kbuild from the Linux kernel to build it's
sources. It consists of two parts: the makefile infrastructure (kbuild)
and a configuration system (kconfig). So building @a barebox is very
similar to building the Linux kernel.
In the examples below we use the "sandbox" configuration, which is a
port of @a Barebox to the Linux userspace. This makes it possible to
test the code without having real hardware or even qemu. Note that the
sandbox architecture does only work well on x86 and has some issues on
x86_64.
\todo Find out about issues on x86_64.
Selecting the architecture and the corresponding cross compiler is done
by setting the following environment variables:
- ARCH=\<architecture>
- CROSS_COMPILE=\<compiler-prefix>
For @p ARCH=sandbox we do not need a cross compiler, so it is sufficient
to specify the architecture:
@code
# export ARCH=sandbox
@endcode
In order to configure the various aspects of @a barebox, start the
@a barebox configuration system:
@code
# make menuconfig
@endcode
This command starts a menu box and lets you select all the different
options available for the selected architecture. Once the configuration
is finished (you can simulate this by using the default config file with
'make sandbox_defconfig'), there is a .config file in the toplevel
directory of the sourcecode.
After @a barebox is configured, we can start the compilation:
@code
# make
@endcode
You can use '-j \<n\>' in order to do a parallel build if you have more
than one cpus.
If everything goes well, the result is a file called @p barebox:
@code
# ls -l barebox
-rwxr-xr-x 1 rsc ptx 114073 Jun 26 22:34 barebox
@endcode
*/

View File

@ -1,111 +0,0 @@
/**
* @page command_reference Shell Commands
<i>This section describes the commands which are available on the @a
Barebox shell. </i>
@a Barebox, as a bootloader, usually shall start the Linux kernel right
away. However, there are several use cases around which make it
necessary to have some (customizable) logic and interactive scripting
possibilities. In order to achieve this, @a Barebox offers several
commands on it's integrated commandline shell.
The following alphabetically sorted list documents all commands
available in @a Barebox:
\todo Sort this by functionality?
@li @subpage _name
@li @subpage addpart_command
@li @subpage alternate
@li @subpage bootm_command
@li @subpage bootu
@li @subpage bootz
@li @subpage cat_command
@li @subpage cd_command
@li @subpage clear_command
@li @subpage clko
@li @subpage cp_command
@li @subpage cpufreq
@li @subpage cpuinfo
@li @subpage crc_command
@li @subpage crc32
@li @subpage delpart_command
@li @subpage devinfo_command
@li @subpage dfu_command
@li @subpage dhcp
@li @subpage dump_clocks
@li @subpage echo_command
@li @subpage edit_command
@li @subpage erase_command
@li @subpage ethact
@li @subpage exec
@li @subpage exit
@li @subpage export_command
@li @subpage false
@li @subpage getopt
@li @subpage gpio_get_value_command
@li @subpage gpio_set_value_command
@li @subpage gpio_direction_input_command
@li @subpage gpio_direction_output_command
@li @subpage go
@li @subpage help
@li @subpage host
@li @subpage i2c_probe
@li @subpage i2c_read
@li @subpage i2c_write
@li @subpage icache
@li @subpage iminfo
@li @subpage insmod
@li @subpage linux16_command
@li @subpage loadenv_command
@li @subpage loadb
@li @subpage loady
@li @subpage loadxc
@li @subpage login
@li @subpage ls_command
@li @subpage lsmod
@li @subpage md
@li @subpage memcmp
@li @subpage meminfo
@li @subpage memset
@li @subpage menu
@li @subpage mkdir
@li @subpage mount_command
@li @subpage mtest
@li @subpage mw
@li @subpage mycdev
@li @subpage nand
@li @subpage nand_boot_test
@li @subpage nfs
@li @subpage passwd
@li @subpage ping
@li @subpage printenv_command
@li @subpage protect_command
@li @subpage pwd
@li @subpage readline
@li @subpage reset
@li @subpage rarpboot
@li @subpage reginfo
@li @subpage rm
@li @subpage rmdir
@li @subpage saveenv_command
@li @subpage setenv_command
@li @subpage sh
@li @subpage sleep
@li @subpage source
@li @subpage splash_command
@li @subpage test
@li @subpage timeout
@li @subpage true
@li @subpage tftp_command
@li @subpage ubiattach
@li @subpage ubimkvol
@li @subpage ubirmvol
@li @subpage umount
@li @subpage unlzo
@li @subpage unprotect_command
@li @subpage usb
@li @subpage version
*/

View File

@ -0,0 +1,9 @@
Command reference
=================
.. toctree::
:glob:
:maxdepth: 1
commands/*

262
Documentation/conf.py Normal file
View File

@ -0,0 +1,262 @@
# -*- coding: utf-8 -*-
#
# barebox documentation build configuration file, created by
# sphinx-quickstart on Tue Jun 17 11:45:57 2014.
#
# This file is execfile()d with the current directory set to its
# containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#sys.path.insert(0, os.path.abspath('.'))
# -- General configuration ------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
# ones.
extensions = []
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'barebox'
copyright = u'2014, The barebox project'
# The version info for the project you're documenting, acts as replacement for
# |version| and |release|, also used in various other places throughout the
# built documents.
#
# The short X.Y version.
import os
version = os.environ["KERNELVERSION"]
# The full version, including alpha/beta/rc tags.
release = os.environ["KERNELRELEASE"]
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = []
# The reST default role (used for this markup: `text`) to use for all
# documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
#add_module_names = True
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
#show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
#modindex_common_prefix = []
# If true, keep warnings as "system message" paragraphs in the built documents.
#keep_warnings = False
# -- Options for HTML output ----------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'default'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
# html_static_path = ['_static']
# Add any extra paths that contain custom files (such as robots.txt or
# .htaccess) here, relative to this directory. These files are copied
# directly to the root of the documentation.
#html_extra_path = []
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
#html_last_updated_fmt = '%b %d, %Y'
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
#html_domain_indices = True
# If false, no index is generated.
#html_use_index = True
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'bareboxdoc'
# -- Options for LaTeX output ---------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title,
# author, documentclass [howto, manual, or own class]).
latex_documents = [
('index', 'barebox.tex', u'barebox Documentation',
u'The barebox project', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for manual page output ---------------------------------------
# One entry per manual page. List of tuples
# (source start file, name, description, authors, manual section).
man_pages = [
('index', 'barebox', u'barebox Documentation',
[u'The barebox project'], 1)
]
# If true, show URL addresses after external links.
#man_show_urls = False
# -- Options for Texinfo output -------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'barebox', u'barebox Documentation',
u'The barebox project', 'barebox', 'One line description of project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# If true, do not generate a @detailmenu in the "Top" node's menu.
#texinfo_no_detailmenu = False
highlight_language = 'c'

View File

@ -1,13 +0,0 @@
-------------- barebox consoles ------------------
barebox supports multiple consoles which may be simultaneously active.
Depending on the configuration none, the first or all consoles are
activated on startup, see CONSOLE_ACTIVATE_FIRST and CONSOLE_ACTIVATE_ALL
options.
During runtime the behaviour of the consoles can be controlled with the
'active' parameter each console has. The console system recognizes three
characters: 'i' for stdin, 'o' for stdout and 'e' for stderr. These options
may be concatenated together as needed, so setting an 'active' parameter
of a console to 'io' would enable it for stdout and stdin while leaving
stderr disabled.

View File

@ -1,24 +0,0 @@
/** @page developers_manual Developer's Manual
This part of the documentation is intended for developers of @a barebox.
@section devel_backgrounds Some background knowledge for some frameworks barebox
@li @subpage driver_model
@li @subpage dev_params
@section devel_hints Hints and tips for simply adapting barebox
@li @subpage dev_architecture
@li @subpage dev_cpu
@li @subpage dev_board
@section devel_themes Various themes about barebox
@li @subpage how_mount_works
@li @subpage boot_preparation
@li @subpage barebox_simul
@li @subpage io_access_functions
@li @subpage mcfv4e_MCDlib
*/

View File

@ -1,72 +0,0 @@
---------- Devices and drivers in barebox --------------
We follow a rather simplistic driver model here. There is a struct device which
describes a particular device present in the system. A struct driver represents
a driver present in the system. Both structs find together via the members
'type' (int) and 'name' (char *). If both members match, the driver's probe
function is called with the struct device as argument. People familiar with
the Linux platform bus will recognize this behaviour and in fact many things were
stolen from there. Some selected members of the structs will be described in this
document.
Currently all devices and drivers are handled in simple linked lists. When it comes
to USB or PCI it may be desirable to have a tree structure, but this may also be
unnecessary overhead.
struct device
-------------
char name[MAX_DRIVER_NAME];
This member (and 'type' described below) is used to match with a driver. This is
a descriptive name and could be MPC5XXX_ether or imx_serial.
char id[MAX_DRIVER_NAME];
The id is used to uniquely identify a device in the system. The id will show up
under /dev/ as the device's name. Usually this is something like eth0 or nor0.
void *type_data;
Devices of a particular class normaly need to store more information than struct
device holds. This entry holds a pointer to the type specific struct.
void *priv;
Used by the device driver to store private information.
void *platform_data;
This is used to carry information of board specific data from the board code to the
device driver.
struct param_d *param;
The parameters for this device. See Documentation/parameters.txt for more info.
struct driver_d
---------------
char name[MAX_DRIVER_NAME];
unsigned long type;
See above.
int (*probe) (struct device_d *);
int (*remove)(struct device_d *);
These are called if an instance of a device is found or gone.
ssize_t (*read) (struct device_d*, void* buf, size_t count, ulong offset, ulong flags);
ssize_t (*write) (struct device_d*, const void* buf, size_t count, ulong offset, ulong flags);
The standard read/write functions. These are called as a response to the read/write
system calls. No driver needs to implement these.
void *type_data;
This is somewhat redundant with the type data in struct device. Currently the
filesystem implementation uses this field while ethernet drivers use the same
field in struct device. Probably one of them should be removed.

View File

@ -1,10 +0,0 @@
barebox specific devicetree bindings
====================================
barebox uses some barebox specific devicetree bindings. All of these
are under the /chosen/ hierarchy in the devicetree.
The bindings have the form of a device with regular 'compatible' properties.
drivers matching these devices do not handle physical devices but instead
influence / configure certain behaviours of barebox like the place where to
find the persistent environment.

View File

@ -0,0 +1,26 @@
barebox environment
===================
This driver provides an environment for barebox from the devicetree.
Required properties:
* ``compatible``: should be ``barebox,environment``
* ``device-path``: path to the environment
The device-path is a multistring property. The first string should be a
nodepath to the node containing the physical device of the environment.
The subsequent strings are of the form <type>:<options> to further describe
the path to the environment. Supported values for <type>:
``partname``:<partname>
This describes a partition on a device. <partname> can
be the label for MTD partitions, the number for DOS
partitions (beginning with 0) or the name for GPT partitions.
Example::
environment@0 {
compatible = "barebox,environment";
device-path = &flash, "partname:barebox-environment";
};

View File

@ -1,25 +0,0 @@
barebox environment
===================
This driver provides an environment for barebox from the devicetree.
Required properties:
- compatible: should be "barebox,environment"
- device-path: path to the environment
The device-path is a multistring property. The first string should be a
nodepath to the node containing the physical device of the environment.
The subsequent strings are of the form <type>:<options> to further describe
the path to the environment. Supported values for <type>:
partname:<partname> This describes a partition on a device. <partname> can
be the label for mtd partitions, the number for DOS
partitions (beginning with 0) or the name for GPT
partitions
Example:
environment@0 {
compatible = "barebox,environment";
device-path = &flash, "partname:barebox-environment";
};

View File

@ -0,0 +1,10 @@
Common leds properties
======================
* ``linux,default-trigger``, ``barebox,default-trigger``: This parameter, if present, is a
string defining the trigger assigned to the LED. Current triggers are:
* ``heartbeat`` - LED flashes at a constant rate
* ``panic`` - LED turns on when barebox panics
* ``net`` - LED indicates network activity

View File

@ -1,8 +0,0 @@
Common leds properties.
- linux,default-trigger barebox,default-trigger: This parameter, if present, is a
string defining the trigger assigned to the LED. Current triggers are:
"heartbeat" - LED flashes at a constant rate
"panic" - LED turns on when barebox panics
"net" - LED indicates network activity

View File

@ -0,0 +1,21 @@
Freescale i.MX IIM (Ic Identification Module)
=============================================
Required properties:
* ``compatible``: ``fsl,imx27-iim``, ``fsl,imx51-iim``
* ``reg``: physical register base and size
Optional properties:
* ``barebox,provide-mac-address``: Provide MAC addresses for Ethernet devices. This
can be multiple entries in the form <&phandle bankno fuseofs> to assign a MAC
address to an Ethernet device.
Example::
iim: iim@83f98000 {
compatible = "fsl,imx51-iim", "fsl,imx27-iim";
reg = <0x83f98000 0x4000>;
barebox,provide-mac-address = <&fec 1 9>;
};

View File

@ -1,20 +0,0 @@
Freescale i.MX IIM (Ic Identification Module)
Required properties:
- compatible: fsl,imx27-iim
- reg: physical register base and size
Optional properties:
- barebox,provide-mac-address: Provide MAC addresses for ethernet devices. This
can be multiple entries in the form <&phandle bankno fuseofs> to specify a MAC
address to a ethernet device.
Example:
iim: iim@83f98000 {
compatible = "fsl,imx51-iim", "fsl,imx27-iim";
reg = <0x83f98000 0x4000>;
barebox,provide-mac-address = <&fec 1 9>;
};

View File

@ -0,0 +1,21 @@
Freescale i.MX OCOTP (On-Chip OTP)
==================================
Required properties:
* ``compatible``: ``fsl,imx6q-ocotp``
* ``reg``: physical register base and size
Optional properties:
* ``barebox,provide-mac-address``: Provide MAC addresses for Ethernet devices. This
can be multiple entries in the form <&phandle regofs> to assign a MAC
address to an Ethernet device.
Example::
ocotp1: ocotp@021bc000 {
compatible = "fsl,imx6q-ocotp";
reg = <0x021bc000 0x4000>;
barebox,provide-mac-address = <&fec 0x620>;
};

View File

@ -1,20 +0,0 @@
Freescale i.MX OCOTP (On-Chip OTP)
Required properties:
- compatible: fsl,imx6q-ocotp
- reg: physical register base and size
Optional properties:
- barebox,provide-mac-address: Provide MAC addresses for ethernet devices. This
can be multiple entries in the form <&phandle regofs> to specify a MAC
address to a ethernet device.
Example:
ocotp1: ocotp@021bc000 {
compatible = "fsl,imx6q-ocotp";
reg = <0x021bc000 0x4000>;
barebox,provide-mac-address = <&fec 0x620>;
};

View File

@ -0,0 +1,13 @@
Barebox specific devicetree bindings
====================================
Contents:
.. toctree::
:glob:
:numbered:
:maxdepth: 1
bindings/barebox/*
bindings/leds/*
bindings/misc/*

View File

@ -0,0 +1,10 @@
.. _filesystems:
Filesystems
===========
.. toctree::
:maxdepth: 2
:glob:
filesystems/*

View File

@ -0,0 +1,15 @@
.. index:: fat (filesystem)
FAT filesystem
==============
barebox supports FAT filesystems in both read and write modes with optional
support for long filenames. A FAT filesystem can be mounted using the
:ref:`command_mount` command::
mkdir /mnt
mount /dev/disk0.0 fat /mnt
ls /mnt
zImage barebox.bin
umount /mnt

View File

@ -0,0 +1,12 @@
.. index:: nfs (filesystem)
.. _filesystems_nfs:
NFS Support
===========
barebox has readonly support for NFSv3 in UDP mode.
Example::
mount -t nfs 192.168.23.4:/home/user/nfsroot /mnt/nfs

View File

@ -0,0 +1,12 @@
.. index:: ramfs (filesystem)
RAM filesystem
==============
ramfs is a simple malloc-based filesystem. An instance of ramfs is
mounted during startup on /. The filesystem type passed to ``mount``
is ``ramfs``.
Example::
mount none ramfs /somedir

View File

@ -0,0 +1,16 @@
.. index:: tftp (filesystem)
.. _filesystems_tftp:
TFTP support
============
barebox has read/write support for the Trivial File Transfer Protocol.
TFTP is not designed as a filesystem. It does not have support for listing
directories. This means a :ref:`command_ls` to a TFTP-mounted path will show an empty
directory. Nevertheless, the files are there.
Example::
mount -t tftp 192.168.23.4 /mnt/tftp

View File

@ -1,61 +0,0 @@
/** @page first_steps First Steps
<i>This section demonstrates the first steps with the 'sandbox'
platform. </i>
@a barebox usually needs an environment for storing its configuration.
You can generate an environment using the example environment contained
in arch/sandbox/board/env:
@code
# ./scripts/bareboxenv -s -p 0x10000 arch/sandbox/board/env/ env.bin
@endcode
To get some files to play with you can generate a cramfs image:
@code
# mkcramfs somedir/ cramfs.bin
@endcode
The @a barebox image is a normal Linux executable, so it can be started
just like every other program:
@code
# ./barebox -e env.bin -i cramfs.bin
barebox 2010.10.0 (Oct 29 2010 - 13:47:17)
loading environment from /dev/env0
barebox\> /
@endcode
Specifying -[ie] \<file\> tells @a barebox to map the file as a device
under @p /dev. Files given with '-e' will appear as @p /dev/env[n]. Files
given with '-i' will appear as @p /dev/fd[n].
If @a barebox finds a valid configuration sector on @p /dev/env0, it
will be loaded into @p /env and executes @p /env/init if existing.
The default environment from the example above will show up a menu
asking for the relevant settings.
If you have started @a barebox as root you will find a new tap device on
your host which you can configure using ifconfig. Once configured with
valid network addresses, barebox can be used to ping the host machine or
to fetch files with tftp.
\todo Add more about tun/tap configuration
If you have mapped a cramfs image, try mounting it with
@code
# mkdir /cram
# mount /dev/fd0 cramfs /cram
@endcode
Memory can be examined using @p md/mw commands. They both understand the
-f \<file\> option to tell the commands that they should work on the
specified files instead of @p /dev/mem (which holds the complete address
space). Note that if you call 'md /dev/fd0' (without -f), @a barebox will
segfault on the host, because it will interpret @p /dev/fd0 as a number.
*/

164
Documentation/gen_commands.py Executable file
View File

@ -0,0 +1,164 @@
#!/usr/bin/python
import os
import re
import sys
from collections import defaultdict
from pprint import pprint
# TODO: handle commands with the same name in multiple files
# TODO: handle #ifdefs
HELP_START = re.compile(r"""^BAREBOX_CMD_HELP_START\s*\((\w+)\)?\s*$""")
HELP_TEXT = re.compile(r"""^BAREBOX_CMD_HELP_TEXT\s*\("(.*?)"\)?\s*$""")
HELP_OPT = re.compile(r"""^BAREBOX_CMD_HELP_OPT\s*\("(.+?)",\s*"(.+?)"\)?\s*$""")
HELP_END = re.compile(r"""^BAREBOX_CMD_HELP_END\s*$""")
CMD_START = re.compile(r"""^BAREBOX_CMD_START\s*\((.+)\)\s*$""")
CMD_FUNC = re.compile(r"""^\s*\.cmd\s*=\s*(.+?),\s*$""")
CMD_DESC = re.compile(r"""^\s*BAREBOX_CMD_DESC\s*\("(.*?)"\)?\s*$""")
CMD_OPTS = re.compile(r"""^\s*BAREBOX_CMD_OPTS\s*\("(.*?)"\)?\s*$""")
CMD_GROUP = re.compile(r"""^\s*BAREBOX_CMD_GROUP\s*\((.+)\)\s*$""")
CMD_END = re.compile(r"""^BAREBOX_CMD_END\s*$""")
CONT = re.compile(r"""\s*"(.*?)"\s*\)?\s*$""")
CMDS = {}
def parse_c(name):
cmd = None
last = None
for line in file(name, 'r'):
x = HELP_START.match(line)
if x:
cmd = CMDS.setdefault(x.group(1), defaultdict(list))
cmd.setdefault("files", set()).add(name)
continue
x = CMD_START.match(line)
if x:
cmd = CMDS.setdefault(x.group(1), defaultdict(list))
cmd.setdefault("files", set()).add(name)
continue
if cmd is None:
continue
x = HELP_TEXT.match(line)
if x:
if 'h_opts' not in cmd:
last = cmd['h_pre']
else:
last = cmd['h_post']
last.append(x.group(1).decode("string_escape").strip())
continue
x = HELP_OPT.match(line)
if x:
last = cmd['h_opts']
last.append([
x.group(1).decode("string_escape"),
x.group(2).decode("string_escape")
])
continue
x = CMD_FUNC.match(line)
if x:
last = cmd['c_func']
last.append(x.group(1))
continue
x = CMD_DESC.match(line)
if x:
last = cmd['c_desc']
last.append(x.group(1).decode("string_escape"))
continue
x = CMD_OPTS.match(line)
if x:
last = cmd['c_opts']
last.append(x.group(1).decode("string_escape"))
continue
x = CMD_GROUP.match(line)
if x:
last = cmd['c_group']
last.append(x.group(1).decode("string_escape"))
continue
x = CONT.match(line)
if x:
if last is None:
raise Exception("Parse error in %s: %r" % (name, line))
if isinstance(last[-1], str):
last[-1] += x.group(1).decode("string_escape")
elif isinstance(last[-1], list):
last[-1][1] += x.group(1).decode("string_escape")
continue
x = HELP_END.match(line)
if x:
cmd = last = None
x = CMD_END.match(line)
if x:
cmd = last = None
def gen_rst(name, cmd):
out = []
out.append('.. index:: %s (command)' % name)
out.append('')
out.append('.. _command_%s:' % name)
out.append('')
if 'c_desc' in cmd:
out.append("%s (%s)" % (name, ''.join(cmd['c_desc']).strip()))
else:
out.append("%s" % (name,))
out.append('='*len(out[-1]))
out.append('')
if 'c_opts' in cmd:
out.append('Usage')
out.append('^'*len(out[-1]))
out.append('``%s %s``' % (name, ''.join(cmd['c_opts']).strip()))
out.append('')
if 'h_pre' in cmd:
pre = cmd['h_pre']
if pre and pre[-1] == "Options:":
del pre[-1]
if pre and pre[-1] == "":
del pre[-1]
if pre:
out.append('Synopsis')
out.append('^'*len(out[-1]))
out.append('\n'.join(cmd['h_pre']).strip())
out.append('')
if 'h_opts' in cmd:
out.append('Options')
out.append('^'*len(out[-1]))
for o, d in cmd['h_opts']:
o = o.strip()
d = d.strip()
if o:
out.append('%s\n %s' % (o, d))
else:
out.append(' %s' % (d,))
out.append('')
if 'h_post' in cmd:
post = cmd['h_post']
if post and post[0] == "":
del post[0]
if post:
out.append('Description')
out.append('^'*len(out[-1]))
out.append('\n'.join(cmd['h_post']).strip())
out.append('')
out.append('.. generated from: %s' % ', '.join(cmd['files']))
if 'c_func' in cmd:
out.append('.. command function: %s' % ', '.join(cmd['c_func']))
return '\n'.join(out)
for root, dirs, files in os.walk(sys.argv[1]):
for name in files:
if name.endswith('.c'):
source = os.path.join(root, name)
parse_c(source)
for name in CMDS.keys():
CMDS[name] = dict(CMDS[name])
for name, cmd in CMDS.items():
#pprint({name: cmd})
rst = gen_rst(name, cmd)
target = os.path.join(sys.argv[2], name+'.rst')
file(target, 'w').write(rst)

View File

@ -0,0 +1,18 @@
.. _glossary:
Glossary
========
.. glossary:: :sorted:
FDT
Flattened Device Tree
DTB
Device Tree Blob (or Binary)
DTS
Device Tree Source
PBL
Pre BootLoader image

25
Documentation/index.rst Normal file
View File

@ -0,0 +1,25 @@
.. barebox documentation master file, created by
sphinx-quickstart on Tue Jun 17 11:45:57 2014.
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Welcome to barebox
==================
Contents:
.. toctree::
:glob:
:numbered:
:maxdepth: 1
user/user-manual
filesystems
commands
boards
glossary
devicetree/*
* :ref:`search`
* :ref:`genindex`

View File

@ -1,27 +0,0 @@
/** @page manual_org Organisation of this Manual
There is no fixed organisation in this manual, as various source files forwards
their content into different parts. So there are more visible menu entries,
than listed here. But these files are the main control files:
- Documentation
- Documentation/Doxyfile
- Documentation/barebox-main.dox
- Documentation/users_manual.dox
- Documentation/commands.dox
- Documentation/developers_manual.dox
- Documentation/board.dox
- arch/architecture.dox
- arch/arm/mach-arm.dox
- arch/blackfin/mach-bf.dox
- arch/ppc/mach-ppc.dox
- Documentation/parameters.dox
- Documentation/boards.dox
- various documentation files from the board directory
New commands should forward their content to Documentation/commands.dox, so
their pages should be listed in this file.
New boards should forward their content to Documentation/boards.dox, so
their pages should be listed in this file.
*/

View File

@ -1,27 +0,0 @@
-------------- omap4_usb_booting --------------
omap4 processors have support for booting from the usb port. To be able to fully
use this feature you will need to enable the following:
OMAP4_USBBOOT
This CONFIG_ option adds the required infrastructure.
DRIVER_SERIAL_OMAP4_USBBOOT
This adds console support over the same usb port used for booting.
FS_OMAP4_USBBOOT
This adds filesystem support over the same usb port used for booting.
To send the bootloader to the processor, execute the utility omap4_usbboot which
can be found in the scripts subdirectory.
omap4_usbboot takes two parameters:
the bootloader image
a directory name which will be the root for the guest system
Once omap4_usbboot is running it will wait for enumeration of the omap4 cpu on
the host usb subsystem. Then power on or reset the cpu with the correct sys_boot
or SAR memory configuration.
If everything works, barebox's first stage will boot and afterwards it will load
the second stage found at "/barebox.bin".
Barebox's second stage will still have access to the usb filesystem, so an
initrd and a zImage can be loaded.
Overall this procedure frees the developer of continously be changing the SD
card or other boot media from host to target.

View File

@ -1,115 +0,0 @@
When porting from old barebox the follwing steps must be taken (please complain
if there's something missing here ;)
- Most of the macros in include/configs/yourboard.h can be removed, especially
the CONFIG_COMMANDS section. The goal is to remove this file entirely, but
for now some values are still needed here. If you think some things are better
configured with the Kconfig system feel free to add them there.
- The linker script needs a new section for the initcalls. The handling of the
barebox command table has changed, too. (The commands are now sorted by the
linker instead at runtime.) To change it you need an entry like the following
in your linker script:
#include <asm-generic/barebox.lds.h>
__barebox_cmd_start = .;
.barebox_cmd : { BAREBOX_CMDS }
__barebox_cmd_end = .;
__barebox_initcalls_start = .;
.barebox_initcalls : { INITCALLS }
__barebox_initcalls_end = .;
- Rename your linker script to barebox.lds.S and add the following entry to the
Makefile to make sure the linker script is generated:
extra-y += barebox.lds
- Register the devices present in your system in the board specific .c file.
To see anything you have to at least register a console. In scb9328.c this
looks like this:
static struct device_d scb9328_serial_device = {
.name = "imx_serial",
.map_base = IMX_UART1_BASE,
.size = 4096,
};
static int scb9328_console_init(void)
{
platform_device_register(&scb9328_serial_device);
return 0;
}
console_initcall(scb9328_console_init);
- For most boards you will have to register a cfi_flash device. NAND flash
is not ported yet.
- Call devfs_add_partition() to add an environment partition for your device:
devfs_add_partition("nor0", 0x40000, 0x20000, DEVFS_PARTITION_FIXED, "env0");
This will add an area starting at 0x40000 of size 0x20000 of the device
nor0 as env0.
- Port missing drivers. Depending on the driver this can a be rather simple
process:
Serial drivers
- Declare all functions static.
- in your probe function fill in a struct console_device and register it
with console_register()
Ethernet drivers
- Basically do the same as with serial drivers.
- Identify the parts of the driver which handle the MAC address. There are
now two functions handling them in struct eth_device.
get_mac_address() retrieve the MAC address from the EEPROM if one is
connected. If you don't have an EEPROM just return -1.
set_mac_address() set the MAC address in the device. All magic previously
done with getenv/setenv(ethaddr) must be removed.
During startup barebox calls get_mac_address() to see if an EEPROM is
connected. If so, it calls set_mac_address() with this address. This
is done even if networking is not used during startup. This makes sure
that the MAC address is set in the device and Linux can pick it up later.
- There is now (the beginning of) generic phy support. When porting drivers
it is recommended to use it. The phy support currently only starts generic
autonegotiation, so if you have some fancy things to do (or have gigabit
ethernet) you'll have to extend the phy layer first. Although this is
extra work, it will pay off some day, as phy support is a great source
of duplicated code. see drivers/net/dm9000.c or drivers/net/fec_mpc5200.c
for examples.
- Add a clocksource for your system. PowerPCs have a generic decrementer
counter, so if you have a PowerPC you have nothing to do here. On ARM
this is SoC dependent. See Documentation/timekeeping.txt for further
information.
- Adjust start.S. On PowerPC there is at least the Problem that the relocation
offset is defined at compile time. It is easily possible to determine the
address barebox is currently starting from at runtime and thus allowing it
barebox to be started at any address. Look at the relocation code and replace
TEXT_BASE with the following calculation of the runtime address:
bl calc_source /* Calculate Source Address */
calc_source:
mfspr r4, LR
subi r4, r4, (calc_source - _start)
subi r4, r4, 0x100
(I'm almost sure that PowerPC has a dedicated instruction for this, un-
fortunately I know next to nothing of PowerPC assembler, so if you have
a better way to archieve this, please write to the list.)
On PowerPC barebox now runs at the address it was linked to, so you have
to adjust TEXT_BASE to be in RAM. This makes the various fixup relocation
functions unnecessary. On PowerPC the removal of -fPIC saves around 10% of
binary space. It also simplifies debugging because you will see the correct
addresses in the objdump without doing offset calculation.
- On ARM most of the duplicate code under cpu/arm* is already merged into
arch/arm/cpu. The start.S files are missing though.

View File

@ -1,13 +0,0 @@
------------ barebox timekeeping -------------
In barebox we use the clocksource mechanism from the Linux Kernel. This makes
it fairly easy to add timer functionality for a new board or architecture.
Apart from initialization there is only one function required:
clocksource_read(). This function returns the current value of a free running
counter. Other functions like udelay() and get_time_ns() are derived from this
function. The only thing you have to implement is a clocksource driver. See
cpu/arm920t/imx/interrupts.c for an example. clocksource drivers from the
Linux Kernel can be used nearly 1:1, except for the register accesses.
for clocksources the __lshrdi3 symbol is needed. You can find the function for
your architecture in the Linux Kernel or a libc of your choice.

View File

@ -0,0 +1,34 @@
.. _automount:
Automount
=========
barebox supports automatically mounting filesystems when a path is first
accessed. This is handled with the :ref:`command_automount` command. With automounting
it is possible to separate the configuration of a board from actually using
filesystems. The filesystems (and the devices they are on) are only probed
when necessary, so barebox does not lose time probing unused devices.
Typical usage is for accessing the TFTP server. To set up an automount for a
TFTP server, the following is required::
mkdir -p /mnt/tftp
automount /mnt/tftp 'ifup eth0 && mount -t tftp $eth0.serverip /mnt/tftp'
This creates an automountpoint on ``/mnt/tftp``. Whenever this directory is accessed,
the command ``ifup eth0 && mount -t tftp $eth0.serverip /mnt/tftp`` is executed.
It will bring up the network device using :ref:`command_ifup` and mount a TFTP filesystem
using :ref:`command_mount`.
Usually the above automount command is executed from an init script in ``/env/init/automount``.
With the above, files on the TFTP server can be accessed without configuration::
cp /mnt/tftp/linuximage /image
This automatically detects a USB mass storage device and mounts the first
partition to ``/mnt/fat``::
mkdir -p /mnt/fat
automount -d /mnt/fat 'usb && [ -e /dev/disk0.0 ] && mount /dev/disk0.0 /mnt/fat'
To see a list of currently registered automountpoints use ``automount -l``.

View File

@ -0,0 +1,230 @@
barebox
=======
Getting barebox
---------------
barebox is released on a monthly basis. The version numbers use the format
YYYY.MM.N, so 2014.06.0 is the monthly release for June 2014. Stable releases
are done as needed to fix critical problems and are indicated by incrementing
the suffix (for example 2014.06.1).
All releases can be downloaded from:
http://www.barebox.org/download/
Development versions of barebox are accessible via Git. A local repository clone
can be checked out as follows::
$ git clone git://git.pengutronix.de/git/barebox.git
Cloning into 'barebox'...
remote: Counting objects: 113356, done.
remote: Compressing objects: 100% (25177/25177), done.
remote: Total 113356 (delta 87910), reused 111155 (delta 85935)
Receiving objects: 100% (113356/113356), 33.13 MiB | 183.00 KiB/s, done.
Resolving deltas: 100% (87910/87910), done.
Checking connectivity... done.
Checking out files: 100% (5651/5651), done.
After this, make sure to check out the appropriate branch. If you want to
develop for barebox, it's best to check out the ``next`` branch rather than
the ``master`` branch::
$ git checkout -b next origin/remotes/next
A web interface to the repository is available at
http://git.pengutronix.de/?p=barebox.git.
.. _configuration:
Configuration
-------------
barebox uses Kconfig from the Linux kernel as a configuration tool,
where all configuration is done via the ``make`` command. Before running
it you have to specify your architecture with the ``ARCH`` environment
variable and the cross compiler with the ``CROSS_COMPILE`` environment
variable. Currently, ``ARCH`` must be one of:
* arm
* blackfin
* mips
* nios2
* openrisc
* ppc
* sandbox
* x86
``CROSS_COMPILE`` should be the prefix of your cross compiler. This can
either contain the full path or, if the cross compiler binary is
in your $PATH, just the prefix.
Either export ``ARCH`` and ``CROSS_COMPILE`` once before working on barebox::
export ARCH=arm
export CROSS_COMPILE=/path/to/arm-cortexa8-linux-gnueabihf-
make ...
or add them to each invocation of the ``make`` command::
ARCH=arm CROSS_COMPILE=/path/to/arm-cortexa8-linux-gnueabihf- make ...
For readability, ARCH/CROSS_COMPILE are skipped from the following examples.
Configuring for a board
^^^^^^^^^^^^^^^^^^^^^^^
All configuration files can be found under the ``arch/${ARCH}/configs/``
directory. For an overview of possible Make targets for your architecture,
type::
make help
Your output from ``make help`` will be based on the architecture you've
selected via the ``ARCH`` variable. So if, for example, you had selected::
export ARCH=mips
your help output would represent all of the generic (architecture-independent)
targets, followed by the MIPS-specific ones::
make [ARCH=mips] help
...
... list of generic targets ...
...
Architecture specific targets (mips):
No architecture specific help defined for mips
loongson-ls1b_defconfig - Build for loongson-ls1b
ritmix-rzx50_defconfig - Build for ritmix-rzx50
tplink-mr3020_defconfig - Build for tplink-mr3020
dlink-dir-320_defconfig - Build for dlink-dir-320
qemu-malta_defconfig - Build for qemu-malta
barebox supports building for multiple boards with a single config. If you
can't find your board in the list, it may be supported by one of the multi-board
configs. As an example, this is the case for tegra_v7_defconfig and imx_v7_defconfig.
Select your config with ``make <yourboard>_defconfig``::
make imx_v7_defconfig
The configuration can be further customized with one of the configuration frontends
with the most popular being ``menuconfig``::
make menuconfig
barebox uses the same (Kbuild) configuration system as Linux, so you can use
all the kernel config targets you already know, e.g. ``make xconfig``,
``make allyesconfig`` etc.
Configuring and compiling "out-of-tree"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Before going any further, it's worth knowing how you can do all your barebox
configuration and compilation "out of tree"; that is, how you can keep your
source directory pristine and have all output from the various ``make`` commands
generated in a separate build directory.
Once you check out your barebox source directory, and before you do any
configuration or building, set the environment variable ``KBUILD_OUTPUT``
to point to your intended output directory, as in::
export KBUILD_OUTPUT=.../my_barebox_build_directory
From that point on, all of the ``make`` commands you run in your source
directory will generate their output in your specified output directory.
Not only does this keep your source directory clean, but it allows several
developers to share the same source directory while doing all their own
configuration and building in their own individual build directories.
.. note::
To do out-of-tree builds, your source tree must be absolutely clean
of all generated artifacts from previous configurations and builds.
In other words, if you had earlier done any configuration or building
in that source tree that dumped its results into the same source tree
directory, you need to do the equivalent of a ``make distclean`` before
using that source directory for any out-of-tree builds.
Compilation
-----------
After barebox has been :ref:`configured <configuration>` it can be compiled
simply with::
make
The resulting binary varies depending on the board barebox is compiled for.
Without :ref:`multi_image` support the ``barebox-flash-image`` link will point
to the binary for flashing/uploading to the board. With :ref:`multi_image` support
the compilation process will finish with a list of images built under ``images/``::
images built:
barebox-freescale-imx51-babbage.img
barebox-genesi-efikasb.img
barebox-freescale-imx53-loco.img
barebox-freescale-imx53-loco-r.img
barebox-freescale-imx53-vmx53.img
barebox-tq-mba53-512mib.img
barebox-tq-mba53-1gib.img
barebox-datamodul-edm-qmx6.img
barebox-guf-santaro.img
barebox-gk802.img
Starting barebox
-----------------
Bringing barebox to a board for the first time is highly board specific, see your
board documentation for initial bringup.
barebox binaries are, where possible, designed to be startable second stage from another
bootloader. For example, if you have U-Boot running on your board, you can start barebox
with U-Boot's 'go' command::
U-Boot: tftp $load_addr barebox.bin
U-Boot: go $load_addr
With barebox already running on your board, this can be used to chainload another barebox::
bootm /mnt/tftp/barebox.bin
At least ``barebox.bin`` (with :ref:`pbl` support enabled ``arch/$ARCH/pbl/zbarebox.bin``)
should be startable second stage. The flash binary (``barebox-flash-image``) may or may not
be startable second stage as it may have SoC specific headers which prevent running second
stage.
First Steps
-----------
This is a typical barebox startup log::
barebox 2014.06.0-00232-g689dc27-dirty #406 Wed Jun 18 00:25:17 CEST 2014
Board: Genesi Efika MX Smartbook
detected i.MX51 revision 3.0
mc13xxx-spi mc13892@00: Found MC13892 ID: 0x0045d0 [Rev: 2.0a]
m25p80 m25p800: sst25vf032b (4096 Kbytes)
ata0: registered /dev/ata0
imx-esdhc 70004000.esdhc: registered as 70004000.esdhc
imx-esdhc 70008000.esdhc: registered as 70008000.esdhc
imx-ipuv3 40000000.ipu: IPUv3EX probed
netconsole: registered as cs2
malloc space: 0xabe00000 -> 0xafdfffff (size 64 MiB)
mmc1: detected SD card version 2.0
mmc1: registered mmc1
barebox-environment environment-sd.7: setting default environment path to /dev/mmc1.barebox-environment
running /env/bin/init...
Hit any key to stop autoboot: 3
barebox@Genesi Efika MX Smartbook:/
Without intervention, barebox will continue booting after 3 seconds. If interrupted
by pressing a key, you will find yourself at the :ref:`shell <hush>`.
At the shell type ``help`` for a list of supported commands. ``help <command>`` shows
the usage for a particular command. barebox has tab completion which will complete
your command. Arguments to commands are also completed depending on the command. If
a command expects a file argument only files will be offered as completion. Other
commands will only complete devices or devicetree nodes.

View File

@ -0,0 +1,267 @@
.. _booting_linux:
Booting Linux
=============
Introduction
------------
The basic boot command in barebox is :ref:`command_bootm`. This command
can be used directly, but there is also a :ref:`command_boot` command
which offers additional features like a boot sequence which tries to
boot different entries until one succeeds.
The bootm command
-----------------
The :ref:`command_bootm` command is the basic boot command. Depending on the
architecture the bootm command handles different image types. On ARM the
following images are supported:
* ARM Linux zImage
* U-Boot uImage
* barebox images
The images can either be passed directly to the bootm command as argument or
in the ``global.bootm.image`` variable:
.. code-block:: sh
bootm /path/to/zImage
# same as:
global.bootm.image=/path/to/zImage
bootm
When barebox has an internal devicetree it is passed to the kernel. You can
specify an alternative devicetree with the ``-o DTS`` option or the ``global.bootm.oftree``
variable:
.. code-block:: sh
bootm -o /path/to/dtb /path/to/zImage
# same as:
global.bootm.oftree=/path/to/dtb
global.bootm.image=/path/to/zImage
bootm
**NOTE:** it may happen that barebox is probed from the devicetree, but you have
want to start a Kernel without passing a devicetree. In this case call ``oftree -f``
to free the internal devicetree before calling ``bootm``
Passing Kernel Arguments
^^^^^^^^^^^^^^^^^^^^^^^^
Depending on the barebox configuration (``CONFIG_FLEXIBLE_BOOTARGS``) there
are to ways to pass bootargs to the Kernel. With ``CONFIG_FLEXIBLE_BOOTARGS``
disabled the bootm command takes the bootargs from the ``bootargs`` environment
variable. With ``CONFIG_FLEXIBLE_BOOTARGS`` enabled the bootargs are composed
from different :ref:`global_device` variables. All variables beginning with
``global.bootargs.`` will be concatenated to the bootargs:
.. code-block:: sh
global linux.bootargs.base="console=ttyO0,115200"
global linux.bootargs.debug="earlyprintk ignore_loglevel"
bootm zImage
...
Kernel command line: console=ttymxc0,115200n8 earlyprintk ignore_loglevel
Additionally all variables starting with ``global.linux.mtdparts.`` are concatenated
to a ``mtdparts=`` parameter to the kernel. This makes it possible to consistently
partition devices with the :ref:`command_addpart` command and pass the same string as used
with addpart to the Kernel:
.. code-block:: sh
norparts="512k(bootloader),512k(env),4M(kernel),-(root)"
nandparts="1M(bootloader),1M(env),4M(kernel),-(root)"
global linux.mtdparts.nor0="physmap-flash.0:$norparts"
global linux.mtdparts.nand0="mxc_nand:$nandparts"
addpart /dev/nor0 $norparts
addpart /dev/nand0 $nandparts
...
bootm zImage
...
Kernel command line: mtdparts=physmap-flash.0:512k(bootloader),512k(env),4M(kernel),-(root);
mxc_nand:1M(bootloader),1M(env),4M(kernel),-(root)
The boot command
----------------
The :ref:`command_boot` command offers additional convenience for the :ref:`command_bootm`
command. It works with :ref:`boot_entries` and :ref:`bootloader_spec` entries. Boot entries
are located under /env/boot/ and are scripts which setup the bootm variables so that the
``boot`` command can run ``bootm`` without further arguments.
.. _boot_entries:
Boot entries
^^^^^^^^^^^^
A simple boot entry in ``/env/boot/mmc`` could look like this:
.. code-block:: sh
#!/bin/sh
global.bootm.image=/mnt/mmc1/zImage
global.bootm.oftree=/env/oftree
global linux.bootargs.dyn.root="root=PARTUUID=deadbeef:01"
This takes the kernel from ``/mnt/mmc1/zImage`` (which could be an
:ref:`automount` path registered earlier). The devicetree will be used from
``/env/oftree``. The Kernel gets the command line
``root=PARTUUID=deadbeef:01``. Note the ``.dyn`` in the bootargs variable name.
boot entries should always add Kernel command line parameters to variables with
``.dyn`` in it. These will be cleared before booting different boot entries.
This is done so that following boot entries do not leak command line
parameters from the previous boot entries.
This entry can be booted with ``boot mmc``. It can also be made the default by
setting the ``global.boot.default`` variable to ``mmc`` and then calling
``boot`` without arguments.
.. _bootloader_spec:
Bootloader Spec
^^^^^^^^^^^^^^^
barebox supports booting according to the bootloader spec:
http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/
It follows another philosophy than the :ref:`boot_entries`. With Boot Entries
booting is completely configured in the bootloader. Bootloader Spec Entries
on the other hand the boot entries are on a boot medium. This gives a boot medium
the possibility to describe where a Kernel is and what parameters it needs.
All Bootloader Spec Entries are in a partition on the boot medium under ``/loader/entries/*.conf``.
In the Bootloader Spec a boot medium has a dedicated partition to use for
boot entries. barebox is less strict, it accepts Bootloader Spec Entries on
every partition barebox can read.
A Bootloader Spec Entry consists of key value pairs::
/loader/entries/6a9857a393724b7a981ebb5b8495b9ea-3.8.0-2.fc19.x86_64.conf:
title Fedora 19 (Rawhide)
version 3.8.0-2.fc19.x86_64
machine-id 6a9857a393724b7a981ebb5b8495b9ea
options root=UUID=6d3376e4-fc93-4509-95ec-a21d68011da2
linux /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/linux
initrd /6a9857a393724b7a981ebb5b8495b9ea/3.8.0-2.fc19.x86_64/initrd
All pathes are absolute pathes in the partition. Bootloader Spec Entries can
be created manually, but there also is the ``scripts/kernel-install`` tool to
create/list/modify entries directly on a MMC/SD card or other media. To use
it create a SD card / USB memory stick with a /boot partition with type 0xea.
The partition can be formatted with FAT or EXT4 filesystem. If you wish to write
to it from barebox later you must use FAT. The following creates a Bootloader
Spec Entry on a SD card:
.. code-block:: sh
scripts/kernel-install --device=/dev/mmcblk0 -a \
--machine-id=11ab7c89d02c4f66a4e2474ea25b2b84 --kernel-version="3.15" \
--kernel=/home/sha/linux/arch/arm/boot/zImage --add-root-option \
--root=/dev/mmcblk0p1 -o "console=ttymxc0,115200"
The entry can be listed with the -l option:
.. code-block:: sh
scripts/kernel-install --device=/dev/mmcblk0 -l
Entry 0:
title: Linux-3.15
version: 3.15
machine_id: 11ab7c89d02c4f66a4e2474ea25b2b84
options: console=ttymxc0,115200 root=PARTUUID=0007CB20-01
linux: 11ab7c89d02c4f66a4e2474ea25b2b84.15/linux
When on barebox the SD card shows up as ``mmc`` then this entry can be booted with
``boot mmc1`` or with setting ``global.boot.default`` to ``mmc1``.
Network boot
------------
With the following steps barebox can start the Kernel and root filesystem
over network, a standard development case.
Configure network: edit ``/env/network/eth0``. For a standard dhcp setup
the following is enough:
.. code-block:: sh
#!/bin/sh
ip=dhcp
serverip=192.168.23.45
serverip is only necessary if it differs from the serverip offered from the dhcp server.
A static ip setup can look like this:
.. code-block:: sh
#!/bin/sh
ip=static
ipaddr=192.168.2.10
netmask=255.255.0.0
gateway=192.168.2.1
serverip=192.168.2.1
Note that barebox will pass the same ip settings to the kernel, i.e. it passes
``ip=$ipaddr:$serverip:$gateway:$netmask::eth0:`` for a static ip setup and
``ip=dhcp`` for a dynamic dhcp setup.
Adjust ``global.user`` and maybe ``global.hostname`` in ``/env/config``::
global.user=sha
global.hostname=efikasb
Copy the kernel (and devicetree if needed) to the base dir of the TFTP server::
cp zImage /tftpboot/sha-linux-efikasb
cp myboard.dtb /tftpboot/sha-oftree-efikasb
barebox will pass ``nfsroot=/home/${global.user}/nfsroot/${global.hostname}``
This may be a link to another location on the NFS server. Make sure that the
link target is exported from the server.
``boot net`` will then start the Kernel.
If the pathes or names are not suitable they can be adjusted in
``/env/boot/net``:
.. code-block:: sh
#!/bin/sh
path="/mnt/tftp"
global.bootm.image="${path}/${global.user}-linux-${global.hostname}"
oftree="${path}/${global.user}-oftree-${global.hostname}"
if [ -f "${oftree}" ]; then
global.bootm.oftree="$oftree"
fi
nfsroot="/home/${global.user}/nfsroot/${global.hostname}"
bootargs-ip
global.linux.bootargs.dyn.root="root=/dev/nfs nfsroot=$nfsroot,v3,tcp"

View File

@ -0,0 +1,133 @@
Default environment version 2
=============================
barebox stores its environment files under the top-level ``/env/``
directory, where most of the runtime configuration scripts are located.
This environment is comparable to a tar archive which is unpacked from
a storage medium during startup. If for whatever reason the environment
cannot be loaded from a storage medium, a compiled-in default environment
is used instead.
The environment is not automatically stored on the storage medium when a file
under ``/env/`` is changed; rather, this has to be done manually using the
:ref:`command_saveenv` command.
There are two sets of generic environment files which can be used. The older
version (version one) should not be used for new boards and is not described here
(even though there are still numerous board definitions that use it).
All new boards should use defaultenv-2 exclusively.
The default environment is composed from different directories during compilation::
defaultenv/defaultenv-2-base -> base files
defaultenv/defaultenv-2-dfu -> overlay for DFU
defaultenv/defaultenv-2-menu -> overlay for menus
arch/$ARCH/boards/<board>/env -> board specific overlay
The content of the above directories is applied one after another. If the
same file exists in a later overlay, it will overwrite the preceding one.
Note that not all of the above directories will necessarily be
included in your default environment, it depends on your barebox
configuration settings. You can see the configuration variables
and their respective included directories in ``defaultenv/Makefile``::
bbenv-$(CONFIG_DEFAULT_ENVIRONMENT_GENERIC_NEW) += defaultenv-2-base
bbenv-$(CONFIG_DEFAULT_ENVIRONMENT_GENERIC_NEW_MENU) += defaultenv-2-menu
bbenv-$(CONFIG_DEFAULT_ENVIRONMENT_GENERIC_NEW_DFU) += defaultenv-2-dfu
bbenv-$(CONFIG_DEFAULT_ENVIRONMENT_GENERIC) += defaultenv-1
/env/bin/init
-------------
This script is executed by the barebox startup code after initialization.
In defaultenv-2, this script will define and set a number of global
variables, followed by sourcing all of the scripts in ``/env/init/`` with::
for i in /env/init/*; do
. $i
done
This script is also responsible for defining the boot timeout value
(by default, three seconds), then printing the timeout prompt for the user.
Be careful making changes to this script: since it is executed before any user
intervention, it might lock the system.
/env/init/
----------
The ``/env/init/`` directory is the location for startup scripts. The scripts
in this directory will be executed in alphabetical order by the
``/env/bin/init`` script described earlier.
/env/boot/
----------
The ``/env/boot/`` directory contains boot entry scripts. The :ref:`command_boot`
command treats the files in this directory as possible boot targets.
See :ref:`booting_linux` for more details.
/env/config
-----------
This file contains some basic configuration settings. It can be edited using
the :ref:`command_edit` command. Typical content:
.. code-block:: sh
#!/bin/sh
# change network settings in /env/network/eth0
# change mtd partition settings and automountpoints in /env/init/*
#global.hostname=
# set to false if you do not want to have colors
#global.allow_color=true
# user (used for network filenames)
#global.user=none
# timeout in seconds before the default boot entry is started
#global.autoboot_timeout=3
# list of boot entries. These are executed in order until one
# succeeds. An entry can be:
# - a filename in /env/boot/
# - a full path to a directory. All files in this directory are
# treated as boot files and executed in alphabetical order
#global.boot.default=net
# base bootargs
#global.linux.bootargs.base="console=ttyS0,115200"
When changing this file remember to do a ``saveenv`` to make the change
persistent. Also it may be necessary to manually ``source /env/config`` before
the changes take effect.
/env/network/
-------------
This contains the configuration files for the network interfaces. Typically
there will be a file ``eth0`` with a content like this:
.. code-block:: sh
#!/bin/sh
# ip setting (static/dhcp)
ip=dhcp
global.dhcp.vendor_id=barebox-${global.hostname}
# static setup used if ip=static
ipaddr=
netmask=
gateway=
serverip=
# MAC address if needed
#ethaddr=xx:xx:xx:xx:xx:xx
# put code to discover eth0 (i.e. 'usb') to /env/network/eth0-discover
exit 0

View File

@ -0,0 +1,85 @@
.. _devicetree:
Devicetree support
==================
Flattened Device Tree (FDT) is a data structure for describing the hardware on
a system. On an increasing number of boards, both barebox and the Linux kernel can
probe their devices directly from devicetrees. barebox needs the devicetree compiled
into the binary. The kernel usually does not have a devicetree compiled in; instead,
the kernel expects to be passed a devicetree from the bootloader.
From a bootloader's point of view, using devicetrees has the advantage that the
same devicetree can be used by both the bootloader and the kernel; this
drastically reduces porting effort since the devicetree has to be written only
once (and with luck somebody has already written a devicetree for the kernel).
Having barebox consult a devicetree is highly recommended for new projects.
.. _internal_devicetree:
The internal devicetree
-----------------------
The devicetree consulted by barebox plays a special role. It is referred to
as the "internal devicetree." The barebox devicetree commands work on this
devicetree. The devicetree source (DTS) files are kept in sync with the kernel DTS
files. As the FDT files are meant to be backward compatible, it should always be possible
to start a kernel with the barebox internal devicetree. However, since the barebox
devicetree may not be complete or contain bugs it is always possible to start the
kernel with a devicetree different from the one used by barebox.
If a device has been probed from the devicetree then using the :ref:`command_devinfo`
command on it will show the corresponding devicetree node:
.. code-block:: sh
barebox@Phytec pcm970:/ devinfo 10002000.wdog
Resources:
num: 0
name: /soc/aipi@10000000/wdog@10002000
start: 0x10002000
size: 0x00001000
Driver: imx-watchdog
Bus: platform
Device node: /soc/aipi@10000000/wdog@10002000
wdog@10002000 {
compatible = "fsl,imx27-wdt", "fsl,imx21-wdt";
reg = <0x10002000 0x1000>;
interrupts = <0x1b>;
clocks = <0x1 0x4a>;
};
Devicetree commands
-------------------
barebox has commands to show and manipulate devicetrees. These commands always
work on the internal devicetree. It is possible to add/remove nodes using the
:ref:`command_of_node` command and to add/change/remove properties using the
:ref:`command_of_property` command. To dump devicetrees on the console use the
:ref:`command_of_dump` command.
.. code-block:: sh
# dump the whole devicetree
of_dump
# dump node of_dump /soc/nand@d8000000/
of_dump /soc/nand@d8000000/
# create a new node
of_node -c /chosen/mynode
# add a property to it
of_property -s /chosen/mynode/ myproperty myvalue
It is important to know that these commands always work on the internal
devicetree. If you modify the internal devicetree to influence the behaviour of
a kernel booted later, make sure that you start the kernel with the internal
devicetree (i.e. don't pass a devicetree to the :ref:`command_bootm` command). If you
wish to use another devicetree than the internal devicetree for starting the kernel,
you can exchange the internal devicetree during runtime using the
:ref:`command_oftree` command:
.. code-block:: sh
oftree -f
oftree -l /new/dtb

View File

@ -0,0 +1,93 @@
Driver model
============
barebox has a driver model. This matches the devices on a board with their
corresponding drivers. From a user's point of view this is mostly visible in the
:ref:`command_devinfo` and :ref:`command_drvinfo` commands. Without arguments
the :ref:`command_devinfo` command will show a hierarchical list of devices
found on the board. As this may be instantiated from the :ref:`devicetree`
there may be devices listed for which no driver is available. The
:ref:`command_drvinfo` command shows a list of drivers together with the
devices they handle.
:ref:`command_devinfo` also shows a list of device files a device has registered::
`-- 70008000.esdhc
`-- mmc1
`-- 0x00000000-0x1d9bfffff ( 7.4 GiB): /dev/mmc1
`-- 0x00100000-0x040fffff ( 64 MiB): /dev/mmc1.0
`-- 0x04100000-0x240fffff ( 512 MiB): /dev/mmc1.1
`-- 0x24100000-0xe40fffff ( 3 GiB): /dev/mmc1.2
`-- 0xe4100000-0x1640fffff ( 2 GiB): /dev/mmc1.3
`-- 0x00080000-0x000fffff ( 512 KiB): /dev/mmc1.barebox-environment
In this case the /dev/mmc1\* are handled by the mmc1 device. It must be noted
that it's desirable that devices (mmc1) have the same name as the device files (/dev/mmc1\*),
but this doesn't always have to be the case.
Device detection
----------------
Some devices like USB or MMC may take a longer time to probe. Probing USB
devices should not delay booting when USB may not even be used. This case is
handled with device detection. The user visible interface to device detection
is the :ref:`command_detect` command. ``detect -l`` shows a list of detectable
devices::
barebox:/ detect -l
70004000.esdhc
70008000.esdhc
73f80000.usb
73f80200.usb
73f80400.usb
83fe0000.pata
ata0
mmc0
mmc1
miibus0
A particular device can be detected with ``detect <devname>``::
barebox:/ detect 73f80200.usb
Found SMSC USB331x ULPI transceiver (0x0424:0x0006).
Bus 002 Device 004: ID 13d3:3273 802.11 n WLAN
mdio_bus: miibus0: probed
eth0: got preset MAC address: 00:1c:49:01:03:4b
Bus 002 Device 005: ID 0b95:7720 ZoWii
Bus 002 Device 002: ID 0424:2514
Bus 002 Device 001: ID 0000:0000 EHCI Host Controller
For detecting all devices ``detect -a`` can be used.
.. _device_parameters:
Device parameters
-----------------
Devices can have parameters which can be used to configure devices or to provide
additional information for a device. The parameters can be listed with the
:ref:`command_devinfo` command. A ``devinfo <devicename>`` will print the parameters
of a device::
barebox:/ devinfo eth0
Parameters:
ipaddr: 192.168.23.197
serverip: 192.168.23.1
gateway: 192.168.23.1
netmask: 255.255.0.0
ethaddr: 00:1c:49:01:03:4b
The parameters can be used as shell variables::
eth0.ipaddr=192.168.23.15
echo "my current ip is: $eth0.ipaddr"
device variables may have a type, so assigning wrong values may fail::
barebox:/ eth0.ipaddr="This is not an IP"
set parameter: Invalid argument
barebox:/ echo $?
1
**HINT:** barebox has tab completion for variables. Typing ``eth0.<TAB><TAB>``
will show the parameters for eth0.

View File

@ -0,0 +1,43 @@
Framebuffer support
===================
barebox has support for framebuffer devices. Currently there is no console support
for framebuffers, so framebuffer usage is limited to splash screens only. barebox
supports BMP and PNG graphics using the :ref:`command_splash` command. barebox
currently has no support for backlights, so unless there is a board specific enable
hook for enabling a display it must be done manually with a script. Since barebox
has nothing useful to show on the framebuffer it doesn't enable it during startup.
A framebuffer can be enabled with the ``enable`` parameter of the framebuffer device:
.. code-block:: sh
fb0.enable=1
Some framebuffer devices support different resolutions. These can be configured
with the ``mode_name`` parameter. See a list of supported modes using ``devinfo fb0``.
A mode can only be changed when the framebuffer is disabled.
A typical script to enable the framebuffer could look like this:
.. code-block:: sh
#!/bin/sh
SPLASH=/path/to/mysplash.png
if [ ! -f $SPLASH ]; then
exit 0
fi
# first show splash
splash /path/to/mysplash.png
# enable framebuffer
fb0.enable=1
# wait for signals to become stable
msleep 100
# finally enable backlight
gpio_direction_output 42 1

View File

@ -0,0 +1,60 @@
.. index:: hush shell
.. _hush:
Hush shell
==========
barebox has an integrated shell: hush. This is a simple shell which
is enough for writing simple shell scripts. Usage of the shell for
scripts should not be overstrained. Often a command written in C is
more flexible and also more robust than a complicated shell script.
Hush features
-------------
variables::
a="Hello user"
echo $a
Hello user
conditional execution ``if`` / ``elif`` / ``else`` / ``fi``::
if [ ${foo} = ${bar} ]; then
echo "foo equals bar"
else
echo "foo and bar differ"
fi
``for`` loops::
for i in a b c; do
echo $i
done
``while`` loops::
while true; do
echo "endless loop"
done
wildcard globbing::
ls d*
echo ???
There is no support in hush for input/output redirection or pipes.
Some commands work around this limitation with additional arguments. for
example the :ref:`command_echo` command has the ``-a FILE`` option for appending
a file and the ``-o FILE`` option for overwriting a file. The readline
command requires a variable name as argument in which the line will be
stored.
**NOTE:** hush feels like a normal Unix shell, but it cannot calculate by
itself, i.e. $(($A/2)) won't work. Calculation can however be done
with :ref:`command_let`::
A=10
let B=$A/2
echo $B

View File

@ -0,0 +1,29 @@
Introduction
============
This is the barebox user manual, which describes how to configure, compile
and run barebox on embedded systems.
barebox (just barebox, not *the* barebox) is a bootloader designed for
embedded systems. It runs on a variety of architectures including
x86, ARM, MIPS, PowerPC and others.
barebox aims to be a versatile and flexible bootloader, not only for
booting embedded Linux systems, but also for initial hardware bringup and
development. barebox is highly configurable to be suitable as a full-featured
development binary as well as for lean production systems.
Just like busybox is the Swiss Army Knife for embedded Linux,
barebox is the Swiss Army Knife for bare metal, hence the name.
Feedback
--------
For sending patches, asking for help and giving general feedback you are
always welcome to write an e-mail to the barebox mailing list. Most of the
discussion of barebox takes place here:
http://lists.infradead.org/mailman/listinfo/barebox/
There's also an IRC channel:
IRC: #barebox (Freenode)

View File

@ -0,0 +1,27 @@
Memory areas
============
Several barebox commands like :ref:`command_md`, :ref:`command_erase`
or :ref:`command_crc` work on an area of memory. Areas have the following form::
<start>-<end>
or::
<start>+<count>
start, end and count are interpreted as decimal values if not prefixed with 0x.
Additionally these can be postfixed with K, M or G for kilobyte, megabyte or
gigabyte.
Examples
--------
Display a hexdump from 0x80000000 to 0x80001000 (inclusive)::
md 0x80000000-0x80001000
Display 1 kilobyte of memory starting at 0x80000000::
md 0x80000000+1k

View File

@ -0,0 +1,54 @@
.. _multi_image:
Multi Image Support
===================
Traditionally a single configuration only works for a single board. Sometimes
even variants of a single board like different amount of memory require a new
config. This has the effect that the number of defconfig files increases dramatically.
All the configs have to be kept in sync manually. Multi Image Support solves this
problem.
With Multi Image Support binaries for multiple boards can be generated from a single
config. A single board can only support compilation with or without Multi Image Support.
Multi Image Support exposes several user visible changes:
* In ``make menuconfig`` it becomes possible to select multiple boards instead of
only one.
* The ``barebox-flash-image`` link is no longer generated since there is no single
binary to use anymore.
* images are generated under images/. The build process shows all images generated
at the end of the build.
Technical background
--------------------
With Multi Image Support enabled, the main barebox binary (barebox.bin) will be
shared across different boards. For board specific code this means that it has
to test whether it actually runs on the board it is designed for. Typically board
specific code has this:
.. code-block:: c
static int efikamx_init(void)
{
if (!of_machine_is_compatible("genesi,imx51-sb"))
return 0;
... board specific code ...
}
device_initcall(efikamx_init);
Multi Image Support always uses :ref:`PBL <pbl>` to generate compressed images.
A board specific PBL image is prepended to the common barebox binary. The PBL
image contains the devicetree which is passed to the common barebox binary to
let the common binary determine the board type.
The board specific PBL images are generated from a single set of object files
using the linker. The basic trick here is that the PBL objects have multiple
entry points, specified with the ENTRY_POINT macro. For each PBL binary
generated a different entry point is selected using the ``-e`` option to ld.
The linker will throw away all unused entry points and only keep the functions
used by a particular entry point.
The Multi Image PBL files can be disassembled with ``make <entry-function-name.pbl.S``

View File

@ -0,0 +1,81 @@
Networking
==========
barebox has IPv4 networking support. Several protocols such as
:ref:`command_dhcp`, :ref:`filesystems_nfs`, :ref:`command_tftp` are
supported.
Network configuration
---------------------
The first step for networking is configuring the network device. The network
device is usually ``eth0``. The current configuration can be viewed with the
:ref:`command_devinfo` command:
.. code-block:: sh
barebox:/ devinfo eth0
Parameters:
ipaddr: 192.168.23.197
serverip: 192.168.23.1
gateway: 192.168.23.1
netmask: 255.255.0.0
ethaddr: 00:1c:49:01:03:4b
The configuration can be changed on the command line with:
.. code-block:: sh
eth0.ipaddr=172.0.0.10
The :ref:`command_dhcp` command will change the settings based on the answer
from the DHCP server.
This low-level configuration of the network interface is often not necessary. Normally
the network settings should be edited in ``/env/network/eth0``, then the network interface
can be brought up using the :ref:`command_ifup` command.
Network filesystems
-------------------
barebox supports NFS and TFTP as filesystem implementations. See :ref:`filesystems_nfs`
and :ref:`filesystems_tftp` for more information. After the network device has been
brought up a network filesystem can be mounted with:
.. code-block:: sh
mount -t tftp 192.168.2.1 /mnt
or
.. code-block:: sh
mount -t nfs 192.168.2.1:/export none /mnt
**NOTE:** this can often be hidden behind the :ref:`command_automount` command to make
mounting transparent to the user.
Network console
---------------
barebox has a UDP-based network console. If enabled in the config, you will see
something like this during startup::
registered netconsole as cs1
By default the network console is disabled during runtime to prevent security
risks. It can be enabled using:
.. code-block:: sh
cs1.ip=192.168.23.2
cs1.active=ioe
This will send UDP packets to 192.168.23.2 on port 6666. On 192.168.23.2 the
scripts/netconsole script can be used to control barebox:
.. code-block:: sh
scripts/netconsole <board IP> 6666
The netconsole can be used just like any other console.

View File

@ -0,0 +1,31 @@
.. _pbl:
PreBootLoader images (PBL)
==========================
Traditionally barebox generates a raw uncompressed binary. PBL is an effort to
create self extracting compressed images instead. This helps on some boards
where storage space is sparse. Another usecase of PBL is on SoCs on which the
ROM code loads the initial bootloader to (limited) SRAM. With self extracting
binaries, more binary space becomes available.
PBL is available for ARM and MIPS. It can be enabled in ``make menuconfig`` with
the ``[*] Pre-Bootloader image`` option.
The user visible difference is that with PBL support ``barebox.bin`` is no longer
the final binary image, but instead ``arch/$ARCH/pbl/zbarebox.bin``. Use the
``barebox-flash-image`` link which always points to the correct image.
Technical background
--------------------
Normal object files are added to the make system using ``obj-y += file.o``.
With PBL the build system recurses into the source directories a second
time, this time all files specified with ``pbl-y += file.o`` are compiled.
This way source code can be shared between regular barebox and PBL. A special
case is ``lwl-y += file.o`` which expands to ``obj-y`` when PBL is disabled
and to ``pbl-y`` when PBL is enabled.
**HINT:** for getting an overview over the binaries, disassemble barebox.bin
(``make barebox.S``) with or without PBL support and also disassemble the
PBL (``make arch/$ARCH/pbl/zbarebox.S``)

View File

@ -0,0 +1,64 @@
Appendix: System Setup
======================
Serial Console Access
---------------------
As most current development machines don't have serial ports, the usual setup
is to use a USB-Serial-Converter. Some evaluation boards have such a converter
on board. After connecting, these usually show up on your host as
``/dev/ttyUSB#`` or ``/dev/ttyACM#`` (check ``dmesg`` to find out).
On Debian systems, the device node will be accessible to the ``dialout`` group,
so adding your user to that group (``adduser <user> dialout``) removes the need
for root privileges.
Using the "screen" program
^^^^^^^^^^^^^^^^^^^^^^^^^^
The terminal manager ``screen`` can also be used as a simple terminal emulator::
screen /dev/ttyUSB0 115200
To exit from ``screen``, press ``<CTRL-A> <K> <y>``.
Using the "microcom" program
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A good alternative terminal program is microcom. On Debian it can be installed
with ``apt-get install microcom``, on other distributions it can be installed
from source:
http://git.pengutronix.de/?p=tools/microcom;a=summary
Usage is simple::
microcom -p /dev/ttyUSB0
Network Access
--------------
Having network connectivity between your host and your target will save you a
lot of time otherwise spent on writing SD cards or using JTAG. The main
protocols used with barebox are DHCP, TFTP and NFS.
Configuration of dnsmasq for DHCP and TFTP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The ``dnsmasq`` program can be configured as a DHCP and TFTP server in addition
to its original DNS functionality::
sudo ip addr add 192.168.23.1/24 dev <interface>
sudo ip link set <interface> up
sudo /usr/sbin/dnsmasq --interface=<interface> --no-daemon --log-queries \
--enable-tftp --tftp-root=<absolute-path-to-your-images>/ \
--dhcp-range=192.168.23.240,192.168.23.250
Configuration of a TFTP Server
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Configuration of a BOOTP / DHCP Server
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Configuring a NFS Server
^^^^^^^^^^^^^^^^^^^^^^^^

138
Documentation/user/ubi.rst Normal file
View File

@ -0,0 +1,138 @@
UBI/UBIFS support
=================
barebox has both UBI and UBIFS support. For handling UBI barebox has commands similar to
the Linux commands :ref:`command_ubiformat`, :ref:`command_ubiattach`, :ref:`command_ubidetach`,
:ref:`command_ubimkvol` and :ref:`command_ubirmvol`.
The following examples assume we work on the first UBI device. Replace ``ubi0`` with
the appropriate number when you have multiple UBI devices.
The first step for preparing a pristine Flash for UBI is to :ref:`command_ubiformat` the
device:
.. code-block:: sh
ubiformat /dev/nand0.root
If you intend to use a device with UBI you should always use ``ubiformat`` instead of plain
:ref:`command_erase`. ``ubiformat`` will make sure the erasecounters are preserved and also
:ref:`ubi_fastmap` won't work when a flash is erased with ``erase``
**NOTE:** when using the :ref:`ubi_fastmap` feature make sure that the UBI is attached and detached
once after using ``ubiformat``. This makes sure the Fastmap is written.
After a device has been formatted it can be attached with :ref:`command_ubiattach`.
.. code-block:: sh
ubiattach /dev/nand0.root
This will create the controlling node ``/dev/ubi0`` and also register all volumes present
on the device as ``/dev/ubi0.<volname>``. When freshly formatted there won't be any volumes
present. A volume can be created with:
.. code-block:: sh
ubimkvol /dev/ubi0 root 0
The first parameter is the controlling node. The second parameter is the name of the volume.
In this case the volume can be found under ``/dev/ubi.root``. The third parameter contains
the size. A size of zero means that all available space shall be used.
The next step is to write a UBIFS image to the volume. The image must be created on a host using
the ``mkfs.ubifs`` command. ``mkfs.ubifs`` requires several arguments for describing the
flash layout. Values for these arguments can be retrieved from a ``devinfo ubi`` under barebox:
.. code-block:: sh
barebox@Phytec pcm970:/ devinfo ubi0
Parameters:
peb_size: 16384
leb_size: 15360
vid_header_offset: 512
min_io_size: 512
sub_page_size: 512
good_peb_count: 3796
bad_peb_count: 4
max_erase_counter: 0
mean_erase_counter: 0
available_pebs: 3713
reserved_pebs: 83
To build a UBIFS image for this device the following command is suitable:
.. code-block:: sh
mkfs.ubifs --min-io-size=512 --leb-size=15360 --max-leb-cnt=4096 -r rootdir \
/tftpboot/root.ubifs
The ``--max-leb-cnt`` parameter specifies the maximum number of logical erase blocks
the UBIFS image can ever have. For this particular device a number of 3713 would be
enough. If the image shall be used for multiple boards the maximim peb count of all
boards must be used.
The UBIFS image can be transferred to the board for example with TFTP:
.. code-block:: sh
cp /mnt/tftp/root.ubifs /dev/ubi0.root
Finally it can be mounted using the :ref:`command_mount` command:
.. code-block:: sh
mkdir -p /mnt/ubi
mount -t ubifs /dev/ubi0.root /mnt/ubi
The second time the UBIFS is mounted the above can be simplified to:
.. code-block:: sh
ubiattach /dev/nand0.root
mount -t ubifs /dev/ubi0.root /mnt/ubi
Mounting the UBIFS can also be made transparent with the automount command.
With this helper script in ``/env/bin/automount-ubi:``:
.. code-block:: sh
#!/bin/sh
if [ ! -e /dev/ubi0 ]; then
ubiattach /dev/nand0 || exit 1
fi
mount -t ubifs /dev/ubi0.root $automount_path
The command ``automount -d /mnt/ubi/ '/env/bin/automount-ubi'`` will automatically
attach the UBI device and mount the UBIFS image to ``/mnt/ubi`` whenever ``/mnt/ubi``
is first accessed. The automount command can be added to ``/env/init/automount`` to
execute it during startup.
.. _ubi_fastmap:
UBI Fastmap
-----------
When attaching UBI to a flash device the UBI code has to scan all eraseblocks on the
flash. Since this can take some time the Fastmap feature has been introduced. It has
been merged in Linux 3.7. barebox has support for the Fastmap feature, but to use
it some care must be taken. The Fastmap feature reduces scanning time by adding
informations to one of the first blocks of a flash. For technical details see
http://www.linux-mtd.infradead.org/doc/ubi.html#L_fastmap. Since the Fastmap can
only live near the beginning of a flash the Fastmap code relies on finding a free
eraseblock there. The above example command make that sure, but Fastmap is incompatible
with creating a UBI image on a host and directly flashing the UBI image to the
raw NAND/NOR device. In this case the Fastmap code will not find a free eraseblock
and the following message will occur during ``ubidetach``:
.. code-block:: sh
UBI error: ubi_update_fastmap: could not find any anchor PEB
UBI warning: ubi_update_fastmap: Unable to write new fastmap, err=-28
The Fastmap is first written after a ``ubidetach``, so it's important to attach/detach
a UBI volume after using ``ubiformat``.

View File

@ -0,0 +1,29 @@
.. _update:
Updating barebox
================
Updating barebox is potentially a dangerous task. When the update fails,
the board may not start anymore and must be recovered. barebox has a special
command to make updating barebox easier and safer: :ref:`command_barebox_update`.
A board can register an update handler to the update command. The handler can
do additional checks before trying an update, e.g. it's possible
to check whether the new image actually is a barebox image.
Updating barebox can be as easy as::
barebox_update /path/to/new/barebox.img
Multiple handlers can be registered to the update mechanism. Usually the device
barebox has been started from is registered as default (marked with a ``*``)::
barebox:/ barebox_update -l
registered update handlers:
* mmc -> /dev/mmc1
spinor -> /dev/m25p0
:ref:`command_barebox_update` requires board support, so it may not be
available for your board. It is recommended to implement it, but you can also
update barebox manually using :ref:`command_erase` and :ref:`command_cp`
commands. The exact commands are board specific.

View File

@ -0,0 +1,90 @@
USB support
===========
USB host support
----------------
barebox has support for both USB host and USB device mode. USB devices
take a long time to probe, so they are not probed automatically. Probing
has to be triggered using the :ref:`command_usb` or :ref:`command_detect` command.
USB devices in barebox are not hot-pluggable. It is expected that USB
devices are not disconnected while barebox is running.
USB Networking
^^^^^^^^^^^^^^
barebox supports ASIX-compatible devices and the SMSC95xx. After
detection, the device shows up as eth0 and can be used like a regular network
device.
To use a USB network device together with the :ref:`command_ifup` command, add the
following to ``/env/network/eth0-discover``:
.. code-block:: sh
#!/bin/sh
usb
USB mass storage
^^^^^^^^^^^^^^^^
barebox supports USB mass storage devices. After probing them with the :ref:`command_usb`
command, they show up as ``/dev/diskx`` and can be used like any other device.
USB device support
------------------
DFU
^^^
USB Device Firmware Upgrade (DFU) is an official USB device class specification of the USB
Implementers Forum. It provides a vendor-independent way to update the firmware of embedded
devices. The current specification is version 1.1 and can be downloaded here:
http://www.usb.org/developers/devclass_docs/DFU_1.1.pdf
On the barebox side, the update is handled with the :ref:`command_dfu` command.
It is passed a list of partitions to provide to the host. The partition list
has the form ``<file>(<name>)<flags>``. ``file`` is the path to the device or
regular file which shall be updated. ``name`` is the name under which the partition
shall be provided to the host. For the possible ``flags`` see
:ref:`command_dfu`. A typical ``dfu`` command could look like this:
.. code-block:: sh
dfu "/dev/nand0.barebox.bb(barebox)sr,/dev/nand0.kernel.bb(kernel)r,/dev/nand0.root.bb(root)r"
On the host side, the tool `dfu-util <http://dfu-util.gnumonks.org/>`_ can be used
to update the partitions. It is available for most distributions and typically
supports the following options::
dfu-util -h
Usage: dfu-util [options] ...
-h --help Print this help message
-V --version Print the version number
-v --verbose Print verbose debug statements
-l --list List the currently attached DFU capable USB devices
-e --detach Detach the currently attached DFU capable USB devices
-d --device vendor:product Specify Vendor/Product ID of DFU device
-p --path bus-port. ... .port Specify path to DFU device
-c --cfg config_nr Specify the Configuration of DFU device
-i --intf intf_nr Specify the DFU Interface number
-a --alt alt Specify the Altsetting of the DFU Interface
by name or by number
-t --transfer-size Specify the number of bytes per USB Transfer
-U --upload file Read firmware from device into <file>
-D --download file Write firmware from <file> into device
-R --reset Issue USB Reset signalling once we're finished
-s --dfuse-address address ST DfuSe mode, specify target address for
raw file download or upload. Not applicable for
DfuSe file (.dfu) downloads
To update the kernel for the above example, you would use something like
the following:
.. code-block:: sh
dfu-util -D arch/arm/boot/zImage -a kernel
The ``dfu-util`` command automatically finds DFU-capable devices. If there are
multiple devices found, you need to identify one with the ``-d``/``-p`` options.

View File

@ -0,0 +1,33 @@
.. highlight:: console
User manual
===========
Contents:
.. toctree::
:numbered:
:maxdepth: 2
introduction
barebox
networking
automount
memory-areas
driver-model
variables
hush
defaultenv-2
updating
devicetree
pbl
multi-image
framebuffer
usb
ubi
booting-linux
system-setup
* :ref:`search`
* :ref:`genindex`

View File

@ -0,0 +1,52 @@
Variables
=========
We already have seen some variables in :ref:`device_parameters`. But
there is more to variables.
.. _global_device:
The ``global`` device
---------------------
The ``global`` device is a special purpose device. It only exists as a
storage for global variables. Some global variables are created internally
in barebox (see :ref:`magicvars`). Additional variables can be created with
the :ref:`command_global` command::
global myvar
This creates the ``global.myvar`` variable which now can be used like any
other variable. You can also directly assign a value during creation::
global myvar1=foobar
**NOTE:** creating a variable with ``global myvar1=foobar`` looks very similar
to assigning a value with ``global.myvar1=foobar``, but the latter fails when
a variable has not been created before.
.. _magicvars:
Magic variables
---------------
Some variables have special meanings and influence the behaviour
of barebox. Most but not all of them are consolidated in the :ref:`global_device`.
Since it's hard to remember which variables these are and if the current
barebox has support for them the :ref:`command_magicvar` command can print a list
of all variables with special meaning along with a short description::
barebox:/ magicvar
OPTARG optarg for hush builtin getopt
PATH colon separated list of pathes to search for executables
PS1 hush prompt
armlinux_architecture ARM machine ID
armlinux_system_rev ARM system revision
armlinux_system_serial ARM system serial
automount_path mountpath passed to automount scripts
bootargs Linux Kernel parameters
bootsource The source barebox has been booted from
bootsource_instance The instance of the source barebox has been booted from
global.boot.default default boot order
...

View File

@ -1,18 +0,0 @@
/** @page users_manual User's Manual
This manual provides help for working with @a Barebox from the user's
point of view. So if you want to use @a Barebox for booting your target,
you find a lot of nice tricks on these pages to make your life easier.
@li @subpage building
@li @subpage first_steps
@li @subpage command_reference
@li @subpage gpio_for_users
\todo Rework the following sections
@li @subpage shell_notes
@li @subpage readline_parser
@li @subpage x86_bootloader
@li @subpage net_netconsole
*/

1310
Doxyfile

File diff suppressed because it is too large Load Diff

View File

@ -1076,8 +1076,7 @@ help:
@echo ' enough build support to build external modules' @echo ' enough build support to build external modules'
@echo ' mrproper - Remove all generated files + config + various backup files' @echo ' mrproper - Remove all generated files + config + various backup files'
@echo ' distclean - mrproper + remove editor backup and patch files' @echo ' distclean - mrproper + remove editor backup and patch files'
@echo ' docs - start doxygen for all output types (only HTML - FIXME)' @echo ' docs - build documentation'
@echo ' htmldocs - create documentation in HTML format'
@echo '' @echo ''
@echo 'Configuration targets:' @echo 'Configuration targets:'
@$(MAKE) -f $(srctree)/scripts/kconfig/Makefile help @$(MAKE) -f $(srctree)/scripts/kconfig/Makefile help
@ -1117,16 +1116,6 @@ help:
@echo 'Execute "make" or "make all" to build all targets marked with [*] ' @echo 'Execute "make" or "make all" to build all targets marked with [*] '
@echo 'For further info see the ./README file' @echo 'For further info see the ./README file'
# Generate doxygen docs
# ---------------------------------------------------------------------------
.PHONY += docs htmldocs
docs : htmldocs
htmldocs: Doxyfile.version
@echo 'Running doxygen with local Doxyfile'
$(Q)doxygen Doxyfile
# Generate tags for editors # Generate tags for editors
# --------------------------------------------------------------------------- # ---------------------------------------------------------------------------
quiet_cmd_tags = GEN $@ quiet_cmd_tags = GEN $@
@ -1135,6 +1124,14 @@ quiet_cmd_tags = GEN $@
tags TAGS cscope: FORCE tags TAGS cscope: FORCE
$(call cmd,tags) $(call cmd,tags)
SPHINXBUILD = sphinx-build
ALLSPHINXOPTS = source
docs: FORCE
@mkdir -p $(srctree)/Documentation/commands
@$(srctree)/Documentation/gen_commands.py $(srctree) $(srctree)/Documentation/commands
@$(SPHINXBUILD) -b html -d $(objtree)/doctrees $(srctree)/Documentation \
$(objtree)/Documentation/html
endif #ifeq ($(config-targets),1) endif #ifeq ($(config-targets),1)
endif #ifeq ($(mixed-targets),1) endif #ifeq ($(mixed-targets),1)

View File

@ -1,175 +0,0 @@
/** @page dev_architecture Integrate a new architecture (ARCH)
@section linker_scripts Rules for the generic Linker Script File
Never include an object file by name directly! Linker Script Files defines the
layout, not the content. Content is defined in objecfiles instead.
Don't rely on the given object file order to create your binary @a barebox! This
may work, but is not relyable in all cases (and its a very bad style)!
For the special case some layout contraints exists, use specific section
naming instead. Refer @ref reset_code how to define this specific section.
@section reset_code Bring it up: The Reset Code
The way a CPU wakes up after reset is very specific to its architecture.
For example the ARM architecture starts its reset code at address 0x0000000,
the x86 architecture at 0x000FFFF0, PowerPC at 0x00000100 or 0xFFFFF100.
So for the special reset code on all architectures it must be located at
architecture specific locations within the binary @a barebox image.
All reset code uses section ".text_entry" for its localisation within the
binary @a barebox image. Its up to the linker script file to use this section name
to find the right place in whatever environment and @a barebox sizes.
@code
.section ".text_entry","ax"
@endcode
@section arch_files List of changes
- create a new subdirectory in /arch
TODO
*/
/** @page dev_cpu Integrate a new CPU (MACH)
Features required for every CPU:
- clocksource
- CPU reset function
@section time_keeping Time keeping
In @a barebox we are using the clocksource mechanism from the Linux Kernel.
This makes it fairly easy to add timer functionality for a new board or
architecture.
Apart from initialization there is only one function to be registerd:
clocksource_read(). This function returns the current value of a free running
counter. Other functions like udelay() and get_time_ns() are derived from this
function. The only thing you have to implement is a clocksource driver and
to register it at runtime.
@code
static uint64_t mycpu_clocksource_read(void)
{
TODO
}
static struct clocksource cs = {
.read = mycpu_clocksource_read,
.mask = 0xffffffff,
.shift = 10,
};
....
init_clock(&cs);
....
@endcode
See arch/arm/mach-imx/clocksource.c for an example. clocksource drivers from
the Linux Kernel can be used nearly 1:1, except for the register accesses.
Note: For clocksources the __lshrdi3 symbol is needed. You can find the
function for your architecture in the Linux Kernel or a libc of your choice.
@note @a barebox expects an upward counting counter!
@section reset_function Reset function
TODO
@li @subpage dev_arm_mach
@li @subpage dev_bf_mach
@li @subpage dev_mips_mach
@li @subpage dev_ppc_mach
@li @subpage dev_x86_mach
*/
/** @page io_access_functions I/O access functions
List of functions to be used for hardware register access (I/O).
@section native_access Native IN/OUT access
@note Native means: It uses the same endianess than the CPU.
@subsection single_native_access Single access of various width
The following functions are intended to be used for a single I/O access.
To read a byte (8 bit) from a specific I/O address:
@code
uint8_t readb(unsigned long)
@endcode
To read a word (16 bit) from a specific I/O address:
@code
uint16_t readw(unsigned long)
@endcode
To read a long word (32 bit) from a specific I/O address:
@code
uint32_t readl(unsigned long)
@endcode
To write a byte (8 bit) into a specific I/O address:
@code
void writeb(uint8_t val, unsigned long)
@endcode
To write a word (16 bit) into a specific I/O address:
@code
void writew(uint16_t val, unsigned long)
@endcode
To write a long word (32 bit) into a specific I/O address:
@code
void writel(uint32_t val, unsigned long)
@endcode
@subsection string_native_access String native access of various width
The following functions are intended to be used for string based I/O access.
To read a string of bytes (8 bit) from one specific I/O address:
@code
void readsb(const void __iomem *addr, void *mem_buffer, int byte_count);
@endcode
To read a string of words (16 bit) from one specific I/O address:
@code
void readsw(const void __iomem *addr, void *mem_buffer, int word_count);
@endcode
To read a string of long words (32 bit) from one specific I/O address:
@code
void readsl(const void __iomem *addr, void *mem_buffer, int long_count);
@endcode
To write a string of bytes (8 bit) to one specific I/O address:
@code
void writesb(void __iomem *addr, const void *mem_buffer, int byte_count);
@endcode
To write a string of words (16 bit) to one specific I/O address:
@code
void writesw(void __iomem *addr, const void *mem_buffer, int word_count);
@endcode
To write a string of long words (32 bit) to one specific I/O address:
@code
void writesl(void __iomem *addr, const void *mem_buffer, int long_count);
@endcode
@section special_access Special IN/OUT access
TBD
*/

View File

@ -14,12 +14,6 @@
* *
*/ */
/**
* @file
* @brief a9m2410 Specific Board Initialization routines
*
*/
#include <common.h> #include <common.h>
#include <driver.h> #include <driver.h>
#include <init.h> #include <init.h>
@ -154,65 +148,3 @@ static int a9m2410_console_init(void)
} }
console_initcall(a9m2410_console_init); console_initcall(a9m2410_console_init);
/** @page a9m2410 DIGI's a9m2410
This CPU card is based on a Samsung S3C2410 CPU. The card is shipped with:
- S3C2410\@200 MHz (ARM920T/ARMv4T)
- 12MHz crystal reference
- SDRAM 32 MiB
- Samsung K4M563233E-EE1H
- 2M x 32Bit x 4 Banks Mobile SDRAM
- 90 pin FBGA
- CL3\@133MHz, CL2\@100MHz (CAS/RAS delay 19ns)
- four banks
- 32 bit data bits
- row address size is 11
- Row cycle time: 69ns
- collumn address size is 9 bits
- Extended temperature range (-25°C...85°C)
- 64ms refresh period (4k)
- NAND Flash 32 MiB
- Samsung KM29U256T
- 32MiB 3,3V 8-bit
- ID: 0xEC, 0x75, 0x??, 0xBD
- 30ns/40ns/20ns
- I2C interface, 100KHz and 400KHz
- Real Time Clock
- Dallas DS1337
- address 0x68
- EEPROM
- ST M24LC64
- address 0x50
- 16bit addressing
- LCD interface
- Touch Screen interface
- Camera interface
- I2S interface
- AC97 Audio-CODEC interface
- SD card interface
- 3 serial RS232 interfaces
- Host and device USB interface, USB1.1 compliant
- Ethernet interface
- 10Mbps, Cirrus Logic, CS8900A (on the CPU card) or
- 10/100Mbps, SMSC 91C111 (on the baseboard)
- SPI interface
- JTAG interface
How to get the binary image:
Using the default configuration:
@code
make ARCH=arm a9m2410_defconfig
@endcode
Build the binary image:
@code
make ARCH=arm CROSS_COMPILE=armv4compiler
@endcode
@note replace the armv4compiler with your ARM v4 cross compiler.
*/

View File

@ -14,12 +14,6 @@
* *
*/ */
/**
* @file
* @brief a9m2440 Specific Board Initialization routines
*
*/
#include <common.h> #include <common.h>
#include <driver.h> #include <driver.h>
#include <init.h> #include <init.h>
@ -161,76 +155,3 @@ static int a9m2440_console_init(void)
} }
console_initcall(a9m2440_console_init); console_initcall(a9m2440_console_init);
/** @page a9m2440 DIGI's a9m2440
This CPU card is based on a Samsung S3C2440 CPU. The card is shipped with:
- S3C2440\@400 MHz or 533 MHz (ARM920T/ARMv4T)
- 16.9344 MHz crystal reference
- SDRAM 32/64/128 MiB
- Samsung K4M563233E-EE1H (one or two devices for 32 MiB or 64 MiB)
- 2M x 32bit x 4 Banks Mobile SDRAM
- CL2\@100 MHz (CAS/RAS delay 19ns)
- 105 MHz max
- collumn address size is 9 bits
- Row cycle time: 69ns
- Samsung K4M513233C-DG75 (one or two devices for 64 MiB or 128 MiB)
- 4M x 32bit x 4 Banks Mobile SDRAM
- CL2\@100MHz (CAS/RAS delay 18ns)
- 111 MHz max
- collumn address size is 9 bits
- Row cycle time: 63ns
- 64ms refresh period (4k)
- 90 pin FBGA
- 32 bit data bits
- Extended temperature range (-25°C...85°C)
- NAND Flash 32/64/128 MiB
- Samsung KM29U512T (NAND01GW3A0AN6)
- 64 MiB 3,3V 8-bit
- ID: 0xEC, 0x76, 0x??, 0xBD
- Samsung KM29U256T
- 32 MiB 3,3V 8-bit
- ID: 0xEC, 0x75, 0x??, 0xBD
- ST Micro
- 128 MiB 3,3V 8-bit
- ID: 0x20, 0x79
- 30ns/40ns/20ns
- I2C interface, 100 KHz and 400 KHz
- Real Time Clock
- Dallas DS1337
- address 0x68
- EEPROM
- ST M24LC64
- address 0x50
- 16bit addressing
- LCD interface
- Touch Screen interface
- Camera interface
- I2S interface
- AC97 Audio-CODEC interface
- SD card interface
- 3 serial RS232 interfaces
- Host and device USB interface, USB1.1 compliant
- Ethernet interface
- 10Mbps, Cirrus Logic, CS8900A (on the CPU card)
- SPI interface
- JTAG interface
How to get the binary image:
Using the default configuration:
@code
make ARCH=arm a9m2440_defconfig
@endcode
Build the binary image:
@code
make ARCH=arm CROSS_COMPILE=armv4compiler
@endcode
@note replace the armv4compiler with your ARM v4 cross compiler.
*/

View File

@ -15,37 +15,6 @@
* *
*/ */
/**
* @file
* @brief Beagle Specific Board Initialization routines
*/
/**
* @page ti_beagle Texas Instruments Beagle Board
*
* Beagle Board from Texas Instruments as described here:
* http://www.beagleboard.org
*
* This board is based on OMAP3530.
* More on OMAP3530 (including documentation can be found here):
* http://focus.ti.com/docs/prod/folders/print/omap3530.html
*
* This file provides initialization in two stages:
* @li boot time initialization - do basics required to get SDRAM working.
* This is run from SRAM - so no case constructs and global vars can be used.
* @li run time initialization - this is for the rest of the initializations
* such as flash, uart etc.
*
* Boot time initialization includes:
* @li SDRAM initialization.
* @li Pin Muxing relevant for Beagle.
*
* Run time initialization includes
* @li serial @ref serial_ns16550.c driver device definition
*
* Originally from arch/arm/boards/omap/board-sdp343x.c
*/
#include <common.h> #include <common.h>
#include <console.h> #include <console.h>
#include <init.h> #include <init.h>

View File

@ -1,7 +0,0 @@
/** @page ccxmx51 Digi ConnectCore board
This boards is based on a Freescale i.MX51 CPU. The board is shipped with:
- Up to 8 GB NAND Flash.
- Up to 512 MB DDR2 RAM.
*/

View File

@ -318,141 +318,3 @@ static int falconwing_console_init(void)
} }
console_initcall(falconwing_console_init); console_initcall(falconwing_console_init);
/** @page chumbyone Chumby Industrie's Falconwing
This device is also known as "chumby one" (http://www.chumby.com/)
This CPU card is based on a Freescale i.MX23 CPU. The card is shipped with:
- 64 MiB synchronous dynamic RAM (DDR type)
Memory layout when @b barebox is running:
- 0x40000000 start of SDRAM
- 0x40000100 start of kernel's boot parameters
- below malloc area: stack area
- below barebox: malloc area
- 0x42000000 start of @b barebox
@section get_falconwing_binary How to get the bootloader binary image:
Using the default configuration:
@verbatim
make ARCH=arm chumbyone_defconfig
@endverbatim
Build the bootloader binary image:
@verbatim
make ARCH=arm CROSS_COMPILE=armv5compiler
@endverbatim
@note replace the armv5compiler with your ARM v5 cross compiler.
@section setup_falconwing How to prepare an MCI card to boot the "chumby one" with barebox
- Create four primary partitions on the MCI card
- the first one for the bootlets (about 256 kiB)
- the second one for the persistant environment (size is up to you, at least 256k)
- the third one for the kernel (2 MiB ... 4 MiB in size)
- the 4th one for the root filesystem which can fill the rest of the available space
- Mark the first partition with the partition ID "53" and copy the bootlets
into this partition (currently not part of @b barebox!).
- Copy the default @b barebox environment into the second partition (no filesystem required).
- Copy the kernel into the third partition (no filesystem required).
- Create the root filesystem in the 4th partition. You may copy an image into this
partition or you can do it in the classic way: mkfs on it, mount it and copy
all required data and programs into it.
@section gpio_falconwing Available GPIOs
The Falconwing uses some GPIOs to control various features. With the regular
GPIO commands these features can be controlled at @a barebox's runtime.
<table width="100%" border="1" cellspacing="1" cellpadding="3">
<tr>
<td>No</td>
<td>Direction</td>
<td>Function</td>
<td>Reset</td>
<td>Set</td>
</tr>
<tr>
<td>8</td>
<td>Output</td>
<td>Switch Audio Amplifier</td>
<td>Off</td>
<td>On</td>
</tr>
<tr>
<td>11</td>
<td>Input</td>
<td>Head Phone Detection</td>
<td>TBD</td>
<td>TBD</td>
</tr>
<tr>
<td>14</td>
<td>Input</td>
<td>Unused (J113)</td>
<td>User</td>
<td>User</td>
</tr>
<tr>
<td>15</td>
<td>Input</td>
<td>Unused (J114)</td>
<td>User</td>
<td>User</td>
</tr>
<tr>
<td>26</td>
<td>Output</td>
<td>USB Power</td>
<td>TBD</td>
<td>TBD</td>
</tr>
<tr>
<td>27</td>
<td>Input</td>
<td>Display Connected</td>
<td>Display<br>Attached</td>
<td>Display<br>Disconnected</td>
</tr>
<tr>
<td>29</td>
<td>Output</td>
<td>USB HUB Reset</td>
<td>TBD</td>
<td>TBD</td>
</tr>
<tr>
<td>50</td>
<td>Output</td>
<td>Display Reset</td>
<td>Display<br>Reset</td>
<td>Display<br>Running</td>
</tr>
<tr>
<td>60</td>
<td>Output</td>
<td>Display Backlight</td>
<td>Backlight<br>Off</td>
<td>Backlight<br>On (100 %)</td>
</tr>
<tr>
<td>62</td>
<td>Input</td>
<td>Bend</td>
<td>Not pressed</td>
<td>Pressed</td>
</tr>
</table>
*/

View File

@ -1,108 +0,0 @@
/** @page edb9301 Cirrus Logic EDB9301
This boards is based on a Cirrus Logic EP9301 CPU. The board is shipped with:
- 16MiB NOR type Flash Memory
- 32MiB synchronous dynamic RAM on CS3
- 128kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
*/
/** @page edb9302 Cirrus Logic EDB9302
This board is based on a Cirrus Logic EP9302 CPU. The board is shipped with:
- 16MiB NOR type Flash Memory
- 32MiB synchronous dynamic RAM on CS3
- 128kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
*/
/** @page edb9302a Cirrus Logic EDB9302A
This board is based on a Cirrus Logic EP9302 CPU. The board is shipped with:
- 16MiB NOR type Flash Memory
- 32MiB synchronous dynamic RAM on CS0
- 512kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
*/
/** @page edb9307 Cirrus Logic EDB9307
This board is based on a Cirrus Logic EP9307 CPU. The board is shipped with:
- 32MiB NOR type Flash Memory
- 64MiB synchronous dynamic RAM on CS3
- 512kiB asynchronous SRAM
- 128kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
- Real-Time Clock
- IR receiver
*/
/** @page edb9307a Cirrus Logic EDB9307A
This board is based on a Cirrus Logic EP9307 CPU. The board is shipped with:
- 32MiB NOR type Flash Memory
- 64MiB synchronous dynamic RAM on CS0
- 512kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
- Real-Time Clock
- IR receiver
*/
/** @page edb9312 Cirrus Logic EDB9312
This board is based on a Cirrus Logic EP9312 CPU. The board is shipped with:
- 32MiB NOR type Flash Memory
- 64MiB synchronous dynamic RAM on CS3
- 512kiB asynchronous SRAM
- 128kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
- Real-Time Clock
- IR receiver
*/
/** @page edb9315 Cirrus Logic EDB9315
This board is based on a Cirrus Logic EP9315 CPU. The board is shipped with:
- 32MiB NOR type Flash Memory
- 64MiB synchronous dynamic RAM on CS3
- 512kiB asynchronous SRAM
- 128kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
- Real-Time Clock
- IR receiver
*/
/** @page edb9315a Cirrus Logic EDB9315A
This board is based on a Cirrus Logic EP9315 CPU. The board is shipped with:
- 32MiB NOR type Flash Memory
- 64MiB synchronous dynamic RAM on CS0
- 128kiB serial EEPROM
- MII 10/100 Ethernet PHY
- Stereo audio codec
- Real-Time Clock
- IR receiver
*/

View File

@ -1,11 +0,0 @@
/** @page eukrea_cpuimx27 Eukrea's CPUIMX27
This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with:
- up to 64MiB NOR type Flash Memory
- up to 256MiB synchronous dynamic RAM
- up to 512MiB NAND type Flash Memory
- MII 10/100 ethernet PHY
- optional 16554 Quad UART on CS3
*/

View File

@ -1,4 +0,0 @@
/** @page eukrea_cpuimx35 Eukrea's CPUIMX35
*/

View File

@ -1,4 +0,0 @@
/** @page eukrea_cpuimx51 Eukrea's CPUIMX51
*/

View File

@ -1,5 +0,0 @@
/** @page imx21ads Freescale i.MX21ads
This is the Freescale evaluation board for the i.MX21 Processor
*/

View File

@ -144,35 +144,3 @@ static int mx23_evk_console_init(void)
} }
console_initcall(mx23_evk_console_init); console_initcall(mx23_evk_console_init);
/** @page mx23_evk Freescale's i.MX23 evaluation kit
This CPU card is based on an i.MX23 CPU. The card is shipped with:
- 32 MiB synchronous dynamic RAM (mobile DDR type)
- ENC28j60 based network (over SPI)
Memory layout when @b barebox is running:
- 0x40000000 start of SDRAM
- 0x40000100 start of kernel's boot parameters
- below malloc area: stack area
- below barebox: malloc area
- 0x41000000 start of @b barebox
@section get_imx23evk_binary How to get the bootloader binary image:
Using the default configuration:
@verbatim
make ARCH=arm imx23evk_defconfig
@endverbatim
Build the bootloader binary image:
@verbatim
make ARCH=arm CROSS_COMPILE=armv5compiler
@endverbatim
@note replace the armv5compiler with your ARM v5 cross compiler.
*/

View File

@ -1,5 +0,0 @@
/** @page imx27ads Freescale i.MX27ads
This is the Freescale evaluation board for the i.MX27 Processor
*/

Some files were not shown because too many files have changed in this diff Show More