Skip to contentSkip to conversation

support for ARM32 arndale and cubietruck platforms

PATCH Superseded Ian Campbell 2 participants 22 messages Jan 22, 2015 – Jan 26, 2015

lore
Share & tools
lore
#0 lore raw

v5 cover support for ARM32 arndale and cubietruck platforms

I'm preparing a bunch of each of these boards to be racked for inclusion in osstest. This series adds the necessary osstest support:

* Support for platforms which require us to supply a Device Tree
* Removing various hardcoded midway assumptions
* Some new features needed to workaround h/w quirks (of arndale in particular)
* Support for the power relay switch board which these are attached to
* Some new convenience features

The series is completely acked now, reposting just because some of the acks were given preemptively to give a chance for objections etc.

I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)

Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.

I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).

So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.

Stefano, do you have another preference?

WRT deploying we need to figure out the sequence in which we push these patches, reenable the linux-arm-xen branch and commissioning the new boards.

Ian.

PlatformsArmhf midway cubietruck arndale

HostProp_arndale-metrocentre_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 1 HostProp_arndale-westfield_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 2 HostProp_arndale-lakeside_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 3 HostProp_arndale-bluewater_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 4

HostProp_cubietruck-braque_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 5 HostProp_cubietruck-picaso_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 6 HostProp_cubietruck-metzinger_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 7 HostProp_cubietruck-gleizes_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 8

HostGroupProp_arndale_LinuxSerialConsole ttySAC2 HostGroupProp_arndale_Build_Make_Flags -j4 HostGroupProp_arndale_XenSerialConsole dtuart HostGroupProp_arndale_XenDTUARTPath /serial@12C20000 HostGroupProp_arndale_Interface_Force eth0 HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata HostGroupProp_arndale_Rootdelay 3
HostGroupProp_arndale_UBootSetXenAddrR 0x41000000
HostGroupProp_arndale_Serial sympathy osstser1 HostGroupProp_arndale_PowerCycleTime 15
HostGroupProp_arndale_TftpScope xenclient

HostGroupFlags_arndale suite-wheezy,platform-arndale,need-kernel-deb-armmp,no-di-kernel,force-mac-address,need-uboot-bootscr

HostGroup_arndale-metrocentre arndale HostProp_arndale-metrocentre_Fqdn arndale-metrocentre.cam.xci-test.com HostProp_arndale-metrocentre_Ether 9e:04:00:59:64:5a

HostGroup_arndale-westfield arndale HostProp_arndale-westfield_Fqdn arndale-westfield.cam.xci-test.com HostProp_arndale-westfield_Ether a6:46:13:77:e8:2f

HostGroup_arndale-lakeside arndale HostProp_arndale-lakeside_Fqdn arndale-lakeside.cam.xci-test.com HostProp_arndale-lakeside_Ether e2:e7:75:3f:df:4c

HostGroup_arndale-bluewater arndale HostProp_arndale-bluewater_Fqdn arndale-bluewater.cam.xci-test.com HostProp_arndale-bluewater_Ether f2:dc:22:d7:e9:e9

HostGroupProp_cubietruck_LinuxSerialConsole ttyS0 HostGroupProp_cubietruck_Build_Make_Flags -j4 HostGroupProp_cubietruck_XenSerialConsole dtuart HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000 HostGroupProp_cubietruck_UBootSetXenAddrR 0x41000000 HostGroupProp_cubietruck_Serial sympathy arm-serial-01 HostGroupProp_cubietruck_TftpScope xenclient

HostGroupFlags_cubietruck suite-wheezy,platform-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

HostGroup_cubietruck-braque cubietruck HostProp_cubietruck-braque_Fqdn cubietruck-braque.cam.xci-test.com

HostGroup_cubietruck-picaso cubietruck HostProp_cubietruck-picaso_Fqdn cubietruck-picaso.cam.xci-test.com

HostGroup_cubietruck-metzinger cubietruck HostProp_cubietruck-metzinger cubietruck-metzinger.cam.xci-test.com

HostGroup_cubietruck-gleizes cubietruck HostProp_cubietruck-gleizes_Fqdn cubietruck-gleizes.cam.xci-test.com

#1 lore raw

PATCH v5 1/14 make-flight: Run a basic test on each arm platform

Unlike x86 there is enough variation in the ARM platforms that it is worth having a basic test on each as part of a standard run. This relies on each host having an appropriate platform-$platform host flag.

The existing test-ARCH-ARCH-xl test is retained as a floating test, while a new variant is added for each distinct platform present in the hostdb which is tied to that platform type. The intention is that only arm platforms will have platforms at first, although perhaps platform-intel and platform-amd could be added in the future too.

There are currently no platform-* flags in the hostdb, so tested with s/platform-/equiv-/ and:

  ( set -ex ;
    source ./cri-getplatforms ;
    blessing=real ;
    export OSSTEST_CONFIG=production-config ;
    for p in '' `getplatforms "armhf"` ; do
      set +x ;
      echo PLATFORM: $p ;
    done

)
which prints:
PLATFORM:
PLATFORM: marilith
and with s/armhf/amd64/:
PLATFORM:
PLATFORM: rackservers-s40670
PLATFORM: r310-moth
PLATFORM: rackservers-s40680
PLATFORM: dell-r310
PLATFORM: rackservers-s40679
PLATFORM: rackservers-s40663
PLATFORM: rackservers-q21011

Also tested in standalone mode with a ~/.xen-osstest/config containing:

PlatformsArmhf midway cubietruck arndale

---
v3:

    Split /\s+/
v2:
    Use platform-* prop not equiv-*
    Select platforms from host db
---
 Osstest/HostDB/Executive.pm | 28 ++++++++++++++++++++++++++++
 Osstest/HostDB/Static.pm    |  9 +++++++++
 README                      |  3 +++
 cri-getplatforms            | 25 +++++++++++++++++++++++++
 make-flight                 |  9 +++++++--
 5 files changed, 72 insertions(+), 2 deletions(-)
 create mode 100755 cri-getplatforms
Osstest/HostDB/Executive.pm +28 -0
index b2c8dc9..6257829 100644
@@ -67,6 +67,34 @@ END
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my @plats = ( );
+    my $platsq = $dbh_tests->prepare(<<END);
+SELECT DISTINCT hostflag
+           FROM hostflags h0
+   WHERE EXISTS (
+       SELECT *
+         FROM hostflags h1, hostflags h2
+        WHERE h0.hostname = h1.hostname AND h1.hostname = h2.hostname
+          AND h1.hostflag = ?
+          AND h2.hostflag = ?
+   )
+   AND hostflag like 'platform-%';
+END
+
+    $platsq->execute("blessed-$blessing", "arch-$arch");
+
+    while (my ($plat) = $platsq->fetchrow_array()) {
+	$plat =~ s/^platform-//g or die;
+	push @plats, $plat;
+    }
+
+    $platsq->finish();
+    return @plats;
+}
+
 sub default_methods ($$) {
     my ($hd, $ho) = @_;
 
Osstest/HostDB/Static.pm +9 -0
index ad18395..60f5d3c 100644
@@ -65,6 +65,15 @@ sub get_flags ($$) { #method
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my $prop = "Platforms".ucfirst($arch);
+
+    return split /\s+/, $c{$prop} if $c{$prop};
+    return () unless $c{$prop};
+}
+
 sub default_methods ($$) { #method
     my ($hd, $ho) = @_;
 
README +3 -0
index b727a6f..6e63e97 100644
@@ -396,6 +396,9 @@ The keys in ~/.ssh/id_{rsa,dsa}.pub and ~/.ssh/authorized_keys
 
 TestHostKeypairPath
 
+Platforms<Arch>
+   List of platforms (i.e. distinct host types) to run a basic test on.
+
 HostProp_GenEtherPrefixBase 5e:36:0e:f5
 # 	                               :00:01 guest number in job appended
 #            in standalone jobdb, ^^^^^ xor'd with low 16 bits of your uid
cri-getplatforms new file +25 -0
new file mode 100755
index 0000000..067730c
@@ -0,0 +1,25 @@
+# -*- bash -*-
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+getplatforms () {
+        perl -e '
+                use Osstest;
+                csreadconfig();
+                print join " ", $mhostdb->get_arch_platforms("'$blessing'", "'$1'") or die $!;
+        '
+}
make-flight +7 -2
index a91f256..97e7a06 100755
@@ -27,6 +27,7 @@ buildflight=$4
 flight=`./cs-flight-create $blessing $branch`
 
 . cri-common
+. cri-getplatforms
 . ap-common
 . mfi-common
 
@@ -284,10 +285,14 @@ do_passthrough_tests () {
 test_matrix_do_one () {
 
   # Basic PV Linux test with xl
+  for platform in '' `getplatforms $xenarch` ; do
+    suffix=${platform:+-$platform}
+    hostflags=${most_hostflags}${platform:+,platform-$platform}
 
-  job_create_test test-$xenarch$kern-$dom0arch-xl test-debian xl \
+    job_create_test test-$xenarch$kern-$dom0arch-xl$suffix test-debian xl \
             $xenarch $dom0arch                                   \
-            $debian_runvars all_hostflags=$most_hostflags
+            $debian_runvars all_hostflags=$hostflags
+  done
 
   job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \
             $xenarch $dom0arch                                       \
Signature · 1 line
2.1.4
#2 lore raw

PATCH v5 2/14 Osstest/PDU: Add eth008.pm method to control the ARM rack PDU

In reply to Ian Campbell

This controls the eth008 relay board:
http://www.robot-electronics.co.uk/htm/eth008tech.htm

Due to the use of the CGI interface this requires firmware version 4+.

---
v3: Use LWP::UserAgent
v2: Pass username and password via a netrc file.

---
 Osstest/PDU/eth008.pm | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 Osstest/PDU/eth008.pm
Osstest/PDU/eth008.pm new file +65 -0
new file mode 100644
index 0000000..fc5fa96
@@ -0,0 +1,65 @@
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2014 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+package Osstest::PDU::eth008;
+
+use strict;
+use warnings;
+
+use Osstest;
+use Osstest::TestSupport;
+use LWP::UserAgent;
+
+BEGIN {
+    use Exporter ();
+    our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
+    $VERSION     = 1.00;
+    @ISA         = qw(Exporter);
+    @EXPORT      = qw();
+    %EXPORT_TAGS = ( );
+
+    @EXPORT_OK   = qw();
+}
+
+sub new {
+    my ($class, $ho, $methname, $pdu, $user, $pass, $port, @opts) = @_;
+    return bless { Host => $ho,
+		   PDU => $pdu,
+		   User => $user,
+		   Pass => $pass,
+		   Port => $port,
+		   Opts => \@opts }, $class;
+}
+
+sub pdu_power_state {
+    my ($mo, $on) = @_;
+    my $op= $on ? "DOA" : "DOI"; # Digital Output (In)Active
+
+    # Use the CGI interface since it is less prone to being firewalled
+    # off, unlike the standard interface on port 17494. This is only
+    # available from firmware v4 onwards.
+
+    my $ua = LWP::UserAgent->new;
+
+    $ua->credentials("$mo->{PDU}:80", "Protected", $mo->{User}, $mo->{Pass});
+
+    my $resp = $ua->get("http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0");
+
+    die "failed" unless $resp->is_success;
+    logm($resp->decoded_content);
+}
+
+1;
Signature · 1 line
2.1.4
#3 lore raw

PATCH v5 3/14 Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs

In reply to Ian Campbell

This is done whenever dtbs.tar.gz exists. mg-debian-installer-update produces the necessary inputs on the relevant platform (armhf).

---
v3: More careful check/stat for existence of dtbs.tar.gz
v2: Install dtbs iff dtbs.tar.gz exists.

---
 Osstest/Debian.pm | 28 +++++++++++++++++++++++++---
 1 file changed, 25 insertions(+), 3 deletions(-)
Osstest/Debian.pm +25 -3
index 7081a29..0a69aca 100644
@@ -20,6 +20,8 @@ package Osstest::Debian;
 use strict;
 use warnings;
 
+use POSIX;
+
 use IO::File;
 use File::Copy;
 
@@ -514,6 +516,9 @@ sub preseed_create ($$;@) {
     my $disk= $xopts{DiskDevice} || '/dev/sda';
     my $suite= $xopts{Suite} || $c{DebianSuite};
 
+    my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.
+	$c{TftpDiVersion}.'-'.$ho->{Suite};
+
     my $hostsq= $dbh_tests->prepare(<<END);
         SELECT val FROM runvars
          WHERE flight=? AND name LIKE '%host'
@@ -627,12 +632,29 @@ $overlays
 echo latecmd done.
 END
 
+    my $dtbs = "$d_i/dtbs.tar.gz";
+    if (!stat $dtbs) {
+        $!==&ENOENT or die "dtbs $!";
+    } elsif (-e _) {
+	my $durl = create_webfile($ho, "dtbs", sub {
+	    copy("$d_i/dtbs.tar.gz", $_[0])
+		or die "Copy dtbs failed: $!";
+	});
+	preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+r=/target
+
+wget -O \$r/tmp/dtbs.tar.gz $durl
+
+in-target tar -C /boot -xaf /tmp/dtbs.tar.gz
+END
+    }
+
     foreach my $kp (keys %{ $ho->{Flags} }) {
 	$kp =~ s/need-kernel-deb-// or next;
 
-	my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'.
-	    $c{TftpDiVersion}.'-'.$ho->{Suite};
-
 	my $kurl = create_webfile($ho, "kernel", sub {
 	    copy("$d_i/$kp.deb", $_[0])
 		or die "Copy kernel failed: $!";
Signature · 1 line
2.1.4
#4 lore raw

PATCH v5 4/14 Osstest/Debian: Support for loading an FDT from u-boot script

In reply to Ian Campbell

The currently supported platform provides an FDT preloaded at 0x1000. Replace this with ${fdt_addr} (which the current platform exposes) and for platforms which do not provide an fdt arrange to load the relevant file as named in the ${fdtfile} (which is conventionally provided by u-boot for platforms which need this).

Drop some random memory clearing rune, I've no idea what the intended purpose was, 0x800000 doesn't correspond to any $foo_addr_r on the midway systems for example.

Also get rid of the scsi scan which must necessarily have already happened (since the boot.scr itselfs lives on a scsi drive).

Lastly, add some echos to show progress through the script, as an aid to debugging.

---
v2: Refactor uboot dtb loading scriptlet, which previously appeared
twice

---
 Osstest/Debian.pm | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)
Osstest/Debian.pm +19 -6
index 0a69aca..8b70442 100644
@@ -114,6 +114,15 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
+sub uboot_scr_load_dtb () {
+    return <<'END';
+if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
+    echo Loading dtbs/\${fdtfile}
+    ext2load scsi 0 \${fdt_addr_r} dtbs/\${fdtfile}
+    setenv fdt_addr \${fdt_addr_r}
+fi
+END
+}
 sub setupboot_uboot ($$$) {
     my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_;
     my $bl= { };
@@ -132,6 +141,8 @@ sub setupboot_uboot ($$$) {
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
 
+	my $load_dtb = uboot_scr_load_dtb();
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -143,9 +154,7 @@ cp -n /boot/boot.scr /boot/boot.scr.bak
 xen=`readlink /boot/$xen`
 
 cat >/boot/boot <<EOF
-
-mw.l 800000 0 10000
-scsi scan
+${load_dtb}
 
 fdt addr \\\${fdt_addr}
 fdt resize
@@ -692,6 +701,8 @@ END
 
 	my $bootargs = join ' ', @bootargs;
 
+	my $load_dtb = uboot_scr_load_dtb();
+
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
 set -ex
@@ -703,11 +714,13 @@ initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
 setenv bootargs $bootargs
-mw.l 800000 0 10000
-scsi scan
+${load_dtb}
+echo Loading \$kernel
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
+echo Loading \$initrd
 ext2load scsi 0 \\\${ramdisk_addr_r} \$initrd
-bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} 0x1000
+echo Booting
+bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
 EOF
 
 in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
Signature · 1 line
2.1.4
#5 lore raw

PATCH v5 5/14 Osstest/Debian: Refactor setting of dom0 kernel command line.

In reply to Ian Campbell

This will make it easier to make components optional in the future.

---
 Osstest/Debian.pm | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
Osstest/Debian.pm +9 -2
index 8b70442..0b047df 100644
@@ -136,6 +136,13 @@ sub setupboot_uboot ($$$) {
 
 	my $root= target_guest_lv_name($ho,"root");
 
+	my @xenkopt;
+	push @xenkopt, $xenkopt;
+	push @xenkopt, "ro";
+	push @xenkopt, "root=$root";
+
+	$xenkopt = join ' ', @xenkopt;
+
 	logm("Xen options: $xenhopt");
 	logm("Linux options: $xenkopt");
 
@@ -177,9 +184,9 @@ ext2load scsi 0 \\\${kernel_addr_r} $kern
 fdt mknod /chosen module\@0
 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
 fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}>
-fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root"
+fdt set /chosen/module\@0 bootargs "$xenkopt"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
-echo command line: $xenkopt ro root=$root
+echo command line: $xenkopt
 
 ext2load scsi 0 \\\${ramdisk_addr_r} $initrd
 fdt mknod /chosen module\@1
Signature · 1 line
2.1.4
#6 lore raw

PATCH v5 6/14 Osstest/Debian.pm: Refactor common kernel cmdline setup.

In reply to Ian Campbell

---
v5: New patch, based on review of Osstest/Debian: support adding a
rootdelay property to bootargs

---
 Osstest/Debian.pm | 23 +++++++++++++++--------
 1 file changed, 15 insertions(+), 8 deletions(-)
Osstest/Debian.pm +15 -8
index 0b047df..1f7a4f0 100644
@@ -114,6 +114,19 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
+sub uboot_common_kernel_bootargs ($)
+{
+    my ($ho) = @_;
+
+    my $root= target_guest_lv_name($ho,"root");
+
+    my @bootargs;
+    push @bootargs, "ro";
+    push @bootargs, "root=$root";
+
+    return @bootargs;
+}
+
 sub uboot_scr_load_dtb () {
     return <<'END';
 if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
@@ -134,12 +147,8 @@ sub setupboot_uboot ($$$) {
 	my $kern = "vmlinuz-$want_kernver";
 	my $initrd = "initrd.img-$want_kernver";
 
-	my $root= target_guest_lv_name($ho,"root");
-
-	my @xenkopt;
+	my @xenkopt = uboot_common_kernel_bootargs($ho);
 	push @xenkopt, $xenkopt;
-	push @xenkopt, "ro";
-	push @xenkopt, "root=$root";
 
 	$xenkopt = join ' ', @xenkopt;
 
@@ -698,12 +707,10 @@ END
     }
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
-	my @bootargs;
+	my @bootargs = uboot_common_kernel_bootargs($ho);
 
-	my $root=target_guest_lv_name($ho,"root");
 	my $console=get_host_native_linux_console($ho);
 
-	push @bootargs, "root=$root";
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;
Signature · 1 line
2.1.4
#7 lore raw

PATCH v5 7/14 Osstest/Debian: support adding a rootdelay property to bootargs

In reply to Ian Campbell

arndale appears to be quite slow (and asynchronous) at finding it's scsi controller. rootdelay=3 seems to do the trick.

For the dom0 case this involved refactoring the existing provision of the commandline to be less open-coded in the boot script here doc.

---
v5: Rebased over refactoring.
v3: Honour rootdelay when booting dom 0.

---
 Osstest/Debian.pm | 2 ++
 1 file changed, 2 insertions(+)
Osstest/Debian.pm +2 -0
index 1f7a4f0..2ea1a7e 100644
@@ -119,10 +119,12 @@ sub uboot_common_kernel_bootargs ($)
     my ($ho) = @_;
 
     my $root= target_guest_lv_name($ho,"root");
+    my $rootdelay= get_host_property($ho, "rootdelay");
 
     my @bootargs;
     push @bootargs, "ro";
     push @bootargs, "root=$root";
+    push @bootargs, "rootdelay=$rootdelay" if $rootdelay;
 
     return @bootargs;
 }
Signature · 1 line
2.1.4
#8 lore raw

PATCH v5 8/14 Osstest/Debian: Remove hardcoded addresses from boot.scr

In reply to Ian Campbell

Those are specific to the midway platform.

This depends on a change to the hostdb to add "0x01000000" as the value of a new UBootSetXenAddrR property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale 0x41000000.

---
v3: Move the property to a specific one like I was supposed to last
time
v2: s/go along with/depends on/

---
 Osstest/Debian.pm | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
Osstest/Debian.pm +5 -4
index 2ea1a7e..146fa94 100644
@@ -158,9 +158,13 @@ sub setupboot_uboot ($$$) {
 	logm("Linux options: $xenkopt");
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
+	my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef);
 
 	my $load_dtb = uboot_scr_load_dtb();
 
+	my $set_xen_addr_r =
+	    $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : "";
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -178,14 +182,11 @@ fdt addr \\\${fdt_addr}
 fdt resize
 
 ${early_commands}
+${set_xen_addr_r}
 
 fdt set /chosen \\\#address-cells <1>
 fdt set /chosen \\\#size-cells <1>
 
-setenv xen_addr_r 0x01000000
-#   kernel_addr_r=0x02000000
-#  ramdisk_addr_r=0x04000000
-
 ext2load scsi 0 \\\${xen_addr_r} \$xen
 setenv bootargs "$xenhopt"
 echo Loaded \$xen to \\\${xen_addr_r} (\\\${filesize})
Signature · 1 line
2.1.4
#9 lore raw

PATCH v5 9/14 Osstest/Debian: Add "clk_ignore_unused" to default command line

In reply to Ian Campbell

dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so this stops the kernel from messing with (specifically, disabling) those clocks. It's harmless even when not needed.

Really there ought to be some interface to communicate this from Xen to dom0, or some other mechanism to gate things. See
http://bugs.xenproject.org/xen/bug/45

This bug is present in at least Wheezy and Jessie so apply this workaround to those.

---
v5: Conditional on wheezy|jessie
v3: More verbiage about why this is done
v2: New patch, previously incorrectly included in "Osstest/Debian:
Workaround oddities in the u-boot script parser."

---
 Osstest/Debian.pm | 3 +++
 1 file changed, 3 insertions(+)
Osstest/Debian.pm +3 -0
index 146fa94..8b94913 100644
@@ -151,6 +151,9 @@ sub setupboot_uboot ($$$) {
 
 	my @xenkopt = uboot_common_kernel_bootargs($ho);
 	push @xenkopt, $xenkopt;
+	# http://bugs.xenproject.org/xen/bug/45
+	push @xenkopt, "clk_ignore_unused"
+	    if $ho->{Suite} =~ m/wheezy|jessie/;
 
 	$xenkopt = join ' ', @xenkopt;
 
Signature · 1 line
2.1.4
#10 lore raw

PATCH v5 10/14 Osstest/Debian: Add 0x prefix to $filesize

In reply to Ian Campbell

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly. See
http://lists.denx.de/pipermail/u-boot/2014-October/193622.html,
http://lists.denx.de/pipermail/u-boot/2014-November/194150.html and
http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.

---
v3: Reference ML thread.
v2: New patch, previously included in "Osstest/Debian: Workaround
oddities in the u-boot script parser.". Note that the oddities with requiring a space before the ">" is no longer reproducible with the latest u-boot.

---
 Osstest/Debian.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Osstest/Debian.pm +2 -2
index 8b94913..de1f7b0 100644
@@ -198,7 +198,7 @@ echo command line: \\\${bootargs}
 ext2load scsi 0 \\\${kernel_addr_r} $kern
 fdt mknod /chosen module\@0
 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
-fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}>
+fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}>
 fdt set /chosen/module\@0 bootargs "$xenkopt"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
 echo command line: $xenkopt
@@ -206,7 +206,7 @@ echo command line: $xenkopt
 ext2load scsi 0 \\\${ramdisk_addr_r} $initrd
 fdt mknod /chosen module\@1
 fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module"
-fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}>
+fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
 fdt print /chosen
Signature · 1 line
2.1.4
#11 lore raw

PATCH v5 11/14 ts-kernel-build: Adjust kernel .config to work on the arndale boards.

In reply to Ian Campbell

Various drivers are missing from multi_v7_defconfig in v3.16, also some drivers which don't play nice are enabled by default, so remove them.

---
v3: This is a more extensive version of "ts-kernel-build: Enable
CONFIG_PHY_EXYNOS5250_SATA". Ian acked that but this does a lot more so I've dropped it.

---
 ts-kernel-build | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
ts-kernel-build +35 -0
index f02205f..b2f19cf 100755
@@ -171,6 +171,41 @@ setopt CONFIG_BLK_DEV_NBD y
 # At least with Linux 3.4.77 on wheezy, the nbd module is
 # not loaded automatically.
 
+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't
+# support that platform anyway.
+setopt CONFIG_ARCH_EXYNOS4 n
+
+# Having these on breaks USB
+setopt CONFIG_SAMSUNG_USB2PHY n
+setopt CONFIG_SAMSUNG_USB3PHY n
+
+# These cause i2c bus timeout errors on boot.
+# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU?
+# http://patchwork.ozlabs.org/patch/337812/
+setopt CONFIG_SENSORS_LM90 n
+setopt CONFIG_ICS932S401 n
+
+# Enable some additional drivers for Arndale.
+setopt CONFIG_PHY_EXYNOS5250_SATA m
+setopt CONFIG_USB_EHCI_EXYNOS m
+setopt CONFIG_USB_OHCI_EXYNOS m
+setopt CONFIG_USB_HSIC_USB3503 m
+setopt CONFIG_USB_DWC3 m
+setopt CONFIG_USB_DWC3_HOST y
+setopt CONFIG_USB_DWC3_EXYNOS m
+setopt CONFIG_USB_DWC3_PCI n
+setopt CONFIG_PHY_SAMSUNG_USB2 m
+setopt CONFIG_PHY_EXYNOS5250_USB2 y
+setopt CONFIG_PHY_EXYNOS5_USBDRD m
+setopt CONFIG_RTC_DRV_S5M y
+setopt CONFIG_COMMON_CLK_S2MPS11 m
+setopt CONFIG_I2C_S3C2410 y
+setopt CONFIG_MMC_DW m
+setopt CONFIG_MMC_DW_EXYNOS m
+setopt CONFIG_REGULATOR_S5M8767 m
+
+####
+
 END
 
 our $config_features= <<END;
Signature · 1 line
2.1.4
#12 lore raw

PATCH v5 12/14 Debian: Create boot.scr with a suffix and copy to boot.scr

In reply to Ian Campbell

This ensures that we always have a boot script to boot at least the native Debian kernel and Xen available, even after multiple iterations of installation, which is handy when debugging a system.

---
 Osstest/Debian.pm | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)
Osstest/Debian.pm +8 -6
index de1f7b0..d703e00 100644
@@ -173,12 +173,12 @@ if test ! -f /boot/$kern ; then
     exit 1
 fi
 # Save a copy of the original
-cp -n /boot/boot /boot/boot.bak
-cp -n /boot/boot.scr /boot/boot.scr.bak
+cp -n /boot/boot.xen /boot/boot.xen.bak
+cp -n /boot/boot.scr.xen /boot/boot.scr.xen.bak
 
 xen=`readlink /boot/$xen`
 
-cat >/boot/boot <<EOF
+cat >/boot/boot.xen <<EOF
 ${load_dtb}
 
 fdt addr \\\${fdt_addr}
@@ -214,7 +214,8 @@ fdt print /chosen
 echo Booting \\\${xen_addr_r} - \\\${fdt_addr}
 bootz \\\${xen_addr_r} - \\\${fdt_addr}
 EOF
-mkimage -A arm -T script -d /boot/boot /boot/boot.scr
+mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen
+cp /boot/boot.scr.xen /boot/boot.scr
 END
     };
 
@@ -732,7 +733,7 @@ r=/target #/
 kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
-cat >\$r/boot/boot <<EOF
+cat >\$r/boot/boot.deb <<EOF
 setenv bootargs $bootargs
 ${load_dtb}
 echo Loading \$kernel
@@ -743,7 +744,8 @@ echo Booting
 bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
 EOF
 
-in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
+in-target mkimage -A arm -T script -d /boot/boot.deb /boot/boot.scr.deb
+in-target cp /boot/boot.scr.deb /boot/boot.scr
 END
     }
 
Signature · 1 line
2.1.4
#13 lore raw

PATCH v5 13/14 TestSupport: replace power_cycle_timeout with power_cycle_sleep

In reply to Ian Campbell

Which does the actual sleep and logs that it is doing so.

Otherwise on a machine which has a longish PowerCycleTime I keep wondering why osstest has hung...

---
 Osstest/TestSupport.pm | 10 ++++++----
 ts-host-install        |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)
Osstest/TestSupport.pm +6 -4
index 5ac66e5..8d070ab 100644
@@ -66,7 +66,7 @@ BEGIN {
 
                       selecthost get_hostflags get_host_property
                       get_host_native_linux_console
-                      power_state power_cycle power_cycle_time
+                      power_state power_cycle power_cycle_sleep
                       serial_fetch_logs
                       propname_massage
          
@@ -712,9 +712,11 @@ sub power_cycle_host_setup ($) {
     $ho->{PowerMethobjs} = $methobjs;
 }
 
-sub power_cycle_time ($) {
+sub power_cycle_sleep ($) {
     my ($ho) = @_;
-    return get_host_property($ho, 'power-cycle-time', 5);
+    my $to = get_host_property($ho, 'power-cycle-time', 5);
+    logm("power-cycle: waiting ${to}s");
+    sleep($to);
 }
 
 sub power_cycle ($) {
@@ -724,7 +726,7 @@ sub power_cycle ($) {
 	" possibly shared with other jobs\n"
 	if $ho->{SharedMaybeOthers};
     power_state($ho, 0);
-    sleep(power_cycle_time($ho));
+    power_cycle_sleep($ho);
     power_state($ho, 1);
 }
 
ts-host-install +1 -1
index 30f6465..ae1d228 100755
@@ -63,7 +63,7 @@ d-i netcfg/get_ipaddress string $ho->{Ip}
 END
 
     setup_pxeboot_firstboot($ps_url);
-    sleep(power_cycle_time($ho));
+    power_cycle_sleep($ho);
 
     my $logtailer= Osstest::Logtailer->new($c{WebspaceLog});
     power_state($ho, 1);
Signature · 1 line
2.1.4
#14 lore raw

PATCH v5 14/14 Debian: create boot.scr.nat when installing Xen on u-boot.

In reply to Ian Campbell

This boots the kernel we've build natively, where boot.xen boots Xen and boot.deb boots the original Debian kernel.

Sometimes convenient when debugging issues.

---
v5: Rebased over Linux cmdline refactoring.
v4: New patch

---
 Osstest/Debian.pm | 32 +++++++++++++++++++++++++++++---
 1 file changed, 29 insertions(+), 3 deletions(-)
Osstest/Debian.pm +29 -3
index d703e00..3c4ac5e 100644
@@ -149,16 +149,28 @@ sub setupboot_uboot ($$$) {
 	my $kern = "vmlinuz-$want_kernver";
 	my $initrd = "initrd.img-$want_kernver";
 
-	my @xenkopt = uboot_common_kernel_bootargs($ho);
+	logm("Xen options: $xenhopt");
+
+	# Common kernel options
+	my @kopt = uboot_common_kernel_bootargs($ho);
+
+	# Dom0 specific kernel options
+	my @xenkopt = @kopt;
 	push @xenkopt, $xenkopt;
 	# http://bugs.xenproject.org/xen/bug/45
 	push @xenkopt, "clk_ignore_unused"
 	    if $ho->{Suite} =~ m/wheezy|jessie/;
 
 	$xenkopt = join ' ', @xenkopt;
+	logm("Dom0 Linux options: $xenkopt");
 
-	logm("Xen options: $xenhopt");
-	logm("Linux options: $xenkopt");
+	# Native specific kernel options
+	my $natcons = get_host_native_linux_console($ho);
+	my @natkopt = @kopt;
+	push @natkopt, "console=$natcons" unless $natcons eq "NONE";
+
+	my $natkopt = join ' ', @natkopt;
+	logm("Native linux options: $natkopt");
 
 	my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', '');
 	my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef);
@@ -216,6 +228,20 @@ bootz \\\${xen_addr_r} - \\\${fdt_addr}
 EOF
 mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen
 cp /boot/boot.scr.xen /boot/boot.scr
+
+# Create boot.scr.nat for convenience too
+cat >/boot/boot.nat <<EOF
+setenv bootargs $natkopt
+${load_dtb}
+echo Loading $kern
+ext2load scsi 0 \\\${kernel_addr_r} $kern
+echo Loading $initrd
+ext2load scsi 0 \\\${ramdisk_addr_r} $initrd
+echo Booting
+bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr}
+EOF
+mkimage -A arm -T script -d /boot/boot.nat /boot/boot.scr.nat
+
 END
     };
 
Signature · 1 line
2.1.4
#15 lore raw
In reply to Ian Campbell
Quoted 12 lines · Ian Campbell

I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)

Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.

I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).

Quoted 7 lines

So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.

Stefano, do you have another preference?

We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.

Stefano,

Please could you pull from git://kernel.ubuntu.com/ubuntu/linux.git and the force push::

The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the input tree#branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git#linux-arm-xen

and v3.16.7-ckt4~1 (i.e. the commit before the tag) to the output tree#branch at:
git://xenbits.xen.org/linux-pvops.git#tested/linux-arm-xen

Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.

Ian.

#16 lore raw
Quoted 2 lines · Ian Campbell

Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.

Actually using the result will require me to push this along with the main series.

8<-------

Quoted 1 line

From ba72d891c2d97991a4b00d8958883d17e4bc16d1 Mon Sep 17 00:00:00 2001

From: Ian Campbell <[email protected]>
Date: Thu, 22 Jan 2015 15:53:35 +0000
Subject: [PATCH] Switch ARM testing back to linux-arm-xen branch.

The cubietruck and arndale boards need a newer kernel than our current baseline of 3.14. Therefore switch all ARM testing to the linux-arm-kernel branch which has been moved up to test v3.16.

This effectively reverts commit 38b2fe2020883 "Switch armhf to use common default Linux."

---
 mfi-common | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)
