[PATCH v3 0/7] Isar cross-compilation support

[PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

Hi everybody,

sorry for the delay, this is the third version of cross-compilation
support for Isar.

Supported targets for cross-compilation:
 - stretch armhf
 - stretch amd64

Artifacts could be cross-compiled:
 - dpkg.bbclass users
 - dpkg-raw.bbclass users
 - kernel

Known issues:
 - if target and host architectures are the same, there is no need
   to use host buildchroot.
 - kernel module doesn't support cross-compilation. Default linux-headers
   package depends from target gcc binaries. So attempt to install, for
   example linux-headers-armmp, tries to install gcc:armhf, what rises
   conflict with the host tools.

To enable cross-compilation, the variable ISAR_CROSS_COMPILE should be set
to "1" in local.conf file.

With best regards,
Alex

Alexander Smirnov (7):
  isar-bootstrap: Update routine to determine host arch
  buildchroot: Split generic part
  buildchroot: Add host buildchroot
  isar-bootstrap-helper: Add target architecture for dpkg
  build.sh: Add additional parameter
  cross-compilation: Introduce variable switch
  linux: Add cross-compilation support

 meta-isar/conf/local.conf.sample                   |  5 ++
 meta/classes/dpkg-base.bbclass                     | 19 ++++-
 meta/classes/dpkg.bbclass                          |  4 +-
 meta/classes/isar-bootstrap-helper.bbclass         | 13 +++-
 meta/classes/wic-img.bbclass                       |  3 +-
 meta/conf/isar-bitbake.conf                        |  3 +-
 .../buildchroot/buildchroot-host.bb                | 31 ++++++++
 .../buildchroot/buildchroot-target.bb              | 54 ++++++++++++++
 meta/recipes-devtools/buildchroot/buildchroot.bb   | 83 ----------------------
 meta/recipes-devtools/buildchroot/buildchroot.inc  | 37 ++++++++++
 meta/recipes-devtools/buildchroot/files/build.sh   | 17 ++++-
 meta/recipes-kernel/linux-module/module.inc        |  7 ++
 meta/recipes-kernel/linux/files/build-kernel.sh    | 16 +++++
 meta/recipes-kernel/linux/linux-custom.inc         |  4 +-
 14 files changed, 200 insertions(+), 96 deletions(-)
 create mode 100644 meta/recipes-devtools/buildchroot/buildchroot-host.bb
 create mode 100644 meta/recipes-devtools/buildchroot/buildchroot-target.bb
 delete mode 100644 meta/recipes-devtools/buildchroot/buildchroot.bb
 create mode 100644 meta/recipes-devtools/buildchroot/buildchroot.inc

-- 
2.1.4

[PATCH v3 1/7] isar-bootstrap: Update routine to determine host arch

[Alexander Smirnov]

Use generic dpkg call, because dpkg-architecture requires additional
package to install.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/classes/isar-bootstrap-helper.bbclass | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/classes/isar-bootstrap-helper.bbclass b/meta/classes/isar-bootstrap-helper.bbclass
index e4d99d5..3faee7c 100644
--- a/meta/classes/isar-bootstrap-helper.bbclass
+++ b/meta/classes/isar-bootstrap-helper.bbclass
@@ -9,8 +9,12 @@ IMAGE_TRANSIENT_PACKAGES ??= ""
 
 def get_deb_host_arch():
     import subprocess
-    arch =  subprocess.check_output(['/usr/bin/dpkg-architecture', '-q', 'DEB_HOST_ARCH'], universal_newlines=True)
-    return str.splitlines(arch)[0]
+    host_arch = subprocess.Popen("dpkg --print-architecture",
+                                 shell=True,
+                                 env=os.environ,
+                                 stdout=subprocess.PIPE
+                                ).stdout.read().decode('utf-8').strip()
+    return host_arch
 
 #Debian Distribution for SDK host
 HOST_DISTRO ?= "debian-stretch"
-- 
2.1.4

[PATCH v3 2/7] buildchroot: Split generic part

[Alexander Smirnov]

Split generic part of the buildchroot creation process. Also
intriduce buildchroot recipe for target.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/classes/dpkg-base.bbclass                     |  2 +-
 meta/classes/dpkg-raw.bbclass                      |  1 +
 meta/classes/dpkg.bbclass                          |  4 +-
 meta/classes/wic-img.bbclass                       |  3 +-
 meta/conf/isar-bitbake.conf                        |  2 +-
 .../buildchroot/buildchroot-target.bb              | 54 ++++++++++++++
 meta/recipes-devtools/buildchroot/buildchroot.bb   | 83 ----------------------
 meta/recipes-devtools/buildchroot/buildchroot.inc  | 37 ++++++++++
 8 files changed, 99 insertions(+), 87 deletions(-)
 create mode 100644 meta/recipes-devtools/buildchroot/buildchroot-target.bb
 delete mode 100644 meta/recipes-devtools/buildchroot/buildchroot.bb
 create mode 100644 meta/recipes-devtools/buildchroot/buildchroot.inc

diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
index 75b45a7..3234234 100644
--- a/meta/classes/dpkg-base.bbclass
+++ b/meta/classes/dpkg-base.bbclass
@@ -15,7 +15,7 @@ inherit patch
 addtask patch after do_adjust_git before do_build
 
 # Add dependency from buildchroot creation
-do_build[depends] = "buildchroot:do_build"
+do_build[depends] = "buildchroot-target:do_build"
 
 # Add dependency between Isar recipes
 DEPENDS ?= ""
diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
index 28233ac..2f23eb7 100644
--- a/meta/classes/dpkg-raw.bbclass
+++ b/meta/classes/dpkg-raw.bbclass
@@ -7,6 +7,7 @@ DEBIAN_DEPENDS ?= ""
 MAINTAINER ?= "FIXME Unknown maintainer"
 
 D = "${WORKDIR}/image/"
+BUILDCHROOT_DIR = "${BUILDCHROOT_TARGET_DIR}"
 
 # Populate folder that will be picked up as package
 do_install() {
diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
index c8d4ac5..563b63c 100644
--- a/meta/classes/dpkg.bbclass
+++ b/meta/classes/dpkg.bbclass
@@ -1,8 +1,10 @@
 # This software is a part of ISAR.
-# Copyright (C) 2015-2016 ilbers GmbH
+# Copyright (C) 2015-2018 ilbers GmbH
 
 inherit dpkg-base
 
+BUILDCHROOT_DIR = "${BUILDCHROOT_TARGET_DIR}"
+
 # Build package from sources using build script
 dpkg_runbuild() {
     E="${@ bb.utils.export_proxies(d)}"
diff --git a/meta/classes/wic-img.bbclass b/meta/classes/wic-img.bbclass
index 07c2a9e..b56df7b 100644
--- a/meta/classes/wic-img.bbclass
+++ b/meta/classes/wic-img.bbclass
@@ -13,6 +13,7 @@ STAGING_DIR ?= "${TMPDIR}"
 IMAGE_BASENAME ?= "${PN}-${DISTRO}"
 FAKEROOTCMD ?= "${ISARROOT}/scripts/wic_fakeroot"
 RECIPE_SYSROOT_NATIVE ?= "/"
+BUILDCHROOT_DIR = "${BUILDCHROOT_TARGET_DIR}"
 
 do_wic_image[stamp-extra-info] = "${DISTRO}-${MACHINE}"
 
@@ -73,6 +74,6 @@ do_wic_image() {
     cp -f `ls -t -1 ${BUILDCHROOT_DIR}/tmp/${WKS_FILE}*.direct | head -1` ${WIC_IMAGE_FILE}
 }
 
-do_wic_image[depends] = "buildchroot:do_build"
+do_wic_image[depends] = "buildchroot-target:do_build"
 
 addtask wic_image before do_build after do_copy_boot_files
diff --git a/meta/conf/isar-bitbake.conf b/meta/conf/isar-bitbake.conf
index ead7798..aaba96e 100644
--- a/meta/conf/isar-bitbake.conf
+++ b/meta/conf/isar-bitbake.conf
@@ -21,7 +21,7 @@
 WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PF}"
 DL_DIR = "${TOPDIR}/downloads"
 SSTATE_DIR ?= "${TMPDIR}/sstate-cache"
-BUILDCHROOT_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/buildchroot/rootfs"
+BUILDCHROOT_TARGET_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/buildchroot-target/rootfs"
 CACHE = "${TMPDIR}/cache"
 
 OVERRIDES_append = ":${DISTRO}:${DISTRO_ARCH}"
diff --git a/meta/recipes-devtools/buildchroot/buildchroot-target.bb b/meta/recipes-devtools/buildchroot/buildchroot-target.bb
new file mode 100644
index 0000000..66b526a
--- /dev/null
+++ b/meta/recipes-devtools/buildchroot/buildchroot-target.bb
@@ -0,0 +1,54 @@
+# Root filesystem for packages building
+#
+# This software is a part of ISAR.
+# Copyright (C) 2015-2018 ilbers GmbH
+
+DESCRIPTION = "Isar development filesystem for target"
+
+include buildchroot.inc
+
+BUILDCHROOT_PREINSTALL ?= "gcc \
+                           make \
+                           build-essential \
+                           debhelper \
+                           autotools-dev \
+                           dpkg \
+                           locales \
+                           docbook-to-man \
+                           apt \
+                           automake \
+                           devscripts \
+                           equivs"
+
+BUILDCHROOT_PREINSTALL_WIC = " \
+                             parted \
+                             gdisk \
+                             util-linux \
+                             dosfstools \
+                             mtools \
+                             e2fsprogs \
+                             python3"
+
+BUILDCHROOT_PREINSTALL_WIC_append_amd64 = " \
+                             syslinux \
+                             syslinux-common \
+                             grub-efi-amd64-bin"
+
+BUILDCHROOT_PREINSTALL_WIC_append_armhf = " \
+                             grub-efi-arm-bin"
+
+BUILDCHROOT_PREINSTALL_WIC_append_arm64 = " \
+                             grub-efi-arm64-bin"
+
+BUILDCHROOT_PREINSTALL_WIC_append_i386 = " \
+                             syslinux \
+                             syslinux-common \
+                             grub-efi-ia32-bin"
+
+python () {
+    if d.getVar('IMAGE_TYPE', True) == 'wic-img':
+        d.appendVar('BUILDCHROOT_PREINSTALL',
+                    d.getVar('BUILDCHROOT_PREINSTALL_WIC', True))
+}
+
+do_build[depends] = "isar-apt:do_cache_config isar-bootstrap-target:do_bootstrap"
diff --git a/meta/recipes-devtools/buildchroot/buildchroot.bb b/meta/recipes-devtools/buildchroot/buildchroot.bb
deleted file mode 100644
index 7ad24f1..0000000
--- a/meta/recipes-devtools/buildchroot/buildchroot.bb
+++ /dev/null
@@ -1,83 +0,0 @@
-# Root filesystem for packages building
-#
-# This software is a part of ISAR.
-# Copyright (C) 2015-2016 ilbers GmbH
-
-DESCRIPTION = "Isar development filesystem"
-
-LICENSE = "gpl-2.0"
-LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
-
-FILESPATH_prepend := "${THISDIR}/files:"
-SRC_URI = "file://configscript.sh \
-           file://build.sh"
-PV = "1.0"
-
-inherit isar-bootstrap-helper
-
-BUILDCHROOT_PREINSTALL ?= "gcc \
-                           make \
-                           build-essential \
-                           debhelper \
-                           autotools-dev \
-                           dpkg \
-                           locales \
-                           docbook-to-man \
-                           apt \
-                           automake \
-                           devscripts \
-                           equivs"
-
-BUILDCHROOT_PREINSTALL_WIC = " \
-                             parted \
-                             gdisk \
-                             util-linux \
-                             dosfstools \
-                             mtools \
-                             e2fsprogs \
-                             python3"
-
-BUILDCHROOT_PREINSTALL_WIC_append_amd64 = " \
-                             syslinux \
-                             syslinux-common \
-                             grub-efi-amd64-bin"
-
-BUILDCHROOT_PREINSTALL_WIC_append_armhf = " \
-                             grub-efi-arm-bin"
-
-BUILDCHROOT_PREINSTALL_WIC_append_arm64 = " \
-                             grub-efi-arm64-bin"
-
-BUILDCHROOT_PREINSTALL_WIC_append_i386 = " \
-                             syslinux \
-                             syslinux-common \
-                             grub-efi-ia32-bin"
-
-python () {
-    if d.getVar('IMAGE_TYPE', True) == 'wic-img':
-        d.appendVar('BUILDCHROOT_PREINSTALL',
-                    d.getVar('BUILDCHROOT_PREINSTALL_WIC', True))
-}
-
-WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
-
-do_build[stamp-extra-info] = "${DISTRO}-${DISTRO_ARCH}"
-do_build[root_cleandirs] = "${BUILDCHROOT_DIR} \
-                            ${BUILDCHROOT_DIR}/isar-apt \
-                            ${BUILDCHROOT_DIR}/downloads \
-                            ${BUILDCHROOT_DIR}/home/builder"
-do_build[depends] = "isar-apt:do_cache_config isar-bootstrap-target:do_bootstrap"
-
-do_build() {
-    setup_root_file_system "${BUILDCHROOT_DIR}" ${BUILDCHROOT_PREINSTALL}
-
-    # Install package builder script
-    sudo chmod -R a+rw "${BUILDCHROOT_DIR}/home/builder"
-    sudo install -m 755 ${WORKDIR}/build.sh ${BUILDCHROOT_DIR}
-
-    # Configure root filesystem
-    sudo install -m 755 ${WORKDIR}/configscript.sh ${BUILDCHROOT_DIR}
-    sudo chroot ${BUILDCHROOT_DIR} /configscript.sh
-
-    sudo mount --bind ${DL_DIR} ${BUILDCHROOT_DIR}/downloads
-}
diff --git a/meta/recipes-devtools/buildchroot/buildchroot.inc b/meta/recipes-devtools/buildchroot/buildchroot.inc
new file mode 100644
index 0000000..43e3cd6
--- /dev/null
+++ b/meta/recipes-devtools/buildchroot/buildchroot.inc
@@ -0,0 +1,37 @@
+# Common part for build chroot filesystem.
+#
+# This software is a part of ISAR.
+# Copyright (C) 2015-2018 ilbers GmbH
+
+LICENSE = "gpl-2.0"
+LIC_FILES_CHKSUM = "file://${LAYERDIR_isar}/licenses/COPYING.GPLv2;md5=751419260aa954499f7abaabaa882bbe"
+
+FILESPATH_prepend := "${THISDIR}/files:"
+SRC_URI = "file://configscript.sh \
+           file://build.sh"
+PV = "1.0"
+
+inherit isar-bootstrap-helper
+
+WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}"
+BUILDCHROOT_DIR = "${WORKDIR}/rootfs"
+
+do_build[stamp-extra-info] = "${DISTRO}-${DISTRO_ARCH}"
+do_build[root_cleandirs] = "${BUILDCHROOT_DIR} \
+                            ${BUILDCHROOT_DIR}/isar-apt \
+                            ${BUILDCHROOT_DIR}/downloads \
+                            ${BUILDCHROOT_DIR}/home/builder"
+
+do_build() {
+    setup_root_file_system ${PARAMS} ${BUILDCHROOT_DIR} ${BUILDCHROOT_PREINSTALL}
+
+    # Install package builder script
+    sudo chmod -R a+rw "${BUILDCHROOT_DIR}/home/builder"
+    sudo install -m 755 ${WORKDIR}/build.sh ${BUILDCHROOT_DIR}
+
+    # Configure root filesystem
+    sudo install -m 755 ${WORKDIR}/configscript.sh ${BUILDCHROOT_DIR}
+    sudo chroot ${BUILDCHROOT_DIR} /configscript.sh
+
+    sudo mount --bind ${DL_DIR} ${BUILDCHROOT_DIR}/downloads
+}
-- 
2.1.4

[PATCH v3 3/7] buildchroot: Add host buildchroot

[Alexander Smirnov]

Add buildchroot for host architecture.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/conf/isar-bitbake.conf                        |  1 +
 .../buildchroot/buildchroot-host.bb                | 31 ++++++++++++++++++++++
 2 files changed, 32 insertions(+)
 create mode 100644 meta/recipes-devtools/buildchroot/buildchroot-host.bb

diff --git a/meta/conf/isar-bitbake.conf b/meta/conf/isar-bitbake.conf
index aaba96e..666c4a3 100644
--- a/meta/conf/isar-bitbake.conf
+++ b/meta/conf/isar-bitbake.conf
@@ -21,6 +21,7 @@
 WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PF}"
 DL_DIR = "${TOPDIR}/downloads"
 SSTATE_DIR ?= "${TMPDIR}/sstate-cache"
