[PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms

[PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms

[Ian Campbell]

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

I have run a full (including host reinstall) build-* job on each
platform on v3, but not on v4 which is mostly functionality unchanged.

Since v4 I've wrapped the commit messages. Resending with that done on
your request.

The system is also now in the osstest rack here in Cambridge (pending
move to the new colo). For reference the relevant bits of my
~/.xen-osstest/config are below, updated for new DNS and boards renamed
with the their type as a prefix (per discussion IRL).

A bunch of the early patches have gone in already, including all the
mg-debian-installer-update related stuff, and it has been rerun so there
is no longer a dependency on rerunning it.

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

[PATCH OSSTEST v4 01/13] make-flight: Run a basic test on each arm platform

[Ian Campbell]

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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
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

diff --git a/Osstest/HostDB/Executive.pm b/Osstest/HostDB/Executive.pm
index b2c8dc9..6257829 100644
--- a/Osstest/HostDB/Executive.pm
+++ b/Osstest/HostDB/Executive.pm
@@ -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) = @_;
 
diff --git a/Osstest/HostDB/Static.pm b/Osstest/HostDB/Static.pm
index ad18395..60f5d3c 100644
--- a/Osstest/HostDB/Static.pm
+++ b/Osstest/HostDB/Static.pm
@@ -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) = @_;
 
diff --git a/README b/README
index b727a6f..6e63e97 100644
--- a/README
+++ b/README
@@ -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
diff --git a/cri-getplatforms b/cri-getplatforms
new file mode 100755
index 0000000..067730c
--- /dev/null
+++ b/cri-getplatforms
@@ -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 $!;
+        '
+}
diff --git a/make-flight b/make-flight
index a91f256..97e7a06 100755
--- a/make-flight
+++ b/make-flight
@@ -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                                       \
-- 
2.1.4

[PATCH OSSTEST v4 02/13] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU

[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+.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
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

diff --git a/Osstest/PDU/eth008.pm b/Osstest/PDU/eth008.pm
new file mode 100644
index 0000000..fc5fa96
--- /dev/null
+++ b/Osstest/PDU/eth008.pm
@@ -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;
-- 
2.1.4

Re: [PATCH OSSTEST v4 02/13] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 02/13] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU"):
> 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+.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

[PATCH OSSTEST v4 03/13] Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs

[Ian Campbell]

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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
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(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 7081a29..0a69aca 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -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: $!";
-- 
2.1.4

Re: [PATCH OSSTEST v4 03/13] Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 03/13] Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs"):
> This is done whenever dtbs.tar.gz exists. mg-debian-installer-update
> produces the necessary inputs on the relevant platform (armhf).

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

[PATCH OSSTEST v4 04/13] Osstest/Debian: Support for loading an FDT from u-boot script

[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.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v2: Refactor uboot dtb loading scriptlet, which previously appeared
    twice
---
 Osstest/Debian.pm | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 0a69aca..8b70442 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -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
-- 
2.1.4

[PATCH OSSTEST v4 05/13] Osstest/Debian: Refactor setting of dom0 kernel command line.

[Ian Campbell]

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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8b70442..0b047df 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -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
-- 
2.1.4

Re: [PATCH OSSTEST v4 05/13] Osstest/Debian: Refactor setting of dom0 kernel command line.

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 05/13] Osstest/Debian: Refactor setting of dom0 kernel command line."):
> This will make it easier to make components optional in the future.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs

[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.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v3: Honour rootdelay when booting dom 0.
---
 Osstest/Debian.pm | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 0b047df..276457e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -135,11 +135,13 @@ sub setupboot_uboot ($$$) {
 	my $initrd = "initrd.img-$want_kernver";
 
 	my $root= target_guest_lv_name($ho,"root");
+	my $rootdelay=get_host_property($ho, "rootdelay");
 
 	my @xenkopt;
 	push @xenkopt, $xenkopt;
 	push @xenkopt, "ro";
 	push @xenkopt, "root=$root";
+	push @xenkopt, "rootdelay=$rootdelay" if $rootdelay;
 
 	$xenkopt = join ' ', @xenkopt;
 
@@ -701,9 +703,11 @@ END
 	my @bootargs;
 
 	my $root=target_guest_lv_name($ho,"root");
+	my $rootdelay=get_host_property($ho, "rootdelay");
 	my $console=get_host_native_linux_console($ho);
 
 	push @bootargs, "root=$root";
+	push @bootargs, "rootdelay=$rootdelay" if $rootdelay;
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;
-- 
2.1.4

Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):
> 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.

The two hunks in this patch are starting to be rather similar.
Perhaps it would be worth combining them ?  (I notice that the
setup_uboot one doesn't handle the console - presumably it is right by
default, but perhaps it ought to use the common console selection, if
it does the right thing by default.)

> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs

[Ian Campbell]

On Wed, 2015-01-21 at 11:58 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):
> > 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.
> 
> The two hunks in this patch are starting to be rather similar.
> Perhaps it would be worth combining them ?