mfi-common +6 -5
index e167606..7ccff40 100644
@@ -73,6 +73,10 @@ create_build_jobs () {
       xen-4.1-testing) continue;;
       xen-4.2-testing) continue;;
       esac
+      pvops_kernel="
+        tree_linux=$TREE_LINUX_ARM
+        revision_linux=${REVISION_LINUX_ARM:-${DEFAULT_REVISION_LINUX_ARM}}
+      "
       pvops_kconfig_overrides="
         kconfig_override_y=CONFIG_EXT4_FS
       "
@@ -81,15 +85,12 @@ create_build_jobs () {
       case "$branch" in
       linux-arm-xen) continue;;
       esac
-      ;;
-    esac
-
-    if [ "x$pvops_kernel" = x ] ; then
       pvops_kernel="
         tree_linux=$TREE_LINUX
         revision_linux=${REVISION_LINUX:-${DEFAULT_REVISION_LINUX}}
       "
-    fi
+      ;;
+    esac
 
     case "$arch" in
     *)     suite=$defsuite;;
Signature · 1 line
2.1.4
#17 lore raw
Quoted 6 lines · Ian Campbell
Quoted 2 lines · Ian Campbell

Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.

Actually using the result will require me to push this along with the main series.

I've have just pushed these to pretest as discussed last week:

