How to debug Linux kernel Boot process after __turn_mmu_on stage?

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

Answering this because I ran into the same problem: Kernel hangs early in the boot process, but past MMU on. In my case I am debugging an arm64 phone by rebooting it (solution should apply to arm32 as well), but the problem is the same: can't access registers because they are not mapped. I've tried mapping it but it didn't work out properly.

My solution was this:

There's a section of code in the kernel that's identity mapped, meaning virtual address = physical address This is needed for turning the MMU on/off, otherwise the code running would suddenly be inaccessible. After the MMU is on, I can turn it off in that part of the code, then write what I want to my registers (then do an infinite loop of nothing).

I've made it so that after the MMU is on, and the kernel jumps to MMU mapped virtual address, I can return back to identity mapped territory where the LR points straight to my MMU off and reboot code. This works all the way up until the arm64 code disables id mapping in my case, but from that point on, early_ioremap works fine!

Hope this helps anyone trying to debug some board/phone/anything without access to JTAG/SWD (in my case, because it's a retail phone with it disabled)

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.

Answer 3

-

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.