Merge branch 'for-next/doc'
This commit is contained in:
commit
ce1b0d4ae3
|
@ -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-*
|
||||||
|
|
|
@ -1 +1,2 @@
|
||||||
|
build
|
||||||
html
|
html
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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>
|
|
||||||
*
|
|
||||||
*/
|
|
|
@ -0,0 +1,10 @@
|
||||||
|
.. _boards:
|
||||||
|
|
||||||
|
Board support
|
||||||
|
=============
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 2
|
||||||
|
|
||||||
|
boards/*
|
|
@ -0,0 +1,9 @@
|
||||||
|
Cirrus Logic edb9xxx
|
||||||
|
====================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:numbered:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
edb9xxx/*
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
||||||
|
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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/*
|
|
@ -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
|
|
@ -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.
|
|
@ -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
|
||||||
|
|
|
@ -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
|
|
@ -0,0 +1,9 @@
|
||||||
|
MIPS
|
||||||
|
====
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:numbered:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
mips/*
|
|
@ -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
|
|
@ -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
|
|
@ -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/
|
|
@ -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
|
|
@ -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/
|
|
@ -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.
|
|
@ -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.
|
|
@ -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
|
|
@ -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.
|
|
@ -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.
|
|
@ -0,0 +1,9 @@
|
||||||
|
Samsung S3C/S5P
|
||||||
|
===============
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:numbered:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
s3c/*
|
|
@ -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.
|
|
@ -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.
|
|
@ -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.
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -0,0 +1,9 @@
|
||||||
|
Command reference
|
||||||
|
=================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
commands/*
|
||||||
|
|
|
@ -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'
|
|
@ -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.
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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.
|
|
||||||
|
|
||||||
|
|
|
@ -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.
|
|
|
@ -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";
|
||||||
|
};
|
|
@ -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";
|
|
||||||
};
|
|
|
@ -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
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
|
@ -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>;
|
||||||
|
};
|
|
@ -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>;
|
|
||||||
};
|
|
|
@ -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>;
|
||||||
|
};
|
|
@ -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>;
|
|
||||||
};
|
|
|
@ -0,0 +1,13 @@
|
||||||
|
Barebox specific devicetree bindings
|
||||||
|
====================================
|
||||||
|
|
||||||
|
Contents:
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:numbered:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
bindings/barebox/*
|
||||||
|
bindings/leds/*
|
||||||
|
bindings/misc/*
|
|
@ -0,0 +1,10 @@
|
||||||
|
.. _filesystems:
|
||||||
|
|
||||||
|
Filesystems
|
||||||
|
===========
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:maxdepth: 2
|
||||||
|
:glob:
|
||||||
|
|
||||||
|
filesystems/*
|
|
@ -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
|
||||||
|
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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.
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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)
|
||||||
|
|
|
@ -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
|
|
@ -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`
|
||||||
|
|
|
@ -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.
|
|
||||||
*/
|
|
|
@ -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.
|
|
|
@ -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.
|
|
|
@ -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.
|
|
|
@ -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``.
|
|
@ -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.
|
|
@ -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"
|
|
@ -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
|
|
@ -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
|
|
@ -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.
|
|
@ -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
|
||||||
|
|
|
@ -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
|
|
@ -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)
|
|
@ -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
|
||||||
|
|
|
@ -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``
|
|
@ -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.
|
|
@ -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``)
|
|
@ -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
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^^^^
|
|
@ -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``.
|
||||||
|
|
|
@ -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.
|
|
@ -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.
|
|
@ -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`
|
||||||
|
|
|
@ -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
|
||||||
|
...
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
21
Makefile
21
Makefile
|
@ -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)
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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.
|
|
||||||
*/
|
|
||||||
|
|
|
@ -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.
|
|
||||||
|
|
||||||
*/
|
|
||||||
|
|
|
@ -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>
|
||||||
|
|
|
@ -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.
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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>
|
|
||||||
|
|
||||||
*/
|
|
||||||
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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
|
|
||||||
|
|
||||||
*/
|
|
|
@ -1,4 +0,0 @@
|
||||||
/** @page eukrea_cpuimx35 Eukrea's CPUIMX35
|
|
||||||
|
|
||||||
|
|
||||||
*/
|
|
|
@ -1,4 +0,0 @@
|
||||||
/** @page eukrea_cpuimx51 Eukrea's CPUIMX51
|
|
||||||
|
|
||||||
|
|
||||||
*/
|
|
|
@ -1,5 +0,0 @@
|
||||||
/** @page imx21ads Freescale i.MX21ads
|
|
||||||
|
|
||||||
This is the Freescale evaluation board for the i.MX21 Processor
|
|
||||||
|
|
||||||
*/
|
|
|
@ -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.
|
|
||||||
*/
|
|
||||||
|
|
|
@ -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
Loading…
Reference in New Issue