__turn_mmu_on阶段之后如何调试Linux内核启动过程？

Question

I am trying to Boot Android 4.0.1 (Ice Cream Sandwich), based on Linux kernel 3.0.1 on a custom hardware.

I am able to debug the Linux Kernel 3.0.1 boot process till __enable_mmu function defined in head.S, using serial port.

But as soon as __turn_mmu_on function is performed I am not able to debug the boot process.

I have gone through linux-arm-kernel mailing list archives & i have tried their printascii() work around. But still I am not able to see any boot logs on serial console after __turn_mmu_on .

Here I am able to get logs before __turn_mmu_on so my serial console port is working fine.

And one more thing - I don't have JTAG.

Can anyone provide the solution how to debug Linux kernel Boot process after turn MMU on?

Answer 1

-

Hi, there, I have no idea on your question, but some thoughts.

in Linux source code, there are some points below,

/* * Enable the MMU. This completely changes the structure of the visible
* memory space. You will not be able to trace execution through this.
* If you have an enquiry about this, please check the linux-arm-kernel
* mailing list archives BEFORE sending another post to the list.
*
* r0 = cp#15 control register
* r1 = machine ID
* r2 = atags or dtb pointer
* r9 = processor ID
* r13 = virtual address to jump to upon completion
*
* other registers depend on the function called upon completion
*/ .align 5
.pushsection .idmap.text, "ax"
ENTRY(__turn_mmu_on)
....
....
__turn_mmu_on_end:
ENDPROC(__turn_mmu_on)
.popsection

So, it seems very normal that you can not trace the flow after the __turn_mmu_on is called.

But, with your result of using printascii(), have you debugged why it cannot be available to you?

Do you know whether or not printascii() is easy to use without any configures? Are there any necessary settings prior to using it? Have you provided a runnable environment for it?

Because of lack of JTAG, printing may be the only one method left, so debugging printascii() may be a MUST for you.

Thanks.

Answer 2

Most probably you have a memory translation configuration issue. After turning on the MMU, the serial device must be accessed using a virtual address that has been mapped to the original hardware address (that you were using previously.)

To debug your problem, you need to make sure that you have set up the correct virtual address and that the memory mapping configuration is that of a device. Generally devices memory mapping is done statically so if you can't see what is wrong in the source file you should also be able to output the values just before the call to __enable_mmu .