• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 97 subscribers
  • Views 774 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Sync Kernel debug. Pre- init_machine() code -- how? (AM335x Linux psp)

sviss
Expert 1530 points

Hi hardware guys.

How do you debug the kernel code executed before the machine is initialized : before init_machine() is called?

The case:

I see on my board that one of the GPIO's state change. (this is GPIO0_6, to be specific).

To my understanding, this is strange : I expect all the periferal devices' state is preserved from the U-boot set values.

I added a LED blinking code, to the init_machine() /alias of am335x_evm_init() from the SK support code/ , and using oscilloscope found that GPIO state changes some ~40 milliseconds *BEFORE* the  init_machine() is entered.

I want to find out why is it happening but no LED blinking (GPIO conrol) code works there, in the code above init_machine() /maybe pinmuxing is destroyed?/, nor a printk() helps because it is asynchronous: printout goes to the memory, not to the UART, and therefore I cannot trace that 40ms interval. Not even a mdelay()/udelay() methods seem to be functional in certain places of the kernel init code.

So, please kindly share your ideas/knowledge on how to get a bit of information, synchronously (anything better than memory printing with the printk), for hardware debug, from the code executed in the main.c at kernel_init() and around, before the board is initialized, and after the decompress_kernel() / kernel start.

Thanks.

  • 0
    Expert 1530 points

    Aha, obviously this is the case when kernel debugger might be an option.

    (TI Sitara_Linux_Training_Uboot_linux_debug_with_CCSv5 document)

    Or somebody could suggest anything better?

    The case is that setting breakpoints in the kernel is too heavy process (especially if using that slow XDS100 JTAG) and lacks real-time debug facility: not so easy to do oscilloscope-aided timing analysis. Whereas this possible in the code before kernel_decompress() I was curious to know if the like something exists, good for the code before the board initialization is called.

    Also the hope was to have a confirmation from somebody that after U-boot passes control to the kernel but before init_machine() is called there is a code which could spoil GPIO hardware settings. (I mean the EVM/SK support code which I still use as a template).

  • 0 in reply to sviss
    Expert 1530 points

    (sorry for persistence)

    JTAG debugging is very slow (well known fact), debugging of multithreaded routine (like kernel) is a thing.

    To do kernel debug using JTAG one needs to have the more breakpoints the better.

     

    How many hardware breakpoints the Sitara am335x processors supports? What is the difference, from the hardware point of view, between hard and soft breakpoint (CCS5)?

    What is the watchpoint? Where can I find the details on all that? (datasheet, TRM, nor search did not help)

    Could please somebody suggest?

    Thanks!