Yes it would. Below is the incremental patch to the end of the series,
which I will fold appropriately back into a precursor to do the refactor
and then this patch adding the rootdelay (nb I fixed the spacing you
complained about elsewhere while I was here).

Are you OK with me keeping your ack on this one once updated? It would
be essentially either of the two current hunks applied to the new
function instead.

BTW, another side effect is adding "ro" in the Xen case, which I think
was a bug to omit until now, I'll find an appropriate place to fix that.

Ian.

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 20485e2..a94f847 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -114,6 +114,21 @@ sub bl_getmenu_open ($$$) {
     return $f;
 }
 
+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;
+}
+
 sub uboot_scr_load_dtb () {
     return <<'END';
 if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
@@ -134,18 +149,12 @@ sub setupboot_uboot ($$$) {
 	my $kern = "vmlinuz-$want_kernver";
 	my $initrd = "initrd.img-$want_kernver";
 
-	my $root= target_guest_lv_name($ho,"root");
-	my $rootdelay=get_host_property($ho, "rootdelay");
 	my $natcons=get_host_native_linux_console($ho);
 
 	logm("Xen options: $xenhopt");
 
 	# Common kernel options
-	my @kopt;
-
-	push @kopt, "ro";
-	push @kopt, "root=$root";
-	push @kopt, "rootdelay=$rootdelay" if $rootdelay;
+	my @kopt = uboot_common_kernel_bootargs($ho);
 
 	# Dom0 specific kernel options
 	my @xenkopt = @kopt;
@@ -731,14 +740,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 $rootdelay=get_host_property($ho, "rootdelay");
 	my $console=get_host_native_linux_console($ho);
 
-	push @bootargs, "root=$root";
-	push @bootargs, "rootdelay=$rootdelay" if $rootdelay;
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;

Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):
> Are you OK with me keeping your ack on this one once updated? It would
> be essentially either of the two current hunks applied to the new
> function instead.

Yes.

> BTW, another side effect is adding "ro" in the Xen case, which I think
> was a bug to omit until now, I'll find an appropriate place to fix that.

> +sub uboot_common_kernel_bootargs ($)
> +{
> +    my ( $ho ) = @_;
           ^   ^
Coding style.

Otherwise,

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr

[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.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
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(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 276457e..c9e11fe 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -149,9 +149,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
@@ -169,14 +173,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})
-- 
2.1.4

Re: [PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr"):
> 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.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

(I expect you agree with me that the fact we can't get this
information some other way is a defect elsewhere, but this is a fine
workaround.)

Ian.

Re: [PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr

[Ian Campbell]

On Wed, 2015-01-21 at 12:00 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr"):
> > 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.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> (I expect you agree with me that the fact we can't get this
> information some other way is a defect elsewhere, but this is a fine
> workaround.)

Yeah, all the other similar envvars are part of the board configuration
in the u-boot source. We could start trying to upstream a patch for each
platform to define an address for Xen, but I don't know how well it
would go down, or we could try and (ab)use e.g. $script_addr.

For now I prefer to just add it to the hostdb and the relevant wiki page
for the platform.

Ian.

[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line

[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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
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 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c9e11fe..f03ece5 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -141,6 +141,7 @@ sub setupboot_uboot ($$$) {
 	push @xenkopt, $xenkopt;
 	push @xenkopt, "ro";
 	push @xenkopt, "root=$root";
+	push @xenkopt, "clk_ignore_unused"; # http://bugs.xenproject.org/xen/bug/45
 	push @xenkopt, "rootdelay=$rootdelay" if $rootdelay;
 
 	$xenkopt = join ' ', @xenkopt;
-- 
2.1.4

Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> 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

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> 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

Actually, despite my email just now acking this: perhaps you could
gate this on $suite ?

That way at the very least we'll be prompted every couple of years to
see if this is still needed.

Ian.

Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line

[Ian Campbell]

On Wed, 2015-01-21 at 12:02 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> > 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
> 
> Actually, despite my email just now acking this: perhaps you could
> gate this on $suite ?
> 
> That way at the very least we'll be prompted every couple of years to
> see if this is still needed.

Sure. Since I know already that this won't be fixed in Jessie I propose
to insert an "if $ho->{Suite} =~ m/wheezy|jessie/;" right from the get
go, as below.

Are you OK with your Ack being retained with that? (I'll mention Jessie
in the commit log too).

Ian.

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index a94f847..aef1b37 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -159,7 +159,9 @@ sub setupboot_uboot ($$$) {
 	# Dom0 specific kernel options
 	my @xenkopt = @kopt;
 	push @xenkopt, $xenkopt;
-	push @xenkopt, "clk_ignore_unused"; # http://bugs.xenproject.org/xen/bug/45
+	# 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");

Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
> On Wed, 2015-01-21 at 12:02 +0000, Ian Jackson wrote:
> > That way at the very least we'll be prompted every couple of years to
> > see if this is still needed.
> 
> Sure. Since I know already that this won't be fixed in Jessie I propose
> to insert an "if $ho->{Suite} =~ m/wheezy|jessie/;" right from the get
> go, as below.

Right.

> Are you OK with your Ack being retained with that? (I'll mention Jessie
> in the commit log too).

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize

[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

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
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(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index f03ece5..96b823a 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -187,7 +187,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
@@ -195,7 +195,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
-- 
2.1.4

Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):
> $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

It seems that u-boot think there is a bug here and perhaps even intend
to fix it.  So this workaround could be gated on $suite ?  (Or on the
u-boot version somehow if we are making our own - I forget.)

Ian.

Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize

[Ian Campbell]

On Wed, 2015-01-21 at 12:04 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):
> > $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
> 
> It seems that u-boot think there is a bug here and perhaps even intend
> to fix it.  So this workaround could be gated on $suite ?  

The conversation continued into November, which the archives helpfully
don't reflect:
http://lists.denx.de/pipermail/u-boot/2014-November/194070.html (I'll
add that one to the commit log too). The end result is "documentation
bug" http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.

> (Or on the u-boot version somehow if we are making our own - I forget.)

I am providing the u-boot, but it is outside of osstest (via [1]) and
TBH once deployed (esp. remotely) I don't expect to want to change it.

Ian.

[1]
http://xenbits.xen.org/gitweb/?p=people/ianc/osstest/boards.git;a=summary

Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):
> On Wed, 2015-01-21 at 12:04 +0000, Ian Jackson wrote:
> The conversation continued into November, which the archives helpfully
> don't reflect:
> http://lists.denx.de/pipermail/u-boot/2014-November/194070.html (I'll
> add that one to the commit log too). The end result is "documentation
> bug" http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.

Bah.  OK then.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[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.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
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(+)

diff --git a/ts-kernel-build b/ts-kernel-build
index f02205f..b2f19cf 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -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;
-- 
2.1.4

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> 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.
...
> +# 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

I think these should be gated on the kernel version and/or arch or
something.  After all, disabling modules is a workaround (and risks
making things not work in the future in an annoyingly mysterious way).

> +# 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

This part is all fine.

Thanks,
Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Campbell]

On Wed, 2015-01-21 at 12:05 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> > 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.
> ...
> > +# 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
> 
> I think these should be gated on the kernel version and/or arch or
> something.  After all, disabling modules is a workaround (and risks
> making things not work in the future in an annoyingly mysterious way).

Arch I can easily do.

Not sure how easy it will be to get the kern ver, currently we get it
from the name of the subdir created in /lib/modules by the kernel
install, which is too late of course.

Not sure if there is some other surrogate we could use.

FWIW LM90 is some i2c temperature sensor thing which I doubt we are
exercising (i.e. we aren't installed lmsensors packages) and ICS932S401
is some equally uninteresting i2c sensor device. I think it's pretty
unlikely we would suddenly trip over an x86 system with these and for
ARM each new platform is likely to need some dev work to add etc anyway.
In neither case do I think we would miss these devices in practice.

Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Campbell]

On Wed, 2015-01-21 at 13:20 +0000, Ian Campbell wrote:
> On Wed, 2015-01-21 at 12:05 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> > > 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.
> > ...
> > > +# 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
> > 
> > I think these should be gated on the kernel version and/or arch or
> > something.  After all, disabling modules is a workaround (and risks
> > making things not work in the future in an annoyingly mysterious way).
> 
> Arch I can easily do.
> 
> Not sure how easy it will be to get the kern ver,

"make kernelversion" will return the version from the Makefile (i.e. not
including any localversion stuff). The question then becomes what the
white/blacklist should look like.

Should I list all the current linux-* branch versions? How should we
handle e.g. linux-next and linux-linus?

Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> On Wed, 2015-01-21 at 12:05 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> > > 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.
> > ...
> >
> > > +# 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
> > 
> > I think these should be gated on the kernel version and/or arch or
> > something.  After all, disabling modules is a workaround (and risks
> > making things not work in the future in an annoyingly mysterious way).
> 
> Arch I can easily do.
> 
> Not sure how easy it will be to get the kern ver, currently we get it
> from the name of the subdir created in /lib/modules by the kernel
> install, which is too late of course.

Hmm.

> Not sure if there is some other surrogate we could use.
> 
> FWIW LM90 is some i2c temperature sensor thing which I doubt we are
> exercising (i.e. we aren't installed lmsensors packages) and ICS932S401
> is some equally uninteresting i2c sensor device. I think it's pretty
> unlikely we would suddenly trip over an x86 system with these and for
> ARM each new platform is likely to need some dev work to add etc anyway.
> In neither case do I think we would miss these devices in practice.

That answers my concerns for the ones above.  But:

> > > +# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't
> > > +# support that platform anyway.
> > > +setopt CONFIG_ARCH_EXYNOS4 n

This is a particular kind of board ?  In which case, fine.

> > > +# Having these on breaks USB
> > > +setopt CONFIG_SAMSUNG_USB2PHY n
> > > +setopt CONFIG_SAMSUNG_USB3PHY n

I don't know what this is.  Convince me it's harmless to disable ? :-)

Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Campbell]

On Wed, 2015-01-21 at 16:20 +0000, Ian Jackson wrote:
> > > > +# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't
> > > > +# support that platform anyway.
> > > > +setopt CONFIG_ARCH_EXYNOS4 n
> 
> This is a particular kind of board ?  In which case, fine.

It's a class of SoC (i.e. SoC models 4xxx), however virtualisation
support was only added to EXYNOS 5xxx onwards, so I don't think we will
ever care about EXYNOS4 in osstest.

However:
https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg41070.html
might cause this to change at some point.

> > > > +# Having these on breaks USB
> > > > +setopt CONFIG_SAMSUNG_USB2PHY n
> > > > +setopt CONFIG_SAMSUNG_USB3PHY n
> 
> I don't know what this is.  Convince me it's harmless to disable ? :-)

They are phy drivers for the USB on some samsung SoC or other, I'm not
sure which. I do know that they aren't needed for any of the peripherals
on the Arndale which we need, like the USB Ethernet.

Exynos' support for multiplatform kernels (i.e. ones which run on
several SoCs instead of being compiled for a single system) is pretty
immature at the moment, since it is pretty new. I'd expect that
eventually some of these quirks will go away, but at that point we still
won't care about these options, I think.

Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> On Wed, 2015-01-21 at 16:20 +0000, Ian Jackson wrote:
> > I don't know what this is.  Convince me it's harmless to disable ? :-)
> 
> [stuff]

OK, thanks.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Campbell]

