Eflanagan: moved BKM: Packaging a BSP to BKM: Packaging a BSP Trash

2013-12-04T16:37:33Z

moved BKM: Packaging a BSP to BKM: Packaging a BSP Trash

← Older revision	Revision as of 16:37, 4 December 2013
(No difference)

Eflanagan: Created page with "== Packaging a BSP == This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, w..."

2013-12-04T16:36:35Z

Created page with "== Packaging a BSP == This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, w..."

New page

== Packaging a BSP ==

This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, we suggest that you review the [[http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html | Yocto Project BSP Guide]]

=== General Guidelines ===

* A BSP should contain a root level binary directory to contain binary images. Enough to get a board to boot with some level of functionality, keeping in mind that the larger the image, the longer it takes for people to download your BSP
* A BSP should contain *just* the meta-data needed to at least rebuild the images that exist in /binary. If your BSP repo contains support for 10 BSPs, the BSP tarball you release SHOULD NOT contain all of that meta-data.
* A BSP tarball should contain a MAINTAINERS and a README file
* A BSP tarball should contain licensing information
* A BSP tarball does NOT need to contain the version of the poky/oe-core repo it was built with, however, it SHOULD be built with a known released version of poky and/or oe-core
* When requesting the release of a BSP, you should be able to provide the git hash the images were built against, for ALL layers. So, if you built images that contained meta-intel and poky, you should be able to provide both git hashes.
* In general the purpose of releasing a BSP is to make it easier for the end user to duplicate your work. Prior to requesting a release, please, test that someone can use your BSP and get the same results.

=== Example structure ===

For our example, we will utilize the meta-intel BSP, meta-fri2.

<nowiki>
-rw-r--r-- MAINTAINERS
-rw-r--r-- README
d--------- classes
d--------- common
d--------- conf
d--------- meta-chiefriver
d--------- meta-crownbay
d--------- meta-crystalforest
d--------- meta-emenlow
d--------- meta-fri2
d--------- meta-isg
d--------- meta-jasperforest
d--------- meta-n450
d--------- meta-nuc
d--------- meta-romley
d--------- meta-sugarbay
d--------- meta-sys940x
d--------- meta-tlk
</nowiki>
The top level directory of the meta-intel repo contains multiple BSPs, and classes, common and conf directories.

For our example, we will be using fri2. What we will first do is remove all BSPs that are not fri2:

<nowiki>
-rw-r--r-- MAINTAINERS
-rw-r--r-- README
d--------- classes
d--------- common
d--------- conf
d--------- meta-fri2
d--------- meta-tlk
</nowiki>

You will notice that we have left the meta-tlk directory. As meta-intel images are built with a time limited kernel, we need to include this, both to ensure end users have the ability to recreate our work and also to maintain open source license compliance.

<nowiki>
-rw-r--r-- MAINTAINERS
-rw-r--r-- README
d--------- binary
d--------- classes
d--------- common
d--------- conf
d--------- meta-fri2
d--------- meta-tlk
</nowiki>

Next, we will add a binary directory. This should contain the images needed to get hardware to boot.

We will then tar the image up in either tar.bz2 or tar.gz (tar.bz2 is much prefered). Please do not utilize non-standard compression formats.

The naming convention for the tarball is:

<name of bsp>-<name of release it was built against>-M.m.p

We do not generally care what the name of the file expands to, HOWEVER, please ensure that whatever it expands to is exactly the same as what it is documented as.

BKM: Packaging a BSP Trash - Revision history

Eflanagan: moved BKM: Packaging a BSP to BKM: Packaging a BSP Trash

Eflanagan: Created page with "== Packaging a BSP == This explains, in a very general way, how to structure a BSP for release. As the structure of different board support packages can be slightly different, w..."