FirefoxOS/RPiB2
Contents
State of the project
READ FIRST
This project is officially on HOLD. It will be active again after transition branch is completely merged. If you want to know more details about this project and next steps, please check this blog post
About The Project
We are looking to demonstrate that Firefox OS can be a viable and valuable operating system for a range of development boards and hardware related to IoT
This page describes how to install Firefox OS in a Raspberry Pi B+ 2 running, without a Linux distribution installation previously. This is not Firefox OS running on top of Raspbian, this is a clean and full rom based on Android (as the ones running on phones).
WARNING: this guide is specific for the Raspberry PI B+ 2, older models have a different chipset and newest model have not been tested.
The initial goal is release a downloadable and flashable version of Firefox OS for Raspberry Pi B+ 2 board and a step by step guide to let everybody create their our roms using the B2G build system. The meta bug for this project is bug 1225139
Project Management Team
| Name | Role | Email address |
|---|---|---|
| Dietrich Ayala | Project Manager | dietrich@mozilla.com |
| Giovanny Gongora | Porting Developer | gioyik@mozilla.com |
What We'd Like To See Happen
- Start the path of the new strategy Connected Devices with this port
- Let the community be part of the success in this project.
- Bring RPi users more options (operating systems) for their next project
- Push the Web of things forward
- Enable programmers (via DOM/CSS) to develop robotics and other IoT projects
Limitations
- VC4 driver is still on development
- Sometimes slow and buggy
- Not all device capabilities are exposed through Web APIs
- Small/integrated display not planned to support soon
Development Sprints
This is a 6 months project, starting November 2015 and finishing April 2016. The project is divided in two Sprints each one of 3 months.
Sprint A
In the first three months I will divide them in 3 phases. The main goal for this Q1 is have at the end a full build of Android Lollipop running in the Raspberry PI to continue with the port of Firefox OS components.
Phase 1
- Prepare for Android Lollipop [DONE]
- Identify the product name, code name, architecture, memory size, internal storage size, and platform architecture of the RPI 2. Collect any available existing source code to be used to make a build and add support for more hardware components.
- Start AOSP tree for RPI 2 [DONE]
- Generate the folders for RPI 2 device configuration
- Android devices files for RP2 [DONE]
- B2G build system uses AOSP that requires a repo with device configuration. Folder and files like AndroidBoard.mk, AndroidProducts.mk, BoardConfig.mk, device_rpi2.mk, recovery.fstab, and more will be created or adapted to RPI 2 architecture
- Make RPI 2 kernel build from source [DONE]
- Create a sync configuration for BoardConfig.mk file to build the kernel and any required kernel modules automatically.
- Create manifest file for RPI 2 [DONE]
- Create the rpi2.xml in b2g-manifest with all the sources for the first build
Phase 2
- Add libraries [DONE]
- In the device specific files during compilation process there are necessary includes to specific libraries
- Configure modules [DONE]
- In the device specific files is necessary to add external modules/files to be compiled and binary generated
- Kernel configuration for RPI 2 [DONE]
- Create a configuration specially for RPI 2 hardware components and ARM support
Phase 3
- Generate working build [DONE]
- Generate a first booting copy of Android Lollipop
- Automated Android builds server [WORKING]
- Jenkins or TaskCluster running to make automated builds of Android for the RPI 2.
- Update documentation [DONE]
- Update building steps and requirements with new ones for Raspberry PI 2
Sprint B
The next three months will divided in 4 phases. The main goal for Q2 is have a stable Firefox OS build with most of the hardware in the Raspberry supported (not fully support expected) and some tweaks for the UI to make it desktop friendly.
Phase 1
- Gecko Port [DONE]
- Having a basic Android base system the next priority is get Gecko working. This will help to identify easily more problems in the final ROM
- Graphics support [DONE]
- Use hardware default renderer.
- In this project there is a challenge, and that’s the correct graphics support. RPI 2 has a VideoCore with a Broadcom BCM2739 that changed a lot in this latest version of the RPI 2. Will be necessary take a look of Broadcom reference guides
- Update documentation [DONE]
- Create page about Firefox OS architecture on the Raspberry PI 2
Phase 2
- Input support [PARTIAL DONE]
- Keyboard and mouse support is one of the P1 for Raspberry PI port. The basic support for Keyboard would be on early stages of Android building.
- Mouse support: https://bugzilla.mozilla.org/show_bug.cgi?id=1082892
- Storage support [DONE]
- Add support to SD Card recognition and USB storage devices
- Connection support [PARTIAL DONE]
- Work on WiFi and Ethernet support and add listeners for every time you plug or unplug it to the board. Usually it recognizes Ethernet connection if is connected before booting.
- ADB Push [DONE]
- Enable support to push apps by ADB connection
Phase 3
- Generate complete/stable/usable Firefox OS build [DONE]
- After all the base system is working and running, I will create builds to distribute and publish them.
- Flashing files [DONE]
- The Raspberry PI could not be flashed correctly with common Fastboot method, is necessary to create a filesystem that will be copied to the SD card
- Update documentation [DONE]
- Update flashing guide with steps for Raspberry PI 2
Phase 4
- Gaia Port [DONE]
- The Gaia port will be ready only when the graphics support is done, added to this, maybe will be some display/resolution limitations if the graphic support is not fully implemented or there are missing parts.
- Remove unnecessary apps
- Apps like Radio, Dialer, Messages and others are not necessary due Raspberry PI 2 itself doesn’t have hardware components to be used with those apps.
- NOOBS installer [DONE]
- Add support to install B2G using NOOBs installer
- Update documentation [WORKING]
- Blog post on Hacks Blog
Build From Source
Install the b2g build prerequisites. For the time being, only linux is officially supported as a build environment; you can use OS X but you'll have to manually partition your RPi's SD card for the first flash. Note that Ubuntu 12.04 is the best-supported development OS. If you're not running Ubuntu 12.04 on your development machine, you can install it as virtual machine and build in there. A b2g build environment consumes a fair amount of disk space, between 15-20 GB. Please make sure you have enough free space on your development machine (or VM).
Be sure of have those libraries installed to avoid compiling problems. On Ubuntu would be:
sudo apt-get install libfontconfig1 libXrender1 libXcomposite1 libgtk2.0-0 libxt6 unzip python-pip gettext libasound2
Installing pip dependencies for LibMesa:
pip install Mako --upgrade
To build b2g for your Raspberry Pi B+ 2, first download the b2g helper scripts
git clone https://github.com/mozilla-b2g/B2G.git
Next configure b2g for your Raspberry Pi B+ 2
cd B2G ./config.sh rpi2b-l
The config.sh step can take quite a while, because it downloads a large amount of data. Finally, build b2g
./build.sh
This step also takes some time, because it's building an entire operating system. When your build finishes, it's time to flash it onto an SD card for your RPi.
Prepare To Flash
WARNING: The process described here will erase all the data in your SD card. Be sure of not lose sensitive data inside the card.
You need a 4Gb SD card at least, if has more space better. Then create partitions and copy the files to let the Raspberry PI boot Firefox OS.
Configure UDEV rules for the SD card
By configuring udev rules for the specific SD card you are going to use for B2G, you will avoid the need to pass via root access (e.g., sudo dd) to be able to copy data. This also limits the risks of doing dd to the wrong device and mess with everything. This is documented for use with a sd card integrated reader, but this should be able to work elsewhere.
First, plug your sdcard and identify its serial:
$ udisksctl status MODEL REVISION SERIAL DEVICE -------------------------------------------------------------------------- [...] SL08G 0xa0442a9f mmcblk0
So in this case, /dev/mmcblk0 has serial number 0xa0442a9f. You can now unplug the card for now.
The populate a file in /etc/udev/rules.d/, let be its name 52-mmcblk.rules. And put the following content:
# µSD B2G
SUBSYSTEM=="block", SUBSYSTEMS=="mmc", DRIVERS=="mmcblk", ATTRS{serial}=="0xa0442a9f", MODE="0666", GROUP="plugdev"
Make sure you have ATTRS{serial}=="0xa0442a9f". Rule will match any mmcblk exposed device whose attribute serial is 0xa0442a9f. If it matches, then it will set permissions 0666 and group plugdev. Save this file, and issue a udev reload:
# udevadm control --reload
Now, if you replug the sdcard, it should be set with the proper permissions in /dev.
Partitions for the SD card
Create 4 partitions in next order and be careful with the sized of each one.
boot (Partition 1) = Size [48MB] = Format as fat32, tag bootable flag system (Partition 2) = Size [537MB] = Format as new primary partition or ext4 cache (Partition 3) = Size [512MB] = format as ext4 data (Partition 4) = Size [Rest of free space] = format as ext4
Installing on the SD card
For a first time installation, you will have to flash all partitions. Images have been produced in the out/target/product/rpi2b directory and you should flash:
- boot.img to Partition 1
- system.img to Partition 2
- cache.img to Partition 3
- userdata.img to Partition 4
Please proceed with the dd command (and replace file with the proper file name):
dd if=file of=/dev/XpY bs=1m
Be sure of check that everything is copied successfully on the partition. For this port we create a userdebug build, so, everything is inside system image. Usually, X will be the name of your device and pY should be replaced by the partition number. For example, a SD card reader might expose this as: /dev/mmcblk0p1 for boot partition (Partition 1).
Remember to NOT flash cache and/or userdata images if you are just updating your system, except if you are sure or instructed to do so. Doing this will result in your data being erased.
Faster flashing
You can also make use of bmaptool to flash faster than with dd. bmaptool repo.
Produce bmap files
Once you have built the system, produce bmap files:
$ bmaptool create -o out/target/product/rpi2b/PARTITION.bmap out/target/product/rpi2b/PARTITION.img
You can do this for each PARTITION that we have: boot, system, cache and userdata.
Flashing with bmaptool
Then flash using bmaptool (here only boot partition):
$ sudo bmaptool copy out/target/product/rpi2b/boot.img /dev/mmcblk0p1 bmaptool: info: discovered bmap file 'out/target/product/rpi2b/boot.bmap' bmaptool: info: block map format version 2.0 bmaptool: info: 12288 blocks of size 4096 (48.0 MiB), mapped 2358 blocks (9.2 MiB or 19.2%) bmaptool: info: copying image 'boot.img' to block device '/dev/mmcblk0p1' using bmap file 'boot.bmap' bmaptool: info: 100% copied bmaptool: info: synchronizing '/dev/mmcblk0p1' bmaptool: info: copying time: 0.6s, copying speed 16.1 MiB/sec
Using dd on the same partition reports a write speed of 5.0MiB/s.
Debugging
The Raspberry Pi serial port consists of two signals (a 'transmit' signal, TxD and a 'receive' signal RxD) made available on the GPIO header. To connect to another serial device, you connect the 'transmit' of one to the 'receive' of the other, and vice versa. You will also need to connect the Ground pins of the two devices together.
If you wish to connect your Pi to a PC with a USB port, the simplest option is to use a USB-to-serial cable which uses 3.3V logic levels (e.g. the Adafruit 954 cable, the FTDI TTL-232R-RPI cable, or the Debug Buddy ultimate serial port). These can be simply plugged in directly to the GPIO header (see illustration).
- For using the Adafruit 954 cable on Windows, see Adafruit 954 USB serial cable.
Linux terminal set up
If your PC is running Linux, you will need to know the port name of its serial port:
- Built-in (standard) Serial Port: the Linux standard is /dev/ttyS0, /dev/ttyS1, and so on
- USB Serial Port Adapter: /dev/ttyUSB0, /dev/ttyUSB1, and so on.
- Some types of USB serial adapter may appear as /dev/ttyACM0 ...
You will need to be a member of the dialout group to access this port (for later releases the required group is tty). You can check which is needed with:
ls -l /dev/ttyUSB0
and you will see something like "crw-rw----T 1 root dialout ...", c means character device, and root can 'read,write' and the group dialout can 'read,write' to the port and everyone else cannot access it.
To find out if you, the current user, is in the group dialout, use the command:
id
If you do not see dialout listed, add yourself with the command
sudo usermod -a -G dialout username
You then have a choice of terminal emulation programs:
Using GNU Screen
Enter the command below into a terminal window
screen port_name 115200
To exit GNU screen, type Control-A k.
Using Minicom
Run minicom with the following parameters:
minicom -b 115200 -o -D Port_Name
You can exit minicom with Control-A x
Windows terminal set-up
Users of Windows Vista or later will need to download a terminal program, for instance PuTTY, or TeraTerm. Users of XP and below can choose between using PuTTY and the built-in Hyperterminal.
PuTTY users simply need to choose 'serial', select the correct COM port and set the speed, as shown in the dialog below.
If you are unsure of the COM port, run [Device Manager] and look under 'Ports'. USB-attached serial adapters should have the name of the adapter shown (the Adafruit cable comes up as 'Prolific USB-to_Serial Comm Port'.
Mac OS X terminal set-up
OSX includes terminal emulation software that you can use from the command line, so we only need to install the USB drivers for the cable.
[Check out the most recent Mac Driver from prolific]
If using Lion or Mountain Lion or later OS X, try this driver here http://changux.co/osx-installer-to-pl2303-serial-usb-on-osx-lio
Both downloads are standard Mac installers. Accept all defaults when prompted.
Using Screen
Open a Terminal window and issue the command:
screen /dev/cu.usbserial 115200
The device will have a slightly different name to mine. So, type the line above as far as "cu." then press the TAB key to auto-complete to whatever your device is called, before adding 115200 (which is the baud rate) to the end.
Connect All The Things
The Console lead has four female connections that can be plugged directly onto the GPIO header of the Raspberry Pi. The Adafruit USB console cable has 3.3V logic, so its safe to use with your Pi.
For this experiment, the serial lead is going to power the Raspberry Pi. So, DO NOT attach the Pi's USB power adapter. If you would rather power the Pi from your USB power adapter then leave the Red lead from the Serial lead un attached.
The important thing here is to only power it from one source, the USB power adaptor or the Console Lead BUT NOT BOTH.
Attach the leads as shown below:
The connections are to the outside pin connections of the GPIO header.
- The red lead should be connected to 5V,
- The black lead to GND,
- The white lead to TXD.
- The green lead to RXD.
Now plug in the USB lead and you will see the Pi's power LED should light.
Boot messages
If your connection is set up correctly, when the Pi is booted you should see many messages as the system comes up:
Uncompressing Linux... done, booting the kernel. [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.2.27+ (dc4@dc4-arm-01) [ 0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache [ 0.000000] Machine: BCM2708 [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 113792
and so on. Eventually, you should see a login prompt:
shell@rpi2b:/ $
You can then log in as you would with a keyboard and screen.
Keeping Log Copy
If you are debugging, maybe you will be interested on keep a copy of the logs. If you are using screen you can do it adding -L flag. For example:
screen -L /dev/cu.usbserial 115200
Then you will have a file named screenlog.0 with a record of all the logs you got when you run screen command.
Need Help?
- IRC channel #fxos (Ping Gioyik)
- Fill a bug on bugzilla
- Send an email to fxos mailing list
