Programming the ARM chip

[Dave_G_2]

@dwelch67

I assume you are using bare metal and not a Linux distro.
Are you using physical or bus addresses to populate the GPIO regs?

[dwelch67]

Yes, all bare metal.

Using physical addressing, replace 0x7Exxxxxx with 0x20xxxxxx, can blink leds and talk to timers and such, moving toward bringing up one of the uarts. Prefer the mini uart to the full uart, but am having problems with the mini.

[Dave_G_2]

@dwelch67

Have you disabled uart interrupts or do you have a handler for them in your vector table?

[dwelch67]

That was probably it. The docs say you should config the gpio first, that may have caused something on the rx, causing an interrupt. So I disabled the interrupts first, then disabled the uart, then was able to configure the gpio, and then configure and enable the uart. Not working yet, but over that hurdle.

[dwelch67]

typos in the manual it appears

page 12 ..5044 is the IER not IIR, next page 5048 is the IIR not IER, right?

in the IER description those should all be R/W bits.

[tufty]

My guess:
No, macro cell as in ASIC design, specifically a "hard macro" that Broadcom licenses from the company that designed it. Much more complex than a CPLD macro cell.

A more likely scenario is that it's designed by Broadcom themselves and manufacture is outsourced
to a company such as TSMC or UMC that do OEM for fabless companies such as Broadcom which
then create/compile the required firmware using MetaWare or similar.

No. The ARM is a macrocell from ARM Holdings, inc, along with the serial port, timer and probably some other bits and pieces. SD is apparently Arasan. USB is from Designworks. Some, if not all, of these are 'tweaked' to fit Broadcom's requirements, but most of what you see on the ARM side is externally licensed IP.

Nobody designs their own stuff any more unless they have to. Licensing is cheaper and you end up with less bugs.

Simon

[dwelch67]

Does anyone have bare metal code that initializes the gpio/uart and transmits characters? This is driving me nuts...I can get the mini uart to spit something out, the other side isnt seeing it correctly (I have the proper level shifter on the host side). I can bit bang just fine. The full uart is not outputting anything on the wire.

[dwelch67]

That was quite painful. I figured it out though http://github.com/dwelch67/raspberrypi/uart01

This uses the mini uart, which is uart1 (TXD1, RXD1). Actually only TXD1, GPIO14.

I dont understand all the fuss about making a MAX232 board, when there are at least three different flavors of ftdi boards at sparkfun (that support 3.3v), like this one for example:
http://www.sparkfun.com/products/718
Many of the arduino flavors (mini, lillypad, etc) rely on a usb to serial board that also supplies power to the board as well as managing the uart, no need to really level shift since it is going straight into the host uart (in the ftdi part). Be very careful the arduinos are often 5V not 3.3, make sure you get a 3.3v board not a 5v board. Connect ground on the ftdi board to pin 6 of connector P1. Connect rx on the ftdi board to pin 8 of connector P1 (tx on the raspi). And tx on the ftdi board to pin 10 of connector P1 (rx on the raspi).

The IIR and IER titles being swapped in the chip doc were one thing, not the major problem. The major problem is the description for the word length is that bit 0 of the LCR is zero for 7 bits per character and 1 for 8 bits and that bit 1 and some other bits are used by 16550 uarts but ignored by the mini uart. That is not true, if bit 1 is zero, then either state of bit 0 gives 7 bits. To get 8 bits per character you need bit 1 to be set. (write a 3 to the LCR register).

[dwelch67]

I have a bootloader working now. http://github.com/dwelch67/raspberrypi/ You may find it ugly but it works. I didnt count the dozens/hundreds of sd card insertions it took to get to this point...no more! Hacking through the error(s) in the chip doc were quite painful.

[Dave_G_2]

@dwelch67

Well done for getting it going, all those SD card insertions and removals are not fun.
Very similar to the old days using the 8051 where it was a case of take the chip out of the socket,
insert in ZIF socket of programmer, program, take out, put back into target board, test, oops, mistake,
repeat.........

I quite like the idea of a loader via the serial port and did a similar thing (based on the Xmodem protocol)
for a X86 project I was working on some time back.

Like you say, the documentation is woeful.
Have you checked out this page:
http://elinux.org/BCM2835_datasheet_errata

[tufty]

I have a bootloader working now. http://github.com/dwelch67/raspberrypi/ You may find it ugly but it works. I didnt count the dozens/hundreds of sd card insertions it took to get to this point...no more! Hacking through the error(s) in the chip doc were quite painful.

Excellent.

Please publicise the errors you've found in the available documentation, if it's in the doc from Broadcom, the wiki is a decent starting point, but I suspect Gert might b interested as well.

Simon

[Dave_G_2]

@dwelch67

