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