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..
with a 
