This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

66AK2G12: ARM Kernel booting issue

Part Number: 66AK2G12

Tool/software:

Hello,

I have created a new board using the 66AK2G12, but I'm encountering some issues and would like to ask for your help.

I'm booting the DSP using a micro SD card. The following message appears in the terminal window during the process. The same micro SD card works fine on another board.

U-Boot runs correctly, but there seems to be a problem when starting the kernel.

When I connect an emulator to the DSP and download and run the DSP binary, everything works fine.

It seems like there might be an issue on the ARM side. Could this be a problem with the 66ak2g12 hardware?

  • Hi Park,

    It seems like there might be an issue on the ARM side. Could this be a problem with the 66ak2g12 hardware?

    It looks like the UART is trying to output something during Kernel startup/operation so I'd perhaps try to start debugging from there. Some thoughts here...

    • Do the "garbage characters" stop like you show in the screenshot? Or continue for some more time?
    • Do the "garbage characters" always look the same for every boot?
    • Can you connect a logic analyzer to the UART TX pin close to the SoC, and analyze the waveforms? Perhaps it's transmitting at a different baud rate for some reason? (different clock setup due to board differences, or some type of failure or anomaly triggered during kernel startup)
    • When you connect to the ARM core, can you see the kernel is running? Or is it crashed/halted?

    Regards, Andreas

  • Thank you for your response. I will review the points you mentioned.
    The kernel is running. The main functions of the ARM—Ethernet communication, DSP booting, and SRAM access—are all working properly.
    After the kernel starts, only garbage values appear on the terminal, but the intended functionalities are operating as expected.

  • The root cause of the issue was the boot mode configuration. The problem occurred because the REF clock in the MMCSD boot mode configuration was not set correctly for the board. Thank you for your interest and assistance.