Performed general edits to this chapter.
many english corrections performed. Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
09ef6a4e13
commit
4243a61e98
|
|
@ -1,53 +1,60 @@
|
||||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
||||||
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
<chapter id="bsp">
|
||||||
|
|
||||||
<chapter id='bsp'>
|
|
||||||
|
|
||||||
<title>Board Support Packages (BSP) - Developers Guide</title>
|
<title>Board Support Packages (BSP) - Developers Guide</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
A Board Support Package (BSP) is a collection of information which together
|
A Board Support Package (BSP) is a collection of information that
|
||||||
defines how to support a particular hardware device, set of devices, or
|
defines how to support a particular hardware device, set of devices, or
|
||||||
hardware platform. It will include information about the hardware features
|
hardware platform.
|
||||||
|
The BSP includes information about the hardware features
|
||||||
present on the device and kernel configuration information along with any
|
present on the device and kernel configuration information along with any
|
||||||
additional hardware drivers required. It will also list any additional software
|
additional hardware drivers required.
|
||||||
|
The BSP also lists any additional software
|
||||||
components required in addition to a generic Linux software stack for both
|
components required in addition to a generic Linux software stack for both
|
||||||
essential and optional platform features.
|
essential and optional platform features.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The intent of this document is to define a structure for these components
|
The intent of this document is to define a structure for these components
|
||||||
so that BSPs follow a commonly understood layout, allowing them to be
|
so that BSPs follow a commonly understood layout.
|
||||||
provided in a common form that everyone understands. It also allows end-users
|
Providing a common form allows end-users to understand and become familiar
|
||||||
to become familiar with one common format and encourages standardisation
|
with the layout.
|
||||||
|
A common form also encourages standardization
|
||||||
of software support of hardware.
|
of software support of hardware.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The proposed format does have elements that are specific to the Poky and
|
The proposed format does have elements that are specific to the Poky and
|
||||||
OpenEmbedded build systems. It is intended that this information can be
|
OpenEmbedded build systems.
|
||||||
used by other systems besides Poky/OpenEmbedded and that it will be simple
|
It is intended that this information can be
|
||||||
to extract information and convert to other formats if required. The format
|
used by other systems besides Poky and OpenEmbedded and thatspecified it will be simple
|
||||||
described can be directly accepted as a layer by Poky using its standard
|
to extract information and convert it to other formats if required.
|
||||||
layers mechanism, but it is important to recognise that the BSP captures all
|
Poky, through its standard slyers mechanism, can directly accept The format
|
||||||
|
described as a layer.
|
||||||
|
The BSP captures all
|
||||||
the hardware specific details in one place in a standard format, which is
|
the hardware specific details in one place in a standard format, which is
|
||||||
useful for any person wishing to use the hardware platform regardless of
|
useful for any person wishing to use the hardware platform regardless of
|
||||||
the build system in use.
|
the build system being used.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The BSP specification does not include a build system or other tools -
|
The BSP specification does not include a build system or other tools -
|
||||||
it is concerned with the hardware specific components only. At the end
|
it is concerned with the hardware-specific components only.
|
||||||
distribution point the BSP may be shipped combined with a build system
|
At the end
|
||||||
and other tools, but it is important to maintain the distinction that these
|
distribution point you can shipt the BSP combined with a build system
|
||||||
are separate components which may just be combined in certain end products.
|
and other tools.
|
||||||
|
However, it is important to maintain the distinction that these
|
||||||
|
are separate components that happen to be combined in certain end products.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<section id='bsp-filelayout'>
|
<section id="bsp-filelayout">
|
||||||
<title>Example Filesystem Layout</title>
|
<title>Example Filesystem Layout</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The BSP consists of a file structure inside a base directory, meta-bsp in this example, where "bsp" is a placeholder for the machine or platform name. Examples of some files that it could contain are:
|
The BSP consists of a file structure inside a base directory, meta-bsp in this example,
|
||||||
|
where "bsp" is a placeholder for the machine or platform name.
|
||||||
|
Examples of some files that it could contain are:
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
@ -76,15 +83,18 @@ meta-bsp/prebuilds/
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bsp-filelayout-binary'>
|
<section id="bsp-filelayout-binary">
|
||||||
<title>Prebuilt User Binaries (meta-bsp/binary/*)</title>
|
<title>Prebuilt User Binaries (meta-bsp/binary/*)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This optional area contains useful prebuilt kernels and userspace filesystem
|
This optional area contains useful prebuilt kernels and userspace filesystem
|
||||||
images appropriate to the target system. Users could use these to get a system
|
images appropriate to the target system.
|
||||||
running and quickly get started on development tasks. The exact types of binaries
|
Users could use these to get a system
|
||||||
|
running and quickly get started on development tasks.
|
||||||
|
The exact types of binaries
|
||||||
present will be highly hardware-dependent but a README file should be present
|
present will be highly hardware-dependent but a README file should be present
|
||||||
explaining how to use them with the target hardware. If prebuilt binaries are
|
explaining how to use them with the target hardware.
|
||||||
|
If prebuilt binaries are
|
||||||
present, source code to meet licensing requirements must also be provided in
|
present, source code to meet licensing requirements must also be provided in
|
||||||
some form.
|
some form.
|
||||||
</para>
|
</para>
|
||||||
|
|
@ -95,9 +105,10 @@ meta-bsp/prebuilds/
|
||||||
<title>Layer Configuration (meta-bsp/conf/layer.conf)</title>
|
<title>Layer Configuration (meta-bsp/conf/layer.conf)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This file identifies the structure as a Poky layer. This file identifies the
|
This file identifies the structure as a Poky layer by identifying the
|
||||||
contents of the layer and contains information about how Poky should use
|
contents of the layer and containing information about how Poky should use
|
||||||
it. In general it will most likely be a standard boilerplate file consisting of:
|
it.
|
||||||
|
Generally, a standard boilerplate file consisting of the following works.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
@ -106,7 +117,7 @@ meta-bsp/prebuilds/
|
||||||
BBPATH := "${BBPATH}${LAYERDIR}"
|
BBPATH := "${BBPATH}${LAYERDIR}"
|
||||||
|
|
||||||
# We have a recipes directory containing .bb and .bbappend files, add to BBFILES
|
# We have a recipes directory containing .bb and .bbappend files, add to BBFILES
|
||||||
BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb ${LAYERDIR}/recipes/*/*.bbappend"
|
BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend"
|
||||||
|
|
||||||
BBFILE_COLLECTIONS += "bsp"
|
BBFILE_COLLECTIONS += "bsp"
|
||||||
BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
|
BBFILE_PATTERN_bsp := "^${LAYERDIR}/"
|
||||||
|
|
@ -115,47 +126,45 @@ BBFILE_PRIORITY_bsp = "5"
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
which simply makes bitbake aware of the recipes and conf directories.
|
This file simply makes bitbake aware of the recipes and conf directories and is required
|
||||||
</para>
|
for recognition of the BSP by Poky.
|
||||||
|
|
||||||
<para>
|
|
||||||
This file is required for recognition of the BSP by Poky.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bsp-filelayout-machine'>
|
<section id="bsp-filelayout-machine">
|
||||||
<title>Hardware Configuration Options (meta-bsp/conf/machine/*.conf)</title>
|
<title>Hardware Configuration Options (meta-bsp/conf/machine/*.conf)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The machine files bind together all the information contained elsewhere
|
The machine files bind together all the information contained elsewhere
|
||||||
in the BSP into a format that Poky/OpenEmbedded can understand. If
|
in the BSP into a format that Poky/OpenEmbedded can understand.
|
||||||
the BSP supports multiple machines, multiple machine configuration files
|
If the BSP supports multiple machines, multiple machine configuration files
|
||||||
can be present. These filenames correspond to the values users set the
|
can be present.
|
||||||
MACHINE variable to.
|
These filenames correspond to the values to which users have set the MACHINE variable.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These files would define things like which kernel package to use
|
These files define things such as what kernel package to use
|
||||||
(PREFERRED_PROVIDER of virtual/kernel), which hardware drivers to
|
(PREFERRED_PROVIDER of virtual/kernel), what hardware drivers to
|
||||||
include in different types of images, any special software components
|
include in different types of images, any special software components
|
||||||
that are needed, any bootloader information, and also any special image
|
that are needed, any bootloader information, and also any special image
|
||||||
format requirements.
|
format requirements.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
At least one machine file is required for a Poky BSP layer but more than one may be present.
|
At least one machine file is required for a Poky BSP layer.
|
||||||
|
However, you can supply more than one file.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bsp-filelayout-tune'>
|
<section id="bsp-filelayout-tune">
|
||||||
<title>Hardware Optimisation Options (meta-bsp/conf/machine/include/tune-*.inc)</title>
|
<title>Hardware Optimization Options (meta-bsp/conf/machine/include/tune-*.inc)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These are shared hardware "tuning" definitions and are commonly used to
|
These are shared hardware "tuning" definitions and are commonly used to
|
||||||
pass specific optimisation flags to the compiler. An example is
|
pass specific optimization flags to the compiler.
|
||||||
tune-atom.inc:
|
An example is tune-atom.inc:
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
@ -164,40 +173,42 @@ TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse"
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
which defines a new package architecture called "core2" and uses the
|
This example defines a new package architecture called "core2" and uses the
|
||||||
optimization flags specified, which are carefully chosen to give best
|
specified optimization flags, which are carefully chosen to give best
|
||||||
performance on atom cpus.
|
performance on atom processors.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The tune file would be included by the machine definition and can be
|
The tune file would be included by the machine definition and can be
|
||||||
contained in the BSP or reference one from the standard core set of
|
contained in the BSP or referenced from one of the standard core set of
|
||||||
files included with Poky itself.
|
files included with Poky itself.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
These files are optional for a Poky BSP layer.
|
Both the base package architecuture file and the tune file are optional for a Poky BSP layer.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bsp-filelayout-kernel'>
|
<section id='bsp-filelayout-kernel'>
|
||||||
<title>Linux Kernel Configuration (meta-bsp/packages/linux/*)</title>
|
<title>Linux Kernel Configuration (meta-bsp/packages/linux/*)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These files make up the definition of a kernel to use with this
|
These files make up the definition of a kernel to use with this
|
||||||
hardware. In this case it is a complete self-contained kernel with its own
|
hardware.
|
||||||
|
In this case it is a complete self-contained kernel with its own
|
||||||
configuration and patches but kernels can be shared between many
|
configuration and patches but kernels can be shared between many
|
||||||
machines as well. Taking some specific example files:
|
machines as well.
|
||||||
</para>
|
Following is an example:
|
||||||
<para>
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
meta-bsp/packages/linux/linux-bsp_2.6.50.bb
|
meta-bsp/packages/linux/linux-bsp_2.6.50.bb
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
This example file is the core kernel recipe that details from where to get the kernel
|
||||||
|
source.
|
||||||
|
All standard source code locations are supported so this could
|
||||||
|
be a release tarball, some git repository, or source included in
|
||||||
|
the directory within the BSP itself.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
which is the core kernel recipe which firstly details where to get the kernel
|
The file then contains information about what patches to apply and how to configure and build them.
|
||||||
source from. All standard source code locations are supported so this could
|
It can reuse the main Poky kernel build class, so the definitions here can remain very simple.
|
||||||
be a release tarball, some git repository, or source included in
|
|
||||||
the directory within the BSP itself. It then contains information about which
|
|
||||||
patches to apply and how to configure and build it. It can reuse the main
|
|
||||||
Poky kernel build class, so the definitions here can remain very simple.
|
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
@ -205,7 +216,7 @@ linux-bsp-2.6.50/*.patch
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
which are patches which may be applied against the base kernel, wherever
|
The above example file contains patches you can apply against the base kernel, wherever
|
||||||
they may have been obtained from.
|
they may have been obtained from.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
|
|
@ -214,11 +225,11 @@ meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
which is the configuration information to use to configure the kernel.
|
Finally, this last example file contains configuration information to use to configure the kernel.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Examples of kernel recipes are available in Poky itself. These files are
|
Examples of kernel recipes are available in Poky itself.
|
||||||
optional since a kernel from Poky itself could be selected, although it
|
These files are optional since a kernel from Poky itself could be selected, although it
|
||||||
would be unusual not to have a kernel configuration.
|
would be unusual not to have a kernel configuration.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
@ -227,11 +238,19 @@ meta-bsp/packages/linux/linux-bsp-2.6.50/defconfig-bsp
|
||||||
<title>Other Software (meta-bsp/packages/*)</title>
|
<title>Other Software (meta-bsp/packages/*)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This area includes other pieces of software which the hardware may need for best
|
This section describes other pieces of software that the hardware might need for best
|
||||||
operation. These are just examples of the kind of things that may be
|
operation.
|
||||||
encountered. These are standard .bb file recipes in the usual Poky format,
|
These are examples of the kinds of things that you could encounter.
|
||||||
so for examples, see standard Poky recipes. The source can be included directly,
|
The examples used in this section are standard <filename>.bb</filename> file recipes in the
|
||||||
referred to in source control systems or release tarballs of external software projects.
|
usual Poky format.
|
||||||
|
You can include the source directly by referring to it in the source control system or
|
||||||
|
the released tarballs of external software projects.
|
||||||
|
You only need to provide these types of files if the platform requires them.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The following file is a bootloader recipe that can be used to generate a new
|
||||||
|
bootloader binary.
|
||||||
|
Sometimes these files are included in the final image format and are needed to reflash hardware.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
@ -239,9 +258,9 @@ meta-bsp/packages/bootloader/bootloader_0.1.bb
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Some kind of bootloader recipe which may be used to generate a new
|
These next two files are examples of a hardware driver and a hardware daemon that might need
|
||||||
bootloader binary. Sometimes these are included in the final image
|
to be included in images to make the hardware useful.
|
||||||
format and needed to reflash hardware.
|
Although the example uses "modem" there may be other components needed, such as firmware.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
@ -250,72 +269,62 @@ meta-bsp/packages/modem/modem-daemon_0.1.bb
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
These are examples of a hardware driver and also a hardware daemon which
|
Sometimes the device needs an image in a very specific format so that the update
|
||||||
may need to be included in images to make the hardware useful. "modem"
|
mechanism can accept and reflash it.
|
||||||
is one example but there may be other components needed like firmware.
|
Recipes to build the tools needed to do this can be included with the BSP.
|
||||||
|
Following is an example.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<programlisting>
|
<programlisting>
|
||||||
meta-bsp/packages/image-creator/image-creator-native_0.1.bb
|
meta-bsp/packages/image-creator/image-creator-native_0.1.bb
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
|
||||||
Sometimes the device will need an image in a very specific format for
|
|
||||||
its update mechanism to accept and reflash with it. Recipes to build the
|
|
||||||
tools needed to do this can be included with the BSP.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
These files only need be provided if the platform requires them.
|
|
||||||
</para>
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bs-filelayout-bbappend'>
|
<section id='bs-filelayout-bbappend'>
|
||||||
<title>Append BSP specific information to existing recipes</title>
|
<title>Append BSP-Specific Information to Existing Recipes</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Say you have a recipe like pointercal which has machine-specific information in it,
|
Suppose you have a recipe such as 'pointercal' that requires machine-specific information.
|
||||||
and then you have your new BSP code in a layer. Before the .bbappend extension was
|
At the same time, you have your new BSP code nicely partitioned into a layer, which is where
|
||||||
introduced, you'd have to copy the whole pointercal recipe and files into your layer,
|
you would also like to specify any machine-specific information associated with your new machine.
|
||||||
and then add the single file for your machine, which is ugly.
|
Before the <filename>.bbappend</filename> extension was introduced, you would have to copy the whole
|
||||||
|
pointercal recipe and files into your layer, and then add the single file for your machine.
|
||||||
.bbappend makes the above work much easier, to allow BSP-specific information to be merged
|
</para>
|
||||||
with the original recipe easily. When bitbake finds any X.bbappend files, they will be
|
<para>
|
||||||
included after bitbake loads X.bb but before finalise or anonymous methods run.
|
With the <filename>.bbappend</filename> extension, however, your work becomes much easier.
|
||||||
This allows the BSP layer to poke around and do whatever it might want to customise
|
It allows you to easily merge BSP-specific information with the original recipe.
|
||||||
the original recipe.
|
Whenever bitbake finds any <filename>.bbappend</filename> files, they will be
|
||||||
|
included after bitbake loads the associated <filename>.bb</filename> but before any finalize
|
||||||
If your recipe needs to reference extra files it can use the FILESEXTRAPATH variable
|
or anonymous methods run.
|
||||||
to specify their location. The example below shows extra files contained in a folder
|
This allows the BSP layer to do whatever it might want to do to customize the original recipe.
|
||||||
called ${PN} (the package name).
|
</para>
|
||||||
|
<para>
|
||||||
|
If your recipe needs to reference extra files it can use the FILESEXTRAPATH variable
|
||||||
|
to specify their location.
|
||||||
|
The example below shows extra files contained in a folder called ${PN} (the package name).
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
FILESEXTRAPATHS := "${THISDIR}/${PN}"
|
FILESEXTRAPATHS := "${THISDIR}/${PN}"
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Then the BSP could add machine-specific config files in layer directory, which will be
|
This technique allows the BSP to add machine-specific configuration files to the layer directory,
|
||||||
added by bitbake. You can look at meta-emenlow/packages/formfactor as an example.
|
which will be picked up by bitbake.
|
||||||
|
For an example see <filename>meta-emenlow/packages/formfactor</filename>.
|
||||||
</para>
|
</para>
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bsp-filelayout-prebuilds'>
|
<section id="bsp-filelayout-prebuilds">
|
||||||
<title>Prebuild Data (meta-bsp/prebuilds/*)</title>
|
<title>Prebuild Data (meta-bsp/prebuilds/*)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The location can contain a precompiled representation of the source code
|
This location can contain precompiled representations of the source code
|
||||||
contained elsewhere in the BSP layer. It can be processed and used by
|
contained elsewhere in the BSP layer.
|
||||||
Poky to provide much faster build times, assuming a compatible configuration is used.
|
Assuming a compatible configuration is used, Poky can process and use these optional precompiled
|
||||||
|
representations to provide much faster build times.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
|
||||||
These files are optional.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
</section>
|
</section>
|
||||||
|
|
||||||
<section id='bsp-click-through-licensing'>
|
<section id='bsp-click-through-licensing'>
|
||||||
<title>BSP 'Click-through' Licensing Procedure</title>
|
<title>BSP 'Click-Through' Licensing Procedure</title>
|
||||||
|
|
||||||
<note><para> This section is here as a description of how
|
<note><para> This section is here as a description of how
|
||||||
click-through licensing is expected to work, and is
|
click-through licensing is expected to work, and is
|
||||||
|
|
@ -367,10 +376,9 @@ FILESEXTRAPATHS := "${THISDIR}/${PN}"
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Get a license key (or keys) for the encumbered BSP
|
Get a license key (or keys) for the encumbered BSP
|
||||||
by
|
by visiting
|
||||||
visiting <ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink>
|
<ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink>
|
||||||
and give the web form there the name of the BSP
|
and give the web form there the name of the BSP and your e-mail address.
|
||||||
and your e-mail address.
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue