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).
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.
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 ?
I wonder why there's a 15 minute limit. It will take most people more than 15 minutes, before someone will notice and suggest a change.
-If you ask me, there should be no limit at all.
-But the document is great nevertheless; packed with information on the topic.
Thanks for the compliment but I had made an omission and that otherwise "excellent" document: the OP can only mark or unmark the discussion as a question within 15 minutes of its creation... However, cause I thought it's what you wanted, I have made the change for you... and I have updated the document!
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
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.
The good thing about the ARM Connected Community, is that "nothing is final". You can edit everything you've posted earlier - even delete posts.
Try having a look at this excellent post, in particular: "3. How can I change a discussion to a question?".
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.
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 ...
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.
(Is there a way to give credits, or something?)
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).
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".
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.
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.
Try this: https://github.com/adamgreen/mri
This is only for lpc17xx over serial but is fully adaptable for any processor/interface
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.
View all questions in Embedded forum