On Wed, 2015-01-21 at 16:36 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> > On Wed, 2015-01-21 at 16:20 +0000, Ian Jackson wrote:
> > > I don't know what this is.  Convince me it's harmless to disable ? :-)
> > 
> > [stuff]
> 
> OK, thanks.
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.

I think that means everything is now acked. I'll repost one final time
(likely tomorrow), since I've changed a few things (as discussed), then
we can talk about commissioning etc.

Cheers,
Ian.

Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
> Thanks.
> 
> I think that means everything is now acked. I'll repost one final time
> (likely tomorrow), since I've changed a few things (as discussed), then
> we can talk about commissioning etc.

Right.

Ian.

[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr

[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.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 96b823a..8169c01 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -162,12 +162,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}
@@ -203,7 +203,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
     };
 
@@ -725,7 +726,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
@@ -736,7 +737,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
     }
 
-- 
2.1.4

Re: [PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr"):
> 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.

I confess I don't quite see how this works, due to my lack of
understanding of u-boot et al's plumbing, but I see nothing to object
to.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr

[Ian Campbell]

On Wed, 2015-01-21 at 12:08 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr"):
> > 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.
> 
> I confess I don't quite see how this works, due to my lack of
> understanding of u-boot et al's plumbing, but I see nothing to object
> to.

u-boot essential does "load $script_addr $boot_script ; source
$script_addr", all this does is mean one can conveniently do "setenv
boot_script boot.scr.$foo; boot" (for foo in deb, nat, xen) to override
the default of boot.scr if you've borked it somehow.

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks.
Ian.

[PATCH OSSTEST v4 12/13] TestSupport: replace power_cycle_timeout with power_cycle_sleep

[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...

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/TestSupport.pm | 10 ++++++----
 ts-host-install        |  2 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 5ac66e5..8d070ab 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -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);
 }
 
