AM3359 stopped at Uncompressing Linux... done, booting the kernel.

Hi,

I'm just guessing here, but perhaps you have some DDR issues in your HW version 1.1? The kernel is loaded into RAM and when the time comes to start executing, something fails.

I'll try to involve a hardware engineer to share his thoughts on the subject.

Please check the PSP documentation section of the Sitara Linux Software Developer's Guide and compare the differences between the working PSP release and the non-working PSP releases. Knowing the differences in your two hardware design versions, perhaps this can point you in the right direction.

Best regards,
Miroslav

Hi,

    Thanks for your reply.

     We've tested external mem in u-boot with the command "mtest", and can't found any errors

    "we use psp04.06.00.08, added the changes for our board, both HW V1.0 and HW V1.1 can setup linux kernel", it seems the HW can work correctly

Hi,

Even if it is a software issue, it is most probably unlocked by your hardware differences. What are the differences between HW v.1.0 and HW v.1.1?

I would suggest you to read these two articles about the arm linux boot sequence:

http://amitshah.bizhat.com/arm/arm_linux_boot-1.html
http://gicl.cs.drexel.edu/people/sevy/linux/ARM_Linux_boot_sequence.html

As far as I understand from your logs, your system hangs somewhere between the completion of the decompress_linux() and the beginning of start_kernel() functions.

Best regards,
Miroslav

Hi,

    Thanks for your reply.

    The differences between HW v.1.0 and HW v.1.1 is the RTC clock, HW V1.0 direct use an external crystal oscillator clock to provide 3359; while HW V1.1 using the power management chip 65910 to provide the clock to 3359

    Kernel pre-print can be opened by macro CONFIG_DEBUG_LL,We opened the macro, but it does not seem to take effect, what other changes need to work together to open the kernel pre-printing feature?

Hi,

After open macro CONFIG_DEBUG_LL successfully, We can see how kernel working through fun early_print(),.

Then we found that there are something different when the kernel processed in start_kernel()->rest_init()->schedule().

schedule() operated normally with HW1.0 , schedule() could not get out with HW1.1

here are the changes we make in rest_init(void):

the normal LOG in HW V1.0

and the error LOG in HW V1.1

Was this issue ever resolved? I am experiencing a completely identical boot problem (getting no early_print statements after schedule()). The board I am using also does not have a 32K crystal connected... Just wondering if there was a solution you found to this or someone else.

I found this problem is caused by the RTC_PORZ pin being grounded. This pin is recommended to be grounded by TI when not using the RTC module, so why would this cause booting issues?

Any ideas anybody?

Hi,

I have identical problem, Was this issue resolved ? Any explanation about this topic ? 

Thanks,

Ran