Hi,
I am planning to do debug the u-boot code which is running on target, with out using JTAG connection.
I mean to use the gdb on host pc to connect with remote target through serial / usb communication.
Please guide me, how can I approach…
I saw there was one source branch to support qemu and gdb agent functionality for virtual emulator and there is no actual target connectivity, complete testing on VM device.
Please let me know your views and inputs…
Cheers
Hi,
As continuation, I am trying to bring gdb server commands on u-boot.
One basic clarification, Currently u-boot is single process thread, can anyone tell me why it is limited to run on single process thread flow.
For simplicity… avoiding interrupts, threads and SMP makes the bootloader easier to understand and easier to debug.
Thanks for your response Daniel.
I am planning to do debug of a standalone application which is loaded and run through u-boot, expectation is to do debug without using JTAG, and through serial connectivity b/w target and host.
I initially thought to bring gbd server application loaded from u-boot and then load the actual test application from host machine through gdb connectivity either serially or through TCP/IP, since both peripherals are readily usable from u-boot. But the problem is with gdb server code currently works based on kernel based methods.
Do you know any other approaches or the better way to debug the standalone applications which are loaded using u-boot.
One more doubt, some times the u-boot is getting crashed due to the issue with loaded applications, my expectation is to return the error information and come back to command line interface. To do this support, I removed the while (1) logic in panic() method, and allowed to leave from exception, but still it is not going back to command line interface. let me know how to come back to CLI from this scenario
Cheers
Are you writing a u-boot standalone application (UBootStandalone < DULG < DENX ) or a fully standalone application (e.g. one that is independent of u-boot console, interrupt and memory management)?
For the former it might be possible to add a gdb remote stub to u-boot but for the later the gdb remote stub would have to be added to your application (or to the RTOS your application is linked to).
To be honest though, in both cases I would be reluctant to implement the debug stubs until I needed them (e.g. I was faced with a problem that UART logging it not very helpful for resolving). For early work I would rely on UART logging.
@danielt, Yes I am writing standalone applications out of u-boot console. Exceptions and memory management of u-boot will be utilized as a super set for my standalone application, some times it will be entire new set by the application.
Yes, I agree with you, once gdb remote stub is triggered from u-boot, gdb remote stub could eventually load the actual application by interacting with gdb host by connecting either through serial or TCP/IP.
@danielt, any suggestions to come back to CLI of u-boot from exceptions. I got synchronous abort exception when I try to give the following command “go 0x80080000”. I want to display error message from exception routine, and return back to CLI.
Personally I would automate the reset sequence (with a relay+pexpect or similar) so I can update my application from host machine and and not need to go back to the CLI on failure!
In terms of debugging the synchronous abort you can probably do a git grep across the u-boot sources to find out what code prints this message and enrich the exception message as you need.
@danielt, it means you are planning to reset the entire system at this situation and it will comes to cli post initialization.
I did that analysis to identify that exception and provided my own print message.
Cheers
@danielt, it means you are planning to reset the entire system at this situation and it will comes to cli post initialization.
Pretty much, yes. I would also automate any actions after the reset so
that the application is automatically reloaded each compile cycle
(so make && bootit.sh on the host is sufficient to restart the
application).
