raspberrypi/README

Right, I know...Got my raspberry pi today.

This repo serves as a collection of low level examples.  No operating
system, embedded or low level embedded or deeply embedded, whatever
your term is for this.

From what we know so far there is a gpu on chip that boots off of I
assume an on chip rom.  This goes to the sd card and does things.  it
appears that the entry point for us as programmers is the kernel.img
file, which appears to be the memory image copied into the ARM memory
before releasing reset on the ARM processor.  The name of course because
this is intended to be a Linux based educational computer, but it is
just a file name, just a memory image.

You will want to go here
http://elinux.org/RPi_Hardware
And get the datasheet for the part
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
(might be an old link, find the one on the wiki page)
And the schematic for the board
http://www.raspberrypi.org/wp-content/uploads/2012/04/Raspberry-Pi-Schematics-R1.0.pdf
(might be an old link, find the one on the wiki page)

The manual uses addresses like 0x7Exxxxxx, which is the real address for
something.  But there is an address translation layer between the ARM
physical address and the real address.  All of this code will use the
ARM physical address which is 0x20xxxxxx.  The rest of the address is
the same so if the manual says 0x7E123456, then from the ARM use 0x20123456

I dont normally use .data nor gcc libraries nor C libraries so you can
build most if not all of my examples using a gcc cross compilerl.  Basically
it doesnt matter if you use arm-none-linux-gnueabi or arm-none-eabi.
what was formerly codesourcery.com still has a LITE version of their
toolchain which is easy to come by, easy to install and well maybe not
easy to use but you can use it.  Building your own toolchain from gnu
sources (binutils and gcc) is fairly straight forward and at some point
will create a script to do that for you.

As far as we know so far the Raspberry Pi is not "brickable".  Normally
what brickable means is the processor relies on a boot flash.  For example
there may be a bootloader that allows you to re-program the flash.  If you
make a mistake writing code at this low level and load the boot flash
with that bad code you may not be able to reload the flash again.  There
are many ways to prevent this, but there are also still boards that
can be bricked or at least require more equipment or soldering, etc to
recover them.  They way this board works is quite interesting.  There
is a GPU on chip that boots from an on chip flash (in that respect it
may be brickable, but we dont have access to that GPU boot loader).  The
GPU on chip bootloader looks for an sd card, the sd card contains more
GPU code.  That code probably initializes sdram, and then copies the
contents of kernel.img on the sd card to sdram.  Then releases reset
on the ARM.  Each of these example programs produce a .bin file.
kernel.img is nothing more than a .bin file, an image of the flash.
The filename is special to the raspi bootloder, so you need to use
that file name.  Backup your original kernel.img if you want to go back
to playing with linux then copy the .bin file in the example to
kernel.img on the sd card.  For example
cp blinker01.bin /media/9876-5432/kernel.img
sync
umount /media/9876-5432
Insert the sd card into the raspi and power.

It wont take you very long to figure out this is going to get painful.

1) power off raspi
2) remove sd card
3) insert sd card in reader
4) plug reader into computer
5) mount/wait
6) copy binary file to kernel.img
7) sync/wait
8) unmount
9) insert sd card in raspi
10) power raspi
11) repeat

There are ways to avoid this, one is jtag, which is not as expensive
as it used to be.  It used to be in the thousands of dollars, now it
is under $50 and the software tools are free.  Now the raspi does have
jtag on the arm, getting the jtag connected to that is going to require
some soldering.  I have not done it yet but will and will post info.
Unfortunately the connection to jtag is not there on power up you have
to run some code on the arm, so when that happens I will post that
program.

Another method is a bootloader, typically you connect a serial port.
The program that actually boots on the processor has some way for you
to get into a bootloader.  Sometimes that is all that is there, sometimes
you have to hit a key within a few seconds after it starts to boot.
The bootloader will have some way for you to use either the serial
or ethernet to copy a file into memory or flash.  In this case probably
memory.  I have a bootloader that works.  Am working on a second one
that will probably be easier/better to use.  With the bootloader method
at least how I am implementing it for the raspi, you perform the sd
card dance above one time to copy the bootloader to the sd card.  You
use some flavor of serial port as described below.  When the board
boots you can load your programs over the serial connection, never
needing to do the sd card dance until you want to leave your application
on the raspi and not the bootloader.  The bootloader step will be
something like:

1) power off raspi
2) power on raspi
3) type command to load and start new program


My first bootloader is working, this will greatly save on wear and tear
on the sd card socket.  You will need some sort of serial adapter.
The uart signals on the raspi are not at RS232 levels, you CANNOT
simply connect them to a "COM port", you will fry your raspberry pi.
A simple solution is to get these two items at sparkfun or something
similar (there are many ftdi usb to serial 3.3v solutions out there)
http://www.sparkfun.com/products/718
http://www.sparkfun.com/products/8430
On the raspberry pi, the connector with two rows of a bunch of pins is
P1.  Starting at that corner of the board, the outside corner pin is
pin 2.  From pin 2 heading toward the yellow rca connector the pins
are 2, 4, 6, 8, 10.  Pin 6 connect to gnd on the usb to serial board
pin 8 is tx out of the raspi connect that to RX on the usb to serial
board.  pin 10 is rx into the raspi, connect that to TX on the usb to
serial board.  Careful not to have metal items on the usb to serial
board touch metal items on the raspberry pi (other than the three
connections described).  On your host computer you will want to use
some sort of dumb terminal program, minicom, putty, etc.  Set the
serial port (usb to serial board) to 115200 baud, 8 data bits, no
parity, 1 stop bit.  NO flow control.  With minicom you likely have
to save the config, exit minicom, then restart in order for flow control
changes to take effect.

I recommend you start with blinker01 and follow the discovery through
those to uart01, etc.  If you dont have a bootloader, do the sd card
dance with the .bin file.

bootloader01 uses the .hex file from the examples and prograspi program
bootloader02 uses the .bin file from the examples and xmodem from a
terminal program