Hi everyone! I got lucky and got an embedded linux internship:) I'm trying to port linux to an existing board that is currently using vxWorks. The board uses an mpc8572e processor which contains two e500v2 cores. Basically, the entry point in vmlinux is arch/powerpc/kernel/head_fsl_booke.S We are using the simpleboot bootwrapper which works just fine (simpleboot passes the device tree address and jump right into the gunziped vmlinux which is located at 0x0 physical). head_fsl_booke.S include arch/powerpc/kernel/fsl_booke_entry_mapping.S and we just crash at line 223 (rfi instruction) of fsl_booke_entry_mapping.S 215 lis r7,MSR_KERNEL@h 216 ori r7,r7,MSR_KERNEL@l 217 bl 1f /* Find our address */ 218 1: mflr r9 219 rlwimi r6,r9,0,20,31 220 addi r6,r6,(2f - 1b) 221 mtspr SPRN_SRR0,r6 222 mtspr SPRN_SRR1,r7 223 rfi /* start execution out of TLB1[0] entry */ rfi at line 223 causes us to jump to 0xc000_0264 while we want to jump to 0x000_0264. This is not caused by our mmu, we are basically loading 0xc000_0264 in srr0 I think it's related to the following config fields in our defconfig: CONFIG_PAGE_OFFSET=0xc0000000 <---- CONFIG_PHYSICAL_START=0x00000000 CONFIG_PHYSICAL_ALIGN=0x04000000 CONFIG_TASK_SIZE=0xc0000000 CONFIG_KERNEL_START=0xc00000000 <----- I tried to set CONFIG_KERNEL_START and CONFIG_PAGE_OFFSET to 0x0 but this would not compile: arch/powerpc/include/asm/processor.h:100:2: error: #error User TASK_SIZE overlaps with KERNEL_START address By the way CONFIG_TASK_SIZE=0xc0000000 Also, my debugger cannot map anything because all the symbols in vmlinux are at 0xcxxx_xxxx but we are at 0x0xxx_xxxx Pretty much all the ports that uses the simpleboot bootwrapper are gunzipping vmlinux at 0x0 but I can easily change that and I tried to send vmlinux at 0xc000_0000 and it solved this particular issue but then the mmu mapping just does not work because simpleboot extract our device tree at about 0x0011_0000 and we need vmlinux and the device tree to be inside a 64Mb page (also tried to hack fsl_booke_entry_mapping.S to create a 4GB tlb entry based at 0x0 and this was causing other issues...) Got any idea? Also, I found out that __machine_desc_start is invalid (I see .long 0x0 as value in my on-chip debugger for this symbol when I tried to use a 4GB tlb entry.). This was causing me issues in probe_machine() located in arch/powerpc/kernel/setup-common.c when I tried the 4GB tlb approach. The 4GB tlb entry was also causing issues with the __va() macro (it was doing address translation from physical to virtual address) so I was removing the calls to that macro to make it work. but I don't really wan't to hack the kernel all over the place because I don't understand how it's supposed to be done. I suppose it's somehow still related to the configs above? For the 4GB tlb entry I want __va() to return what it received because we are using a 1:1 mapping. Btw, I'm on the right mailing list? Thanks! Nicolas Béland Dialogic Inc. Montreal (Canada) Nicolas.Beland@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
