Skip to content
Snippets Groups Projects
Commit ecb5b694 authored by Martyn Welch's avatar Martyn Welch
Browse files

Remove user pages


Most of the user pages contain links to pages written by the user as some
users took the convention of writing pages in their user areas before
moving into a more suitable location once they had been reviewed. As this
is no longer the expected workflow and the new site does not have the
concept of users, remove these pages.

Any pages with potential value as still in progress have been moved to
branches which can be reviewed an merged properly in the future.

Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.com>
parent 87adbb15
No related branches found
No related tags found
1 merge request!1Wip/martyn/t6720
...@@ -41,7 +41,7 @@ Apertis community have previously shared (ordered newest to oldest): ...@@ -41,7 +41,7 @@ Apertis community have previously shared (ordered newest to oldest):
- [<File:Genivi-amm-2017-slides.odp>](/genivi-amm-2017-slides.odp) - [<File:Genivi-amm-2017-slides.odp>](/genivi-amm-2017-slides.odp)
- introduction to application framework for GENIVI and Apertis by - introduction to application framework for GENIVI and Apertis by
[Kat]( {{< ref "/user_kittykat.md" >}} ) and Andre Ekaterina Gerasimova and Andre Magalhães
### 2016 ### 2016
...@@ -50,4 +50,4 @@ Apertis community have previously shared (ordered newest to oldest): ...@@ -50,4 +50,4 @@ Apertis community have previously shared (ordered newest to oldest):
- an introduction to Apertis by Lukas Nack - an introduction to Apertis by Lukas Nack
- [<File:Apertis-GNOMEAsia-2016-slides.odp>](/apertis-gnomeasia-2016-slides.odp) - [<File:Apertis-GNOMEAsia-2016-slides.odp>](/apertis-gnomeasia-2016-slides.odp)
- an overview of architecture and development by Sudarshan - an overview of architecture and development by Sudarshan
Chikkapura Puttalingaiah Chikkapura Puttalingaiah
\ No newline at end of file
+++
date = "2016-09-15"
weight = 100
title = "User:Andrewsh"
aliases = [
"/old-wiki/User:Andrewsh"
]
+++
+++
date = "2016-08-26"
weight = 100
title = "User:Fdalleau"
aliases = [
"/old-wiki/User:Fdalleau"
]
+++
Work in progress
[User:Connman-pan-network-access-profile]( {{< ref "/qa/test_cases/connman-pan-network-access.md" >}} )
[User:ofono-voicecall]( {{< ref "/user_ofono-voicecall.md" >}} )
\ No newline at end of file
+++
date = "2017-03-24"
weight = 100
title = "User:Joykim"
aliases = [
"/old-wiki/User:Joykim"
]
+++
[User:Joykim/HowToWorkWithPatches]( {{< ref "/guidelines/contribution_process.md" >}} )
[User:Joykim/HowToReleasePackages]( {{< ref "/guidelines/howtoreleasepackages.md" >}} )
+++
date = "2015-11-03"
weight = 100
title = "User:Kittykat"
aliases = [
"/old-wiki/User:Kittykat"
]
+++
- IRC: kittykat on freenode and GIMPNet
- Blog: <http://blogs.gnome.org/kittykat/>
\ No newline at end of file
+++
date = "2016-01-07"
weight = 100
title = "User:Kittykat TODO"
aliases = [
"/old-wiki/User:Kittykat/TODO"
]
+++
- Link <https://wiki.apertis.org/Creating_a_project> to a licensing
page
\ No newline at end of file
+++
date = "2019-11-25"
weight = 100
title = "User:Martyn"
aliases = [
"/old-wiki/User:Martyn"
]
+++
## Published pages
- [User:Martyn/HowToBuildYourOwnKernel]( {{< ref "/guidelines/howtobuildyourownkernel.md" >}} )
- [User:Martyn/BuildingPatchingAndMaintainingTheApertisKernel]( {{< ref "/guidelines/buildingpatchingandmaintainingtheapertiskernel.md" >}} )
## Draft pages
- [User:Martyn/Main_Page]( {{< ref "/user_martyn/main_page.md" >}} )
- [User:Martyn/HardwareBringUp]( {{< ref "/user_martyn/hardwarebringup.md" >}} )
\ No newline at end of file
+++
date = "2019-12-03"
weight = 100
title = "User:Martyn HardwareBringUp"
aliases = [
"/old-wiki/User:Martyn/HardwareBringUp"
]
+++
When we wish to utilise Apertis on a new platform, it is highly likely
that "Hardware Bring-Up" will be one of the first tasks that needs to be
performed. Hardware bring-up is the process by which support for an
initially unsupported target platform is iteratively created and tested.
The process of board bring-up by necessity initially follows the boot
process, we need at least a basic implementation of the initial boot
steps in place before moving on to the later steps. It is likely that
this process will be iterative, with the boot process initially being
implemented in a way that is more suited to the development process and
evolving over time with the addition of extra board support to become
closer to that desired for the final end product.
Unless a third party CPU module on an architecture with highly
standardised boot firmware is being used (which may be the case with an
x86 based CPU module, where development of the boot firmware may be
entirely by-passed), development will start with enabling support in a
suitable boot firmware. For the majority of the reference platforms
currently enabled in Apertis (and as a result, the other platforms that
have been enabled in Apertis) have utilised
[U-Boot](https://www.denx.de/wiki/U-Boot) as boot firmware. In this
guide we will assume development is to be carried out on an ARM based
platform, though it is likely that the process would be broadly similar
for targets utilising other architectures as well.
# Development Environment
In order to perform the required development a suitable development
environment will be required. It is likely that early development steps
could be carried out on any Linux host with a suitable toolchain
available. As development progresses the required feature set of the
toolchain will grow and will incorporate tools generally only found in
Debian based development systems. In order to ensure that prospective
Apertis developers have access to a suitable environment, the Apertis
project makes available a [Software Development
Kit](https://wiki.apertis.org/Deployment_Environment) (SDK) which can be
used through VirtualBox.
# Boot firmware source
The two code bases that are most likely to need to be adapted or
configured to bring-up the target hardware are a boot loader, such as
U-Boot and the Linux kernel. Whilst, within reason, any relatively
recent version of a boot loader and Linux kernel can be used some of the
advanced features supported by Apertis have required specific
configuration changes and/or changes to be made to the boot loader and
kernel. In order to minimise work required to support such features
(should they be needed at a later date) and to take full advantage of
the efficiencies afforded by the Apertis platform, it is advisable to
start from the current supported Apertis bootloader. Apertis stores it's
source code in gitlab the currently supported bootloader and kernel can
be found here:
- [U-Boot](https://gitlab.apertis.org/pkg/target/u-boot)
- [Linux Kernel](https://gitlab.apertis.org/pkg/target/linux)
# Development process
## Bootloader Development
Unless developing for a target utilising an Architecture or SoC not
currently supported by the chosen firmware (something that is out of
scope for this guide), it is likely that the initial focus will be on
ensuring that the firmware is correctly configuring the memory timing,
pin multiplexing and serial port configuration . These are generally
configured in a board support file in the U-Boot firmware under
`board/`. Whilst serial ports have broadly been replaced in their
traditional use cases, the simplicity of the port means that it remains
a very common mechanism for sending boot process and debug messages
during board bring-up. If these settings are correctly configured, this
is usually enough to get early an boot message via the serial port when
booted.
Generally it is not necessary to start from scratch. The U-Boot source
contains support for a myriad of existing targets and it's acceptable to
pick support for an existing board, copy it and use that as a basis for
your own board. Please note that whilst this can be more efficient that
starting from scratch, there is a risk of picking up a board that
doesn't follow the latest preferred style/mechanisms, so it's worth
spending a bit of time looking at the available boards and understanding
which mechanisms are being used in the latest boards.
In order to ensure the development process is as efficient as possible,
it is advisable to utilise any available process that allows the target
to be booted from a remote source. In the case of the ARM architecture,
most if not all System-on-Chips (SoCs) provide some mechanism to boot
the device over USB using a SoC specific protocol to load the boot
firmware into RAM. On many SoCs, the boot process must be broken down
into multiple stages as the default state of the system is unable to
handle the size of a full U-Boot binary. In order to enable bigger
binaries to be loaded, U-Boot has the concept of a Secondary Program
Loader (SPL). This is a smaller cut-down version of U-Boot that is
loaded before the main U-Boot binary and is used to configure the system
sufficiently to enable the main U-Boot binary to be loaded. (In fact on
some systems there is also a Tertiary Program Loader (TPL) to enable
loading of the SPL.) U-Boot is able to handle a number of these SoC
specific protocols allowing the multiple stages of U-Boot to be loaded
via these mechanisms. For later components in the boot process, network
booting such as TFTP usually becomes a viable option.
In order to maximise driver reuse and to allow a single binary to
support multiple target platforms, both U-Boot and the Linux kernel make
use of a [device tree](https://elinux.org/Device_Tree_What_It_Is) to
describe the non-discoverable hardware available in a given target
system. It is common to utilise the same device tree in both U-Boot and
the Linux kernel, potentially with an overlay in U-Boot to provide
U-Boot specific customisations to the device tree. The device tree
enables U-Boot's Driver Model (DM) to instantiate drivers to drive
compatible hardware wherever they sit in the devices memory map. The use
of device trees means that for any already supported SoCs, a large part
of the work associated with initial bring up is in adding the required
nodes to the device tree to describe the hardware and enabling the
required drivers. Where possible it is highly recommended to utilise
U-Boot's driver model.
### Apertis Requirements
Apertis utilises the "[Generic Distro Configuration
Concept](https://gitlab.denx.de/u-boot/u-boot/raw/master/doc/README.distro)"
(often referred to as "Distro Boot") during it's boot process. It is
recommended to enable both the required local boot media, PXE and DHCP
options via the `BOOT_TARGET_DEVICES` macro, the PXE and DHCP options
being especially useful during development as this allows the kernel and
subsequent binaries in the boot process to be provided via a network
interface. Such a network interface may be an Ethernet connection
provided by the target board (and enabled in U-Boot) or if no Ethernet
port is available, it is possible to provide networking with a USB RNDIS
gadget should a USB On-The-Go (USB OTG) port be available. This allows
U-Boot to retrieve boot configuration and the required binaries, such as
the Linux kernel, device tree binary (DTB) and initrd, via TFTP.
## Kernel Development
Once U-Boot has reached the point where it can load via the Distro Boot
mechanism we can start to focus on the Linux kernel rather than U-Boot.
At this point we are likely to have a simple device tree, providing
nodes for the minimal support that we've needed to add for the limited
functionality we need in the bootloader. This can be integrated into the
kernel source tree and needs to be expanded whilst enabling support for
board features required at runtime, but which are not required as part
of the bootloader.
In order to provide a user space environment for testing on the target
device, especially before the on-board storage has been enabled and
initialised, it is common to use a [NFS based root file
system](https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt).
This requires networking and NFS support to be enabled in the kernel and
the location of the NFS root can be specified via the Distro Boot
configuration. This of course requires a roof file system and the
Apertis minimal OSpack (downloadable from
[images.apertis.org](https://images.apertis.org)) can be extracted and
used to provide this. The minimal image can be easily extended using
`apt` to install and tools and utilities needed to test the interfaces
and peripherals attached to the system.
Once a point has been reached where the device tree adequately describes
the hardware found in the target platform, it is worth spending the time
to update the device tree found in the U-Boot source to match the one
found in the kernel source to ensure that the two stay in sync.
### Apertis Requirements
In order to support the Apertis user space, the kernels support for
Apparmor should be enabled as this is widely used by Apertis for process
containment. As Apertis uses systemd, it is necessary to also ensure
that the [kernel configuration
options](https://github.com/systemd/systemd/blob/master/README) required
by systemd are also enabled. This will be the case if starting from the
existing [Apertis kernel
configuration]( {{< ref "/guidelines/buildingpatchingandmaintainingtheapertiskernel.md#building" >}} ).
Further guidance regarding the integration of specific hardware is
provided in [Hardware Interfaces]( {{< ref "/hardware_interfaces.md" >}} ).
## Packaging Components
Once we have a kernel booting to an NFS-based rootfs with sufficient
support (including the local storage that is to be used), we need to
package the bootloader and kernel. If using the Apertis supplied
bootloader and kernel, a lot of the necessary metadata will already be
in place and the workflow has been documented in [Building, Patching And
Maintaining The Apertis
Kernel]( {{< ref "/guidelines/buildingpatchingandmaintainingtheapertiskernel.md" >}} ).
If working from a kernel from another source, it will be necessary to
become familiar with [Debian
packaging](https://wiki.debian.org/Packaging/Intro). Note that the
Debian kernel (and thus the Apertis kernel) utilise a slightly modified
approach to configuration compared with most deb packages due to the
special nature of the kernel. More information about the kernel
configuration, see the Debian kernel's
[README.Debian](https://salsa.debian.org/kernel-team/linux/blob/master/debian/README.Debian).
## Creating Target Specific Images
Once the bootloader and kernel have been packaged, an image suitable for
loading onto the device can be created. Building these packages is
expected to be carried out from source by the Apertis infrastructure,
ensuring all packages dependencies are properly described and reducing
the risk of unexpected dependencies. This also results in the packages
being made available in a deb package repository and thus available by
the image creation tooling.
These packages are usually assembled into 2 bigger building blocks
before ultimately being combined, the `OSpack` and the `HWpack`. The
process is managed by a tool called
[Debos](https://github.com/go-debos/debos), which uses yaml
configuration files to guide what steps it takes.
### OSpack
The OSpack is a generic (architecture specific but largely hardware
independent) archived rootfs built from Apertis packages. Apertis
provides Debos yaml files to assemble a number of differently targeted
OSpacks, ranging from a minimal GUI-less OSpack, a target focused GUI
OSpack and a development environment with a desktop style GUI.
### HWpack
Unlike the OSpack, that is generic, the hardware pack (HWpack) contains
the bits needed to boot on a specific target. The HWpack is not a single
item, it is a number of packages and processes, controlled via a Debos
script, that convert a hardware independent OSpack into an image which
can be successfully booted on a specific hardware platform. It is
expected a small number of OSpacks to be combined with a number of
HWpacks to create an array of images suitable for a wide range of
targets.
The configuration used to create OSpacks and images from them for the
Apertis reference platforms can be found in
[GitLab](https://gitlab.apertis.org/infrastructure/apertis-image-recipes)
with their use documented in `README.md`.
To find out more about the process of creating OSpacks and HWpacks, see
[Image Building]( {{< ref "/image_building.md" >}} ).
### Building images for hypervisors and virtual machines
TBD (Basically the same as packaging for real hardware)
# Testing
TBD
- Boot test on both new and existing hardware
<!-- end list -->
- Boot test
- Ensure changes do not result in regressions against Apertis tests
# Submitting Upstream
The Apertis project strongly supports the concept of upstreaming and
supports it's users to upstream. The Apertis project provides
documentation covering [why, where and
what](https://designs.apertis.org/latest/upstreaming.html) to upstream,
as well as [guidance on the upstreaming
process](https://designs.apertis.org/latest/contribution-process.html).
\ No newline at end of file
+++
date = "2019-11-14"
weight = 100
title = "User:Martyn Main Page"
aliases = [
"/old-wiki/User:Martyn/Main_Page"
]
+++
Apertis is a versatile open source infrastructure tailored to the
automotive needs and fit for a wide variety of electronic devices.
Security and modularity are two of its primary strengths. Apertis
provides a feature-rich framework for add-on software and resilient
upgrade capabilities. Beyond an operating system, it offers new APIs,
tools and cloud services.
<table>
<tbody>
<tr class="odd">
<td><table>
<tbody>
<tr class="odd">
<td><h2 id="mp-tfa-h2" style="margin:3px; background:#3a5a82; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#ffffff; padding:0.2em 0.4em;">
<p>Production Friendly</p>
</h2></td>
</tr>
<tr class="even">
<td><div id="mp-tfa" style="padding:2px 5px">
<p>Apertis aims to accomplish the following goals:</p>
<ul>
<li>Ensure that all the software shipped in Apertis is open source or at least freely distributable, so that downstreams are entitled to use, modify and redistribute work derived from our deliverables.</li>
<li>Ensure that Apertis images targeting devices (such as target and minimal), are not subject to licensing constraints that may conflict with the regulatory requirements of some intended use cases.</li>
</ul>
<p>Apertis is primarily licensed under the Mozilla Public License Version 2.0, with images and documentation licensed under CC BY-SA 4.0.</p>
<p>For more information see <a href="https://designs.apertis.org/latest/license-expectations.html">Open source License expectations</a>.</p>
<p>Apertis undergoes regular automated and manual testing with publicly available results.</p>
<p>For more information see</p>
<h2 id="further-links-1">Further Links</h2>
<ul>
<li><a href="https://designs.apertis.org/latest/license-expectations.html">Licensing</a></li>
<li><a href=" {{< ref "/build_and_integration_infrastructure_documentation.md" >}} ">Build and Integration infrastructure</a></li>
<li><a href=" {{< ref "/qa.md" >}} ">Quality assurance</a></li>
<li><a href="https://lavaphabbridge.apertis.org">Test results</a></li>
</ul></td>
</tr>
</tbody>
</table></td>
<td></td>
<td><table>
<tbody>
<tr class="odd">
<td><h2 id="mp-itn-h2" style="margin:3px; background:#3a5a82; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#ffffff; padding:0.2em 0.4em;">
<p>Frequent Releases</p>
</h2></td>
</tr>
<tr class="even">
<td><div id="mp-itn">
<p>The overall goal is for Apertis to do a yearly product release. These releases will be named after the year of the stable release, in other words the product release targetted at 2020 will be given major version 2020. A product release is intended to both be based on the most recent mainline kernel LTS release and the current Debian stable release. Since Debian releases roughly once every two years, that means that there will typically be two Apertis product releases based on a single Debian stable release. With Linux doing an LTS release on a yearly basis, each Apertis product release will be based on a different (and then current) Linux kernel release.</p>
<p>The standard support period for each Apertis product release is 7 quarters. In other words from the initial release at the end of Q1 until the end of the next year.</p>
<p>For more information, see <a href="https://designs.apertis.org/latest/release-flow.html">Release flow and product lines</a>.</p>
<h2 id="further-links-3">Further Links</h2>
<ul>
<li><a href=" {{< ref "/releasenotes.md" >}} ">Releases</a></li>
<li><a href=" {{< ref "/roadmap.md" >}} ">Roadmap</a></li>
<li><a href=" {{< ref "/v2019.0/release_schedule.md" >}} ">Release schedule for V2019.0</a></li>
<li><a href=" {{< ref "/v2020dev0/release_schedule.md" >}} ">Release schedule for V2020dev0</a></li>
</ul></td>
</tr>
</tbody>
</table></td>
<td></td>
<td><table>
<tbody>
<tr class="odd">
<td><h2 id="mp-itn-h2" style="margin:3px; background:#3a5a82; font-family:inherit; font-size:120%; font-weight:bold; border:1px solid #a3b0bf; text-align:left; color:#ffffff; padding:0.2em 0.4em;">
<p>Developer Ready</p>
</h2></td>
</tr>
<tr class="even">
<td><div id="mp-itn">
<p>Apertis provides a number of pre-built images for Intel (64-bit) and ARM (32-bit and 64-bit) for evaluation on one of the Apertis <a href="https://wiki.apertis.org/Reference_Hardware">Reference Hardware</a> platforms. Additionally Apertis provides an SDK image to simplify development for the platform.</p>
<p><img src="/images/vm-sdk.png" alt="frameless|center|The Apertis SDK"></p>
<h2 id="further-links-5">Further Links</h2>
<ul>
<li><a href=" {{< ref "/apertis_code_of_conduct.md" >}} ">Code of conduct</a></li>
<li><a href=" {{< ref "/images.md" >}} ">Download the current images</a></li>
<li><a href=" {{< ref "/deployment_environment.md" >}} ">Set up your development environment</a></li>
<li><a href="https://gitlab.apertis.org">Source code</a></li>
<li><a href=" {{< ref "/guidelines.md" >}} ">Development guidelines</a></li>
<li><a href="https://developer.apertis.org">App developer portal</a></li>
<li><a href="https://lists.apertis.org/">Mailing lists</a></li>
<li><a href="https://images.apertis.org/">Images</a></li>
<li><a href="https://repositories.apertis.org/">Repositories</a></li>
<li><a href=" {{< ref "/conceptdesigns.md" >}} ">Concept designs</a></li>
<li><a href="https://developer.apertis.org/latest/apis.html">Supported APIs</a></li>
</ul></td>
</tr>
</tbody>
</table></td>
</tr>
</tbody>
</table>
\ No newline at end of file
+++
date = "2019-11-25"
weight = 100
title = "User:Peter"
aliases = [
"/old-wiki/User:Peter"
]
+++
[User:Peter/HWPACKforVendors](https://wiki.apertis.org/User:Peter/HWPACKforVendors)
\ No newline at end of file
+++
date = "2019-11-25"
weight = 100
title = "User:Peter HWPACKforVendors"
aliases = [
"/old-wiki/User:Peter/HWPACKforVendors"
]
+++
# Apertis hwpack: requirements for vendors
This is the output of
[APERTIS-6608](https://phabricator.apertis.org/T6608).
## Introduction
Adding support to a new architecture, or to a new board is done trough
cycles of hardware bring-up. During each cycle, the developer enables
new features, or fixes known issues until the hardware support is
considered adequate. On a low level perspective, hardware bring-up is
about developing and adjusting a few components such as the boot loader
and the kernel to provide the hardware initialization and hardware
support for the operating system. When using Apertis, the output of the
hardware bring-up will be the hwpack, which is a platform specific
collection of artifacts that are needed for the hardware initialization
and support.
[Debos](https://github.com/go-debos/debos) is the main tool used for
building Apertis images. Debos allows for modular design of images, and
is capable of creating the modules and the images. The image modules
used by Apertis are:
`* hwpack: platform-specific artifacts related to hardware initialization and hardware support`
`* ospack: platform-independent artifacts common to a set of images such as target or development images`
The
[apertis-image-recipes](https://gitlab.apertis.org/infrastructure/apertis-image-recipes)
is the code repository that hosts the Debos recipes that are used for
creating Apertis images. While the ospack recipes are explicitly named,
the hwpacks are defined inside the apertis-image-\*.yaml files. The
rationale is that the hwpack is a set of steps and components that
extends the ospack to boot on the target. Looking at the
[apertis-image-uboot.yaml](https://gitlab.apertis.org/infrastructure/apertis-image-recipes/blob/apertis/v2020pre/apertis-image-uboot.yaml)
recipe, we see that Debos uncompress the ospack to add changes on top of
it, that it creates the image with partition scheme, filesystems,
u-boot, and that it deploys the modified ospack into the image adding
hwpack artifacts such as the kernel, and other system packages.
Apertis is both a platform and the automated infrastructure that is used
to conveniently evolve and cheaply maintain the platform. The
infrastructure uses automation to ensure quality and minimize
maintenance costs. Some of the hwpack requirements and suggestions are
in place to avoid deviation from the existing Apertis processes.
## Requirements
### Source code
### Long term support
### Updates
### Security fixes
### Boot loader
### Kernel
## Suggestions
### Boot loader
### Kernel
## Example of Apertis hwpack
## Final words
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment