[Buildroot] [PATCH v1 0/9] board: introduce common infrastructure for Intel SoCs

[Buildroot] [PATCH v1 0/9] board: introduce common infrastructure for Intel SoCs

[Andy Shevchenko]

Buildroot often is used for embedded world where Intel, for example, is
presented by a number of boards, such as Intel Galileo, Edison, and Joule.

This series introduces a common infrastructure to build images for such boards.
Besides that it has a brand new set of the ACPI ASL examples to support devices
that can be used with open connected boards.

The series has been tested on Intel Joule, Minnowboard, Minnowboard MAX, and
partially on many other boards and devices.

Andy Shevchenko (3):
  package/acpica: Add host configuration to the tool
  board/intel/common: Add common files for x86 boards
  board/intel/common: Add possibility for adding ACPI tables to the
    initrd

Mika Westerberg (6):
  board / intel: Add SPI peripherals for Minnowboard MAX
  board / intel: Add SPI peripherals for Joule
  board / intel: Add Aosong AM2315 sensor for Intel Joule
  board / intel: Add GPIO LEDs for Intel Joule
  board / intel: Add GPIO LEDs for Intel Minnowboard
  board / intel: Add GPIO buttons for Intel Minnowboard

 board/intel/common/README.rst                      | 113 +++++++++++++++++++++
 board/intel/common/cmdline                         |   1 +
 board/intel/common/libshell-intel                  |  26 +++++
 board/intel/common/post-build.d/10-install-modules |  23 +++++
 board/intel/common/post-build.d/README             |   4 +
 board/intel/common/post-build.sh                   |  16 +++
 board/intel/common/post-image.d/10-prepare-cmdline |  26 +++++
 .../common/post-image.d/30-append-custom-cmdline   |  17 ++++
 board/intel/common/post-image.d/40-prepare-initrd  |  14 +++
 board/intel/common/post-image.d/80-acpi-tables     |  86 ++++++++++++++++
 board/intel/common/post-image.d/README             |   4 +
 board/intel/common/post-image.sh                   |  16 +++
 board/intel/joule/acpi/am2315.asl                  |  36 +++++++
 board/intel/joule/acpi/at25.asl                    |  56 ++++++++++
 board/intel/joule/acpi/leds.asl                    | 107 +++++++++++++++++++
 board/intel/joule/acpi/spidev.asl                  |  42 ++++++++
 board/intel/minnowboard-max/acpi/at25.asl          |  58 +++++++++++
 board/intel/minnowboard-max/acpi/m25p80.asl        |  52 ++++++++++
 board/intel/minnowboard/acpi/buttons.asl           | 104 +++++++++++++++++++
 board/intel/minnowboard/acpi/leds.asl              |  82 +++++++++++++++
 configs/intel_defconfig                            |  30 ++++++
 package/Config.in.host                             |   1 +
 package/acpica/Config.in.host                      |   9 ++
 package/acpica/acpica.mk                           |  15 +++
 24 files changed, 938 insertions(+)
 create mode 100644 board/intel/common/README.rst
 create mode 100644 board/intel/common/cmdline
 create mode 100644 board/intel/common/libshell-intel
 create mode 100755 board/intel/common/post-build.d/10-install-modules
 create mode 100644 board/intel/common/post-build.d/README
 create mode 100755 board/intel/common/post-build.sh
 create mode 100755 board/intel/common/post-image.d/10-prepare-cmdline
 create mode 100755 board/intel/common/post-image.d/30-append-custom-cmdline
 create mode 100755 board/intel/common/post-image.d/40-prepare-initrd
 create mode 100755 board/intel/common/post-image.d/80-acpi-tables
 create mode 100644 board/intel/common/post-image.d/README
 create mode 100755 board/intel/common/post-image.sh
 create mode 100644 board/intel/joule/acpi/am2315.asl
 create mode 100644 board/intel/joule/acpi/at25.asl
 create mode 100644 board/intel/joule/acpi/leds.asl
 create mode 100644 board/intel/joule/acpi/spidev.asl
 create mode 100644 board/intel/minnowboard-max/acpi/at25.asl
 create mode 100644 board/intel/minnowboard-max/acpi/m25p80.asl
 create mode 100644 board/intel/minnowboard/acpi/buttons.asl
 create mode 100644 board/intel/minnowboard/acpi/leds.asl
 create mode 100644 configs/intel_defconfig
 create mode 100644 package/acpica/Config.in.host

-- 
2.8.1

[Buildroot] [PATCH v1 1/9] package/acpica: Add host configuration to the tool

[Andy Shevchenko]

The ACPI excerpts, which would be added to an initial RAM disk image, require
to be compiled first. iasl tool from acpica package helps do that.

Enable host variant of the application to be built.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 package/Config.in.host        |  1 +
 package/acpica/Config.in.host |  9 +++++++++
 package/acpica/acpica.mk      | 15 +++++++++++++++
 3 files changed, 25 insertions(+)
 create mode 100644 package/acpica/Config.in.host

diff --git a/package/Config.in.host b/package/Config.in.host
index 1c99e34..992e2bb 100644
--- a/package/Config.in.host
+++ b/package/Config.in.host
@@ -1,5 +1,6 @@
 menu "Host utilities"
 
+	source "package/acpica/Config.in.host"
 	source "package/aespipe/Config.in.host"
 	source "package/android-tools/Config.in.host"
 	source "package/cbootimage/Config.in.host"
diff --git a/package/acpica/Config.in.host b/package/acpica/Config.in.host
new file mode 100644
index 0000000..4e5751e
--- /dev/null
+++ b/package/acpica/Config.in.host
@@ -0,0 +1,9 @@
+config BR2_PACKAGE_HOST_ACPICA
+	bool "host acpica"
+	help
+	  The ACPI Component Architecture (ACPICA) project provides an
+	  operating system (OS)-independent reference implementation of
+	  the Advanced Configuration and Power Interface Specification
+	  (ACPI).
+
+	  https://www.acpica.org
diff --git a/package/acpica/acpica.mk b/package/acpica/acpica.mk
index b8459d8..40ec81b 100644
--- a/package/acpica/acpica.mk
+++ b/package/acpica/acpica.mk
@@ -23,4 +23,19 @@ define ACPICA_INSTALL_TARGET_CMDS
 		INSTALLFLAGS=-m755 install
 endef
 
+HOST_ACPICA_DEPENDENCIES = host-bison host-flex
+
+define HOST_ACPICA_BUILD_CMDS
+	$(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)				\
+		HARDWARE_NAME=$(BR2_ARCH) HOST=_LINUX CC="$(HOSTCC)"	\
+		all
+endef
+
+define HOST_ACPICA_INSTALL_CMDS
+	$(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)				\
+		HARDWARE_NAME=$(BR2_ARCH) DESTDIR="$(HOST_DIR)"		\
+		INSTALLFLAGS=-m755 install
+endef
+
 $(eval $(generic-package))
+$(eval $(host-generic-package))
-- 
2.8.1

[Buildroot] [PATCH v1 2/9] board/intel/common: Add common files for x86 boards

[Andy Shevchenko]

There are several x86 boards that can utilize same image creation
infrastructure.

Add common configuration, cmdline, post-image.sh, post-build.sh scripts and
placeholders for their extensions.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/common/README.rst                      | 96 ++++++++++++++++++++++
 board/intel/common/cmdline                         |  1 +
 board/intel/common/libshell-intel                  | 26 ++++++
 board/intel/common/post-build.d/10-install-modules | 23 ++++++
 board/intel/common/post-build.d/README             |  4 +
 board/intel/common/post-build.sh                   | 16 ++++
 board/intel/common/post-image.d/10-prepare-cmdline | 26 ++++++
 .../common/post-image.d/30-append-custom-cmdline   | 17 ++++
 board/intel/common/post-image.d/40-prepare-initrd  | 14 ++++
 board/intel/common/post-image.d/README             |  4 +
 board/intel/common/post-image.sh                   | 16 ++++
 configs/intel_defconfig                            | 27 ++++++
 12 files changed, 270 insertions(+)
 create mode 100644 board/intel/common/README.rst
 create mode 100644 board/intel/common/cmdline
 create mode 100644 board/intel/common/libshell-intel
 create mode 100755 board/intel/common/post-build.d/10-install-modules
 create mode 100644 board/intel/common/post-build.d/README
 create mode 100755 board/intel/common/post-build.sh
 create mode 100755 board/intel/common/post-image.d/10-prepare-cmdline
 create mode 100755 board/intel/common/post-image.d/30-append-custom-cmdline
 create mode 100755 board/intel/common/post-image.d/40-prepare-initrd
 create mode 100644 board/intel/common/post-image.d/README
 create mode 100755 board/intel/common/post-image.sh
 create mode 100644 configs/intel_defconfig

