1 files changed, 9 insertions, 9 deletions
diff --git a/arch/arm/mach-omap/arch-omap.dox b/arch/arm/mach-omap/arch-omap.dox
index 857ca3eb5d..d5a7f8be35 100644
--- a/arch/arm/mach-omap/arch-omap.dox
+++ b/arch/arm/mach-omap/arch-omap.dox
@@ -1,10 +1,10 @@
 /* This document is intended to provide the developer with information
- * how to integrate a new OMAP Architecture into this part of the U-Boot tree
+ * how to integrate a new OMAP Architecture into this part of the barebox tree
  */
 
-/** @page dev_omap_arch Texas Instrument's OMAP Platforms in U-Boot V2
+/** @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 U-Boot V2.
+This document highlights some of the factors for supporting Texas Instrument's OMAP platforms in barebox.
 
 @par Table of Contents
 @li @ref omap_boards
@@ -24,13 +24,13 @@ This document highlights some of the factors for supporting Texas Instrument's O
 
 @li @subpage arch/arm/mach-omap/omap3_generic.c
 
-@section omap_code_arch How is U-Boot V2 OMAP specific architecture code organized?
+@section omap_code_arch How is barebox OMAP specific architecture code organized?
 
-To understand the architecture of U-Boot V2 source code for OMAP processors, we need to understand a bit on OMAP itself.
+To understand the architecture of 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. U-Boot V2 code organization is driven by this fact.
+Essentially, OMAP is modular with on-silicon peripherals being reused across multiple OMAP versions. 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 U-Boot 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 U-Boot V2. This is more like programming for Linux kernel - it is pretty easy.
+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.
 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, U-Boot'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, 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, U-boot V2 boot process proceeds by calling init functions and finally entering shell prompt
+Once this is complete, 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