It's very difficult debug these sections of code without an hardware
emulator like bdi2000 or similar.
In the following link there is a simple introduction to the step made from
the kernel in the early boot sequence
http://gicl.cs.drexel.edu/people/sevy/linux/PPC_Linux_boot_sequence.html.
Maybe the problem is due to the machine type code that is not correctly
saved.
Best Regards,
Andrea Bernardi
2008/7/5 YenHung Chen <[EMAIL PROTECTED]>:
>
> I am porting linux-2.6.23-android-m5-rc14 kernel to TI Davinci DM355,
> and encountered a problem, could anyone help me to fix the problem?
>
> My development environment:
>
> Fedora Core 8
> GCC 4.1.2 <-- I build the cross compiling tool by myself
> linux-2.6.23-android-m5-rc14 kernel
>
> My problem is the compiled kernel could not boot on EVM board,
> I have checked the booting process, the uncompress kernel process is done,
> the problem is happened at the places in 2 files as following list:
>
> arch/arm/kernel/head.S
> arch/arm/kernel/head-common.S
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> The booting information is:
>
> Starting kernel ...
>
> Uncompressing
> Linux...................................................................................................................
> done, booting the kernel.
>
>
> Then, there is no other information on the screen.
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> In file arch/arm/kernel/head.S, function __turn_mmu_on
>
> ENTRY(stext)
> msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
> @ and irqs disabled
> mrc p15, 0, r9, c0, c0 @ get processor id
> bl __lookup_processor_type @ r5=procinfo r9=cpuid
> movs r10, r5 @ invalid processor (r5=0)?
> beq __error_p @ yes, error 'p'
> bl __lookup_machine_type @ r5=machinfo
> movs r8, r5 @ invalid machine (r5=0)?
> beq __error_a @ yes, error 'a'
> bl __vet_atags
> bl __create_page_tables
>
> /*
> * The following calls CPU specific code in a position independent
> * manner. See arch/arm/mm/proc-*.S for details. r10 = base of
> * xxx_proc_info structure selected by __lookup_machine_type
> * above. On return, the CPU will be ready for the MMU to be
> * turned on, and r0 will hold the CPU control register value.
> */
> ldr r13, __switch_data @ address to jump to after
> @ mmu has been enabled
> adr lr, __enable_mmu @ return (PIC) address <--- this line has
> run
> add pc, r10, #PROCINFO_INITFUNC <--- this line has run
>
> .align 5
> .type __turn_mmu_on, %function
> __turn_mmu_on:
> mov r0, r0
> mcr p15, 0, r0, c1, c0, 0 @ write control reg <--- not sure
> that it has run
> mrc p15, 0, r3, c0, c0, 0 @ read id reg
> mov r3, r3
> mov r3, r3
> mov pc, r13
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> In file arch/arm/kernel/head-common.S, I am not sure that object
> __switch_data and function
> __mmap_switched have run?
>
> .type __switch_data, %object
> __switch_data:
> .long __mmap_switched
> .long __data_loc @ r4
> .long __data_start @ r5
> .long __bss_start @ r6
> .long _end @ r7
> .long processor_id @ r4
> .long __machine_arch_type @ r5
> .long __atags_pointer @ r6
> .long cr_alignment @ r7
> .long init_thread_union + THREAD_START_SP @ sp
>
> /*
> * The following fragment of code is executed with the MMU on in MMU mode,
> * and uses absolute addresses; this is not position independent.
> *
> * r0 = cp#15 control register
> * r1 = machine ID
> * r2 = atags pointer
> * r9 = processor ID
> */
> .type __mmap_switched, %function
> __mmap_switched:
> adr r3, __switch_data + 4
> ldmia r3!, {r4, r5, r6, r7}
> cmp r4, r5 @ Copy data segment if needed
> 1: cmpne r5, r6
> ldrne fp, [r4], #4
> strne fp, [r5], #4
> bne 1b
> mov fp, #0 @ Clear BSS (and zero fp)
> 1: cmp r6, r7
> strcc fp, [r6],#4
> bcc 1b
> ldmia r3, {r4, r5, r6, r7, sp}
> str r9, [r4] @ Save processor ID
> str r1, [r5] @ Save machine type
> str r2, [r6] @ Save atags pointer
> bic r4, r0, #CR_A @ Clear 'A' bit
> stmia r7, {r0, r4} @ Save control register values
> b start_kernel
>
> -------------------------------------------------------------------------------------------
>
> Could anyone recommend me how to fix the problem?
>
> Thanks!
>
> YenHung Chen
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Android Internals" group.
To post to this group, send email to android-internals@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-internals?hl=en
-~----------~----~----~----~------~----~------~--~---