diff --git a/ts-host-install b/ts-host-install
index 30f6465..ae1d228 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -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);
-- 
2.1.4

Re: [PATCH OSSTEST v4 12/13] TestSupport: replace power_cycle_timeout with power_cycle_sleep

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 12/13] TestSupport: replace power_cycle_timeout with power_cycle_sleep"):
> 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...

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

[PATCH OSSTEST v4 13/13] Debian: create boot.scr.nat when installing Xen on u-boot.

[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.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: New patch
---
 Osstest/Debian.pm | 40 ++++++++++++++++++++++++++++++++++------
 1 file changed, 34 insertions(+), 6 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8169c01..20485e2 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -136,18 +136,32 @@ sub setupboot_uboot ($$$) {
 
 	my $root= target_guest_lv_name($ho,"root");
 	my $rootdelay=get_host_property($ho, "rootdelay");
+	my $natcons=get_host_native_linux_console($ho);
 
-	my @xenkopt;
+	logm("Xen options: $xenhopt");
+
+	# Common kernel options
+	my @kopt;
+
+	push @kopt, "ro";
+	push @kopt, "root=$root";
+	push @kopt, "rootdelay=$rootdelay" if $rootdelay;
+
+	# Dom0 specific kernel options
+	my @xenkopt = @kopt;
 	push @xenkopt, $xenkopt;
-	push @xenkopt, "ro";
-	push @xenkopt, "root=$root";
 	push @xenkopt, "clk_ignore_unused"; # http://bugs.xenproject.org/xen/bug/45
-	push @xenkopt, "rootdelay=$rootdelay" if $rootdelay;
 
 	$xenkopt = join ' ', @xenkopt;
+	logm("Dom0 Linux options: $xenkopt");
 
-	logm("Xen options: $xenhopt");
-	logm("Linux options: $xenkopt");
+	# Native specific kernel options
+
+	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);
@@ -205,6 +219,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
     };
 
