Re: debugging

[Ryan]

Hi Felipe,

On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi  wrote:
>
> Hi,
>
> (please avoid top-posting)
>
> Ryan  writes:
>> Hi Tony,
>>
>> Thanks for your response. I dont see any prints. I suspect that it
>> might be hanging before the serial port is initialized
>>
>> All i see is after arch_reset is called. I can see that is mmc clk and
>> data signals toggling. This makes me think that boot rom has loaded
>> the xloader into sram.
>
> you might wanna consider openocd if your jtag interface is available
> somewhere on your pcb. Just keep in mind that you might have to fiddle a
> bit with some TCL config files to get openocd to behave correctly with
> your board.
>

I managed to connect a lauterbach debugger. to my target. This is what
i did to test

1. reset the board.  & stop at u-boot prompt
2. Do a system.attach on the T32 (Lauterbach says that system is ready)
3. I do a run on the T32. I see that the status changes on T32 to run.
4. Now, i try to play with the u-boot prompt and board does not respond.

Any idea what i am doing wrong? The PC is pointing to some address
0x28000 and does not change.
I expect the PC to be some address in the RAM since mmu is off.

Also, do i need to compile the x-loader and u-boot with some special
options & how do i tell the T32 to
pick the map file for x-loader and u-boot?

Thanks you,
ryan





> cheers
>
>> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>>> * Ryan  [151209 09:03]:
 Hello,

 On a custom 4460 board. The x-loader hangs at some place when we
 reboot. This happens occasionally on an android port by linaro.

 I just want to find out how to debug in this case. How can i get to
 know where the hang takes place. After boot rom, i can see the mmc clk
 toggling
 indicating that xloader is in sram when the hang takes place and not
 sure where the hang is.

 Do i need Lauterbach to debug - Is it possible to connect the emulator
 across reboot. If so, how? or is there any other way i can debug this

 Also, i want to check - If i can turn off the dplls? If so, how?

 I tried to do a disable on all the clocks in the clock list using
 clk_disable call just before reboot and that does not seem to help.
>>>
>>> You can add selected serial print statements very early into u-boot
>>> MLO (and probably x-loader). You need to keep them down to minimum
>>> so the image still fits into SRAM. If you enable debug, then that also
>>> needs to be limited to selected files only as enabling debug for the
>>> whole MLO/x-loader in the Makefile will make it too big.
>>>
>>> Regards,
>>>
>>> Tony
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging

[Felipe Balbi]

Hi,

Ryan  writes:
> Hi Felipe,
>
> On Thu, Dec 10, 2015 at 3:17 AM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> (please avoid top-posting)
>>
>> Ryan  writes:
>>> Hi Tony,
>>>
>>> Thanks for your response. I dont see any prints. I suspect that it
>>> might be hanging before the serial port is initialized
>>>
>>> All i see is after arch_reset is called. I can see that is mmc clk and
>>> data signals toggling. This makes me think that boot rom has loaded
>>> the xloader into sram.
>>
>> you might wanna consider openocd if your jtag interface is available
>> somewhere on your pcb. Just keep in mind that you might have to fiddle a
>> bit with some TCL config files to get openocd to behave correctly with
>> your board.
>>
>
> I managed to connect a lauterbach debugger. to my target. This is what
> i did to test
>
> 1. reset the board.  & stop at u-boot prompt
> 2. Do a system.attach on the T32 (Lauterbach says that system is ready)
> 3. I do a run on the T32. I see that the status changes on T32 to run.
> 4. Now, i try to play with the u-boot prompt and board does not
> respond.

is CPU, perhaps, halted ?

> Any idea what i am doing wrong? The PC is pointing to some address
> 0x28000 and does not change.

yeah, it's halted. I don't know much about T32, you might wanna read its
documentation, though.

> I expect the PC to be some address in the RAM since mmu is off.
>
> Also, do i need to compile the x-loader and u-boot with some special
> options & how do i tell the T32 to pick the map file for x-loader and
> u-boot?

yeah, you gotta read T32's documentation. I can't help there :-p

-- 
balbi


signature.asc
Description: PGP signature

Re: debugging

[Ryan]

Hi Tony,

Thanks for your response. I dont see any prints. I suspect that it
might be hanging before the serial port is initialized
All i see is after arch_reset is called. I can see that is mmc clk and
data signals toggling. This makes me think that
 boot rom has loaded the xloader into sram.

Thanks,



On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
> * Ryan  [151209 09:03]:
>> Hello,
>>
>> On a custom 4460 board. The x-loader hangs at some place when we
>> reboot. This happens occasionally on an android port by linaro.
>>
>> I just want to find out how to debug in this case. How can i get to
>> know where the hang takes place. After boot rom, i can see the mmc clk
>> toggling
>> indicating that xloader is in sram when the hang takes place and not
>> sure where the hang is.
>>
>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>> across reboot. If so, how? or is there any other way i can debug this
>>
>> Also, i want to check - If i can turn off the dplls? If so, how?
>>
>> I tried to do a disable on all the clocks in the clock list using
>> clk_disable call just before reboot and that does not seem to help.
>
> You can add selected serial print statements very early into u-boot
> MLO (and probably x-loader). You need to keep them down to minimum
> so the image still fits into SRAM. If you enable debug, then that also
> needs to be limited to selected files only as enabling debug for the
> whole MLO/x-loader in the Makefile will make it too big.
>
> Regards,
>
> Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging

[Felipe Balbi]

Hi,

(please avoid top-posting)

Ryan  writes:
> Hi Tony,
>
> Thanks for your response. I dont see any prints. I suspect that it
> might be hanging before the serial port is initialized
>
> All i see is after arch_reset is called. I can see that is mmc clk and
> data signals toggling. This makes me think that boot rom has loaded
> the xloader into sram.

you might wanna consider openocd if your jtag interface is available
somewhere on your pcb. Just keep in mind that you might have to fiddle a
bit with some TCL config files to get openocd to behave correctly with
your board.

cheers

> On Thu, Dec 10, 2015 at 1:44 AM, Tony Lindgren  wrote:
>> * Ryan  [151209 09:03]:
>>> Hello,
>>>
>>> On a custom 4460 board. The x-loader hangs at some place when we
>>> reboot. This happens occasionally on an android port by linaro.
>>>
>>> I just want to find out how to debug in this case. How can i get to
>>> know where the hang takes place. After boot rom, i can see the mmc clk
>>> toggling
>>> indicating that xloader is in sram when the hang takes place and not
>>> sure where the hang is.
>>>
>>> Do i need Lauterbach to debug - Is it possible to connect the emulator
>>> across reboot. If so, how? or is there any other way i can debug this
>>>
>>> Also, i want to check - If i can turn off the dplls? If so, how?
>>>
>>> I tried to do a disable on all the clocks in the clock list using
>>> clk_disable call just before reboot and that does not seem to help.
>>
>> You can add selected serial print statements very early into u-boot
>> MLO (and probably x-loader). You need to keep them down to minimum
>> so the image still fits into SRAM. If you enable debug, then that also
>> needs to be limited to selected files only as enabling debug for the
>> whole MLO/x-loader in the Makefile will make it too big.
>>
>> Regards,
>>
>> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: PGP signature

Re: debugging

[Tony Lindgren]

* Ryan  [151209 09:03]:
> Hello,
> 
> On a custom 4460 board. The x-loader hangs at some place when we
> reboot. This happens occasionally on an android port by linaro.
> 
> I just want to find out how to debug in this case. How can i get to
> know where the hang takes place. After boot rom, i can see the mmc clk
> toggling
> indicating that xloader is in sram when the hang takes place and not
> sure where the hang is.
> 
> Do i need Lauterbach to debug - Is it possible to connect the emulator
> across reboot. If so, how? or is there any other way i can debug this
> 
> Also, i want to check - If i can turn off the dplls? If so, how?
> 
> I tried to do a disable on all the clocks in the clock list using
> clk_disable call just before reboot and that does not seem to help.

