Baremetal for Raspberry Pi

The keil MDK-ARM kit is designed for smaller microcontrollers.

Any reason you don't want to use the free gcc toolchain for the RP? What advantages do you see with trying to use MDK-ARM? The Keil tools requiers a commercial license, since it isn't meaningful to use the demo version on a RP because of the restrictions in code size.

Hi,

I only want to write small baremetal applications so the Lite version would be great. I want to learn about other development environments.

Thanks.

But the lite edition is still a commercial license that costs money. Just a bit less money than the larger license options.

The completely "free" demo version has extremely limited code size so it is probably not meaningful to use - it is only intended to test the tool and get an idea what the tool can do.

In your case, you will already be able to find complete configuration files for how to build binaries for use on the Raspberry Pi. Running a "bare metal" application on the platform is very similar to compiling the Linux kernel. Your code would be started in the same way that the Linux kernel gets started. Which also means that you can look at the Linux kernel source to see what they do to activate different hardware functions of the processor.

Hi,

Sorry sir, but I think you are wrong. The Lite version is the same as the demo version. I know it is limited but it is also free. I can make an application up to 32K which I think is plenty for a small baremetal application. Also a baremetal application is not like the Linux kernel. It is more like a bootloader. I want to learn about bootloaders and I want to talk to the chip directly.

I think that the debugger and stuff will not be able to simulate the Broadcom chip, but I want to make simple assembly and C applications and try them. I think that the Keil MDK can produce code to work with the Broadcom core.

The Linux kernel can be run "raw" or you can have a boot loader that starts it. It's just that it is normally easier to have a boot loader start the kernel since a boot loader represents a much easier solution to switch to another Linux kernel version.

You can even find variants where people have thrown out the BIOS from a PC and booting Linux directly from the BIOS flash memory.

Sir,

Sorry but I do not understand why you keep talking about using the kernel and the PC. I know what the kernel does but I do not want to do that at the moment. I want to do baremetal with my Raspberry Pi. To talk directly to the hardware with only a little code. I have found a lot of example code using GCC but I want to learn about using another development environment.

Not sure why Per would want to stop you from experimenting.

Keil isn't particularly well situated for the Raspberry Pi development work, it doesn't seem to have native support for Broadcom CPUs, good hardware/register level documentation for Broadcom or Marvell parts is not at all easy to obtain.

Do you have good JTAG/SWD connectivity to permit low level development?

Most available example source for the platform is likely to target GNU/GCC tools.

"keep talking about using the kernel and the PC" would mean I have said it multiple times. I have said it only once, as an example that the Linux kernel can be used without a boot loader.

I have never said you should use any kernel.

I did write "Your code would be started in the same way that the Linux kernel gets started. Which also means that you can look at the Linux kernel source to see what they do to activate different hardware functions of the processor."

See the difference?

And I said that when using the gcc toolchain, you can already find lots of information how to set it up to build an application for use without any boot loader.

"Not sure why Per would want to stop you from experimenting."

There isn't one single sentence in my posts where I want to stop him from experimenting. All I am questioning is his interest in using the Keil tools, instead of gcc. Do _you_ see any obvious advantage to use the Keil tools instead of gcc?

Do _you_ see any difference in me noting more samples to look at if using gcc, compared to your own suggestion that there are more samples to look at if selecting gcc?

I find that Keil, and Realview before it, had some pretty good debuggers, and I've definitely blind debugged in to hardware for which source wasn't immediately available or I had used GNU/GCC to create. I've stepped through ROMs, boot loaders, and into Linux kernels.

Many systems have staged boot processes, where a simple boot loader pulls in uBoot, bitbox, or RedBoot, which in turn brings in the kernel.

I think Keil is unsuitable for uBoot or Kernel work, but plenty adequate for boot roms or boot loaders, and in many cases 32 KB would be more that enough to do quite a bit of damage. Admittedly you're not going to fill up NAND/DDR with code, but you could log data there, and copy it to an SDCard.

I don't think Keil is a good match for the Pi, I'd probably look for something that had ready JTAG support, and open documentation. John is working with what he has, and is showing a whole bunch more wherewithal than a slew of other posters, and we should be using a tone that's commensurate with the effort to try something new in a constructive fashion.

Sir,

Sorry for my late reply but my mum told me to go to bed last night.

You said "I have said it only once". But you used the word kernel in two posts before. I told you I want to do baremetal. I did not say kernel because I do not want to do kernel at the moment. Maybe you do not really know what baremetal is.

You said "Your code would be started in the same way that the Linux kernel gets started."

But I already know that! I know all code starts at the beginning.

What I want to do with baremetal is keep it as simple as possible. I do not want to use the code that is in the kernel. I want to learn how to write it myself. I want to learn about something different. I want to get more experience of alternatives.

The kernel is big and is more complicated. I want to keep it simple. I have a Raspberry Pi. I do not have enough money to buy another development board.

I think I asked a simple question about baremetal. I want to learn about different development environments. Please understand. Why do you have to give your opinion about whether it is a good idea? I am learning in my free time. What I do doesn't cost you anything.

Thank you John Linq for starting to answer my question. Can anyone tell me more about what I asked?

-> Can anyone tell me more about what I asked?

Do you have a plan about how to program the Broadcom BCM2835 SoC?
Do you plan to store your software on the SD Card, just like NOOBS installer and Raspbian?
Do you have a plan about how to debug your software?