+BUILDCHROOT_HOST_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/buildchroot-host/rootfs"
 BUILDCHROOT_TARGET_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/buildchroot-target/rootfs"
 CACHE = "${TMPDIR}/cache"
 
diff --git a/meta/recipes-devtools/buildchroot/buildchroot-host.bb b/meta/recipes-devtools/buildchroot/buildchroot-host.bb
new file mode 100644
index 0000000..20b1e79
--- /dev/null
+++ b/meta/recipes-devtools/buildchroot/buildchroot-host.bb
@@ -0,0 +1,31 @@
+# Root filesystem for packages building
+#
+# This software is a part of ISAR.
+# Copyright (C) 2015-2018 ilbers GmbH
+
+DESCRIPTION = "Isar development filesystem for host"
+
+include buildchroot.inc
+
+BUILDCHROOT_PREINSTALL ?= "make \
+                           debhelper \
+                           autotools-dev \
+                           dpkg \
+                           locales \
+                           docbook-to-man \
+                           apt \
+                           automake \
+                           devscripts \
+                           equivs \
+                           libc6:${DISTRO_ARCH}"
+
+# Please note: this works for Stretch distro only. According to the wiki page:
+#     https://wiki.debian.org/CrossToolchains
+# Jessie doesn't contain toolchain. It should be fetched from the external
+# repository:
+#     http://emdebian.org/tools/debian/
+BUILDCHROOT_PREINSTALL_append_armhf += "binutils-arm-linux-gnueabihf \
+                                              crossbuild-essential-armhf"
+
+PARAMS = "--host-arch"
+do_build[depends] = "isar-apt:do_cache_config isar-bootstrap-host:do_bootstrap"
-- 
2.1.4

Re: [PATCH v3 3/7] buildchroot: Add host buildchroot

[Jan Kiszka]

On 2018-07-17 15:18, Alexander Smirnov wrote:
> Add buildchroot for host architecture.
> 
> Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
> ---
>  meta/conf/isar-bitbake.conf                        |  1 +
>  .../buildchroot/buildchroot-host.bb                | 31 ++++++++++++++++++++++
>  2 files changed, 32 insertions(+)
>  create mode 100644 meta/recipes-devtools/buildchroot/buildchroot-host.bb
> 
> diff --git a/meta/conf/isar-bitbake.conf b/meta/conf/isar-bitbake.conf
> index aaba96e..666c4a3 100644
> --- a/meta/conf/isar-bitbake.conf
> +++ b/meta/conf/isar-bitbake.conf
> @@ -21,6 +21,7 @@
>  WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PF}"
>  DL_DIR = "${TOPDIR}/downloads"
>  SSTATE_DIR ?= "${TMPDIR}/sstate-cache"
> +BUILDCHROOT_HOST_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/buildchroot-host/rootfs"
>  BUILDCHROOT_TARGET_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/buildchroot-target/rootfs"
>  CACHE = "${TMPDIR}/cache"
>  
> diff --git a/meta/recipes-devtools/buildchroot/buildchroot-host.bb b/meta/recipes-devtools/buildchroot/buildchroot-host.bb
> new file mode 100644
> index 0000000..20b1e79
> --- /dev/null
> +++ b/meta/recipes-devtools/buildchroot/buildchroot-host.bb
> @@ -0,0 +1,31 @@
> +# Root filesystem for packages building
> +#
> +# This software is a part of ISAR.
> +# Copyright (C) 2015-2018 ilbers GmbH
> +
> +DESCRIPTION = "Isar development filesystem for host"
> +
> +include buildchroot.inc
> +
> +BUILDCHROOT_PREINSTALL ?= "make \
> +                           debhelper \
> +                           autotools-dev \
> +                           dpkg \
> +                           locales \
> +                           docbook-to-man \
> +                           apt \
> +                           automake \
> +                           devscripts \
> +                           equivs \
> +                           libc6:${DISTRO_ARCH}"
> +
> +# Please note: this works for Stretch distro only. According to the wiki page:
> +#     https://wiki.debian.org/CrossToolchains
> +# Jessie doesn't contain toolchain. It should be fetched from the external
> +# repository:
> +#     http://emdebian.org/tools/debian/
> +BUILDCHROOT_PREINSTALL_append_armhf += "binutils-arm-linux-gnueabihf \
> +                                              crossbuild-essential-armhf"

Indention is a bit off.

Here is the ARM64 addon that builds the kernel:

diff --git a/meta/recipes-devtools/buildchroot/buildchroot-host.bb b/meta/recipes-devtools/buildchroot/buildchroot-host.bb
index 20b1e79..c8d8373 100644
--- a/meta/recipes-devtools/buildchroot/buildchroot-host.bb
+++ b/meta/recipes-devtools/buildchroot/buildchroot-host.bb
@@ -26,6 +26,8 @@ BUILDCHROOT_PREINSTALL ?= "make \
 #     http://emdebian.org/tools/debian/
 BUILDCHROOT_PREINSTALL_append_armhf += "binutils-arm-linux-gnueabihf \
                                               crossbuild-essential-armhf"
+BUILDCHROOT_PREINSTALL_append_arm64 += "binutils-aarch64-linux-gnu \
+                                        crossbuild-essential-arm64"
 
 PARAMS = "--host-arch"
 do_build[depends] = "isar-apt:do_cache_config isar-bootstrap-host:do_bootstrap"
diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh b/meta/recipes-kernel/linux/files/build-kernel.sh
index ecfbf83..ca2c7b2 100644
--- a/meta/recipes-kernel/linux/files/build-kernel.sh
+++ b/meta/recipes-kernel/linux/files/build-kernel.sh
@@ -18,6 +18,10 @@ if [ "$host_arch" != "$target_arch" ]; then
         export ARCH=arm
         export CROSS_COMPILE="arm-linux-gnueabihf-"
         ;;
+    arm64)
+        export ARCH=arm64
+        export CROSS_COMPILE="aarch64-linux-gnu-"
+        ;;
     *)
         echo "error: unsupported architecture ($target_arch)"
         exit 1

> +
> +PARAMS = "--host-arch"
> +do_build[depends] = "isar-apt:do_cache_config isar-bootstrap-host:do_bootstrap"
> 

Jan

[PATCH v3 4/7] isar-bootstrap-helper: Add target architecture for dpkg

[Alexander Smirnov]

This filesystem intended for cross-compilation, so the target
architecture should be added. Otherwise dpkg won't be able to
install dependencies.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/classes/isar-bootstrap-helper.bbclass | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/isar-bootstrap-helper.bbclass b/meta/classes/isar-bootstrap-helper.bbclass
index 3faee7c..d45cdd7 100644
--- a/meta/classes/isar-bootstrap-helper.bbclass
+++ b/meta/classes/isar-bootstrap-helper.bbclass
@@ -111,6 +111,11 @@ setup_root_file_system() {
         -o Dir::Etc::sourcelist="sources.list.d/isar-apt.list" \
         -o Dir::Etc::sourceparts="-" \
         -o APT::Get::List-Cleanup="0"
+    # Add multiarch for cross-target
+    if [ "${ROOTFS_ARCH}" != "${DISTRO_ARCH}" ]; then
+        sudo -E chroot "$ROOTFSDIR" /usr/bin/dpkg --add-architecture ${DISTRO_ARCH}
+        sudo -E chroot "$ROOTFSDIR" /usr/bin/apt-get update
+    fi
     sudo -E chroot "$ROOTFSDIR" \
         /usr/bin/apt-get ${APT_ARGS} --download-only $PACKAGES \
             ${IMAGE_TRANSIENT_PACKAGES}
-- 
2.1.4

[PATCH v3 5/7] build.sh: Add additional parameter

[Alexander Smirnov]

Pass target architecture as a parameter for build.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/recipes-devtools/buildchroot/files/build.sh | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/buildchroot/files/build.sh b/meta/recipes-devtools/buildchroot/files/build.sh
index 73c0889..40ba410 100644
--- a/meta/recipes-devtools/buildchroot/files/build.sh
+++ b/meta/recipes-devtools/buildchroot/files/build.sh
@@ -6,6 +6,19 @@
 
 set -e
 
+# Create human-readable names
+target_arch=$2
+
+# Notes:
+#   mk-build-deps for jessie and jtretch has different parameter name to specify
+#   host architecture.
+debian_version=$(cat /etc/debian_version | cut -c 1)
+if [ $(($debian_version)) -ge 9 ]; then
+    set_arch="--host-arch $target_arch"
+else
+    set_arch="-a $target_arch"
+fi
+
 # Go to build directory
 cd $1
 
@@ -36,7 +49,7 @@ install_cmd="apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -y
         -o APT::Get::List-Cleanup="0"
 
     # Install all build deps
-    mk-build-deps -t "${install_cmd}" -i -r debian/control
+    mk-build-deps $set_arch -t "${install_cmd}" -i -r debian/control
 ) 42>/dpkg.lock
 
 # If autotools files have been created, update their timestamp to
