Debug on the raspberry pi for Baking pi

4 posts
by Ekami » Tue Aug 20, 2013 1:50 am
I currently learning assembly language through the Baking pi tutorials.
But until now I use the "hard way kernel testing" which consist of taking off my SD card from
my pi, putting it into the laptop and vice versa.
I would like to know if there is a way to avoid it and instead, transfers my kernel.img
through serial transfers (but I'm a real n00b and I dunno how it really works actually).
Also , I would like to be able to debug my assembly code because I'm, for now,
blind of what really happen onto my pi.
Is there any tutorial on how to setup serial+debugger for kernel dev?
Thank you.
Posts: 11
Joined: Fri Jan 04, 2013 1:01 pm
by ambivalent » Tue Aug 20, 2013 1:54 pm
I believe dwelch implemented a bootloader using uart
Posts: 18
Joined: Mon Jun 10, 2013 6:16 pm
by tgritchie » Wed Aug 21, 2013 11:48 am
Hello - I, too, experienced mechanical problems with my SD card from all those swappings in and out while developing my bare metal projects and have used the serial bootloader approach of David Welch. This method does, however, require some external hardware to interface to the COM port of your host computer so might not be easy for someone who is not confident in the soldering arts :( Now, though, thanks the NOOBS boot system and an Ethernet connection on both host and Raspi I don't need the serial port to transfer .img files from the host to the Raspi. I start with a standard boot into a Linux command line and then by knowing the IP address of the Raspi, use sftp on the host to send any .img files I want to test to the home directory of the Raspi. I then copy these to the /boot directory and restart the Raspi. On this restart I interrupt the boot by holding the Shift key and edit the config.txt file as required for the .img file I want to run (in place of Linux) on the next boot. This would most often only involve a change to the .img file that is loaded by the startup code. The next restart will then run the code I am testing. If it all collapses in a heap I repeat the process but return to Linux. This works but is a bit long-winded and of course more often than not the code under test doesn't work so, normally, I use a combination of this sequence and debugging through the serial port. This is done by replacing Linux with a GDB remote stub program image and using the ARM debugger (arm-none-eabi-gdb) in remote mode from the host to download, run and debug code under development. And not a single SD card has been harmed in the entire process :D
Posts: 18
Joined: Fri Jun 01, 2012 4:07 pm
Location: United Kingdom
by Ekami » Wed Aug 21, 2013 5:45 pm
Thanks a lot for your answers.
tgritchie, your method is of course more handy than what I use to use but this
time I'll lose time during each startup process of linux.
Nevermind, I'll try it, thanks again.
Posts: 11
Joined: Fri Jan 04, 2013 1:01 pm