-- 
2.1.4

Re: [PATCH OSSTEST v4 13/13] Debian: create boot.scr.nat when installing Xen on u-boot.

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v4 13/13] Debian: create boot.scr.nat when installing Xen on u-boot."):
> 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.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> v4: New patch
> ---
>  Osstest/Debian.pm | 40 ++++++++++++++++++++++++++++++++++------
>  1 file changed, 34 insertions(+), 6 deletions(-)
> 
> diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
> index 8169c01..20485e2 100644
> --- a/Osstest/Debian.pm
> +++ b/Osstest/Debian.pm
> @@ -136,18 +136,32 @@ sub setupboot_uboot ($$$) {
>  
>  	my $root= target_guest_lv_name($ho,"root");
>  	my $rootdelay=get_host_property($ho, "rootdelay");
> +	my $natcons=get_host_native_linux_console($ho);

The coding style here (missing spaces to rhs of =) is getting worse.
The existing code is inconsistent between ` = ' and `= ' but I think
adding `=' too is not helping...

> +	# Native specific kernel options
> +
> +	my @natkopt = @kopt;
> +	push @natkopt, "console=$natcons" unless $natcons eq "NONE";

Ah I think this answers my question about native console, from
earlier.

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

Re: [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms

[Ian Campbell]

On Wed, 2015-01-21 at 11:17 +0000, Ian Campbell wrote:

I initially forgot to set the new UBootSetXenAddrR property on the
existing midway systems, as required by 653d0af2fd70 "Osstest/Debian:
Remove hardcoded addresses from boot.scr", so the initial flight failed.

The flight which is currently in progress (33888) has failed
ts-host-reboot on arm with (from the serial log):
        12349569 bytes read in 401 ms (29.4 MiB/s)
        Sorry, I could not convert "xbc7081>"
        Loaded initrd.img-3.16.7-ckt4+ to 0x04000000 (0xbc7081)

The ts-xen-install log shows that the relevant fragment of boot.scr is:
        ext2load scsi 0 \${ramdisk_addr_r} initrd.img-3.16.7-ckt4+
        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} 0x\${filesize}>
        echo Loaded initrd.img-3.16.7-ckt4+ to \${ramdisk_addr_r} (\${filesize})

I think this is a combination of ee5e442f15eb "Osstest/Debian: Add 0x
prefix to $filesize" from this series and a much older change in
e6e9078c80d6 "Debian: more corrections to arm u-boot rune" which removed
a space from before the ">", probably because I couldn't remember what
it was for...

It turns out that the ext2load command on midway only sets filesize with
the 0x prefix, but e.g. tftp doesn't. This doesn't occur on arndale or
cubietruck which has much newer u-boot which has this bug fixed (not
sure by what but [0] look like candidates).

Based on the email threads referenced by ee5e442f15e[1] I think we
should consider this a quirk/bug on the midway platform.

In theory I could try upgrading the u-boot firmware on these systems
(it's still supported by mainline u-boot), but to be honest with Calxeda
no longer existing I'm reluctant to do anything which might have any
chance of bricking the systems.

I'm not sure how specific to make this quirk and whether it is worth
doing via the hostdb or just directly in Debian.pm. Options:

      * Make the addition of the 0x prefix conditional on !
        platform-midway
      * Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to
        0x and set to '' on midway machines
      * A similar host flag to control the addition (or, more likely, 
        the omission of) of the 0x

Ian.

[0] http://git.denx.de/?p=u-boot.git;a=commit;h=b770e88a6c2548727f0d57a3e9e8bb0830f977b5
    http://git.denx.de/?p=u-boot.git;a=commit;h=3f83c87ee58d86e9a9d2e50b62f38c728bfb31f6

[1] 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.

Re: [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms"):
> I think this is a combination of ee5e442f15eb "Osstest/Debian: Add 0x
> prefix to $filesize" from this series and a much older change in
> e6e9078c80d6 "Debian: more corrections to arm u-boot rune" which removed
> a space from before the ">", probably because I couldn't remember what
> it was for...

Nnng.

> It turns out that the ext2load command on midway only sets filesize with
> the 0x prefix, but e.g. tftp doesn't. This doesn't occur on arndale or
> cubietruck which has much newer u-boot which has this bug fixed (not
> sure by what but [0] look like candidates).

Oh god oh god the horror.

> Based on the email threads referenced by ee5e442f15e[1] I think we
> should consider this a quirk/bug on the midway platform.

OK.

> In theory I could try upgrading the u-boot firmware on these systems
> (it's still supported by mainline u-boot), but to be honest with Calxeda
> no longer existing I'm reluctant to do anything which might have any
> chance of bricking the systems.
> 
> I'm not sure how specific to make this quirk and whether it is worth
> doing via the hostdb or just directly in Debian.pm. Options:
> 
>       * Make the addition of the 0x prefix conditional on !
>         platform-midway

I think this would be an abuse of platform-*.  You've already done
this kind of thing once with equiv-marilith in Osstest/CXFabric.pm and
I think I should have put my foot down then...

>       * A similar host flag to control the addition (or, more likely, 
>         the omission of) of the 0x

That would be fine, although AFAICT we don't really have any quirks in
the hostflags already.  It should probably be quirk-something.

>       * Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to
>         0x and set to '' on midway machines

That would be fine too (although do you expect any values other than
'' and 0x?)

Thanks,
Ian.

Re: [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms

[Ian Campbell]

On Thu, 2015-01-29 at 11:25 +0000, Ian Jackson wrote:
> Nnng.
[...]
> Oh god oh god the horror.

Quite...

> > In theory I could try upgrading the u-boot firmware on these systems
> > (it's still supported by mainline u-boot), but to be honest with Calxeda
> > no longer existing I'm reluctant to do anything which might have any
> > chance of bricking the systems.
> > 
> > I'm not sure how specific to make this quirk and whether it is worth
> > doing via the hostdb or just directly in Debian.pm. Options:
> > 
> >       * Make the addition of the 0x prefix conditional on !
> >         platform-midway
> 
> I think this would be an abuse of platform-*.  You've already done
> this kind of thing once with equiv-marilith in Osstest/CXFabric.pm and
> I think I should have put my foot down then...

I thought you'd say that ;-)

> 
> >       * A similar host flag to control the addition (or, more likely, 
> >         the omission of) of the 0x
> 
> That would be fine, although AFAICT we don't really have any quirks in
> the hostflags already.  It should probably be quirk-something.
> 
> >       * Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to
> >         0x and set to '' on midway machines
> 
> That would be fine too (although do you expect any values other than
> '' and 0x?)

It seems pretty unlikely, at least I can't think of anything plausible.
Which suggests a hostflag is the right answer...

I propose to append the following to the pretest branch (rather than
trying to fold it into some existing patch, although I can if you want)

Feel free to bikeshed the name, of course ;-)...

8<------

>From caee3d8167b107b02293b1e72dae2d76db08437c Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@citrix.com>
Date: Thu, 29 Jan 2015 11:37:39 +0000
Subject: [PATCH] Debian: Handle systems where u-boot includes 0x on $filesize

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---
 Osstest/Debian.pm | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 3c4ac5e..9b54e5e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -180,6 +180,22 @@ sub setupboot_uboot ($$$) {
 	my $set_xen_addr_r =
 	    $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : "";
 
+	# According to u-boot policy $filesize is an unprefixed hex
+	# number, but fdt set requires numbers to be prefixed
+	# (e.g. with 0x for a hex number). 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.
+	#
+	# However some older u-boot versions (e.g. on midway) erroneously
+	# include the 0x prefix when setting $filesize from ext*load
+	# commands, meaning we cannot simply unconditionally prepend
+	# the 0x. Base it on a host flag quirk.
+	my $size_hex_prefix =
+	    $ho->{Flags}{'quirk-load-filesize-has-0x-prefix'} ?
+	    '' : '0x';
+
 	target_cmd_root($ho, <<END);
 if test ! -f /boot/$kern ; then
     exit 1
@@ -210,7 +226,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} 0x\\\${filesize}>
+fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} ${size_hex_prefix}\\\${filesize}>
 fdt set /chosen/module\@0 bootargs "$xenkopt"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
 echo command line: $xenkopt
@@ -218,7 +234,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} 0x\\\${filesize}>
+fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} ${size_hex_prefix}\\\${filesize}>
 echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
 
 fdt print /chosen
-- 
2.1.4

Re: [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms

[Ian Campbell]

On Thu, 2015-01-29 at 11:44 +0000, Ian Campbell wrote:
> 8<------
> 
> From caee3d8167b107b02293b1e72dae2d76db08437c Mon Sep 17 00:00:00 2001
> From: Ian Campbell <ian.campbell@citrix.com>
> Date: Thu, 29 Jan 2015 11:37:39 +0000
> Subject: [PATCH] Debian: Handle systems where u-boot includes 0x on $filesize
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked on IRC + pushed to pretest + "./mg-hosts setflags marilith-n\* --
quirk-load-filesize-has-0x-prefix" + killed in-progress flight 33888.

Ian.