Baremetal for Raspberry Pi

"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.

"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.