Raspberry Pi: Difference between revisions

Note: The serial adaptor I use provides both a 0V and 5V lead (black and red) which provide power to the RPi. No extra power supply is needed besides this.

 

 

First things first, you're going to want to make sure all your hardware works. Connect your serial adaptor to the RPi and boot up the official Raspian image. The boot process will output to both the serial and the HDMI and will start a getty on the serial. Set up your serial port, however yours works, and open up minicom. Make sure you have flow control turned off.

If you started minicom only after the RPi has booted then simply press '''return''' in minicom so the getty will output a fresh login prompt. Otherwise wait for the boot messages to appear. If you don't get any output then connect the RPi to a monitor to check that it actually boots, check your connections and minicom settings.

 

 

 

<source lang="bash">

Now you are ready to start.

 

# [http://www.cl.cam.ac.uk/freshers/raspberrypi/tutorials/os/ Tutorial in assembler (University of Cambridge)]

# [https://github.com/dwelch67/raspberrypi Collection of examples and bootloader by dwelch67]

# [https://github.com/bztsrc/raspi3-tutorial Tutorials for AArch64 in C by bzt]

# [[Detecting Raspberry Pi Board]]

 

 

Do you still have the SD card with the original Raspian image on it from when you where testing the hardware above? Great. So you already have a SD card with a boot partition and the required files. If not then download one of the original Raspberry boot images and copy them to the SD card.

Now mount the first partition from the SD card and look at it:

 

bootcode.bin fixup.dat kernel.img start.elf

cmdline.txt fixup_cd.dat kernel_cutdown.img start_cd.elf

Note: The GPU also initialized the video ouput, detecting the right resolution from the monitor (if hdmi) or from the config.txt and creates a 2x2 pixel framebuffer (red, yellow, blue and cyan pixels) that the hardware scales to fullscreen with color interpolation. So you get rectangle with a nice color fading.

 

 

The RPi boots the kernel directly from an SD card and only from an SD card. There is no other option. While developing this becomes tiresome since one has to constantly swap the SD card from the RPi to a SD card reader and back. Writing the kernel to the SD card over and over also wears out the card. Plus the SD card slot is somewhat fragile; several people have reported that they broke it accidentally. Overall not an ideal solution. So what can we do about that?

Raspbootin is completely transparent for your kernel. It preserves the r0, r1 and r2 registers and ATAGs placed into memory by the GPU for your kernel. So whether you boot your kernel directly from an SD card or with Raspbootin via serial port makes no difference to your code.

 

 

You don't have to care about this unless you want to write your own boot server.

The boot protocol for Raspbootin is rather simple. Raspbootin first sends 3 breaks (<code>\x03</code>) over the serial line to signal that it is ready to receive a kernel. It then expects the size of the kernel as <code>uint32_t</code> in little endian byte order. After the size it replies with "<code>OK</code>" if the size is acceptable or "<code>SE</code>" if it is too large for it to handle. After "<code>OK</code>" it expects <code>size</code> many bytes representing the kernel. That's it.

 

 

A good documentation for ATAGs can be found [http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html#appendix_tag_reference here].

[https://www.devicetree.org/ Device Tree Specification]

 

 

On boot the RPi configures a display with a virtual resolution of 2x2 pixel scaled to full screen. Each pixel has a different color and the hardware scaling interpolates the colors to show a nice color fade. So before you do anything first connect a monitor and see to it that you get some output.

 

 

Start with a single simple querry at first and then build up more complex mails. If you get it working then I recommend just altering the virtual size and color depth and leaving the physical resolution as is. The RPi seems to do a fine job of detecting the monitor and the user can also configure a resolution in the boot config files on the SD card. Best to honor his wishes.

 

 

By default the exception vector table on ARM starts at 0x0. You can use that but there are better ways. You can set a flag to use a high vector at 0xffff0000 or set the exception vector base address register to point to your own table anywhere (32 byte aligned) you like.

When configuring some peripheral to send an interrupt it is a useful thing to have interrupts disabled in the CPSR, enable the interrupt you are interested in (or all) in the 3 interrupt enable registers and then poll the 3 pending registers in a tight loop and output changes. This allows you to see if the peripheral raises an interrupt and (if in doubt) which one. After that the real interrupt handler can be configured and tested. Gives you a nice half way point to test what you have so far.

 

 

To be able to use any floating point operations, such as storing or loading floating point numbers, you need to enable the FPU before using it. To do this, you have to enable access to the coprocessor to whoever should be able to use it, and you have to enable the FPU itself.

 

 

And then enable the FPU itself:

 

 

The third line is the actual instruction that you'd want to use, but due to a bug in Binutils 2.23 it does not assemble. The line below it is what it should assemble to, and replaces the opcode. After doing these two, it's possible to use the FPU.

 

 

A standalone BSD-licenced USB driver with support for keyboard and mouse is available here: https://github.com/Chadderz121/csud . This driver can be kept stand-alone, by editing the <code>/source/platform.c</code> file to interface the driver with your implementation of <code>malloc()</code> and similar functions, or you can integrate the driver more closely with your operating system.

 

# [https://www.scss.tcd.ie/~waldroj/3d1/arm_arm.pdf arm_arm.pdf] - General ARM Architecture Reference Manual v6

# [http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf DDI0301H_arm1176jzfs_r0p7_trm.pdf] - More specific ARM for the RPi

 

[[Category:ARM]]