First Look
Couple of days a go I received my raspberry pi, pre-ordered a month before.
In dimension, it exactly matches the size of my credit card, as they said. By finishing and clarity of the device, it is average, but no one will give such a board at such cost. Realy appricatlabe designing which looks worth and logical for usablity and to reduce cost. Few of appreciating designs are:
- Power supply by mini usb (worth as I already had my Mobile charger with rating of 5V-700mA)
- Searial connection through expansion pins
- No power on/off button
- JTAG and SD card muxed to same pins
- 1st level of booting only through SD card, so you would be happy that you will not brick your board during development work.
I couldn't get detailed internals for the BCM2835 Soc, which disappointed me.
Lets Explore the device
Lets 1st try to understand how booting sequence goes on in the board, you may get these information from raspberry pi forum.
- When device is powered on, only GPU core gets turned on (ARM core, SDRAM and SD card controller is still off state)
- Bootloader from BCM2385 Soc ROM starts executing and scans SD card for bootcode.bin
- Here chain loading sequence is observed with broadcom firmware. ROM BL loads bootcode.bin as first bootloader, visible to user and present in FAT32 partition of SD card, to L2 cache. (note that SDRAM is still off and not available). So you can say, 1st stage initiates communication with SD card controller and also understands FAT32 file system only, as like many other 1st stage bootloader I have seen.
- bootcode.bin now enables SDRAM and loads loader.bin which basically understands elf format.
- loader.bin then loads start.elf at top of memory. Till this point nothing is visible in bootlog message.
- start.elf then does its jobs like split memory between ARM CPU and GPU, reads commandline.txt for getting information of root partition, its format and kernel parameters. I guess start.elf turns on peripherals for console/display. As start.elf could show some colourful screen through HDMI, which seams un-initialized. I guess here display subsystem is mapped to RAM memory area.
- start.elf program finds and loads kernel.img from root partition to SDRAM. Till this time, all instructions were running in GPU core.
- Now control goes to ARM core to execute kernel image.
In short: GPU core(GPU start) -> BL from Soc ROM -> bootcode.bin -> loader.bin -> start.elf(GPU end) -> (CPU start) kernel.img
This boot sequence is fundamentally same across different board, but the way start.elf reads cmdline.txt, it shows similarity with GRUB BL.
We can play with our code only from kernel.img file or later. It is better if can put u-boot in the system to have more fun were we can do debugging traces.
Running Linux into the board
So now lets start with how to start porting Linux into the board:
Take appropriate SD card as in raspberry specification. Format it to FAT32 bootable format.
$ mkfs.vfat /dev/mmcxxxx
Now make two partitions in mmc card, one for boot device as FAT32 file system and another root partition as ext4 file system.
/boot -- in FAT32 format to keep raspberry GPU firmwares, bootcode.bin, loader.bin, start.elf and kernel directive file cmdline.txt.
/root -- proper root device should be mentioned cmdline.txt file.
We need certain toolchains to cross compile linux into Ubuntu OS.
Install git and the cross-compilation toolchain:
$ sudo apt-get install git-core gcc-4.6-arm-linux-gnueabi
Make a directory for the sources and tools, then clone them with git:
$mkdir raspberrypi
$cd raspberrypi
$git clone https://github.com/raspberrypi/tools.git
$git clone https://github.com/raspberrypi/linux.git
$cd linux
Generate the .config file from the pre-packaged raspberry pi one:
$make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- bcmrpi_cutdown_defconfig
For doing any configuration changes, open configuration menu and mark your changes,
$make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- menuconfig
Once configuration file is prepared, start compiling kernel for r-pi device,
$make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -k -j5
mkdir ../modules
Then compile and ‘install’ the loadable modules to the temp directory:
$make modules_install ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- INSTALL_MOD_PATH=../modules/
Now we need to use imagetool-uncompressed.py to generate un-compressed kernel image for r-pi.
See below for necessary download links
$cd ../tools/mkimage/
$./imagetool-uncompressed.py ../../linux/arch/arm/boot/Image
Here you will find generated kernel.img.
Now we can copy kernel.img in mmc card.
$sudo cp -f kernel.img /media/<boot partition>/
Now copy generated library and firmwares from modules directory to mmc
$cd ../../modules/
$sudo cp -rf lib/ /media/<boot partition >/lib/
$sync
Now put mmc card into the r-pi mmc slot and power-on the device. HDMI cable was my 1st preference to see the output message, as my serial setup was not working initially. To get minimum indication of your source code execution, observe green led, next to red power led in r-pi board. If your instructions are executing, then you will see continuous blinks of green led.
So, if you see you kernel message, you are done with one stage, now you have to move ahead to execute user space code. Well hopefully in the end of above code execution, you might see kernel panic as your kernel would not be able to find root partition if you are not done with it.
Raspberry Pi on QEMU
Install latest QEMU version in your system. I have verified support in QEMU v1.5.
# qemu-system-arm -cpu ?|grep arm11
If you find arm1176 in list then you have support for rpi in qemu.
Download arch linux from raspberry pi official site and verify if it boots well.
# qemu-system-arm -cpu arm1176 -kernel kernel-qemu -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=0" -hda archlinux-hf-2013-02-11.img
If it boots then it is allright to go for your custom image. Just use same arch linux image, mount at some place and use your custom kernel, or boot loader, or library.
Link: http://www.v13.gr/blog/?p=276
Follow https://github.com/raspberrypi/ link and download most of the required tools,
$git clone git://github.com/raspberrypi/tools.git
$git clone git://github.com/raspberrypi/linux.git
$git clone git://github.com/gonzoua/u-boot-pi.git
$git clone https://github.com/raspberrypi/firmware/
http://kernelnomicon.org/?m=201205
http://wiki.gentoo.org/wiki/Raspberry_Pi
References: http://raspberrypi.org/phpBB3/viewtopic.php?f=63&t=6685
Couple of days a go I received my raspberry pi, pre-ordered a month before.
In dimension, it exactly matches the size of my credit card, as they said. By finishing and clarity of the device, it is average, but no one will give such a board at such cost. Realy appricatlabe designing which looks worth and logical for usablity and to reduce cost. Few of appreciating designs are:
- Power supply by mini usb (worth as I already had my Mobile charger with rating of 5V-700mA)
- Searial connection through expansion pins
- No power on/off button
- JTAG and SD card muxed to same pins
- 1st level of booting only through SD card, so you would be happy that you will not brick your board during development work.
I couldn't get detailed internals for the BCM2835 Soc, which disappointed me.
Lets Explore the device
Lets 1st try to understand how booting sequence goes on in the board, you may get these information from raspberry pi forum.
- When device is powered on, only GPU core gets turned on (ARM core, SDRAM and SD card controller is still off state)
- Bootloader from BCM2385 Soc ROM starts executing and scans SD card for bootcode.bin
- Here chain loading sequence is observed with broadcom firmware. ROM BL loads bootcode.bin as first bootloader, visible to user and present in FAT32 partition of SD card, to L2 cache. (note that SDRAM is still off and not available). So you can say, 1st stage initiates communication with SD card controller and also understands FAT32 file system only, as like many other 1st stage bootloader I have seen.
- bootcode.bin now enables SDRAM and loads loader.bin which basically understands elf format.
- loader.bin then loads start.elf at top of memory. Till this point nothing is visible in bootlog message.
- start.elf then does its jobs like split memory between ARM CPU and GPU, reads commandline.txt for getting information of root partition, its format and kernel parameters. I guess start.elf turns on peripherals for console/display. As start.elf could show some colourful screen through HDMI, which seams un-initialized. I guess here display subsystem is mapped to RAM memory area.
- start.elf program finds and loads kernel.img from root partition to SDRAM. Till this time, all instructions were running in GPU core.
- Now control goes to ARM core to execute kernel image.
In short: GPU core(GPU start) -> BL from Soc ROM -> bootcode.bin -> loader.bin -> start.elf(GPU end) -> (CPU start) kernel.img
This boot sequence is fundamentally same across different board, but the way start.elf reads cmdline.txt, it shows similarity with GRUB BL.
We can play with our code only from kernel.img file or later. It is better if can put u-boot in the system to have more fun were we can do debugging traces.
Running Linux into the board
So now lets start with how to start porting Linux into the board:
Take appropriate SD card as in raspberry specification. Format it to FAT32 bootable format.
$ mkfs.vfat /dev/mmcxxxx
Now make two partitions in mmc card, one for boot device as FAT32 file system and another root partition as ext4 file system.
/boot -- in FAT32 format to keep raspberry GPU firmwares, bootcode.bin, loader.bin, start.elf and kernel directive file cmdline.txt.
/root -- proper root device should be mentioned cmdline.txt file.
We need certain toolchains to cross compile linux into Ubuntu OS.
Install git and the cross-compilation toolchain:
$ sudo apt-get install git-core gcc-4.6-arm-linux-gnueabi
Make a directory for the sources and tools, then clone them with git:
$mkdir raspberrypi
$cd raspberrypi
$git clone https://github.com/raspberrypi/tools.git
$git clone https://github.com/raspberrypi/linux.git
$cd linux
Generate the .config file from the pre-packaged raspberry pi one:
$make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- bcmrpi_cutdown_defconfig
For doing any configuration changes, open configuration menu and mark your changes,
$make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- menuconfig
Once configuration file is prepared, start compiling kernel for r-pi device,
$make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -k -j5
mkdir ../modules
Then compile and ‘install’ the loadable modules to the temp directory:
$make modules_install ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- INSTALL_MOD_PATH=../modules/
Now we need to use imagetool-uncompressed.py to generate un-compressed kernel image for r-pi.
See below for necessary download links
$cd ../tools/mkimage/
$./imagetool-uncompressed.py ../../linux/arch/arm/boot/Image
Here you will find generated kernel.img.
Now we can copy kernel.img in mmc card.
$sudo cp -f kernel.img /media/<boot partition>/
Now copy generated library and firmwares from modules directory to mmc
$cd ../../modules/
$sudo cp -rf lib/ /media/<boot partition >/lib/
$sync
Now put mmc card into the r-pi mmc slot and power-on the device. HDMI cable was my 1st preference to see the output message, as my serial setup was not working initially. To get minimum indication of your source code execution, observe green led, next to red power led in r-pi board. If your instructions are executing, then you will see continuous blinks of green led.
So, if you see you kernel message, you are done with one stage, now you have to move ahead to execute user space code. Well hopefully in the end of above code execution, you might see kernel panic as your kernel would not be able to find root partition if you are not done with it.
Raspberry Pi on QEMU
Install latest QEMU version in your system. I have verified support in QEMU v1.5.
# qemu-system-arm -cpu ?|grep arm11
If you find arm1176 in list then you have support for rpi in qemu.
Download arch linux from raspberry pi official site and verify if it boots well.
# qemu-system-arm -cpu arm1176 -kernel kernel-qemu -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=0" -hda archlinux-hf-2013-02-11.img
If it boots then it is allright to go for your custom image. Just use same arch linux image, mount at some place and use your custom kernel, or boot loader, or library.
Link: http://www.v13.gr/blog/?p=276
Links
- Porting:http://www.sparkfun.com/tutorials/372
- Serial interface: Serial communication with Raspberry Pi
- GPIO Expansion: element14, elinux
- u-boot: http://kernelnomicon.org/
Downloads
Follow https://github.com/raspberrypi/ link and download most of the required tools,
$git clone git://github.com/raspberrypi/tools.git
$git clone git://github.com/raspberrypi/linux.git
$git clone git://github.com/gonzoua/u-boot-pi.git
$git clone https://github.com/raspberrypi/firmware/
http://kernelnomicon.org/?m=201205
http://wiki.gentoo.org/wiki/Raspberry_Pi
References: http://raspberrypi.org/phpBB3/viewtopic.php?f=63&t=6685
No comments:
Post a Comment