$ git log --oneline bb2240e..2e35f88
2e35f88 make-flight: reorganize scheduling related test jobs
25ee621 Switch ARM testing back to linux-arm-xen branch.
339ad81 Debian: create boot.scr.nat when installing Xen on u-boot.
fcf00b2 TestSupport: replace power_cycle_timeout with power_cycle_sleep
70b19e1 Debian: Create boot.scr with a suffix and copy to boot.scr
e449fed ts-kernel-build: Adjust kernel .config to work on the arndale boards.
ee5e442 Osstest/Debian: Add 0x prefix to $filesize
0e24cb2 Osstest/Debian: Add "clk_ignore_unused" to default command line
653d0af Osstest/Debian: Remove hardcoded addresses from boot.scr
2d08c4c Osstest/Debian: support adding a rootdelay property to bootargs
64c57cb Osstest/Debian.pm: Refactor common kernel cmdline setup.
45e3b3c Osstest/Debian: Refactor setting of dom0 kernel command line.
070db63 Osstest/Debian: Support for loading an FDT from u-boot script
781c575 Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs
2d92112 Osstest/PDU: Add eth008.pm method to control the ARM rack PDU
056840c make-flight: Run a basic test on each arm platform

That is: This series, the one extra patch to use linux-arm-xen for kernels and Dario's scheduler rejigging.