diff --git a/board/intel/common/README.rst b/board/intel/common/README.rst
new file mode 100644
index 0000000..e427067
--- /dev/null
+++ b/board/intel/common/README.rst
@@ -0,0 +1,96 @@
+===========
+ Intel IoT
+===========
+
+----------------------------------------
+ Common infrastructure for Intel boards
+----------------------------------------
+
+:Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+:Date: 2016-08-17
+
+Quick instructions
+------------------
+
+Building an image
+~~~~~~~~~~~~~~~~~
+
+For building a normal bootable image, you need to do following steps:
+
+1) Build your own kernel.
+
+2) Configure Buildroot.
+
+The Buildroot configuration would be done by running::
+
+	% make <BOARD>_defconfig
+
+For most of the boards it's good enough to use generic [intel_defconfig]_.
+
+3) Build Buildroot.
+
+Build the necessary Buildroot packages and resulting image::
+
+	% make KERNEL_SRC=~/linux
+
+where ``~/linux`` is whatever the path to the kernel output folder is.
+
+4) Get the resulting image.
+
+The resulting image is placed under output/images and is called either
+``rootfs.cpio.bz2`` or ``initrd``. ``initrd`` is the link to the last modified
+image since some scripts may alter it on post image stage.
+
+Supported environment variables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The scripts under ``board/intel/common`` accept several environment variables
+that can be used to alter the default behaviour. Typically you do something
+like::
+
+	% make KERNEL_SRC=~/linux
+
+in order to take advantage of these.
+
+BOARD_INTEL_CUSTOM_CMDLINE
+	provides a custom appendix to the command line.
+
+BOARD_INTEL_DIR
+	points to a specific board directory.
+
+KERNEL_SRC
+	path to your kernel output folder.
+
+Alterate console
+~~~~~~~~~~~~~~~~
+
+By default ``ttyS0`` is used as a default cosole for both kernel and userspace.
+The **BR2_TARGET_GENERIC_GETTY_PORT** variable could be used to alterate this
+setting.
+
+Supported boards
+~~~~~~~~~~~~~~~~
+
+.. [intel_defconfig] Generic config for most of Intel SoCs.
+
+Examples
+~~~~~~~~
+
+- ASuS T100TA and the rest with ``ttyUSB0``::
+
+	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyUSB0		\
+				  BOARD_INTEL_CUSTOM_CMDLINE="reboot=h,p"
+
+- Galileo (Quark)::
+
+	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS1
+
+- Joule (Broxton), Edison (Merrifield)::
+
+	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS2
+
+- Minnowboard [#]_::
+
+	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyPCH0
+
+.. [#] Minnowboard MAX goes the standard way with ``ttyS0``.
diff --git a/board/intel/common/cmdline b/board/intel/common/cmdline
new file mode 100644
index 0000000..54465ef
--- /dev/null
+++ b/board/intel/common/cmdline
@@ -0,0 +1 @@
+console=tty1 console=ttyS0,115200n8
diff --git a/board/intel/common/libshell-intel b/board/intel/common/libshell-intel
new file mode 100644
index 0000000..f834ecb
--- /dev/null
+++ b/board/intel/common/libshell-intel
@@ -0,0 +1,26 @@
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+#
+# Environment:
+#
+# BOARD_INTEL_DIR		- Directory holding board specific
+#				  configuration
+#
+
+# Use this folder to provide board specific files
+BOARD_DIR_DEFAULT="$(dirname $(dirname "$0"))"
+BOARD_DIR="$(readlink -mnq "${BOARD_INTEL_DIR:-$BOARD_DIR_DEFAULT}")"
+
+[ -d "$BOARD_DIR" ] || echo "Warning: $BOARD_INTEL_DIR does not exist"
+
+# Looking up for a custom file if provided, otherwise fallback to the original name
+intel_file_lookup() {
+	[ -f "$BOARD_DIR/$1" ] && echo "$BOARD_DIR/$1" || echo "$BOARD_DIR_DEFAULT/$1"
+}
+
+# Looking up for a custom folder if provided, otherwise fallback to the original name
+intel_folder_lookup() {
+	[ -d "$BOARD_DIR/$1" ] && echo "$BOARD_DIR/$1" || echo "$BOARD_DIR_DEFAULT/$1"
+}
diff --git a/board/intel/common/post-build.d/10-install-modules b/board/intel/common/post-build.d/10-install-modules
new file mode 100755
index 0000000..4f88d8f
--- /dev/null
+++ b/board/intel/common/post-build.d/10-install-modules
@@ -0,0 +1,23 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+#
+# Environment:
+#
+# BOARD_INTEL_LEAVE_MODULES	- If defined, the modules from previous kernel
+#				  will be left untouched. Otherwise cleans up
+#				  /lib/modules folder completely.
+#
+# KERNEL_SRC			- Directory holding output of Linux kernel
+#				  build. If defined, it will be used to install
+#				  kernel modules from.
+#
+
+# Leave old modules in the /lib/modules folder if asked
+[ -z "$BOARD_INTEL_LEAVE_MODULES" ] && rm -rf $TARGET_DIR/lib/modules/*
+
+# Install kernel modules
+[ -d "$KERNEL_SRC" ] && make -C "$KERNEL_SRC" INSTALL_MOD_PATH="$1" modules_install
diff --git a/board/intel/common/post-build.d/README b/board/intel/common/post-build.d/README
new file mode 100644
index 0000000..5bcb10b
--- /dev/null
+++ b/board/intel/common/post-build.d/README
@@ -0,0 +1,4 @@
+#
+# This folder contains the shell scripts which will be executed in alphabetical
+# order on post build stage.
+#
diff --git a/board/intel/common/post-build.sh b/board/intel/common/post-build.sh
new file mode 100755
index 0000000..28cf638
--- /dev/null
+++ b/board/intel/common/post-build.sh
@@ -0,0 +1,16 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+SCRIPT_LOCATION="$(dirname $0)"
+SCRIPT_DIR="$SCRIPT_LOCATION/post-build.d"
+
+find "$SCRIPT_DIR" -maxdepth 1 -type f -perm -u+x | sort -u | while read script; do
+	name=$(basename $script)
+
+	echo "Executing $name..."
+
+	$script "$@"
+done
diff --git a/board/intel/common/post-image.d/10-prepare-cmdline b/board/intel/common/post-image.d/10-prepare-cmdline
new file mode 100755
index 0000000..a222a1e
--- /dev/null
+++ b/board/intel/common/post-image.d/10-prepare-cmdline
@@ -0,0 +1,26 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+#
+# Environment:
+#
+# BR2_TARGET_GENERIC_GETTY_PORT		- set console port
+#
+
+PROG_NAME="${0##*/}"
+PROG_DIR="${0%/*}"
+
+. $PROG_DIR/../libshell-intel
+
+# Assign default console which should be the same as provided in cmdline
+console_default="ttyS0"
+console="${BR2_TARGET_GENERIC_GETTY_PORT:-$console_default}"
+
+# Get initial cmdline
+cmdline="$(intel_file_lookup "cmdline")"
+
+# Read cmdline and modify console parameter
+sed -e "s#$console_default#$console#" "$cmdline" > "$BINARIES_DIR/cmdline"
diff --git a/board/intel/common/post-image.d/30-append-custom-cmdline b/board/intel/common/post-image.d/30-append-custom-cmdline
new file mode 100755
index 0000000..cbc07da
--- /dev/null
+++ b/board/intel/common/post-image.d/30-append-custom-cmdline
@@ -0,0 +1,17 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+#
+# Environment:
+#
+# BOARD_INTEL_CUSTOM_CMDLINE	- Provides an addition to the default kernel
+#				  command line
+#
+
+[ -n "$BOARD_INTEL_CUSTOM_CMDLINE" ] || exit 0
+
+# Append custom part of cmdline
+echo "$(cat "$BINARIES_DIR/cmdline") $BOARD_INTEL_CUSTOM_CMDLINE" > "$BINARIES_DIR/cmdline"
diff --git a/board/intel/common/post-image.d/40-prepare-initrd b/board/intel/common/post-image.d/40-prepare-initrd
new file mode 100755
index 0000000..7bf7769
--- /dev/null
+++ b/board/intel/common/post-image.d/40-prepare-initrd
@@ -0,0 +1,14 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+#
+# Environment:
+#
+# None
+#
+
+# Link to the initial ramfs image as stated in intel_defconfig
+ln -sf "rootfs.cpio.bz2" "$BINARIES_DIR/initrd"
diff --git a/board/intel/common/post-image.d/README b/board/intel/common/post-image.d/README
new file mode 100644
index 0000000..d214a4e
--- /dev/null
+++ b/board/intel/common/post-image.d/README
@@ -0,0 +1,4 @@
+#
+# This folder contains the shell scripts which will be executed in alphabetical
+# order on post image stage.
+#
diff --git a/board/intel/common/post-image.sh b/board/intel/common/post-image.sh
new file mode 100755
index 0000000..4166845
--- /dev/null
+++ b/board/intel/common/post-image.sh
@@ -0,0 +1,16 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+SCRIPT_LOCATION="$(dirname $0)"
+SCRIPT_DIR="$SCRIPT_LOCATION/post-image.d"
+
+find "$SCRIPT_DIR" -maxdepth 1 -type f -perm -u+x | sort -u | while read script; do
+	name=$(basename $script)
+
+	echo "Executing $name..."
+
+	$script "$@"
+done
diff --git a/configs/intel_defconfig b/configs/intel_defconfig
new file mode 100644
index 0000000..8aff9e1
--- /dev/null
+++ b/configs/intel_defconfig
@@ -0,0 +1,27 @@
+# Architecture
+BR2_i386=y
+BR2_x86_i586=y
+
+# Misc
+BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_MDEV=y
+BR2_TARGET_GENERIC_GETTY_PORT="ttyS0"
+BR2_TARGET_GENERIC_GETTY_BAUDRATE_115200=y
+
+# Root FS
+# BR2_TARGET_ROOTFS_TAR is not set
+BR2_TARGET_ROOTFS_CPIO=y
+BR2_TARGET_ROOTFS_CPIO_BZIP2=y
+
+# Root FS hooks
+BR2_ROOTFS_POST_BUILD_SCRIPT="board/intel/common/post-build.sh"
+BR2_ROOTFS_POST_IMAGE_SCRIPT="board/intel/common/post-image.sh"
+BR2_ROOTFS_POST_SCRIPT_ARGS=""
+
+# Busybox utilities (target)
+BR2_PACKAGE_BUSYBOX_WATCHDOG=y
+
+# Packages
+BR2_PACKAGE_KEXEC=y
+BR2_PACKAGE_KEXEC_ZLIB=y
+BR2_PACKAGE_LRZSZ=y
+BR2_PACKAGE_SCREEN=y
-- 
2.8.1

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Andy Shevchenko]

Add script which takes ASL files as input, compiles them to AML bytecode,
and prepends the whole thing to the initrd archive. They are placed in
kernel/firmware/acpi directory where the kernel is able to find and use
them.

The script requires iasl host tool that would be provided by acpica package.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/common/README.rst                  | 19 +++++-
 board/intel/common/post-image.d/80-acpi-tables | 86 ++++++++++++++++++++++++++
 configs/intel_defconfig                        |  3 +
 3 files changed, 107 insertions(+), 1 deletion(-)
 create mode 100755 board/intel/common/post-image.d/80-acpi-tables