Both Per Westermark and Westonsupermare Pier have quite a lot of experiences on Embedded system development, tell us more, so that people can help you better.

Yes, I have used the word "kernel" in several posts. But only one post noting kernel+PC.

And in none of the posts have I said you should use a Linux kernel. I just noted that the Linux kernel can be used bare metal, which means it could be interesting to take a closer look at how that was done - and to take a peek at the kernel code for how to set up some of the hardware your own bare-metal code would also need to configure.

Don't know what bare metal is? Well, how could I not, since I have worked with embedded for a huge many years - including writing boot loaders? In fact, a huge majority of all embedded devices only have bare bone, or requires the developer to both write a boot loader and the actual application just to give the customer a way to field-update the firmware.

"But I already know that! I know all code starts at the beginning."

That is a sentence that just doesn't make sense. All code may have an entry point, and so it would be irrelevant to spend time talking about it unless you have specific issues with that. What I am talking about is the hardware setup that a bare-metal program needs to worry about - like all the oscillator settings, power configurations, memory mappings etc. Not sure if you have thought about it, but lots of low-level information are often not (!) available in a document _you_ can get access to. Which is a reason why it might be meaningful to look at the Linux kernel source to see the data structures, the register values etc.

You say you have little money. In which case gcc have advantages. The Keil tools aren't intended for the processor in the Raspberry Pi.

You may think you asked a simple question. Just don't lock yourself into believing you know what the correct answer is to that question. If you have already decided that the answer is Keil, then there wouldn't have been a need for a question in the first place, would it?

"Why do you have to give your opinion about whether it is a good idea?"

Because that follows directly from your question. You ask if you can use the Keil tools? You might be able to. But they aren't designed for that specific task - the Raspberry Pi processor is not in the list of supported processors. So a good answer then would be to tell you that the Keil tools would most probably not be a good idea to use.

"You are wrong again. I don't have any issues with it."
No, I am not wrong again, since i haven't made a claim you have any issues with it. I said that it wasn't meaningful do discuss starting point of a binary _unless_ you had any issues with it. You regularly show interesting reading "skills".

The only point I have been wrong is cost of MDK-ARM Lite - Keil doesn't show any prices for the different packages, and I might have seen a price for a package including some development board. Irrelevant to me, since I need a much larger package - both because of commercial needs and because 32kB is quickly consumed if writing in C/C++ instead of just using assembler.

"That is what I want to experiment with!"
And have you verified that you have access to all the required information to experiment with all the low level stuff? As I wrote, not all things are always documented. It is very common, when you get to "Linux class" or "PC class" processors that the documentation you will be able to find will lack huge amounts of information that are required to make use of the chip. In some situations, the chip manufacturer (or a company they have hired) have "leaked" lots of that information in the Linux low-level driver code.

Lots of microcontrollers are intened for general use. So there are lots of good documentation because the processor will be used in tens of thousands of projects and the support engineers don't want to spend the time having to involve themselves in every project.

But the "Linux class" processors are often so complex that it isn't economical to try to produce a full documentation for them, in a way that can be released to the public.

Broadcom works with procesors where the customer normally buys them in the millions - so working hand-in-hand with Broadcom engineers. Which means that lots and lots of information just isn't available. And there is zero possibility for you to get access to any support engineer. Which means that you are very likely to _have_ to look at the Linux sources just to find out where registers are located, and what values they take. Even if you get angry and try to rewrite it into me saying you should run a Linux kernel.

"Yes, I did." An assumption there. A simple question is only simple if it really has a simple answer. Most "simple" questions actually have quite complex answers. You can often abuse things to solve problems they aren't designed for. But at a cost, that can often be high. Or even very high. The MDK-ARM tools are not designed for use with the processor in the RP. Even if an ARM11 can run code compiled for an ARM9, the rules for generating ARM11 code is different to fit the design of the ARM11 core. Without simulation support for the peripherials of the chip, you can't really use the simulator to debug your code. And if all you have is the RP board, then you don't have any hardware interface (like JTAG) for using the Keil debugger.

Wanting to use an environment specifically targeted at "low-end" ARM chips, motivates a question why you would be interested in using MDK-ARM, instead of using gcc, which is available for free and with lots of examples.

One of the most important things at the start of a project is to make sure all information is - or will be - available. And when it comes to the documentation of the Broadcom chip - the Linux kernel is an important information source.

In some situations, when doing low-level work with processors, the only accessible information might be gnu assembler source - requiring a need to know how to read it. And maybe a knowledge how to rewrite it to a completely different format, in case another assembler is used.

Do you really have an issue with your simple question having the complex answer that you might be able to use Keil MDK-ARM, but it would not be a good route? And you would learn more, by looking for a different alternative? Your question just can't be answered with a "yes" or "no", without you having qualified your question much more.

Your question just can't be answered with a "yes" or "no", without you having qualified your question much more.

I totally disagree. As you might have noticed, I very nearly did give a yes/no answer. The reason I didn't is not because of difficulties in understanding John's original question, but because I do not have sufficient experience to answer it with more certainty. I do, however, hope I have now given sufficient detail to allow him to follow it through.

Looking through the responses certainly makes me wonder why Per is being the way he is in this thread. John is showing a remarkable level of enthusiasm and understanding; something that is rarely seen from new posters on this forum. It should be encouraged, not knocked. The original question was reasonably clear and in no way complex.

John, I wish you luck, hope you learn lots and gain much satisfaction from your experimentation.