Skip to contentSkip to conversation

support for ARM32 arndale and cubietruck platforms

PATCH Superseded Ian Campbell 2 participants 45 messages Jan 21, 2015 – Jan 29, 2015

v4 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

v4 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

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

#1 lore raw

PATCH v4 1/13 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 v4 2/13 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
#4 lore raw

PATCH v4 3/13 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
#6 lore raw

PATCH v4 4/13 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
#7 lore raw

PATCH v4 5/13 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
#9 lore raw

PATCH v4 6/13 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.

---
v3: Honour rootdelay when booting dom 0.

---
 Osstest/Debian.pm | 4 ++++
 1 file changed, 4 insertions(+)
Osstest/Debian.pm +4 -0
index 0b047df..276457e 100644
@@ -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;
Signature · 1 line
2.1.4
#13 lore raw

PATCH v4 7/13 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 276457e..c9e11fe 100644
@@ -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})
Signature · 1 line
2.1.4
#16 lore raw

PATCH v4 8/13 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

---
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(+)
Osstest/Debian.pm +1 -0
index c9e11fe..f03ece5 100644
@@ -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;
Signature · 1 line
2.1.4
#21 lore raw

PATCH v4 9/13 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

---
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 f03ece5..96b823a 100644
@@ -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
Signature · 1 line
2.1.4
#25 lore raw

PATCH v4 10/13 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
#34 lore raw

PATCH v4 11/13 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 96b823a..8169c01 100644
@@ -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
     }
 
Signature · 1 line
2.1.4
#37 lore raw

PATCH v4 12/13 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
#39 lore raw

PATCH v4 13/13 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.

---
v4: New patch

---
 Osstest/Debian.pm | 40 ++++++++++++++++++++++++++++++++++------
 1 file changed, 34 insertions(+), 6 deletions(-)
Osstest/Debian.pm +34 -6
index 8169c01..20485e2 100644
@@ -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
     };
 
Signature · 1 line
2.1.4
Acked-by on v4 2/13
#3 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 02/13] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU"):

Quoted 4 lines

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 on v4 3/13
#5 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 03/13] Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs"):

Quoted 2 lines

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

Acked-by on v4 5/13
#8 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 05/13] Osstest/Debian: Refactor setting of dom0 kernel command line."):

Quoted 1 line

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

Ian.

#10 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):

Quoted 5 lines

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

Quoted 2 lines

Ian.

Acked-by on v4 7/13
#14 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr"):

Quoted 7 lines

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.

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

Acked-by on v4 8/13
#17 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 7 lines

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

Ian.

#18 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 7 lines

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.

#22 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 3 lines

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

#26 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 3 lines

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.

...

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186

Quoted 13 lines
ts-kernel-build +13 -0
+# 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).

Quoted 8 lines
ts-kernel-build +8 -0
+# 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

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 205

Quoted 10 lines
ts-kernel-build +10 -0
+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.

Acked-by on v4 11/13
#35 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr"):

Quoted 3 lines

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.

Ian.

Acked-by on v4 12/13
#38 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 12/13] TestSupport: replace power_cycle_timeout with power_cycle_sleep"):

Quoted 4 lines

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 on v4 13/13
#40 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("[PATCH OSSTEST v4 13/13] Debian: create boot.scr.nat when installing Xen on u-boot."):

Quoted 17 lines

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.

---
v4: New patch

---
 Osstest/Debian.pm | 40 ++++++++++++++++++++++++++++++++++------
 1 file changed, 34 insertions(+), 6 deletions(-)
Osstest/Debian.pm +0 -0
index 8169c01..20485e2 100644