@@ -48,4 +61,4 @@ for i in configure aclocal.m4 Makefile.am Makefile.in; do
 done
 
 # Build the package
-dpkg-buildpackage
+dpkg-buildpackage -a$target_arch
-- 
2.1.4

[PATCH v3 6/7] cross-compilation: Introduce variable switch

[Alexander Smirnov]

Add variable to switch from native to cross compilation.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta-isar/conf/local.conf.sample            |  5 +++++
 meta/classes/dpkg-base.bbclass              | 19 ++++++++++++++++---
 meta/classes/dpkg-raw.bbclass               |  1 -
 meta/classes/dpkg.bbclass                   |  4 +---
 meta/recipes-kernel/linux-module/module.inc |  7 +++++++
 meta/recipes-kernel/linux/linux-custom.inc  |  2 ++
 6 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/meta-isar/conf/local.conf.sample b/meta-isar/conf/local.conf.sample
index 16ef488..27b43d1 100644
--- a/meta-isar/conf/local.conf.sample
+++ b/meta-isar/conf/local.conf.sample
@@ -156,3 +156,8 @@ CONF_VERSION = "1"
 #
 # The default list of extra packages to be installed.
 IMAGE_INSTALL = "example-hello example-raw example-module"
+
+#
+# Enable cross-compilation support
+# NOTE: this works only for stretch-armhf and stretch-amd64 targets for now.
+ISAR_CROSS_COMPILE ?= "0"
diff --git a/meta/classes/dpkg-base.bbclass b/meta/classes/dpkg-base.bbclass
index 3234234..674c0b5 100644
--- a/meta/classes/dpkg-base.bbclass
+++ b/meta/classes/dpkg-base.bbclass
@@ -1,6 +1,22 @@
 # This software is a part of ISAR.
 # Copyright (C) 2017 Siemens AG
 
+ISAR_CROSS_COMPILE ??= "0"
+
+# Add dependency from the correct buildchroot: host or target
+python __anonymous() {
+    mode = d.getVar('ISAR_CROSS_COMPILE', True)
+    if mode == "0":
+        dep = "buildchroot-target:do_build"
+        rootfs = d.getVar('BUILDCHROOT_TARGET_DIR', True)
+    else:
+        dep = "buildchroot-host:do_build"
+        rootfs = d.getVar('BUILDCHROOT_HOST_DIR', True)
+
+    d.setVarFlag('do_build', 'depends', dep)
+    d.setVar('BUILDCHROOT_DIR', rootfs)
+}
+
 do_adjust_git() {
     if [ -f ${S}/.git/objects/info/alternates ]; then
         sed -i ${S}/.git/objects/info/alternates \
@@ -14,9 +30,6 @@ do_adjust_git[stamp-extra-info] = "${DISTRO}-${DISTRO_ARCH}"
 inherit patch
 addtask patch after do_adjust_git before do_build
 
-# Add dependency from buildchroot creation
-do_build[depends] = "buildchroot-target:do_build"
-
 # Add dependency between Isar recipes
 DEPENDS ?= ""
 do_build[deptask] = "do_deploy_deb"
diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
index 2f23eb7..28233ac 100644
--- a/meta/classes/dpkg-raw.bbclass
+++ b/meta/classes/dpkg-raw.bbclass
@@ -7,7 +7,6 @@ DEBIAN_DEPENDS ?= ""
 MAINTAINER ?= "FIXME Unknown maintainer"
 
 D = "${WORKDIR}/image/"
-BUILDCHROOT_DIR = "${BUILDCHROOT_TARGET_DIR}"
 
 # Populate folder that will be picked up as package
 do_install() {
diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
index 563b63c..ab70645 100644
--- a/meta/classes/dpkg.bbclass
+++ b/meta/classes/dpkg.bbclass
@@ -3,10 +3,8 @@
 
 inherit dpkg-base
 
-BUILDCHROOT_DIR = "${BUILDCHROOT_TARGET_DIR}"
-
 # Build package from sources using build script
 dpkg_runbuild() {
     E="${@ bb.utils.export_proxies(d)}"
-    sudo -E chroot ${BUILDCHROOT_DIR} /build.sh ${PP}/${PPS}
+    sudo -E chroot ${BUILDCHROOT_DIR} /build.sh ${PP}/${PPS} ${DISTRO_ARCH}
 }
diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index 3075f44..aeccfba 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -15,6 +15,13 @@ SRC_URI += "file://debian/"
 
 AUTOLOAD ?= "0"
 
+# Cross-compilation is not supported for default Debian kernels.
+# For example, package with kernel headers for ARM:
+#   linux-headers-armmp
+# has hard dependencies from linux-compiler-gcc-4.8-arm, what
+# conflicts with the host binaries.
+ISAR_CROSS_COMPILE := "0"
+
 inherit dpkg
 
 dpkg_runbuild_prepend() {
diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index 1176b25..f7641ef 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -20,6 +20,8 @@ python() {
                              'linux-headers-' + kernel)
 }
 
+ISAR_CROSS_COMPILE = "0"
+
 inherit dpkg-base
 
 SRC_URI += "file://build-kernel.sh"
-- 
2.1.4

[PATCH v3 7/7] linux: Add cross-compilation support

[Alexander Smirnov]

Add possibility to cross-compile ARM target.

Signed-off-by: Alexander Smirnov <asmirnov@ilbers.de>
---
 meta/recipes-kernel/linux/files/build-kernel.sh | 16 ++++++++++++++++
 meta/recipes-kernel/linux/linux-custom.inc      |  4 +---
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh b/meta/recipes-kernel/linux/files/build-kernel.sh
index 1ec094e..ecfbf83 100644
--- a/meta/recipes-kernel/linux/files/build-kernel.sh
+++ b/meta/recipes-kernel/linux/files/build-kernel.sh
@@ -9,6 +9,22 @@
 
 set -e
 
+host_arch=$(dpkg --print-architecture)
+target_arch=$2
+
+if [ "$host_arch" != "$target_arch" ]; then
+    case $target_arch in
+    armhf)
+        export ARCH=arm
+        export CROSS_COMPILE="arm-linux-gnueabihf-"
+        ;;
+    *)
+        echo "error: unsupported architecture ($target_arch)"
+        exit 1
+        ;;
+    esac
+fi
+
 REPACK_DIR="$1/../repack"
 REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image"
 REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers"
diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index f7641ef..d5fc5a6 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -20,8 +20,6 @@ python() {
                              'linux-headers-' + kernel)
 }
 
-ISAR_CROSS_COMPILE = "0"
-
 inherit dpkg-base
 
 SRC_URI += "file://build-kernel.sh"
@@ -45,5 +43,5 @@ dpkg_runbuild() {
 	export KERNEL_DEBIAN_DEPENDS="${KERNEL_DEBIAN_DEPENDS}"
 	export KERNEL_HEADERS_DEBIAN_DEPENDS="${KERNEL_HEADERS_DEBIAN_DEPENDS}"
 
-	sudo -E chroot ${BUILDCHROOT_DIR} /build-kernel.sh ${PP}/${PPS}
+	sudo -E chroot ${BUILDCHROOT_DIR} /build-kernel.sh ${PP}/${PPS} ${DISTRO_ARCH}
 }
-- 
2.1.4

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-17 15:18, Alexander Smirnov wrote:
> Hi everybody,
> 
> sorry for the delay, this is the third version of cross-compilation
> support for Isar.
> 

Thanks for the update!

> Supported targets for cross-compilation:
>  - stretch armhf
>  - stretch amd64
> 
> Artifacts could be cross-compiled:
>  - dpkg.bbclass users
>  - dpkg-raw.bbclass users
>  - kernel
> 
> Known issues:
>  - if target and host architectures are the same, there is no need
>    to use host buildchroot.
>  - kernel module doesn't support cross-compilation. Default linux-headers
>    package depends from target gcc binaries. So attempt to install, for
>    example linux-headers-armmp, tries to install gcc:armhf, what rises
>    conflict with the host tools.

Could you imagine overriding such specialties with extra rules, even if
package specific? Not having kernel module in the cross compilation
chain main cause troubles (or does it work fine to cross-build the
kernel and then natively build the modules?).

> 
> To enable cross-compilation, the variable ISAR_CROSS_COMPILE should be set
> to "1" in local.conf file.

I will retry that series soon, on my standard testcase jailhouse-images.
It's growing and urgently needs an accelerator :).

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-17 15:38, [ext] Jan Kiszka wrote:
> On 2018-07-17 15:18, Alexander Smirnov wrote:
>> Hi everybody,
>>
>> sorry for the delay, this is the third version of cross-compilation
>> support for Isar.
>>
> 
> Thanks for the update!
> 
>> Supported targets for cross-compilation:
>>  - stretch armhf
>>  - stretch amd64
>>
>> Artifacts could be cross-compiled:
>>  - dpkg.bbclass users
>>  - dpkg-raw.bbclass users
>>  - kernel
>>
>> Known issues:
>>  - if target and host architectures are the same, there is no need
>>    to use host buildchroot.
>>  - kernel module doesn't support cross-compilation. Default linux-headers
>>    package depends from target gcc binaries. So attempt to install, for
>>    example linux-headers-armmp, tries to install gcc:armhf, what rises
>>    conflict with the host tools.
> 
> Could you imagine overriding such specialties with extra rules, even if
> package specific? Not having kernel module in the cross compilation
> chain main cause troubles (or does it work fine to cross-build the
> kernel and then natively build the modules?).
> 
>>
>> To enable cross-compilation, the variable ISAR_CROSS_COMPILE should be set
>> to "1" in local.conf file.
> 
> I will retry that series soon, on my standard testcase jailhouse-images.
> It's growing and urgently needs an accelerator :).
> 

What's the baseline of these patches, master? Why not using next?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

On 07/17/2018 05:40 PM, Jan Kiszka wrote:
> On 2018-07-17 15:38, [ext] Jan Kiszka wrote:
>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>> Hi everybody,
>>>
>>> sorry for the delay, this is the third version of cross-compilation
>>> support for Isar.
>>>
>>
>> Thanks for the update!
>>
>>> Supported targets for cross-compilation:
>>>   - stretch armhf
>>>   - stretch amd64
>>>
>>> Artifacts could be cross-compiled:
>>>   - dpkg.bbclass users
>>>   - dpkg-raw.bbclass users
>>>   - kernel
>>>
>>> Known issues:
>>>   - if target and host architectures are the same, there is no need
>>>     to use host buildchroot.
>>>   - kernel module doesn't support cross-compilation. Default linux-headers
>>>     package depends from target gcc binaries. So attempt to install, for
>>>     example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>     conflict with the host tools.
>>
>> Could you imagine overriding such specialties with extra rules, even if
>> package specific? Not having kernel module in the cross compilation
>> chain main cause troubles (or does it work fine to cross-build the
>> kernel and then natively build the modules?).
>>
>>>
>>> To enable cross-compilation, the variable ISAR_CROSS_COMPILE should be set
>>> to "1" in local.conf file.
>>
>> I will retry that series soon, on my standard testcase jailhouse-images.
>> It's growing and urgently needs an accelerator :).
>>
> 
> What's the baseline of these patches, master? Why not using next?
> 

mosipov-devel to avoid additional rebase, let me check.

Alex

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

On 07/17/2018 06:06 PM, Alexander Smirnov wrote:
> On 07/17/2018 05:40 PM, Jan Kiszka wrote:
>> On 2018-07-17 15:38, [ext] Jan Kiszka wrote:
>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>> Hi everybody,
>>>>
>>>> sorry for the delay, this is the third version of cross-compilation
>>>> support for Isar.
>>>>
>>>
>>> Thanks for the update!
>>>
>>>> Supported targets for cross-compilation:
>>>>   - stretch armhf
>>>>   - stretch amd64
>>>>
>>>> Artifacts could be cross-compiled:
>>>>   - dpkg.bbclass users
>>>>   - dpkg-raw.bbclass users
>>>>   - kernel
>>>>
>>>> Known issues:
>>>>   - if target and host architectures are the same, there is no need
>>>>     to use host buildchroot.
>>>>   - kernel module doesn't support cross-compilation. Default 
>>>> linux-headers
>>>>     package depends from target gcc binaries. So attempt to install, 
>>>> for
>>>>     example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>>     conflict with the host tools.
>>>
>>> Could you imagine overriding such specialties with extra rules, even if
>>> package specific? Not having kernel module in the cross compilation
>>> chain main cause troubles (or does it work fine to cross-build the
>>> kernel and then natively build the modules?).
>>>
>>>>
>>>> To enable cross-compilation, the variable ISAR_CROSS_COMPILE should 
>>>> be set
>>>> to "1" in local.conf file.
>>>
>>> I will retry that series soon, on my standard testcase jailhouse-images.
>>> It's growing and urgently needs an accelerator :).
>>>
>>
>> What's the baseline of these patches, master? Why not using next?
>>
> 
> mosipov-devel to avoid additional rebase, let me check.
> 

