See the top level README file for more information on documentation and how to run these programs. Derived from uart05 This is specific to the Raspberry Pi 2 as it experiments with the multiple processor cores. So the little additional information we have from Broadcom about the raspberry pi 2 processor, shows some mailbox addresses that cause interrupts. If you disassemble the first 0x100 bytes of memory as we find it when kernel7.img runs. At least as of this writing it is in that space. There is vbar, mvbar manipulation (moving the entry from that interrupt/event to somewhere other than zero) various things including the other cores waiting on an interrupt. These addresses are one of four mailboxes for each of these cores, writing with an address triggers the interrupt which triggers this code to then ultimately branch to that address for that core. So if you write to address 0x4000009C for core 1 0x400000AC for core 2 0x400000BC for core 3 With the address to the entry point for the code you want that core to run...it will start that core. This program starts up the other three cores, lets them fight over the memory location at address 0x40. Core 0 reads 0x40 and prints out when it sees it change. It is going to look somewhat random. So we have to be careful not messing with this first 0x100 bytes, unless you know what you are doing or you have started each core. Check blinker05 rpi2 version. As of late 2015 the GPU loader (start.elf) which leaves this code for the ARM is now putting the ARM in what is called hyp mode or hypervisor mode. A little/lot different than the supervisor mode that we have been used to for so many years. You dont switch modes for an interrupt, etc you are just in hyp mode. With or without hyp mode we can move the exception handler table from the traditional address zero to other places, and not having to mess with this bootcode left for us if we dont want to, yet still do fun things.