>> RedBoot> load -r -b 0x00200000 kernel
>> Using default protocol (TFTP)
>> Raw file loaded 0x00200000-0x00565eb2, assumed entry at 0x00200000
>> RedBoot> go
>> $T050f:00200000;0d:03fc0fec;#d9

CPU got wrecked during 'running before dawn'

> Am I wrong using 0x00200000 to boot the kernel ?
> I am not sure what memory address use here.

Being occupied by RedBoot itself?

ARM SoCs have a habit of inconsistent RAM paddr.  It's definitely a trap for new
comers since the fact imposes horrible complications for OS initialization steps.
When completed correctly, initarm() finishes the entire NetBSD address space; kernel
in upper vaddr (at 0xC000'0000 in most cases) and user process in rest of it.  RAM
paddr varies wildly and DEV registers are vaddr'ed somewhere at far beyond kernel
end, KVA 0xF000'0000 or some.  It's simple, isn't it?

The issue is how to get there.  RedBoot provides a comfortable illusion as if
RAM is populated at address range bottom.  But, during OS initialization steps
CPU have to kill anyway MMU to see "naked HW paddr layout" and constructs
new address space tailored for the booting OS.  So, it's very important where
the CPU thinks itself running around.

Another complication is zImage; self-decompressing kernel binary scheme
inherited from ISA PC.  NetBSD reluctantly (happily?) introduced gzboot to
cope with RedBoot.  Decompress requires intermediate working memory
before the target kernel image is populated at the target place.  Lack of
understanding RAM vaddr/paddr trampoline scheme wasted precious developer
time.  Look back at mail-index.netbsd.org and count how many time essentially
the same Q was made to understand address space crafting.

So, moral here is;
- get confident about HW paddr layout first
- get encumbered RedBoot vaddr if you can not escape from
- draw figures how CPU traverses address range while munching insns
- when initarm() completes successfully, it's likely your port effort is 90% done
  (minus fancy bell&whistle devices...)

Toru Nishimura/ALKYL Technology