summaryrefslogtreecommitdiffstats
path: root/arch
diff options
context:
space:
mode:
authorJuergen Beisert <jbe@pengutronix.de>2009-12-15 11:32:02 +0100
committerSascha Hauer <s.hauer@pengutronix.de>2009-12-15 11:32:02 +0100
commitdac84c7b9d67c2f831adb53a41f53a9f7330acdb (patch)
tree4e6e7ad95e421fd8e0f4a7eb1771b7391f8f1f1f /arch
parentf3d6e2f8f93b6f0d9b8ca68bc7978ea3036636be (diff)
downloadbarebox-dac84c7b9d67c2f831adb53a41f53a9f7330acdb.tar.gz
barebox-dac84c7b9d67c2f831adb53a41f53a9f7330acdb.tar.xz
documentation updates
Signed-off-by: Juergen Beisert <jbe@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Diffstat (limited to 'arch')
-rw-r--r--arch/architecture.dox12
-rw-r--r--arch/arm/cpu/start-arm.S1
-rw-r--r--arch/arm/mach-arm.dox2
-rw-r--r--arch/arm/mach-omap/arch-omap.dox16
-rw-r--r--arch/arm/mach-s3c24xx/generic.c12
5 files changed, 21 insertions, 22 deletions
diff --git a/arch/architecture.dox b/arch/architecture.dox
index b1e32a5328..669c028435 100644
--- a/arch/architecture.dox
+++ b/arch/architecture.dox
@@ -5,7 +5,7 @@
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 barebox! This
+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
@@ -19,11 +19,11 @@ 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 barebox image.
+architecture specific locations within the binary @a barebox image.
All reset code uses section ".text_entry" for its localisation within the
-binary barebox image. Its up to the linker script file to use this section name
-to find the right place in whatever environment and barebox sizes.
+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"
@@ -45,7 +45,7 @@ Features required for every CPU:
@section time_keeping Time keeping
-In barebox we are using the clocksource mechanism from the Linux Kernel.
+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.
@@ -78,7 +78,7 @@ 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: barebox expects an upward counting counter!
+@note @a barebox expects an upward counting counter!
@section reset_function Reset function
diff --git a/arch/arm/cpu/start-arm.S b/arch/arm/cpu/start-arm.S
index 43bc5dddda..a30b281c93 100644
--- a/arch/arm/cpu/start-arm.S
+++ b/arch/arm/cpu/start-arm.S
@@ -35,7 +35,6 @@
* - i.MX27
* - i.MX31
*
- * FIXME: Stop doxygen from parsing the text below
*/
.section ".text_entry","ax"
diff --git a/arch/arm/mach-arm.dox b/arch/arm/mach-arm.dox
index 3b76f8e34a..76b6883609 100644
--- a/arch/arm/mach-arm.dox
+++ b/arch/arm/mach-arm.dox
@@ -31,7 +31,7 @@ barebox binary from the NAND flash memory prior returning from \<board_init_lowl
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 barebox itself (if not already done). It gets copied
+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".
diff --git a/arch/arm/mach-omap/arch-omap.dox b/arch/arm/mach-omap/arch-omap.dox
index d5a7f8be35..01e45f291e 100644
--- a/arch/arm/mach-omap/arch-omap.dox
+++ b/arch/arm/mach-omap/arch-omap.dox
@@ -4,7 +4,7 @@
/** @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 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
@@ -17,8 +17,8 @@ This document highlights some of the factors for supporting Texas Instrument's O
@section omap_boards Boards using OMAP processors
-@li @subpage board/omap/board-sdp343x.c
-@li @subpage board/omap/board-beagle.c
+@li @subpage ti_SDP3430
+@li @subpage ti_beagle
@section omap_arch Documentation for OMAP Architectures files
@@ -26,11 +26,11 @@ This document highlights some of the factors for supporting Texas Instrument's O
@section omap_code_arch How is barebox OMAP specific architecture code organized?
-To understand the architecture of barebox source code for OMAP processors, we need to understand a bit on OMAP itself.
+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. barebox code organization is driven by this fact.
+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.
@@ -53,13 +53,13 @@ All OMAP common headers are located here. Where we have to incorporate a OMAP va
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 #define OMAP_SOMETHING_BASE to allow re-use.
@section board_omap board/omap directory guidelines
-All Board specific files go here. In barebox V1, 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 barebox. This is more like programming for Linux kernel - it is pretty easy.
+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, 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 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.
@@ -69,7 +69,7 @@ Once this is past, the code returns back to arm common code (cpu/start-arm.S). H
If the proper CONFIG_MACH_DO_LOWLEVEL_INIT flag is setup, board_init_lowlevel is called. This again would call a common file board/omap/platform.S which setups a temporary SRAM stack and bumps the control to board_init.
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, barebox boot process proceeds by calling init functions and finally entering shell prompt
+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
diff --git a/arch/arm/mach-s3c24xx/generic.c b/arch/arm/mach-s3c24xx/generic.c
index dddd0187c3..2de03ca809 100644
--- a/arch/arm/mach-s3c24xx/generic.c
+++ b/arch/arm/mach-s3c24xx/generic.c
@@ -276,18 +276,18 @@ All S3C24xx common headers are located here.
@par barebox Map
-The location of the barebox itself depends on the available amount of
+The location of the @a barebox itself depends on the available amount of
installed SDRAM memory:
-- 0x30fc.0000 Start of barebox when 16MiB SDRAM is available
-- 0x31fc.0000 Start of barebox when 32MiB SDRAM is available
-- 0x33fc.0000 Start of barebox when 64MiB SDRAM is available
+- 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 CONFIG_TEXT_BASE/CONFIG_ARCH_TEXT_BASE symbol in accordance to
+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
-barebox start address.
+@a barebox start address.
@li @subpage dev_s3c24xx_wd_handling
@li @subpage dev_s3c24xx_pll_handling