I also ran:
OSSTEST_CONFIG=production-config ./mg-hosts setflags marilith-n\* -- platform-midway

So that 056840c does something.

Ian.

#18 lore raw
In reply to Ian Campbell
Quoted 21 lines · Ian Campbell
Quoted 12 lines · Ian Campbell

I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)

Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.

I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).

Quoted 7 lines

So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.

Stefano, do you have another preference?

Quoted 7 lines

We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.

Stefano,

Please could you pull from git://kernel.ubuntu.com/ubuntu/linux.git and the force push::

Actually I think we should follow

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.16.y

Quoted 1 line

The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the

I was talking about v3.16.7

Quoted 12 lines

input tree#branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git#linux-arm-xen

and v3.16.7-ckt4~1 (i.e. the commit before the tag) to the output tree#branch at:
git://xenbits.xen.org/linux-pvops.git#tested/linux-arm-xen

Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.

Ian.

#19 lore raw
Quoted 25 lines · Stefano Stabellini
Quoted 24 lines · Ian Campbell
Quoted 12 lines · Ian Campbell

I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)

Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.

I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).

Quoted 7 lines

So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.

Stefano, do you have another preference?

We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.

Quoted 8 lines
Quoted 4 lines

Stefano,

Please could you pull from git://kernel.ubuntu.com/ubuntu/linux.git and the force push::

Actually I think we should follow

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.16.y

There are no more updates to this, since it is not a kernel.org LTS kernel.

The canonical kernel team (ckt in the tag name) are doing ongoing stable support for these kernels (which is also being consumed by Debian).

Quoted 3 lines
Quoted 1 line

The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the

I was talking about v3.16.7

This doesn't have e.g. the swiotlb/dma fixes which you have had backported, those are in the ckt kernels only.

Ian.

#20 lore raw
Quoted 41 lines · Ian Campbell
Quoted 25 lines · Stefano Stabellini
Quoted 24 lines · Ian Campbell
Quoted 12 lines · Ian Campbell

I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)

Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.

I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).

Quoted 7 lines

So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.

Stefano, do you have another preference?

We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.

Quoted 8 lines
Quoted 4 lines

Stefano,

Please could you pull from git://kernel.ubuntu.com/ubuntu/linux.git and the force push::

Actually I think we should follow

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.16.y

There are no more updates to this, since it is not a kernel.org LTS kernel.

The canonical kernel team (ckt in the tag name) are doing ongoing stable support for these kernels (which is also being consumed by Debian).

Quoted 6 lines
Quoted 3 lines
Quoted 1 line

The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the

I was talking about v3.16.7

This doesn't have e.g. the swiotlb/dma fixes which you have had backported, those are in the ckt kernels only.

You are right, I was mistaken. However keep in mind that only the ubuntu stable branch linux-3.16.y-queue has the following important backport:

commit 342443e998bd2dd6406d46c5f7e62540a6d4a170

Author: Stefano Stabellini <[email protected]>
Date:   Fri Nov 21 11:07:39 2014 +0000

xen/arm/arm64: introduce xen_arch_need_swiotlb

commit a4dba130891271084344c12537731542ec77cb85 upstream.

Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer.

the main linux-3.16.y branch (currently tagged v3.16.7-ckt4) doesn't have it yet.

Without it, DMA is not safe with non-coherent devices.

#21 lore raw
Quoted 10 lines · Stefano Stabellini

You are right, I was mistaken. However keep in mind that only the ubuntu stable branch linux-3.16.y-queue has the following important backport:

commit 342443e998bd2dd6406d46c5f7e62540a6d4a170

Author: Stefano Stabellini <[email protected]>
Date:   Fri Nov 21 11:07:39 2014 +0000

xen/arm/arm64: introduce xen_arch_need_swiotlb

Quoted 8 lines

commit a4dba130891271084344c12537731542ec77cb85 upstream.

Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer.

the main linux-3.16.y branch (currently tagged v3.16.7-ckt4) doesn't have it yet.

Without it, DMA is not safe with non-coherent devices.

Hrm, how unfortunate. We expect that patch to land in ckt5 I suppose?

I think we can either wait for ckt5 or you could apply it to your branch, which means future versions would need merging not fast-forwarding. Not horrendous I suppose.