Programming the ARM chip

[cronotk]

Hello!

I have been wondering if it is possible to program the ARM IC on the board directly. The reason is that I want to learn a bit about ARM programming, but the normal development/evaluation boards are pretty expensive.

However, I didn't find any information on that in the FAQ, the wiki or the forum.
I'm pretty sure that I could just code what I want to do and run it from the SD card, but I also want to get rid of the bootloader that's already in there to experiment more

Any help on that matter would be highly appreciated!

Regards

[nick.mccloud]

There are numerous resources on the interweb on programming the ARM - Google is your friend.

As to the boot loader, start.elf is used by the GPU to get the show on the road and then hands over to kernel.img to be run by the ARM CPU - you can make kernel.img anything you like - if you search the forums there are a few more details including some dissection of the first few byte codes of the kernel.img, but once the GPU has passed over control, it's all yours. The Broadcom documentation gives info on addresses to use for the frame buffer for display. The consensus is that your biggest challenge will be writing a USB stack to communicate with the keyboard, alternatively you can talk to the serial port that comes out on the GPIO.

[cronotk]

Yes, there are numerous resources on ARM programming. With programming I actually meant "What JTAG programmer would I have to buy to get this running". I find this question is not that easy to answer with Google...

But after finding the "datasheet" (very generous description I would say ) for the BCM2835 I guess I'll better look for a real development board and a controller with decent documentation for my purposes.

Thanks for your input.

[jamesh]

There is no JTAG on the Arm - you don't really need JTAG except during board bring up. You can write arm assembler and run it in the Linux environment using GDB as your debugger, which should be more than enough for learning Arm assembler, as should the documentation available - you don't need anything more than the peripheral spec already provided.

[nick.mccloud]

With programming I actually meant "What JTAG programmer would I have to buy to get this running".

If only you'd asked it straight away.

As James says, there isn't one.

[johnbeetem]

Here's a good RasPi forum thread on ARM assembler: http://www.raspberrypi.org/phpBB3/viewt ... f=2&t=2910

The thread includes advice on which ARM ARM you need and where there is a nice ARM tutorial. You don't need JTAG. I recommend starting by writing some small C programs and compiling them with the option that saves ASM source. Then play with that ASM source to create your own programs.

We also had an Absolute Beginner's thread on ARM ASM a few days ago: http://www.raspberrypi.org/phpBB3/viewt ... f=5&t=5646

[R37R0]

I picked up a good book from abebooks on Arm programming, "ARM System Developer's Guide". From googling, somebody appears to have uploaded it in PDF to google code

It covers ARMv6 and has details about ARM11 too.

[jamesh]

I fear the OP has already legged it. Apparently, can't be used as a development board.... Which seems odd given the original question of learning Arm assembler.
Thinking about it, the Raspi must be one of the few Arm boards where you can learn assembler without the need for JTAG.

[cronotk]

I didn't really ask about ARM assembly. I was just hoping that there was a way to run some sort of compiled code (which may or may not include assembly) on the ARM without any sort of annoying operating system getting in my way or preventing me from doing nasty stuff. I also don't really want to run from the SD card but flash the ARM itself.

But since the chip's documentation isn't good enough I'll just let it be and get me some other ARM chip to experiment on. There are other not-too-expenive boards that have decently documented chips. Well, I guess you could say that I "legged it"

Maybe I'll still get one to run my webserver though

Regards


PS: Thanks for the links/hints johnbeetem and R37R0, they will surely come in handy

[jamesh]