Sorry, mosipov-next.

Alex

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-17 17:18, Alexander Smirnov wrote:
> 
> 
> On 07/17/2018 06:06 PM, Alexander Smirnov wrote:
>> On 07/17/2018 05:40 PM, Jan Kiszka wrote:
>>> On 2018-07-17 15:38, [ext] Jan Kiszka wrote:
>>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>>> Hi everybody,
>>>>>
>>>>> sorry for the delay, this is the third version of cross-compilation
>>>>> support for Isar.
>>>>>
>>>>
>>>> Thanks for the update!
>>>>
>>>>> Supported targets for cross-compilation:
>>>>>   - stretch armhf
>>>>>   - stretch amd64
>>>>>
>>>>> Artifacts could be cross-compiled:
>>>>>   - dpkg.bbclass users
>>>>>   - dpkg-raw.bbclass users
>>>>>   - kernel
>>>>>
>>>>> Known issues:
>>>>>   - if target and host architectures are the same, there is no need
>>>>>     to use host buildchroot.
>>>>>   - kernel module doesn't support cross-compilation. Default
>>>>> linux-headers
>>>>>     package depends from target gcc binaries. So attempt to
>>>>> install, for
>>>>>     example linux-headers-armmp, tries to install gcc:armhf, what
>>>>> rises
>>>>>     conflict with the host tools.
>>>>
>>>> Could you imagine overriding such specialties with extra rules, even if
>>>> package specific? Not having kernel module in the cross compilation
>>>> chain main cause troubles (or does it work fine to cross-build the
>>>> kernel and then natively build the modules?).
>>>>
>>>>>
>>>>> To enable cross-compilation, the variable ISAR_CROSS_COMPILE should
>>>>> be set
>>>>> to "1" in local.conf file.
>>>>
>>>> I will retry that series soon, on my standard testcase
>>>> jailhouse-images.
>>>> It's growing and urgently needs an accelerator :).
>>>>
>>>
>>> What's the baseline of these patches, master? Why not using next?
>>>
>>
>> mosipov-devel to avoid additional rebase, let me check.
>>
> 
> Sorry, mosipov-next.
> 

Yes, that works fine. Would have been good to note this.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

>> Sorry, mosipov-next.
>>
> 
> Yes, that works fine. Would have been good to note this.
> 

Fully agree, my fault, sorry for time you spent.

Alex

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

On 07/17/2018 04:38 PM, Jan Kiszka wrote:
> On 2018-07-17 15:18, Alexander Smirnov wrote:
>> Hi everybody,
>>
>> sorry for the delay, this is the third version of cross-compilation
>> support for Isar.
>>
> 
> Thanks for the update!
> 
>> Supported targets for cross-compilation:
>>   - stretch armhf
>>   - stretch amd64
>>
>> Artifacts could be cross-compiled:
>>   - dpkg.bbclass users
>>   - dpkg-raw.bbclass users
>>   - kernel
>>
>> Known issues:
>>   - if target and host architectures are the same, there is no need
>>     to use host buildchroot.
>>   - kernel module doesn't support cross-compilation. Default linux-headers
>>     package depends from target gcc binaries. So attempt to install, for
>>     example linux-headers-armmp, tries to install gcc:armhf, what rises
>>     conflict with the host tools.
> 
> Could you imagine overriding such specialties with extra rules, even if
> package specific? Not having kernel module in the cross compilation
> chain main cause troubles (or does it work fine to cross-build the
> kernel and then natively build the modules?).

What I'd like to try:
1. Add ARM defconfig for linux-cip
2. Try to build example module for linux-cip for armhf

Regarding overriding default Debian kernel, ATM I don't see any 
possibilities. Just as an exercise - I tried to install linux-headers-armmp:

$ sudo dpkg --add-architecture armhf
$ sudo apt-get update
$ sudo apt-get install linux-headers-armmp

No chances here, this package pulls lots of armhf binaries that conflict 
with the host ones. The only way I see now is to manually fetch and 
unpack this package. But it's an ugly hack IMHO :-(

Regarding hybrid mode (apps and kernel are compiled cross, modules are 
compiled natively) - this works. You could check this by trying 
cross-build for qemuarm-stretch, for example.

Alex

> 
>>
>> To enable cross-compilation, the variable ISAR_CROSS_COMPILE should be set
>> to "1" in local.conf file.
> 
> I will retry that series soon, on my standard testcase jailhouse-images.
> It's growing and urgently needs an accelerator :).
> 
> Jan
> 

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-17 17:41, Alexander Smirnov wrote:
> 
> 
> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>> Hi everybody,
>>>
>>> sorry for the delay, this is the third version of cross-compilation
>>> support for Isar.
>>>
>>
>> Thanks for the update!
>>
>>> Supported targets for cross-compilation:
>>>   - stretch armhf
>>>   - stretch amd64
>>>
>>> Artifacts could be cross-compiled:
>>>   - dpkg.bbclass users
>>>   - dpkg-raw.bbclass users
>>>   - kernel
>>>
>>> Known issues:
>>>   - if target and host architectures are the same, there is no need
>>>     to use host buildchroot.
>>>   - kernel module doesn't support cross-compilation. Default
>>> linux-headers
>>>     package depends from target gcc binaries. So attempt to install, for
>>>     example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>     conflict with the host tools.
>>
>> Could you imagine overriding such specialties with extra rules, even if
>> package specific? Not having kernel module in the cross compilation
>> chain main cause troubles (or does it work fine to cross-build the
>> kernel and then natively build the modules?).
> 
> What I'd like to try:
> 1. Add ARM defconfig for linux-cip
> 2. Try to build example module for linux-cip for armhf
> 
> Regarding overriding default Debian kernel, ATM I don't see any
> possibilities. Just as an exercise - I tried to install
> linux-headers-armmp:
> 
> $ sudo dpkg --add-architecture armhf
> $ sudo apt-get update
> $ sudo apt-get install linux-headers-armmp
> 
> No chances here, this package pulls lots of armhf binaries that conflict
> with the host ones. The only way I see now is to manually fetch and
> unpack this package. But it's an ugly hack IMHO :-(

But maybe we can resolve that issue for self-built kernel by providing
also a compatible headers package?

> 
> Regarding hybrid mode (apps and kernel are compiled cross, modules are
> compiled natively) - this works. You could check this by trying
> cross-build for qemuarm-stretch, for example.

I suppose to opt-out a package from cross-building, I need to add
ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:

| Broken jailhouse-build-deps:arm64 Depends on
linux-headers-jailhouse-arm64:arm64 < none @un H >
|   Removing jailhouse-build-deps:arm64 because I can't find
linux-headers-jailhouse-arm64:arm64

The problem seems to be that the header package is generate as :amd64,
so I can't install it into the arm64 buildchroot. However, the cross
build also fails because it searches for :arm64 as well:

| Broken jailhouse-cross-build-deps:arm64 Depends on
linux-headers-jailhouse-arm64:arm64 < none @un H >
|   Removing jailhouse-cross-build-deps:arm64 because I can't find
linux-headers-jailhouse-arm64:arm64

By requesting :amd64 versions of the header as well as some python deps,
I'm getting further and then fail differently:

| dpkg-architecture: warning: specified GNU system type
aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
setting a correct CC environment variable
|  dpkg-source --before-build git
| dpkg-buildpackage: info: host architecture arm64
| dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64
python-setuptools:amd64 python-mako:amd64

"host architecture arm64", that is suspicious...


And then python - I'm still facing that issue with another package as well:

| Setting up python2.7-minimal:arm64 (2.7.13-2+deb9u2) ...
| /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
/var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
| dpkg: error processing package python2.7-minimal:arm64 (--configure):
|  subprocess installed post-installation script returned error exit
status 127
| dpkg: dependency problems prevent configuration of python-minimal:arm64:
|  python-minimal:arm64 depends on python2.7-minimal (>= 2.7.13-1~);
however:
|   Package python2.7-minimal:arm64 is not configured yet.
|
| dpkg: error processing package python-minimal:arm64 (--configure):
|  dependency problems - leaving unconfigured
| Errors were encountered while processing:
|  python2.7-minimal:arm64
|  python-minimal:arm64
| E: Sub-process /usr/bin/dpkg returned an error code (1)

Corresponding build dependencies there:
Build-Depends: wget, cpio, unzip, rsync, python, bc

Here I get my job done by hacking it this way:
Build-Depends: wget, cpio, unzip, rsync, python:amd64, bc

Jan

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

Jan Kiszka <jan.kiszka@siemens.com> 17 июля 2018 г. 22:45:11 написал:

> On 2018-07-17 17:41, Alexander Smirnov wrote:
>>
>>
>> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>> Hi everybody,
>>>>
>>>> sorry for the delay, this is the third version of cross-compilation
>>>> support for Isar.
>>>
>>> Thanks for the update!
>>>
>>>> Supported targets for cross-compilation:
>>>>  - stretch armhf
>>>>  - stretch amd64
>>>>
>>>> Artifacts could be cross-compiled:
>>>>  - dpkg.bbclass users
>>>>  - dpkg-raw.bbclass users
>>>>  - kernel
>>>>
>>>> Known issues:
>>>>  - if target and host architectures are the same, there is no need
>>>>    to use host buildchroot.
>>>>  - kernel module doesn't support cross-compilation. Default
>>>> linux-headers
>>>>    package depends from target gcc binaries. So attempt to install, for
>>>>    example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>>    conflict with the host tools.
>>>
>>> Could you imagine overriding such specialties with extra rules, even if
>>> package specific? Not having kernel module in the cross compilation
>>> chain main cause troubles (or does it work fine to cross-build the
>>> kernel and then natively build the modules?).
>>
>> What I'd like to try:
>> 1. Add ARM defconfig for linux-cip
>> 2. Try to build example module for linux-cip for armhf
>>
>> Regarding overriding default Debian kernel, ATM I don't see any
>> possibilities. Just as an exercise - I tried to install
>> linux-headers-armmp:
>>
>> $ sudo dpkg --add-architecture armhf
>> $ sudo apt-get update
>> $ sudo apt-get install linux-headers-armmp
>>
>> No chances here, this package pulls lots of armhf binaries that conflict
>> with the host ones. The only way I see now is to manually fetch and
>> unpack this package. But it's an ugly hack IMHO :-(
>
> But maybe we can resolve that issue for self-built kernel by providing
> also a compatible headers package?


I need to investigate this topic in more details.

>
>
>>
>> Regarding hybrid mode (apps and kernel are compiled cross, modules are
>> compiled natively) - this works. You could check this by trying
>> cross-build for qemuarm-stretch, for example.
>
> I suppose to opt-out a package from cross-building, I need to add
> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:

Hmm, actually it should. That's how I disable cross-comp for kernel 
modules. Could you try more strength assignment := ?

>
> | Broken jailhouse-build-deps:arm64 Depends on
> linux-headers-jailhouse-arm64:arm64 < none @un H >
> |   Removing jailhouse-build-deps:arm64 because I can't find
> linux-headers-jailhouse-arm64:arm64
>
> The problem seems to be that the header package is generate as :amd64,
> so I can't install it into the arm64 buildchroot. However, the cross
> build also fails because it searches for :arm64 as well:
>
> | Broken jailhouse-cross-build-deps:arm64 Depends on
> linux-headers-jailhouse-arm64:arm64 < none @un H >
> |   Removing jailhouse-cross-build-deps:arm64 because I can't find
> linux-headers-jailhouse-arm64:arm64
>
> By requesting :amd64 versions of the header as well as some python deps,
> I'm getting further and then fail differently:
>
> | dpkg-architecture: warning: specified GNU system type
> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
> setting a correct CC environment variable
> |  dpkg-source --before-build git
> | dpkg-buildpackage: info: host architecture arm64
> | dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64
> python-setuptools:amd64 python-mako:amd64
>
> "host architecture arm64", that is suspicious...
>
>
> And then python - I'm still facing that issue with another package as well:
>
> | Setting up python2.7-minimal:arm64 (2.7.13-2+deb9u2) ...
> | /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
> | dpkg: error processing package python2.7-minimal:arm64 (--configure):
> |  subprocess installed post-installation script returned error exit
> status 127
> | dpkg: dependency problems prevent configuration of python-minimal:arm64:
> |  python-minimal:arm64 depends on python2.7-minimal (>= 2.7.13-1~);
> however:
> |   Package python2.7-minimal:arm64 is not configured yet.
> |
> | dpkg: error processing package python-minimal:arm64 (--configure):
> |  dependency problems - leaving unconfigured
> | Errors were encountered while processing:
> |  python2.7-minimal:arm64
> |  python-minimal:arm64
> | E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> Corresponding build dependencies there:
> Build-Depends: wget, cpio, unzip, rsync, python, bc
>
> Here I get my job done by hacking it this way:
> Build-Depends: wget, cpio, unzip, rsync, python:amd64, bc