diff --git a/board/intel/common/README.rst b/board/intel/common/README.rst
index e427067..f7f677e 100644
--- a/board/intel/common/README.rst
+++ b/board/intel/common/README.rst
@@ -52,6 +52,9 @@ like::
 
 in order to take advantage of these.
 
+BOARD_INTEL_ACPI_TABLES
+	list of table names to built into the ``initrd``.
+
 BOARD_INTEL_CUSTOM_CMDLINE
 	provides a custom appendix to the command line.
 
@@ -68,6 +71,20 @@ By default ``ttyS0`` is used as a default cosole for both kernel and userspace.
 The **BR2_TARGET_GENERIC_GETTY_PORT** variable could be used to alterate this
 setting.
 
+Adding custom ACPI SSDT tables
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can add additional ACPI tables to the ``initrd`` (think of device tree
+overlays) if you need to have some special devices for example. The ASL files
+should be stored in board specific directories as they vary from one board to
+another. Below we add SPI test device for Intel `Joule`_ board::
+
+	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS2		\
+				  BOARD_INTEL_DIR=board/intel/joule		\
+				  BOARD_INTEL_ACPI_TABLES=spidev.asl
+
+The resulting image is called ``output/images/joule-acpi-rootfs.cpio``.
+
 Supported boards
 ~~~~~~~~~~~~~~~~
 
@@ -85,7 +102,7 @@ Examples
 
 	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS1
 
-- Joule (Broxton), Edison (Merrifield)::
+- _`Joule` (Broxton), Edison (Merrifield)::
 
 	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS2
 
diff --git a/board/intel/common/post-image.d/80-acpi-tables b/board/intel/common/post-image.d/80-acpi-tables
new file mode 100755
index 0000000..c9495d8
--- /dev/null
+++ b/board/intel/common/post-image.d/80-acpi-tables
@@ -0,0 +1,86 @@
+#!/bin/sh -e
+
+#
+# Copyright (c) 2016 Intel Corp.
+#
+
+#
+# Environment:
+#
+# BOARD_INTEL_ACPI_TABLES	- ASL files to build separated by spaces
+#
+# BOARD_INTEL_DIR		- Directory holding board specific
+# 				  configuration. Should contain directory
+# 				  called "acpi" which holds the ASL tables.
+#
+# For example following variables compile two ACPI SSDTs into updated
+# initrd image called $BINARIES_DIR/joule-acpi-rootfs.cpio.
+#
+# BOARD_INTEL_DIR="board/intel/joule"
+# BOARD_INTEL_ACPI_TABLES="at25.asl spidev.asl"
+#
+
+PROG_NAME="${0##*/}"
+PROG_DIR="${0%/*}"
+
+. $PROG_DIR/../libshell-intel
+
+ACPI_DIR="$(intel_folder_lookup "acpi")"
+ACPI_TABLES="$BOARD_INTEL_ACPI_TABLES"
+
+[ -d "$ACPI_DIR" ] || exit 0
+[ -z "$ACPI_TABLES" ] && exit 0
+
+# Pick iASL.
+# First try from buildroot and if not there then try from the host.
+[ -x "$HOST_DIR/usr/bin/iasl" ] && iasl="$HOST_DIR/usr/bin/iasl" || iasl=$(which iasl)
+
+[ -x "$iasl" ] || {
+	echo "You need to to have iASL compiler available. You can either enable"
+	echo "BR2_PACKAGE_HOST_ACPICA or install it locally for your host."
+	echo "Typically the package is called acpica-tools in major distros".
+	exit 1
+}
+
+# The name of the folder is the name of a board
+board_name="${BOARD_DIR##*/}"
+[ "$board_name" = "common" ] && {
+	echo "Adding ACPI tables is always specific to a board!"
+	echo "You are not supposed to use common as board here!"
+	exit 1
+}
+
+# Always prefix with the board name to avoid mistakes if the initrd is used
+# with another board.
+updated_initrd_name="${board_name}-acpi-rootfs.cpio"
+updated_initrd="$BINARIES_DIR/$updated_initrd_name"
+initrd="$(readlink -enq "$BINARIES_DIR/initrd")"
+tmpamldir="$BINARIES_DIR/acpi-tables"
+
+# Make sure existing tables get cleared
+rm -fr $tmpamldir
+mkdir -p $tmpamldir/kernel/firmware/acpi
+
+for table in $ACPI_TABLES; do
+	[ -f "$ACPI_DIR/$table" ] || continue
+
+	$iasl -p $tmpamldir/kernel/firmware/acpi/$table "$ACPI_DIR/$table" > /dev/null 2>&1
+
+	echo "ACPI: Compiled ASL from $(realpath --relative-to=$PWD $ACPI_DIR/$table)"
+done
+
+# Exit if no tables were compiled
+[ -n "$(find $tmpamldir -type f)" ] || {
+	echo "ACPI: No tables were compiled"
+	exit 0
+}
+
+# Attach compiled tables to initrd
+(
+	cd $tmpamldir
+	find kernel | cpio -H newc -o > $updated_initrd 2>/dev/null
+	cat $initrd >> $updated_initrd
+	ln -sf "$updated_initrd_name" "$BINARIES_DIR/initrd"
+)
+
+echo "ACPI: Created initrd with updated ACPI tables in $(realpath --relative-to=$PWD $updated_initrd)"
diff --git a/configs/intel_defconfig b/configs/intel_defconfig
index 8aff9e1..24167fc 100644
--- a/configs/intel_defconfig
+++ b/configs/intel_defconfig
@@ -17,6 +17,9 @@ BR2_ROOTFS_POST_BUILD_SCRIPT="board/intel/common/post-build.sh"
 BR2_ROOTFS_POST_IMAGE_SCRIPT="board/intel/common/post-image.sh"
 BR2_ROOTFS_POST_SCRIPT_ARGS=""
 
+# Host tools
+BR2_PACKAGE_HOST_ACPICA=y
+
 # Busybox utilities (target)
 BR2_PACKAGE_BUSYBOX_WATCHDOG=y
 
-- 
2.8.1

[Buildroot] [PATCH v1 4/9] board / intel: Add SPI peripherals for Minnowboard MAX

[Andy Shevchenko]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

Add two SPI peripherals which can be connected to Minnowboard MAX low speed
connector. First is Atmel AT25 compatible SPI EEPROM and second is M25P80
compatible SPI serial flash.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/minnowboard-max/acpi/at25.asl   | 58 +++++++++++++++++++++++++++++
 board/intel/minnowboard-max/acpi/m25p80.asl | 52 ++++++++++++++++++++++++++
 2 files changed, 110 insertions(+)
 create mode 100644 board/intel/minnowboard-max/acpi/at25.asl
 create mode 100644 board/intel/minnowboard-max/acpi/m25p80.asl

