Subject: Re: how to determine loader address when porting NetBSD using u-boot
To: None <port-arm@netbsd.org>
From: Toru Nishimura <locore64@alkyltechnology.com>
List: port-arm
Date: 04/07/2006 10:25:29
[... regarding to use U-Boot utility ...]

> mkimage  -A arch -O os -T type -a addr1  -e addr2  -d sourceImage uImage
> How to determine addr1 and addr2 ?   And why?

You need to grasp ARM address space layout.  I ring a bell loudly.
It's very common mishap to trap badly the ARM new comers.
Do careful research kernel code path from entry point to the last line
of initarm().

- ARM needs to start paddr 0 instruction.
- but these days right after power on NOR is commonly mapped there
to allow XIP.  It's handy but...
- SDRAM is located high; sometimes 0x8000'0000, 0xA000'0000 or
0xC000'0000, very strange arrangement.
- Some ARM9 SoC needs to crank up SDRAM controller circuit to
make it *useful* (ooch!)
- Some ARM9 SoC can swap SDRAM paddr into bottom by magic
switching.
- Most of ARM NetBSD kernel is located vaddr 0xC000'0000.  Bootloader
has to be _smart enough_ to solve mismatch SDRAM paddr and
kernel vaddr, include appropriate ELF header pursing.
- if paddr/vaddr arrangement disagree each other between
bootloader and NetBSD kernel, it's pretty likely you gets wrecked
before any meaningful printf().  IMHO, avoid RedBoot.

As die-hard MIPS fan, it's a real strength MIPS has processor reset
entry point in the end of KSEG1 space, I believe in.  There is no
need to concern about (the lack of) MMU/TLB and how the cache
machinery works.  The processor can run as it is. See the below
if you're interested in my point.

http://www.e-14.com/collateral/wp/SB-1_WP100-R.pdf

Toru Nishimura/ALKYL Technology