Is it possible to reproduce these results on my machine? I.e. are these 
artifacts available in public? In my series I only guarantee that isar tree 
is buildable, but unfortunately it doesn't cover all the possible cases. 
:-( As mention above, we definetely need to add ARM kernel configs to 
meta-isar to test real cross-compilation out of the box.

Alex

>
> Jan
>
> --
> You received this message because you are subscribed to the Google Groups 
> "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to isar-users+unsubscribe@googlegroups.com.
> To post to this group, send email to isar-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/isar-users/1ed1ad84-acaf-1aa9-0ac7-f2f1353670ab%40siemens.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-17 22:48, Alexander Smirnov wrote:
> 
> Jan Kiszka <jan.kiszka@siemens.com> 17 июля 2018 г. 22:45:11 написал:
> 
>> On 2018-07-17 17:41, Alexander Smirnov wrote:
>>>
>>>
>>> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>>> Hi everybody,
>>>>>
>>>>> sorry for the delay, this is the third version of cross-compilation
>>>>> support for Isar.
>>>>
>>>> Thanks for the update!
>>>>
>>>>> Supported targets for cross-compilation:
>>>>>  - stretch armhf
>>>>>  - stretch amd64
>>>>>
>>>>> Artifacts could be cross-compiled:
>>>>>  - dpkg.bbclass users
>>>>>  - dpkg-raw.bbclass users
>>>>>  - kernel
>>>>>
>>>>> Known issues:
>>>>>  - if target and host architectures are the same, there is no need
>>>>>    to use host buildchroot.
>>>>>  - kernel module doesn't support cross-compilation. Default
>>>>> linux-headers
>>>>>    package depends from target gcc binaries. So attempt to install,
>>>>> for
>>>>>    example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>>>    conflict with the host tools.
>>>>
>>>> Could you imagine overriding such specialties with extra rules, even if
>>>> package specific? Not having kernel module in the cross compilation
>>>> chain main cause troubles (or does it work fine to cross-build the
>>>> kernel and then natively build the modules?).
>>>
>>> What I'd like to try:
>>> 1. Add ARM defconfig for linux-cip
>>> 2. Try to build example module for linux-cip for armhf
>>>
>>> Regarding overriding default Debian kernel, ATM I don't see any
>>> possibilities. Just as an exercise - I tried to install
>>> linux-headers-armmp:
>>>
>>> $ sudo dpkg --add-architecture armhf
>>> $ sudo apt-get update
>>> $ sudo apt-get install linux-headers-armmp
>>>
>>> No chances here, this package pulls lots of armhf binaries that conflict
>>> with the host ones. The only way I see now is to manually fetch and
>>> unpack this package. But it's an ugly hack IMHO :-(
>>
>> But maybe we can resolve that issue for self-built kernel by providing
>> also a compatible headers package?
> 
> 
> I need to investigate this topic in more details.
> 
>>
>>
>>>
>>> Regarding hybrid mode (apps and kernel are compiled cross, modules are
>>> compiled natively) - this works. You could check this by trying
>>> cross-build for qemuarm-stretch, for example.
>>
>> I suppose to opt-out a package from cross-building, I need to add
>> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:
> 
> Hmm, actually it should. That's how I disable cross-comp for kernel
> modules. Could you try more strength assignment := ?
> 
>>
>> | Broken jailhouse-build-deps:arm64 Depends on
>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>> |   Removing jailhouse-build-deps:arm64 because I can't find
>> linux-headers-jailhouse-arm64:arm64
>>
>> The problem seems to be that the header package is generate as :amd64,
>> so I can't install it into the arm64 buildchroot. However, the cross
>> build also fails because it searches for :arm64 as well:
>>
>> | Broken jailhouse-cross-build-deps:arm64 Depends on
>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>> |   Removing jailhouse-cross-build-deps:arm64 because I can't find
>> linux-headers-jailhouse-arm64:arm64
>>
>> By requesting :amd64 versions of the header as well as some python deps,
>> I'm getting further and then fail differently:
>>
>> | dpkg-architecture: warning: specified GNU system type
>> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
>> setting a correct CC environment variable
>> |  dpkg-source --before-build git
>> | dpkg-buildpackage: info: host architecture arm64
>> | dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64
>> python-setuptools:amd64 python-mako:amd64
>>
>> "host architecture arm64", that is suspicious...
>>
>>
>> And then python - I'm still facing that issue with another package as
>> well:
>>
>> | Setting up python2.7-minimal:arm64 (2.7.13-2+deb9u2) ...
>> | /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
>> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
>> | dpkg: error processing package python2.7-minimal:arm64 (--configure):
>> |  subprocess installed post-installation script returned error exit
>> status 127
>> | dpkg: dependency problems prevent configuration of
>> python-minimal:arm64:
>> |  python-minimal:arm64 depends on python2.7-minimal (>= 2.7.13-1~);
>> however:
>> |   Package python2.7-minimal:arm64 is not configured yet.
>> |
>> | dpkg: error processing package python-minimal:arm64 (--configure):
>> |  dependency problems - leaving unconfigured
>> | Errors were encountered while processing:
>> |  python2.7-minimal:arm64
>> |  python-minimal:arm64
>> | E: Sub-process /usr/bin/dpkg returned an error code (1)
>>
>> Corresponding build dependencies there:
>> Build-Depends: wget, cpio, unzip, rsync, python, bc
>>
>> Here I get my job done by hacking it this way:
>> Build-Depends: wget, cpio, unzip, rsync, python:amd64, bc
> 
> Is it possible to reproduce these results on my machine? I.e. are these
> artifacts available in public? In my series I only guarantee that isar
> tree is buildable, but unfortunately it doesn't cover all the possible
> cases. :-( As mention above, we definetely need to add ARM kernel
> configs to meta-isar to test real cross-compilation out of the box.

Sure: I'm testing with https://github.com/siemens/jailhouse-images,
current next branch. You may skip the length non-root-initramfs package
and also just do the Orange Pi Zero build.

We can also switch to the CIP kernel in Isar for the Banana Pi target.
Will notably prolong the CI run, though.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-18 09:06, Jan Kiszka wrote:
> On 2018-07-17 22:48, Alexander Smirnov wrote:
>>
>> Jan Kiszka <jan.kiszka@siemens.com> 17 июля 2018 г. 22:45:11 написал:
>>
>>> On 2018-07-17 17:41, Alexander Smirnov wrote:
>>>>
>>>>
>>>> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>>>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>>>> Hi everybody,
>>>>>>
>>>>>> sorry for the delay, this is the third version of cross-compilation
>>>>>> support for Isar.
>>>>>
>>>>> Thanks for the update!
>>>>>
>>>>>> Supported targets for cross-compilation:
>>>>>>  - stretch armhf
>>>>>>  - stretch amd64
>>>>>>
>>>>>> Artifacts could be cross-compiled:
>>>>>>  - dpkg.bbclass users
>>>>>>  - dpkg-raw.bbclass users
>>>>>>  - kernel
>>>>>>
>>>>>> Known issues:
>>>>>>  - if target and host architectures are the same, there is no need
>>>>>>    to use host buildchroot.
>>>>>>  - kernel module doesn't support cross-compilation. Default
>>>>>> linux-headers
>>>>>>    package depends from target gcc binaries. So attempt to install,
>>>>>> for
>>>>>>    example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>>>>    conflict with the host tools.
>>>>>
>>>>> Could you imagine overriding such specialties with extra rules, even if
>>>>> package specific? Not having kernel module in the cross compilation
>>>>> chain main cause troubles (or does it work fine to cross-build the
>>>>> kernel and then natively build the modules?).
>>>>
>>>> What I'd like to try:
>>>> 1. Add ARM defconfig for linux-cip
>>>> 2. Try to build example module for linux-cip for armhf
>>>>
>>>> Regarding overriding default Debian kernel, ATM I don't see any
>>>> possibilities. Just as an exercise - I tried to install
>>>> linux-headers-armmp:
>>>>
>>>> $ sudo dpkg --add-architecture armhf
>>>> $ sudo apt-get update
>>>> $ sudo apt-get install linux-headers-armmp
>>>>
>>>> No chances here, this package pulls lots of armhf binaries that conflict
>>>> with the host ones. The only way I see now is to manually fetch and
>>>> unpack this package. But it's an ugly hack IMHO :-(
>>>
>>> But maybe we can resolve that issue for self-built kernel by providing
>>> also a compatible headers package?
>>
>>
>> I need to investigate this topic in more details.
>>
>>>
>>>
>>>>
>>>> Regarding hybrid mode (apps and kernel are compiled cross, modules are
>>>> compiled natively) - this works. You could check this by trying
>>>> cross-build for qemuarm-stretch, for example.
>>>
>>> I suppose to opt-out a package from cross-building, I need to add
>>> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:
>>
>> Hmm, actually it should. That's how I disable cross-comp for kernel
>> modules. Could you try more strength assignment := ?
>>

Sorry, "no" was referring to the build in general. I can enforce the
opt-out via ISAR_CROSS_COMPILE = "0" successfully.

>>>
>>> | Broken jailhouse-build-deps:arm64 Depends on
>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>> |   Removing jailhouse-build-deps:arm64 because I can't find
>>> linux-headers-jailhouse-arm64:arm64
>>>
>>> The problem seems to be that the header package is generate as :amd64,
>>> so I can't install it into the arm64 buildchroot. However, the cross
>>> build also fails because it searches for :arm64 as well:
>>>
>>> | Broken jailhouse-cross-build-deps:arm64 Depends on
>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>> |   Removing jailhouse-cross-build-deps:arm64 because I can't find
>>> linux-headers-jailhouse-arm64:arm64
>>>
>>> By requesting :amd64 versions of the header as well as some python deps,
>>> I'm getting further and then fail differently:
>>>
>>> | dpkg-architecture: warning: specified GNU system type
>>> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
>>> setting a correct CC environment variable
>>> |  dpkg-source --before-build git
>>> | dpkg-buildpackage: info: host architecture arm64
>>> | dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64
>>> python-setuptools:amd64 python-mako:amd64
>>>
>>> "host architecture arm64", that is suspicious...
>>>

I'm starting to wonder if there is the wrong architecture set at some
level, which may also explain why dpdk pulls tool packages for the
target architecture, rather than the host arch. Does that ring any bell?

Jan
-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-18 10:19, Jan Kiszka wrote:
> On 2018-07-18 09:06, Jan Kiszka wrote:
>> On 2018-07-17 22:48, Alexander Smirnov wrote:
>>>
>>> Jan Kiszka <jan.kiszka@siemens.com> 17 июля 2018 г. 22:45:11 написал:
>>>
>>>> On 2018-07-17 17:41, Alexander Smirnov wrote:
>>>>>
>>>>>
>>>>> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>>>>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>>>>> Hi everybody,
>>>>>>>
>>>>>>> sorry for the delay, this is the third version of cross-compilation
>>>>>>> support for Isar.
>>>>>>
>>>>>> Thanks for the update!
>>>>>>
>>>>>>> Supported targets for cross-compilation:
>>>>>>>  - stretch armhf
>>>>>>>  - stretch amd64
>>>>>>>
>>>>>>> Artifacts could be cross-compiled:
>>>>>>>  - dpkg.bbclass users
>>>>>>>  - dpkg-raw.bbclass users
>>>>>>>  - kernel
>>>>>>>
>>>>>>> Known issues:
>>>>>>>  - if target and host architectures are the same, there is no need
>>>>>>>    to use host buildchroot.
>>>>>>>  - kernel module doesn't support cross-compilation. Default
>>>>>>> linux-headers
>>>>>>>    package depends from target gcc binaries. So attempt to install,
>>>>>>> for
>>>>>>>    example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>>>>>    conflict with the host tools.
>>>>>>
>>>>>> Could you imagine overriding such specialties with extra rules, even if
>>>>>> package specific? Not having kernel module in the cross compilation
>>>>>> chain main cause troubles (or does it work fine to cross-build the
>>>>>> kernel and then natively build the modules?).
>>>>>
>>>>> What I'd like to try:
>>>>> 1. Add ARM defconfig for linux-cip
>>>>> 2. Try to build example module for linux-cip for armhf
>>>>>
>>>>> Regarding overriding default Debian kernel, ATM I don't see any
>>>>> possibilities. Just as an exercise - I tried to install
>>>>> linux-headers-armmp:
>>>>>
>>>>> $ sudo dpkg --add-architecture armhf
>>>>> $ sudo apt-get update
>>>>> $ sudo apt-get install linux-headers-armmp
>>>>>
>>>>> No chances here, this package pulls lots of armhf binaries that conflict
>>>>> with the host ones. The only way I see now is to manually fetch and
>>>>> unpack this package. But it's an ugly hack IMHO :-(
>>>>
>>>> But maybe we can resolve that issue for self-built kernel by providing
>>>> also a compatible headers package?
>>>
>>>
>>> I need to investigate this topic in more details.
>>>
>>>>
>>>>
>>>>>
>>>>> Regarding hybrid mode (apps and kernel are compiled cross, modules are
>>>>> compiled natively) - this works. You could check this by trying
>>>>> cross-build for qemuarm-stretch, for example.
>>>>
>>>> I suppose to opt-out a package from cross-building, I need to add
>>>> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:
>>>
>>> Hmm, actually it should. That's how I disable cross-comp for kernel
>>> modules. Could you try more strength assignment := ?
>>>
> 
> Sorry, "no" was referring to the build in general. I can enforce the
> opt-out via ISAR_CROSS_COMPILE = "0" successfully.
> 
>>>>
>>>> | Broken jailhouse-build-deps:arm64 Depends on
>>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>>> |   Removing jailhouse-build-deps:arm64 because I can't find
>>>> linux-headers-jailhouse-arm64:arm64
>>>>
>>>> The problem seems to be that the header package is generate as :amd64,
>>>> so I can't install it into the arm64 buildchroot. However, the cross
>>>> build also fails because it searches for :arm64 as well:
>>>>
>>>> | Broken jailhouse-cross-build-deps:arm64 Depends on
>>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>>> |   Removing jailhouse-cross-build-deps:arm64 because I can't find
>>>> linux-headers-jailhouse-arm64:arm64
>>>>
>>>> By requesting :amd64 versions of the header as well as some python deps,
>>>> I'm getting further and then fail differently:
>>>>
>>>> | dpkg-architecture: warning: specified GNU system type
>>>> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
>>>> setting a correct CC environment variable
>>>> |  dpkg-source --before-build git
>>>> | dpkg-buildpackage: info: host architecture arm64
>>>> | dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64
>>>> python-setuptools:amd64 python-mako:amd64
>>>>
>>>> "host architecture arm64", that is suspicious...
>>>>
> 
> I'm starting to wonder if there is the wrong architecture set at some
> level, which may also explain why dpdk pulls tool packages for the
> target architecture, rather than the host arch. Does that ring any bell?
> 

Again looking at that wiki, I'm seeing

CONFIG_SITE=/etc/dpkg-cross/cross-config.<host_arch> \
DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -aarmhf

as the recommended invocation pattern for dpkg-buildpackage. Our
build.sh does not seem to set those to variables, neither for the build
nor the separately run mk-build-deps. Intentionally?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

On 07/18/2018 10:06 AM, Jan Kiszka wrote:
> On 2018-07-17 22:48, Alexander Smirnov wrote:
>>
>> Jan Kiszka <jan.kiszka@siemens.com> 17 июля 2018 г. 22:45:11 написал:
>>
>>> On 2018-07-17 17:41, Alexander Smirnov wrote:
>>>>
>>>>
>>>> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>>>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>>>> Hi everybody,
>>>>>>
>>>>>> sorry for the delay, this is the third version of cross-compilation
>>>>>> support for Isar.
>>>>>
>>>>> Thanks for the update!
>>>>>
>>>>>> Supported targets for cross-compilation:
>>>>>>   - stretch armhf
>>>>>>   - stretch amd64
>>>>>>
>>>>>> Artifacts could be cross-compiled:
>>>>>>   - dpkg.bbclass users
>>>>>>   - dpkg-raw.bbclass users
>>>>>>   - kernel
>>>>>>
>>>>>> Known issues:
>>>>>>   - if target and host architectures are the same, there is no need
>>>>>>     to use host buildchroot.
>>>>>>   - kernel module doesn't support cross-compilation. Default
>>>>>> linux-headers
>>>>>>     package depends from target gcc binaries. So attempt to install,
>>>>>> for
>>>>>>     example linux-headers-armmp, tries to install gcc:armhf, what rises
>>>>>>     conflict with the host tools.
>>>>>
>>>>> Could you imagine overriding such specialties with extra rules, even if
>>>>> package specific? Not having kernel module in the cross compilation
>>>>> chain main cause troubles (or does it work fine to cross-build the
>>>>> kernel and then natively build the modules?).
>>>>
>>>> What I'd like to try:
>>>> 1. Add ARM defconfig for linux-cip
>>>> 2. Try to build example module for linux-cip for armhf
>>>>
>>>> Regarding overriding default Debian kernel, ATM I don't see any
>>>> possibilities. Just as an exercise - I tried to install
>>>> linux-headers-armmp:
>>>>
>>>> $ sudo dpkg --add-architecture armhf
>>>> $ sudo apt-get update
>>>> $ sudo apt-get install linux-headers-armmp
>>>>
>>>> No chances here, this package pulls lots of armhf binaries that conflict
>>>> with the host ones. The only way I see now is to manually fetch and
>>>> unpack this package. But it's an ugly hack IMHO :-(
>>>
>>> But maybe we can resolve that issue for self-built kernel by providing
>>> also a compatible headers package?
>>
>>
>> I need to investigate this topic in more details.
>>
>>>
>>>
>>>>
>>>> Regarding hybrid mode (apps and kernel are compiled cross, modules are
>>>> compiled natively) - this works. You could check this by trying
>>>> cross-build for qemuarm-stretch, for example.
>>>
>>> I suppose to opt-out a package from cross-building, I need to add
>>> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:
>>
>> Hmm, actually it should. That's how I disable cross-comp for kernel
>> modules. Could you try more strength assignment := ?
>>
>>>
>>> | Broken jailhouse-build-deps:arm64 Depends on
>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>> |   Removing jailhouse-build-deps:arm64 because I can't find
>>> linux-headers-jailhouse-arm64:arm64
>>>
>>> The problem seems to be that the header package is generate as :amd64,
>>> so I can't install it into the arm64 buildchroot. However, the cross
>>> build also fails because it searches for :arm64 as well:
>>>
>>> | Broken jailhouse-cross-build-deps:arm64 Depends on
>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>> |   Removing jailhouse-cross-build-deps:arm64 because I can't find
>>> linux-headers-jailhouse-arm64:arm64
>>>
>>> By requesting :amd64 versions of the header as well as some python deps,
>>> I'm getting further and then fail differently:
>>>
>>> | dpkg-architecture: warning: specified GNU system type
>>> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
>>> setting a correct CC environment variable
>>> |  dpkg-source --before-build git
>>> | dpkg-buildpackage: info: host architecture arm64
>>> | dpkg-checkbuilddeps: error: Unmet build dependencies: python-pip:amd64
>>> python-setuptools:amd64 python-mako:amd64
>>>
>>> "host architecture arm64", that is suspicious...
>>>
>>>
>>> And then python - I'm still facing that issue with another package as
>>> well:
>>>
>>> | Setting up python2.7-minimal:arm64 (2.7.13-2+deb9u2) ...
>>> | /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
>>> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
>>> | dpkg: error processing package python2.7-minimal:arm64 (--configure):
>>> |  subprocess installed post-installation script returned error exit
>>> status 127
>>> | dpkg: dependency problems prevent configuration of
>>> python-minimal:arm64:
>>> |  python-minimal:arm64 depends on python2.7-minimal (>= 2.7.13-1~);
>>> however:
>>> |   Package python2.7-minimal:arm64 is not configured yet.
>>> |
>>> | dpkg: error processing package python-minimal:arm64 (--configure):
>>> |  dependency problems - leaving unconfigured
>>> | Errors were encountered while processing:
>>> |  python2.7-minimal:arm64
>>> |  python-minimal:arm64
>>> | E: Sub-process /usr/bin/dpkg returned an error code (1)
>>>
>>> Corresponding build dependencies there:
>>> Build-Depends: wget, cpio, unzip, rsync, python, bc
>>>
>>> Here I get my job done by hacking it this way:
>>> Build-Depends: wget, cpio, unzip, rsync, python:amd64, bc
>>
>> Is it possible to reproduce these results on my machine? I.e. are these
>> artifacts available in public? In my series I only guarantee that isar
>> tree is buildable, but unfortunately it doesn't cover all the possible
>> cases. :-( As mention above, we definetely need to add ARM kernel
>> configs to meta-isar to test real cross-compilation out of the box.
> 
> Sure: I'm testing with https://github.com/siemens/jailhouse-images,
> current next branch. You may skip the length non-root-initramfs package
> and also just do the Orange Pi Zero build.
> 
> We can also switch to the CIP kernel in Isar for the Banana Pi target.
> Will notably prolong the CI run, though.
> 

Just an observation, you use here buster but I didn't test it.

Alex

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-18 20:52, Alexander Smirnov wrote:
> 
> 
> On 07/18/2018 10:06 AM, Jan Kiszka wrote:
>> On 2018-07-17 22:48, Alexander Smirnov wrote:
>>>
>>> Jan Kiszka <jan.kiszka@siemens.com> 17 июля 2018 г. 22:45:11 написал:
>>>
>>>> On 2018-07-17 17:41, Alexander Smirnov wrote:
>>>>>
>>>>>
>>>>> On 07/17/2018 04:38 PM, Jan Kiszka wrote:
>>>>>> On 2018-07-17 15:18, Alexander Smirnov wrote:
>>>>>>> Hi everybody,
>>>>>>>
>>>>>>> sorry for the delay, this is the third version of cross-compilation
>>>>>>> support for Isar.
>>>>>>
>>>>>> Thanks for the update!
>>>>>>
>>>>>>> Supported targets for cross-compilation:
>>>>>>>   - stretch armhf
>>>>>>>   - stretch amd64
>>>>>>>
>>>>>>> Artifacts could be cross-compiled:
>>>>>>>   - dpkg.bbclass users
>>>>>>>   - dpkg-raw.bbclass users
>>>>>>>   - kernel
>>>>>>>
>>>>>>> Known issues:
>>>>>>>   - if target and host architectures are the same, there is no need
>>>>>>>     to use host buildchroot.
>>>>>>>   - kernel module doesn't support cross-compilation. Default
>>>>>>> linux-headers
>>>>>>>     package depends from target gcc binaries. So attempt to install,
>>>>>>> for
>>>>>>>     example linux-headers-armmp, tries to install gcc:armhf, what
>>>>>>> rises
>>>>>>>     conflict with the host tools.
>>>>>>
>>>>>> Could you imagine overriding such specialties with extra rules,
>>>>>> even if
>>>>>> package specific? Not having kernel module in the cross compilation
>>>>>> chain main cause troubles (or does it work fine to cross-build the
>>>>>> kernel and then natively build the modules?).
>>>>>
>>>>> What I'd like to try:
>>>>> 1. Add ARM defconfig for linux-cip
>>>>> 2. Try to build example module for linux-cip for armhf
>>>>>
>>>>> Regarding overriding default Debian kernel, ATM I don't see any
>>>>> possibilities. Just as an exercise - I tried to install
>>>>> linux-headers-armmp:
>>>>>
>>>>> $ sudo dpkg --add-architecture armhf
>>>>> $ sudo apt-get update
>>>>> $ sudo apt-get install linux-headers-armmp
>>>>>
>>>>> No chances here, this package pulls lots of armhf binaries that
>>>>> conflict
>>>>> with the host ones. The only way I see now is to manually fetch and
>>>>> unpack this package. But it's an ugly hack IMHO :-(
>>>>
>>>> But maybe we can resolve that issue for self-built kernel by providing
>>>> also a compatible headers package?
>>>
>>>
>>> I need to investigate this topic in more details.
>>>
>>>>
>>>>
>>>>>
>>>>> Regarding hybrid mode (apps and kernel are compiled cross, modules are
>>>>> compiled natively) - this works. You could check this by trying
>>>>> cross-build for qemuarm-stretch, for example.
>>>>
>>>> I suppose to opt-out a package from cross-building, I need to add
>>>> ISAR_CROSS_COMPILE = "0" to its recipe, right? Currently trying... no:
>>>
>>> Hmm, actually it should. That's how I disable cross-comp for kernel
>>> modules. Could you try more strength assignment := ?
>>>
>>>>
>>>> | Broken jailhouse-build-deps:arm64 Depends on
>>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>>> |   Removing jailhouse-build-deps:arm64 because I can't find
>>>> linux-headers-jailhouse-arm64:arm64
>>>>
>>>> The problem seems to be that the header package is generate as :amd64,
>>>> so I can't install it into the arm64 buildchroot. However, the cross
>>>> build also fails because it searches for :arm64 as well:
>>>>
>>>> | Broken jailhouse-cross-build-deps:arm64 Depends on
>>>> linux-headers-jailhouse-arm64:arm64 < none @un H >
>>>> |   Removing jailhouse-cross-build-deps:arm64 because I can't find
>>>> linux-headers-jailhouse-arm64:arm64
>>>>
>>>> By requesting :amd64 versions of the header as well as some python
>>>> deps,
>>>> I'm getting further and then fail differently:
>>>>
>>>> | dpkg-architecture: warning: specified GNU system type
>>>> aarch64-linux-gnu does not match CC system type x86_64-linux-gnu, try
>>>> setting a correct CC environment variable
>>>> |  dpkg-source --before-build git
>>>> | dpkg-buildpackage: info: host architecture arm64
>>>> | dpkg-checkbuilddeps: error: Unmet build dependencies:
>>>> python-pip:amd64
>>>> python-setuptools:amd64 python-mako:amd64
>>>>
>>>> "host architecture arm64", that is suspicious...
>>>>
>>>>
>>>> And then python - I'm still facing that issue with another package as
>>>> well:
>>>>
>>>> | Setting up python2.7-minimal:arm64 (2.7.13-2+deb9u2) ...
>>>> | /var/lib/dpkg/info/python2.7-minimal.postinst: 42:
>>>> /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
>>>> | dpkg: error processing package python2.7-minimal:arm64 (--configure):
>>>> |  subprocess installed post-installation script returned error exit
>>>> status 127
>>>> | dpkg: dependency problems prevent configuration of
>>>> python-minimal:arm64:
>>>> |  python-minimal:arm64 depends on python2.7-minimal (>= 2.7.13-1~);
>>>> however:
>>>> |   Package python2.7-minimal:arm64 is not configured yet.
>>>> |
>>>> | dpkg: error processing package python-minimal:arm64 (--configure):
>>>> |  dependency problems - leaving unconfigured
>>>> | Errors were encountered while processing:
>>>> |  python2.7-minimal:arm64
>>>> |  python-minimal:arm64
>>>> | E: Sub-process /usr/bin/dpkg returned an error code (1)
>>>>
>>>> Corresponding build dependencies there:
>>>> Build-Depends: wget, cpio, unzip, rsync, python, bc
>>>>
>>>> Here I get my job done by hacking it this way:
>>>> Build-Depends: wget, cpio, unzip, rsync, python:amd64, bc
>>>
>>> Is it possible to reproduce these results on my machine? I.e. are these
>>> artifacts available in public? In my series I only guarantee that isar
>>> tree is buildable, but unfortunately it doesn't cover all the possible
>>> cases. :-( As mention above, we definetely need to add ARM kernel
>>> configs to meta-isar to test real cross-compilation out of the box.
>>
>> Sure: I'm testing with https://github.com/siemens/jailhouse-images,
>> current next branch. You may skip the length non-root-initramfs package
>> and also just do the Orange Pi Zero build.
>>
>> We can also switch to the CIP kernel in Isar for the Banana Pi target.
>> Will notably prolong the CI run, though.
>>
> 
> Just an observation, you use here buster but I didn't test it.

Yes, but only for the pre-built u-boot package, and only for the Orange
Pi. See conf/multiconfig/preferences.orangepi-zero.conf.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

Hi Jan,

[...]

>> Just an observation, you use here buster but I didn't test it.
> 
> Yes, but only for the pre-built u-boot package, and only for the Orange
> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.

I've found several issue with v3 regarding kernel and modules 
cross-compilation. I've fixed them and pushed asmirnov/devel branch.

Now I'm able to cross-build orangepi kernel and example-module for it, 
huh! :-)

I've tried to make commits on the top small just to demonstrate my findings.

Could you please try this branch with your use-case? Unfortunately I 
wasn't able to quickly run clean jailhoust build, I have fedora as host 
OS and use debian in chroot. I've tried to run build scripts but docker 
fails with tons of errors :-(

Alex

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

Hi Alex,

On 2018-07-19 22:59, Alexander Smirnov wrote:
> Hi Jan,
> 
> [...]
> 
>>> Just an observation, you use here buster but I didn't test it.
>>
>> Yes, but only for the pre-built u-boot package, and only for the Orange
>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
> 
> I've found several issue with v3 regarding kernel and modules 
> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
> 
> Now I'm able to cross-build orangepi kernel and example-module for it, 
> huh! :-)

That's good news, and I can confirm that at least the linux-headers 
packages looks good now. It's also clear now that there can be no 
mixed-mode when building kernel modules because this package with its 
host tools is generated for the build host, not the target arch.

However, I'm still stuck on the Python dependency problems. I bet you 
can also reproduce them by declaring the hello package to build-depend 
on "python". Same for "python-pip".

> 
> I've tried to make commits on the top small just to demonstrate my 
> findings.
> 
> Could you please try this branch with your use-case? Unfortunately I 
> wasn't able to quickly run clean jailhoust build, I have fedora as host 
> OS and use debian in chroot. I've tried to run build scripts but docker 
> fails with tons of errors :-(

Can you share your error dump? That would be interesting as the whole 
docker story is about removing the host-side dependency on a particular 
distribution with a particular package set pre-installed, not to speak 
of the sudo config hack.

If you have a Debian 9 build host, you can also leave out the docker 
wrapping, just installing kas via pip and then doing

mkdir -p out
cd out
kas build /path/to/jailhouse-images/kas.yml

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

On 07/20/2018 08:56 AM, Jan Kiszka wrote:
> Hi Alex,
> 
> On 2018-07-19 22:59, Alexander Smirnov wrote:
>> Hi Jan,
>>
>> [...]
>>
>>>> Just an observation, you use here buster but I didn't test it.
>>>
>>> Yes, but only for the pre-built u-boot package, and only for the Orange
>>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
>>
>> I've found several issue with v3 regarding kernel and modules 
>> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
>>
>> Now I'm able to cross-build orangepi kernel and example-module for it, 
>> huh! :-)
> 
> That's good news, and I can confirm that at least the linux-headers 
> packages looks good now. It's also clear now that there can be no 
> mixed-mode when building kernel modules because this package with its 
> host tools is generated for the build host, not the target arch.
> 
> However, I'm still stuck on the Python dependency problems. I bet you 
> can also reproduce them by declaring the hello package to build-depend 
> on "python". Same for "python-pip".
> 
>>
>> I've tried to make commits on the top small just to demonstrate my 
>> findings.
>>
>> Could you please try this branch with your use-case? Unfortunately I 
>> wasn't able to quickly run clean jailhoust build, I have fedora as 
>> host OS and use debian in chroot. I've tried to run build scripts but 
>> docker fails with tons of errors :-(
> 
> Can you share your error dump? That would be interesting as the whole 
> docker story is about removing the host-side dependency on a particular 
> distribution with a particular package set pre-installed, not to speak 
> of the sudo config hack.

builder@zbook:~/jailhouse-images$ sudo 
KAS_TARGET="multiconfig:orangepi-zero-jailhouse:demo-image" 
./build-images.sh
Unable to find image 'kasproject/kas-isar:latest' locally
latest: Pulling from kasproject/kas-isar
6de29172b78c: Pull complete
0e2ff9900052: Pull complete
89b3b64c6e1a: Pull complete
c4ede5890983: Pull complete
63b0417b6e80: Pull complete
2095a826ca1c: Pull complete
519ff2acda8f: Pull complete
3568c8b200f9: Pull complete
84fb75e6e501: Pull complete
a8e3362d930a: Pull complete
fa1925a99ab2: Pull complete
af55a23213f5: Pull complete
2f0f64c16666: Pull complete
875a76dca692: Pull complete
4e9bfef3b1d2: Pull complete
6e603ec88847: Pull complete
b41c12cafe1e: Pull complete
cf73b0705769: Pull complete
Digest: 
sha256:c44212948d6f9b60faf17f3e769cc7bc926873ff1628adafb5c1ff1960931177
Status: Downloaded newer image for kasproject/kas-isar:latest
FATA[0085] Error response from daemon: Cannot start container 
32bdec7e11264b90a4090ea2892cb9b359a8f95b8b42e1c81ac2010d63ebefa3: [8] 
System error: mountpoint for cpu not found


> 
> If you have a Debian 9 build host, you can also leave out the docker 
> wrapping, just installing kas via pip and then doing
> 
> mkdir -p out
> cd out
> kas build /path/to/jailhouse-images/kas.yml
> 

Will try, thanks for the hint!

Alex

Re: [PATCH v3 0/7] Isar cross-compilation support

[Alexander Smirnov]

Hi Jan,

On 07/22/2018 11:15 PM, Alexander Smirnov wrote:
> 
> 
> On 07/20/2018 08:56 AM, Jan Kiszka wrote:
>> Hi Alex,
>>
>> On 2018-07-19 22:59, Alexander Smirnov wrote:
>>> Hi Jan,
>>>
>>> [...]
>>>
>>>>> Just an observation, you use here buster but I didn't test it.
>>>>
>>>> Yes, but only for the pre-built u-boot package, and only for the Orange
>>>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
>>>
>>> I've found several issue with v3 regarding kernel and modules 
>>> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
>>>
>>> Now I'm able to cross-build orangepi kernel and example-module for 
>>> it, huh! :-)
>>
>> That's good news, and I can confirm that at least the linux-headers 
>> packages looks good now. It's also clear now that there can be no 
>> mixed-mode when building kernel modules because this package with its 
>> host tools is generated for the build host, not the target arch.
>>
>> However, I'm still stuck on the Python dependency problems. I bet you 
>> can also reproduce them by declaring the hello package to build-depend 
>> on "python". Same for "python-pip".
>>

I've found an interesting notes here:

https://wiki.debian.org/DebianBootstrap/TODO#Remove_blockers_for_:any_and_:native_introduction

adding native qualifier for python solves the issue for me (i.e. 
python:native).

Do you think current status contains enough functionality for the first
implementation, so I could format clean patches and add the documentation?

Alex

>>>
>>> I've tried to make commits on the top small just to demonstrate my 
>>> findings.
>>>
>>> Could you please try this branch with your use-case? Unfortunately I 
>>> wasn't able to quickly run clean jailhoust build, I have fedora as 
>>> host OS and use debian in chroot. I've tried to run build scripts but 
>>> docker fails with tons of errors :-(
>>
>> Can you share your error dump? That would be interesting as the whole 
>> docker story is about removing the host-side dependency on a 
>> particular distribution with a particular package set pre-installed, 
>> not to speak of the sudo config hack.
> 
> builder@zbook:~/jailhouse-images$ sudo 
> KAS_TARGET="multiconfig:orangepi-zero-jailhouse:demo-image" 
> ./build-images.sh
> Unable to find image 'kasproject/kas-isar:latest' locally
> latest: Pulling from kasproject/kas-isar
> 6de29172b78c: Pull complete
> 0e2ff9900052: Pull complete
> 89b3b64c6e1a: Pull complete
> c4ede5890983: Pull complete
> 63b0417b6e80: Pull complete
> 2095a826ca1c: Pull complete
> 519ff2acda8f: Pull complete
> 3568c8b200f9: Pull complete
> 84fb75e6e501: Pull complete
> a8e3362d930a: Pull complete
> fa1925a99ab2: Pull complete
> af55a23213f5: Pull complete
> 2f0f64c16666: Pull complete
> 875a76dca692: Pull complete
> 4e9bfef3b1d2: Pull complete
> 6e603ec88847: Pull complete
> b41c12cafe1e: Pull complete
> cf73b0705769: Pull complete
> Digest: 
> sha256:c44212948d6f9b60faf17f3e769cc7bc926873ff1628adafb5c1ff1960931177
> Status: Downloaded newer image for kasproject/kas-isar:latest
> FATA[0085] Error response from daemon: Cannot start container 
> 32bdec7e11264b90a4090ea2892cb9b359a8f95b8b42e1c81ac2010d63ebefa3: [8] 
> System error: mountpoint for cpu not found
> 
> 
>>
>> If you have a Debian 9 build host, you can also leave out the docker 
>> wrapping, just installing kas via pip and then doing
>>
>> mkdir -p out
>> cd out
>> kas build /path/to/jailhouse-images/kas.yml
>>
> 
> Will try, thanks for the hint!
> 
> Alex
> 

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

Hi Alex,

On 2018-07-22 22:32, Alexander Smirnov wrote:
> Hi Jan,
> 
> On 07/22/2018 11:15 PM, Alexander Smirnov wrote:
>>
>>
>> On 07/20/2018 08:56 AM, Jan Kiszka wrote:
>>> Hi Alex,
>>>
>>> On 2018-07-19 22:59, Alexander Smirnov wrote:
>>>> Hi Jan,
>>>>
>>>> [...]
>>>>
>>>>>> Just an observation, you use here buster but I didn't test it.
>>>>>
>>>>> Yes, but only for the pre-built u-boot package, and only for the 
>>>>> Orange
>>>>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
>>>>
>>>> I've found several issue with v3 regarding kernel and modules 
>>>> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
>>>>
>>>> Now I'm able to cross-build orangepi kernel and example-module for 
>>>> it, huh! :-)
>>>
>>> That's good news, and I can confirm that at least the linux-headers 
>>> packages looks good now. It's also clear now that there can be no 
>>> mixed-mode when building kernel modules because this package with its 
>>> host tools is generated for the build host, not the target arch.
>>>
>>> However, I'm still stuck on the Python dependency problems. I bet you 
>>> can also reproduce them by declaring the hello package to 
>>> build-depend on "python". Same for "python-pip".
>>>
> 
> I've found an interesting notes here:
> 
> https://wiki.debian.org/DebianBootstrap/TODO#Remove_blockers_for_:any_and_:native_introduction 
> 
> 
> adding native qualifier for python solves the issue for me (i.e. 
> python:native).

Yes, already wanted to report (but got distracted by Jailhouse bugs)
that I found the same hint in

https://groups.google.com/forum/#!topic/linux.debian.devel.mentors/OuuorAmGgWc

Adding :native to python solved the build issue for non-root-initramfs
in jailhouse-image. But I have harder nuts in that repo. :)

The jailhouse package has build dependencies on python-mako, a package
mentioned above as cross-incompatible, and also python-pip. Those can be
installed by adding :native as well, but dpgk-buildpackage will then
fail on validating the build dependencies. That can be skipped, though:

diff --git a/meta/recipes-devtools/buildchroot/files/build.sh b/meta/recipes-devtools/buildchroot/files/build.sh
index 40ba410..aba2042 100644
--- a/meta/recipes-devtools/buildchroot/files/build.sh
+++ b/meta/recipes-devtools/buildchroot/files/build.sh
@@ -61,4 +61,4 @@ for i in configure aclocal.m4 Makefile.am Makefile.in; do
 done
 
 # Build the package
-dpkg-buildpackage -a$target_arch
+dpkg-buildpackage -a$target_arch --no-check-builddeps

With that change and by adding arm64 support, I was now able to build
*all* jailhouse-image targets cross!

> 
> Do you think current status contains enough functionality for the first
> implementation, so I could format clean patches and add the documentation?

Yes, definitely, with that workaround and arm64 support, please. Maybe
you have an idea how to limit the --no-check-builddeps to cross-builds.

I noticed one further minor thing: wic images seem to enforce generating
buildchroot-target. I suppose wic will be fine with buildchroot-host as
well. Would be nice to avoid that redundant bootstrap if possible.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-22 23:54, [ext] Jan Kiszka wrote:
> Hi Alex,
> 
> On 2018-07-22 22:32, Alexander Smirnov wrote:
>> Hi Jan,
>>
>> On 07/22/2018 11:15 PM, Alexander Smirnov wrote:
>>>
>>>
>>> On 07/20/2018 08:56 AM, Jan Kiszka wrote:
>>>> Hi Alex,
>>>>
>>>> On 2018-07-19 22:59, Alexander Smirnov wrote:
>>>>> Hi Jan,
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Just an observation, you use here buster but I didn't test it.
>>>>>>
>>>>>> Yes, but only for the pre-built u-boot package, and only for the
>>>>>> Orange
>>>>>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
>>>>>
>>>>> I've found several issue with v3 regarding kernel and modules
>>>>> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
>>>>>
>>>>> Now I'm able to cross-build orangepi kernel and example-module for
>>>>> it, huh! :-)
>>>>
>>>> That's good news, and I can confirm that at least the linux-headers
>>>> packages looks good now. It's also clear now that there can be no
>>>> mixed-mode when building kernel modules because this package with its
>>>> host tools is generated for the build host, not the target arch.
>>>>
>>>> However, I'm still stuck on the Python dependency problems. I bet you
>>>> can also reproduce them by declaring the hello package to
>>>> build-depend on "python". Same for "python-pip".
>>>>
>>
>> I've found an interesting notes here:
>>
>> https://wiki.debian.org/DebianBootstrap/TODO#Remove_blockers_for_:any_and_:native_introduction
>>
>>
>> adding native qualifier for python solves the issue for me (i.e.
>> python:native).
> 
> Yes, already wanted to report (but got distracted by Jailhouse bugs)
> that I found the same hint in
> 
> https://groups.google.com/forum/#!topic/linux.debian.devel.mentors/OuuorAmGgWc
> 
> Adding :native to python solved the build issue for non-root-initramfs
> in jailhouse-image. But I have harder nuts in that repo. :)
> 
> The jailhouse package has build dependencies on python-mako, a package
> mentioned above as cross-incompatible, and also python-pip. Those can be
> installed by adding :native as well, but dpgk-buildpackage will then
> fail on validating the build dependencies. That can be skipped, though:
> 
> diff --git a/meta/recipes-devtools/buildchroot/files/build.sh b/meta/recipes-devtools/buildchroot/files/build.sh
> index 40ba410..aba2042 100644
> --- a/meta/recipes-devtools/buildchroot/files/build.sh
> +++ b/meta/recipes-devtools/buildchroot/files/build.sh
> @@ -61,4 +61,4 @@ for i in configure aclocal.m4 Makefile.am Makefile.in; do
>   done
>   
>   # Build the package
> -dpkg-buildpackage -a$target_arch
> +dpkg-buildpackage -a$target_arch --no-check-builddeps
> 
> With that change and by adding arm64 support, I was now able to build
> *all* jailhouse-image targets cross!
> 
>>
>> Do you think current status contains enough functionality for the first
>> implementation, so I could format clean patches and add the documentation?
> 
> Yes, definitely, with that workaround and arm64 support, please. Maybe
> you have an idea how to limit the --no-check-builddeps to cross-builds.
> 
> I noticed one further minor thing: wic images seem to enforce generating
> buildchroot-target. I suppose wic will be fine with buildchroot-host as
> well. Would be nice to avoid that redundant bootstrap if possible.
> 

