Re: Fwd: Gumstix Verdex not booting with NetBSD 7.0 and newer

[smesgr <smesgr%gmail.com@localhost>]

> Does this help?
After all the boot issues are solved now. Thanks to you and Christos. I 
think I'm back at the original problem with the memory layout. On 
selecting the /sbin/init the system crashs.

copyout 0xc060fc60, 0xbfffeff5, 11
data_abort_handler: data_aborts fsr=0x406 far=0xbfffeff5

To my understanding the kernel try to copy data from its kernel space to 
user space. But the target address is odd. To my understanding the user 
address is in unmapped address space. (oddly if i reboot the system - 
the system is useable afterwards even the user space address seems still 
odd)

The USRSPACE is calculated by this KERNEL_BASE - PAGE_SIZE. the Verdex 
(or all Xscale-based Gumstix boards) uses ARM_VECTORS_LOW. The newer 
non-Xscale Gumstix boards (Overo, DuoVero and Pepper) uses _HIGH. I'm 
under the expression there is a mixup between these setups. I would 
expect the following layout with VECTORS_LOW.

start of virtual memory AND start of kernel area @ 0xc0000000
end of kernel area @  0xc0ffffff
start of user space @ 0xc1000000
end of virtual memory AND end of user space @ 0xc8000000 or 0xc400000 
for 64MB RAM

If I understand your patch correctly you try to move the start of the 
kernel address to the higher area so user space can be mapped in front 
of the kernel. But then the KERNEL_BASE address should be adjusted 
according to the ram available in the system. For an 64MB system the 
start address 0xc8000000 would be afaik not available.

sorry if I can't see the obvious thing in here.

Best Regards
Stephan