summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--getting-started/customize_bitbake_conf.md48
-rw-r--r--getting-started/footers/intel-footer.md47
-rw-r--r--getting-started/footers/raspberrypi-footer.md2
-rw-r--r--getting-started/machines/R-Car-Starter-Kit-gen3.md109
-rw-r--r--getting-started/machines/intel.md37
-rw-r--r--getting-started/machines/porter.md2
-rw-r--r--getting-started/machines/raspberrypi.md2
-rw-r--r--getting-started/setup-sdk-environment.md24
-rw-r--r--getting-started/source-code.md14
-rw-r--r--getting-started/troubleshooting.md51
-rw-r--r--platform/working-on-the-chinook-branch.md103
-rw-r--r--platform/working-on-the-master-branch.md103
-rw-r--r--sec-blueprint/04-adversaries.md65
13 files changed, 467 insertions, 140 deletions
diff --git a/getting-started/customize_bitbake_conf.md b/getting-started/customize_bitbake_conf.md
new file mode 100644
index 0000000..dc7dc6b
--- /dev/null
+++ b/getting-started/customize_bitbake_conf.md
@@ -0,0 +1,48 @@
+# Customize AGL build
+To customize the AGL build, you edit local.conf file, located in the build/conf directory.
+
+```
+edit $AGL_TOP/build/conf/local.conf
+```
+
+## Buildhistory
+The OpenEmbedded build system creates this directory when you enable the build history feature.
+
+```
+INHERIT += "buildhistory"
+BUILDHISTORY_COMMIT = "1"
+```
+
+For more information please check [Here][buildhistory]
+
+## Deletion of temporary workspace
+Removes work files after the OpenEmbedded build system has finished with them.
+
+```
+INHERIT += "rm_work"
+```
+
+For more information please check [Here][rm_work]
+
+## Share sstate cache
+The directory for the shared state cache.
+
+```
+SSTATE_DIR = "${HOME}/workspace_agl/sstate-cache"
+```
+
+For more information please check [Here][share_sstatecache]
+
+## Share Download directory
+The central download directory used by the build process to store downloads.
+
+```
+DL_DIR = "${HOME}/workspace_agl/downloads"
+```
+
+For more information please check [Here][share_download]
+
+[buildhistory]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#maintaining-build-output-quality
+[rm_work]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-tasks-rm_work
+[share_sstatecache]: https://wiki.yoctoproject.org/wiki/Enable_sstate_cache
+[share_download]: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-DL_DIR
diff --git a/getting-started/footers/intel-footer.md b/getting-started/footers/intel-footer.md
new file mode 100644
index 0000000..191ff98
--- /dev/null
+++ b/getting-started/footers/intel-footer.md
@@ -0,0 +1,47 @@
+## BIOS update
+Both the Joule and the Minnowboard require a BIOS upgrade. **Don t loose time trying without.**<br>
+https://firmware.intel.com/projects/minnowboard-max<br>
+https://software.intel.com/en-us/flashing-the-bios-on-joule
+
+## Creating a bootable image
+Multiple options are avaiable but dd and tar can very easily let you down due to the requirement to pass SMACK labels, create a proper UEFI configuration and a few other tricks.<br>
+The script [mkefi-agl.sh](https://github.com/dominig/mkefi-agl.sh) has been done to help you.<br>
+The option -h will print the help and the option -v will detailled the operation and ease any debug.<br>
+
+## Selecting the SD or USB to boot.
+When booting a Minnowboard or a Joule you can change the default boot device by hitting F2 during initial UEFI boot.
+It's easier to acheive it in the right time with a USB keyboard than via serial link.
+During boot USB hub are not supported, you need to connect the keyboard directly in the USB socket.<br>
+It's also preferable to use F9 and to change the boot order once for all.<br>
+Please note: You can only change the boot order, when a valid device is inserted in the corresponding port (USB or SD).
+
+The Minnow, Joule, many laptops and NUCs will not accept to boot with some USB3 stick. If you have some trouble to get your USB3 stick detected during boot, swap it for a USB2. In anycase working with SD card is faster to flash and to boot. SD should be prefered.<br>
+The Joule seems to refuse to boot with my SD-HC-I type cards while I had no problem with the Minnow. If you work with a Joule, use regular SD-HC (mode 4 and 10 work fine)
+
+
+## Serial debug Port
+
+Serial debug port ID varies with the HW platform :<br>
+By default AGL build Intel target as a Minnowboard where serial is /dev/ttyS0 <br>
+On Joule and MRB the serial debug is /dev/ttyS2 <br>
+
+You may have to change the configuration in your boot loader which is located in the EFI partition.
+
+## Serial debug cable
+
+On the Minnowboard the serial cable is a FTDI serial cable. The wiring can be found [here](http://wiki.minnowboard.org/MinnowBoard_MAX_HW_Setup).<br>
+On the Joule the serial connection is done via the micro USB cable which is not provided in the Developer kit. Details can be found [here](https://software.intel.com/en-us/node/667851).<br>
+Interface speed is 115200 bps, 8 bits, no parity, no flow control
+
+## Which port name is used to define the connected display(s)
+
+Port naming may change with HW platforms and connected display. The simplest is to check following the fist boot, in the systemd journal which display names are listed.<br>
+```
+journalctl |grep Output
+```
+**Note:** The Output information is only listed if a real Display is connected to the connector on the board.<br>
+The file holding that configuration is /etc/xdg/weston/weston.ini<br>
+Common Display name for Intel are
+* HDMI-A-1
+* HDMI-A-2
+* LVDS-1
diff --git a/getting-started/footers/raspberrypi-footer.md b/getting-started/footers/raspberrypi-footer.md
index 99964c8..cb914dc 100644
--- a/getting-started/footers/raspberrypi-footer.md
+++ b/getting-started/footers/raspberrypi-footer.md
@@ -53,4 +53,4 @@ It is possible to debug AGL images on Raspberry Pi using 3.3V USB to serial cabl
sudo screen /dev/ttyUSB0 115200
```
-Pay attention that the colours of the cable may vary depending on the vendor. If you have USB console cable from Adafruit please have a look [here](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead).
+Pay attention that the colors of the cable may vary depending on the vendor. If you have USB console cable from Adafruit please have a look [here](https://learn.adafruit.com/adafruits-raspberry-pi-lesson-5-using-a-console-cable/connect-the-lead).
diff --git a/getting-started/machines/R-Car-Starter-Kit-gen3.md b/getting-started/machines/R-Car-Starter-Kit-gen3.md
index d75a52e..e18de67 100644
--- a/getting-started/machines/R-Car-Starter-Kit-gen3.md
+++ b/getting-started/machines/R-Car-Starter-Kit-gen3.md
@@ -1,9 +1,9 @@
-# AGL Kickstart on Renesas R-Car Starter Kit Gen3 (h3ulcb, m3ulcb)
+# AGL Kickstart on Renesas R-Car Starter Kit Gen3 V2.16 (h3ulcb, m3ulcb)
Here is a non exhaustive list of hardware parts that could be used to setup the R-Car Starter Kit Gen3 board development environment:
* Starter Kit Gen3 board with its power supply
-* mini USB-A cable for serial console
+* micro USB-A cable for serial console
* USB 2.0 Hub
* Ethernet cable
* HDMI type D (Micro connector) cable and associated display
@@ -23,9 +23,9 @@ The following documents may also be helpful:
Before setting up the build environment, you need to download the proprietary drivers.
-* Download Renesas graphics drivers with a "click through" license from Renesas website [Link][rcar demoboard]
+* Download Renesas graphics drivers with a "click through" license from Renesas website [Link][rcar Linux] and [Link][rcar Linux Drivers]
* Under the Target hardware: **R-Car H3/M3** section.
-
+
#### Note:
* You have to register with a free account on MyRenesas and accept the license conditions before downloading them the drivers.
@@ -36,10 +36,10 @@ Here after is an example of the typical files downloaded at the time of writing:
```
chmod a+r $XDG_DOWNLOAD_DIR/*.zip
-ls -l $XDG_DOWNLOAD_DIR
+ls -1 $XDG_DOWNLOAD_DIR
total 8220
--rw-r--r-- 1 XXX XXX 4619114 14 sept. 05:02 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20160906.tar.gz
--rw-r--r-- 1 XXX XXX 4619796 10 oct. 23:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20160906.zip
+-rw-r--r--. 1 1664 agl-sdk 4.5M Dec 8 15:23 R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20170125.zip
+-rw-r--r--. 1 1664 agl-sdk 2.5M Dec 8 15:24 R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20170125.zip
```
## Setting up the build environment:
@@ -73,12 +73,14 @@ In case of missing graphics drivers, you could notice an error message as follow
[snip]
--- fragment /home/working/workspace_agl_master/meta-agl/templates/machine/h3ulcb/50_setup.sh
/home/working/workspace_agl_master /home/working/workspace_agl_master/build_gen3
-The graphics and multimedia acceleration packages for the R-Car Gen3 board can be download from :
- <http://www.renesas.com/secret/r_car_download/rcar_demoboard.jsp>
-
-These 2 files from there should be store in your'/home/ronan/Téléchargements' directory.
- R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20160906.zip
- R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20160906.zip
+The graphics and multimedia acceleration packages for
+the R-Car Gen3 board can be downloaded from:
+ https://www.renesas.com/en-us/software/D6000821.html
+ https://www.renesas.com/en-us/software/D6000822.html
+
+These 2 files from there should be store in your'/home/devel/Téléchargements' directory.
+ R-Car_Gen3_Series_Evaluation_Software_Package_for_Linux-20170125.zip
+ R-Car_Gen3_Series_Evaluation_Software_Package_of_Linux_Drivers-20170125.zip
/home/working/workspace_agl_master/build_gen3
--- fragment /home/working/workspace_agl_master/meta-agl/templates/base/99_setup_EULAconf.sh
--- end of setup script
@@ -168,7 +170,8 @@ lsblk
└─sdc2 8:34 1 788M 0 part
```
-**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time: so you should repeat this operation each time you insert the microSD card to confirm the device name.
+**IMPORTANT NOTE**: This is a critical operation, each computer is different and removable devices can change from time to time:
+so you should repeat this operation each time you insert the microSD card to confirm the device name.
In the example above, we see:
* the first SATA drive as 'sda'.
@@ -282,12 +285,12 @@ sudo $TAR --extract --numeric-owner --preserve-permissions --preserve-order --to
Copy Kernel Image and Device Tree Blob file into the **boot** directory:
* For machine h3ulcb:
```
-sudo cp Image-r8a7795-h3ulcb.dtb /tmp/agl/boot/
+sudo cp Image-r8a7795-h3ulcb.dtb $SDCARD/boot/
```
* For machine m3ulcb:
```
-sudo cp Image-r8a7796-m3ulcb.dtb /tmp/agl/boot/
+sudo cp Image-r8a7796-m3ulcb.dtb $SDCARD/boot/
```
Ensure the changes have been written to the disk:
@@ -320,9 +323,11 @@ After a few seconds, you'll see the AGL splash screen on the display and you'll
This can be “screen”, “picocom”, “minicom”.
The lighter of the 3 is “picocom” (it has less dependencies).
-## Plug a USB cable from your computer to the serial CP2102 USB port (mini USB-A).
+## Plug a USB cable from your computer to the serial CP2102 USB port (micro USB-A).
-With “dmesg” you can check the device created for the serial link. Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host. To get it, you must switch the board on.
+With “dmesg” you can check the device created for the serial link.
+Usually, it's /dev/ttyUSB0 but the number may vary depending on other USB serial ports connected to the host.
+To get it, you must switch the board on.
For example:
```
@@ -442,13 +447,15 @@ Hit any key to stop autoboot: 0
## Configure U-boot parameters
+Follow the steps below to configure the boot from microSD card and to set screen resolution:
+
* Turn the board on using the power switch.
* Hit any key to stop autoboot (warning you have only few seconds).
-* Check if you have correct parameters for booting your board:
+* Type **print** to check if you have correct parameters for booting your board:
* For machine m3ulcb:
-
+
```
-=> print
+=> printenv
baudrate=115200
bootargs=console=ttySC0,115200 root=/dev/mmcblk1p1 rootwait rw rootfstype=ext4
bootcmd=run load_ker; run load_dtb; booti 0x48080000 - 0x48000000
@@ -518,63 +525,6 @@ saveenv
run bootcmd
```
-### U-Boot screen configuration
-
-Follow the steps below to configure the boot from microSD card and to set screen resolution:
-
-* Power up the board
-* Using your preferred terminal emulator, type a character to abort the boot and enter the U-boot menu
-* Type **print** to check the environment:
-
-```
-print
-```
-
-* Verify that the ethaddr environment variable is set to the same MAC address value shown on the label on top of the RJ45 Ethernet connector.
-* If not, set it using the following command:
-
-```
-setenv ethaddr <MAC address>
-```
-
-For example:
-
-```
-setenv ethaddr 2e:09:0a:00:75:b5
-```
-
-* Set the follow environment variables:
-
-```
-setenv bootargs_console 'console=ttySC6,38400 ignore_loglevel'
-setenv bootargs_video 'vmalloc=384M video=HDMI-A-1:1920x1080-32@60'
-setenv bootargs_root 'root=/dev/mmcblk0p1 rootdelay=3 rw rootfstype=ext4 rootwait'
-setenv bootmmc '1:1'
-setenv bootcmd_sd 'ext4load mmc ${bootmmc} 0x40007fc0 boot/uImage+dtb'
-setenv bootcmd 'setenv bootargs ${bootargs_console} ${bootargs_video} ${bootargs_root}; run bootcmd_sd; bootm 0x40007fc0'
-```
-
-**WARNINGS:**
-If no display shows up when booting, e.g. for a non-full HD screen, replace **1920x1080** value in the **bootargs_video** variable with lower screen resolution such as **1024x768**.
- Unfortunately at the moment, there is no universally supported setting.
-
-For Renesas h3ulcb use screen resolution **1024x768** and set **bootmmc** to **2:1**.
-
-* Save the environment variables:
-
-```
-saveenv
- Saving Environment to SPI Flash...
- SF: Detected S25FL512S with page size 256 KiB, total 64 MiB
- Erasing SPI flash...Writing to SPI flash...done
-```
-
-* Reboot:
-
-```
-reset
-```
-
## Console boot
After booting, you should see the wayland display on the external monitor and a login prompt on the console, such as:
@@ -645,7 +595,8 @@ Generic guide on how to add a new service in the BSP.
[R-car m3ulcb]: http://elinux.org/R-Car/Boards/M3SK
[R-car h3ulcb]: http://elinux.org/R-Car/Boards/H3SK
[R-car yocto]: http://elinux.org/R-Car/Boards/Yocto-Gen3
-[rcar demoboard]: https://www.renesas.com/en-eu/solutions/automotive/rcar-demoboard.html
+[rcar Linux]: https://www.renesas.com/en-us/software/D6000821.html
+[rcar Linux Drivers]: https://www.renesas.com/en-us/software/D6000822.html
[Iot.bzh AGL-Kickstart-on-Renesas-Porter-Board]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Kickstart-on-Renesas-Porter-board.pdf
[Iot.bzh AGL-Devkit-Image-and-SDK-for-Porter]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Image-and-SDK-for-porter.pdf
[Iot.bzh AGL-Devkit-Build-your-1st-AGL-Application]: http://docs.automotivelinux.org/docs/devguides/en/dev/reference/iotbzh2016/sdk/AGL-Devkit-Build-your-1st-AGL-Application.pdf
diff --git a/getting-started/machines/intel.md b/getting-started/machines/intel.md
index 9c71d87..6e29ab5 100644
--- a/getting-started/machines/intel.md
+++ b/getting-started/machines/intel.md
@@ -4,18 +4,20 @@
This documentation is aiming at people who want to run Automotive Grade
Linux (AGL) on an Intel Hardware (HW).
While the reference HW used by AGL project is the Open Source Minnowboard.
-This documentation [MinnowBoard wiki](http://wiki.minnowboard.org/MinnowBoard\_Wiki\_Home)
-can be used to enable most of 64 bits Intel Architecture (IA) using UEFI as boot loader.
+This documentation [MinnowBoard wiki](https://minnowboard.org/)
+can be used to enable most of 64 bits Intel Architecture (IA) using UEFI as boot loader.<br>
+In addition to the MinnowBoard, support for the the [Joule Developer Kit](https://software.intel.com/en-us/iot/hardware/joule/dev-kit) has been added.
You need to run the 64 bits version of the UEFI boot.
-Minnowbaord Max and Turbo are both 64 bits capable.
+Minnowbaord Max and Turbo has well as the Joule are both 64 bits capable.
**Note** :
* This page is more focused on please willing to create bespoke AGL image and BSP.
If you are more interested by Apps creation, please visit [ Developing Apps for AGL](https://wiki.automotivelinux.org/agl-distro/developer_resources_intel_apps)
-UEFI has evolved a lot recently and you likely want to check that your HW firmware is up-to-date, this is particularly important for the Minnowboard.
+UEFI has evolved a lot recently and you likely want to check that your HW firmware is up-to-date, this is mandatory for the Minnowboard and the Joule.
-[`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max)
+[`https://firmware.intel.com/projects/minnowboard-max`](https://firmware.intel.com/projects/minnowboard-max)<br>
+[`https://software.intel.com/en-us/flashing-the-bios-on-joule`](https://software.intel.com/en-us/flashing-the-bios-on-joule)
## Where to find an AGL bootable image
@@ -40,27 +42,18 @@ To install the repo tool.
chmod a+x ~/bin/repo;
```
-#### Configuring for the current *(older)* stable (blowfish\_2.0.4) (BB)
+#### Configuring for the current *(older)* stable (Charming Chinook 3.0.x)
```bash
- cd AGL-2.0.4;
- repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo -b blowfish -m default_blowfish_2.0.4.xml
+ cd AGL-3.0.x;
+ repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
```
-#### Configuring for master (CC)
+#### Configuring for master (DD)
```bash
cd AGL-master;
repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo;
```
-
-#### Only for developer working on virtualisation
-**Note :**:
-This is WIP and most likely to fail most of the time)
-```bash
- cd AGL-master-next;
- repo init -b morty -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo;
-```
-
Once that you repo is initialised either with the stable or WIP, you need to sync the repo to fetch the various git trees.
#### Downloading the configured AGL source code
@@ -77,19 +70,21 @@ When running the command:
source meta-agl/scripts/aglsetup.sh -h
```
-You will notice the Intel entry
+You will notice the Intel entries
```bash
intel-corei7-64
+ joule
```
-Simply select that entry to replace porter in the -m option.
+Simply select that entry to replace porter in the -m option.<br>
```bash
source meta-agl/scripts/aglsetup.sh \
-m intel-corei7-64 \
-b build \
- agl-devel agl-demo agl-appfw-smack agl-netboot
+ agl-devel agl-demo agl-appfw-smack agl-netboot<br>
```
+**Note:** use the option "-m joule" when building for a Joule developer Kit target.
Start the build **This can take several hours depending of your CPU and
internet connection and will required several GB on /tmp as well as on your build directory**
diff --git a/getting-started/machines/porter.md b/getting-started/machines/porter.md
index fe585fc..f3f6d15 100644
--- a/getting-started/machines/porter.md
+++ b/getting-started/machines/porter.md
@@ -364,7 +364,7 @@ setenv ethaddr 2e:09:0a:00:75:b5
```
setenv bootargs_console 'console=ttySC6,38400 ignore_loglevel'
setenv bootargs_video 'vmalloc=384M video=HDMI-A-1:1920x1080-32@60'
-setenv bootargs_root 'root=/dev/mmcblk0p1 rootdelay=3 rw rootfstype=ext3 rootwait'
+setenv bootargs_root 'root=/dev/mmcblk0p1 rootdelay=3 rw rootfstype=ext4 rootwait'
setenv bootmmc '1:1'
setenv bootcmd_sd 'ext4load mmc ${bootmmc} 0x40007fc0 boot/uImage+dtb'
setenv bootcmd 'setenv bootargs ${bootargs_console} ${bootargs_video} ${bootargs_root}; run bootcmd_sd; bootm 0x40007fc0'
diff --git a/getting-started/machines/raspberrypi.md b/getting-started/machines/raspberrypi.md
index 4d4185f..19a41ce 100644
--- a/getting-started/machines/raspberrypi.md
+++ b/getting-started/machines/raspberrypi.md
@@ -28,6 +28,8 @@ Follow the steps below to copy the image to microSD card and to boot it on Raspb
* Output Image location in build machine for Raspberry Pi 3: *tmp/deploy/images/raspberrypi3/agl-demo-platform-raspberrypi3.rpi-sdimg*
* Unmount the microSD card and after that flash output image to it card with root user:
+*Note: the sdimage files can also be named rpi-sdimg-ota in case you have the **"agl-sota"** feature enabled*
+
```
sudo umount [sdcard device]
sudo dd if=[output image] of=[sdcard device] bs=4M
diff --git a/getting-started/setup-sdk-environment.md b/getting-started/setup-sdk-environment.md
index 3776621..1435b50 100644
--- a/getting-started/setup-sdk-environment.md
+++ b/getting-started/setup-sdk-environment.md
@@ -35,20 +35,20 @@ chmod a+w ~/ssd ~/devel
### Get docker image
#### Pre-built image
-A pre-built image is available on [IoT.bzh](http://iot.bzh) public site and can be used directly.
+A pre-built image is available on automotivelinux download public site and can be used directly.
First, download and load the image in your local Docker instance:
```bash
-wget -O - http://iot.bzh/download/public/2016/docker/docker_agl_worker-2.1.tar.xz | docker load;
+wget -O - https://download.automotivelinux.org/AGL/snapshots/sdk/docker/docker_agl_worker-3.0.tar.xz | sudo docker load;
docker images;
REPOSITORY TAG IMAGE ID CREATED SIZE
- docker.automotivelinux.org/agl/worker 2.1 42009148bc03 6 days ago 926.9 MB
+ docker.automotivelinux.org/agl/worker 3.0 42009148bc03 6 days ago 926.9 MB
jenkins latest 55720d63e328 5 weeks ago 711.9 MB
hello-world latest c54a2cc56cbb 5 months ago 1.848 kB
```
#### Rebuilt image
-The Docker image for AGL Worker can be rebuilt using the scripts published here [agl-docker-worker](https://github.com/iotbzh/agl-docker-worker).
+The Docker image for AGL Worker can be rebuilt using the scripts published here [docker-worker-generator](https://git.automotivelinux.org/AGL/docker-worker-generator/).
### Start image
Then, use the 'create_container' script to start a new, fresh container based on the AGL Worker image:
@@ -56,12 +56,12 @@ Then, use the 'create_container' script to start a new, fresh container based on
* The password for the id 'devel' inside the docker image is 'devel'.
```bash
-git clone https://github.com/iotbzh/agl-docker-worker;
-cd agl-docker-worker;
-./create_container 0;
+git clone https://git.automotivelinux.org/AGL/docker-worker-generator;
+cd docker-worker-generator;
+./contrib/create_container 0;
docker ps;
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
- 4fb7c550ad75 docker.automotivelinux.org/agl/worker:2.1 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx
+ 4fb7c550ad75 docker.automotivelinux.org/agl/worker:3.0 "/usr/bin/wait_for_ne" 33 hours ago Up 33 hours 0.0.0.0:2222->22/tcp, 0.0.0.0:69->69/udp, 0.0.0.0:8000->8000/tcp, 0.0.0.0:10809->10809/tcp agl-worker-odin-0-sdx
```
@@ -91,7 +91,13 @@ install_sdk ~/share/poky-agl-glibc-x86_64-agl-demo-platform-crosssdk-cortexa15hf
## Step 5: build your application
-You're ready to go: get the sources, run the builds ...
+First, you must source the SDK environment you wish to use (you MUST repeat this step each time you open a new shell):
+
+```bash
+source /xdt/sdk/environment-setup-<your_target>
+```
+
+You're then ready to go: get the sources, run the builds ...
```bash
git clone <your repo for your app>;
diff --git a/getting-started/source-code.md b/getting-started/source-code.md
index 730b242..9b60b82 100644
--- a/getting-started/source-code.md
+++ b/getting-started/source-code.md
@@ -1,7 +1,9 @@
# Introduction: Building target AGL image with Yocto project
+
The standard Yocto process is made of the following steps:
+
* Setting up your operating system.
* Setting up the build environment for R-Car BSP.
* Downloading the proprietary drivers and installing them in the build environment (if needed).
@@ -20,6 +22,7 @@ If you want to bypass the build phase and quick boot the board, you can download
The very first step is to ensure that your system can run the build system of the Yocto Project.
**Important**: it only runs on Linux
+
* if your system is Windows© or iOS© you should use a virtualization solution (Virtualbox, VMWare ...) to run a Linux VM on your system.
For AGL 2.1, Yocto Project 2.1, known as krogoth, has been selected for the BSP and build system.
@@ -29,6 +32,7 @@ Reference data for configuring your system can be found in the Yocto documentati
Here after an extract of this documentation for most common Linux distributions:
+
* The build system should be able to run on any modern distributions that has the following versions for:
* Python
* Git 1.7.8 or greater
@@ -109,20 +113,20 @@ chmod a+x ~/bin/repo
You can choose your source release
### Download Latest Stable Release
-To download all layers for the for the latest stable release, Blowfish 2.0.3:
+To download all layers for the for the latest stable release, Chinook 3.0.1:
```
cd $AGL_TOP
-repo init -b blowfish -m default_blowfish_2.0.3.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+repo init -b chinook -m chinook_3.0.1.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
repo sync
```
-### Download Latest on Blowfish Branch
+### Download Latest on Chinook Branch
To download all layers on the current release branch which may be in the midst of testing or changes prior to the next stable release:
```
cd $AGL_TOP
-repo init -b blowfish -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+repo init -b chinook -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
repo sync
```
@@ -144,7 +148,7 @@ cd $AGL_TOP
source meta-agl/scripts/aglsetup.sh -h
```
-Once you run aglsetup.sh with your desired paramaters, you can build any target desired.
+Once you run aglsetup.sh with your desired parameters, you can build any target desired.
## Features supported by aglsetup
diff --git a/getting-started/troubleshooting.md b/getting-started/troubleshooting.md
index 96bdda5..183d0c9 100644
--- a/getting-started/troubleshooting.md
+++ b/getting-started/troubleshooting.md
@@ -2,7 +2,7 @@
## Extended attributes MUST be copied
-***IMPORTANT, The extended attribute set during image construction MUST be copied to the SD card.***
+**IMPORTANT, The extended attribute set during image construction MUST be copied to the SD card.**
When using tar to create the SDcard, it is a common error to not copy the extended attributes. Find below instruction for using tar.
@@ -40,3 +40,52 @@ CXXFLAGS_append = " -D_GLIBCXX_USE_CXX11_ABI=0"
BUILD_CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0"
TARGET_CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0" CXXFLAGS_remove_pn-gcc-runtime = "-D_GLIBCXX_USE_CXX11_ABI=0"
```
+## Screen orientation for Splash and in Weston
+Depending of your scren mounting the default orientation of the UI an/or splash screen might be incorrect.
+To change the orientation of the splash screen patch
+```
+File: /etc/systemd/system/sysinit.target.wants/psplash-start.service
+Line: ExecStart=/usr/bin/psplash -n -a 90
+```
+To change the orientation of the UI in Weston patch
+```
+File: /etc/xdg/weston/weston.ini
+Line: transform=90
+```
+
+## Disabling Homescreen in AGL 3.0.x CC release
+
+**Problem**: new installed applications are not available on Homescreen and even if started manually through afm-util, the application starts but no surface appears.
+
+**Answer**: this is due to IVI-Shell integration with Qt and Homescreen.
+
+To disable IVI-Shell and revert to the "plain old" weston desktop, you can follow the 4 steps below:
+
+* Modify */etc/xdg/weston/weston.ini* and comment the line mentioning IVI-shell. For example on Porter board:
+
+```
+ [core]
+ backend=drm-backend.so
+ #shell=ivi-shell.so
+ ...
+```
+
+* modify */usr/lib/systemd/user/afm-user-daemon.service* and comment the line specifying QT Wayland backend:
+
+```
+ ...
+ #Environment=QT_WAYLAND_SHELL_INTEGRATION=ivi-shell
+ ...
+```
+
+* disable Homescreen services:
+
+```
+ # systemctl disable HomeScreenAppFrameworkBinderAGL.service
+ # systemctl disable HomeScreen.service
+ # systemctl disable InputEventManager.service
+ # systemctl disable WindowManager.service
+```
+
+* Reboot your target and you should then be able to start apps on the standard weston screen using afm-util
+
diff --git a/platform/working-on-the-chinook-branch.md b/platform/working-on-the-chinook-branch.md
new file mode 100644
index 0000000..1f8eef8
--- /dev/null
+++ b/platform/working-on-the-chinook-branch.md
@@ -0,0 +1,103 @@
+# Working on the chinook branch
+## Intro
+This is a quick howto for working on the 'Charming Chinook' branch. Working on the branch
+is easy as we maintain all changes through gerrit.automotivelinux.org.
+If you are unfamiliar with gerrit, please read these fine how-to pages were put together from the
+Mediawiki community here: https://www.mediawiki.org/wiki/Gerrit/Tutorial . This covers the basics very well. Of course we'll work with gerrit.automotivelinux.org instead so apply likewise.
+
+## Installation of tools
+Install `git` with your distributions package manager.
+A very useful tool is "git-review" (cmdline is then `git review`).
+Install it from your distro or with `sudo pip install git-review`.
+
+## Prerequisites
+It is important to setup git and gerrit properly (see the Tutorial page mentioned above):
+
+* prereq #1) make sure git is properly setup with name/email
+* prereq #2) make sure your ssh key is in gerrit.automotivelinux.org
+
+## Cloning, editing and submitting for review
+
+Follow these steps to submit a change to the 'Charming Chinook' branch:
+
+1) cloning the (tip of the) branch
+ ```
+ repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+ repo sync
+ ```
+
+2) Change the recipe in question (one change at a time - small is better)
+ ```
+ vi recipe-foo/bar/baz.bb
+ ```
+
+3) Do a a few builds and tests (try 2 architectures if possible)
+ ```
+ source meta-agl/scripts/aglsetup.sh .... agl-all-features
+ bitbake agl-demo-platform
+ ```
+
+4) once satisfied do commit your change as usual in git
+ Make sure to do a proper commit message:
+ http://chris.beams.io/posts/git-commit/
+ ```
+ git commit -s
+ <enter proper commit message>
+ ```
+
+5) All repos have .gitreview files already, so now it is just
+ ```
+ git review
+ ```
+
+6) (optional, but highly recommended!) Reset to gerrit/chinook
+ ```
+ git checkout chinook`
+ git reset --hard gerrit/chinook
+ ```
+
+ It helps during the review process as gerrit would otherwise enforce
+ the whole series of patches to be reviewed/merged together (2nd depends on 1st patch).
+
+7) Rinse (=6) and repeat (=2-5)
+
+## Using git review to review/test-build a specific change in gerrit
+'git review' is also useful if you want to review a change.
+Example for meta-agl:
+```
+ repo init -b chinook -m default.xml -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+ repo sync
+ cd meta-agl/
+ git review -d 8105
+```
+This will pull-down change 8105. Now we can build with it applied:
+```
+ cd ..
+ source ...
+ bitbake ...
+````
+
+## Using gerrit to amend a changeset while in review
+The same workflow applies if you want to _amend_ a changeset while it is in review (not merged, yet):
+```
+cd meta-agl/
+git review -d 8105
+```
+This will pull-down change 8105. You can now edit a file:
+```
+vi recipes-foo/bar/baz.bb
+git commit -s --amend
+```
+
+ Don't forget a test build
+```
+cd ..
+source meta-agl/scripts/aglsetup.sh ..... agl-all-features
+bitbake ... # e.g. agl-demo-platform
+```
+
+ Finally call git review to upload the change
+```
+git review
+```
+
diff --git a/platform/working-on-the-master-branch.md b/platform/working-on-the-master-branch.md
new file mode 100644
index 0000000..0f91eaf
--- /dev/null
+++ b/platform/working-on-the-master-branch.md
@@ -0,0 +1,103 @@
+# Working on the master branch
+## Intro
+This is a quick howto for working on the 'master' branch. Working on the branch
+is easy as we maintain all changes through gerrit.automotivelinux.org.
+If you are unfamiliar with gerrit, please read these fine how-to pages were put together from the
+Mediawiki community here: https://www.mediawiki.org/wiki/Gerrit/Tutorial . This covers the basics very well. Of course we'll work with gerrit.automotivelinux.org instead so apply likewise.
+
+## Installation of tools
+Install `git` with your distributions package manager.
+A very useful tool is "git-review" (cmdline is then `git review`).
+Install it from your distro or with `sudo pip install git-review`.
+
+## Prerequisites
+It is important to setup git and gerrit properly (see the Tutorial page mentioned above):
+
+* prereq #1) make sure git is properly setup with name/email
+* prereq #2) make sure your ssh key is in gerrit.automotivelinux.org
+
+## Cloning, editing and submitting for review
+
+Follow these steps to submit a change to the 'master' branch:
+
+1) cloning the (tip of the) branch
+ ```
+ repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+ repo sync
+ ```
+
+2) Change the recipe in question (one change at a time - small is better)
+ ```
+ vi meta-xyz/recipe-foo/bar/baz.bb
+ ```
+
+3) Do a a few builds and tests (try 2 architectures if possible)
+ ```
+ source meta-agl/scripts/aglsetup.sh .... agl-all-features
+ bitbake agl-demo-platform
+ ```
+
+4) once satisfied do commit your change as usual in git
+ Make sure to do a proper commit message:
+ http://chris.beams.io/posts/git-commit/
+ ```
+ git commit -s
+ <enter proper commit message>
+ ```
+
+5) All repos have .gitreview files already, so now it is just
+ ```
+ git review
+ ```
+
+6) (optional, but highly recommended!) Reset to gerrit/master
+ ```
+ git checkout master
+ git reset --hard gerrit/master
+ ```
+
+ It helps during the review process as gerrit would otherwise enforce
+ the whole series of patches to be reviewed/merged together (2nd depends on 1st patch).
+
+7) Rinse (=6) and repeat (=2-5)
+
+## Using git review to review/test-build a specific change in gerrit
+'git review' is also useful if you want to review a change.
+Example for meta-agl:
+```
+ repo init -u https://gerrit.automotivelinux.org/gerrit/AGL/AGL-repo
+ repo sync
+ cd meta-agl/
+ git review -d 8233
+```
+This will pull-down change 8233. Now we can build with it applied:
+```
+ cd ..
+ source ...
+ bitbake ...
+````
+
+## Using gerrit to amend a changeset while in review
+The same workflow applies if you want to _amend_ a changeset while it is in review (not merged, yet):
+```
+cd meta-agl/
+git review -d 8233
+```
+This will pull-down change 8233. You can now edit a file:
+```
+vi meta-xyz/recipes-foo/bar/baz.bb
+git commit -s --amend
+```
+
+ Don't forget a test build
+```
+cd ..
+source meta-agl/scripts/aglsetup.sh ..... agl-all-features
+bitbake ... # e.g. agl-demo-platform
+```
+
+ Finally call git review to upload the change
+```
+git review
+```
+
diff --git a/sec-blueprint/04-adversaries.md b/sec-blueprint/04-adversaries.md
index acf3764..8740ae5 100644
--- a/sec-blueprint/04-adversaries.md
+++ b/sec-blueprint/04-adversaries.md
@@ -1,25 +1,44 @@
----
-
-title : Adversaries
-date : 2016-06-30
-categories: architecture, automotive
-tags: architecture, automotive, linux
-layout: techdoc
+This section lists some of the adversaries and attackers in Automotive.
+## Enthusiast Attackers:
+ Enthusiast attackers have physical access to the Engine Control
+ Units (ECUs) at the circuit board level. They can solder ‘mod chips’
+ onto the board and have access to probing tools. They also have
+ information on ECUs that have been hacked previously and have
+ access to softwares and instructions developed by other members
+ of car modification forums. The goal of the enthusiast hacker
+ could be, but is not limited to, adding extra horse power to the
+ car or hacking it just for fun.
----
-
-**Table of Content**
-
-1. TOC
-{:toc}
-
-## Authorised malicious project admin/developer
-
-## Malware developer
-
-## Organised crime
-
-## Authorised device/cloud user
-
-## Network mass attacker
+## Corrupt Dealers:
+ These are attackers that have access to the same capabilities as
+ enthusiasts, but also have access to the car manufacturer's (OEM)
+ dealer network. They may also have access to standard debugging
+ tools provided by the car manufacturer. Their goal may be to support
+ local car theft gangs or organized criminals.
+
+## Organized Criminal:
+ Organized Criminals have access to all of the above tools but may
+ also have some level of control over the internal network at
+ many dealerships. They may have hacked and gained temporary
+ control of the Over-The-Air (OTA) servers or the In-Vehicle
+ Infotainment (IVI) systems. This is very much like the role of
+ organized criminals in other industries such as paid media today.
+ Their goal is to extort money from an OEMs and/or governments by
+ threatening to disable multiple vehicles.
+
+## Malware Developers:
+ Malware Developers have developed malicious software to attach
+ and compromise a large number of vehicle. The malicious software
+ would usually be designed spread from one vehicle to another.
+ The goal usually is to take control of multiple machines then sell
+ access to them for malicious purposes like denial-of-service (DoS)
+ attacks or stealing private information and data.
+
+## Security Researchers:
+ These attackers are ‘self-publicized’ security consultants trying
+ to make a name for themselves. They have access standard tools for
+ software security analysis. They also have physical access to the
+ vehicle and standard hardware debugging tools (Logic Analyzers,
+ Oscilloscopes, etc). Their goal is to publicize attacks for personal
+ gains.