FWIW, I've pushed all required changes to jailhouse-images to its next 
branch. You just need to adjust the kas file to point to a compatible 
isar revision (your branch + arm64 + my workaround) and add

diff --git a/kas.yml b/kas.yml
index 64e80c5..0158ae5 100644
--- a/kas.yml
+++ b/kas.yml
@@ -33,3 +33,5 @@ bblayers_conf_header:
  local_conf_header:
    standard: |
      CONF_VERSION = "1"
+  cross: |
+    ISAR_CROSS_COMPILE = "1"

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-22 23:54, [ext] Jan Kiszka wrote:
> Hi Alex,
> 
> On 2018-07-22 22:32, Alexander Smirnov wrote:
>> Hi Jan,
>>
>> On 07/22/2018 11:15 PM, Alexander Smirnov wrote:
>>>
>>>
>>> On 07/20/2018 08:56 AM, Jan Kiszka wrote:
>>>> Hi Alex,
>>>>
>>>> On 2018-07-19 22:59, Alexander Smirnov wrote:
>>>>> Hi Jan,
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Just an observation, you use here buster but I didn't test it.
>>>>>>
>>>>>> Yes, but only for the pre-built u-boot package, and only for the
>>>>>> Orange
>>>>>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
>>>>>
>>>>> I've found several issue with v3 regarding kernel and modules
>>>>> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
>>>>>
>>>>> Now I'm able to cross-build orangepi kernel and example-module for
>>>>> it, huh! :-)
>>>>
>>>> That's good news, and I can confirm that at least the linux-headers
>>>> packages looks good now. It's also clear now that there can be no
>>>> mixed-mode when building kernel modules because this package with its
>>>> host tools is generated for the build host, not the target arch.
>>>>
>>>> However, I'm still stuck on the Python dependency problems. I bet you
>>>> can also reproduce them by declaring the hello package to
>>>> build-depend on "python". Same for "python-pip".
>>>>
>>
>> I've found an interesting notes here:
>>
>> https://wiki.debian.org/DebianBootstrap/TODO#Remove_blockers_for_:any_and_:native_introduction
>>
>>
>> adding native qualifier for python solves the issue for me (i.e.
>> python:native).
> 
> Yes, already wanted to report (but got distracted by Jailhouse bugs)
> that I found the same hint in
> 
> https://groups.google.com/forum/#!topic/linux.debian.devel.mentors/OuuorAmGgWc
> 
> Adding :native to python solved the build issue for non-root-initramfs
> in jailhouse-image. But I have harder nuts in that repo. :)
> 
> The jailhouse package has build dependencies on python-mako, a package
> mentioned above as cross-incompatible, and also python-pip. Those can be
> installed by adding :native as well, but dpgk-buildpackage will then
> fail on validating the build dependencies. That can be skipped, though:
> 
> diff --git a/meta/recipes-devtools/buildchroot/files/build.sh b/meta/recipes-devtools/buildchroot/files/build.sh
> index 40ba410..aba2042 100644
> --- a/meta/recipes-devtools/buildchroot/files/build.sh
> +++ b/meta/recipes-devtools/buildchroot/files/build.sh
> @@ -61,4 +61,4 @@ for i in configure aclocal.m4 Makefile.am Makefile.in; do
>   done
>   
>   # Build the package
> -dpkg-buildpackage -a$target_arch
> +dpkg-buildpackage -a$target_arch --no-check-builddeps
> 
> With that change and by adding arm64 support, I was now able to build
> *all* jailhouse-image targets cross!
> 
>>
>> Do you think current status contains enough functionality for the first
>> implementation, so I could format clean patches and add the documentation?
> 
> Yes, definitely, with that workaround and arm64 support, please. Maybe
> you have an idea how to limit the --no-check-builddeps to cross-builds.

