[U-Boot-Users] Q) Anyone know how to debug u-boot on AT91SMA9263-EK using J-Link from Segger?
Does anyone have a recipe for debugging u-boot on AT91SAM9263-EK target?
Our proprietary board is very similar, but can't see what goes wrong. Atmel has a bootstrap that inits SDRAM, and loads u-boot image from Flash device into SDRAM. It jumps to the proper address in the SDRAM and dies.
All we have to debug is J-Link from Segger along gdbserver from Segger which is an application that runs on Windows and talks via Usb to the J-Link Pod. We can talk to Windows as if it were gdbserver from a Linux host.
The bootup sequence provided by Atmel looks different from u-boot in that u-boot does not move itself into SDRAM, this is done by the Atmel bootstrap.
Don't know how to init SDRAM from J-Link. Has anyone done that?
--jlf
I am using BDI2000 with my at91rm9200 board - I think, you can do the same for at91rm9263 unless you doesn't get JTAG on your board. I can step through code, etc...
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Jeff Franks Sent: Sunday, September 30, 2007 12:33 PM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] Q) Anyone know how to debug u-boot on AT91SMA9263-EK using J-Link from Segger?
Does anyone have a recipe for debugging u-boot on AT91SAM9263-EK target?
Our proprietary board is very similar, but can't see what goes wrong. Atmel has a bootstrap that inits SDRAM, and loads u-boot image from Flash device into SDRAM. It jumps to the proper address in the SDRAM and dies.
All we have to debug is J-Link from Segger along gdbserver from Segger which is an application that runs on Windows and talks via Usb to the J-Link Pod. We can talk to Windows as if it were gdbserver from a Linux host.
The bootup sequence provided by Atmel looks different from u-boot in that u-boot does not move itself into SDRAM, this is done by the Atmel bootstrap.
Don't know how to init SDRAM from J-Link. Has anyone done that?
--jlf
------------------------------------------------------------------------ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Hello!
Leonid schrieb:
I am using BDI2000 with my at91rm9200 board - I think, you can do the same for at91rm9263 unless you doesn't get JTAG on your board. I can step through code, etc...
And I am using a Lauterbach ICD for such purposes without any major problem. I can't see a reason why there should be a problem AFTER reading the documentation.
In my eyes it doesn't make any sense to use a tool like a JTAG debugger without understanding how the systems works. So if you get initialization scripts from someone else and don't understand them you also won't understand how to debug your bootloader(s). In many cases you won't be able to find all bugs when just stepping through the code on C language level. But if you understand how the processor works you won't need anybody else providing you with further information/files.
Why do so many people think that mailing lists like this are a total replacement for RTFM?
With best regards Andreas Schweigstill
Andreas Schweigstill wrote:
Hello!
Leonid schrieb:
I am using BDI2000 with my at91rm9200 board - I think, you can do the same for at91rm9263 unless you doesn't get JTAG on your board. I can step through code, etc...
And I am using a Lauterbach ICD for such purposes without any major problem. I can't see a reason why there should be a problem AFTER reading the documentation.
In my eyes it doesn't make any sense to use a tool like a JTAG debugger without understanding how the systems works. So if you get initialization scripts from someone else and don't understand them you also won't understand how to debug your bootloader(s). In many cases you won't be able to find all bugs when just stepping through the code on C language level. But if you understand how the processor works you won't need anybody else providing you with further information/files.
Why do so many people think that mailing lists like this are a total replacement for RTFM?
With best regards Andreas Schweigstill
Many of the docs are for a Windows Yagarto environment or using BDI2000 directly from a Linux cross-dev machine. Everything works seemlessly for the in-the-box solution. However, there are no docs that tell how to setup a mixed Linux/Windows development environment whereby Windows provides the back-end remote gdb-server to the Linux cross-development host machine. Missing one detail like not having Zylin CDT installed in Eclipse, or having an Insight debugger that is not compatible with the cross-dev environment can cause havoc.
I view mailing lists as a tool to reap the collective experience for cases that go "outside-the-box" and are an adjunct to trying to resolve issues after many docs have been read and digested, which is what I did. In my case I wanted to find out why u-boot was failing to run after being loaded into SDRAM. I'm finally able to accomplish this with the tools that I have.
Sincerely, Jeffrey Franks
participants (3)
-
Andreas Schweigstill -
Jeff Franks -
Leonid