Osstest/Debian.pm sub setupboot_uboot ($$$) { · line 139

Quoted 4 lines
Osstest/Debian.pm +1 -0
@@ -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...

Osstest/Debian.pm sub setupboot_uboot ($$$) { · line 161

Quoted 4 lines
Osstest/Debian.pm +4 -0
+	# 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.

Ian.

#23 lore raw

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

In reply to Ian Jackson
Quoted 7 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 3 lines

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

Quoted 1 line

(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

#15 lore raw

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

In reply to Ian Jackson
Quoted 6 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr"):

Quoted 5 lines

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.

Quoted 8 lines
Quoted 2 lines

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

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

#36 lore raw

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

In reply to Ian Jackson
Quoted 8 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr"):

Quoted 3 lines

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.

Quoted 1 line

Thanks.
Ian.

#11 lore raw

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

In reply to Ian Jackson
Quoted 9 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):

Quoted 5 lines

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.

Osstest/Debian.pm +17 -12
index 20485e2..a94f847 100644
@@ -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;
#19 lore raw

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

In reply to Ian Jackson
Quoted 9 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 7 lines

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

Quoted 5 lines

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.

Osstest/Debian.pm +3 -1
index a94f847..aef1b37 100644
@@ -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");
#27 lore raw

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

In reply to Ian Jackson
Quoted 14 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 3 lines

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.

...

Quoted 9 lines
ts-kernel-build +9 -0
+# 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.
Quoted 8 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186

Quoted 4 lines
ts-kernel-build +4 -0
+# 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.

#28 lore raw

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

Quoted 24 lines · Ian Campbell
Quoted 14 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 3 lines

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.

...

Quoted 9 lines
ts-kernel-build +9 -0
+# 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.
Quoted 8 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186

Quoted 4 lines
ts-kernel-build +4 -0
+# 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).

Quoted 3 lines

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.

Acked-by
#24 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 6 lines · Ian Jackson

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.

Ian.

Acked-by
#12 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):

Quoted 3 lines

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.

Osstest/Debian.pm sub bl_getmenu_open ($$$) { · line 119

Quoted 6 lines

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.

Osstest/Debian.pm +3 -0
+sub uboot_common_kernel_bootargs ($)
+{
+    my ( $ho ) = @_;
           ^   ^

Coding style.

Otherwise,

Ian.

Acked-by
#20 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 7 lines · Ian Jackson
Quoted 2 lines

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.

Quoted 2 lines

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

Thanks,
Ian.

#29 lore raw

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

In reply to Ian Campbell

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 17 lines · Ian Jackson
Quoted 6 lines

Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 3 lines

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.

...

Quoted 9 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186

Quoted 5 lines
ts-kernel-build +5 -0
+# 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).

Quoted 5 lines

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.

Quoted 8 lines

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:

Quoted 3 lines
Quoted 3 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 176

Quoted 3 lines
ts-kernel-build +3 -0
+# 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.

Quoted 3 lines
Quoted 3 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 180

Quoted 3 lines
ts-kernel-build +3 -0
+# 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.

#30 lore raw

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

Quoted 5 lines · Ian Jackson
Quoted 3 lines
Quoted 3 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 176

Quoted 3 lines
ts-kernel-build +3 -0
+# 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/[email protected]/msg41070.html
might cause this to change at some point.

Quoted 5 lines
Quoted 3 lines
Quoted 3 lines

ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 180

Quoted 3 lines
ts-kernel-build +3 -0
+# 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.

Acked-by
#31 lore raw

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

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 4 lines · Ian Jackson
Quoted 1 line

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

[stuff]

OK, thanks.

Ian.

#32 lore raw

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

Quoted 9 lines · Ian Jackson

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 4 lines · Ian Jackson
Quoted 1 line

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

[stuff]

OK, thanks.

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.

#33 lore raw

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

Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):

Quoted 5 lines

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.

#41 lore raw
In reply to 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.
#42 lore raw

Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms"):

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 2 lines

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

OK.

Quoted 10 lines

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

Quoted 2 lines

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

Quoted 2 lines

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

#43 lore raw
Quoted 1 line · Ian Jackson

Nnng.

[...]

Quoted 1 line

Oh god oh god the horror.

Quite...

Quoted 8 lines
Quoted 8 lines

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:

Quoted 6 lines
Quoted 2 lines

* 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 ;-)

Quoted 4 lines
Quoted 3 lines

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

Quoted 8 lines

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

Quoted 2 lines

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

Quoted 1 line

From caee3d8167b107b02293b1e72dae2d76db08437c Mon Sep 17 00:00:00 2001

From: Ian Campbell <[email protected]>
Date: Thu, 29 Jan 2015 11:37:39 +0000
Subject: [PATCH] Debian: Handle systems where u-boot includes 0x on $filesize

---
 Osstest/Debian.pm | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)
Osstest/Debian.pm +18 -2
index 3c4ac5e..9b54e5e 100644
@@ -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
Signature · 1 line
2.1.4
#44 lore raw
Quoted 8 lines · Ian Campbell

8<------

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

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

Ian.