zydronium/documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Adjust for HiKey

Browse source
This commit is contained in:
Fathi Boudra 2016-07-02 10:08:42 +03:00 • committed by GitHub
parent 861c7b098e
commit 8ea9689f57
1 changed files with 60 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

99
Reference-Platform/CECommon/OEYocto.md
View file

@ -1,6 +1,6 @@
## OpenEmbedded and Yocto
This page provides instructions to get started with OpenEmbedded and the Yocto Project on the DragonBoard 410c.
This page provides instructions to get started with OpenEmbedded and the Yocto Project on the DragonBoard 410c and HiKey.
# Introduction
@ -13,23 +13,27 @@ In this wiki, we assume that the reader is familiar with basic concepts of OpenE
The support for DragonBoard 410c is available in the [meta-qcom BSP layer](http://git.yoctoproject.org/cgit/cgit.cgi/meta-qcom).
This layer has been tested with OpenEmbedded Core layer, and is expected to work with any other standard layers and of course any OpenEmbedded based distributions.
The support for HiKey is available in the [meta-96boards BSP layer](https://github.com/96boards/meta-96boards).
The Linux kernel used for the DragonBoard 410c is the Linaro Landing team kernel, e.g. the same kernel used for the Linaro Linux release builds. The graphic stack is based on mesa, using the freedreno driver.
These layers have been tested with OpenEmbedded Core layer, and are expected to work with any other standard layers and of course any OpenEmbedded based distributions.
The Linux kernel used for these boards is the Reference Platform Kernel (RPK). The graphic stack is based on mesa:
* using the freedreno driver for Dragonboard 410c
* using the ARM Mali Utgard GPU driver for HiKey
## OE Layers
| Layer | Description |
|:-----------------------:|:----------------------|
| OE-Core (Base layer) | This is the main collaboration point when working on OpenEmbedded projects and is part of the core recipes. The goal of this layer is to have just enough recipes to build a basic system, this means keeping it as small as possible. |
| Meta-rpb (Distro layer) | This is a very small layer where the distro configurations live. Currently it houses both Reference Platform Build and Wayland Reference Platform Builds. |
| Meta-oe | This layer houses many useful, but sometimes unmaintained recipes. Since the reduction in recipes to the core, meta-oe was created for everything else. There are currently approximately 650 recipes in this layer. |
| Meta-browser | This layer holds the recipes for Firefox and Chromium. Both recipes require a lot of maintenance, because of this a seperate layer was created. |
| Meta-qt5 | This is a cross-platform toolkit. |
| Meta-linaro | This layer is used to get the Linaro toolchain. |
| Meta-linaro-backports | This is an experimental layer used to get newer versions into the build which were not part of the release. |
| Meta-96Boards | This support layer is managed by Linaro and intended for boards that do not have their own board support layer. Currently used for the HiKey Consumer edition board, and eventually the Bubblegum-96 board. If a vendor does not support their own layer, it can be added to this layer. |
| Meta-qcom (BSP) | This is the board support layer for Qualcomm boards. Currently supports IFC6410 and the DragonBoard 410c. |
| oe-core (Base layer) | This is the main collaboration point when working on OpenEmbedded projects and is part of the core recipes. The goal of this layer is to have just enough recipes to build a basic system, this means keeping it as small as possible. |
| meta-rpb (Distro layer) | This is a very small layer where the distro configurations live. Currently it houses both Reference Platform Build and Wayland Reference Platform Builds. |
| meta-oe | This layer houses many useful, but sometimes unmaintained recipes. Since the reduction in recipes to the core, meta-oe was created for everything else. There are currently approximately 650 recipes in this layer. |
| meta-browser | This layer holds the recipes for Firefox and Chromium. Both recipes require a lot of maintenance, because of this a seperate layer was created. |
| meta-qt5 | This is a cross-platform toolkit. |
| meta-linaro | This layer is used to get the Linaro toolchain. |
| meta-linaro-backports | This is an experimental layer used to get newer versions into the build which were not part of the release. |
| meta-96Boards | This support layer is managed by Linaro and intended for boards that do not have their own board support layer. Currently used for the HiKey Consumer Edition board, and eventually the Bubblegum-96 board. If a vendor does not support their own layer, it can be added to this layer. |
| meta-qcom (BSP) | This is the board support layer for Qualcomm boards. Currently supports IFC6410 and the DragonBoard 410c. |
# Package Dependencies
@ -70,7 +74,7 @@ All required dependencies should now be installed on your host environment, you
# Setup the build environment
The Qualcomm BSP layer can be used with any OE based distribution, such as Poky. The following instructions are provided to get started with 96boards Open Embedded Reference Software Platforms.
The BSPs layesr can be used with any OE based distribution, such as Poky. The following instructions are provided to get started with OpenEmbedded Reference Software Platforms.
To manage the various git trees and the OpenEmbedded environment, a repo manifest is provided. If you do not have `repo` installed on your host machine, you first need to install it, using the following instructions (or similar):
@ -81,13 +85,13 @@ To manage the various git trees and the OpenEmbedded environment, a repo manifes
To initialize your build environment, you need to run:
mkdir oe-qcom && cd oe-qcom
mkdir oe-rpb && cd oe-rpb
repo init -u https://github.com/96boards/oe-rpb-manifest.git -b jethro
repo sync
source setup-environment [<build folder>]
* after the command `repo sync` returns, all the OpenEmbedded recipes have been downloaded locally.
* you will be prompted to choose the target machine, pick `dragonboard-410c`
* you will be prompted to choose the target machine, pick `dragonboard-410c` or `hikey`
* you will be prompted to choose the distro, for now, it is recommended to use 'rpb'
* <build folder> is optional, if missing it will default to `build-$DISTRO`
@ -99,20 +103,24 @@ To build a console image, you can run:
$ bitbake rpb-console-image
At the end of the build, your build artifacts will be found in `tmp-eglibc/deploy/images/dragonboard-410c`. The two artifacts you will use to update your DragonBoard are:
* `rpb-console-image-dragonboard-410c.ext4.gz` and
* `boot-dragonboard-410c.img`
At the end of the build, your build artifacts will be found under `tmp-eglibc/deploy/images/MACHINE/`. The two artifacts you will use to update your board are:
* `rpb-console-image-MACHINE.ext4.gz` and
* `boot-MACHINE.img`
where `MACHINE` is `dragonboard-410c` or `hikey`.
# Bootloaders and eMMC partitions
Build artifacts from your OE build will be flashed into the DragonBoard's on-board eMMC (in contrast to some other boards which run their images from an SDcard). The OpenEmbedded BSP layer assumes that the _Linux_ Bootloaders and eMMC partition layout are used on the DragonBoard 410c (not the _Android_ ones; by default DragonBoards come pre-configured with the Android eMMC partition layout). You can download the latest Linux bootloader package from [here](http://builds.96boards.org/releases/dragonboard410c/linaro/rescue/latest/) to your development host, it will be named something like `dragonboard410c_bootloader_emmc_linux-<version>.zip`.
Build artifacts from your OE build will be flashed into the on-board eMMC (in contrast to some other boards which run their images from an SDcard). The OpenEmbedded BSP layer assumes that the _Linux_ Bootloaders and eMMC partition layout are used on the board (not the _Android_ ones; by default DragonBoards come pre-configured with the Android eMMC partition layout). You can download the latest Linux bootloader package for Dragonboard 410c from [here](http://builds.96boards.org/releases/dragonboard410c/linaro/rescue/latest/) to your development host, it will be named something like `dragonboard410c_bootloader_emmc_linux-<version>.zip`.
Whether your DragonBoard is using the Android eMMC partition layout or the Linux partition eMMC layout, you will use the Android `fastboot` utility on your development host for managing the board's eMMC partitions. If you are using a relatively recent Linux distribution on your development host, it probably already has a package that includes the `fastboot` utility (it might be named something like `android-tools` or `android-tools-fastboot`) so go ahead and install it on your development host. In order for your development host's fastboot utility to interact with the DragonBoard, the DragonBoard must be booted into a special `fastboot mode`. The procedure to do so is as follows:
* remove power from your DragonBoard
Whether your board is using the Android eMMC partition layout or the Linux partition eMMC layout, you will use the Android `fastboot` utility on your development host for managing the board's eMMC partitions. If you are using a relatively recent Linux distribution on your development host, it probably already has a package that includes the `fastboot` utility (it might be named something like `android-tools` or `android-tools-fastboot`) so go ahead and install it on your development host. In order for your development host's fastboot utility to interact with the board, in the case of the DragonBoard 410c, it must be booted into a special `fastboot mode`. The procedure to do so is as follows:
* remove power from your DragonBoard 410c
* plug a USB cable from your development host to your DragonBoard's J4 connector
* while holding down S4 on the DragonBoard (the one marked "(-)"), insert the power adapter
* while holding down S4 on the DragonBoard 410c (the one marked "(-)"), insert the power adapter
* after a few seconds you can release S4
In the case of case of HiKey, see `TBA` (put a link to Debian instructions, they are the same).
To verify your cables and that the above procedure worked, on your development host run:
# sudo fastboot devices
@ -122,7 +130,7 @@ and you should get a non-empty response, e.g.
# sudo fastboot devices
83581d40 fastboot
If this is your first time using a particular DragonBoard, you will need to switch its eMMC partition layout to the Linux layout, but this procedure only needs to be done once for a given board. After switching your layout, you only have to update your board with your latest build artifacts.
If this is your first time using a particular board, you will need to switch its eMMC partition layout to the Linux layout, but this procedure only needs to be done once for a given board. After switching your layout, you only have to update your board with your latest build artifacts.
The procedure for updating your eMMC partitions is as follows. Put your DragonBoard into `fastboot mode` (see procedure above) then perform these steps on your development host:
* download the latest Linux bootloader package (e.g. `dragonboard410c_bootloader_emmc_linux-<version>.zip`)
@ -131,26 +139,39 @@ The procedure for updating your eMMC partitions is as follows. Put your DragonBo
At this point your eMMC has the following partition layout:
* `/dev/mmcblk0p7` , aka `aboot` is used for the bootloader (LK/fastboot)
Dragonboard 410c:
* `/dev/mmcblk0p8` , aka `boot` is used for the boot image (kernel, device tree, initrd)
* `/dev/mmcblk0p10` , aka `rootfs` is used for the root file system
HiKey:
* `/dev/mmcblk0p6` , aka `boot` is used for the boot image (kernel, device tree, initrd)
* `/dev/mmcblk0p9` , aka `rootfs` is used for the root file system
# Flashing build artifacts
In the following description, replace `image` with the name of the image you built. For example: if you built `rpb-console-image` then `image` will be `rpb-console-image`.
In the following description, replace `IMAGE` with the name of the image you built. For example: if you built `rpb-console-image` then `IMAGE` will be `rpb-console-image`.
Same for `IMAGE`, replace with the name of your board. For example: if you built for `Dragonboard 410c` then `MACHINE` will be `dragonboard-410c`, if you built for `HiKey` then `MACHINE` will be `hikey`.
At the end of any successful build you will end up with the following artifacts (amongst others)
* `image-dragonboard-410c.ext4.gz` and
* `boot-dragonboard-410c.img`
* `IMAGE-MACHINE.ext4.gz` and
* `boot-MACHINE.img`
These will be found in your `tmp-eglibc/deploy/images/dragonboard-410c` directory.
These will be found in your `tmp-eglibc/deploy/images/MACHINE` directory.
To install these to your DragonBoard's eMMC from your development host:
To install these to your board's eMMC from your development host:
# gunzip IMAGE-MACHINE.ext4.gz
# fastboot flash boot boot-MACHINE.img
In the case of Dragonboard 410c:
# fastboot flash rootfs IMAGE-MACHINE.ext4
In the case of HiKey:
# ext2simg -v IMAGE-MACHINE.ext4 IMAGE-MACHINE.img
# fastboot flash rootfs IMAGE-MACHINE.img
# gzip -d < image-dragonboard-410c.ext4.gz > image-dragonboard-410c.ext4
# fastboot flash rootfs image-dragonboard-410c.ext4
# fastboot flash boot boot-dragonboard-410c.img
# Proprietary firmware blob
When running the `setup-environment` script, you were asked to read/accept the Qualcomm EULA. The EULA is required to access the proprietary firmware, such as the GPU firmware , WLAN, ...
@ -161,11 +182,11 @@ If you did not accept the EULA, the firmware are not downloaded, and not install
# Build a simple X11 image
To build an X11 image with GPU hardware accelerated support run:
To build an X11 image with GPU hardware accelerated support, run:
$ bitbake rpb-desktop-image
At the end of the build, the root file system image will be available as `tmp-eglibc/deploy/images/dragonboard-410c/rpb-desktop-image-dragonboard-410c.ext4.gz`.
At the end of the build, the root file system image will be available as `tmp-eglibc/deploy/images/MACHINE/rpb-desktop-image-MACHINE.ext4.gz`.
Then you can finally start the X server, and run any graphical application:
@ -193,11 +214,11 @@ and rebuild the `rpb-desktop-image` image, it will now include `metacity`, which
# Build a sample Wayland/Weston image
For Wayland/weston, it is recommended to change the DISTRO and use `rpb-wayland` instead of `rpb`. The main reason is that in the `rpb-wayland` distro, the support for X11 is completely removed. So , in a new terminal prompt, setup a new environment and make sure to use `rpb-wayland` for DISTRO, then, you can run a sample image with:
For Wayland/weston, it is needed to change the DISTRO and use `rpb-wayland` instead of `rpb`. The main reason is that in the `rpb-wayland` distro, the support for X11 is completely removed. So, in a new terminal prompt, setup a new environment and make sure to use `rpb-wayland` for DISTRO, then, you can run a sample image with:
$ bitbake rpb-weston-image
This image includes a few additional features, such as `systemd`, `connman` which makes it simpler to use. Once built, the image will be available at `tmp-eglibc/deploy/images/dragonboard-410c/rpb-weston-image-dragonboard-410c.ext4.gz`. And it can be flashed into `rootfs` partition.
This image includes a few additional features, such as `systemd`, `connman` which makes it simpler to use. Once built, the image will be available at `tmp-eglibc/deploy/images/MACHINE/rpb-weston-image-MACHINE.ext4.gz`. And it can be flashed into `rootfs` partition.
If you boot this image on the board, you should get a command prompt on the HDMI monitor. A user called `linaro` exists (and has no password). Once logged in a VT, you run start weston with:
@ -207,6 +228,6 @@ And that should get you to the Weston desktop shell.
# Support
For general question or support request, please go to [96boards.org Community forum](https://www.96boards.org/forums/forum/products/dragonboard410c/).
For general question or support request, please go to [96boards.org Community forum](http://www.96boards.org/forums/forum/products/).
For any bug related to this release, please submit issues to the [96Board.org Bug tracking system](https://bugs.96boards.org/). To submit a bug, follow this [link](https://bugs.96boards.org/enter_bug.cgi?product=Dragonboard%20410c).
For any bug related to this release, please submit issues to the [96Board.org Bug tracking system](https://bugs.linaro.org/). To submit a bug, follow this [link](https://bugs.linaro.org/enter_bug.cgi?product=Reference%20Platforms).