You can add selected serial print statements very early into u-boot
MLO (and probably x-loader). You need to keep them down to minimum
so the image still fits into SRAM. If you enable debug, then that also
needs to be limited to selected files only as enabling debug for the
whole MLO/x-loader in the Makefile will make it too big.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: debugging options (was: Re: [PATCH 1/6] ARM: OMAP2+: Remove board-4430sdp.c)

[Russell King - ARM Linux]

Apologies for the topic hijack.

On Sat, Jul 06, 2013 at 11:36:48PM +0200, Arnd Bergmann wrote:
 Sorry, I missed that this was going on, and I absolutely agree with your
 sentiment. From what I can tell from the git log, Tegra was the first
 to have the separate choice statement, after it just move its
 options from mach-tegra/Kconfig into the Kconfig.debug. OMAP followed
 with the same method and I think from there people just copied it.
 
 I can understand why one wants to have some more structure in the list,
 given that i.MX alone has 37 options for UART addresses, but we first
 need to have a consistent method of configuring the addresses.

I don't have an option with an option after the choice or a set of
options afterwards asking for details about the selected option -
that is logical.

For example, if we were to reduce the 8250-uart based stuff down to
a single 8250-compatible uart option, and then ask for the address,
register shift and register access size.

... and of course by this time I now have a patch set which does
exactly that... and it can do more by getting rid of that 8250_32.S
file as well with another config option.  The patch below tries
hard not to break anything or lose information as to the details of
the 8250 UART in any platform which they're already known to the
kernel, but they can be trivially overridden.  Eventually (maybe
tomorrow), I expect a load of the choice config statements in
arch/arm/Kconfig.debug to go away, replaced just with a generic
Kernel low-level debugging messages via 8250 UART option.

 arch/arm/Kconfig.debug |   92 ++--
 arch/arm/include/asm/hardware/debug-8250.S |   29 --
 arch/arm/include/debug/8250.S  |   36 
 arch/arm/include/debug/mvebu.S |   30 ---
 arch/arm/include/debug/nspire.S|9 +--
 arch/arm/include/debug/pxa.S   |   33 ---
 arch/arm/include/debug/rockchip.S  |   42 -
 arch/arm/include/debug/sunxi.S |   27 --
 arch/arm/mach-dove/include/mach/debug-macro.S  |   19 
 arch/arm/mach-ebsa110/include/mach/debug-macro.S   |   22 -
 .../arm/mach-footbridge/include/mach/debug-macro.S |   15 ---
 arch/arm/mach-gemini/include/mach/debug-macro.S|   21 -
 arch/arm/mach-iop13xx/include/mach/debug-macro.S   |   24 -
 arch/arm/mach-iop32x/include/mach/debug-macro.S|   21 -
 arch/arm/mach-iop33x/include/mach/debug-macro.S|   22 -
 arch/arm/mach-ixp4xx/include/mach/debug-macro.S|   26 --
 arch/arm/mach-kirkwood/include/mach/debug-macro.S  |   19 
 arch/arm/mach-lpc32xx/include/mach/debug-macro.S   |   29 --
 arch/arm/mach-mv78xx0/include/mach/debug-macro.S   |   19 
 arch/arm/mach-orion5x/include/mach/debug-macro.S   |   21 -
 arch/arm/mach-rpc/include/mach/debug-macro.S   |   23 -
 21 files changed, 121 insertions(+), 458 deletions(-)
 delete mode 100644 arch/arm/include/asm/hardware/debug-8250.S
 create mode 100644 arch/arm/include/debug/8250.S
 delete mode 100644 arch/arm/include/debug/mvebu.S
 delete mode 100644 arch/arm/include/debug/pxa.S
 delete mode 100644 arch/arm/include/debug/rockchip.S
 delete mode 100644 arch/arm/include/debug/sunxi.S
 delete mode 100644 arch/arm/mach-dove/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ebsa110/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-gemini/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop13xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop32x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-iop33x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-ixp4xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-kirkwood/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-lpc32xx/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-mv78xx0/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-orion5x/include/mach/debug-macro.S
 delete mode 100644 arch/arm/mach-rpc/include/mach/debug-macro.S

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html