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

Comments

Popular posts from this blog

simpler alternative to minicom

Quick and Dirty userspace testing of regulator with virtual consumer

Setting up Email forwarding System for GIT