Just a thought, why not also put the compiled img on github so that beginners that don't quite yet
understand the whole process (or only use Windows) can also test and hopefully get interested.

[dwelch67]

Please educate me/us on where I need to go or what I need to do to inform the right parties about errors in the datasheet.

[dwelch67]

@dwelch67

Well done for getting it going, all those SD card insertions and removals are not fun.
Very similar to the old days using the 8051 where it was a case of take the chip out of the socket,
insert in ZIF socket of programmer, program, take out, put back into target board, test, oops, mistake,
repeat.........

I quite like the idea of a loader via the serial port and did a similar thing (based on the Xmodem protocol)
for a X86 project I was working on some time back.

Like you say, the documentation is woeful.
Have you checked out this page:
http://elinux.org/BCM2835_datasheet_errata

Yeah, actually xmodem is a good idea, that way you can live within the dumb terminal (and have the program under test just start using the terminal and not have to do some sort of two step). I have surprisingly little experience with that method as so many things have their own special serial protocols. Definitely old school and definitely works. I have implemented xmodem before may dig that up or just re-invent it...last night I happened to have had something I made for a game boy advance years ago and lifted that code and had it running in a matter of minutes which is why I took this path.

[dwelch67]

@dwelch67

Just a thought, why not also put the compiled img on github so that beginners that don't quite yet
understand the whole process (or only use Windows) can also test and hopefully get interested.

Done. At first I was thinking that if they want to use this tool they need a toolchain anyway, they wont get very far so if they cant build the bootloader they wont be able to build anything else. But I have also been planning on taking a thumb assembler I recently wrote for a thumb simulator (avoids the problems that come from trying to get or make your own cross assembler) and making some assembler example programs using that. In that case they wont necessarily have a full cross compiler...so I committed the binary version of the bootloader...

[tufty]

Please educate me/us on where I need to go or what I need to do to inform the right parties about errors in the datasheet.

A decent place to document them for all to see would be on the Wiki page mentioned beforehand, viz: http://elinux.org/BCM2835_datasheet_errata

I would tend to contact Gert van Loo as well, either by pm here or via direct email. He's (as I understand it) the person most likely to be able to get them corrected in the actual document. He can probably clear up any misunderstandings as well.

Simon

[DexOS]

@dwelch67, First great work on what you have done so far.
Your name seems familiar, did you use to program the GP2X ?.

Also have you any input for interfacing a ps2 keyboard to the R-PI, from a hardware point, as i am more a software persons, that wants to now also get into hardware.
Thanks.

[dwelch67]

Yes, I was active on the GP2X. Did the same thing there as here, not interested in writing linux apps, but instead getting down into the guts of the thing.

I have not interfaced to a PS/2 keyboard or mouse. Looks like you have to supply 5V to power the keyboard. My understanding the serial interface is not that complicated.

http://www.computer-engineering.org/ps2protocol/

I would power the keyboard with something else, not the raspi. Probably want to use 3.3v to/from 5v level shifters, assuming there is something to supply the 5V side use that to power the keyboard.

You might try doing something like bit banging a serial interface first. Look at my other projects I think I have some msp430 code bit banging serial. A number of the boards receiving infra red, not a bad first project. Using the uart and the keyboard on your host computer is a quick way to get input into the target board, if that is what you are after.

[dwelch67]

@dwelch67

Well done for getting it going, all those SD card insertions and removals are not fun.
Very similar to the old days using the 8051 where it was a case of take the chip out of the socket,
insert in ZIF socket of programmer, program, take out, put back into target board, test, oops, mistake,
repeat.........

I quite like the idea of a loader via the serial port and did a similar thing (based on the Xmodem protocol)
for a X86 project I was working on some time back.

Like you say, the documentation is woeful.
Have you checked out this page:
http://elinux.org/BCM2835_datasheet_errata

http://github.com/dwelch67/raspberrypi/bootloader02

A very simple xmodem based bootloader. No state machine at all in the receiver so if it misses a single byte it is game over. A first step in that (xmodem) direction though.

[annodomini2]

I dont understand all the fuss about making a MAX232 board,

If you're just using it as say a debug port or some other PC interface, then an FTDI chip is fine, but if you are interfacing to an actual RS232 device, then the MAX232 is critical.

[hippy]

I dont understand all the fuss about making a MAX232 board,

If you're just using it as say a debug port or some other PC interface, then an FTDI chip is fine, but if you are interfacing to an actual RS232 device, then the MAX232 is critical.

If serial comms can be made to work by bit-banging, rather than using the on-chip UART, it should be possible to create a GPIO direct to RS232 interface using nothing but a current limiting resistor on serial in.

That's worked with all micros and PC's I have used and though not RS232 or SoC spec compliant can be entirely usable.

