On 02/04/17 14:40, smesgr wrote:
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.Does this help?copyout 0xc060fc60, 0xbfffeff5, 11 data_abort_handler: data_aborts fsr=0x406 far=0xbfffeff5
What ABI are you using for your userland/kernel?earm allows unaligned access whereas the old ABI didn't - looking back at an old dmesg it looks like you're using OABI. As it won't be (isn't?) supported for much longer you should switch.
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 @ 0xc1000000end of virtual memory AND end of user space @ 0xc8000000 or 0xc400000 for 64MB RAMIf 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.
My patch shuffles kernel virtual address space (KVA) so that the kernel and all the memory can be "direct mapped". That is, all the memory is in one contiguous block from a start address. 0xc0000000 in this case. The KVA above the direct map area is available for other users.
Nick