diff --git a/board/intel/minnowboard-max/acpi/at25.asl b/board/intel/minnowboard-max/acpi/at25.asl
new file mode 100644
index 0000000..fdc169a
--- /dev/null
+++ b/board/intel/minnowboard-max/acpi/at25.asl
@@ -0,0 +1,58 @@
+/*
+ * Minnowboard MAX
+ *
+ * http://wiki.minnowboard.org/MinnowBoard_MAX
+ *
+ * This adds Atmel AT25 compatible 1kb serial EEPROM to the SPI host
+ * controller available on Minnowboard MAX low speed connector (JP1) pins:
+ *
+ *   pin name		pin number
+ *   -----------------------------
+ *   GPIO_SPI_CS	5
+ *   GPIO_SPI_MISO	7
+ *   GPIO_SPI_MOSI	9
+ *   GPIO_SPI_CLK	11
+ *
+ * In Linux you need to set CONFIG_EEPROM_AT25=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("at25.aml", "SSDT", 5, "INTEL", "AT25", 1)
+{
+    External (_SB_.SPI1, DeviceObj)
+
+    Scope (\_SB.SPI1)
+    {
+        Device (EEP0) {
+            Name (_HID, "PRP0001")
+            Name (_DDN, "Atmel AT25 compatible EEPROM")
+            Name (_CRS, ResourceTemplate () {
+                SpiSerialBus (
+                    1,                      // Chip select
+                    PolarityLow,            // Chip select is active low
+                    FourWireMode,           // Full duplex
+                    8,                      // Bits per word is 8 (byte)
+                    ControllerInitiated,    // Don't care
+                    1000000,                // 1 MHz
+                    ClockPolarityLow,       // SPI mode 0
+                    ClockPhaseFirst,        // SPI mode 0
+                    "\\_SB.SPI1",           // SPI host controller
+                    0                       // Must be 0
+                )
+            })
+
+            /*
+	     * See Documentation/devicetree/bindings/eeprom/at25.txt for
+	     * more information about these bindings.
+             */
+            Name (_DSD, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"compatible", "atmel,at25"},
+                    Package () {"size", 1024},
+                    Package () {"pagesize", 32},
+                    Package () {"address-width", 16},
+                }
+            })
+        }
+    }
+}
diff --git a/board/intel/minnowboard-max/acpi/m25p80.asl b/board/intel/minnowboard-max/acpi/m25p80.asl
new file mode 100644
index 0000000..d0676c6
--- /dev/null
+++ b/board/intel/minnowboard-max/acpi/m25p80.asl
@@ -0,0 +1,52 @@
+/*
+ * Minnowboard MAX
+ *
+ * http://wiki.minnowboard.org/MinnowBoard_MAX
+ *
+ * This adds M25P80 (AT26DF, M25P, W25X) compatible serial flash to the SPI
+ * host controller available on Minnowboard MAX low speed connector (JP1)
+ * pins:
+ *
+ *   pin name		pin number
+ *   -----------------------------
+ *   GPIO_SPI_CS	5
+ *   GPIO_SPI_MISO	7
+ *   GPIO_SPI_MOSI	9
+ *   GPIO_SPI_CLK	11
+ *
+ * In Linux you need to set CONFIG_MTD_M25P80=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("m25p80.aml", "SSDT", 5, "INTEL", "M25P80", 1)
+{
+    External (_SB_.SPI1, DeviceObj)
+
+    Scope (\_SB.SPI1)
+    {
+        Device (FLS0) {
+            Name (_HID, "PRP0001")
+            Name (_DDN, "M25P80 compatible serial flash")
+            Name (_CRS, ResourceTemplate () {
+                SpiSerialBus (
+                    1,                      // Chip select
+                    PolarityLow,            // Chip select is active low
+                    FourWireMode,           // Full duplex
+                    8,                      // Bits per word is 8 (byte)
+                    ControllerInitiated,    // Don't care
+                    10000000,               // 10 MHz
+                    ClockPolarityLow,       // SPI mode 0
+                    ClockPhaseFirst,        // SPI mode 0
+                    "\\_SB.SPI1",           // SPI host controller
+                    0                       // Must be 0
+                )
+            })
+
+            Name (_DSD, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"compatible", "jedec,spi-nor"},
+                }
+            })
+        }
+    }
+}
-- 
2.8.1

[Buildroot] [PATCH v1 5/9] board / intel: Add SPI peripherals for Joule

[Andy Shevchenko]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

Add two SPI peripherals which can be connected to Intel Joule breakout
board connectors. First is Atmel AT25 compatible SPI EEPROM and second is
spidev that userspace can use to perform raw I/O access to the SPI bus.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/joule/acpi/at25.asl   | 56 +++++++++++++++++++++++++++++++++++++++
 board/intel/joule/acpi/spidev.asl | 42 +++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 board/intel/joule/acpi/at25.asl
 create mode 100644 board/intel/joule/acpi/spidev.asl

diff --git a/board/intel/joule/acpi/at25.asl b/board/intel/joule/acpi/at25.asl
new file mode 100644
index 0000000..018542e
--- /dev/null
+++ b/board/intel/joule/acpi/at25.asl
@@ -0,0 +1,56 @@
+/*
+ * Intel Joule
+ *
+ * This adds Atmel AT25 compatible serial EEPROM to the SPI host controller
+ * available on Intel Joule breakout #1 header:
+ *
+ *   pin name		pin number
+ *   -----------------------------
+ *   SPI_1_MISO_LS	2
+ *   SPI_1_MOSI_LS	4
+ *   SPI_1_FS0_LS	6
+ *   SPI_1_CLK_LS	10
+ *
+ * In Linux you need to set CONFIG_EEPROM_AT25=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("at25.aml", "SSDT", 5, "INTEL", "AT25", 1)
+{
+    External (_SB_.PCI0.SPI2, DeviceObj)
+
+    Scope (\_SB.PCI0.SPI2)
+    {
+        Device (EEP0) {
+            Name (_HID, "PRP0001")
+            Name (_DDN, "Atmel AT25 compatible EEPROM")
+            Name (_CRS, ResourceTemplate () {
+                SpiSerialBus (
+                    0,                      // Chip select
+                    PolarityLow,            // Chip select is active low
+                    FourWireMode,           // Full duplex
+                    8,                      // Bits per word is 8 (byte)
+                    ControllerInitiated,    // Don't care
+                    1000000,                // 1 MHz
+                    ClockPolarityLow,       // SPI mode 0
+                    ClockPhaseFirst,        // SPI mode 0
+                    "\\_SB.PCI0.SPI2",      // SPI host controller
+                    0                       // Must be 0
+                )
+            })
+
+            /*
+             * See Documentation/devicetree/bindings/eeprom/at25.txt for
+             * more information about these bindings.
+             */
+            Name (_DSD, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"compatible", Package () {"atmel,at25"}},
+                    Package () {"size", 1024},
+                    Package () {"pagesize", 32},
+                    Package () {"address-width", 16},
+                }
+            })
+        }
+    }
+}
diff --git a/board/intel/joule/acpi/spidev.asl b/board/intel/joule/acpi/spidev.asl
new file mode 100644
index 0000000..17acca6
--- /dev/null
+++ b/board/intel/joule/acpi/spidev.asl
@@ -0,0 +1,42 @@
+/*
+ * Intel Joule
+ *
+ * This adds an SPI test device to the SPI host controller available on
+ * Intel Joule breakout #1 header:
+ *
+ *   pin name		pin number
+ *   -----------------------------
+ *   SPI_1_MISO_LS	2
+ *   SPI_1_MOSI_LS	4
+ *   SPI_1_FS2_LS	8
+ *   SPI_1_CLK_LS	10
+ *
+ * In Linux you need to set CONFIG_SPI_SPIDEV=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("spidev.aml", "SSDT", 5, "INTEL", "SPIDEV", 1)
+{
+    External (_SB_.PCI0.SPI2, DeviceObj)
+
+    Scope (\_SB.PCI0.SPI2)
+    {
+        Device (TP0) {
+            Name (_HID, "SPT0001")
+            Name (_DDN, "SPI test device connected to CS2")
+            Name (_CRS, ResourceTemplate () {
+                SpiSerialBus (
+                    2,                      // Chip select
+                    PolarityLow,            // Chip select is active low
+                    FourWireMode,           // Full duplex
+                    8,                      // Bits per word is 8 (byte)
+                    ControllerInitiated,    // Don't care
+                    1000000,                // 1 MHz
+                    ClockPolarityLow,       // SPI mode 0
+                    ClockPhaseFirst,        // SPI mode 0
+                    "\\_SB.PCI0.SPI2",      // SPI host controller
+                    0                       // Must be 0
+                )
+            })
+        }
+    }
+}
-- 
2.8.1

[Buildroot] [PATCH v1 6/9] board / intel: Add Aosong AM2315 sensor for Intel Joule

[Andy Shevchenko]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

This is I2C connected temperature and humidity sensor.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/joule/acpi/am2315.asl | 36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
 create mode 100644 board/intel/joule/acpi/am2315.asl

diff --git a/board/intel/joule/acpi/am2315.asl b/board/intel/joule/acpi/am2315.asl
new file mode 100644
index 0000000..be1dc83
--- /dev/null
+++ b/board/intel/joule/acpi/am2315.asl
@@ -0,0 +1,36 @@
+/*
+ * Intel Joule
+ *
+ * This adds Aosong AM2315 temperature and humidity sensor to the
+ * first I2C bus available on Intel Joule breakout #1 header:
+ *
+ *   pin name           pin number
+ *   -----------------------------
+ *   I2C_0_SDA_LS       11
+ *   I2C_0_SCL_LS       13
+ *
+ * In Linux you need to set CONFIG_AM2315=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("adc.aml", "SSDT", 5, "INTEL", "ADC", 1)
+{
+    External (_SB_.PCI0.I2C1, DeviceObj)
+
+    Scope (\_SB.PCI0.I2C1)
+    {
+        Device (TEMP) {
+            Name (_HID, "AOS2315")
+            Name (_DDN, "Aosong AM2315 Temperature & Humidity sensor")
+            Name (_CRS, ResourceTemplate () {
+                I2cSerialBus (
+                    0x5c,                   // Bus address
+                    ControllerInitiated,    // Don't care
+                    400000,                 // Fast mode (400 kHz)
+                    AddressingMode7Bit,     // 7-bit addressing
+                    "\\_SB.PCI0.I2C1",      // I2C host controller
+                    0                       // Must be 0
+                )
+            })
+        }
+    }
+}
-- 
2.8.1

[Buildroot] [PATCH v1 7/9] board / intel: Add GPIO LEDs for Intel Joule

[Andy Shevchenko]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

There are 4 user controllable leds on the Joule breakout board. This adds
the GPIO LEDs device for those and sets default triggers for SD-card and
system heartbeat.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/joule/acpi/leds.asl | 107 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 107 insertions(+)
 create mode 100644 board/intel/joule/acpi/leds.asl

diff --git a/board/intel/joule/acpi/leds.asl b/board/intel/joule/acpi/leds.asl
new file mode 100644
index 0000000..61ba3c4
--- /dev/null
+++ b/board/intel/joule/acpi/leds.asl
@@ -0,0 +1,107 @@
+/*
+ * Intel Joule
+ *
+ * This adds GPIO LEDs device for the 4 LEDs found on Intel Joule board
+ * available for users. Same GPIOs are also available on breakout header
+ * with pins:
+ *
+ *   pin name           pin number   led
+ *   -----------------------------------------
+ *   ISH_GPIO_0_LS      35           heartbeat
+ *   ISH_GPIO_1_LS      33           sd-card
+ *   ISH_GPIO_2_LS      31           led-2
+ *   ISH_GPIO_3_LS      29           led-3
+ *
+ * In Linux you need to set CONFIG_LEDS_GPIO=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("leds.aml", "SSDT", 5, "INTEL", "LEDS", 1)
+{
+    External (_SB_.PCI0, DeviceObj)
+
+    Scope (\_SB.PCI0)
+    {
+        Device (LEDS)
+        {
+            Name (_HID, "PRP0001")
+            Name (_DDN, "GPIO LEDs device")
+
+            Name (_CRS, ResourceTemplate () {
+                GpioIo (
+                    Exclusive,                  // Not shared
+                    PullNone,                   // No need for pulls
+                    0,                          // Debounce timeout
+                    0,                          // Drive strength
+                    IoRestrictionOutputOnly,    // Only used as output
+                    "\\_SB.GPO2",               // GPIO controller
+                    0)                          // Must be 0
+                {
+                    22,                         // ISH_GPIO_0_LS
+                    23,                         // ISH_GPIO_1_LS
+                    24,                         // ISH_GPIO_2_LS
+                    25                          // ISH_GPIO_3_LS
+                }
+            })
+
+            Name (_DSD, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"compatible", "gpio-leds"},
+                },
+                ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
+                Package () {
+                    Package () {"led-0", "LED0"},
+                    Package () {"led-1", "LED1"},
+                    Package () {"led-2", "LED2"},
+                    Package () {"led-3", "LED3"},
+                }
+            })
+
+            // For more information about these bindings see:
+            // Documentation/devicetree/bindings/leds/leds-gpio.txt and
+            // Documentation/acpi/gpio-properties.txt.
+
+            Name (LED0, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"label", "heartbeat"},
+                    Package () {"gpios", Package () {^LEDS, 0, 0, 1}},
+                    Package () {"linux,default-state", "off"},
+                    Package () {"linux,default-trigger", "heartbeat"},
+                    Package () {"linux,retain-state-suspended", 1},
+                }
+            })
+
+            Name (LED1, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"label", "sd-card"},
+                    Package () {"gpios", Package () {^LEDS, 0, 1, 1}},
+                    Package () {"linux,default-state", "off"},
+                    Package () {"linux,default-trigger", "mmc0"},
+                    Package () {"linux,retain-state-suspended", 1},
+                }
+            })
+
+            Name (LED2, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"label", "led-2"},
+                    Package () {"gpios", Package () {^LEDS, 0, 2, 1}},
+                    Package () {"linux,default-state", "off"},
+                    Package () {"linux,retain-state-suspended", 1},
+                }
+            })
+
+            Name (LED3, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"label", "led-3"},
+                    Package () {"gpios", Package () {^LEDS, 0, 3, 1}},
+                    Package () {"linux,default-state", "off"},
+                    Package () {"linux,retain-state-suspended", 1},
+                }
+            })
+        }
+    }
+}
-- 
2.8.1

[Buildroot] [PATCH v1 8/9] board / intel: Add GPIO LEDs for Intel Minnowboard

[Andy Shevchenko]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

There are 2 user controllable leds on Intel Minnowboard. This adds GPIO
LEDs device for those and sets default triggers for SD-card and system
heartbeat.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/minnowboard/acpi/leds.asl | 82 +++++++++++++++++++++++++++++++++++
 1 file changed, 82 insertions(+)
 create mode 100644 board/intel/minnowboard/acpi/leds.asl

diff --git a/board/intel/minnowboard/acpi/leds.asl b/board/intel/minnowboard/acpi/leds.asl
new file mode 100644
index 0000000..0de36d5
--- /dev/null
+++ b/board/intel/minnowboard/acpi/leds.asl
@@ -0,0 +1,82 @@
+/*
+ * Intel Minnowboard
+ *
+ * http://wiki.minnowboard.org/MinnowBoard
+ *
+ * This adds GPIO LEDs device for the 2 LEDs found on Intel Minnowboard
+ * available for users.
+ *
+ *   GPIO name           GPIO number   led
+ *   -----------------------------------------
+ *   E6XX_GPIO_SUS5      10           heartbeat
+ *   E6XX_GPIO_SUS6      11           sd-card
+ *
+ * In Linux you need to set CONFIG_LEDS_GPIO=y (or m) to be able to use
+ * this device.
+ */
+DefinitionBlock ("leds.aml", "SSDT", 5, "INTEL", "LEDS", 1)
+{
+    External (_SB_.PCI0.LPC, DeviceObj)
+
+    Scope (\_SB.PCI0.LPC)
+    {
+        Device (LEDS)
+        {
+            Name (_HID, "PRP0001")
+            Name (_DDN, "GPIO LEDs device")
+
+            Name (_CRS, ResourceTemplate () {
+                GpioIo (
+                    Exclusive,                  // Not shared
+                    PullNone,                   // No need for pulls
+                    0,                          // Debounce timeout
+                    0,                          // Drive strength
+                    IoRestrictionOutputOnly,    // Only used as output
+                    "\\_SB.PCI0.LPC",           // GPIO controller
+                    0)                          // Must be 0
+                {
+                    10,                         // E6XX_GPIO_SUS5
+                    11,                         // E6XX_GPIO_SUS6
+                }
+            })
+
+            Name (_DSD, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"compatible", "gpio-leds"},
+                },
+                ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
+                Package () {
+                    Package () {"led-0", "LED0"},
+                    Package () {"led-1", "LED1"},
+                }
+            })
+
+            // For more information about these bindings see:
+            // Documentation/devicetree/bindings/leds/leds-gpio.txt and
+            // Documentation/acpi/gpio-properties.txt.
+
+            Name (LED0, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"label", "heartbeat"},
+                    Package () {"gpios", Package () {^LEDS, 0, 0, 0}},
+                    Package () {"linux,default-state", "off"},
+                    Package () {"linux,default-trigger", "heartbeat"},
+                    Package () {"linux,retain-state-suspended", 1},
+                }
+            })
+
+            Name (LED1, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"label", "sd-card"},
+                    Package () {"gpios", Package () {^LEDS, 0, 1, 0}},
+                    Package () {"linux,default-state", "off"},
+                    Package () {"linux,default-trigger", "mmc0"},
+                    Package () {"linux,retain-state-suspended", 1},
+                }
+            })
+        }
+    }
+}
-- 
2.8.1