It looks like that we cannot leave that out if we want to support 
:native unconditionally in control files, even for native builds.

Jan

Re: [PATCH v3 0/7] Isar cross-compilation support

[Jan Kiszka]

On 2018-07-22 22:15, Alexander Smirnov wrote:
> 
> 
> On 07/20/2018 08:56 AM, Jan Kiszka wrote:
>> Hi Alex,
>>
>> On 2018-07-19 22:59, Alexander Smirnov wrote:
>>> Hi Jan,
>>>
>>> [...]
>>>
>>>>> Just an observation, you use here buster but I didn't test it.
>>>>
>>>> Yes, but only for the pre-built u-boot package, and only for the Orange
>>>> Pi. See conf/multiconfig/preferences.orangepi-zero.conf.
>>>
>>> I've found several issue with v3 regarding kernel and modules 
>>> cross-compilation. I've fixed them and pushed asmirnov/devel branch.
>>>
>>> Now I'm able to cross-build orangepi kernel and example-module for 
>>> it, huh! :-)
>>
>> That's good news, and I can confirm that at least the linux-headers 
>> packages looks good now. It's also clear now that there can be no 
>> mixed-mode when building kernel modules because this package with its 
>> host tools is generated for the build host, not the target arch.
>>
>> However, I'm still stuck on the Python dependency problems. I bet you 
>> can also reproduce them by declaring the hello package to build-depend 
>> on "python". Same for "python-pip".
>>
>>>
>>> I've tried to make commits on the top small just to demonstrate my 
>>> findings.
>>>
>>> Could you please try this branch with your use-case? Unfortunately I 
>>> wasn't able to quickly run clean jailhoust build, I have fedora as 
>>> host OS and use debian in chroot. I've tried to run build scripts but 
>>> docker fails with tons of errors :-(
>>
>> Can you share your error dump? That would be interesting as the whole 
>> docker story is about removing the host-side dependency on a 
>> particular distribution with a particular package set pre-installed, 
>> not to speak of the sudo config hack.
> 
> builder@zbook:~/jailhouse-images$ sudo 
> KAS_TARGET="multiconfig:orangepi-zero-jailhouse:demo-image" 
> ./build-images.sh
> Unable to find image 'kasproject/kas-isar:latest' locally
> latest: Pulling from kasproject/kas-isar
> 6de29172b78c: Pull complete
> 0e2ff9900052: Pull complete
> 89b3b64c6e1a: Pull complete
> c4ede5890983: Pull complete
> 63b0417b6e80: Pull complete
> 2095a826ca1c: Pull complete
> 519ff2acda8f: Pull complete
> 3568c8b200f9: Pull complete
> 84fb75e6e501: Pull complete
> a8e3362d930a: Pull complete
> fa1925a99ab2: Pull complete
> af55a23213f5: Pull complete
> 2f0f64c16666: Pull complete
> 875a76dca692: Pull complete
> 4e9bfef3b1d2: Pull complete
> 6e603ec88847: Pull complete
> b41c12cafe1e: Pull complete
> cf73b0705769: Pull complete
> Digest: 
> sha256:c44212948d6f9b60faf17f3e769cc7bc926873ff1628adafb5c1ff1960931177
> Status: Downloaded newer image for kasproject/kas-isar:latest
> FATA[0085] Error response from daemon: Cannot start container 
> 32bdec7e11264b90a4090ea2892cb9b359a8f95b8b42e1c81ac2010d63ebefa3: [8] 
> System error: mountpoint for cpu not found
> 

I'm far from docker guru level, but this looks like you have some 
problem with your local docker installation.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux