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).
Would OpenOCD by any chance be what you're looking for ?
-If it is, I recommend cloning the sources from the official git repository.
I can provide you with some quick build instructions, just let me know.
I think not - OpenOCD also runs on host (and wants an OS around), and is used for "HW debugging" (=jtag, j-link, ...).
What I'm after is like gdb stub, but separate standalone program not linked into the program to be debugged.
I have a Linux machine as host and a bare metal ARM-board (Raspberry Pi) as a target. I don't have a jtag pod
(or anything for that function).
Sadly I'm no expert in this area, but here's my thoughts ... Perhaps you've already been thinking about these things.
If I understand it correctly now, it's more like a "remote debugger" you're looking for; eg. a "thin debugger" so to speak ?
-But if you're going to "run a program" on the target board, I believe you would need one of these 3...
1: An operating system
2: To link your program with a 'debugger library' (the 'stub' you mentioned)
3: A bootloader, which is also the 'thin debugger'
I expect that you're interested in something like #3 ?
(I do not know if the RasPi has a built-in bootloader, which allows simple debugging; some Cortex-M devices are 'born' with a bootloader that has a few extra features. If the RasPi has such a bootloader, already, you'd only need to write a small program on your host, which interfaces with GDB).
Although you're not looking for OpenOCD, I would still advice to ask this question on the OpenOCD developer mailing list, because many of the people there are experts; they work with ARM architectures and also know the inner workings of OpenOCD; which is a GDB server. There's a slim chance that someone could have tried something similar already.
Yes, I'm after the option #3.
RasPi has a bootloader, but it's for the GPU. The GPU reads in the boot code for the ARM, and it doesn't include any debugging facilities. That code basically initializes the ARM-side and reads in the kernel from the memory card. To boot your own SW, you just generate a binary image and put it onto the memory card as 'kernel.img'.
Asking from OpenOCD-guys is a good idea.
Have a look at the Black Magic Probe
http://www.blacksphere.co.nz/main/blackmagic
blacksphere/blackmagic · GitHub
This seem to require JTAG or SWD, turboscrew is looking for a gdb remote debugger, which does not require JTAG or SWD.
It does not seem like it's easy to find such a bootloader, though.
Liviu Ionescu replied to my query on the OpenOCD mailing list ... I asked for a lightweight GDB remote server.
"RedBoot also includes a GDB server, accessible via Ethernet and serial, but I don't know if it qualifies as 'Lightweight'."
I think that RedBoot might sound interesting ?
For jtag (or j-link) I've used CoIde with STM3240G-EVAL. Very easy to set up and use.
Didn't quite get OpenOCD to work properly. It worked partially (I think - don't remember very well), but had to switch to CoIde.
Now the idea is to debug a bare metal program on a board (Raspberry Pi 2 B) with only serial port.r
I don't have jtag (or the like) pod, and now the only way is to compile a program on one computer, move it to another computer (without the development environment, but has a card reader), write the program onto the SD-card, take the memory and put it in RPi and boot. If it fails (how should I know?), have to do that all over.
Tedious + not good for the SD-card - or RPi memory card slot.
I'd rather have a dbg server on the SD-card so I could upload the program onto the chip and debug - and keep the SD-card in place. (That's why gdb stub is not very good solution either, although it would at least allow debugging).
I follow you completely now.
If you can build RedBoot and place it on the SD card, then I think it would allow you to upload the program via either serial interface or Ethernet.
Try this: https://github.com/adamgreen/mri
This is only for lpc17xx over serial but is fully adaptable for any processor/interface
Ah darn: it looks like a gdb stub:
Please Note: This project just contains the sources to build the MRI debug monitor library but doesn't show how to link it into your program and make use of it. Such an example is provided by the GCC4MBED project.
RedBoot looks very promising. Just have to check what this really means:
As RedBoot is based on the eCos operating system, it is easy to port RedBoot to any system to which eCos has been ported.
RPi 2 B has Cortex v7 A. I wonder if Cortex M is close enough for porting with moderate effort.
(I think Cortex M is the closest architecture that eCos has been ported to.)
Anyway, looks like the best candidate this far.
(Is there a way to give credits, or something?)
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".
On my CubieBoard2, which is Cortex-A7, I sometimes write Cortex-M0 assembly code, in order to test it without waiting for too long.
Cortex-M0 instructions can be run directly on the Cortex-A7; I even think the instruction set is binary compatible (upwards of course).
What's not compatible are the exception vectors and the peripherals.
That means: Ethernet, SPI and U(S)ART hardware would require some work.
-But I would expect that someone, somewhere would have written header files for your Raspberry Pi board.
You can mark the discussion as a question, then you have two "helpful answer" coins and one "correct answer" coin.
-And of course, you can click "Like" at the bottom of each reply that you like or find relevant - feel free to click "Like" anywhere you find something that you're interested in on the entire ARM Connected Community - for instance, when albanrampon posts some helpful information (for instance like FAQ, Guide, Tip, Governance - Content & Planned Outage).
Ah, yes - I wasn't logged in. Now the 'like' shows.
You can mark the discussion as a question
That must have escaped me, because I remember, when posting, as it there where two mutually exclusive options: to write a question or to write to a certain place. Now I recall seeing a check box, when I started a thread earlier.
Well, next time ...