I have a bootloader working now. http://github.com/dwelch67/raspberrypi/ You may find it ugly but it works.

A quick question on "dummy(ra);" -- what's the purpose of those; just time delays or are they doing something more ?

[DexOS]

Yes, I was active on the GP2X. Did the same thing there as here, not interested in writing linux apps, but instead getting down into the guts of the thing.

I have not interfaced to a PS/2 keyboard or mouse. Looks like you have to supply 5V to power the keyboard. My understanding the serial interface is not that complicated.

http://www.computer-engineering.org/ps2protocol/

I would power the keyboard with something else, not the raspi. Probably want to use 3.3v to/from 5v level shifters, assuming there is something to supply the 5V side use that to power the keyboard.

You might try doing something like bit banging a serial interface first. Look at my other projects I think I have some msp430 code bit banging serial. A number of the boards receiving infra red, not a bad first project. Using the uart and the keyboard on your host computer is a quick way to get input into the target board, if that is what you are after.

Thanks for the info, i need a directly connected keyboard, because i am porting my OS to R-PI, but also want to go back to the R-PI roots and boot to a modern basic interpreter.
So a keyboard interface is important, could implement a usb stack and hid, but i am half way through that in my x86 OS and its a pain (but at lest i know whats on the R-PI).
Thought ps2 would be easier, also read the RISC OS is also having similar problems.

[dwelch67]

I dont understand all the fuss about making a MAX232 board,

If you're just using it as say a debug port or some other PC interface, then an FTDI chip is fine, but if you are interfacing to an actual RS232 device, then the MAX232 is critical.

If serial comms can be made to work by bit-banging, rather than using the on-chip UART, it should be possible to create a GPIO direct to RS232 interface using nothing but a current limiting resistor on serial in.

That's worked with all micros and PC's I have used and though not RS232 or SoC spec compliant can be entirely usable.

I have a bootloader working now. http://github.com/dwelch67/raspberrypi/ You may find it ugly but it works.

A quick question on "dummy(ra);" -- what's the purpose of those; just time delays or are they doing something more ?

I completely understand that, how many people have actual serial ports vs usb? How many of those ports are just usb to serial? The ftdi solution should be a fit for far more people than a level shifter. For real serial ports back to sparkfun (local for USA, dont know about elsewhere).
http://www.sparkfun.com/products/449
My main point is there is no need to re-invent the wheel here and make some special board, there are many, affordable, solutions out there already.

The dummy function is there to prevent the compiler from optimizing out the loop. A volatile would work as well, but I prefer this method.

[annodomini2]

I dont understand all the fuss about making a MAX232 board,

If you're just using it as say a debug port or some other PC interface, then an FTDI chip is fine, but if you are interfacing to an actual RS232 device, then the MAX232 is critical.

If serial comms can be made to work by bit-banging, rather than using the on-chip UART, it should be possible to create a GPIO direct to RS232 interface using nothing but a current limiting resistor on serial in.

That's worked with all micros and PC's I have used and though not RS232 or SoC spec compliant can be entirely usable.

I have a bootloader working now. http://github.com/dwelch67/raspberrypi/ You may find it ugly but it works.

A quick question on "dummy(ra);" -- what's the purpose of those; just time delays or are they doing something more ?

RS232 operates at +/-15v so it won't work 'bit-banging' TTL lines.

It's one of the reasons setting up the MAX232 is a challenge.

[Dave_G_2]

I think there is a bit of confusion as regards the serial ports.

The R-PI has a UART which along with it's GPIO lines give out 3.3v so the serial port
is not RS232 levels i.e. +15V and -15V
For this we need a MAX type chip which converts the RS232 levels to 3.3v logic and vice versa.
The MAX232 is meant for 5V logic which means that it must be supplied with 5V and it will give out
close to that on the TTL outputs (not the RS232 outputs).
So to use it on the R-PI, we must use resistor divider networks to bring the 5V down to 3.3v.
For the "TTL" inputs, the MAX232 will normally see 3.3v as a legal logic high.

Alternatively we can use the MAX3232 which are specifically made for 3.3V logic levels.

All of the above of course applies if we want to make our own interface, but as dwelch67 has
written, there are plenty of ready made modules available.

As far as the FTDI chipset goes, it also gives out and expects TTL levels (not RS232 levels).
However the USB to serial type convertors available in PC stores, ebay, etc etc DO give out
RS232 levels and thus CANNOT be connected directly to the R-PIs uart without a MAX232
or MAX3232.

By the way, when one bit bangs the serial port, we are actually bit banging the "TTL" side which is
then fed to the MAX chip.
One does not bit bang the RS232 levels directly.

See below:
http://s11.postimage.org/jy79tc6kj/Serial_Diffs.jpg