This repo serves as a collection of low level examples.  No operatingsystem, embedded or low level embedded or deeply embedded or bare metal,whatever your term is for this.I am in no way shape or form associated with the raspberry pi organizationnor broadcom.  I just happen to own one (some) and am sharing myexperiences.  The raspberry pi is about education, and I feel lowlevel education is just as important as Python programming.From what we know so far there is a gpu on chip which:1) boots off of an on chip rom of some sort2) reads the sd card and looks for additional gpu specific boot filesbootcode.bin and start.elf in the root dir of the first partition(fat32 formatted, loader.bin no longer used/required)3) in the same dir it looks for config.txt which you can do things likechange the arm speed from the default 700MHz, change the address whereto load kernel.img, and many others4) it reads kernel.img the arm boot binary file and copies it to memory5) releases reset on the arm such that it runs from the address wherethe kernel.img data was writtenThe memory is split between the GPU and the ARM, I believe the defaultis to split the memory in half.  And there are ways to change thatsplit (to give the ARM more).  Not going to worry about that here.From the ARMs perspective the kernel.img file is loaded, by default,to address 0x8000.  (there are ways to change that, not going to worryabout that right now).Hardware and programming information:You will want to go herehttp://elinux.org/RPi_HardwareAnd get the datasheet for the parthttp://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 boardhttp://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)Early in the BCM2835 document you see a memory map.  I am going tooperate based on the middle map, this is how the ARM comes up.  Theleft side is the system which we dont have direct access to in thatform, the gpu probably, not the ARM.  The ARM comes up with a memoryspace that is basically 0x40000000 bytes in size as it mentions inthe middle chart.  The bottom of this picture shows total systemsdram (memory) and somewhere between zero and the top of ram is asplit between sdram for the ARM on the bottom and a chunk of thatfor the VC SDRAM, basically memory for the gpu and memory sharedbetween the ARM and GPU to allow the ARM to ask the GPU to draw stuffon the video screen.  256MBytes is 0x10000000, and 512MBytes is0x20000000.  Some models of raspberry pi have 256MB, newer models have512MB total ram which is split between the GPU and the ARM.  Assumethe ARM gets at least half of this.  Peripherals (uart, gpio, etc)are mapped into arm address space at 0x20000000.  When you see0x7Exxxxxx in the manual replace that with 0x20xxxxxx as your ARMphysical address.  Experimentally I have seen the memory repeats every0x40000000, read 0x40008000 and you see the data from 0x8000.  Iwouldnt rely on this, just an observation (likely ignoring the upperaddress bits in the memory controller).I do not normally zero out .bss or use .data so if you do this to my examplesint x;fun(){  static int y;}dont assume x and y are zero when your program starts. Nor if you do thisint x=5;fun(){  static int y=7;}will x=5 or y=7.  See the bssdata directory for more information.Nor do I use gcc libraries nor C libraries so you can build most if notall of my examples using a gcc cross compiler.  Basically it doesntmatter if you use arm-none-linux-gnueabi or arm-none-eabi.  What wasformerly codesourcery.com still has a LITE version of their toolchainwhich is easy to come by, easy to install and well maybe not easy to usebut you can use it.  Building your own toolchain from gnu sources (binutilsand gcc) is fairly straight forward see my build_gcc repository for abuild script.As far as we know so far the Raspberry Pi is not "brickable".  Normallywhat brickable means is the processor relies on a boot flash and withthat flash it is possible to change/erase it such that the processor willnot boot normally.  Brickable and bricked sometimes excludes thingslike jtag or special programming headers.  From the customers perspectivea bricked board is...bricked.  But on return to the vendor they mayhave other equipment that is able to recover the board without doingany soldering, perhaps plugging in jtag or some other cable on pins/padsthey have declared as reserved.  Take apart a tv remote control orcalculator, etc and you may see some holes or pads on the circuit board,for some of these devices just opening the battery case you have a viewof some of the pcboard.  This is no doubt a programming header.  Longstory short, so far as I know the Raspberry Pi is not brickable becausethe rom/flash that performs the initial boot is for the gpu and we donthave access to the gpu nor its boot rom/flash.  The gpu relies on thesd card to complete the boot, so there is something in hardware orperhaps there is an on chip flash for the gpu, from there on it is allsd card.  It is very easy for the customer to remove andreplace/modify that boot flash.  So from a software perspectiveunless you/we accidentally figure out how to change/erase the gpu bootcode (my guess is it is a one time programmable) you cant brick it.To use my samples you do not need a huge sd card.  Nor do you need norwant to download one of the linux images, takes a while to download,takes a bigger sd card to use, and takes forever to write to the sd card.I use the firmware fromhttp://github.com/raspberrypi.  The minimumconfiguration you need to get started at this level is:go tohttp://github.com/raspberrypi, you DO NOT need to downloadthe repo, they have some large files in there you will not need (formy examples).  go to the firmware directory and then the boot directory.For each of these files, bootcode.bin and start.elf (NOT kernel.img,dont need it, too big)(loader.bin is no longer used/required).  Clickon the file name, it will go to another page then click on View Raw andit will let you download the file.  For reference, I do not use norhave a config.txt file on my sd card.  I only have the three files (bootcode.bin, start.elf, and then kernel.img from one of my examples).My examples are basically the kernel.img file.  Not a linux kernel,just bare metal programs.  Since the GPU bootloader is looking forthat file name, you use that file name.  The kernel.img file is just ablob that is copied to memory, nothing more.What I do is setup the sd card with a single partition, fat32.  Andcopy the above files in the root directory.  bootcode.bin and start.elf.From there you take .bin files from my examples and place them on the sdcard with the name kernel.img.  It wont take you very long to figure outthis is going to get painful.1) power off raspi2) remove sd card3) insert sd card in reader4) plug reader into computer5) mount/wait6) copy binary file to kernel.img7) sync/wait8) unmount9) insert sd card in raspi10) power raspi11) repeatThere are ways to avoid this, one is jtag, which is not as expensiveas it used to be.  It used to be in the thousands of dollars, now itis under $50 and the software tools are free.  Now the raspi does havejtag on the arm, getting the jtag connected requires soldering on somemodels, but not on the newer models.  I do not yet have a newer model.How to use the jtag and how to hook it up is described later and inthe armjtag sample.Another method is a bootloader, typically you use a serial port connectedto the target processor.  That processor boots a bootloader program thatin some way, shape, or form allows you to interact with the bootloaderand load programs into memory (that the bootloader is not using itself)and then the bootloader branches/jumps to your program.  If your programis still being debugged and you want to try again, you reboot the processorthe bootloader comes up and you can try again without having to move anysd cards, etc.  The sd card dance above is now replaced with thebootloader dance:1) power off raspi2) power on raspi3) type command to load and start new programI have working bootloader examples.  bootloader05 is the currentlyrecommended version.  But you need more hardware (no soldering isrequired).  For those old enough to know what a serial port is, youCANNOT connect your raspberry pi directly to this port, you will frythe raspberry pi.  You need some sort of serial port at 3.3V eithera level shifter of some sort (transceiver like a MAX232) or a usbserial port where the signals are 3.3V (dont need to use RS232 juststay at the logic level).  The solution I recommend is a non-soldersolution:http://www.sparkfun.com/products/9873plus some male/female wirehttp://www.sparkfun.com/products/9140Solutions that may involve solderinghttp://www.sparkfun.com/products/718http://www.sparkfun.com/products/8430Or this for level shifting to a real com port.http://www.sparkfun.com/products/449Or see the pitopi (pi to pi) directory.  This talks about how to taketwo raspberry pi's and connect them together.  One being thehost/development platform (a raspberry pi running linux is a nativearm development platform, no need to find/get/build a cross compiler)the other being the target that runs your bare metal programs.---- connecting to the uart pins ----On the raspberry pi, the connector with two rows of a bunch of pins isP1.  Starting at that corner of the board, the outside corner pin ispin 2.  From pin 2 heading toward the yellow rca connector the pinsare 2, 4, 6, 8, 10.  Pin 6 connect to gnd on the usb to serial boardpin 8 is TX out of the raspi connect that to RX on the usb to serialboard.  pin 10 is RX into the raspi, connect that to TX on the usb toserial board.  Careful not to have metal items on the usb to serialboard touch metal items on the raspberry pi (other than the threeconnections described).  On your host computer you will want to usesome sort of dumb terminal program, minicom, putty, etc.  Set theserial port (usb to serial board) to 115200 baud, 8 data bits, noparity, 1 stop bit.  NO flow control.  With minicom to get no flowcontrol you normally have to save the config, exit minicom, thenrestart minicom and load the config in order for flow controlchanges to take effect.  Once you have a saved config you dont haveto mess with it any more.2  outer corner46  ground8  TX out10 RX inground is not necessarily needed if both the raspberry pi and theusb to serial board are powered by the same computer (I recommendyou do that) as they will ideally have the same ground.Read more about the bootloaders in their local README files.  Likewiseif you interested in jtag see the armjatag README file.  Other thanchewing up a few more GPIO pins, and another thing you have to buy, thejtag solution is the most powerful and useful.  My typical setup is thearmjtag binary as kernel.img, a usb to jtag board like the amontecjtag-tiny and a usb to serial using minicom.As far as these samples go I recommend starting with blinker01 thenfollow the discovery of the chip into uart01, etc.  I took one pathwith the first bootloader then switched gears to use xmodem, ifinterested at all you may wish to just skip to that one.  It has nofeatures and isnt even robust, quick and dirty, and most of the timeit works just fine, if not power cycle the raspberry pi and try again.(power cycle = unplug then plug back in)The bssdata and baremetal directories attempt to explain a littlebit about taking control of the gnu toolchain to build bare metalprograms like these examples.  As with any bare metal programmer I havemy ways of doing things and these two directories hopefully will showyou some basics, get you thinking about how these tools really work,take the fear away from using them, as well as some comments on whyI take the approach I take (not worrying about .bss nor .data).  Sincethe raspberry pi is from our perspective RAM based (the GPU loads ourwhole binary into memory), we dont have to deal with the things wewould deal with on a FLASH/PROM + RAM system.  This RAM only approachmakes life a lot easier, but leaves out some important bare metalexperiences that you will have to find elsewhere.