[Buildroot] [PATCH v1 9/9] board / intel: Add GPIO buttons for Intel Minnowboard

[Andy Shevchenko]

From: Mika Westerberg <mika.westerberg@linux.intel.com>

There are 4 user controllable switches (S0, S1, S2, S3) on Intel
Minnowboard. This adds GPIO buttons device that is able to report key
presses through input layer for those.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 board/intel/minnowboard/acpi/buttons.asl | 104 +++++++++++++++++++++++++++++++
 1 file changed, 104 insertions(+)
 create mode 100644 board/intel/minnowboard/acpi/buttons.asl

diff --git a/board/intel/minnowboard/acpi/buttons.asl b/board/intel/minnowboard/acpi/buttons.asl
new file mode 100644
index 0000000..2bc4220
--- /dev/null
+++ b/board/intel/minnowboard/acpi/buttons.asl
@@ -0,0 +1,104 @@
+/*
+ * Intel Minnowboard
+ *
+ * http://wiki.minnowboard.org/MinnowBoard
+ *
+ * This adds GPIO buttons device for the 4 switches found on Intel
+ * Minnowboard available for users.
+ *
+ *   GPIO name           GPIO number  switch
+ *   ---------------------------------------
+ *   E6XX_GPIO_S0        0            S0
+ *   E6XX_GPIO_S1        1            S1
+ *   E6XX_GPIO_S2        2            S2
+ *   E6XX_GPIO_S3        3            S3
+ *
+ * In Linux you need to set CONFIG_KEYBOARD_GPIO_POLLED=y (or m) to be
+ * able to use this device.
+ */
+DefinitionBlock ("buttons.aml", "SSDT", 5, "INTEL", "BUTTONS", 1)
+{
+    External (_SB_.PCI0.LPC, DeviceObj)
+
+    Scope (\_SB.PCI0.LPC)
+    {
+        Device (BTNS)
+        {
+            Name (_HID, "PRP0001")
+            Name (_DDN, "GPIO buttons device")
+
+            Name (_CRS, ResourceTemplate () {
+                GpioIo (
+                    Exclusive,                  // Not shared
+                    PullUp,                     // Pull up the line
+                    0,                          // Debounce timeout
+                    0,                          // Drive strength
+                    IoRestrictionInputOnly,     // Only used as input
+                    "\\_SB.PCI0.LPC",           // GPIO controller
+                    0)                          // Must be 0
+                {
+                    0,                         // E6XX_GPIO_S0
+                    1,                         // E6XX_GPIO_S1
+                    2,                         // E6XX_GPIO_S2
+                    3,                         // E6XX_GPIO_S3
+                }
+            })
+
+            Name (_DSD, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"compatible", "gpio-keys-polled"},
+                    Package () {"poll-interval", 100},
+                    Package () {"autorepeat", 1}
+                },
+                ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
+                Package () {
+                    Package () {"button-0", "BTN0"},
+                    Package () {"button-1", "BTN1"},
+                    Package () {"button-2", "BTN2"},
+                    Package () {"button-3", "BTN3"}
+                }
+            })
+
+            // For more information about these bindings see:
+            // Documentation/devicetree/bindings/input/gpio-keys-polled.txt
+            // and Documentation/acpi/gpio-properties.txt.
+
+            Name (BTN0, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"linux,code", 105},
+                    Package () {"linux,input-type", 1},
+                    Package () {"gpios", Package () {^BTNS, 0, 0, 1}}
+                }
+            })
+
+            Name (BTN1, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"linux,code", 108},
+                    Package () {"linux,input-type", 1},
+                    Package () {"gpios", Package (4) {^BTNS, 0, 1, 1}}
+                }
+            })
+
+            Name (BTN2, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"linux,code", 103},
+                    Package () {"linux,input-type", 1},
+                    Package () {"gpios", Package () {^BTNS, 0, 2, 1}}
+                }
+            })
+
+            Name (BTN3, Package () {
+                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
+                Package () {
+                    Package () {"linux,code", 106},
+                    Package () {"linux,input-type", 1},
+                    Package () {"gpios", Package () {^BTNS, 0, 3, 1}}
+                }
+            })
+        }
+    }
+}
-- 
2.8.1

[Buildroot] [PATCH v1 2/9] board/intel/common: Add common files for x86 boards

[Thomas Petazzoni]

Hello,

On Thu, 25 Aug 2016 17:04:40 +0300, Andy Shevchenko wrote:
> There are several x86 boards that can utilize same image creation
> infrastructure.
> 
> Add common configuration, cmdline, post-image.sh, post-build.sh scripts and
> placeholders for their extensions.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Thanks for working on this, it's great to see contributions from Intel
for those platforms. However, I'm afraid, quite a few things in there
really aren't done in the Buildroot spirit/philosophy. See some
comments below.


> diff --git a/board/intel/common/README.rst b/board/intel/common/README.rst
> new file mode 100644
> index 0000000..e427067
> --- /dev/null
> +++ b/board/intel/common/README.rst

We don't use the .rst format anywhere else in the tree, so please stick
to a regular readme.txt, like we have for all other platforms.

> +Building an image
> +~~~~~~~~~~~~~~~~~
> +
> +For building a normal bootable image, you need to do following steps:
> +
> +1) Build your own kernel.
> +
> +2) Configure Buildroot.
> +
> +The Buildroot configuration would be done by running::
> +
> +	% make <BOARD>_defconfig
> +
> +For most of the boards it's good enough to use generic [intel_defconfig]_.
> +
> +3) Build Buildroot.
> +
> +Build the necessary Buildroot packages and resulting image::
> +
> +	% make KERNEL_SRC=~/linux

What is this magic KERNEL_SRC variable? In appearance at least, it
completely circumvents the Buildroot config options for specifying where
the kernel sources are located. So this is clearly a no-go.

> +Supported environment variables
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The scripts under ``board/intel/common`` accept several environment variables
> +that can be used to alter the default behaviour. Typically you do something
> +like::
> +
> +	% make KERNEL_SRC=~/linux

Should not exist.

> +in order to take advantage of these.
> +
> +BOARD_INTEL_CUSTOM_CMDLINE
> +	provides a custom appendix to the command line.
> +
> +BOARD_INTEL_DIR
> +	points to a specific board directory.
> +
> +KERNEL_SRC
> +	path to your kernel output folder.

I'm not sure any of these should exist. KERNEL_SRC is already something
provided by Buildroot.

The board directory can be known by other ways (see how the various
raspberrypi variants are handled, for example).

> +Alterate console

Alterate, or alternate ?

> +~~~~~~~~~~~~~~~~
> +
> +By default ``ttyS0`` is used as a default cosole for both kernel and userspace.

cosole -> console

> +The **BR2_TARGET_GENERIC_GETTY_PORT** variable could be used to alterate this
> +setting.

Why not, but this is general Buildroot usage, not related to Intel
boards specifically.

> +Supported boards
> +~~~~~~~~~~~~~~~~
> +
> +.. [intel_defconfig] Generic config for most of Intel SoCs.

This part is pretty uninformative :)

> +Examples
> +~~~~~~~~
> +
> +- ASuS T100TA and the rest with ``ttyUSB0``::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyUSB0		\
> +				  BOARD_INTEL_CUSTOM_CMDLINE="reboot=h,p"
> +
> +- Galileo (Quark)::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS1
> +
> +- Joule (Broxton), Edison (Merrifield)::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS2
> +
> +- Minnowboard [#]_::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyPCH0
> +
> +.. [#] Minnowboard MAX goes the standard way with ``ttyS0``.

Please instead provide different defconfigs for those platforms:

	galileo_defconfig
	minnowboard_defconfig
	joule_defconfig

etc.


> diff --git a/board/intel/common/post-build.d/README b/board/intel/common/post-build.d/README
> new file mode 100644
> index 0000000..5bcb10b
> --- /dev/null
> +++ b/board/intel/common/post-build.d/README
> @@ -0,0 +1,4 @@
> +#
> +# This folder contains the shell scripts which will be executed in alphabetical
> +# order on post build stage.
> +#

I don't think we want an Intel specific mechanism for directories
containing post-build scripts. I'd prefer to extend the current
BR2_ROOTFS_POST_BUILD_SCRIPT logic (which allows to pass multiple
space-separated post-build script) to automatically run all scripts in
a directory if one entry in BR2_ROOTFS_POST_BUILD_SCRIPT is a directory.

Or maybe, with the small number of post-build scripts and post-image
scripts that you have, just call them from the relevant board defconfig.

> +# Read cmdline and modify console parameter
> +sed -e "s#$console_default#$console#" "$cmdline" > "$BINARIES_DIR/cmdline"

What is this cmdline file doing in the end?

> diff --git a/board/intel/common/post-image.d/40-prepare-initrd b/board/intel/common/post-image.d/40-prepare-initrd
> new file mode 100755
> index 0000000..7bf7769
> --- /dev/null
> +++ b/board/intel/common/post-image.d/40-prepare-initrd
> @@ -0,0 +1,14 @@
> +#!/bin/sh -e
> +
> +#
> +# Copyright (c) 2016 Intel Corp.
> +#
> +
> +#
> +# Environment:
> +#
> +# None
> +#

That's really a whole lot of nothing for just a single line of useful
code :-)

> diff --git a/configs/intel_defconfig b/configs/intel_defconfig
> new file mode 100644
> index 0000000..8aff9e1
> --- /dev/null
> +++ b/configs/intel_defconfig

We don't have the concept of such generic defconfigs. We have defconfig
per identified platform, and I'm not really sure to understand the
logic behind this generic defconfig that then needs to be passed
through custom environment variables to be customized depending on the
platform.

It's clearly not the direction I would like to take for the defconfigs.

> +# Packages
> +BR2_PACKAGE_KEXEC=y
> +BR2_PACKAGE_KEXEC_ZLIB=y
> +BR2_PACKAGE_LRZSZ=y
> +BR2_PACKAGE_SCREEN=y

We normally don't enable specific packages in our defconfig, since they
are meant to be minimal, i.e just the toolchain, kernel, bootloader,
and Busybox userspace.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Thomas Petazzoni]

Hello,

On Thu, 25 Aug 2016 17:04:41 +0300, Andy Shevchenko wrote:

>  in order to take advantage of these.
>  
> +BOARD_INTEL_ACPI_TABLES
> +	list of table names to built into the ``initrd``.

Please make this a Buildroot configuration option.

> +# Pick iASL.
> +# First try from buildroot and if not there then try from the host.
> +[ -x "$HOST_DIR/usr/bin/iasl" ] && iasl="$HOST_DIR/usr/bin/iasl" || iasl=$(which iasl)
> +
> +[ -x "$iasl" ] || {
> +	echo "You need to to have iASL compiler available. You can either enable"
> +	echo "BR2_PACKAGE_HOST_ACPICA or install it locally for your host."
> +	echo "Typically the package is called acpica-tools in major distros".
> +	exit 1
> +}
> +
> +# The name of the folder is the name of a board
> +board_name="${BOARD_DIR##*/}"
> +[ "$board_name" = "common" ] && {
> +	echo "Adding ACPI tables is always specific to a board!"
> +	echo "You are not supposed to use common as board here!"
> +	exit 1
> +}
> +
> +# Always prefix with the board name to avoid mistakes if the initrd is used
> +# with another board.
> +updated_initrd_name="${board_name}-acpi-rootfs.cpio"
> +updated_initrd="$BINARIES_DIR/$updated_initrd_name"
> +initrd="$(readlink -enq "$BINARIES_DIR/initrd")"
> +tmpamldir="$BINARIES_DIR/acpi-tables"
> +
> +# Make sure existing tables get cleared
> +rm -fr $tmpamldir
> +mkdir -p $tmpamldir/kernel/firmware/acpi
> +
> +for table in $ACPI_TABLES; do
> +	[ -f "$ACPI_DIR/$table" ] || continue
> +
> +	$iasl -p $tmpamldir/kernel/firmware/acpi/$table "$ACPI_DIR/$table" > /dev/null 2>&1
> +
> +	echo "ACPI: Compiled ASL from $(realpath --relative-to=$PWD $ACPI_DIR/$table)"
> +done
> +
> +# Exit if no tables were compiled
> +[ -n "$(find $tmpamldir -type f)" ] || {
> +	echo "ACPI: No tables were compiled"
> +	exit 0
> +}
> +
> +# Attach compiled tables to initrd
> +(
> +	cd $tmpamldir
> +	find kernel | cpio -H newc -o > $updated_initrd 2>/dev/null
> +	cat $initrd >> $updated_initrd
> +	ln -sf "$updated_initrd_name" "$BINARIES_DIR/initrd"
> +)
> +
> +echo "ACPI: Created initrd with updated ACPI tables in $(realpath --relative-to=$PWD $updated_initrd)"

And move all of this logic into Buildroot make code. I'm not sure yet
exactly where it fits. Maybe as an option of the host-acpica package ?
As an option in the "System configuration" menu ? Or, maybe better,
since those updated ACPI tables are consumed by the kernel, as a kernel
option ?

But clearly, something like that shouldn't be done in a post-image or
post-build script.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 1/9] package/acpica: Add host configuration to the tool

[Thomas Petazzoni]

Hello,

On Thu, 25 Aug 2016 17:04:39 +0300, Andy Shevchenko wrote:
> The ACPI excerpts, which would be added to an initial RAM disk image, require
> to be compiled first. iasl tool from acpica package helps do that.
> 
> Enable host variant of the application to be built.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

This patch generally looks good, but I'm not entirely sure we need this
package to be visible in menuconfig. This depends on the outcome of the
discussion for PATCH 3/9.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 4/9] board / intel: Add SPI peripherals for Minnowboard MAX

[Thomas Petazzoni]

Hello,

On Thu, 25 Aug 2016 17:04:42 +0300, Andy Shevchenko wrote:
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> 
> Add two SPI peripherals which can be connected to Minnowboard MAX low speed
> connector. First is Atmel AT25 compatible SPI EEPROM and second is M25P80
> compatible SPI serial flash.
> 
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  board/intel/minnowboard-max/acpi/at25.asl   | 58 +++++++++++++++++++++++++++++
>  board/intel/minnowboard-max/acpi/m25p80.asl | 52 ++++++++++++++++++++++++++
>  2 files changed, 110 insertions(+)
>  create mode 100644 board/intel/minnowboard-max/acpi/at25.asl
>  create mode 100644 board/intel/minnowboard-max/acpi/m25p80.asl

Is there some upstream project for those ACPI tables? I wouldn't want
to have them all in Buildroot, I'd very much prefer to have a Buildroot
package download them, compile them using the acpica compiler, and
install them in the proper place.

It's fine to have them in Buildroot as a temporary solution, as long as
some upstream is being put in place. But if the long term idea is to
keep those ACPI tables source code in Buildroot, then I don't think
it's what we want to do.

This of course applies to patches 4/9 to 9/9.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Arnout Vandecappelle]

On 25-08-16 16:04, Andy Shevchenko wrote:
> Add script which takes ASL files as input, compiles them to AML bytecode,
> and prepends the whole thing to the initrd archive. They are placed in
> kernel/firmware/acpi directory where the kernel is able to find and use
> them.

 Why is this a post-image script, and not just a post-build script that copies
everything in the right place and lets the cpio rootfs take care of generating
the cpio? AFAIK there is no particular requirement for this stuff to be at the
beginning of the cpio image, is there?

 Note: I don't agree with Thomas that there should be buildroot config for doing
this. It's simple enough to do in a post-build script, which is more flexible.

[snip]
> +# Pick iASL.
> +# First try from buildroot and if not there then try from the host.
> +[ -x "$HOST_DIR/usr/bin/iasl" ] && iasl="$HOST_DIR/usr/bin/iasl" || iasl=$(which iasl)

 You can skip the HOST_DIR part, because HOST_DIR/usr/bin is at the beginning of
