Day 1: getting a feel and a few thoughts

Where are the files?
u-boot.arm is what i am basing myself on.
Directory: u-boot.arm/lib_arm/
Description:
ARM specific library function implementation
Files:
armlinux.c _ashrdi3.S cache.c _divsi3.S _modsi3.S _umodsi3.S
_ashldi3.S board.c div0.c Makefile _udivsi3.S
Contains:
some important (if I may use such a word - all look important):
bootm implementation,
banner display
cache functions
start_armboot

Directory:/u-boot.arm/cpu/arm1136
Description:
ARM1136 CPU specific logic. This is kind of common for most part. I can see that ARM integrator and 2420 are the two folks using this so far at least..

Files:
config.mk cpu.c interrupts.c Makefile start.S

Contains:
start.s is the basic starting point of the boot process..
__start is where the code starts the boot..
So... after almost an year and a half of CCS assembly, I need to brush up the GNU ARM Assembly.. i got it somewhere.. hmm..
Ref:
GNU ARM Assembly Quick Reference Guide: http://www.microcross.com/GNU-ARM-Assy-Quick-Ref.pdf
An Introduction to the GNU ARM Assembler - A Summary of the GNU Assembler Manual: http://www.microcross.com/assembler-intro.pdf
GNU inline assembler cookbook: http://www.ethernut.de/en/documents/arm-inline-asm.html

AND ofcourse:
ARM Architecture manual: http://www.arm.com/documentation/books/1183.html
(some 50 bucks or so... )
U can also see ARM V7 info here: http://www.arm.com/products/CPUs/ARM_Cortex-M3_v7.html

Note: I am just putting links here from google.. so lets see where it gets me.

(idea) on reset:
we do an ivt relocation to trampoline vector of rom code.. Hmm.. that should move out of there...
if i move it to cpu_init_crit....and keep _start to r0... will that work? mainly do arm integrator folks care?

I like Kyumin Park's patch on reusing the same uboot as xloader with lots of options stripped out.. so the boot code should be capable of that too..

(idea) arm1136_cache_flush
all flush and cache routines should go out to mmu.s

(idea) .reset_cpu is SOC based.. does not belong here..

(idea): asm/arch/omap2420.h
hmm...i'd like it as:
asm/arch/cpu.h
depends on asm/arch/soc.h
That brings about a larger question:
how should the code be organised.. I think the following is logical:
ARM --> SOC1
\-> SOC2 --> board1
\-> board2
reuse capability:
accross boards (e.g. fpga logic)
across soc (e.g. b/w 3430 and 2430 if i want to reuse gpmc)

now, that raises a question as to how each of the following should be organized:
a) board directory
b) cpu/arm1136
c) include/asm/arch

(idea): should int handling be isolated L220 specific? does not make sense to me... but.. on a larger context??

ok.. it is dinner time and bit of tv mebbe now..