Documentation: remove doxygen documentation
The doxygen documentation is long outdated. Remove it. It will be replaced with sphinx based documentation later. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This commit is contained in:
Sascha Hauer
parent
7b82f54858
commit
98360be0fe
|
|
@ -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>
|
||||
*
|
||||
*/
|
||||
|
|
@ -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
|
||||
|
||||
*/
|
||||
|
|
@ -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,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.
|
||||
|
||||
*/
|
||||
|
|
@ -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,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
|
||||
|
||||
*/
|
||||
10
Makefile
10
Makefile
|
|
@ -1117,16 +1117,6 @@ help:
|
|||
@echo 'Execute "make" or "make all" to build all targets marked with [*] '
|
||||
@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
|
||||
# ---------------------------------------------------------------------------
|
||||
quiet_cmd_tags = GEN $@
|
||||
|
|
|
|||
|
|
@ -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 <driver.h>
|
||||
#include <init.h>
|
||||
|
|
@ -154,65 +148,3 @@ static int a9m2410_console_init(void)
|
|||
}
|
||||
|
||||
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 <driver.h>
|
||||
#include <init.h>
|
||||
|
|
@ -161,76 +155,3 @@ static int a9m2440_console_init(void)
|
|||
}
|
||||
|
||||
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 <console.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);
|
||||
|
||||
/** @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);
|
||||
|
||||
/** @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
|
||||
|
||||
*/
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
/** @page the3stack Freescale MX35 3-Stack Board
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
/** @page board_babage Freescale i.MX51 PDK (Babbage) Board
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
/** @page board_loco Freescale i.MX53 PDK (Loco) Board
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
/** @page board_loco Freescale i.MX53 SMD Board
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -16,12 +16,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief mini2440 Specific Board Initialization routines
|
||||
*
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <driver.h>
|
||||
#include <init.h>
|
||||
|
|
@ -338,156 +332,3 @@ static int mini2440_console_init(void)
|
|||
}
|
||||
|
||||
console_initcall(mini2440_console_init);
|
||||
|
||||
/** @page mini2440 FriendlyARM's mini2440
|
||||
|
||||
This system is based on a Samsung S3C2440 CPU. The card is shipped with:
|
||||
|
||||
- S3C2440\@400 MHz or 533 MHz (ARM920T/ARMv4T)
|
||||
- 12 MHz crystal reference
|
||||
- 32.768 kHz crystal reference
|
||||
- SDRAM 64 MiB (one bank only)
|
||||
- HY57V561620 (two devices for 64 MiB to form a 32 bit bus)
|
||||
- 4M x 16bit x 4 Banks Mobile SDRAM
|
||||
- 8192 refresh cycles / 64 ms
|
||||
- CL2\@100 MHz
|
||||
- 133 MHz max
|
||||
- collumn address size is 9 bits
|
||||
- row address size is 13 bits
|
||||
- MT48LC16M16 (two devices for 64 MiB to form a 32 bit bus)
|
||||
- 4M x 16bit x 4 Banks Mobile SDRAM
|
||||
- commercial & industrial type
|
||||
- 8192 refresh cycles / 64 ms
|
||||
- CL2\@100 MHz
|
||||
- 133 MHz max
|
||||
- collumn address size is 9 bits
|
||||
- row address size is 13 bits
|
||||
- NAND Flash 128MiB...1GiB
|
||||
- K9Fxx08
|
||||
- NOR Flash (up to 22 address lines available)
|
||||
- AM29LV160DB, 2 MiB
|
||||
- SST39VF1601, 2 MiB
|
||||
- 16 bit data bus
|
||||
- SD card interface, 3.3V (fixed voltage)
|
||||
- Host and device USB interface, USB1.1 compliant
|
||||
- UDA1341TS Audio
|
||||
- DM9000 Ethernet interface
|
||||
- uses CS#4
|
||||
- uses EINT7
|
||||
- 16 bit data bus
|
||||
- I2C interface, 100 KHz and 400 KHz
|
||||
- EEPROM
|
||||
- ST M24C08
|
||||
- address 0x50
|
||||
- Speaker on GPB0 ("low" = inactive)
|
||||
- LCD interface
|
||||
- Touch Screen interface
|
||||
- Camera interface
|
||||
- I2S interface
|
||||
- AC97 Audio-CODEC interface
|
||||
- three serial RS232 interfaces (one with level converter)
|
||||
- SPI interface
|
||||
- JTAG interface
|
||||
|
||||
How to get the binary image:
|
||||
|
||||
Using the default configuration:
|
||||
|
||||
@code
|
||||
make ARCH=arm mini2440_defconfig
|
||||
@endcode
|
||||
|
||||
Build the binary image:
|
||||
|
||||
@code
|
||||
make ARCH=arm CROSS_COMPILE=armv4compiler
|
||||
@endcode
|
||||
|
||||
@note replace the armv4compiler with your ARM v4 cross compiler.
|
||||
|
||||
How to bring in \a barebox ?
|
||||
|
||||
First run it as a second stage bootloader. There are two known working ways to
|
||||
do so:
|
||||
|
||||
One way is to use the "device firmware update" feature of the 'supervivi'.
|
||||
- connect a terminal application to the mini2440's serial connector
|
||||
- switch S2 to 'boot from NOR' to boot into 'supervivi'
|
||||
- connect your host to the usb device connector on the mini2440
|
||||
- switch on your mini2440
|
||||
- in 'supervivi' type q (command line) then:
|
||||
@code
|
||||
load ram 0x31000000 \<barebox-size\> u
|
||||
@endcode
|
||||
- use a tool for DFU update (for example from openkomo) to transfer the 'barebox.bin' binary
|
||||
- then in 'supervivi' just run
|
||||
@code
|
||||
go 0x31000000
|
||||
@endcode
|
||||
|
||||
A second way is to use any kind of JTAG adapter. For this case I'm using the
|
||||
'JTAKkey tiny' from Amontec and OpenOCD. First you need an adapter for this
|
||||
kind of Dongle as it uses a 20 pin connector with 2.54 mm grid, and the
|
||||
mini2440 uses a 10 pin connector with 2 mm grid.
|
||||
|
||||
@code
|
||||
Amontec JTAGkey tiny mini2440
|
||||
-------------------------------------------------------
|
||||
VREF 1 2 n.c. VREF 1 2 VREF
|
||||
TRST_N 3 4 GND TRST_N 3 4 SRST_N
|
||||
TDI 5 6 GND TDI 5 6 TDO
|
||||
TMS 7 8 GND TMS 7 8 GND
|
||||
TCK 9 10 GND TCK 9 10 GND
|
||||
n.c. 11 12 GND
|
||||
TDO 13 14 GND
|
||||
SRST_N 15 16 GND
|
||||
n.c. 17 18 GND
|
||||
n.c. 19 20 GND
|
||||
@endcode
|
||||
|
||||
Create a simple board description file. I did it this way:
|
||||
|
||||
@code
|
||||
source [find interface/jtagkey-tiny.cfg]
|
||||
source [find target/samsung_s3c2440.cfg]
|
||||
|
||||
adapter_khz 12000
|
||||
@endcode
|
||||
|
||||
And then the following steps:
|
||||
- connect a terminal application to the mini2440's serial connector
|
||||
- connect the mini2440 to a working network
|
||||
- switch S2 to boot from NOR to boot into 'supervivi'
|
||||
- switch on your mini2440
|
||||
- run the OpenOCD daemon configured with the file shown above
|
||||
- connect to the OpenOCD daemon via 'telnet'.
|
||||
- run the following commands to download @a barebox into your target
|
||||
@code
|
||||
> halt
|
||||
> load_image \<path to the 'barebox.bin'\> 0x31000000 bin
|
||||
> resume 0x31000000
|
||||
@endcode
|
||||
|
||||
Now @a barebox is starting from an already initialized CPU and SDRAM (done by
|
||||
'supervivi').
|
||||
|
||||
Change to your terminal console and configure the network first. Adapt the
|
||||
following settings to your network:
|
||||
@code
|
||||
eth0.ipaddr=192.168.1.240
|
||||
eth0.netmask=255.255.255.0
|
||||
eth0.gateway=192.168.23.2
|
||||
eth0.serverip=192.168.1.7
|
||||
eth0.ethaddr=00:04:f3:00:06:35
|
||||
@endcode
|
||||
|
||||
A 'ping' to your TFTP server should bring a "...is alive" message now.
|
||||
|
||||
We are ready now to program @a barebox into the NAND flash:
|
||||
|
||||
@code
|
||||
erase /dev/nand0.barebox.bb
|
||||
tftp barebox.bin /dev/nand0.barebox.bb
|
||||
@endcode
|
||||
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -1,9 +0,0 @@
|
|||
/** @page board_cupid 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
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -143,62 +143,3 @@ static int imx23_olinuxino_console_init(void)
|
|||
}
|
||||
|
||||
console_initcall(imx23_olinuxino_console_init);
|
||||
|
||||
/** @page olinuxino Olimex.ltd's i.MX23 evaluation kit
|
||||
|
||||
This CPU card is based on an i.MX23 CPU. The card is shipped with:
|
||||
|
||||
- 64 MiB synchronous dynamic RAM (mobile 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_imx23_olinuxino_binary How to get the bootloader binary image:
|
||||
|
||||
Using the default configuration:
|
||||
|
||||
@verbatim
|
||||
make ARCH=arm imx23_olinuxino_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 imx233-olinuxino How to prepare an MCI card to boot
|
||||
the imx233-olinuxino 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!).
|
||||
|
||||
- @b barebox expect device tree blob file imx23-olinuxino.dtb
|
||||
into directory env/oftree. At compile time, copy blob file into directory
|
||||
arch/arm/boards/imx233-olinuxino/env/oftree/.
|
||||
|
||||
- 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.
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -99,55 +99,3 @@ static int tx28_devices_init(void)
|
|||
}
|
||||
|
||||
device_initcall(tx28_devices_init);
|
||||
|
||||
/**
|
||||
@page tx28 KARO's TX28 CPU module
|
||||
|
||||
@section tx28_cpu_card 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
|
||||
|
||||
@section tx28_basboards Supported baseboards
|
||||
|
||||
Supported baseboards are:
|
||||
- KARO's Starterkit 5
|
||||
|
||||
@section tx28_stk5_howto How to get barebox for 'KARO's Starterkit 5'
|
||||
|
||||
Using the default configuration:
|
||||
|
||||
@verbatim
|
||||
make ARCH=arm tx28stk5_defconfig
|
||||
@endverbatim
|
||||
|
||||
Build the binary image:
|
||||
|
||||
@verbatim
|
||||
make ARCH=arm CROSS_COMPILE=armv5compiler
|
||||
@endverbatim
|
||||
|
||||
@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 @b barebox from an attached SD card the
|
||||
'sdimage' tool from Freescale's 'uuc' archive.
|
||||
|
||||
@section tx28_mlayout 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 @b barebox
|
||||
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -1,50 +0,0 @@
|
|||
/**
|
||||
@page tx51 KARO's TX51 CPU module
|
||||
|
||||
@section tx51_cpu_card The CPU module
|
||||
|
||||
http://www.karo-electronics.de/
|
||||
|
||||
This CPU card is based on a Freescale i.MX51 CPU. The card is shipped with:
|
||||
|
||||
- 128 MiB synchronous dynamic RAM (DDR2 type), 200 MHz support
|
||||
- 128 MiB NAND K9F1G08U0A (3.3V type)
|
||||
- DS1339 RTC
|
||||
- LAN8700 Phy
|
||||
|
||||
@section tx51_baseboards Supported baseboards
|
||||
|
||||
Supported baseboards are:
|
||||
- KARO's Starterkit 5 (currently only SD1, FEC implemented but non-working)
|
||||
|
||||
@section tx28_stk5_howto How to get barebox for 'KARO's Starterkit 5'
|
||||
|
||||
Using the default configuration:
|
||||
|
||||
@verbatim
|
||||
make ARCH=arm tx51tk5_defconfig
|
||||
@endverbatim
|
||||
|
||||
Build the binary image:
|
||||
|
||||
@verbatim
|
||||
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
|
||||
@endverbatim
|
||||
|
||||
@note replace the arm-linux-gnueabi with your ARM v7 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 @b barebox from an attached SD card the
|
||||
'sdimage' tool from Freescale's 'uuc' archive.
|
||||
|
||||
@section tx28_mlayout Memory layout when barebox is running:
|
||||
|
||||
- 0x90000000 start of SDRAM
|
||||
- 0x90000100 start of kernel's boot parameters
|
||||
- below malloc area: stack area
|
||||
- below barebox: malloc area
|
||||
- 0x97f00000 start of @b barebox
|
||||
|
||||
*/
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
/** @page module-mb7707 MB 77.07 board
|
||||
|
||||
The board uses MBOOT as bootloader.
|
||||
|
||||
Barebox mini-howto:
|
||||
|
||||
1. Connect to the boards's UART (38400 8N1);
|
||||
|
||||
2. Turn board's power on;
|
||||
|
||||
3. Wait 'Hit any key (in 2 sec) to skip autoload...' prompt and press the space key;
|
||||
|
||||
4. Compile zbarebox.bin image and upload it to the board via tftp
|
||||
@verbatim
|
||||
MBOOT # tftpboot zbarebox.bin
|
||||
greth: greth_halt
|
||||
TFTP Using GRETH_10/100 device
|
||||
TFTP params: server 192.168.0.1 our_ip 192.168.0.7
|
||||
TFTP params: filename 'zbarebox.bin' load_address 0x40100000
|
||||
TFTP Loading: ################
|
||||
TFTP done
|
||||
@endverbatim
|
||||
|
||||
5. Run barebox
|
||||
@verbatim
|
||||
MBOOT # go 0x40100000
|
||||
@endverbatim
|
||||
|
||||
*/
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
/** @page mx31moboard EPFL mx31moboard
|
||||
|
||||
This CPU card is based on a Freescale i.MX31 CPU. The card is shipped with:
|
||||
|
||||
- 32MiB NOR type Flash Memory
|
||||
- 128MiB LPDDR
|
||||
- A least one SD slot
|
||||
- A least one USB host (H2)
|
||||
|
||||
*/
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
/** @page netx Hilscher's NetX card family
|
||||
|
||||
This CPU card is based on a Hilscher's NetX ARM CPU. The card is shipped
|
||||
in various incarnations:
|
||||
|
||||
Specific to this CPU is, it does not require any setup code to bring the
|
||||
SDRAM up and working. This is done in a pre bootloader.
|
||||
|
||||
*/
|
||||
|
|
@ -15,32 +15,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief SDP3430 Specific Board Initialization routines
|
||||
*/
|
||||
|
||||
/**
|
||||
* @page ti_SDP3430 Texas Instruments SDP3430
|
||||
*
|
||||
* SDP3430 from Texas Instruments as described here:
|
||||
* http://www.ti.com/omap3430_devplatform
|
||||
* 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 SDP3430.
|
||||
*
|
||||
* Run time initialization includes
|
||||
* @li serial @ref serial_ns16550.c driver device definition
|
||||
*
|
||||
* Originally from http://linux.omap.com/pub/bootloader/3430sdp/u-boot-v1.tar.gz
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <console.h>
|
||||
#include <init.h>
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
/** @page pcm038 Phytec's phyCORE-i.MX27
|
||||
|
||||
This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with:
|
||||
|
||||
- up to 32MiB NOR type Flash Memory
|
||||
- 32MiB synchronous dynamic RAM
|
||||
|
||||
*/
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
/** @page phycard-a-l1 Phytec's phyCARD-A-L1 (OMAP35xx)
|
||||
|
||||
This phyCARD is based on a Texas Instruments OMAP35xx CPU.
|
||||
The card is shipped with:
|
||||
|
||||
- 256MiB DDR-RAM
|
||||
- 256MiB NAND Flash Memory
|
||||
- SMSC9221 ethernet controller
|
||||
- USB-host interface
|
||||
- USB-OTG interface
|
||||
- LVDS camera interface
|
||||
- LVDS display interface
|
||||
- TPS65023 Power-Managmanet IC
|
||||
- 4kB I2C EEPROM
|
||||
|
||||
*/
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
/** @page pcm038 Phytec's phyCORE-i.MX27
|
||||
|
||||
This CPU card is based on a Freescale i.MX27 CPU. The card is shipped with:
|
||||
|
||||
- up to 64MB NOR Flash Memory
|
||||
- up to 1GB NAND Flash Memory
|
||||
- up to 256MB DRAM
|
||||
|
||||
*/
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
/** @page pcm037 Phytec's phyCORE-i.MX31
|
||||
|
||||
This CPU card is based on a Freescale i.MX31 CPU. The card is shipped with:
|
||||
|
||||
- up to 64MiB NOR type Flash Memory
|
||||
- up to 2MiB static RAM
|
||||
- 64MiB NAND type Flash Memory
|
||||
- SMSC 9217 network controller
|
||||
- 128MiB synchronous dynamic RAM
|
||||
|
||||
*/
|
||||
|
|
@ -1,28 +0,0 @@
|
|||
/** @page pcm043 Phytec's phyCORE-i.MX35
|
||||
|
||||
This CPU card is based on a Freescale i.MX35 CPU. The card is shipped with:
|
||||
|
||||
|
||||
FIXME:
|
||||
- up to 64 MiB NOR type Flash Memory
|
||||
- up to 2 MiB static RAM
|
||||
- 1 GiB or 2 GiB NAND type Flash Memory
|
||||
- Micron NAND 1 GiB 3,3V 8-bit
|
||||
- 256 kiB block size
|
||||
- ? kiB page size
|
||||
- Manufacturer ID: 0x2c
|
||||
- Device ID: 0xd3
|
||||
- Samsung K9K8G08, 1 GiB
|
||||
- 128 kiB block size
|
||||
- 2 kiB page size
|
||||
- Manufacturer ID: ?
|
||||
- Device ID: ?
|
||||
- ST NAND08G, 1 GiB
|
||||
- 128 kiB block size
|
||||
- 2 kiB page size
|
||||
- Manufacturer ID: ?
|
||||
- Device ID: ?
|
||||
- 128MiB synchronous dynamic RAM
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
/**
|
||||
@page qil-a9260 Calao-systems QIL-A9260
|
||||
|
||||
@section qil-a9260 The CPU module
|
||||
|
||||
http://www.calao-systems.com
|
||||
|
||||
This CPU module is based on an Atmel AT91SAM9260 CPU. The card is shipped with:
|
||||
|
||||
- 64MiB or 128MiB SDRAM (3.3V)
|
||||
- 256MiB NAND type Flash Memory (3.3V)
|
||||
- 64Kib SPI EEPROM
|
||||
- RMII 10/100 ethernet PHY
|
||||
- Real Time Clock
|
||||
- micro SD socket
|
||||
|
||||
@section mob-qil-a9xxx Supported development board
|
||||
|
||||
Supported development board is:
|
||||
- MOB-QIL-A9xxx
|
||||
|
||||
*/
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
/** @page scb9328 Synertronixx's scb9328
|
||||
|
||||
This CPU card is based on a Freescale i.MX1 CPU. The card is shipped with:
|
||||
|
||||
- up to 16MiB NOR type Flash Memory
|
||||
- 16MiB synchronous dynamic RAM
|
||||
- DM9000 network controller
|
||||
|
||||
*/
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
/**
|
||||
@page tny-a9263 Calao-systems TNY-A9263
|
||||
|
||||
@section tny-a9263 The CPU module
|
||||
|
||||
http://www.calao-systems.com
|
||||
|
||||
This CPU module is based on an Atmel AT91SAM9263 CPU. The module is shipped with:
|
||||
|
||||
- 64MiB SDRAM (3.3V)
|
||||
- 256MiB NAND type Flash Memory (3.3V)
|
||||
- USB device port
|
||||
- Top expansion connector for daughter boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...)
|
||||
- Bottom expansion connector for development boards
|
||||
|
||||
@section mob-tny-a9xxx-md2 Supported development board
|
||||
|
||||
Supported development board is:
|
||||
- MOB-TNY-A9xxx-MD2
|
||||
|
||||
@section tny-db-boards Supported daughter boards
|
||||
|
||||
Supported daughter boards are:
|
||||
- DAB-GPI2-CXX
|
||||
- DAB-GPS
|
||||
- DAB-GPRS
|
||||
- DAB-HSDPA
|
||||
- DAB-WLAN-BT
|
||||
- DAB-ZIGBEE
|
||||
- DAB-MBUS
|
||||
- DAB-KNX-RF
|
||||
|
||||
*/
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
/**
|
||||
@page tny-a9g20-lpw Calao-systems TNY-A9G20-LPW
|
||||
|
||||
@section tny-a9g20-lpw The CPU module
|
||||
|
||||
http://www.calao-systems.com
|
||||
|
||||
This CPU module is based on an Atmel AT91SAM9G20 CPU. The module is shipped with:
|
||||
|
||||
- 64MiB Low Power SDRAM (1.8V)
|
||||
- 256MiB NAND type Flash Memory (1.8V)
|
||||
- Real Time Clock (I2C)
|
||||
- Micro SD socket
|
||||
- USB device port
|
||||
- JTAG connector
|
||||
- Top expansion connector for daughter boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...)
|
||||
- Bottom expansion connector for development boards
|
||||
|
||||
@section mob-tny-a9xxx-md2 Supported development board
|
||||
|
||||
Supported development board is:
|
||||
- MOB-TNY-A9xxx-MD2
|
||||
|
||||
@section tny-db-boards Supported daughter boards
|
||||
|
||||
Supported daughter boards are:
|
||||
- DAB-GPI2-CXX
|
||||
- DAB-GPS
|
||||
- DAB-GPRS
|
||||
- DAB-HSDPA
|
||||
- DAB-WLAN-BT
|
||||
- DAB-ZIGBEE
|
||||
- DAB-MBUS
|
||||
- DAB-KNX-RF
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
/** @page toshiba-ac100 Toshiba AC100
|
||||
|
||||
Toshiba AC100 is a Tegra2-based netbook.
|
||||
|
||||
The netbook has
|
||||
@li NVidia Tegra 250 SoC;
|
||||
@li 512 MiB DDR2 RAM;
|
||||
@li 8 GiB internal e-MMC Flash Memory (some models have 32 GiB);
|
||||
@li RS232 serial interface (LV-TTL levels on the board!);
|
||||
@li SD card slot;
|
||||
@li 2xUSB interface (miniUSB-B and USB-A connectors);
|
||||
@li 10" LCD display (1024x600);
|
||||
@li HDMI-interface;
|
||||
@li touchpad and keyboard connected via I2C; the ENE KB926QF keyboard controller is used;
|
||||
@li web camera;
|
||||
@li some models have 3G-modem.
|
||||
|
||||
U-Boot master branch is working on AC100, but there's no support for the keyboard or the display.
|
||||
|
||||
barebox-toshiba-ac100 mini-howto:
|
||||
|
||||
1. Connect to the netbook's UART (see http://pecourt.ovh.org/wiki-tegra/doku.php?id=hardware);
|
||||
|
||||
2. Start U-Boot loader. See http://ac100.grandou.net/uboot and http://ac100.grandou.net/swarren_brain_dump for details.
|
||||
|
||||
3. If you use U-Boot with turned on display support, then switch to serial console:
|
||||
@verbatim
|
||||
Tegra2 (ac100) # setenv stdout serial
|
||||
@endverbatim
|
||||
|
||||
4. Upload barebox.bin via Ymodem and start it:
|
||||
@verbatim
|
||||
Tegra2 (ac100) # loady 0x01f00000
|
||||
Tegra2 (ac100) # go 0x01f00000
|
||||
@endverbatim
|
||||
|
||||
*/
|
||||
|
|
@ -1,30 +0,0 @@
|
|||
/**
|
||||
@page usb-a9263 Calao-systems USB-A9263
|
||||
|
||||
@section usb-a9263 The CPU card
|
||||
|
||||
http://www.calao-systems.com
|
||||
|
||||
This CPU card is based on an Atmel AT91SAM9263 CPU. The card is shipped with:
|
||||
|
||||
- 64MiB or 128MiB SDRAM (3.3V)
|
||||
- 256MiB NAND type Flash Memory (3.3V)
|
||||
- Ethernet 10/100M
|
||||
- USB Host port 2.0 (FS)
|
||||
- USB device port (FS)
|
||||
- Top expansion connector for expansion boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...)
|
||||
- Bottom expansion connector for development boards
|
||||
|
||||
@section usb-db-boards Supported daughter boards
|
||||
|
||||
Supported daughter boards are:
|
||||
- DAB-GPI2-CXX
|
||||
- DAB-GPS
|
||||
- DAB-GPRS
|
||||
- DAB-HSDPA
|
||||
- DAB-WLAN-BT
|
||||
- DAB-ZIGBEE
|
||||
- DAB-MBUS
|
||||
- DAB-KNX-RF
|
||||
|
||||
*/
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
/**
|
||||
@page usb-a9g20-lpw Calao-systems USB-A9G20-LPW
|
||||
|
||||
@section usb-a9g20-lpw The CPU card
|
||||
|
||||
http://www.calao-systems.com
|
||||
|
||||
This CPU card is based on an Atmel AT91SAM9G20 CPU. The card is shipped with:
|
||||
|
||||
- 64MiB or 128MiB SDRAM (1.8V)
|
||||
- 256MiB NAND type Flash Memory (1.8V)
|
||||
- Ethernet 10/100M
|
||||
- USB Host port 2.0 (FS)
|
||||
- USB device port (FS)
|
||||
- Micro SD socket
|
||||
- JTAG connector
|
||||
- RTC with battery backup
|
||||
- Top expansion connector for daughter boards (GPS, WIFI/BT, GPRS, 3G, ZigBee, MBUS, ...)
|
||||
- Bottom expansion connector for development boards
|
||||
|
||||
@section usb-db-boards Supported daughter boards
|
||||
|
||||
Supported daughter boards are:
|
||||
- DAB-GPI2-CXX
|
||||
- DAB-GPS
|
||||
- DAB-GPRS
|
||||
- DAB-HSDPA
|
||||
- DAB-WLAN-BT
|
||||
- DAB-ZIGBEE
|
||||
- DAB-MBUS
|
||||
- DAB-KNX-RF
|
||||
|
||||
*/
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
/** @page virt2real virt2real board
|
||||
|
||||
virt2real is a is a miniature board for creation of WiFi
|
||||
or internet controllable smart devices.
|
||||
|
||||
The board has
|
||||
@li TI DaVinchi DM365 running at 300 MHz
|
||||
@li 128 MiB DDR2 SDRAM;
|
||||
@li 256 MiB NAND Flash Memory;
|
||||
@li 2 x UART serial interfaces;
|
||||
@li 2 x Ethernet interfaces;
|
||||
@li 1 x USB interface;
|
||||
@li microSD card slot.
|
||||
|
||||
The board uses U-Boot as bootloader.
|
||||
|
||||
Barebox mini-howto:
|
||||
|
||||
1. Connect to the boards's UART0 (115200 8N1);
|
||||
Use J2.2 (GND), J2.4 (UART0_TXD), J2.6(UART0_RXD) pins.
|
||||
|
||||
2. Turn board's power on;
|
||||
|
||||
3. Wait 'Hit any key to stop autoboot' prompt and press the space key.
|
||||
|
||||
4. Upload barebox.bin via Ymodem
|
||||
@verbatim
|
||||
virt2real ># loady
|
||||
@endverbatim
|
||||
|
||||
5. Run barebox
|
||||
@verbatim
|
||||
virt2real ># go 0x82000000
|
||||
@endverbatim
|
||||
|
||||
virt2real links:
|
||||
@li http://virt2real.com/
|
||||
@li http://wiki.virt2real.ru/
|
||||
@li https://github.com/virt2real
|
||||
|
||||
*/
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
/* This document is intended to provide the developer with information
|
||||
* how to integrate a new CPU (MACH) into this part of the barebox tree
|
||||
*/
|
||||
|
||||
/** @page dev_arm_mach ARM based CPU (MACH) into the tree
|
||||
|
||||
FIXME
|
||||
|
||||
@section mach_arm_reset What's happens when the reset signal is gone
|
||||
|
||||
@note Code running immediately after reset runs at an address it is not linked
|
||||
to: "runtime address != link address". You should only use branches and
|
||||
do not refer to fixed data. This implies the use of assembler code only.
|
||||
|
||||
The ARM CPU starts at lable \<reset\> in one of the corresponding start-*.S
|
||||
files. After some basic hardware setup it can call a function
|
||||
\<arch_init_lowlevel\> if not disabled. This call is intended to give all
|
||||
developers a chance to use a standard reset vector file, but also do some
|
||||
special things required only on their specific CPU.
|
||||
|
||||
After handling some MMU related things \<board_init_lowlevel\> can be called (if
|
||||
not disabled). This is a board specific function for SDRAM setup for example.
|
||||
As its board specific, your can do whatever you need to bring your board up.
|
||||
|
||||
In the case the boot happens from NAND flash memory, further steps are required.
|
||||
Most of the known processor devices are reading the first few blocks from the
|
||||
NAND flash memory into some kind of internal SRAM. This small part must be able
|
||||
to initialize the SDRAM controller and to read the remaining rest of the
|
||||
barebox binary from the NAND flash memory prior returning from \<board_init_lowlevel\>.
|
||||
|
||||
When \<board_init_lowlevel\> returns it will be assumed there is now a working
|
||||
RAM that can be used for all further steps.
|
||||
|
||||
Next step is relocation of @a barebox itself (if not already done). It gets copied
|
||||
to RAM and the last assembler instruction is a jump into start_barebox(). This
|
||||
target address is the first C instruction in barebox. At this point of time:\n
|
||||
"runtime address == link address".
|
||||
|
||||
@section mach_arm_files List of changes
|
||||
|
||||
Lets call the new MACH new_cpu.
|
||||
|
||||
- create a new subdirectory in /arch/arm/mach-new_cpu
|
||||
- create a new subdirectory in /arch/arm/mach-new_cpu/include
|
||||
- add CPU specific definitions into /arch/arm/mach-new_cpu/include
|
||||
- add /arch/arm/mach-new_cpu/Kconfig
|
||||
- add /arch/arm/mach-new_cpu/Makfile
|
||||
- add other CPU specific code into /arch/arm/mach-new_cpu/
|
||||
- modify /arch/arm/Kconfig
|
||||
- modify /arch/arm/Makfile
|
||||
|
||||
@section mach_arm_architecures Architectures using ARM processors
|
||||
For details on specific architectures:
|
||||
|
||||
@subsection mach_arm_omap_info OMAP CPUs
|
||||
|
||||
@li @subpage dev_davinci_arch
|
||||
|
||||
@li @subpage dev_omap_arch
|
||||
|
||||
@subsection mach_arm_s3c24xx_info S3C24XX CPUs
|
||||
|
||||
@li @subpage dev_s3c24xx_arch
|
||||
|
||||
TODO add more details
|
||||
|
||||
*/
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
/** @page dev_davinci_arch TI DaVinci in barebox
|
||||
|
||||
@section davinci_boards DaVinci-based boards
|
||||
|
||||
@li @subpage virt2real
|
||||
|
||||
*/
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
/* This document is intended to provide the developer with information
|
||||
* how to integrate a new OMAP Architecture into this part of the barebox tree
|
||||
*/
|
||||
|
||||
/** @page dev_omap_arch Texas Instrument's OMAP Platforms in barebox
|
||||
|
||||
This document highlights some of the factors for supporting Texas Instrument's OMAP platforms in @a barebox.
|
||||
|
||||
@par Table of Contents
|
||||
@li @ref omap_boards
|
||||
@li @ref omap_code_arch
|
||||
@li @ref mach_omap
|
||||
@li @ref asm_arm
|
||||
@li @ref board_omap
|
||||
@li @ref omap_boot
|
||||
@li @ref board_boot
|
||||
|
||||
@section omap_boards Boards using OMAP processors
|
||||
|
||||
@li @subpage ti_SDP3430
|
||||
@li @subpage ti_beagle
|
||||
|
||||
@section omap_arch Documentation for OMAP Architectures files
|
||||
|
||||
@li @subpage arch/arm/mach-omap/omap3_generic.c
|
||||
|
||||
@section omap_code_arch How is barebox OMAP specific architecture code organized?
|
||||
|
||||
To understand the architecture of @a barebox source code for OMAP processors, we need to understand a bit on OMAP itself.
|
||||
|
||||
A typical Texas Instrument's Open Multimedia Application Processor (OMAP) solution is built around ARM core with multiple on-the-silicon peripherals. It also has a TI Digital Signal Processor(DSP) and few hardware accelerators to cater to computing intensive applications such as encoder/decoders. See http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=11988&contentId=4638 for further details.
|
||||
|
||||
Essentially, OMAP is modular with on-silicon peripherals being reused across multiple OMAP versions. @a Barebox code organization is driven by this fact.
|
||||
|
||||
Motivation for code organization is driven from:
|
||||
@li Clear distinction between architecture and board features.
|
||||
@li Code should be re-usable accross OMAP variants AND board variants.
|
||||
|
||||
Code is Organized into three main directories:
|
||||
@li arch/arm/mach-omap -contains files for ALL peripherals which are present on board with very few exceptions. We will come to these exceptions in later sections.
|
||||
@li include/asm-arm/arch-omap - contains files for ALL OMAP on-silicon peripherals. No Board specific files here please!
|
||||
@li arch/arm/boards/omap - contains files for ALL boards using OMAP processors.
|
||||
|
||||
@section mach_omap arch/arm/mach-omap directory guidelines
|
||||
It is rather simple: All common peripherals should be isolated as separate driver libraries as far as possible. Exceptions such as clock configuration code may be isolated by the following naming convention: omapX_function_name.[cS], where X belongs to the OMAP variant. The exception is for devices who have existing code locations - potentially drivers/i2c/busses and the like.
|
||||
|
||||
All basic devices you'd like to register should be put here with postcore_initcall from architecture files
|
||||
|
||||
@section asm_arm include/asm-arm/arch-omap directory guidelines
|
||||
All OMAP common headers are located here. Where we have to incorporate a OMAP variant specific header, add a omapX_function_name.h.
|
||||
@warning Do not add board specific header files/information here. Put them in mach-omap.
|
||||
|
||||
include/asm-arm/arch-omap/silicon.h contains includes for omapX-silicon.h which defines the base addresses for the peripherals on that platform. the usual convention is to use
|
||||
@code
|
||||
#define OMAP_SOMETHING_BASE
|
||||
@endcode
|
||||
to allow re-use.
|
||||
|
||||
@section board_omap arch/arm/boards/omap directory guidelines
|
||||
All Board specific files go here. In u-boot, we always had to use common config file which is shared by other drivers to get serial, ethernet baseaddress etc.. we can easily use the device_d structure to handle it with @a barebox. This is more like programming for Linux kernel - it is pretty easy.
|
||||
Each specific board file has board-XYZ.c and potentially and equivalent h file.
|
||||
|
||||
We'd potentially use device_initcall and console_initcalls as required.
|
||||
|
||||
@section omap_boot The OMAP boot path
|
||||
The normal flow is to look for arch_init_lowlevel in the required code. This would be the first function to be called after the ARM common code boots up(arch/arm/cpu/start-arm.S), the job of boot code on OMAP platform would be to preventing watchdog timer from kicking in and spoiling all the fun, setup OMAP clocks to the high performance mode, do other architecture specific initializations. There could be some additional stuff we may need to do based on the specific OMAP we support including setting up a usable interrupt vector table etc - some parts of the code may be desired to be in C code (to let normal humans understand without being an asm junkie), in such a case, @a barebox's stack setup is not ready yet, and we may need to setup a temporary SRAM based stack prior to execution. Some things to keep in mind while handling booting code, we might be executing in eXecute In Place (XIP) mode and that only an SRAM stack is setup. Using global variables or using constructs that create function jump tables is doomed to fail as the required area might not be writable or may not be even initialized. So code in this area tends to use lots of if conditions and local variables. Having C code doing the fun part is easy to maintain, so it is advisable to push as much as possible to C functions where possible.
|
||||
|
||||
The responsibility of arch_init_lowlevel and related calls is to setup OMAP. No board specific initializations are to be done here.
|
||||
|
||||
Once this is past, the code returns back to arm common code (cpu/start-arm.S). Here Instruction and Data caches are disabled. The execution proceeds to normal board initialization.
|
||||
|
||||
@section board_boot The board boot path
|
||||
Every Board in OMAP platform can potentially define a board_init and enable defconfig in arch/arm/configs directory. The responsibility here is to setup OMAP for board configurations - this includes SDRAM configuration and pin muxing configuration.
|
||||
|
||||
Once this is complete, @a barebox boot process proceeds by calling init functions and finally entering shell prompt
|
||||
|
||||
board-XYZ file may potentially register every device it is interested in. You can check out how the code is organized in other board directories also, esentially, the method is as simple as:
|
||||
@code
|
||||
static struct device_d my_little_device = {
|
||||
.name = "driver_name",
|
||||
.id = "some_unique_id",
|
||||
.platform_data = &any_driver_specific_data,
|
||||
.type = Type_of_device,
|
||||
};
|
||||
static int my_board_devices_init(void) {
|
||||
/* Do Blah Blah Blah */
|
||||
return platform_device_register(&my_little_device);
|
||||
}
|
||||
|
||||
device_initcall(my_board_devices_init);
|
||||
@endcode
|
||||
|
||||
You may probably be interested in calling console_initcall to get a console.. Modify arch/arm/boards/omap/Kconfig to add your OMAP board, create a defconfig, do a make C=2 to enable sparse warnings, you can potentially have a binary done in no time! if you remember to put doxygen comments in your code, you can do a make docs and get the documentation done too..
|
||||
|
||||
|
||||
*/
|
||||
|
|
@ -31,14 +31,6 @@ s3c24x0_disable_wd:
|
|||
str r1, [r0]
|
||||
mov pc, lr
|
||||
|
||||
/**
|
||||
@page dev_s3c24xx_wd_handling Watchdog handling
|
||||
|
||||
The watchdog must be disabled very early, because if it resets the system
|
||||
it is still active and will continue to reset the system. So, call this
|
||||
routine very early in your board_init_lowlevel routine.
|
||||
*/
|
||||
|
||||
/*
|
||||
* S3C2410 PLL configuration
|
||||
* -------------------------
|
||||
|
|
|
|||
|
|
@ -80,60 +80,3 @@ void s3c24xx_disable_second_sdram_bank(void)
|
|||
writel(readl(S3C_BANKCON7) & ~(0x3 << 15), S3C_BANKCON7);
|
||||
writel(readl(S3C_MISCCR) | (1 << 18), S3C_MISCCR); /* disable its clock */
|
||||
}
|
||||
|
||||
/**
|
||||
|
||||
@page dev_s3c24xx_arch Samsung's S3C24xx Platforms in barebox
|
||||
|
||||
@section s3c24xx_boards Boards using S3C24xx Processors
|
||||
|
||||
@li @subpage arch/arm/boards/a9m2410/a9m2410.c
|
||||
@li @subpage arch/arm/boards/a9m2440/a9m2440.c
|
||||
|
||||
@section s3c24xx_arch Documentation for S3C24xx Architectures Files
|
||||
|
||||
@li @subpage arch/arm/mach-s3c24xx/generic.c
|
||||
|
||||
@section s3c24xx_mem_map SDRAM Memory Map
|
||||
|
||||
SDRAM starts at address 0x3000.0000 up to the available amount of connected
|
||||
SDRAM memory. Physically this CPU can handle up to 256MiB (two areas with
|
||||
up to 128MiB each).
|
||||
|
||||
@subsection s3c24xx_mem_generic_map Generic Map
|
||||
- 0x0000.0000 Start of the internal SRAM when booting from NAND flash memory or CS signal to a NOR flash memory.
|
||||
- 0x0800.0000 Start of I/O space.
|
||||
- 0x3000.0000 Start of SDRAM area.
|
||||
- 0x3000.0100 Start of the TAG list area.
|
||||
- 0x3000.8000 Start of the linux kernel (physical address).
|
||||
- 0x4000.0000 Start of internal SRAM, when booting from NOR flash memory
|
||||
- 0x4800.0000 Start of the internal I/O area
|
||||
|
||||
@section s3c24xx_asm_arm include/asm-arm/arch-s3c24xx directory guidelines
|
||||
All S3C24xx common headers are located here.
|
||||
|
||||
@note Do not add board specific header files/information here.
|
||||
*/
|
||||
|
||||
/** @page dev_s3c24xx_mach Samsung's S3C24xx based platforms
|
||||
|
||||
@par barebox Map
|
||||
|
||||
The location of the @a barebox itself depends on the available amount of
|
||||
installed SDRAM memory:
|
||||
|
||||
- 0x30fc.0000 Start of @a barebox when 16MiB SDRAM is available
|
||||
- 0x31fc.0000 Start of @a barebox when 32MiB SDRAM is available
|
||||
- 0x33fc.0000 Start of @a barebox when 64MiB SDRAM is available
|
||||
|
||||
Adjust the @p CONFIG_TEXT_BASE/CONFIG_ARCH_TEXT_BASE symbol in accordance to
|
||||
the available memory.
|
||||
|
||||
@note The RAM based filesystem and the stack resides always below the
|
||||
@a barebox start address.
|
||||
|
||||
@li @subpage dev_s3c24xx_wd_handling
|
||||
@li @subpage dev_s3c24xx_pll_handling
|
||||
@li @subpage dev_s3c24xx_sdram_handling
|
||||
@li @subpage dev_s3c24xx_nandboot_handling
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -1,10 +0,0 @@
|
|||
/** @page ipe337 ipe337
|
||||
|
||||
This CPU card is based on an Analog Device Blackfin CPU. The card is shipped
|
||||
with:
|
||||
|
||||
- 32MiB NOR type Flash Memory
|
||||
- 128MiB synchronous dynamic RAM
|
||||
- SMSC9xxx network controller
|
||||
|
||||
*/
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
/* This document is intended to provide the developer with information
|
||||
* how to integrate a new CPU (MACH) into this part of the barebox tree
|
||||
*/
|
||||
|
||||
/** @page dev_bf_mach Blackfin based CPU (MACH) into the tree
|
||||
|
||||
FIXME
|
||||
|
||||
*/
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
/** @page dlink_dir_320 D-Link DIR-320 wireless router
|
||||
|
||||
The router has
|
||||
@li BCM5354 SoC;
|
||||
@li 32 MiB SDRAM;
|
||||
@li 4 MiB NOR type Flash Memory;
|
||||
@li RS232 serial interface (LV-TTL levels on board!);
|
||||
@li 1xUSB interface;
|
||||
@li 4 + 1 ethernet interfaces;
|
||||
@li 802.11b/g (WiFi) interface;
|
||||
@li JTAG interface;
|
||||
@li 5 LEDs;
|
||||
@li 2 buttons.
|
||||
|
||||
The router uses CFE as firmware.
|
||||
|
||||
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.:
|
||||
@verbatim
|
||||
CFE> ifconfig eth0 -addr=192.168.0.99
|
||||
CFE> boot -tftp -addr=a0800000 -raw 192.168.0.1:barebox.bin
|
||||
@endverbatim
|
||||
|
||||
DIR-320 links:
|
||||
@li http://www.dlink.com.au/products/?pid=768
|
||||
@li http://wiki.openwrt.org/toh/d-link/dir-320
|
||||
|
||||
CFE links:
|
||||
@li http://www.broadcom.com/support/communications_processors/downloads.php#cfe
|
||||
@li http://www.linux-mips.org/wiki/CFE
|
||||
|
||||
*/
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
/** @page loongson_ls1b Loongson LS1B demo board
|
||||
|
||||
The LS1B is a development board made by Loongson Technology Corp. Ltd.
|
||||
|
||||
The board has
|
||||
@li Loongson LS1B SoC 250 MHz;
|
||||
@li 64 MiB SDRAM;
|
||||
@li 512 KiB SPI boot ROM;
|
||||
@li 128M x 8 Bit NAND Flash Memory;
|
||||
@li 2 x RS232 serial interfaces (DB9 connectors);
|
||||
@li 2 x Ethernet interfaces;
|
||||
@li 4 x USB interfaces;
|
||||
@li microSD card slot;
|
||||
@li LCD display (480x272);
|
||||
@li audio controller;
|
||||
@li beeper;
|
||||
@li buttons;
|
||||
@li EJTAG 10-pin connector.
|
||||
|
||||
The board uses PMON2000 as bootloader.
|
||||
|
||||
Barebox mini-howto:
|
||||
|
||||
1. Connect to the boards's UART2;
|
||||
|
||||
2. Turn board's power on;
|
||||
|
||||
3. Wait 'Press <Enter> to execute loading image' prompt and press the space key.
|
||||
|
||||
4. Upload zbarebox.bin via Ymodem
|
||||
@verbatim
|
||||
PMON> ymodem base=0xa0200000
|
||||
@endverbatim
|
||||
|
||||
5. Run barebox
|
||||
@verbatim
|
||||
PMON> g -e 0xa0200000
|
||||
@endverbatim
|
||||
|
||||
Loongson links:
|
||||
@li http://en.wikipedia.org/wiki/Loongson
|
||||
@li http://www.linux-mips.org/wiki/Loongson
|
||||
@li https://github.com/loongson-gz
|
||||
@li http://www.linux-mips.org/wiki/PMON_2000
|
||||
@li http://www.opsycon.se/PMON2000/Main
|
||||
|
||||
*/
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
/** @page qemu_malta QEmu malta emulated board
|
||||
|
||||
Specific to this emulated board is, it does not require any setup code to bring the SDRAM and RS232 up.
|
||||
|
||||
Emulator run string:
|
||||
@verbatim
|
||||
qemu-system-mips -nodefaults -M malta -m 256 -nographic -serial stdio -monitor null -bios barebox-flash-image
|
||||
@endverbatim
|
||||
|
||||
Also you can use GXemul:
|
||||
@verbatim
|
||||
gxemul -Q -x -e maltabe -M 256 0xbfc00000:barebox-flash-image
|
||||
@endverbatim
|
||||
|
||||
Links:
|
||||
@li http://www.linux-mips.org/wiki/Mips_Malta
|
||||
@li http://www.qemu.org/
|
||||
@li http://gxemul.sourceforge.net/
|
||||
|
||||
*/
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
/** @page ritmix-rzx50 Ritmix RZX-50 game console
|
||||
|
||||
Ritmix RZX-50 is a portable game console for the Russian market.
|
||||
|
||||
The portable game console has
|
||||
@li Ingenic JZ4755 SoC;
|
||||
@li 64 MiB SDRAM;
|
||||
@li 4 GiB microSDHC card / 4 GiB NAND type Flash Memory;
|
||||
@li RS232 serial interface (LV-TTL levels on the board!);
|
||||
@li LCD display (480x272);
|
||||
@li Video out interface;
|
||||
@li 1xUSB interface;
|
||||
@li buttons.
|
||||
|
||||
The game console uses U-Boot 1.1.6 as bootloader.
|
||||
|
||||
barebox-rzx50 mini-howto:
|
||||
|
||||
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. Upload barebox.bin via Zmodem
|
||||
@verbatim
|
||||
# cd /tmp
|
||||
# rz
|
||||
@endverbatim
|
||||
|
||||
5. Write barebox to onboard flash
|
||||
@verbatim
|
||||
# dd if=barebox.bin of=/dev/mmcblk0 seek=1048576 bs=1 count=262144
|
||||
@endverbatim
|
||||
|
||||
6. Reboot RZX-50, next in U-Boot console start barebox:
|
||||
@verbatim
|
||||
CETUS # msc read 0xa0800000 0x100000 0x40000; g a0800000
|
||||
@endverbatim
|
||||
|
||||
Ritmix RZX-50 links:
|
||||
@li http://www.ritmixrussia.ru/products/252/entertainment/game/rzx-50
|
||||
@li ftp://ftp.ingenic.cn/2soc/4755/JZ4755_ds.pdf
|
||||
@li ftp://ftp.ingenic.cn/3sw/01linux/01loader/u-boot/u-boot-1.1.6-jz-20110719-r1728-add-jz4770.patch.bz2
|
||||
|
||||
*/
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
/** @page tplink-mr3020 TP-LINK MR3020 wireless router
|
||||
|
||||
The router has
|
||||
@li Atheros ar9331 SoC;
|
||||
@li 32 MiB SDRAM;
|
||||
@li 4 MiB NOR type SPI Flash Memory;
|
||||
@li RS232 serial interface (LV-TTL levels on board!);
|
||||
@li 1 USB interface;
|
||||
@li 1 Ethernet interfaces;
|
||||
@li 802.11b/g/n (WiFi) interface;
|
||||
@li LEDs & buttons.
|
||||
|
||||
The router uses U-Boot 1.1.4 as firmware.
|
||||
|
||||
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.:
|
||||
|
||||
@verbatim
|
||||
$ 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
|
||||
@endverbatim
|
||||
|
||||
To convert your barebox.bin to U-Boot-loadable image (6F01A8C0.img)
|
||||
use this command sequence:
|
||||
|
||||
@verbatim
|
||||
$ 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
|
||||
@endverbatim
|
||||
|
||||
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.:
|
||||
@verbatim
|
||||
hornet> set ipaddr 192.168.0.2
|
||||
hornet> set serverip 192.168.0.1
|
||||
hornet> tftpboot 0x81000000 6F01A8C0.img
|
||||
hornet> bootm 0x81000000
|
||||
@endverbatim
|
||||
|
||||
TP-LINK MR3020 links:
|
||||
@li http://www.tp-link.com/en/products/details/?model=TL-MR3020
|
||||
@li http://wiki.openwrt.org/toh/tp-link/tl-mr3020
|
||||
@li https://wikidevi.com/wiki/TP-LINK_TL-MR3020
|
||||
|
||||
See also:
|
||||
@li http://www.eeboard.com/wp-content/uploads/downloads/2013/08/AR9331.pdf
|
||||
@li http://squonk42.github.io/TL-WR703N/
|
||||
|
||||
*/
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
/** @page dev_bcm47xx_mach BCM47xx in barebox
|
||||
|
||||
@section bcm47xx_boards BCM47xx-based boards
|
||||
|
||||
@li @subpage dlink_dir_320
|
||||
|
||||
*/
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
/** @page dev_loongson_mach Loongson in barebox
|
||||
|
||||
@section loongson_boards Loongson-based boards
|
||||
|
||||
@li @subpage loongson_ls1b
|
||||
|
||||
*/
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
/** @page dev_malta_mach MIPS Malta in barebox
|
||||
|
||||
@section malta_boards MIPS Malta boards
|
||||
|
||||
@li @subpage qemu_malta
|
||||
|
||||
*/
|
||||
|
|
@ -1,69 +0,0 @@
|
|||
/* This document is intended to provide the developer with information
|
||||
* how to integrate a new CPU (MACH) into this part of the barebox tree
|
||||
*/
|
||||
|
||||
/** @page dev_mips_mach MIPS based CPU (MACH) into the tree
|
||||
|
||||
@section mach_mips_reset What's happens when the reset signal is gone
|
||||
|
||||
Barebox normally must be linked to RAM region, cached region KSEG0 is preferred.
|
||||
This make possible to run fast (because cache used) and skip MMU support.
|
||||
|
||||
After reset MIPS CPU starting to fetch instructions from 0xBFC00000.
|
||||
|
||||
@note Code running immediately after reset runs at an address it is not linked
|
||||
to: "runtime address != link address". You should only use branches and
|
||||
do not refer to fixed data. This implies the use of assembler code only.
|
||||
After MIPS CPU reset cache and MMU are in random state. They are unusable.
|
||||
|
||||
barebox MIPS initialisation sequence:
|
||||
|
||||
* set the CP0 STATUS register to some known and sensible state.
|
||||
Now you can load and store reliably in uncached space.
|
||||
|
||||
* call a function \<mach_init_lowlevel\> (if not disabled).
|
||||
do some special things required only on specific CPU
|
||||
(e. g. init RAM controller, disable watchdog)
|
||||
|
||||
* call a function \<board_init_lowlevel\> (if not disable).
|
||||
do some special things required only on specific board
|
||||
(e. g. setup GPIO to required state).
|
||||
|
||||
** It is desirable to have some debug code to make some contact
|
||||
with the outside world from assembler code
|
||||
(e.g. debug_ll-like functions to write to rs232 console).
|
||||
|
||||
* check integrity of barebox RAM execute location;
|
||||
* copy barebox to RAM execute location;
|
||||
|
||||
* configure cache;
|
||||
|
||||
* setup stack;
|
||||
|
||||
** after this point you can call a standard C routine.
|
||||
|
||||
* setup exception vectors in RAM;
|
||||
* setup CP0 STATUS to switch exception vector address to RAM;
|
||||
|
||||
* call start_barebox()
|
||||
|
||||
Further reading:
|
||||
* Dominic Sweetman, See MIPS Run, Morgan Kaufmann, 2nd edition, 2006
|
||||
ISBN-13: 978-0120884216
|
||||
|
||||
@subsection mach_mips_malta_info Malta boards
|
||||
|
||||
@li @subpage dev_malta_mach
|
||||
|
||||
@subsection mach_bcm47xx_info BCM47xx-based boards
|
||||
|
||||
@li @subpage dev_bcm47xx_mach
|
||||
|
||||
@subsection mach_loongson_info Loongson-based boards
|
||||
|
||||
@li @subpage dev_loongson_mach
|
||||
|
||||
@subsection mach_xburst_info XBurst-based boards
|
||||
|
||||
@li @subpage dev_xburst_mach
|
||||
*/
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
/** @page dev_xburst_mach XBurst in barebox
|
||||
|
||||
@section xburst_boards XBurst-based boards
|
||||
|
||||
@li @subpage ritmix-rzx50
|
||||
|
||||
*/
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
/** @page pcm030 Phytec's phyCORE-MPC5200B-tiny
|
||||
|
||||
This CPU card is based on a Freescale MPC5200B CPU. The card is shipped with:
|
||||
|
||||
- up to 16MiB NOR type Flash Memory
|
||||
- 64MiB synchronous dynamic RAM
|
||||
|
||||
*/
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
/* This document is intended to provide the developer with information
|
||||
* how to integrate a new CPU (MACH) into this part of the barebox tree
|
||||
*/
|
||||
|
||||
/** @page dev_ppc_mach PowerPC based CPU into the tree
|
||||
|
||||
FIXME
|
||||
|
||||
*/
|
||||
|
|
@ -18,10 +18,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Common wrapper functions between barebox and the host
|
||||
*/
|
||||
/*
|
||||
* These are host includes. Never include any barebox header
|
||||
* files here...
|
||||
|
|
@ -421,54 +417,3 @@ static void print_usage(const char *prgname)
|
|||
prgname
|
||||
);
|
||||
}
|
||||
|
||||
/**
|
||||
* @page barebox_simul barebox Simulator
|
||||
*
|
||||
* barebox can be run as a simulator on your host to check and debug new non
|
||||
* hardware related features.
|
||||
*
|
||||
* @section simu_build How to build barebox for simulation
|
||||
*
|
||||
* @section simu_run How to run barebox simulator
|
||||
*
|
||||
* $ barebox [\<OPTIONS\>]
|
||||
*
|
||||
* Options can be:
|
||||
*
|
||||
* -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
|
||||
*
|
||||
* @section simu_dbg How to debug barebox simulator
|
||||
*
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -14,11 +14,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Generic PC support to let barebox acting as a boot loader
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <types.h>
|
||||
#include <driver.h>
|
||||
|
|
@ -34,32 +29,3 @@ static int devices_init(void)
|
|||
return 0;
|
||||
}
|
||||
device_initcall(devices_init);
|
||||
|
||||
/** @page generic_pc Generic PC based bootloader
|
||||
|
||||
This platform acts as a generic PC based bootloader. It depends on at least
|
||||
one boot media that is connected locally (no network boot) and can be
|
||||
handled by the regular BIOS (any kind of hard disks for example).
|
||||
|
||||
The created @a barebox image can be used to boot a standard x86 bzImage
|
||||
Linux kernel.
|
||||
|
||||
Refer section @ref x86_bootloader_preparations how to do so.
|
||||
|
||||
How to get the binary image:
|
||||
|
||||
Using the default configuration:
|
||||
|
||||
@code
|
||||
make ARCH=x86 generic_defconfig
|
||||
@endcode
|
||||
|
||||
Build the binary image:
|
||||
|
||||
@code
|
||||
make ARCH=x86 CROSS_COMPILE=x86compiler
|
||||
@endcode
|
||||
|
||||
@note replace the 'x86compiler' with your x86 (cross) compiler.
|
||||
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -13,8 +13,6 @@
|
|||
* touching registers they shouldn't be.
|
||||
*/
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
.file "bioscall.S"
|
||||
.code16
|
||||
.section .boot.text.intcall, "ax"
|
||||
|
|
@ -95,5 +93,3 @@ die:
|
|||
hlt
|
||||
jmp die
|
||||
.size die, .-die
|
||||
|
||||
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
|
||||
|
|
|
|||
|
|
@ -26,7 +26,6 @@
|
|||
* space below 0x10000
|
||||
*/
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
/*
|
||||
* int bios_disk_rw_int13_extensions (int ah, int drive, void *dap)
|
||||
*
|
||||
|
|
@ -69,5 +68,3 @@ bios_disk_rw_int13_extensions:
|
|||
popl %ebp
|
||||
|
||||
ret
|
||||
|
||||
#endif
|
||||
|
|
|
|||
|
|
@ -30,7 +30,6 @@
|
|||
* void bios_start_linux(unsigned segment)
|
||||
*
|
||||
*/
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
.section .boot.text.bios_start_linux, "ax"
|
||||
.code32
|
||||
|
|
@ -67,5 +66,3 @@ setup_seg:
|
|||
.word 0
|
||||
|
||||
.code32
|
||||
|
||||
#endif
|
||||
|
|
|
|||
|
|
@ -1,128 +0,0 @@
|
|||
/* This document is intended to provide the developer with information
|
||||
* how to integrate a new CPU (MACH) into this part of the barebox tree
|
||||
*/
|
||||
|
||||
/** @page dev_x86_mach barebox on x86 at runtime
|
||||
|
||||
@section mach_x86_memory_layout barebox's memory layout (BIOS based)
|
||||
|
||||
@a barebox uses the following memory layout at runtime when it still depends
|
||||
on some kind of BIOS function:
|
||||
|
||||
@verbatim
|
||||
Addresses
|
||||
------------------------
|
||||
|
||||
seg:off flat
|
||||
|
||||
xxxx:xxxx 0x01xxxxxx end of barebox's malloc area
|
||||
. .
|
||||
xxxx:xxxx 0x01000000 start of barebox's malloc area
|
||||
. .
|
||||
. . (used while loading a Linux kernel of type 'bzImage')
|
||||
. .
|
||||
xxxx:xxxx 0x00100000 start of extended memory and malloc area
|
||||
. .
|
||||
. . (the big hole)
|
||||
. .
|
||||
9000:ffff 0x0009ffff end of expected real mode memory
|
||||
. .
|
||||
. . (used while loading a Linux kernel of type 'bzImage')
|
||||
. .
|
||||
9000:0000 0x00090000 end of used lower real mode memory
|
||||
. .
|
||||
. .
|
||||
. . Flat mode stack (about 32 kiB)
|
||||
. . bss
|
||||
. . Data
|
||||
. . Text
|
||||
0000:7e00 0x00007e00 Real and flat mode barebox code
|
||||
0000:7c00 0x00007c00 MBR initial boot loader code
|
||||
0000:7a00 0x00007a00 location of the indirect sector (while booting only)
|
||||
below: real mode stack
|
||||
@endverbatim
|
||||
|
||||
@note The start address of 0x0000:7c000 is a fixed one, defined by the BIOS.
|
||||
So, for a BIOS based @a barebox this address can't be changed.
|
||||
|
||||
While the @a barebox code is runnung in flat mode, all interrupts are disabled.
|
||||
But in the CPU only. All other interrupt settings are still valid. This is
|
||||
required to be able to call real mode code from inside @a barebox flat mode
|
||||
code. Thats why not the PIC is touched nor the IDT.
|
||||
|
||||
@todo Add some notes about drive numbers used by the BIOS. They may change
|
||||
if one change orders in the BIOS setup. Drive orders and numbers may be
|
||||
different at BIOS runtime and Linux runtime! But these numbers are required
|
||||
at BIOS runtime for booting and the persistant environment storage.
|
||||
|
||||
@attention Currently there is a 4 GiB limit for the disk sizes!
|
||||
|
||||
@section mach_x86_image_layout barebox's image layout
|
||||
|
||||
@a barebox's binary image layout
|
||||
|
||||
@verbatim
|
||||
Offset Content
|
||||
|
||||
0x?????
|
||||
. 32 bit barebox code
|
||||
.
|
||||
. 16 bit bootstrap code, BIOS calling code
|
||||
0x00400
|
||||
0x003ff
|
||||
. indirect sector
|
||||
0x00200
|
||||
0x001ff
|
||||
. MBR
|
||||
0x00000
|
||||
@endverbatim
|
||||
|
||||
The "indirect sector" is a free area in the image where the sector information
|
||||
gets stored when this image will be written to a boot media. This information
|
||||
is required to load all parts of the image from the boot media at runtime.
|
||||
|
||||
The image gets installed in two ways onto the boot media, depending on the
|
||||
need for a persistant storage.
|
||||
|
||||
@subsection mach_x86_drive_layout_wops barebox's boot media layout without persistant storage
|
||||
|
||||
In this case @a barebox's persistant storage is anywhere:
|
||||
|
||||
@verbatim
|
||||
Sector Content
|
||||
---------------------------
|
||||
X start of first partition
|
||||
.
|
||||
? end of the binary image
|
||||
. 32 bit barebox code
|
||||
2 16 bit bootstrap code, BIOS calling code
|
||||
1 indirect sector
|
||||
0 MBR, Partition table, boot code
|
||||
@endverbatim
|
||||
|
||||
@subsection mach_x86_drive_layout_wps barebox's boot media layout with persistant storage
|
||||
|
||||
@a barebox's persistant storage is part of the boot media (more
|
||||
space required in front of the first partition) and interferes with the
|
||||
boot loader image itself:
|
||||
|
||||
@verbatim
|
||||
Sector Content
|
||||
---------------------------
|
||||
X start of first partition
|
||||
.
|
||||
n+? end of the binary image
|
||||
. 32 bit barebox code
|
||||
n+2 16 bit bootstrap code, BIOS calling code
|
||||
n+1 indirect sector
|
||||
n end of persistant environment storage
|
||||
.
|
||||
1 start of persistant environment storage
|
||||
0 MBR, Partition table, boot code
|
||||
@endverbatim
|
||||
|
||||
The information where the persistant storage is located is also stored into
|
||||
the MBR at specific locations by @p setupmbr. The @a barebox runtime will use
|
||||
it to load and store all environment relevant data.
|
||||
|
||||
*/
|
||||
|
|
@ -194,20 +194,3 @@ static int binfmt_uimage_init(void)
|
|||
return binfmt_register(&binfmt_uimage_hook);
|
||||
}
|
||||
fs_initcall(binfmt_uimage_init);
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Boot support for Linux
|
||||
*/
|
||||
|
||||
/**
|
||||
* @page boot_preparation Preparing for Boot
|
||||
*
|
||||
* This chapter describes what's to be done to forward the control from
|
||||
* barebox to Linux. This part describes the generic part, below you can find
|
||||
* the architecture specific part.
|
||||
*
|
||||
* - @subpage arm_boot_preparation
|
||||
* - @subpage ppc_boot_preparation
|
||||
* - @subpage x86_boot_preparation
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -17,10 +17,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief cp: copy file command
|
||||
*/
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <xfuncs.h>
|
||||
|
|
@ -95,15 +91,6 @@ BAREBOX_CMD_HELP_TEXT("Options:")
|
|||
BAREBOX_CMD_HELP_OPT ("-v", "verbose")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page cp_command
|
||||
This command operates on files.
|
||||
|
||||
If you want to copy between memory blocks, use 'memcpy'.
|
||||
|
||||
\todo What does this mean? Add examples.
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(cp)
|
||||
.cmd = do_cp,
|
||||
BAREBOX_CMD_DESC("copy files")
|
||||
|
|
@ -111,4 +98,3 @@ BAREBOX_CMD_START(cp)
|
|||
BAREBOX_CMD_GROUP(CMD_GRP_FILE)
|
||||
BAREBOX_CMD_HELP(cmd_cp_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
|
|
|
|||
|
|
@ -118,34 +118,6 @@ static int do_devinfo(int argc, char *argv[])
|
|||
return 0;
|
||||
}
|
||||
|
||||
|
||||
/**
|
||||
* @page devinfo_command
|
||||
|
||||
If called without arguments, devinfo shows a summary of the known
|
||||
devices and drivers.
|
||||
|
||||
If called with a device path being the argument, devinfo shows more
|
||||
default information about this device and its parameters.
|
||||
|
||||
Example from an MPC5200 based system:
|
||||
|
||||
@verbatim
|
||||
barebox:/ devinfo /dev/eth0
|
||||
base : 0x1002b000
|
||||
size : 0x00000000
|
||||
driver: fec_mpc5xxx
|
||||
|
||||
no info available for eth0
|
||||
Parameters:
|
||||
ipaddr = 192.168.23.197
|
||||
ethaddr = 80:81:82:83:84:86
|
||||
gateway = 192.168.23.1
|
||||
netmask = 255.255.255.0
|
||||
serverip = 192.168.23.2
|
||||
@endverbatim
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_HELP_START(devinfo)
|
||||
BAREBOX_CMD_HELP_TEXT("If called without arguments, devinfo shows a summary of the known")
|
||||
BAREBOX_CMD_HELP_TEXT("devices.")
|
||||
|
|
|
|||
|
|
@ -186,16 +186,6 @@ BAREBOX_CMD_HELP_OPT ("-V ID", "vendor id")
|
|||
BAREBOX_CMD_HELP_OPT ("-P ID", "product id")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page dfu_command
|
||||
\<description> has the following form:
|
||||
device1(name1)[sr],device2(name2)[sr]
|
||||
's' means 'safe mode' (download the complete image before flashing) and
|
||||
'r' that readback of the firmware is allowed.
|
||||
|
||||
\todo Add example, how to use dfu from a Linux or Windows host.
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(dfu)
|
||||
.cmd = do_dfu,
|
||||
BAREBOX_CMD_DESC("device firmware update")
|
||||
|
|
|
|||
|
|
@ -113,13 +113,6 @@ BAREBOX_CMD_HELP_OPT ("-a FILE", "append to FILE instead of using stdout")
|
|||
BAREBOX_CMD_HELP_OPT ("-o FILE", "overwrite FILE instead of using stdout")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page echo_command
|
||||
|
||||
\todo Add documentation for -a, -o and -e.
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(echo)
|
||||
.cmd = do_echo,
|
||||
BAREBOX_CMD_DESC("echo args to console")
|
||||
|
|
@ -127,4 +120,3 @@ BAREBOX_CMD_START(echo)
|
|||
BAREBOX_CMD_GROUP(CMD_GRP_CONSOLE)
|
||||
BAREBOX_CMD_HELP(cmd_echo_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
|
|
|
|||
|
|
@ -15,11 +15,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief A tiny editor implementation
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <malloc.h>
|
||||
|
|
@ -550,16 +545,6 @@ BAREBOX_CMD_HELP_START(edit)
|
|||
BAREBOX_CMD_HELP_TEXT("Use cursor keys, Ctrl-C to exit and Ctrl-D to exit-with-save.")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page edit_command
|
||||
|
||||
<p> Barebox contains a small text editor which can be used to edit
|
||||
config files in /env. You can move the cursor around with the arrow keys
|
||||
and type characters. </p>
|
||||
|
||||
If called as sedit, the editor uses ansi codes to scroll the screen.
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(edit)
|
||||
.cmd = do_edit,
|
||||
.aliases = edit_aliases,
|
||||
|
|
@ -568,4 +553,3 @@ BAREBOX_CMD_START(edit)
|
|||
BAREBOX_CMD_GROUP(CMD_GRP_CONSOLE)
|
||||
BAREBOX_CMD_HELP(cmd_edit_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
|
|
|
|||
|
|
@ -19,11 +19,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Flash memory support: erase, protect, unprotect
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <errno.h>
|
||||
|
|
@ -92,20 +87,6 @@ BAREBOX_CMD_START(erase)
|
|||
BAREBOX_CMD_HELP(cmd_erase_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
/**
|
||||
* @page erase_command
|
||||
|
||||
<p> Erase the flash memory handled by this device. Which area will be
|
||||
erased depends on the device: If the device represents the whole flash
|
||||
memory, the whole memory will be erased. If the device represents a
|
||||
partition on a main flash memory, only this partition part will be
|
||||
erased. </p>
|
||||
|
||||
Refer to \ref addpart_command, \ref delpart_command and \ref
|
||||
devinfo_command for partition handling.
|
||||
|
||||
*/
|
||||
|
||||
static int do_protect(int argc, char *argv[])
|
||||
{
|
||||
int fd;
|
||||
|
|
@ -173,23 +154,6 @@ BAREBOX_CMD_START(protect)
|
|||
BAREBOX_CMD_HELP(cmd_protect_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
/**
|
||||
* @page protect_command
|
||||
|
||||
|
||||
If the device represents the whole
|
||||
flash memory the whole memory will be protected. If the device
|
||||
represents a partition on a main flash memory, only this partition part
|
||||
will be protected.
|
||||
|
||||
Refer addpart_command, delpart_command and devinfo_command for partition
|
||||
handling.
|
||||
|
||||
\todo Rework this documentation, what is an 'area'? Explain more about
|
||||
flashes here.
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_HELP_START(unprotect)
|
||||
BAREBOX_CMD_HELP_TEXT("Unprotect the flash memory behind the device. It depends on the device")
|
||||
BAREBOX_CMD_HELP_TEXT("given, what area will be unprotected. If the device represents the whole")
|
||||
|
|
@ -205,19 +169,3 @@ BAREBOX_CMD_START(unprotect)
|
|||
BAREBOX_CMD_GROUP(CMD_GRP_HWMANIP)
|
||||
BAREBOX_CMD_HELP(cmd_unprotect_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
/**
|
||||
* @page unprotect_command
|
||||
|
||||
It depends on the device given,
|
||||
what area will be unprotected. If the device represents the whole flash memory
|
||||
the whole memory will be unprotected. If the device represents a partition
|
||||
on a main flash memory, only this partition part will be unprotected.
|
||||
|
||||
Refer addpart_command, delpart_command and devinfo_command for partition
|
||||
handling.
|
||||
|
||||
\todo Rework this documentation, what does it mean?
|
||||
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -107,65 +107,3 @@ BAREBOX_CMD_START(gpio_direction_output)
|
|||
BAREBOX_CMD_OPTS("GPIO VALUE")
|
||||
BAREBOX_CMD_GROUP(CMD_GRP_HWMANIP)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
/**
|
||||
* @page gpio_for_users GPIO Handling
|
||||
|
||||
@section regular_gpio General usage information
|
||||
|
||||
These commands are available if the symbol @b CONFIG_GENERIC_GPIO and @b
|
||||
CONFIG_CMD_GPIO are enabled in Kconfig.
|
||||
|
||||
@note All gpio related commands take a number to identify the pad. This
|
||||
number is architecture dependent and may not directly correlate with the
|
||||
pad numbers. Due to this, it is also possible that the numbers changes
|
||||
between @b barebox releases.
|
||||
|
||||
@section gpio_dir_out Use Pad as GPIO Output
|
||||
@verbatim
|
||||
# gpio_direction_output <gpio_no> <initial_value>
|
||||
@endverbatim
|
||||
- gpio_no: Architecture dependend GPIO number
|
||||
- initial_value: Output value
|
||||
|
||||
<p> To avoid glitches on the pad the routines will first set up the
|
||||
pad's value and afterwards switch the pad to output (if the silicon is
|
||||
able to do so). If the pad is already configured in non-GPIO mode (if
|
||||
available), this command may silently fail. </p>
|
||||
|
||||
@section gpio_dir_in Use Pad as GPIO Input
|
||||
@verbatim
|
||||
# gpio_direction_input <gpio_no>
|
||||
@endverbatim
|
||||
- gpio_no: Architecture dependent GPIO number
|
||||
|
||||
<p> If the pad is already configured in non-GPIO mode (if available),
|
||||
this command may silently fail. </p>
|
||||
|
||||
@section gpio_get_value Read Input Value from GPIO Pin
|
||||
@verbatim
|
||||
# gpio_get_value <gpio_no>
|
||||
@endverbatim
|
||||
|
||||
<p> Reads the current value of a GPIO pin and return the value as a
|
||||
shell return code. There is no visible output on stdout. You can check
|
||||
the return value by using "echo $?". </p>
|
||||
|
||||
<p> A return code other than '0' or '1' specifies an error code. </p>
|
||||
|
||||
<p> If the pad is not configured in GPIO mode, this command may silently
|
||||
fail and return garbage. </p>
|
||||
|
||||
@section gpio_set_value Set Output Value on GPIO Pin
|
||||
@verbatim
|
||||
# gpio_set_value <gpio_no> <value>
|
||||
@endverbatim
|
||||
- gpio_no: Architecture dependent GPIO number
|
||||
- value: Output value
|
||||
|
||||
<p> Set a new output value on pad with GPIO number \<gpio_no>. </p>
|
||||
|
||||
<p> If the pad is not configured in GPIO-mode, this command may silently
|
||||
fail. </p>
|
||||
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -70,15 +70,6 @@ static int do_led(int argc, char *argv[])
|
|||
return 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* @page led_command
|
||||
|
||||
The exact meaning of <value> is unspecified. It can be a color in case of rgb
|
||||
LEDs or a brightness if this is controllable. In most cases only 1 for enabled
|
||||
is allowed.
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_HELP_START(led)
|
||||
BAREBOX_CMD_HELP_TEXT("Control the value of a LED. The exact meaning of VALUE is unspecified,")
|
||||
BAREBOX_CMD_HELP_TEXT("it can be a brightness, or a color. Most often a value of '1' means on")
|
||||
|
|
|
|||
|
|
@ -330,18 +330,6 @@ BAREBOX_CMD_HELP_TEXT("Options:")
|
|||
BAREBOX_CMD_HELP_OPT ("-v VESAMODE", "set VESAMODE")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page linux16_command
|
||||
|
||||
<p>Only kernel images in bzImage format are supported by now. See \ref
|
||||
x86_boot_preparation for more info about how to use this command.</p>
|
||||
|
||||
<p>For the video mode refer the Linux kernel documentation
|
||||
'Documentation/fb/vesafb.txt' for correct VESA mode numbers. If the keyword
|
||||
'ask' instead of a number is given, the starting kernel will ask for a number.
|
||||
</p>
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(linux16)
|
||||
.cmd = do_linux16,
|
||||
BAREBOX_CMD_DESC("boot a linux kernel on x86 via real-mode code")
|
||||
|
|
@ -349,57 +337,3 @@ BAREBOX_CMD_START(linux16)
|
|||
BAREBOX_CMD_GROUP(CMD_GRP_BOOT)
|
||||
BAREBOX_CMD_HELP(cmd_linux16_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Boot support for Linux on x86
|
||||
*/
|
||||
|
||||
/**
|
||||
* @page x86_boot_preparation Linux Preparation on x86
|
||||
*
|
||||
* Due to some real mode constraints, starting Linux is somehow tricky.
|
||||
* Currently only @p bzImages are supported, because @p zImages would
|
||||
* interfere with the @a barebox runtime.
|
||||
* Also older load header versions than 2.00 aren't supported.
|
||||
*
|
||||
* The memory layout immediately before starting the Linux kernel:
|
||||
*
|
||||
@verbatim
|
||||
real mode space hole extended memory
|
||||
|---------------------------------------------->|----------->|------------------------------>
|
||||
0 0x7e00 0x90000 0xa0000 0x100000
|
||||
<-1-|----------2-----------><-3- |
|
||||
<-4--|-5--> |---------6------------->
|
||||
@endverbatim
|
||||
*
|
||||
* @li 1 = @a barebox's real mode stack
|
||||
* @li 2 = @a barebox's code
|
||||
* @li 3 = @a barebox's flat mode stack
|
||||
* @li 4 = real mode stack, when starting the Linux kernel
|
||||
* @li 5 = Kernel's real mode setup code
|
||||
* @li 6 = compressed kernel image
|
||||
*
|
||||
* A more detailed memory layout for kernel's real mode setup code
|
||||
*
|
||||
@verbatim
|
||||
|
||||
0x90000 0x97fff 0x99000 0x990ff
|
||||
---|------------------------------------------|----------------|--------------------|
|
||||
|<-------- max setup code size ----------->|<--heap/stack-->|<-- command line -->|
|
||||
|
||||
@endverbatim
|
||||
*
|
||||
* The regular entry point into the setup code is 0x90200 (2nd sector)
|
||||
*
|
||||
* To start the kernel, it's own setup code will be called. To do so, it
|
||||
* must be called in real mode. So, @a barebox switches back to real mode
|
||||
* a last time and does a jump to the setup code entry point. Now its up to
|
||||
* the setup code to deflate the kernel, switching to its own protected mode
|
||||
* setup and starting the kernel itself.
|
||||
*
|
||||
* @note This scenario only works, if a BIOS is still present. In this case
|
||||
* there is no need for @a barebox to forward any system related information
|
||||
* to the kernel. Everything is detected by kernel's setup code.
|
||||
*
|
||||
*/
|
||||
|
|
|
|||
|
|
@ -112,15 +112,6 @@ BAREBOX_CMD_HELP_OPT("-s", "scrub old environment")
|
|||
BAREBOX_CMD_HELP_OPT("-d", "load default environment")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page loadenv_command
|
||||
|
||||
ENVFS can only handle files, directories are skipped silently.
|
||||
|
||||
\todo This needs proper documentation. What is ENVFS, why is it FS etc. Explain the concepts.
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(loadenv)
|
||||
.cmd = do_loadenv,
|
||||
BAREBOX_CMD_DESC("load environment from ENVFS")
|
||||
|
|
|
|||
|
|
@ -293,12 +293,6 @@ BAREBOX_CMD_HELP_TEXT("Options:")
|
|||
BAREBOX_CMD_HELP_OPT("-v", "increase verbosity")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page miitool_command
|
||||
This utility checks or sets the status of a network interface's
|
||||
Media Independent Interface (MII) unit. Most fast ethernet
|
||||
adapters use an MII to autonegotiate link speed and duplex setting.
|
||||
*/
|
||||
BAREBOX_CMD_START(miitool)
|
||||
.cmd = do_miitool,
|
||||
BAREBOX_CMD_DESC("view media-independent interface status")
|
||||
|
|
|
|||
|
|
@ -17,11 +17,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Filesystem mounting support
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <fs.h>
|
||||
|
|
@ -130,37 +125,6 @@ BAREBOX_CMD_HELP_OPT("-o OPTIONS", "set file system OPTIONS")
|
|||
BAREBOX_CMD_HELP_OPT("-v\t", "verbose")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page mount_command
|
||||
|
||||
<ul>
|
||||
<li>\<device> can be a device in /dev or some arbitrary string if no
|
||||
device is needed for this driver, i.e. on ramfs. </li>
|
||||
<li>\<fstype> is the filesystem driver. A list of available drivers can
|
||||
be shown with the \ref devinfo_command command.</li>
|
||||
<li>\<mountpoint> must be an empty directory, one level below the /
|
||||
directory.</li>
|
||||
</ul>
|
||||
|
||||
*/
|
||||
|
||||
/**
|
||||
* @page how_mount_works How mount works in barebox
|
||||
|
||||
Mounting a filesystem ontop of a device is working like devices and
|
||||
drivers are finding together.
|
||||
|
||||
The mount command creates a new device with the filesystem name as the
|
||||
driver for this "device". So the framework is able to merge both parts
|
||||
together.
|
||||
|
||||
By the way: With this feature its impossible to accidentely remove
|
||||
partitions in use. A partition is internally also a device. If its
|
||||
mounted it will be marked as busy, so an delpart command fails, until
|
||||
the filesystem has been unmounted.
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(mount)
|
||||
.cmd = do_mount,
|
||||
BAREBOX_CMD_DESC("mount a filesystem or list mounted filesystems")
|
||||
|
|
|
|||
|
|
@ -180,18 +180,6 @@ BAREBOX_CMD_HELP_TEXT("The size of the last partition can be specified as '-' fo
|
|||
BAREBOX_CMD_HELP_TEXT("space on the device.")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page addpart_command
|
||||
|
||||
The size and the offset can be given in decimal (without any prefix) and
|
||||
in hex (prefixed with 0x). Both can have an optional suffix K, M or G.
|
||||
The size of the last partition can be specified as '-' for the remaining
|
||||
space on the device. This format is the same as used by the Linux
|
||||
kernel or cmdline mtd partitions.
|
||||
|
||||
\todo This command has to be reworked and will probably change it's API.
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(addpart)
|
||||
.cmd = do_addpart,
|
||||
BAREBOX_CMD_DESC("add a partition description to a device")
|
||||
|
|
@ -219,17 +207,6 @@ BAREBOX_CMD_HELP_START(delpart)
|
|||
BAREBOX_CMD_HELP_TEXT("Delete partitions previously added to a device with addpart.")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page delpart_command
|
||||
|
||||
Partitions are created by adding their description with the addpart
|
||||
command. If you want to get rid of a partition again, use delpart. The
|
||||
argument list is taken as a list of partitions to be deleted.
|
||||
|
||||
\todo Add an example
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(delpart)
|
||||
.cmd = do_delpart,
|
||||
BAREBOX_CMD_DESC("delete partition(s)")
|
||||
|
|
@ -238,4 +215,3 @@ BAREBOX_CMD_START(delpart)
|
|||
BAREBOX_CMD_HELP(cmd_delpart_help)
|
||||
BAREBOX_CMD_COMPLETE(devfs_partition_complete)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
|
|
|
|||
|
|
@ -15,11 +15,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief printenv: Print out environment variables
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <errno.h>
|
||||
|
|
@ -62,15 +57,6 @@ BAREBOX_CMD_HELP_TEXT("variable to the terminal. If no argument is specified, al
|
|||
BAREBOX_CMD_HELP_TEXT("printed.")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page printenv_command
|
||||
|
||||
<p>If an argument is given, printenv prints the content of an environment
|
||||
variable to the terminal. If no argument is specified, all variables are
|
||||
printed.</p>
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(printenv)
|
||||
.cmd = do_printenv,
|
||||
BAREBOX_CMD_DESC("print value of environment variables")
|
||||
|
|
|
|||
|
|
@ -15,11 +15,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief saveenv: Make the environment persistent
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <errno.h>
|
||||
|
|
@ -64,16 +59,3 @@ BAREBOX_CMD_START(saveenv)
|
|||
BAREBOX_CMD_GROUP(CMD_GRP_ENV)
|
||||
BAREBOX_CMD_HELP(cmd_saveenv_help)
|
||||
BAREBOX_CMD_END
|
||||
|
||||
/**
|
||||
* @page saveenv_command
|
||||
|
||||
<p>\<envfs> is usually a block in flash but can be any other file. If
|
||||
omitted, \<directory> defaults to /env and \<envfs> defaults to
|
||||
/dev/env0. Note that envfs can only handle files, directories are being
|
||||
skipped silently.</p>
|
||||
|
||||
\todo What does 'block in flash' mean? Add example.
|
||||
|
||||
*/
|
||||
|
||||
|
|
|
|||
|
|
@ -15,11 +15,6 @@
|
|||
*
|
||||
*/
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief setenv: Set an environment variables
|
||||
*/
|
||||
|
||||
#include <common.h>
|
||||
#include <command.h>
|
||||
#include <errno.h>
|
||||
|
|
@ -40,14 +35,6 @@ BAREBOX_CMD_HELP_TEXT("Set environment variable NAME to VALUE.")
|
|||
BAREBOX_CMD_HELP_TEXT("If VALUE is ommitted, then the variable is deleted.")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page setenv_command
|
||||
|
||||
<p> This command is only available if the simple command line parser is
|
||||
in use. Within the hush shell, \c setenv is not required.</p>
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(setenv)
|
||||
.cmd = do_setenv,
|
||||
BAREBOX_CMD_DESC("set environment variable")
|
||||
|
|
|
|||
|
|
@ -89,17 +89,6 @@ BAREBOX_CMD_HELP_OPT ("-b COLOR", "background color in 0xttrrggbb")
|
|||
BAREBOX_CMD_HELP_OPT ("-o\t", "render offscreen")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page bmp_command
|
||||
|
||||
This command displays a graphics in the bitmap (.bmp) format on the
|
||||
framebuffer. Currently the bmp command supports images with 8 and 24 bit
|
||||
color depth.
|
||||
|
||||
\todo What does the -o (offscreen) option do?
|
||||
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(splash)
|
||||
.cmd = do_splash,
|
||||
BAREBOX_CMD_DESC("display a BMP image")
|
||||
|
|
|
|||
|
|
@ -92,10 +92,6 @@ BAREBOX_CMD_HELP_OPT ("-s", "Generic Serial")
|
|||
BAREBOX_CMD_HELP_OPT ("-d", "Disable the serial gadget")
|
||||
BAREBOX_CMD_HELP_END
|
||||
|
||||
/**
|
||||
* @page usbserial_command
|
||||
*/
|
||||
|
||||
BAREBOX_CMD_START(usbserial)
|
||||
.cmd = do_usbserial,
|
||||
BAREBOX_CMD_DESC("serial gadget enable/disable")
|
||||
|
|
|
|||
|
|
@ -3,8 +3,6 @@
|
|||
#include <kallsyms.h>
|
||||
#include <asm/sections.h>
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
/* These will be re-linked against their real values during the second link stage */
|
||||
extern const unsigned long kallsyms_addresses[] __attribute__((weak));
|
||||
extern const unsigned long kallsyms_num_syms __attribute__((weak));
|
||||
|
|
@ -15,8 +13,6 @@ extern const u16 kallsyms_token_index[] __attribute__((weak));
|
|||
|
||||
extern const unsigned long kallsyms_markers[] __attribute__((weak));
|
||||
|
||||
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
|
||||
|
||||
static inline int is_kernel_text(unsigned long addr)
|
||||
{
|
||||
if ((addr >= (unsigned long)_stext && addr <= (unsigned long)_etext))
|
||||
|
|
|
|||
|
|
@ -90,8 +90,6 @@ void barebox_cmd_usage(struct command *cmdtp);
|
|||
|
||||
#endif /* __ASSEMBLY__ */
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
#define Struct_Section __attribute__ ((unused,section (".barebox_cmd")))
|
||||
|
||||
#define BAREBOX_CMD_START(_name) \
|
||||
|
|
@ -127,8 +125,6 @@ static const __maybe_unused char cmd_##_name##_help[] =
|
|||
|
||||
#define BAREBOX_CMD_OPTS(text) .opts = text,
|
||||
|
||||
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
|
||||
|
||||
int register_command(struct command *);
|
||||
|
||||
#endif /* __COMMAND_H */
|
||||
|
|
|
|||
|
|
@ -28,32 +28,6 @@
|
|||
|
||||
#include <param.h>
|
||||
|
||||
/**
|
||||
* @file
|
||||
* @brief Main description of the device/driver model
|
||||
*/
|
||||
|
||||
/** @page driver_model Main description of the device/driver model
|
||||
*
|
||||
* We follow a rather simplistic driver model here. There is a
|
||||
* @code struct device_d @endcode
|
||||
* which describes a particular device present in the system.
|
||||
*
|
||||
* On the other side a
|
||||
* @code struct driver_d @endcode
|
||||
* 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_d 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.
|
||||
*/
|
||||
|
||||
/*@{*/ /* do not delete, doxygen relevant */
|
||||
|
||||
struct filep;
|
||||
struct bus_type;
|
||||
|
||||
|
|
|
|||
|
|
@ -19,8 +19,6 @@
|
|||
#include <driver.h>
|
||||
#include <linux/types.h>
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
/*
|
||||
* struct i2c_platform_data - structure of platform data for MXC I2C driver
|
||||
* @param bitrate Bus speed measured in Hz
|
||||
|
|
@ -153,8 +151,6 @@ extern int i2c_master_recv(struct i2c_client *client, char *buf, int count);
|
|||
extern int i2c_read_reg(struct i2c_client *client, u32 addr, u8 *buf, u16 count);
|
||||
extern int i2c_write_reg(struct i2c_client *client, u32 addr, const u8 *buf, u16 count);
|
||||
|
||||
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
|
||||
|
||||
extern struct bus_type i2c_bus;
|
||||
|
||||
static inline int i2c_driver_register(struct driver_d *drv)
|
||||
|
|
|
|||
|
|
@ -7,8 +7,6 @@
|
|||
#ifndef __MTD_ABI_H__
|
||||
#define __MTD_ABI_H__
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
#include <asm-generic/div64.h>
|
||||
|
||||
struct erase_info_user {
|
||||
|
|
@ -183,6 +181,4 @@ static inline uint32_t mtd_user_div_by_eb(uint64_t sz,
|
|||
return sz;
|
||||
}
|
||||
|
||||
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
|
||||
|
||||
#endif /* __MTD_ABI_H__ */
|
||||
|
|
|
|||
|
|
@ -9,8 +9,6 @@
|
|||
#ifndef __MTD_MTD_H__
|
||||
#define __MTD_MTD_H__
|
||||
|
||||
#ifndef DOXYGEN_SHOULD_SKIP_THIS
|
||||
|
||||
#include <driver.h>
|
||||
#include <errno.h>
|
||||
#include <linux/types.h>
|
||||
|
|
@ -325,8 +323,6 @@ int mtd_all_ff(const void *buf, unsigned int len);
|
|||
|
||||
#endif /* CONFIG_MTD_DEBUG */
|
||||
|
||||
#endif /* DOXYGEN_SHOULD_SKIP_THIS */
|
||||
|
||||
static inline int mtd_is_bitflip(int err) {
|
||||
return err == -EUCLEAN;
|
||||
}
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue