generic-poky/scripts/lib/bsp/substrate/target/arch/common
Brian A. Lloyd ffff37f8f9 yocto-bsp: qualify user files with machine name
The bblayer abstraction makes it where multiple layers can be
configured and used at the same time.  Some layers make changes to
support a specific machine, and should not have any affect when other
machines are in use.

For linux-yocto, all bsps are created with a user-config.cfg and
user-config.cfg and user-patches.scc.  This means that those files
will be pulled from the first location found, which might correspond
to files customized for a different machine.

Instead of using the names user-config.cfg and user-patches.scc, I
propose a machine specific name be used such as
{{=machine}}user-patches.scc and {{=machine}}user-config.cfg.  This
would necessitate that all references changed to these new names,
which would affect the yocto-bsp and yocto-kernel scripts.

With this change, it would be possible to have multiple machine BSPs
searched at the same time and to select which to build against by
using a command like MACHINE=qmeux86 bitbake core-image-sato to
override the default.

Note many of the standard BSPs do not seem to suffer this problem as
they do not use the common files user-config.cfg and user-patches.scc
that the yocto-* scripts depend upon.

Additions by Tom Zanussi:
 - renamed user-config.cfg to {{=machine}}-user-config.cfg everywhere
 - renamed user-patches.scc to {{=machine}}-user-patches.scc everywhere
 - added the user-config/patches SRC_URI items to the qemu -rt kernel recipes
 - fixed conflicts due to the new open_user_file() helper function
 - updated user filename conflicts caused by directory renaming
 - updated custom kernel files to match

Fixes [YOCTO #3731]

(From meta-yocto rev: c20bef60aa8d52971fb061d4b8d473ad19c03180)

Signed-off-by: Brian A. Lloyd <brian.lloyd@familyhonor.net>
Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-01-25 14:12:36 +00:00
..
binary yocto-bsp: add BSP template files 2012-03-22 19:21:14 +00:00
conf yocto-bsp: add BSP template files 2012-03-22 19:21:14 +00:00
recipes-bsp/formfactor yocto-bsp: qualify user files with machine name 2013-01-25 14:12:36 +00:00
recipes-kernel/linux yocto-bsp: qualify user files with machine name 2013-01-25 14:12:36 +00:00
COPYING.MIT yocto-bsp: add BSP template files 2012-03-22 19:21:14 +00:00
README yocto-bsp: add a LICENSE_FLAGS_WHITELIST blurb for emgd to README 2012-09-02 05:52:15 -07:00
README.sources yocto-bsp: add BSP template files 2012-03-22 19:21:14 +00:00

README

This README file contains information on building the meta-{{=machine}}
BSP layer, and booting the images contained in the /binary directory.
Please see the corresponding sections below for details.


Dependencies
============

This layer depends on:

  URI: git://git.openembedded.org/bitbake
  branch: master

  URI: git://git.openembedded.org/openembedded-core
  layers: meta
  branch: master

  URI: git://git.yoctoproject.org/xxxx
  layers: xxxx
  branch: master


Patches
=======

Please submit any patches against this BSP to the Yocto mailing list
(yocto@yoctoproject.org) and cc: the maintainer:

Maintainer: XXX YYYYYY <xxx.yyyyyy@zzzzz.com>

Please see the meta-xxxx/MAINTAINERS file for more details.


Table of Contents
=================

  I. Building the meta-{{=machine}} BSP layer
 II. Booting the images in /binary


I. Building the meta-{{=machine}} BSP layer
========================================

--- replace with specific instructions for your layer ---

In order to build an image with BSP support for a given release, you
need to download the corresponding BSP tarball from the 'Board Support
Package (BSP) Downloads' page of the Yocto Project website.

Having done that, and assuming you extracted the BSP tarball contents
at the top-level of your yocto build tree, you can build a
{{=machine}} image by adding the location of the meta-{{=machine}}
layer to bblayers.conf, along with any other layers needed (to access
common metadata shared between BSPs) e.g.:

  yocto/meta-xxxx \
  yocto/meta-xxxx/meta-{{=machine}} \

To enable the {{=machine}} layer, add the {{=machine}} MACHINE to local.conf:

  MACHINE ?= "{{=machine}}"

You should then be able to build a {{=machine}} image as such:

  $ source oe-init-build-env
  $ bitbake core-image-sato

NOTE: if the '{{=machine}}' machine includes the emgd-driver-bin
package (i.e. if the emgd version of the xserver is being used), it
has a proprietary license that must be whitelisted by adding the
string "license_emgd-driver-bin_1.14" to the LICENSE_FLAGS_WHITELIST
variable in your local.conf.  For example:

  LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.14"

At the end of a successful build, you should have a live image that
you can boot from a USB flash drive (see instructions on how to do
that below, in the section 'Booting the images from /binary').

As an alternative to downloading the BSP tarball, you can also work
directly from the meta-xxxx git repository.  For each BSP in the
'meta-xxxx' repository, there are multiple branches, one corresponding
to each major release starting with 'laverne' (0.90), in addition to
the latest code which tracks the current master (note that not all
BSPs are present in every release).  Instead of extracting a BSP
tarball at the top level of your yocto build tree, you can
equivalently check out the appropriate branch from the meta-xxxx
repository at the same location.


II. Booting the images in /binary
=================================

--- replace with specific instructions for your platform ---

This BSP contains bootable live images, which can be used to directly
boot Yocto off of a USB flash drive.

Under Linux, insert a USB flash drive.  Assuming the USB flash drive
takes device /dev/sdf, use dd to copy the live image to it.  For
example:

# dd if=core-image-sato-{{=machine}}-20101207053738.hddimg of=/dev/sdf
# sync
# eject /dev/sdf

This should give you a bootable USB flash device.  Insert the device
into a bootable USB socket on the target, and power on.  This should
result in a system booted to the Sato graphical desktop.

If you want a terminal, use the arrows at the top of the UI to move to
different pages of available applications, one of which is named
'Terminal'.  Clicking that should give you a root terminal.

If you want to ssh into the system, you can use the root terminal to
ifconfig the IP address and use that to ssh in.  The root password is
empty, so to log in type 'root' for the user name and hit 'Enter' at
the Password prompt: and you should be in.

----

If you find you're getting corrupt images on the USB (it doesn't show
the syslinux boot: prompt, or the boot: prompt contains strange
characters), try doing this first:

# dd if=/dev/zero of=/dev/sdf bs=1M count=512