PATH so that one will be picked up.

> +
> +[ -x "$iasl" ] || {
> +	echo "You need to to have iASL compiler available. You can either enable"
> +	echo "BR2_PACKAGE_HOST_ACPICA or install it locally for your host."
> +	echo "Typically the package is called acpica-tools in major distros".
> +	exit 1
> +}
> +
> +# The name of the folder is the name of a board
> +board_name="${BOARD_DIR##*/}"
> +[ "$board_name" = "common" ] && {
> +	echo "Adding ACPI tables is always specific to a board!"
> +	echo "You are not supposed to use common as board here!"
> +	exit 1
> +}
> +
> +# Always prefix with the board name to avoid mistakes if the initrd is used
> +# with another board.
> +updated_initrd_name="${board_name}-acpi-rootfs.cpio"
> +updated_initrd="$BINARIES_DIR/$updated_initrd_name"
> +initrd="$(readlink -enq "$BINARIES_DIR/initrd")"
> +tmpamldir="$BINARIES_DIR/acpi-tables"

 Better use BUILD_DIR for temporary stuff. Also, since you seem to want to
support several boards in a single output tree, append board_name to the
directory name.


 Regards,
 Arnout

> +
> +# Make sure existing tables get cleared
> +rm -fr $tmpamldir
> +mkdir -p $tmpamldir/kernel/firmware/acpi
> +
> +for table in $ACPI_TABLES; do
> +	[ -f "$ACPI_DIR/$table" ] || continue
> +
> +	$iasl -p $tmpamldir/kernel/firmware/acpi/$table "$ACPI_DIR/$table" > /dev/null 2>&1
> +
> +	echo "ACPI: Compiled ASL from $(realpath --relative-to=$PWD $ACPI_DIR/$table)"
> +done
> +
> +# Exit if no tables were compiled
> +[ -n "$(find $tmpamldir -type f)" ] || {
> +	echo "ACPI: No tables were compiled"
> +	exit 0
> +}
> +
> +# Attach compiled tables to initrd
> +(
> +	cd $tmpamldir
> +	find kernel | cpio -H newc -o > $updated_initrd 2>/dev/null
> +	cat $initrd >> $updated_initrd
> +	ln -sf "$updated_initrd_name" "$BINARIES_DIR/initrd"
> +)
> +
> +echo "ACPI: Created initrd with updated ACPI tables in $(realpath --relative-to=$PWD $updated_initrd)"
> diff --git a/configs/intel_defconfig b/configs/intel_defconfig
> index 8aff9e1..24167fc 100644
> --- a/configs/intel_defconfig
> +++ b/configs/intel_defconfig
> @@ -17,6 +17,9 @@ BR2_ROOTFS_POST_BUILD_SCRIPT="board/intel/common/post-build.sh"
>  BR2_ROOTFS_POST_IMAGE_SCRIPT="board/intel/common/post-image.sh"
>  BR2_ROOTFS_POST_SCRIPT_ARGS=""
>  
> +# Host tools
> +BR2_PACKAGE_HOST_ACPICA=y
> +
>  # Busybox utilities (target)
>  BR2_PACKAGE_BUSYBOX_WATCHDOG=y
>  
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Thomas Petazzoni]

Hello,

On Fri, 26 Aug 2016 08:13:54 +0200, Arnout Vandecappelle wrote:

>  Note: I don't agree with Thomas that there should be buildroot config for doing
> this. It's simple enough to do in a post-build script, which is more flexible.

Depends on what gets done. And just like our linux.mk package allows to
build DTBs, it could allow building ACPI table, which is something
several x86 platforms might need.

What I *really* dislike in the proposal is the additional magic
environment variables, and there's specifically one to list the ACPI
tables to build.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 4/9] board / intel: Add SPI peripherals for Minnowboard MAX

[Thomas Petazzoni]

Hello,

On Fri, 26 Aug 2016 12:09:17 +0300, Mika Westerberg wrote:

> > Is there some upstream project for those ACPI tables? I wouldn't want
> > to have them all in Buildroot, I'd very much prefer to have a Buildroot
> > package download them, compile them using the acpica compiler, and
> > install them in the proper place.  
> 
> Currently there is no upstream project for these but we have plans to do
> so eventually. The idea is to have only one per-device ASL template and
> then tune that to work with the target board, but the template format is
> not yet crystal clear.

So you're storing those files in both Yocto Project recipes, and intend
to do so in Buildroot? And every other build system wanting to support
your platforms would have to carry those files as well. Doesn't seem
like a solution that will make it easy for you to update those files.

What about having some Git repo hosted somewhere to host those files?
We could then have a Buildroot package that fetches them and does the
acpica compilation process.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Thomas Petazzoni]

Hello,

On Fri, 26 Aug 2016 12:04:54 +0300, Mika Westerberg wrote:

> > On 25-08-16 16:04, Andy Shevchenko wrote:  
> > > Add script which takes ASL files as input, compiles them to AML bytecode,
> > > and prepends the whole thing to the initrd archive. They are placed in
> > > kernel/firmware/acpi directory where the kernel is able to find and use
> > > them.  
> > 
> >  Why is this a post-image script, and not just a post-build script that copies
> > everything in the right place and lets the cpio rootfs take care of generating
> > the cpio? AFAIK there is no particular requirement for this stuff to be at the
> > beginning of the cpio image, is there?  
> 
> Actually there is - the kernel looks only from the first uncompressed
> cpio archive for these additional AML files.

Still not clear: Arnout doesn't suggest to generate multiple cpio
archives, but rather to simply have the AML files within the cpio
archive in the first place.

The Buildroot process looks like this:

 1. Build all packages
 2. Run post-build scripts
 3. Create filesystem images (including cpio one)
 4. Run post-image scripts

Right now, if I understand correctly, in step (4), you're generating an
additional initrd with just the AML files. Is this correct?

What about instead having things done in step (2): install the AML
files at the appropriate places in $(TARGET_DIR) so that they
automatically end up in the rootfs.cpio generated by Buildroot?

In this case, there's a single initrd, which contains both the root
filesystem itself and the AML files.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 1/9] package/acpica: Add host configuration to the tool

[Erico Nunes]

Hello,

On Thu, Aug 25, 2016 at 4:04 PM, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> +define HOST_ACPICA_BUILD_CMDS
> +       $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)                         \
> +               HARDWARE_NAME=$(BR2_ARCH) HOST=_LINUX CC="$(HOSTCC)"    \
> +               all
> +endef
> +
> +define HOST_ACPICA_INSTALL_CMDS
> +       $(HOST_CONFIGURE_OPTS) $(MAKE) -C $(@D)                         \
> +               HARDWARE_NAME=$(BR2_ARCH) DESTDIR="$(HOST_DIR)"         \
> +               INSTALLFLAGS=-m755 install
> +endef

HARDWARE_NAME should probably not be set to BR2_ARCH for the host
version of the package, as it contains the target architecture. Even
though it is a rather useless variable today (as pointed out by Thomas
in github https://github.com/acpica/acpica/pull/152), it makes even
less sense here.

Erico

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Thomas Petazzoni]

Hello,

On Fri, 26 Aug 2016 12:39:01 +0300, Mika Westerberg wrote:

> > What about instead having things done in step (2): install the AML
> > files at the appropriate places in $(TARGET_DIR) so that they
> > automatically end up in the rootfs.cpio generated by Buildroot?  
> 
> That would work but it them means that you cannot compress the resulting
> cpio archive. The kernel loader only looks for the first uncompressed
> one.

Ah, *that* is a good reason for having a separate initrd. In fact, I
was not even aware we could pass multiple initrd and that they were
merged together. That's good to know.

Back to your problem, then I guess it makes a lot of sense to have a
separate initrd, so that the biggest part of the initrd (the root
filesystem itself) can remain compressed.

I'm still on the opinion that a package should do all of this: download
the .aml files from some upstream project, compile them with acpica and
generate an uncompressed initrd image. Possibly this package can have
options such as a platform name to only build/install a subset of
the .aml files (and by default it builds all of them). Something along
the lines of (completely untested) :

config BR2_PACKAGE_INTEL_ACPI_TABLE_ADDONS
	bool "intel-acpi-table-addons"
	help
	  ....

	  http://....

if BR2_PACKAGE_INTEL_ACPI_TABLE_ADDONS_PLATFORMS
	string "platform list"
	help
	  Space-separated list of platforms for which the additional
	  ACPI tables should be built and installed. If left empty, all
	  ACPI tables will be built and installed.

endif

in the .mk file:

INTEL_ACPI_TABLE_ADDONS_VERSION = ...
INTEL_ACPI_TABLE_ADDONS_SITE = ...
INTEL_ACPI_TABLE_ADDONS_INSTALL_TARGET = NO
INTEL_ACPI_TABLE_ADDONS_INSTALL_IMAGES = NO
INTEL_ACPI_TABLE_ADDONS_DEPENDENCIES = host-acpica

INTEL_ACPI_TABLE_ADDONS_PLATFORMS = $(call qstrip,$(BR2_PACKAGE_INTEL_ACPI_TABLE_ADDONS_PLATFORMS))
ifeq ($(INTEL_ACPI_TABLE_ADDONS_PLATFORMS),)
INTEL_ACPI_TABLE_ADDONS_PLATFORMS = list of all platforms
endif

define INTEL_ACPI_TABLE_ADDONS_BUILD_CMDS
	$(foreach plat,$(INTEL_ACPI_TABLE_ADDONS_PLATFORMS),\
		$(HOST_DIR)/usr/bin/iasl -o $(@D)/... ....)
	... generate initrd in $(@D)
endef

define INTEL_ACPI_TABLE_ADDONS_INSTALL_IMAGE_CMDS
	... copy initrd from $(@D) to $(BINARIES_DIR) ...
endef

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Arnout Vandecappelle]