Sorry, I assumed that 'Arm development' meant Arm assembly. In fact, Arm development in a high level compiled language is pretty much the same as x86 development in a high level language. Hence my confusion.
The chips documentation IS good enough to do what you want - in what way do you think it isn't? It gives specs for all the interfaces attached to the Arm. The only stuff it doesn't have is GPU related information, which you cannot do anything with anyway (its not an Arm so falls at your first requirement)
There are a number of people planning to run without the OS in place, search forum for 'bare metal' (I have that term - silicon is NOT a metal, it's a tetravalent metaloid)

[khulat]

I guess what you really want is not an ARM SOC but a Microcontroller (AtmegaXX or similar devices). Arduino would be a good place to start looking.

[mccp]

It seems to me that all the OP needs is a bootloader that provides GDB stubs for remote debugging over RS232 or Ethernet. S/he can then write whatever code s/he likes and get it running on the ARM with no OS.

Unless the OP wants to learn how to bring the ARM up, in that case maybe writing (or porting) a bootloader would be the answer. In any case, I'm sure that there will be a variety of ported and home-grown efforts soon enough.

@cronotk - you can't 'flash' the ARM as there is no flash on the SoC (afaik), JTAG would let you write data directly to SDRAM and then execute it, but it seems odd to complain that you can't do that when it is easier (and probably far quicker in my experience) to write an executable to kernel.img on the SD card - the end result - your code running with no OS - is the same.

It is clear to me that (barring any mistakes) the datasheet is perfectly adequate for writing anything - far better than some I have seen. I suppose that it possibly doesn't explain enough to someone with no experience of bare-metal development at all, but surely that's a criticism of any datasheet? At least we expect that the community will develop more introductory texts over the next few months.

@JamesH - I hate bare-metal too, unfortunately there appears to be no widely used alternative.

[cronotk]

The chips documentation IS good enough to do what you want - in what way do you think it isn't? It gives specs for all the interfaces attached to the Arm.

It is good enough? Then maybe I found the wrong document. The one I had just had a list of all the processor's registers but no description on how they are to be used (the document had about 200 pages IIRC).

There are a number of people planning to run without the OS in place, search forum for 'bare metal' (I have that term - silicon is NOT a metal, it's a tetravalent metaloid)

Thanks, I will try that!
And I agree with you, that term is just... silly

I guess what you really want is not an ARM SOC but a Microcontroller (AtmegaXX or similar devices). Arduino would be a good place to start looking.

I guess you are right. I was hoping that the SoC was close enough to the MCU ARMs so that there would be barely any difference (apart from having tons of more stuff on the chip that I would ignore for now). I have worked with the Atmega chips before and their 8-Bit MCUs are pretty damn good. The AVR32s are absolutely terrible though - and this is why I thought that I should take a look at ARM.

Regards

[jamesh]

The chips documentation IS good enough to do what you want - in what way do you think it isn't? It gives specs for all the interfaces attached to the Arm.

It is good enough? Then maybe I found the wrong document. The one I had just had a list of all the processor's registers but no description on how they are to be used (the document had about 200 pages IIRC).
Regards

No, that's the document. And that is in fact all that is available - there is nothing more detailed, even internally at Broadcom - it's what the Broadcom engineers use to write code although they do have access to the people who designed the HW (and the RTL) if they get stuck! It's a spec for this SoC interfaces, not a programming guide. If it's not detailed enough for you then I'm afraid you are stuck.

[cronotk]

No, that's the document. And that is in fact all that is available [...] If it's not detailed enough for you then I'm afraid you are stuck.

I guess I'm too spoiled by Atmega's documentation. But even the NXP documentation for their controllers is a lot better.
Ah well...

[summers]

If you want to go in the JTAG direction, then you'll need to get something like a pandaboard, and the JTAG dongle isn't cheap either ....

Now you'll be able to get the same code inro the ARM be writing fictional kernel images and writing to SD, as using the JTAG. It isn't clear if the arm comes up in the same way, probably not - as the JTAG direction won't have gone via a boot sequence, so the CPU will have very little set up.

The JTAG direction though does give you the option of examining your memory, to see what running the code has done. With just a constructed kernel you'll have to get that functional enough that it writes its output somewhere you can see it.

So guess the RPi vs Pandaboard + JTAG dongle comparison are very different beasts, used for doing very different things ...

[jamesh]

No, that's the document. And that is in fact all that is available [...] If it's not detailed enough for you then I'm afraid you are stuck.

I guess I'm too spoiled by Atmega's documentation. But even the NXP documentation for their controllers is a lot better.
Ah well...

Atmega documentation was designed to be sent to end users, this stuff wasn't. I believe it may even be the first spec sheet Broadcom have ever publicly released. Better is relative of course. Considering the docs were designed for Broadcom engineers for internal use, they are fine for that purpose, just not that great for external use. And the chances of a more detailed one? Not high.

[AndrewS]

Any chance that some of the http://elinux.org/BCM2835_datasheet_errata might get incorporated, and a new revision of the data sheet published?

[nick.mccloud]

The chips documentation IS good enough to do what you want - in what way do you think it isn't? It gives specs for all the interfaces attached to the Arm.

It is good enough? Then maybe I found the wrong document. The one I had just had a list of all the processor's registers but no description on how they are to be used (the document had about 200 pages IIRC).

Should you not decide on how to use the registers? I haven't come across any other MPU's that tell you what the GP registers are to be used for. Overall, the CPU is a standard ARM device - you can snag a copy of the datasheets from ARM and take it from there. The Broadcom docs fill in all the SoC blanks that aren't covered by standard ARM docs.

[zippy]

The Broadcom documentation gives info on addresses to use for the frame buffer for display.

Really? This is exactly what I've been waiting for but in the BCM2835 pdf file I have it doesn't mention anything at all about accessing the hardware directly to display something on screen. Is there a new and updated file which now has this info?

As you say, keyboard access via USB is another hurdle, but if we can at least have a dumb 2D frame buffer direct from ARM code (without an OS) that is a huge step forward.

I have a couple of old A3000 demos I'd like to get running on the Pi as my first project and my board has just been sitting here waiting for display info. like this to be made available.

[mole125]

It may not be in the datasheet but if memory serves me right some sample code has been provided, if it hasn't then isn't the details available in the kernel drivers?

[johnbeetem]

...search forum for 'bare metal' (I [hate] that term - silicon is NOT a metal, it's a tetravalent metaloid)

Personally, I like "bare metal" just fine. After all, I'm only able to get down to the metal wires that connect to the silicon chip, or to the metal layers that connect the silicon transistors within the chip. When I was connecting up resistors and transistors to make RTL when I was a kid, it was the bare metal that I was touching. Besides, the term "bare metal" lets me go back to relay logic and vacuum tubes (AKA "valves") without having to change terminology

[johnbeetem]

For a nice way to play with ARM at the bare metal, I suggest the STM32 Discovery boards. They're ARM Cortex-M3 (or M0 or M4) so you're using the Thumb-2 instruction encodings, but you do have control over everything and can boot from flash. It's also easy to disable the USB ST-Link interface and program the target chip directly from your own JTAG interface. You might also check out the NXP mbed and LPCXpresso boards.

[jamesh]

...search forum for 'bare metal' (I [hate] that term - silicon is NOT a metal, it's a tetravalent metaloid)

Personally, I like "bare metal" just fine. After all, I'm only able to get down to the metal wires that connect to the silicon chip, or to the metal layers that connect the silicon transistors within the chip. When I was connecting up resistors and transistors to make RTL when I was a kid, it was the bare metal that I was touching. Besides, the term "bare metal" lets me go back to relay logic and vacuum tubes (AKA "valves") without having to change terminology

Nah, this is bare metal..!

http://s175.photobucket.com/albums/w143 ... 20rebuild/

[Burngate]

To an astronomer anything heavier than helium is a metal - so silicon is a metal, as is carbon, ...