Has anyone encountered a standalone gdb server? That is gdb server that runs on a bare metal.
I've been looking for sources to build one. Doesn't need to be ARM, but that might help.
Maybe someone has come across a document explaining how gdb server really works?
(It might help in reading the 'standard' gdb server code.)
I understand that 'stub' means "gdb server" linked into the executable, but I'd like to have a server with which I could upload programs onto the board for debugging through the network or serial IF.
My main concern is attaching to the program to be debugged, when there is no OS (and no processes).
I like the expression "Simple is good".
If breaking the "bootloader" up into smaller pieces, I think each piece is not extremely complicated:
1: Bootloader.
Must read an ihex file (intel-hex) - I've made a script that wrote ihex; parsing ihex isn't complicated.
Must decode the ihex and write binary blocks to RAM (temporarily) and when ready, write to flash-memory (if necessary).
2: Debug facilities; a few handlers that would be required in order to access memory...
Read an 8-bit word
Read a 16-bit word
Read a 32-bit word
Write an 8-bit word
Write a 16-bit word
Write a 32-bit word
3: Communication.
Serial interface; should not be too complicated to implement, if you have the peripheral addresses
Use an interrupt for reading and parsing commands.
4: Exception vectors.
Should install all vectors and point to the same handler, before executing the program.
There might be some trouble here, because the program being debugged has its own exception vectors, and if they overwrite the debugger's exception vectors, there's no way for the debugger to be triggered.
5: (Anything I forgot to mention)
Basically, it would be to implement the stub on top of a bootloader.
Writing the bootloader would probably be the hardest part of it (the part where you find a good place to store the temporary data and where you write to the flash memory).
-You could probably take a look at RedBoot and disable Ethernet, in order to quickly hack it into position... That way you'd only need to focus on a serial interface.
... You could use the "Vetle" method: "If it fails to compile, delete it".
Stub in boot loader is OK, stub in program to be debugged is not.
About the compatibility: it's the other HW that I'm more concerned, not the core.
RPi 2 B has 4 cores, and that must make some effect on the interrupt controller etc.
Since RPi HW is not "abundantly documented" it'll take some time to figure out stuff.
Since the Raspberry Pi 2 is fairly new, the Linux sources for it might be one of the best sources on how the hardware works.
Reading "driver source code" is unfortunately not the ideal way of finding out how to accomplish a goal, but sometimes it might be the quickest way.
I do not know where to obtain the source, though. Most of the information you need, is related directly to the processors, so if you can get the processor's User's Manual and datasheet, it would probably be all the documentation you'd need.
Unfortunately, not all companies are willing to give the datasheets to developers, some require NDAs, others think that some companies are too small.
I have not tried too but normally it's using U-Boot .
Many Git exists depending on the platform . But we must have a track here
http://www.denx.de/wiki/U-Boot/Custodians
Good find!
As far as I understand, U-Boot allows you to load the program via Ethernet and remote-debug it; but does it need an operating system in order to work, or does it act fully as a bootloader and remote debugger ?
you'll have to load it an image kernel. a small rootfs with some binary but not necessarly the full os.
I don't try it like that, but small kernel image can be found who are using lowest memory.