On 26-08-16 11:39, Mika Westerberg wrote:
> On Fri, Aug 26, 2016 at 11:30:22AM +0200, Thomas Petazzoni wrote:
[snip]
>> Still not clear: Arnout doesn't suggest to generate multiple cpio
>> archives, but rather to simply have the AML files within the cpio
>> archive in the first place.
>>
>> The Buildroot process looks like this:
>>
>>  1. Build all packages
>>  2. Run post-build scripts
>>  3. Create filesystem images (including cpio one)
>>  4. Run post-image scripts
>>
>> Right now, if I understand correctly, in step (4), you're generating an
>> additional initrd with just the AML files. Is this correct?
> 
> Yes, that's correct.
> 
>> What about instead having things done in step (2): install the AML
>> files at the appropriate places in $(TARGET_DIR) so that they
>> automatically end up in the rootfs.cpio generated by Buildroot?
> 
> That would work but it them means that you cannot compress the resulting
> cpio archive. The kernel loader only looks for the first uncompressed
> one.

 That is rather stupid of the kernel :-) I guess it's because this acpi stuff is
needed in early boot while normally the initrd is only unpacked at the end... I
didn't even know that the kernel supported having multiple cpio archives in the
initrd, and even with different compression!

 Is it still possible to use an ext3 as a rootfs rather than an initrd? I.e.,
use a cpio archive with just the acpi stuff but have the real rootfs (including
/sbin/init) on SD card. We generally have a writeable and persistent rootfs in
the defconfigs because it's more convenient for experimenting.

 If this possibility exists, then I think it would make sense to add a package
(in the bootloader menu maybe?) that generates this cpio archive, like Thomas
suggested. Appending the two archives, however, is still something for a
post-image script I think.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v1 2/9] board/intel/common: Add common files for x86 boards

[Arnout Vandecappelle]

 Hi Andy,

 I generally agree with Thomas's comments, and have a few more.

On 25-08-16 16:04, Andy Shevchenko wrote:
[snip]
> +3) Build Buildroot.
> +
> +Build the necessary Buildroot packages and resulting image::
> +
> +	% make KERNEL_SRC=~/linux
> +
> +where ``~/linux`` is whatever the path to the kernel output folder is.
> +
> +4) Get the resulting image.
> +
> +The resulting image is placed under output/images and is called either
> +``rootfs.cpio.bz2`` or ``initrd``. ``initrd`` is the link to the last modified
> +image since some scripts may alter it on post image stage.

 Why are you not building a kernel or bootloader in this defconfig?

 Why is it called 'initrd'? All bootloaders allow to pass an initrd with a
different name. And it's this initrd name that caused confusion in our
understanding of the two cpio archives: if it would have said 'cat
rootfs.cpio.bz2 >> $initrd' it would have been a lot more obvious.

> +
> +Supported environment variables

 Don't pass things through environment variables, pass them on the command line.
The same arguments are passed to all scripts, so you have to parse them with
some advanced getopt, but that's easy. E.g. the following converts args to vars:

for arg; do
   [[ $arg == *=* ]] && eval "$arg"
done


> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The scripts under ``board/intel/common`` accept several environment variables
> +that can be used to alter the default behaviour. Typically you do something
> +like::
> +
> +	% make KERNEL_SRC=~/linux
> +
> +in order to take advantage of these.
> +
> +BOARD_INTEL_CUSTOM_CMDLINE
> +	provides a custom appendix to the command line.
> +
> +BOARD_INTEL_DIR
> +	points to a specific board directory.
> +
> +KERNEL_SRC
> +	path to your kernel output folder.

 As mentioned by Thomas: scripts that are part of buildroot should only support
a buildroot-built kernel.

 And the defconfigs should build that kernel.

> +
> +Alterate console
> +~~~~~~~~~~~~~~~~
> +
> +By default ``ttyS0`` is used as a default cosole for both kernel and userspace.
> +The **BR2_TARGET_GENERIC_GETTY_PORT** variable could be used to alterate this
> +setting.
> +
> +Supported boards
> +~~~~~~~~~~~~~~~~
> +
> +.. [intel_defconfig] Generic config for most of Intel SoCs.
> +
> +Examples
> +~~~~~~~~
> +
> +- ASuS T100TA and the rest with ``ttyUSB0``::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyUSB0		\
> +				  BOARD_INTEL_CUSTOM_CMDLINE="reboot=h,p"
> +
> +- Galileo (Quark)::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS1
> +
> +- Joule (Broxton), Edison (Merrifield)::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyS2
> +
> +- Minnowboard [#]_::
> +
> +	% make KERNEL_SRC=~/linux BR2_TARGET_GENERIC_GETTY_PORT=ttyPCH0

 As mentioned by Thomas, each of these should have their own defconfig. To show
the commonality, you could make them start with intel_*.

> +
> +.. [#] Minnowboard MAX goes the standard way with ``ttyS0``.
> diff --git a/board/intel/common/cmdline b/board/intel/common/cmdline
> new file mode 100644
> index 0000000..54465ef
> --- /dev/null
> +++ b/board/intel/common/cmdline
> @@ -0,0 +1 @@
> +console=tty1 console=ttyS0,115200n8
> diff --git a/board/intel/common/libshell-intel b/board/intel/common/libshell-intel
> new file mode 100644
> index 0000000..f834ecb
> --- /dev/null
> +++ b/board/intel/common/libshell-intel
> @@ -0,0 +1,26 @@
> +#
> +# Copyright (c) 2016 Intel Corp.
> +#
> +
> +#
> +# Environment:
> +#
> +# BOARD_INTEL_DIR		- Directory holding board specific
> +#				  configuration
> +#
> +
> +# Use this folder to provide board specific files
> +BOARD_DIR_DEFAULT="$(dirname $(dirname "$0"))"
> +BOARD_DIR="$(readlink -mnq "${BOARD_INTEL_DIR:-$BOARD_DIR_DEFAULT}")"
> +
> +[ -d "$BOARD_DIR" ] || echo "Warning: $BOARD_INTEL_DIR does not exist"
> +
> +# Looking up for a custom file if provided, otherwise fallback to the original name
> +intel_file_lookup() {
> +	[ -f "$BOARD_DIR/$1" ] && echo "$BOARD_DIR/$1" || echo "$BOARD_DIR_DEFAULT/$1"
> +}
> +
> +# Looking up for a custom folder if provided, otherwise fallback to the original name
> +intel_folder_lookup() {
> +	[ -d "$BOARD_DIR/$1" ] && echo "$BOARD_DIR/$1" || echo "$BOARD_DIR_DEFAULT/$1"
> +}

 I don't see why we would need this fallback approach. The defconfigs and
related board stuff are not meant to be used for real development. Instead, they
should be copied and adapted for real development.


 Regards,
 Arnout

[snip]
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Arnout Vandecappelle]

On 29-08-16 08:55, Mika Westerberg wrote:
> On Fri, Aug 26, 2016 at 06:30:47PM +0200, Arnout Vandecappelle wrote:
>>
[snip]
>>  Is it still possible to use an ext3 as a rootfs rather than an initrd? I.e.,
>> use a cpio archive with just the acpi stuff but have the real rootfs (including
>> /sbin/init) on SD card. We generally have a writeable and persistent rootfs in
>> the defconfigs because it's more convenient for experimenting.
> 
> Sure we can use ext3 or whatever. Only thing that requires initrd is the
> AML stuff and we can generate that separately. That said the system we
> use here for kernel development only uses initrd (because that does not
> require any kind of disk to be present in the system under development).

 Well, you'll need _some_ kind of storage for the boot loader, no? Unless you
use PXE, but in that case you'll probably want to use NFS-root.

 PXE boot is however a bit more complicated to set up (you have to run a DHCP
server, probably on a private network, which means a second interface on your PC
or setting up VLAN in your switch), so we prefer to stick with disk-based (i.e.,
SD card) boot. Cfr. for instance the existing Minnowboard configs.

 So I would say: create the cpio archive from some package (possibly the package
containing the actual definitions, like Thomas suggested), and create
board-specific defconfigs that build SD card images.

 Regards,
 Arnout

> 
>>  If this possibility exists, then I think it would make sense to add a package
>> (in the bootloader menu maybe?) that generates this cpio archive, like Thomas
>> suggested. Appending the two archives, however, is still something for a
>> post-image script I think.
> 
> OK.
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH v1 3/9] board/intel/common: Add possibility for adding ACPI tables to the initrd

[Arnout Vandecappelle]

On 29-08-16 09:58, Mika Westerberg wrote:
> On Mon, Aug 29, 2016 at 09:45:27AM +0200, Arnout Vandecappelle wrote:
>>
>>
>> On 29-08-16 08:55, Mika Westerberg wrote:
>>> On Fri, Aug 26, 2016 at 06:30:47PM +0200, Arnout Vandecappelle wrote:
>>>>
>> [snip]
>>>>  Is it still possible to use an ext3 as a rootfs rather than an initrd? I.e.,
>>>> use a cpio archive with just the acpi stuff but have the real rootfs (including
>>>> /sbin/init) on SD card. We generally have a writeable and persistent rootfs in
>>>> the defconfigs because it's more convenient for experimenting.
>>>
>>> Sure we can use ext3 or whatever. Only thing that requires initrd is the
>>> AML stuff and we can generate that separately. That said the system we
>>> use here for kernel development only uses initrd (because that does not
>>> require any kind of disk to be present in the system under development).
>>
>>  Well, you'll need _some_ kind of storage for the boot loader, no? Unless you
>> use PXE, but in that case you'll probably want to use NFS-root.
> 
> Right, we boot the system off USB stick which holds kernel+initrd and we
> use that initrd as our rootfs (which is suitable for most cases). That
> thing then fetches the actual kernel+initrd over tftp and kexecs them.

 A very useful setup - I may use that approach in my own future development as
well. But not suitable for a buildroot defconfig :-).

 It also explains why you had KEXEC=y in your defconfig.

 Regards,
 Arnout

> 
>>  PXE boot is however a bit more complicated to set up (you have to run a DHCP
>> server, probably on a private network, which means a second interface on your PC
>> or setting up VLAN in your switch), so we prefer to stick with disk-based (i.e.,
>> SD card) boot. Cfr. for instance the existing Minnowboard configs.
> 
> Yes I know and PXE does not work on most development systems anyway.
> That's why we use the above setup :)
> 

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF