Skip to contentSkip to conversation

support for ARM32 arndale and cubietruck platforms

RFC PATCH Superseded Ian Campbell 4 participants 110 messages Oct 10, 2014 – Nov 12, 2014

v1 of 5 Superseded Latest is v5 →

lore
Share & tools
lore
#0 lore raw

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.

I have successfully run test-armhf-armhf-xl on cubietruck, but not yet on arndale (struggling to find a pvops config which boots, even natively!). I thought I'd send the bulk out to get started with.

For reference the relevant bits of my ~/.xen-osstest/config are below.

Ian.

#HostProp_metrocentre_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 1 HostProp_westfield_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 2 HostProp_lakeside_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 3 HostProp_bluewater_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 4

HostProp_braque_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 5 HostProp_picaso_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 6 HostProp_metzinger_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 7 HostProp_gleizes_PowerMethod eth008 arm-pdu-01.uk.xensource.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_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000

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

HostGroup_metrocentre arndale HostProp_metrocentre_Fqdn metrocentre.uk.xensource.com HostProp_metrocentre_Ether 9e:04:00:59:64:5a

HostGroup_westfield arndale HostProp_westfield_Fqdn westfield.uk.xensource.com HostProp_westfield_Ether a6:46:13:77:e8:2f

HostGroup_lakeside arndale
HostProp_lakeside_Fqdn lakeside.uk.xensource.com
HostProp_lakeside_Ether e2:e7:75:3f:df:4c

HostGroup_bluewater arndale HostProp_bluewater_Fqdn bluewater.uk.xensource.com HostProp_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_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000 HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

HostGroup_braque cubietruck
HostProp_braque_Fqdn braque.uk.xensource.com

HostGroup_picaso cubietruck
HostProp_picaso_Fqdn picaso.uk.xensource.com

HostGroup_metzinger cubietruck
HostProp_metzinger metzinger.uk.xensource.com

HostGroup_gleizes cubietruck
HostProp_gleizes_Fqdn gleizes.uk.xensource.com

#1 lore raw

RFC PATCH 1/19 standalone: Provide a helper to clear the host runvar

---
 standalone | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
standalone +18 -0
index daab7ae..c1139f8 100755
@@ -29,6 +29,12 @@ Operations:
 
   Required options: -h HOST
 
+* reset-host [cf] [JOB]
+
+  Allow a job which has been run before to run on a different host
+  next time. Otherwise osstest will complain if you change the host
+  which a job is running on on successive runs.
+
 Options:
 
 -c FILE, --config=FILE        Use FILE as configuration file
@@ -200,6 +206,18 @@ case $op in
 	fi
 	;;
 
+    reset-host)
+	need_flight;
+
+	if [ $# -lt 1 ] ; then
+	    echo "run-job: Need job" >&2
+	    exit 1
+	fi
+
+	job=$1; shift
+	./cs-adjust-flight -v $flight runvar-del $job host
+	;;
+
     run-job)
 	need_flight; need_host
 
Signature · 1 line
2.1.0
Acked-by on v1 1/19
#2 lore raw

Re: [PATCH RFC OSSTEST 01/19] standalone: Provide a helper to clear the host runvar

Ian Campbell writes ("[PATCH RFC OSSTEST 01/19] standalone: Provide a helper to clear the host runvar"):

Quoted 1 line

Of course this only works for jobs with a single host whose runvar is host' rather than (say) src_host' or whatever. But:

#3 lore raw

Re: [PATCH RFC OSSTEST 01/19] standalone: Provide a helper to clear the host runvar

Quoted 5 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 01/19] standalone: Provide a helper to clear the host runvar"):

Quoted 1 line

Of course this only works for jobs with a single host whose runvar is host' rather than (say) src_host' or whatever.

Ah yes, I suppose I never run such tests in standalone mode.

Is there some way to specify multiple hosts? OSSTEST_HOST_SRC_HOST= and OSSTEST_HOST_DST_HOST= perhaps?

Quoted 3 lines

But:

#4 lore raw

RFC PATCH 2/19 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+.

---
 Osstest/PDU/eth008.pm | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)
 create mode 100644 Osstest/PDU/eth008.pm
Osstest/PDU/eth008.pm new file +68 -0
new file mode 100644
index 0000000..da6af78
@@ -0,0 +1,68 @@
+# 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 IO::File;
+
+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 $url = "http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0";
+    my $cmd = "curl --silent --user $mo->{User}:$mo->{Pass} $url";
+
+    logm("$cmd");
+    open CURL, "$cmd |" or die "fork curl: $!";
+    
+    my $result = <CURL>;
+    close CURL or die "result curl: $!";
+
+    logm("$result");
+    die "curl failed" unless $result =~ /^Success! \d+/;
+}
+
+1;
Signature · 1 line
2.1.0
#5 lore raw

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

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

Quoted 3 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+.

In the future we are likely to want to have more community members working with osstest and that probably means we want to have a less juicy `inside' to our network.

That probably means nontrivial passwords, but it also probably means we'll want to stop passing passwords on command lines.

Osstest/PDU/eth008.pm line 56

Quoted 2 lines
Osstest/PDU/eth008.pm new file +2 -0
+    my $url = "http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0";
+    my $cmd = "curl --silent --user $mo->{User}:$mo->{Pass} $url";

Is there a way to do this where the password goes in a file or via an fd ?

I'm tempted to suggest that you should use the non-CGI interface and get the firewall fixed...

Ian.

#6 lore raw

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

Quoted 9 lines · Ian Jackson

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

Quoted 3 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+.

In the future we are likely to want to have more community members working with osstest and that probably means we want to have a less juicy `inside' to our network.

Quoted 8 lines

That probably means nontrivial passwords, but it also probably means we'll want to stop passing passwords on command lines.

Osstest/PDU/eth008.pm line 56

Quoted 2 lines
Osstest/PDU/eth008.pm new file +2 -0
+    my $url = "http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0";
+    my $cmd = "curl --silent --user $mo->{User}:$mo->{Pass} $url";

Is there a way to do this where the password goes in a file or via an fd ?

There's --netrc which looks in ~/.netrc (or use --netrc-file).

Quoted 2 lines

I'm tempted to suggest that you should use the non-CGI interface and get the firewall fixed...

Probably easiest to do it as part of the move, when we (I pressume) gain control over the f/w, if any, between control host and test machines?

I could code it as an option for now if you like.

Ian.

#7 lore raw

RFC PATCH 3/19 mg-debian-installer-update: Include any device tree blobs in the tftp dir

In reply to Ian Campbell

We will need to supply these for some arm boards.

We provide both an unpacked version, which can be referenced via u-boot's support for the "fdtdir" property in pxelinux.cfg and a tarball which is more convenient for installing into the target filesystem on host install

---
 mg-debian-installer-update | 4 ++++
 1 file changed, 4 insertions(+)
mg-debian-installer-update +4 -0
index b964f95..4e1da8a 100755
@@ -130,6 +130,10 @@ if [ $arch = armhf ]; then
           |pax -x sv4cpio -s '%lib%/lib%' -d -w >../cpio; cd ..
     gzip -9f cpio
     mv cpio.gz armmp.cpio.gz
+    rm -rf dtbs/
+    mkdir dtbs/
+    mv x/usr/lib/linux-image-*-armmp/*.dtb dtbs/
+    tar -caf dtbs.tar.gz dtbs
     rm -rf x
 fi
 
Signature · 1 line
2.1.0
Acked-by on v1 3/19
#8 lore raw

Re: [PATCH RFC OSSTEST 03/19] mg-debian-installer-update: Include any device tree blobs in the tftp dir

Ian Campbell writes ("[PATCH RFC OSSTEST 03/19] mg-debian-installer-update: Include any device tree blobs in the tftp dir"):

Quoted 5 lines

We will need to supply these for some arm boards.

We provide both an unpacked version, which can be referenced via u-boot's support for the "fdtdir" property in pxelinux.cfg and a tarball which is more convenient for installing into the target filesystem on host install

#9 lore raw

RFC PATCH 4/19 mg-debian-installer-update: Add more modules when creating initrd overlay

In reply to Ian Campbell

The arndale platform has a usb network device. In addition both the SATA and NIC/USB hardware on this platform requires additional regulator (power), clk and phy modules, which in turn require i2c support.

Add everything which is needed on this platform.

Sort the list of drivers while here.

---
 mg-debian-installer-update | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
mg-debian-installer-update +10 -2
index 4e1da8a..4af4a42 100755
@@ -123,10 +123,18 @@ if [ $arch = armhf ]; then
                          -path \*/kernel/fs/mbcache.ko -o \
                          -path \*/kernel/fs/ext\* -o \
                          -path \*/kernel/fs/jbd\* -o \
-                         -path \*/kernel/drivers/net/\* -o \
+                         -path \*/kernel/drivers/clk/\* -o \
+                         -path \*/kernel/drivers/mmc/\* -o \
+                         -path \*/kernel/drivers/phy/\* -o \
+                         -path \*/kernel/drivers/usb/misc/\* -o \
                          -path \*/kernel/drivers/ata/\* -o \
+                         -path \*/kernel/drivers/i2c/busses/\* -o \
+                         -path \*/kernel/drivers/md/\* -o \
+                         -path \*/kernel/drivers/net/\* -o \
+                         -path \*/kernel/drivers/regulator/\* -o \
                          -path \*/kernel/drivers/scsi/\* -o \
-                         -path \*/kernel/drivers/md/\* \) \
+                         -path \*/kernel/drivers/usb/dwc3/\* -o \
+                         -path \*/kernel/drivers/usb/host/\* \) \
           |pax -x sv4cpio -s '%lib%/lib%' -d -w >../cpio; cd ..
     gzip -9f cpio
     mv cpio.gz armmp.cpio.gz
Signature · 1 line
2.1.0
Acked-by on v1 4/19
#10 lore raw

Re: [PATCH RFC OSSTEST 04/19] mg-debian-installer-update: Add more modules when creating initrd overlay

Ian Campbell writes ("[PATCH RFC OSSTEST 04/19] mg-debian-installer-update: Add more modules when creating initrd overlay"):

Quoted 3 lines

The arndale platform has a usb network device. In addition both the SATA and NIC/USB hardware on this platform requires additional regulator (power), clk and phy modules, which in turn require i2c support.

This is quite a list. I assume we need to do this filtering to make the initrd not too big. So:

Ian.

#11 lore raw

Re: [PATCH RFC OSSTEST 04/19] mg-debian-installer-update: Add more modules when creating initrd overlay

Quoted 7 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 04/19] mg-debian-installer-update: Add more modules when creating initrd overlay"):

Quoted 3 lines

The arndale platform has a usb network device. In addition both the SATA and NIC/USB hardware on this platform requires additional regulator (power), clk and phy modules, which in turn require i2c support.

This is quite a list. I assume we need to do this filtering to make the initrd not too big.

That was the original idea. Totally unscientifically:

$ du -shc armmp.deb,initrd.gz
23M	armmp.deb
5.2M	initrd.gz

Where the vast majority of the .deb is modules. So it is reducing the size pretty considerably.

Quoted 5 lines

So:

Ian.

#12 lore raw

RFC PATCH 5/19 ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists

In reply to Ian Campbell

u-boot's pxe client uses this together with $fdtfile in its local environment to automatically load the fdt when pxe booting.

---
 ts-host-install | 4 ++++
 1 file changed, 4 insertions(+)
ts-host-install +4 -0
index 95ce845..ca26f95 100755
@@ -188,6 +188,9 @@ SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A
 END
     }
 
+    my $dtbs = "fdtdir /$d_i/dtbs" if
+	-e "$ho->{Tftp}{Path}/$d_i/dtbs";
+
     file_simple_write_contents("$initrd_overlay.cpio", sub {
         contents_make_cpio($_[0], 'newc', "$initrd_overlay.d");
     });
@@ -222,6 +225,7 @@ label overwrite
 	kernel $kernel
 	append $installcmdline
 	ipappend $ipappend
+	$dtbs
 default overwrite
 END
 }
Signature · 1 line
2.1.0
Acked-by on v1 5/19
#13 lore raw

Re: [PATCH RFC OSSTEST 05/19] ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists

Ian Campbell writes ("[PATCH RFC OSSTEST 05/19] ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists"):

Quoted 2 lines

u-boot's pxe client uses this together with $fdtfile in its local environment to automatically load the fdt when pxe booting.

Although, bikeshedding,

ts-host-install SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A · line 193

Quoted 3 lines
ts-host-install +3 -0
+    my $dtbs = "fdtdir /$d_i/dtbs" if
+	-e "$ho->{Tftp}{Path}/$d_i/dtbs";
+

the if at the end of the line strikes me as a slightly odd style. There are many fewer of those in the codebase right now than places where it's on the start and the next line.

Ian.

#14 lore raw

Re: [PATCH RFC OSSTEST 05/19] ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists

Quoted 8 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 05/19] ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists"):

Quoted 2 lines

u-boot's pxe client uses this together with $fdtfile in its local environment to automatically load the fdt when pxe booting.

Although, bikeshedding,

Quoted 7 lines

ts-host-install SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A · line 193

Quoted 3 lines
ts-host-install +3 -0
+    my $dtbs = "fdtdir /$d_i/dtbs" if
+	-e "$ho->{Tftp}{Path}/$d_i/dtbs";
+

the if at the end of the line strikes me as a slightly odd style. There are many fewer of those in the codebase right now than places where it's on the start and the next line.

Yes, in fact I would naturally have done it the other way, I suppose I wasn't paying close enough attention to my fingers...

Quoted 2 lines

Ian.

#15 lore raw

RFC PATCH 6/19 ts-host-install: Refactor code to construct a Linux console= for a host

In reply to Ian Campbell

And reuse it in when writing the u-boot script for initial boot. This was previously hardcoded to ttyAMA which matches the production host DB for the current set of hosts which use this script.

---
 Osstest/Debian.pm      |  4 +++-
 Osstest/TestSupport.pm | 10 ++++++++++
 ts-host-install        |  6 +++---
 3 files changed, 16 insertions(+), 4 deletions(-)
Osstest/Debian.pm +3 -1
index ab09abb..29dec3b 100644
@@ -660,6 +660,8 @@ END
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
 	my $root=target_guest_lv_name($ho,"root");
+	my $console = get_host_native_linux_console($ho);
+	my $consolecmd = "console=$console" unless $console eq "NONE";
 
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
@@ -671,7 +673,7 @@ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
-setenv bootargs console=ttyAMA0 root=$root
+setenv bootargs $consolecmd root=$root
 mw.l 800000 0 10000
 scsi scan
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
Osstest/TestSupport.pm +10 -0
index 1d77933..d66708e 100644
@@ -65,6 +65,7 @@ BEGIN {
                       contents_make_cpio file_simple_write_contents
 
                       selecthost get_hostflags get_host_property
+                      get_host_native_linux_console
                       power_state power_cycle power_cycle_time
                       serial_fetch_logs
                       propname_massage
@@ -863,6 +864,15 @@ sub get_host_property ($$;$) {
     return defined($val) ? $val : $defval;
 }
 
+sub get_host_native_linux_console ($) {
+    my ($ho) = @_;
+
+    my $console = get_host_property($ho, "LinuxSerialConsole", "ttyS0");
+    return $console if $console eq 'NONE';
+
+    return "$console,$c{Baud}n8";
+}
+
 sub get_host_method_object ($$$) {
     my ($ho, $kind, $meth) = @_;
     my (@meth) = split /\s+/, $meth;
ts-host-install +3 -3
index ca26f95..cf9506d 100755
@@ -210,9 +210,9 @@ END
 
     push @installcmdline, qw(--);
 
-    my $console = get_host_property($ho, "LinuxSerialConsole", "ttyS0");
-    push @installcmdline, "console=$console,$c{Baud}n8"
-        unless $console eq "NONE";
+    my $console = get_host_native_linux_console($ho);
+
+    push @installcmdline, "console=$console" unless $console eq "NONE";
 
     my $installcmdline= join ' ', @installcmdline;
 
Signature · 1 line
2.1.0
Acked-by on v1 6/19
#16 lore raw

Re: [PATCH RFC OSSTEST 06/19] ts-host-install: Refactor code to construct a Linux console= for a host

Ian Campbell writes ("[PATCH RFC OSSTEST 06/19] ts-host-install: Refactor code to construct a Linux console= for a host"):

Quoted 3 lines

And reuse it in when writing the u-boot script for initial boot. This was previously hardcoded to ttyAMA which matches the production host DB for the current set of hosts which use this script.

#17 lore raw

RFC PATCH 7/19 ts-host-install: include console before *and* after the -- marker.

In reply to Ian Campbell

As of v3.15 Linux now stop parsing its command line at the -- mark and passes the remainder to init. This has broken Debian Installer's feature where anything after the -- is propagated to the installed system.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007

To work around this we need to pass console= twice, once before the -- for the current kernel's use and then again after the -- which is propagated to the installed system.

---
 ts-host-install | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
ts-host-install +6 -2
index cf9506d..cdbd774 100755
@@ -208,12 +208,16 @@ END
     push @installcmdline,
         get_host_property($ho, "install-append $ho->{Suite}", '');
 
-    push @installcmdline, qw(--);
-
     my $console = get_host_native_linux_console($ho);
 
     push @installcmdline, "console=$console" unless $console eq "NONE";
 
+    push @installcmdline, qw(--);
+
+    # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
+    # why this is repeated.
+    push @installcmdline, "console=$console" unless $console eq "NONE";
+
     my $installcmdline= join ' ', @installcmdline;
 
     setup_pxeboot($ho, <<END);
Signature · 1 line
2.1.0
Acked-by on v1 7/19
#18 lore raw

Re: [PATCH RFC OSSTEST 07/19] ts-host-install: include console before *and* after the -- marker.

Ian Campbell writes ("[PATCH RFC OSSTEST 07/19] ts-host-install: include console before *and* after the -- marker."):

Quoted 5 lines

As of v3.15 Linux now stop parsing its command line at the -- mark and passes the remainder to init. This has broken Debian Installer's feature where anything after the -- is propagated to the installed system.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007

Urgh. Thanks, systemd.

#19 lore raw

RFC PATCH 8/19 ts-host-install: Add option to boot debian-installer in rescue mode

In reply to Ian Campbell

This is useful when trying to bootstrap onto a new platform, since you can log in to an otherwise unbootable rootfs to figure out what is going wrong.

The procedure is the same as installing except "rescue/enabled=true" is added to the command line, hence part of ts-host-install rather than separate.

---
 Osstest/Debian.pm | 1 +
 ts-host-install   | 9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)
Osstest/Debian.pm +1 -0
index 29dec3b..8f80eb4 100644
@@ -422,6 +422,7 @@ sub di_installcmdline_core ($$;@) {
     my $debconf_priority= $xopts{DebconfPriority};
     push @cl, "debconf/priority=$debconf_priority"
         if defined $debconf_priority;
+    push @cl, "rescue/enable=true" if $xopts{RescueMode};
 
     return @cl;
 }
ts-host-install +7 -2
index cdbd774..7c8d693 100755
@@ -30,9 +30,14 @@ my $debconf_priority;
 
 our %xopts;
 
-if (@ARGV && $ARGV[0] =~ m/^--priority(?:=(.*))?$/) {
+while (@ARGV and $ARGV[0] =~ m/^-/) {
+    $_= shift @ARGV;
+    last if m/^--$/;
+    if (m/^--priority(?:=(.*))?$/) {
     $xopts{DebconfPriority}= defined($1) ? $1 : 'low';
-    shift @ARGV;
+    } elsif  (m/^--rescue$/) {
+	$xopts{RescueMode}= 1;
+    }
 }
 
 our ($whhost) = @ARGV;
Signature · 1 line
2.1.0
Acked-by on v1 8/19
#20 lore raw

Re: [PATCH RFC OSSTEST 08/19] ts-host-install: Add option to boot debian-installer in rescue mode

Ian Campbell writes ("[PATCH RFC OSSTEST 08/19] ts-host-install: Add option to boot debian-installer in rescue mode"):

Quoted 6 lines

This is useful when trying to bootstrap onto a new platform, since you can log in to an otherwise unbootable rootfs to figure out what is going wrong.

The procedure is the same as installing except "rescue/enabled=true" is added to the command line, hence part of ts-host-install rather than separate.

#21 lore raw

RFC PATCH 9/19 ts-host-install: Add force-mac-address host flag

In reply to Ian Campbell

This causes us to emit udev runes which force the device named in the host's Interface_Force property to have the MAC address given in the host's Ether property. This is the reverse of the behaviour of the Interface_Force property without this flag, which is to rename the device with MAC address Ether to have the requested name.

This is necessary because the arndale's USB Ethernet device has no burned in MAC address and there is no mechanism to configure this e.g. via the bootloader in a way which Linux will then notice.

Without this change Linux will pick a random mac address when loading the driver, which breaks osstest's attempts to observe when the test host has picked up its preseed file by watching the webserver logs, since DHCP will not map a random mac address to the IP we are expecting.

---
 ts-host-install | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
ts-host-install +4 -1
index 7c8d693..e874b98 100755
@@ -181,6 +181,7 @@ sub setup_pxeboot_firstboot($) {
 
     my $ipappend = 2;
     my $wantphysif= get_host_property($ho,'interface force','auto');
+    logm("Forcing interface $wantphysif");
     if ($wantphysif ne 'auto') {
 	$ipappend = 0;
 	die "need Ether for $ho->{Name} ($wantphysif)"
@@ -188,7 +189,9 @@ sub setup_pxeboot_firstboot($) {
         system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
         file_simple_write_contents
             ("$initrd_overlay.d/etc/udev/rules.d/70-persistent-net.rules",
-             <<END);
+             $ho->{Flags}{'force-mac-address'} ? <<END : <<END);
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="$wantphysif", RUN += "/bin/ip link set $wantphysif address $ho->{Ether}"
+END
 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="$wantphysif"
 END
     }
Signature · 1 line
2.1.0
#22 lore raw

Re: [PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag

Ian Campbell writes ("[PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag"):

Quoted 5 lines

This causes us to emit udev runes which force the device named in the host's Interface_Force property to have the MAC address given in the host's Ether property. This is the reverse of the behaviour of the Interface_Force property without this flag, which is to rename the device with MAC address Ether to have the requested name.

There is a potential problem with this, which is that Linux doctrine
is that devices do not have stable names. So if you don't identify
the device by mac address, and your system has more than one network interface, osstest can't identify the device reliably at all.

Do your actual boards have more than one eth* ?

Ian.

#23 lore raw

Re: [PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag

Quoted 7 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag"):

Quoted 5 lines

This causes us to emit udev runes which force the device named in the host's Interface_Force property to have the MAC address given in the host's Ether property. This is the reverse of the behaviour of the Interface_Force property without this flag, which is to rename the device with MAC address Ether to have the requested name.

Quoted 6 lines

There is a potential problem with this, which is that Linux doctrine
is that devices do not have stable names. So if you don't identify
the device by mac address, and your system has more than one network interface, osstest can't identify the device reliably at all.

Do your actual boards have more than one eth* ?

Just the one.

Ian.

Acked-by
#24 lore raw

Re: [PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag

Ian Campbell writes ("Re: [PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag"):

Quoted 8 lines · Ian Jackson
Quoted 7 lines

Ian Campbell writes ("[PATCH RFC OSSTEST 09/19] ts-host-install: Add force-mac-address host flag"):

Quoted 5 lines

This causes us to emit udev runes which force the device named in the host's Interface_Force property to have the MAC address given in the host's Ether property. This is the reverse of the behaviour of the Interface_Force property without this flag, which is to rename the device with MAC address Ether to have the requested name.

Quoted 8 lines
Quoted 6 lines

There is a potential problem with this, which is that Linux doctrine
is that devices do not have stable names. So if you don't identify
the device by mac address, and your system has more than one network interface, osstest can't identify the device reliably at all.

Do your actual boards have more than one eth* ?

Just the one.

OK then,

#25 lore raw

RFC PATCH 10/19 make-flight: Run a basic test on each arm platform

In reply to 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 equiv-$platform host flag.

Currently the existing arm midway boxes are "equiv-marilith", this turns out to be a bad choice at least for this purpose, since marilith is the host name, not the platform, we should either switch to or add equiv-midway. ISTR discussing this at the time and picking equiv-marilith pretty much arbitrarily, AFAIK nothing is using it explicitly today so I think removing and adding equiv-midway is the right choice.

---
 make-flight | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)
make-flight +11 -2
index 9963a46..0e8e26a 100755
@@ -284,10 +284,19 @@ do_passthrough_tests () {
 test_matrix_do_one () {
 
   # Basic PV Linux test with xl
+  case $xenarch in
+    armhf) platforms='midway cubietruck arndale' ;;
+    *)     platforms='' ;;
+  esac
+
+  for platform in ${platforms:-''} ; do
+    suffix=${platform:+-$platform}
+    hostflags=${most_hostflags}${platform:+,equiv-$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.0
#26 lore raw

Re: [PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform

Ian Campbell writes ("[PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform"):

Quoted 3 lines

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 equiv-$platform host flag.

I think using equiv-* for this is not correct.

Hosts named equiv-* are supposed to be completely identical, but we might end up with hosts which are similar enough that they qualify for this cross-architecture testing, and but not completely identical.

Furthermore, using equiv-* makes it difficult to automatically search for a list of the different board classes we would want to use.

I would invent a new prefix. Perhaps flags like
platform-midway
etc.

Then you could search the database

SELECT UNIQUE platform
WHERE EXISTS host
SUCHTHAT (host,"arch-$arch") in hostflags
AND (host,"blessed-$whatever") in hostflags etc.

rather than hardcoding the list in make-flight.

Quoted 7 lines

Currently the existing arm midway boxes are "equiv-marilith", this turns out to be a bad choice at least for this purpose, since marilith is the host name, not the platform, we should either switch to or add equiv-midway. ISTR discussing this at the time and picking equiv-marilith pretty much arbitrarily, AFAIK nothing is using it explicitly today so I think removing and adding equiv-midway is the right choice.

See above. `equiv-marilith' would be correct if we had another identical Calxeda box.

Ian.

#27 lore raw

Re: [PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform

Quoted 11 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform"):

Quoted 3 lines

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 equiv-$platform host flag.

I think using equiv-* for this is not correct.

Hosts named equiv-* are supposed to be completely identical, but we might end up with hosts which are similar enough that they qualify for this cross-architecture testing, and but not completely identical.

Quoted 6 lines

Furthermore, using equiv-* makes it difficult to automatically search for a list of the different board classes we would want to use.

I would invent a new prefix. Perhaps flags like
platform-midway
etc.

Would I have to add some code somewhere to process this? (I'm often surprised to find that these just work via some generic magic, e.g. the buildjob stuff etc, but I don't think so in this case?)

Perhaps in ts-hosts-allocate-Executive alongside the equiv handling?

Quoted 9 lines

Then you could search the database

SELECT UNIQUE platform
WHERE EXISTS host
SUCHTHAT (host,"arch-$arch") in hostflags
AND (host,"blessed-$whatever") in hostflags etc.

rather than hardcoding the list in make-flight.

I think this wouldn't work for standalone mode, would it?

Quoted 10 lines
Quoted 7 lines

Currently the existing arm midway boxes are "equiv-marilith", this turns out to be a bad choice at least for this purpose, since marilith is the host name, not the platform, we should either switch to or add equiv-midway. ISTR discussing this at the time and picking equiv-marilith pretty much arbitrarily, AFAIK nothing is using it explicitly today so I think removing and adding equiv-midway is the right choice.

See above. `equiv-marilith' would be correct if we had another identical Calxeda box.

Given "marilith" is the host name and not any sort of name which would identify "similar" machines -- really?

#28 lore raw

Re: [PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform

Ian Campbell writes ("Re: [PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform"):

Quoted 3 lines

Would I have to add some code somewhere to process this? (I'm often surprised to find that these just work via some generic magic, e.g. the buildjob stuff etc, but I don't think so in this case?)

(We discussed this in person.)

Quoted 5 lines
Quoted 2 lines

See above. `equiv-marilith' would be correct if we had another identical Calxeda box.

Given "marilith" is the host name and not any sort of name which would identify "similar" machines -- really?

Modulo that `marilith' is the wrong identifier and that I complained about that at the time, yes :-).

Ian.

#29 lore raw

Re: [PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform

In reply to Ian Jackson
Quoted 18 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 10/19] make-flight: Run a basic test on each arm platform"):

Quoted 3 lines

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 equiv-$platform host flag.

I think using equiv-* for this is not correct.

Hosts named equiv-* are supposed to be completely identical, but we might end up with hosts which are similar enough that they qualify for this cross-architecture testing, and but not completely identical.

Furthermore, using equiv-* makes it difficult to automatically search for a list of the different board classes we would want to use.

I would invent a new prefix. Perhaps flags like
platform-midway
etc.

Quoted 7 lines

Then you could search the database

SELECT UNIQUE platform
WHERE EXISTS host
SUCHTHAT (host,"arch-$arch") in hostflags
AND (host,"blessed-$whatever") in hostflags etc.

This was just a pseudo idea, right? Because the Internet has never heard of this EXISTS ... SUCHTHAT syntax that appeared so tantalizingly useful.

I think the real answer is going to involve some exciting JOIN-s? Something like (using equiv-% as a surrogate for the currently non-existent platform-*):

SELECT DISTINCT h4.hostflag
FROM hostflags h1
INNER JOIN hostflags h2 ON h1.hostname = h2.hostname AND h2.hostflag = 'arch-amd64' INNER JOIN hostflags h3 ON h1.hostname = h3.hostname AND h3.hostflag = 'blessed-real' INNER JOIN hostflags h4 ON h1.hostname = h4.hostname AND h4.hostflag LIKE 'equiv-%';

which lists:
equiv-rackservers-s40670
equiv-r310-moth
equiv-dell-r310
equiv-rackservers-s40680
equiv-rackservers-s40679
equiv-rackservers-s40663
equiv-rackservers-q21011

Was it your intention that every machine was given a platform-* property? Or do I need to create code to handle the "everything else" case? i.e. on x86 where there is no platform do we want to retain the exact same set of jobs?

Ian.

#30 lore raw

RFC PATCH 11/19 standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

In reply to Ian Campbell

This saves repeating identical HostProp and HostFlags for sets of identical machines. e.g.

    HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
    HostGroupProp_cubietruck_Build_Make_Flags -j12
    HostGroupProp_cubietruck_XenSerialConsole dtuart
    HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000
    HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

    HostGroup_braque cubietruck
    HostProp_braque_Fqdn braque.uk.xensource.com

    HostGroup_picaso cubietruck
    HostProp_picaso_Fqdn picaso.uk.xensource.com

    HostGroup_metzinger cubietruck
    HostProp_metzinger metzinger.uk.xensource.com

    HostGroup_gleizes cubietruck
    HostProp_gleizes_Fqdn gleizes.uk.xensource.com

I was unsure whether HostGroupProp's ought to be processed before or after the HostDB properties, but since the latter is a NOP I've arbitrarily put them before.

---
 Osstest/HostDB/Static.pm |  2 ++
 Osstest/TestSupport.pm   | 19 ++++++++++++++++++-
 README                   | 20 ++++++++++++++++++++
 3 files changed, 40 insertions(+), 1 deletion(-)
Osstest/HostDB/Static.pm +2 -0
index d0c13a1..ad18395 100644
@@ -58,6 +58,8 @@ sub get_flags ($$) { #method
     };
 
     $process->('HostFlags');
+    $process->("HostGroupFlags_$ho->{Properties}{HostGroup}")
+	if $ho->{Properties}{HostGroup};
     $process->("HostFlags_$ho->{Name}");
 
     return $flags;
Osstest/TestSupport.pm +18 -1
index d66708e..6901563 100644
@@ -766,12 +766,29 @@ sub selecthost ($) {
 	$ho->{Properties}{$pn} = $val;
     };
 
-    # First, we use the config file's general properites as defaults
+    # First, set the prop group if any.
+    foreach my $k (keys %c) {
+	next unless $k =~ m/^HostGroup_([-a-z0-9]+)$/;
+	next unless $1 eq $name;
+	$setprop->("HostGroup", $c{$k});
+	logm("Host $name is in HostGroup $ho->{Properties}{HostGroup}");
+    }
+
+    # Next, we use the config file's general properites as defaults
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([A-Z].*)$/;
 	$setprop->($1, $c{$k});
     }
 
+    # Next, we set any HostGroup based properties
+    if ( $ho->{Properties}{HostGroup} ) {
+	foreach my $k (keys %c) {
+	    next unless $k =~ m/^HostGroupProp_([-a-z0-9]+)_(.*)$/;
+	    next unless $1 eq $ho->{Properties}{HostGroup};
+	    $setprop->($2, $c{$k});
+	}
+    }
+
     # Then we read in the HostDB's properties
     $mhostdb->get_properties($name, $ho->{Properties});
 
README +20 -0
index 9a85549..b4f9cfb 100644
@@ -333,6 +333,26 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostFlags_<testbox>
+   Defines a set of flags for the host. Flags is a list separated by
+   whitespace, comma or semi-colon. A flag can be unset by prepending
+   a !. Only used in standalone mode.
+
+HostGroup_<testbox> <group>
+   Defines a group of similar hosts of which <testbox> is a
+   member. This can then be used with HostGroupProp and HostGroupFlags
+
+HostGroupProps_<group>_<prop>
+   Equivalent to writing HostProp_<testbox>_<prop> for every testbox
+   which declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common properties for a group of similar machines.
+
+HostGroupFlags_<group>
+   Equivalent to writing HostFlags_<testbox> for every testbox which
+   declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common flags for a group of similar machines. Only used in
+   standalone mode.
+
 DebianPreseed
    Text to add to the debian-installer preseed file.  Optional
    but you will need to set some NTP servers here if your firewall
Signature · 1 line
2.1.0
#31 lore raw

Re: [PATCH RFC OSSTEST 11/19] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

Ian Campbell writes ("[PATCH RFC OSSTEST 11/19] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):

Quoted 2 lines

This saves repeating identical HostProp and HostFlags for sets of identical machines. e.g.

The existing code is rather weird in that host properties from the configuration are dealt with in TestSupport (so apply to both standalone and executive), but host flags in the config are dealt with in HostDB/Static.pm (so apply only to standalone).

Quoted 3 lines

I was unsure whether HostGroupProp's ought to be processed before or after the HostDB properties, but since the latter is a NOP I've arbitrarily put them before.

The HostDB properties are not a NOP if the HostDB isn't Static!

In general the configuration should override the database. So I think this is the wrong way round.

Quoted 6 lines
README +0 -0
index 9a85549..b4f9cfb 100644
@@ -333,6 +333,26 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See

README HostProp_<testbox>_TftpScope · line 343

Quoted 10 lines
README +8 -0
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostFlags_<testbox>
+   Defines a set of flags for the host. Flags is a list separated by
+   whitespace, comma or semi-colon. A flag can be unset by prepending
+   a !. Only used in standalone mode.
+
+HostGroup_<testbox> <group>
+   Defines a group of similar hosts of which <testbox> is a
+   member. This can then be used with HostGroupProp and HostGroupFlags

Thanks for documenting this.

README HostProp_<testbox>_TftpScope · line 348

Quoted 4 lines
README +4 -0
+HostGroupProps_<group>_<prop>
+   Equivalent to writing HostProp_<testbox>_<prop> for every testbox
+   which declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common properties for a group of similar machines.

You should specify that this overrides the hostdb but is overridden by host-specific properties.

README HostProp_<testbox>_TftpScope · line 354

Quoted 5 lines
README +5 -0
+HostGroupFlags_<group>
+   Equivalent to writing HostFlags_<testbox> for every testbox which
+   declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common flags for a group of similar machines. Only used in
+   standalone mode.

You should say that this is merged with the host-specific properties and applies only to standlone mode.

Ian.

#32 lore raw

Re: [PATCH RFC OSSTEST 11/19] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

Quoted 8 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 11/19] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):

Quoted 2 lines

This saves repeating identical HostProp and HostFlags for sets of identical machines. e.g.

The existing code is rather weird in that host properties from the configuration are dealt with in TestSupport (so apply to both standalone and executive), but host flags in the config are dealt with in HostDB/Static.pm (so apply only to standalone).

Yes, I noticed that... No reason for it, just hysterical raisins?

Quoted 5 lines
Quoted 3 lines

I was unsure whether HostGroupProp's ought to be processed before or after the HostDB properties, but since the latter is a NOP I've arbitrarily put them before.

The HostDB properties are not a NOP if the HostDB isn't Static!

Sorry, I meant for the Static HostDB, on the basis that I don't think you would use the config file with the proper DB, would you?

(which might argue for moving a bunch of code from TestSupport to HostDB/Static.pm?)

Quoted 2 lines

In general the configuration should override the database. So I think this is the wrong way round.

Ack.

Ian.

#33 lore raw

Re: [PATCH RFC OSSTEST 11/19] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

Ian Campbell writes ("Re: [PATCH RFC OSSTEST 11/19] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):

Quoted 5 lines · Ian Jackson
Quoted 1 line

The HostDB properties are not a NOP if the HostDB isn't Static!

Sorry, I meant for the Static HostDB, on the basis that I don't think you would use the config file with the proper DB, would you?

You might set some properties from the config and some from the DB. I agree that this would be unusual but I wouldn't want to rule it out and I think the precedence ought to be in favour of the config file.

Quoted 2 lines

(which might argue for moving a bunch of code from TestSupport to HostDB/Static.pm?)

Let's not tackle that now :-).

Ian.

#34 lore raw

RFC PATCH 12/19 Osstest/Debian: Refactor code to set bootargs in u-boot script

In reply to Ian Campbell
---
 Osstest/Debian.pm | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
Osstest/Debian.pm +9 -3
index 8f80eb4..3ffbc50 100644
@@ -660,9 +660,15 @@ END
     }
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
+	my @bootargs;
+
 	my $root=target_guest_lv_name($ho,"root");
-	my $console = get_host_native_linux_console($ho);
-	my $consolecmd = "console=$console" unless $console eq "NONE";
+	my $console=get_host_native_linux_console($ho);
+
+	push @bootargs, "root=$root";
+	push @bootargs, "console=$console" unless $console eq "NONE";
+
+	my $bootargs = join ' ', @bootargs;
 
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
@@ -674,7 +680,7 @@ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
-setenv bootargs $consolecmd root=$root
+setenv bootargs $bootargs
 mw.l 800000 0 10000
 scsi scan
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
Signature · 1 line
2.1.0
#36 lore raw

RFC PATCH 13/19 Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs

In reply to Ian Campbell

This is done unconditionally for every platform which has a need-kernel-deb-* flag, which is currently all ARM platforms. Since mg-debian-installer-update produces the necessary inputs for the only such kernel (armmp) this seems tolerable for now.

---
 Osstest/Debian.pm | 8 ++++++++
 1 file changed, 8 insertions(+)
Osstest/Debian.pm +8 -0
index 3ffbc50..9171c72 100644
@@ -643,6 +643,11 @@ END
 		or die "Copy initramfs-tools failed: $!";
         });
 
+	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
@@ -651,6 +656,9 @@ r=/target
 
 wget -O \$r/tmp/kern.deb $kurl
 wget -O \$r/tmp/initramfs-tools.deb $iurl
+wget -O \$r/tmp/dtbs.tar.gz $durl
+
+in-target tar -C /boot -xaf /tmp/dtbs.tar.gz
 
 # This will fail due to dependencies...
 in-target dpkg -i /tmp/kern.deb /tmp/initramfs-tools.deb || true
Signature · 1 line
2.1.0
#37 lore raw

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

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

Quoted 4 lines

This is done unconditionally for every platform which has a need-kernel-deb-* flag, which is currently all ARM platforms. Since mg-debian-installer-update produces the necessary inputs for the only such kernel (armmp) this seems tolerable for now.

Surely it would be better to check whether the source file exists and use it iff it does ?

Ian.

#38 lore raw

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

Quoted 8 lines · Ian Jackson

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

Quoted 4 lines

This is done unconditionally for every platform which has a need-kernel-deb-* flag, which is currently all ARM platforms. Since mg-debian-installer-update produces the necessary inputs for the only such kernel (armmp) this seems tolerable for now.

Surely it would be better to check whether the source file exists and use it iff it does ?

I think I was just being lazy trying to reuse the existing hook script etc.

I could throw the script text into a variable and include it that way though.

#39 lore raw

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

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

Quoted 6 lines · Ian Jackson
Quoted 2 lines

Surely it would be better to check whether the source file exists and use it iff it does ?

I think I was just being lazy trying to reuse the existing hook script etc.

Uh ? You could reuse the existing hook script but just put the call to add the hook inside a conditional.

Ian.

#40 lore raw

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

Quoted 10 lines · Ian Jackson

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

Quoted 6 lines · Ian Jackson
Quoted 2 lines

Surely it would be better to check whether the source file exists and use it iff it does ?

I think I was just being lazy trying to reuse the existing hook script etc.

Uh ? You could reuse the existing hook script but just put the call to add the hook inside a conditional.

I meant reuse existing <<here doc with a script in it, rather than introduce a second call to the helper etc. As I say, lazy ;-)

Ian.

#41 lore raw

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

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

Quoted 6 lines · Ian Jackson
Quoted 2 lines

Uh ? You could reuse the existing hook script but just put the call to add the hook inside a conditional.

I meant reuse existing <<here doc with a script in it, rather than introduce a second call to the helper etc. As I say, lazy ;-)

OIC. The whole point about this helper is that you can call it multiple times...

Ian.

#42 lore raw

RFC PATCH 14/19 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).

---
 Osstest/Debian.pm | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)
Osstest/Debian.pm +14 -6
index 9171c72..19d6a22 100644
@@ -141,9 +141,11 @@ cp -n /boot/boot.scr /boot/boot.scr.bak
 xen=`readlink /boot/$xen`
 
 cat >/boot/boot <<EOF
-
-mw.l 800000 0 10000
-scsi scan
+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
 
 fdt addr \\\${fdt_addr}
 fdt resize
@@ -689,11 +691,17 @@ initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
 setenv bootargs $bootargs
-mw.l 800000 0 10000
-scsi scan
+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
+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.0
#43 lore raw

Re: [PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script

Ian Campbell writes ("[PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script"):

Quoted 5 lines

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

You should mention the extra `echo's in the commit message.

You have two copies of the same dtb-loading code. (You had two copies of the scsi scan' and mw.l' previously, but this is now worse because it's bigger.)

I confess I don't really understand some of this. Platforms which do not provide an fdt' are ones where ${fdt_addr} is empty ? And on those platforms fdt addr \${fdt_addr}' is a no-op ?

You might find the code clearer (less toothpick-counting) if you used <<'delim' for some of it, at one or other of the levels.

Thanks,
Ian.

#44 lore raw

Re: [PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script

Quoted 2 lines · Ian Jackson

I confess I don't really understand some of this. `Platforms which do not provide an fdt' are ones where ${fdt_addr} is empty ?

Yes.

Midway (marilith) provides a dtb in the firmware, and it is located at $fdt_addr. This is how device tree is supposed to work, but is actually vanishingly rare on ARM+u-boot in real life (I've never seen another such platform...)

In practice most ARM+u-boot platforms require you to load the dtb from somewhere by hand, and provide fdt_addr_r as the place you should put it.

(EFI on arm64 is a bit better here...)

Quoted 2 lines

And on
those platforms `fdt addr \${fdt_addr}' is a no-op ?

fdt_addr is set by the new code on those platforms.

Quoted 2 lines

You might find the code clearer (less toothpick-counting) if you used <<'delim' for some of it, at one or other of the levels.

You mean as opposed to <<delim because it changes the quoting behaviour?

That would break places where I wanted to expand a Perl var, I think? Perhaps those uses can be broken out in some convenient way and concatenated back again. I'll give it a go and see how it looks.

Ian.

#45 lore raw

Re: [PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script

Ian Campbell writes ("Re: [PATCH RFC OSSTEST 14/19] Osstest/Debian: Support for loading an FDT from u-boot script"):

Quoted 1 line

[stuff]

Thanks for the explanation.

Quoted 8 lines
Quoted 2 lines

You might find the code clearer (less toothpick-counting) if you used <<'delim' for some of it, at one or other of the levels.

You mean as opposed to <<delim because it changes the quoting behaviour?

That would break places where I wanted to expand a Perl var, I think? Perhaps those uses can be broken out in some convenient way and concatenated back again. I'll give it a go and see how it looks.

Right. In Perl you can write

    blah <<END.<<'END';

for example.

Ian.

#46 lore raw

RFC PATCH 15/19 Osstest/Debian: Add support for "ExtraInitramfsModules" host property

In reply to Ian Campbell

The arndale platform needs a bunch of clk, phy and regulator stuff in order to access its root filesystem. However mkinitramfs is not (currently?) able to figure this out and therefore doesn't include them in the initrd.

Add a new host prop which can list these required additional module and arranges for a suitable /etc/initramfs-tools/modules to be created on install.

Using the new HostGroupProp syntax the required modules are:

HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata

---
 Osstest/Debian.pm | 14 ++++++++++++++
 1 file changed, 14 insertions(+)
Osstest/Debian.pm +14 -0
index 19d6a22..97a6cda 100644
@@ -708,6 +708,20 @@ in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
 END
     }
 
+    my $modules = get_host_property($ho, "ExtraInitramfsModules", "NONE");
+    if ( $modules ne "NONE" )
+    {
+        preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+for i in $modules ; do
+    echo \$i >> /target/etc/initramfs-tools/modules
+done
+in-target update-initramfs -u -k all
+END
+    }
+
     my @extra_packages = ();
     push(@extra_packages, "u-boot-tools") if $ho->{Flags}{'need-uboot-bootscr'};
 
Signature · 1 line
2.1.0
#47 lore raw

Re: [PATCH RFC OSSTEST 15/19] Osstest/Debian: Add support for "ExtraInitramfsModules" host property

Ian Campbell writes ("[PATCH RFC OSSTEST 15/19] Osstest/Debian: Add support for "ExtraInitramfsModules" host property"):

Quoted 4 lines

The arndale platform needs a bunch of clk, phy and regulator stuff in order to access its root filesystem. However mkinitramfs is not (currently?) able to figure this out and therefore doesn't include them in the initrd.

Is this not a bug in mkinitrams or something ? If so I think we should provide a reference to the bug here (eg bugs.debian.org URL or something).

I'm surprised that there isn't a less-raw way of doing this with d-i, than using a late-command.

Ian.

#48 lore raw

Re: [PATCH RFC OSSTEST 15/19] Osstest/Debian: Add support for "ExtraInitramfsModules" host property

Quoted 9 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 15/19] Osstest/Debian: Add support for "ExtraInitramfsModules" host property"):

Quoted 4 lines

The arndale platform needs a bunch of clk, phy and regulator stuff in order to access its root filesystem. However mkinitramfs is not (currently?) able to figure this out and therefore doesn't include them in the initrd.

Is this not a bug in mkinitrams or something ? If so I think we should provide a reference to the bug here (eg bugs.debian.org URL or something).

Yes, I should file one.

Quoted 2 lines

I'm surprised that there isn't a less-raw way of doing this with d-i, than using a late-command.

So was I.

Ian.

#49 lore raw

RFC PATCH 16/19 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.

---
 Osstest/Debian.pm | 2 ++
 1 file changed, 2 insertions(+)
Osstest/Debian.pm +2 -0
index 97a6cda..eca4d7f 100644
@@ -673,9 +673,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";
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;
Signature · 1 line
2.1.0
Acked-by on v1 16/19
#50 lore raw

Re: [PATCH RFC OSSTEST 16/19] Osstest/Debian: support adding a rootdelay property to bootargs

Ian Campbell writes ("[PATCH RFC OSSTEST 16/19] Osstest/Debian: support adding a rootdelay property to bootargs"):

Quoted 2 lines

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

#51 lore raw

RFC PATCH 17/19 Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr

In reply to Ian Campbell

This needs to go along with a change to the hostdb to add "setenv xen_addr_r 0x01000000" to the UBootScriptEarlyCommands property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale "setenv xen_addr_r 0x41000000" is appropriate.

This is going to be a pretty common requirement on ARM/uboot systems, should I make it a specific property instead of reusing the generic hook?

---
 Osstest/Debian.pm | 4 ----
 1 file changed, 4 deletions(-)
Osstest/Debian.pm +0 -4
index eca4d7f..4539452 100644
@@ -155,10 +155,6 @@ ${early_commands}
 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.0
#52 lore raw

Re: [PATCH RFC OSSTEST 17/19] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr

Ian Campbell writes ("[PATCH RFC OSSTEST 17/19] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr"):

Quoted 2 lines

This needs to go along with a change to the hostdb to add "setenv xen_addr_r 0x01000000" to the UBootScriptEarlyCommands property of the midway machines.

Go along with' is not possible. Do you mean this depends on' ?

Quoted 3 lines

This is going to be a pretty common requirement on ARM/uboot systems, should I make it a specific property instead of reusing the generic hook?

Yes.

Ian.

#53 lore raw

Re: [PATCH RFC OSSTEST 17/19] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr

Quoted 5 lines · Ian Jackson

Ian Campbell writes ("[PATCH RFC OSSTEST 17/19] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr"):

Quoted 2 lines

This needs to go along with a change to the hostdb to add "setenv xen_addr_r 0x01000000" to the UBootScriptEarlyCommands property of the midway machines.

Go along with' is not possible. Do you mean this depends on' ?

Yes. The hostdb change can happen first without breaking anything.

Quoted 5 lines
Quoted 3 lines

This is going to be a pretty common requirement on ARM/uboot systems, should I make it a specific property instead of reusing the generic hook?

Yes.

Ack

#54 lore raw

Re: [PATCH RFC OSSTEST 17/19] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr [and 1 more messages]

Ian Campbell writes ("[PATCH OSSTEST v2 17/20] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr"):

Quoted 10 lines

This depends on a change to the hostdb to add "setenv xen_addr_r 0x01000000" to the UBootScriptEarlyCommands property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale "setenv xen_addr_r 0x41000000" is appropriate.

This is going to be a pretty common requirement on ARM/uboot systems, should I make it a specific property instead of reusing the generic hook?

I don't understand why this question is still in the commit message. I already answered it with "yes" and you said "ack" ...

Ian.

#55 lore raw

Re: [PATCH RFC OSSTEST 17/19] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr [and 1 more messages]

Quoted 8 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 17/20] Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr"):

Quoted 7 lines

This depends on a change to the hostdb to add "setenv xen_addr_r 0x01000000" to the UBootScriptEarlyCommands property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale "setenv xen_addr_r 0x41000000" is appropriate.

Quoted 6 lines
Quoted 3 lines

This is going to be a pretty common requirement on ARM/uboot systems, should I make it a specific property instead of reusing the generic hook?

I don't understand why this question is still in the commit message. I already answered it with "yes" and you said "ack" ...

Looks like I overlooked that when refreshing my memory of the last time around, sorry.

Ian.

#56 lore raw

RFC PATCH 18/19 ts-kernel-build: Enable CONFIG_PHY_EXYNOS5250_SATA

In reply to Ian Campbell

Enables the disk on an arndale, which isn't enabled by default in v3.16 for some reason.

---
 ts-kernel-build | 2 ++
 1 file changed, 2 insertions(+)
ts-kernel-build +2 -0
index 3b48920..bae118c 100755
@@ -171,6 +171,8 @@ setopt CONFIG_BLK_DEV_NBD y
 # At least with Linux 3.4.77 on wheezy, the nbd module is
 # not loaded automatically.
 
+setopt CONFIG_PHY_EXYNOS5250_SATA y
+
 END
 
 our $config_features= <<END;
Signature · 1 line
2.1.0
Acked-by on v1 18/19
#57 lore raw

Re: [PATCH RFC OSSTEST 18/19] ts-kernel-build: Enable CONFIG_PHY_EXYNOS5250_SATA

Ian Campbell writes ("[PATCH RFC OSSTEST 18/19] ts-kernel-build: Enable CONFIG_PHY_EXYNOS5250_SATA"):

Quoted 2 lines

Enables the disk on an arndale, which isn't enabled by default in v3.16 for some reason.

#58 lore raw

RFC PATCH 19/19 Osstest/Debian: Workaround oddities in the u-boot script parser.

In reply to Ian Campbell

${filesize} is a bare hex number (i.e. no 0x prefix), but apparently 'fdt set' needs the 0x prefix to make sense of it.

Furthermore it is confused by "0xABCD>" (and "ABCD>") and complains because ">" isn't a valid digit. So put a space after the number.

---
 Osstest/Debian.pm | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
Osstest/Debian.pm +5 -5
index 4539452..2fe4728 100644
@@ -163,16 +163,16 @@ 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 bootargs "$xenkopt ro root=$root"
-echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
+fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize} >
+fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root clk_ignore_unused"
+echo Loaded $kern to \\\${kernel_addr_r} (0x\\\${filesize})
 echo command line: $xenkopt ro root=$root
 
 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}>
-echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
+fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize} >
+echo Loaded $initrd to \\\${ramdisk_addr_r} (0x\\\${filesize})
 
 fdt print /chosen
 
Signature · 1 line
2.1.0
#59 lore raw

Re: [PATCH RFC OSSTEST 19/19] Osstest/Debian: Workaround oddities in the u-boot script parser.

Ian Campbell writes ("[PATCH RFC OSSTEST 19/19] Osstest/Debian: Workaround oddities in the u-boot script parser."):

Quoted 2 lines

${filesize} is a bare hex number (i.e. no 0x prefix), but apparently 'fdt set' needs the 0x prefix to make sense of it.

WTF.

Quoted 2 lines

Furthermore it is confused by "0xABCD>" (and "ABCD>") and complains because ">" isn't a valid digit. So put a space after the number.

Surely these are bugs, so can we have the ref to the upstream bug tracker ?

Thanks,
Ian.

#60 lore raw

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

I have successfully run test-armhf-armhf-xl on cubietruck, but not yet on arndale (struggling to find a pvops config which boots, even natively!). I thought I'd send the bulk out to get started with.

For reference the relevant bits of my ~/.xen-osstest/config are below.

Since v1 I've reordered to pulled the stuff which relates to updating mg-debian-installer-update and TftpDiVersion to the front, in the hopes of getting that in sooner. This includes everything up to at least "ts-host-install: include console before *and* after the -- marker." which is needed because rerunning mg-debian-installer-update today will pull in a kernel which is affected by that issue. In reality the initial set of acked patches here is larger.

Ian.

#HostProp_metrocentre_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 1 HostProp_westfield_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 2 HostProp_lakeside_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 3 HostProp_bluewater_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 4

HostProp_braque_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 5 HostProp_picaso_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 6 HostProp_metzinger_PowerMethod eth008 arm-pdu-01.uk.xensource.com admin password 7 HostProp_gleizes_PowerMethod eth008 arm-pdu-01.uk.xensource.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_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000

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

HostGroup_metrocentre arndale HostProp_metrocentre_Fqdn metrocentre.uk.xensource.com HostProp_metrocentre_Ether 9e:04:00:59:64:5a

HostGroup_westfield arndale HostProp_westfield_Fqdn westfield.uk.xensource.com HostProp_westfield_Ether a6:46:13:77:e8:2f

HostGroup_lakeside arndale
HostProp_lakeside_Fqdn lakeside.uk.xensource.com
HostProp_lakeside_Ether e2:e7:75:3f:df:4c

HostGroup_bluewater arndale HostProp_bluewater_Fqdn bluewater.uk.xensource.com HostProp_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_UBootScriptEarlyCommands setenv xen_addr_r 0x41000000 HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

HostGroup_braque cubietruck
HostProp_braque_Fqdn braque.uk.xensource.com

HostGroup_picaso cubietruck
HostProp_picaso_Fqdn picaso.uk.xensource.com

HostGroup_metzinger cubietruck
HostProp_metzinger metzinger.uk.xensource.com

HostGroup_gleizes cubietruck
HostProp_gleizes_Fqdn gleizes.uk.xensource.com

#61 lore raw

PATCH v2 1/20 standalone: Provide a helper to clear the host runvar

This clears the host flag used for single-host test cases.

---
 standalone | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
standalone +18 -0
index daab7ae..c1139f8 100755
@@ -29,6 +29,12 @@ Operations:
 
   Required options: -h HOST
 
+* reset-host [cf] [JOB]
+
+  Allow a job which has been run before to run on a different host
+  next time. Otherwise osstest will complain if you change the host
+  which a job is running on on successive runs.
+
 Options:
 
 -c FILE, --config=FILE        Use FILE as configuration file
@@ -200,6 +206,18 @@ case $op in
 	fi
 	;;
 
+    reset-host)
+	need_flight;
+
+	if [ $# -lt 1 ] ; then
+	    echo "run-job: Need job" >&2
+	    exit 1
+	fi
+
+	job=$1; shift
+	./cs-adjust-flight -v $flight runvar-del $job host
+	;;
+
     run-job)
 	need_flight; need_host
 
Signature · 1 line
2.1.1
#62 lore raw

PATCH v2 2/20 mg-debian-installer-update: Include any device tree blobs in the tftp dir

In reply to Ian Campbell

We will need to supply these for some arm boards.

We provide both an unpacked version, which can be referenced via u-boot's support for the "fdtdir" property in pxelinux.cfg and a tarball which is more convenient for installing into the target filesystem on host install

---
 mg-debian-installer-update | 4 ++++
 1 file changed, 4 insertions(+)
mg-debian-installer-update +4 -0
index b964f95..4e1da8a 100755
@@ -130,6 +130,10 @@ if [ $arch = armhf ]; then
           |pax -x sv4cpio -s '%lib%/lib%' -d -w >../cpio; cd ..
     gzip -9f cpio
     mv cpio.gz armmp.cpio.gz
+    rm -rf dtbs/
+    mkdir dtbs/
+    mv x/usr/lib/linux-image-*-armmp/*.dtb dtbs/
+    tar -caf dtbs.tar.gz dtbs
     rm -rf x
 fi
 
Signature · 1 line
2.1.1
#63 lore raw

PATCH v2 3/20 mg-debian-installer-update: Add more modules when creating initrd overlay

In reply to Ian Campbell

The arndale platform has a usb network device. In addition both the SATA and NIC/USB hardware on this platform requires additional regulator (power), clk and phy modules, which in turn require i2c support.

Add everything which is needed on this platform.

Sort the list of drivers while here.

---
 mg-debian-installer-update | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
mg-debian-installer-update +10 -2
index 4e1da8a..4af4a42 100755
@@ -123,10 +123,18 @@ if [ $arch = armhf ]; then
                          -path \*/kernel/fs/mbcache.ko -o \
                          -path \*/kernel/fs/ext\* -o \
                          -path \*/kernel/fs/jbd\* -o \
-                         -path \*/kernel/drivers/net/\* -o \
+                         -path \*/kernel/drivers/clk/\* -o \
+                         -path \*/kernel/drivers/mmc/\* -o \
+                         -path \*/kernel/drivers/phy/\* -o \
+                         -path \*/kernel/drivers/usb/misc/\* -o \
                          -path \*/kernel/drivers/ata/\* -o \
+                         -path \*/kernel/drivers/i2c/busses/\* -o \
+                         -path \*/kernel/drivers/md/\* -o \
+                         -path \*/kernel/drivers/net/\* -o \
+                         -path \*/kernel/drivers/regulator/\* -o \
                          -path \*/kernel/drivers/scsi/\* -o \
-                         -path \*/kernel/drivers/md/\* \) \
+                         -path \*/kernel/drivers/usb/dwc3/\* -o \
+                         -path \*/kernel/drivers/usb/host/\* \) \
           |pax -x sv4cpio -s '%lib%/lib%' -d -w >../cpio; cd ..
     gzip -9f cpio
     mv cpio.gz armmp.cpio.gz
Signature · 1 line
2.1.1
#64 lore raw

PATCH v2 4/20 ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists

In reply to Ian Campbell

u-boot's pxe client uses this together with $fdtfile in its local environment to automatically load the fdt when pxe booting.

---
v2: Place if on the next line

---
 ts-host-install | 4 ++++
 1 file changed, 4 insertions(+)
ts-host-install +4 -0
index 95ce845..90058e3 100755
@@ -188,6 +188,9 @@ SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", A
 END
     }
 
+    my $dtbs = "fdtdir /$d_i/dtbs"
+	if -e "$ho->{Tftp}{Path}/$d_i/dtbs";
+
     file_simple_write_contents("$initrd_overlay.cpio", sub {
         contents_make_cpio($_[0], 'newc', "$initrd_overlay.d");
     });
@@ -222,6 +225,7 @@ label overwrite
 	kernel $kernel
 	append $installcmdline
 	ipappend $ipappend
+	$dtbs
 default overwrite
 END
 }
Signature · 1 line
2.1.1
#65 lore raw

PATCH v2 5/20 ts-host-install: Refactor code to construct a Linux console= for a host

In reply to Ian Campbell

And reuse it in when writing the u-boot script for initial boot. This was previously hardcoded to ttyAMA which matches the production host DB for the current set of hosts which use this script.

---
 Osstest/Debian.pm      |  4 +++-
 Osstest/TestSupport.pm | 10 ++++++++++
 ts-host-install        |  6 +++---
 3 files changed, 16 insertions(+), 4 deletions(-)
Osstest/Debian.pm +3 -1
index ab09abb..29dec3b 100644
@@ -660,6 +660,8 @@ END
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
 	my $root=target_guest_lv_name($ho,"root");
+	my $console = get_host_native_linux_console($ho);
+	my $consolecmd = "console=$console" unless $console eq "NONE";
 
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
@@ -671,7 +673,7 @@ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
-setenv bootargs console=ttyAMA0 root=$root
+setenv bootargs $consolecmd root=$root
 mw.l 800000 0 10000
 scsi scan
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
Osstest/TestSupport.pm +10 -0
index 1d77933..d66708e 100644
@@ -65,6 +65,7 @@ BEGIN {
                       contents_make_cpio file_simple_write_contents
 
                       selecthost get_hostflags get_host_property
+                      get_host_native_linux_console
                       power_state power_cycle power_cycle_time
                       serial_fetch_logs
                       propname_massage
@@ -863,6 +864,15 @@ sub get_host_property ($$;$) {
     return defined($val) ? $val : $defval;
 }
 
+sub get_host_native_linux_console ($) {
+    my ($ho) = @_;
+
+    my $console = get_host_property($ho, "LinuxSerialConsole", "ttyS0");
+    return $console if $console eq 'NONE';
+
+    return "$console,$c{Baud}n8";
+}
+
 sub get_host_method_object ($$$) {
     my ($ho, $kind, $meth) = @_;
     my (@meth) = split /\s+/, $meth;
ts-host-install +3 -3
index 90058e3..881c2fd 100755
@@ -210,9 +210,9 @@ END
 
     push @installcmdline, qw(--);
 
-    my $console = get_host_property($ho, "LinuxSerialConsole", "ttyS0");
-    push @installcmdline, "console=$console,$c{Baud}n8"
-        unless $console eq "NONE";
+    my $console = get_host_native_linux_console($ho);
+
+    push @installcmdline, "console=$console" unless $console eq "NONE";
 
     my $installcmdline= join ' ', @installcmdline;
 
Signature · 1 line
2.1.1
#66 lore raw

PATCH v2 6/20 ts-host-install: include console before *and* after the -- marker.

In reply to Ian Campbell

As of v3.15 Linux now stop parsing its command line at the -- mark and passes the remainder to init. This has broken Debian Installer's feature where anything after the -- is propagated to the installed system.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007

To work around this we need to pass console= twice, once before the -- for the current kernel's use and then again after the -- which is propagated to the installed system.

---
 ts-host-install | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
ts-host-install +6 -2
index 881c2fd..c611ed1 100755
@@ -208,12 +208,16 @@ END
     push @installcmdline,
         get_host_property($ho, "install-append $ho->{Suite}", '');
 
-    push @installcmdline, qw(--);
-
     my $console = get_host_native_linux_console($ho);
 
     push @installcmdline, "console=$console" unless $console eq "NONE";
 
+    push @installcmdline, qw(--);
+
+    # See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
+    # why this is repeated.
+    push @installcmdline, "console=$console" unless $console eq "NONE";
+
     my $installcmdline= join ' ', @installcmdline;
 
     setup_pxeboot($ho, <<END);
Signature · 1 line
2.1.1
#67 lore raw

PATCH v2 7/20 ts-host-install: Add option to boot debian-installer in rescue mode

In reply to Ian Campbell

This is useful when trying to bootstrap onto a new platform, since you can log in to an otherwise unbootable rootfs to figure out what is going wrong.

The procedure is the same as installing except "rescue/enabled=true" is added to the command line, hence part of ts-host-install rather than separate.

---
 Osstest/Debian.pm | 1 +
 ts-host-install   | 9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)
Osstest/Debian.pm +1 -0
index 29dec3b..8f80eb4 100644
@@ -422,6 +422,7 @@ sub di_installcmdline_core ($$;@) {
     my $debconf_priority= $xopts{DebconfPriority};
     push @cl, "debconf/priority=$debconf_priority"
         if defined $debconf_priority;
+    push @cl, "rescue/enable=true" if $xopts{RescueMode};
 
     return @cl;
 }
ts-host-install +7 -2
index c611ed1..2f72b5f 100755
@@ -30,9 +30,14 @@ my $debconf_priority;
 
 our %xopts;
 
-if (@ARGV && $ARGV[0] =~ m/^--priority(?:=(.*))?$/) {
+while (@ARGV and $ARGV[0] =~ m/^-/) {
+    $_= shift @ARGV;
+    last if m/^--$/;
+    if (m/^--priority(?:=(.*))?$/) {
     $xopts{DebconfPriority}= defined($1) ? $1 : 'low';
-    shift @ARGV;
+    } elsif  (m/^--rescue$/) {
+	$xopts{RescueMode}= 1;
+    }
 }
 
 our ($whhost) = @ARGV;
Signature · 1 line
2.1.1
#68 lore raw

PATCH v2 8/20 ts-host-install: Add force-mac-address host flag

In reply to Ian Campbell

This causes us to emit udev runes which force the device named in the host's Interface_Force property to have the MAC address given in the host's Ether property. This is the reverse of the behaviour of the Interface_Force property without this flag, which is to rename the device with MAC address Ether to have the requested name.

This is necessary because the arndale's USB Ethernet device has no burned in MAC address and there is no mechanism to configure this e.g. via the bootloader in a way which Linux will then notice.

Without this change Linux will pick a random mac address when loading the driver, which breaks osstest's attempts to observe when the test host has picked up its preseed file by watching the webserver logs, since DHCP will not map a random mac address to the IP we are expecting.

This is only useful on systems which have exactly one Ethernet device, otherwise there is no reliable way to determine which device is which.

---
v2; Added final para to commit log.

---
 ts-host-install | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
ts-host-install +4 -1
index 2f72b5f..b954e53 100755
@@ -181,6 +181,7 @@ sub setup_pxeboot_firstboot($) {
 
     my $ipappend = 2;
     my $wantphysif= get_host_property($ho,'interface force','auto');
+    logm("Forcing interface $wantphysif");
     if ($wantphysif ne 'auto') {
 	$ipappend = 0;
 	die "need Ether for $ho->{Name} ($wantphysif)"
@@ -188,7 +189,9 @@ sub setup_pxeboot_firstboot($) {
         system_checked(qw(mkdir -p --), "$initrd_overlay.d/etc/udev/rules.d");
         file_simple_write_contents
             ("$initrd_overlay.d/etc/udev/rules.d/70-persistent-net.rules",
-             <<END);
+             $ho->{Flags}{'force-mac-address'} ? <<END : <<END);
+SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNEL=="$wantphysif", RUN += "/bin/ip link set $wantphysif address $ho->{Ether}"
+END
 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="$ho->{Ether}", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="$wantphysif"
 END
     }
Signature · 1 line
2.1.1
#69 lore raw

PATCH v2 9/20 make-flight: Run a basic test on each arm platform

In reply to 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

---
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 d0c13a1..e786761 100644
@@ -63,6 +63,15 @@ sub get_flags ($$) { #method
     return $flags;
 }
 
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my $prop = "Platforms".ucfirst($arch);
+
+    return split /[, ]/, $c{$prop} if $c{$prop};
+    return () unless $c{$prop};
+}
+
 sub default_methods ($$) { #method
     my ($hd, $ho) = @_;
 
README +3 -0
index 9a85549..5c5f347 100644
@@ -381,6 +381,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 9963a46..0814eba 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.1
#70 lore raw

Re: [PATCH OSSTEST v2 09/20] make-flight: Run a basic test on each arm platform

Ian Campbell writes ("[PATCH OSSTEST v2 09/20] make-flight: Run a basic test on each arm platform"):

Quoted 9 lines

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.

The sql looks good.

Osstest/HostDB/Static.pm sub get_flags ($$) { #method · line 71

Quoted 6 lines
Osstest/HostDB/Static.pm +6 -0
+sub get_arch_platforms ($$) {
+    my ($hd, $blessing, $arch) = @_;
+
+    my $prop = "Platforms".ucfirst($arch);
+
+    return split /[, ]/, $c{$prop} if $c{$prop};

I think you probably want split /[, \t]+/ or maybe split /\s+/

Thanks,
Ian.

#71 lore raw

PATCH v2 10/20 standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

In reply to Ian Campbell

This saves repeating identical HostProp and HostFlags for sets of identical machines. e.g.

    HostGroupProp_cubietruck_LinuxSerialConsole ttyS0
    HostGroupProp_cubietruck_Build_Make_Flags -j12
    HostGroupProp_cubietruck_XenSerialConsole dtuart
    HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000
    HostGroupFlags_cubietruck suite-wheezy,equiv-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr

    HostGroup_braque cubietruck
    HostProp_braque_Fqdn braque.uk.xensource.com

    HostGroup_picaso cubietruck
    HostProp_picaso_Fqdn picaso.uk.xensource.com

    HostGroup_metzinger cubietruck
    HostProp_metzinger metzinger.uk.xensource.com

    HostGroup_gleizes cubietruck
    HostProp_gleizes_Fqdn gleizes.uk.xensource.com

---
v2: Set HostGroup props after DB
Clarify docs

---
 Osstest/HostDB/Static.pm |  2 ++
 Osstest/TestSupport.pm   | 19 ++++++++++++++++++-
 README                   | 22 ++++++++++++++++++++++
 3 files changed, 42 insertions(+), 1 deletion(-)
Osstest/HostDB/Static.pm +2 -0
index e786761..076da62 100644
@@ -58,6 +58,8 @@ sub get_flags ($$) { #method
     };
 
     $process->('HostFlags');
+    $process->("HostGroupFlags_$ho->{Properties}{HostGroup}")
+	if $ho->{Properties}{HostGroup};
     $process->("HostFlags_$ho->{Name}");
 
     return $flags;
Osstest/TestSupport.pm +18 -1
index d66708e..a1c2947 100644
@@ -766,7 +766,15 @@ sub selecthost ($) {
 	$ho->{Properties}{$pn} = $val;
     };
 
-    # First, we use the config file's general properites as defaults
+    # First, set the prop group if any.
+    foreach my $k (keys %c) {
+	next unless $k =~ m/^HostGroup_([-a-z0-9]+)$/;
+	next unless $1 eq $name;
+	$setprop->("HostGroup", $c{$k});
+	logm("Host $name is in HostGroup $ho->{Properties}{HostGroup}");
+    }
+
+    # Next, we use the config file's general properites as defaults
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([A-Z].*)$/;
 	$setprop->($1, $c{$k});
@@ -775,6 +783,15 @@ sub selecthost ($) {
     # Then we read in the HostDB's properties
     $mhostdb->get_properties($name, $ho->{Properties});
 
+    # Next, we set any HostGroup based properties
+    if ( $ho->{Properties}{HostGroup} ) {
+	foreach my $k (keys %c) {
+	    next unless $k =~ m/^HostGroupProp_([-a-z0-9]+)_(.*)$/;
+	    next unless $1 eq $ho->{Properties}{HostGroup};
+	    $setprop->($2, $c{$k});
+	}
+    }
+
     # Finally, we override any host-specific properties from the config
     foreach my $k (keys %c) {
 	next unless $k =~ m/^HostProp_([-a-z0-9]+)_(.*)$/;
README +22 -0
index 5c5f347..5ba695d 100644
@@ -333,6 +333,28 @@ HostProp_<testbox>_TftpScope
    Defines the Tftp scope (i.e. subnet) where this host resides. See
    "TftpFoo_<scope> and TftpFoo" below.
 
+HostFlags_<testbox>
+   Defines a set of flags for the host. Flags is a list separated by
+   whitespace, comma or semi-colon. A flag can be unset by prepending
+   a !. Only used in standalone mode.
+
+HostGroup_<testbox> <group>
+   Defines a group of similar hosts of which <testbox> is a
+   member. This can then be used with HostGroupProp and HostGroupFlags
+
+HostGroupProps_<group>_<prop>
+   Equivalent to writing HostProp_<testbox>_<prop> for every testbox
+   which declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common properties for a group of similar machines. These settings
+   take precedence over the database provided settings, but are
+   themselves overridden by host-specific properties.
+
+HostGroupFlags_<group>
+   Equivalent to writing HostFlags_<testbox> for every testbox which
+   declares HostGroup_<testbox>_<group>. Allows setting a set of
+   common flags for a group of similar machines. These flags are
+   merged with the host specific flags. Only used in standalone mode.
+
 DebianPreseed
    Text to add to the debian-installer preseed file.  Optional
    but you will need to set some NTP servers here if your firewall
Signature · 1 line
2.1.1
#72 lore raw

Re: [PATCH OSSTEST v2 10/20] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

Ian Campbell writes ("[PATCH OSSTEST v2 10/20] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):

Quoted 2 lines

This saves repeating identical HostProp and HostFlags for sets of identical machines. e.g.

Thanks.

Osstest/TestSupport.pm sub selecthost ($) { · line 772

Quoted 5 lines
Osstest/TestSupport.pm +4 -1
-    # First, we use the config file's general properites as defaults
+    # First, set the prop group if any.
+    foreach my $k (keys %c) {
+	next unless $k =~ m/^HostGroup_([-a-z0-9]+)$/;
+	next unless $1 eq $name;

Am I being dim or could this loop be replaced with a single lookup of $c{"HostGroup_${name}"} ?

Apart from that this looks fine to me.

Thanks,
Ian.

#73 lore raw

Re: [PATCH OSSTEST v2 10/20] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG

Quoted 6 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 10/20] standalone: Introduce "HostGroups" for use in OSSTEST_CONFIG"):

Quoted 2 lines

This saves repeating identical HostProp and HostFlags for sets of identical machines. e.g.

Thanks.

Quoted 8 lines

Osstest/TestSupport.pm sub selecthost ($) { · line 772

Quoted 5 lines
Osstest/TestSupport.pm +4 -1
-    # First, we use the config file's general properites as defaults
+    # First, set the prop group if any.
+    foreach my $k (keys %c) {
+	next unless $k =~ m/^HostGroup_([-a-z0-9]+)$/;
+	next unless $1 eq $name;

Am I being dim or could this loop be replaced with a single lookup of $c{"HostGroup_${name}"} ?

Uh, no, I think it was me who was being dim.

Quoted 1 line

Apart from that this looks fine to me.

Thanks.

Ian.

#74 lore raw

PATCH v2 11/20 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+.

---
v2: Pass username and password via a netrc file.

---
 Osstest/PDU/eth008.pm | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 Osstest/PDU/eth008.pm
Osstest/PDU/eth008.pm new file +73 -0
new file mode 100644
index 0000000..f56cfa0
@@ -0,0 +1,73 @@
+# 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 IO::File;
+use File::Temp qw/ tempfile /;
+
+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.
+
+    # Create a netrc file to avoid putting l/p on command line
+    my ($passfh, $passfilename) = tempfile( UNLINK => 1 );
+    print $passfh "machine $mo->{PDU} login $mo->{User} password $mo->{Pass}\n";
+
+    my $url = "http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0";
+    my $cmd = "curl --silent --netrc --netrc-file $passfilename $url";
+
+    logm("$cmd");
+    open CURL, "$cmd |" or die "fork curl: $!";
+    
+    my $result = <CURL>;
+    close CURL or die "result curl: $!";
+
+    logm("$result");
+    die "curl failed" unless $result =~ /^Success! \d+/;
+}
+
+1;
Signature · 1 line
2.1.1
#75 lore raw

Re: [PATCH OSSTEST v2 11/20] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU

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

Quoted 3 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+.

...

Osstest/PDU/eth008.pm line 58

Quoted 3 lines
Osstest/PDU/eth008.pm new file +3 -0
+    # Create a netrc file to avoid putting l/p on command line
+    my ($passfh, $passfilename) = tempfile( UNLINK => 1 );
+    print $passfh "machine $mo->{PDU} login $mo->{User} password $mo->{Pass}\n";

Where does tempfile(UNLINK=>1) create its files and what deletes it if the script crashes ? It might be better to use something in tmp/ (presumably with the host name in the filename). See for example ts-host-install which uses tmp/t.<host>.initrd.

Or of course you could use LWP::UserAgent.

Ian.

#76 lore raw

Re: [PATCH OSSTEST v2 11/20] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU

Quoted 10 lines · Ian Jackson

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

Quoted 3 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+.

...

Osstest/PDU/eth008.pm line 58

Quoted 3 lines
Osstest/PDU/eth008.pm new file +3 -0
+    # Create a netrc file to avoid putting l/p on command line
+    my ($passfh, $passfilename) = tempfile( UNLINK => 1 );
+    print $passfh "machine $mo->{PDU} login $mo->{User} password $mo->{Pass}\n";

Where does tempfile(UNLINK=>1) create its files

I had assumed it was in /tmp (perhaps with handling for $TMP and synonyms). TFD doesn't really say anything about it though.

Quoted 1 line

and what deletes it if the script crashes ?

Nothing (it just does it when the thing goes out of scope).

Quoted 3 lines

It might be better to use something in tmp/
(presumably with the host name in the filename). See for example ts-host-install which uses tmp/t.<host>.initrd.

Good idea.

Quoted 1 line

Or of course you could use LWP::UserAgent.

I'll check that out.

Ian/

#77 lore raw

PATCH v2 12/20 Osstest/Debian: Refactor code to set bootargs in u-boot script

In reply to Ian Campbell
---
 Osstest/Debian.pm | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)
Osstest/Debian.pm +9 -3
index 8f80eb4..3ffbc50 100644
@@ -660,9 +660,15 @@ END
     }
 
     if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
+	my @bootargs;
+
 	my $root=target_guest_lv_name($ho,"root");
-	my $console = get_host_native_linux_console($ho);
-	my $consolecmd = "console=$console" unless $console eq "NONE";
+	my $console=get_host_native_linux_console($ho);
+
+	push @bootargs, "root=$root";
+	push @bootargs, "console=$console" unless $console eq "NONE";
+
+	my $bootargs = join ' ', @bootargs;
 
 	preseed_hook_command($ho, 'late_command', $sfx, <<END);
 #!/bin/sh
@@ -674,7 +680,7 @@ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'`
 initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'`
 
 cat >\$r/boot/boot <<EOF
-setenv bootargs $consolecmd root=$root
+setenv bootargs $bootargs
 mw.l 800000 0 10000
 scsi scan
 ext2load scsi 0 \\\${kernel_addr_r} \$kernel
Signature · 1 line
2.1.1
#78 lore raw

PATCH v2 13/20 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).

---
v2: Install dtbs iff dtbs.tar.gz exists.

---
 Osstest/Debian.pm | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)
Osstest/Debian.pm +20 -3
index 3ffbc50..6bb14f7 100644
@@ -514,6 +514,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 +630,26 @@ $overlays
 echo latecmd done.
 END
 
+    if ( -e "$d_i/dtbs.tar.gz" ) {
+	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.1
#79 lore raw

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

Ian Campbell writes ("[PATCH OSSTEST v2 13/20] 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).

This patch looks good except for one quibble:

Quoted 1 line

+ if ( -e "$d_i/dtbs.tar.gz" ) {

If stat fails with EIO or something, this will proceed as if the dtb doesn't exist. This is generally a problem with perl's -e things. I would use stat and check $! if stat gives false.

See eg the lstat in TestSupport.pm:file_link_contents. (You probably want stat rather than lstat.)

Thanks,
Ian.

#80 lore raw

PATCH v2 14/20 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 6bb14f7..e390ec9 100644
@@ -112,6 +112,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= { };
@@ -130,6 +139,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
@@ -141,9 +152,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
@@ -687,6 +696,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
@@ -698,11 +709,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.1
Acked-by on v2 14/20
#81 lore raw

Re: [PATCH OSSTEST v2 14/20] Osstest/Debian: Support for loading an FDT from u-boot script

Ian Campbell writes ("[PATCH OSSTEST v2 14/20] Osstest/Debian: Support for loading an FDT from u-boot script"):

Quoted 5 lines

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

#82 lore raw

PATCH v2 15/20 Osstest/Debian: Add support for "ExtraInitramfsModules" host property

In reply to Ian Campbell

The arndale platform needs a bunch of clk, phy and regulator stuff in order to access its root filesystem. However mkinitramfs is not (currently?) able to figure this out and therefore doesn't include them in the initrd. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042

Add a new host prop which can list these required additional module and arranges for a suitable /etc/initramfs-tools/modules to be created on install.

Using the new HostGroupProp syntax the required modules are:

HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata

---
v2: References to bugs.

---
 Osstest/Debian.pm | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
Osstest/Debian.pm +17 -0
index e390ec9..5435bdf 100644
@@ -722,6 +722,23 @@ in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
 END
     }
 
+    my $modules = get_host_property($ho, "ExtraInitramfsModules", "NONE");
+    if ( $modules ne "NONE" )
+    {
+	# This is currently the best available way to add modules to
+	# the installed initramfs. See
+	# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764805
+        preseed_hook_command($ho, 'late_command', $sfx, <<END);
+#!/bin/sh
+set -ex
+
+for i in $modules ; do
+    echo \$i >> /target/etc/initramfs-tools/modules
+done
+in-target update-initramfs -u -k all
+END
+    }
+
     my @extra_packages = ();
     push(@extra_packages, "u-boot-tools") if $ho->{Flags}{'need-uboot-bootscr'};
 
Signature · 1 line
2.1.1
Acked-by on v2 15/20
#83 lore raw

Re: [PATCH OSSTEST v2 15/20] Osstest/Debian: Add support for "ExtraInitramfsModules" host property

Ian Campbell writes ("[PATCH OSSTEST v2 15/20] Osstest/Debian: Add support for "ExtraInitramfsModules" host property"):

Quoted 4 lines

The arndale platform needs a bunch of clk, phy and regulator stuff in order to access its root filesystem. However mkinitramfs is not (currently?) able to figure this out and therefore doesn't include them in the initrd. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762042

#84 lore raw

PATCH v2 16/20 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.

---
 Osstest/Debian.pm | 2 ++
 1 file changed, 2 insertions(+)
Osstest/Debian.pm +2 -0
index 5435bdf..8a4ad02 100644
@@ -689,9 +689,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";
 	push @bootargs, "console=$console" unless $console eq "NONE";
 
 	my $bootargs = join ' ', @bootargs;
Signature · 1 line
2.1.1
#85 lore raw

PATCH v2 17/20 Osstest/Debian: Remove hardcoded midway specific addresses from boot.scr

In reply to Ian Campbell

This depends on a change to the hostdb to add "setenv xen_addr_r 0x01000000" to the UBootScriptEarlyCommands property of the midway machines.

Most platforms will need something similar. For both cubietruck and arndale "setenv xen_addr_r 0x41000000" is appropriate.

This is going to be a pretty common requirement on ARM/uboot systems, should I make it a specific property instead of reusing the generic hook?

---
v2: s/go along with/depends on/

---
 Osstest/Debian.pm | 4 ----
 1 file changed, 4 deletions(-)
Osstest/Debian.pm +0 -4
index 8a4ad02..0e808a0 100644
@@ -162,10 +162,6 @@ ${early_commands}
 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.1
#86 lore raw

PATCH v2 18/20 Osstest/Debian: Add "clk_ignore_unused" to default command line

In reply to Ian Campbell

This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed.

---
v2: New patch, previously incorrectly included in "Osstest/Debian: Workaround
oddities in the u-boot script parser."

---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Osstest/Debian.pm +1 -1
index 0e808a0..eb7464c 100644
@@ -171,7 +171,7 @@ 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 ro root=$root clk_ignore_unused"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
 echo command line: $xenkopt ro root=$root
 
Signature · 1 line
2.1.1
#87 lore raw

Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 2 lines

This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed.

This is pretty odd. Doesn't this correspond to some kind of bug, in the dom0 kernel perhaps ?

Ian.

#88 lore raw

Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

create !
title it arm: domain 0 disables clocks which are in fact being used thanks

Quoted 6 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 2 lines

This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed.

This is pretty odd. Doesn't this correspond to some kind of bug, in the dom0 kernel perhaps ?

dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so the bug is probably in the lack of some interface to communicate this from Xen to dom0, or some other mechanism to gate this.

I think some or all of the above ought to be added to the commit message, and perhaps in a comment too. Along with a reference to the bug which this mail should be about to create. Would you like me to do anything else?

Ian.

#89 lore raw

Processed: Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

Processing commands for [email protected]:

Quoted 1 line

create !

Created new bug #45 rooted at `<[email protected]>'
Title: `Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line'

Quoted 1 line

title it arm: domain 0 disables clocks which are in fact being used

Set title for #45 to `arm: domain 0 disables clocks which are in fact being used'

Quoted 1 line

thanks

Finished processing.

Modified/created Bugs:
- 45: http://bugs.xenproject.org/xen/bug/45 (new)

---
Xen Hypervisor Bug Tracker
See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact [email protected] with any infrastructure issues

#90 lore raw

Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

In reply to Ian Campbell

Ian Campbell writes ("Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 3 lines

create !
title it arm: domain 0 disables clocks which are in fact being used thanks

...

Quoted 3 lines

dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so the bug is probably in the lack of some interface to communicate this from Xen to dom0, or some other mechanism to gate this.

Right.

Quoted 4 lines

I think some or all of the above ought to be added to the commit message, and perhaps in a comment too. Along with a reference to the bug which this mail should be about to create. Would you like me to do anything else?

I think that's enough, thanks.

Ian.

#91 lore raw

Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

In reply to Ian Campbell

Hi,

Somehow I missed this email.

Quoted 9 lines · Ian Campbell

create !
title it arm: domain 0 disables clocks which are in fact being used thanks

Quoted 4 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 2 lines

This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed.

Quoted 6 lines
Quoted 2 lines

This is pretty odd. Doesn't this correspond to some kind of bug, in the dom0 kernel perhaps ?

dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so the bug is probably in the lack of some interface to communicate this from Xen to dom0, or some other mechanism to gate this.

In reality, Xen is only using the clock of the UART. Even though, I think this would also happen with platform device passthrough.

For the latter, it would be fairly easy via a PV drivers. But for UART... gating the clock could be a nightmare because every platform have their own way to enable/disable the clock. Futhermore, the clock could be shared with multiple device...

I'm wondering if we could expose the UART to DOM0 without marking as disabled. It would avoid DOM0 to mess up the clock while everything would be catch via the vuart implementation in Xen.

Regards,

Signature · 1 line
Julien Grall
#92 lore raw

Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

Quoted 24 lines · Julien Grall

Hi,

Somehow I missed this email.

Quoted 9 lines · Ian Campbell

create !
title it arm: domain 0 disables clocks which are in fact being used thanks

Quoted 4 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 2 lines

This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed.

Quoted 6 lines
Quoted 2 lines

This is pretty odd. Doesn't this correspond to some kind of bug, in the dom0 kernel perhaps ?

dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so the bug is probably in the lack of some interface to communicate this from Xen to dom0, or some other mechanism to gate this.

In reality, Xen is only using the clock of the UART. Even though, I think this would also happen with platform device passthrough.

Quoted 8 lines

For the latter, it would be fairly easy via a PV drivers. But for UART... gating the clock could be a nightmare because every platform have their own way to enable/disable the clock. Futhermore, the clock could be shared with multiple device...

I'm wondering if we could expose the UART to DOM0 without marking as disabled. It would avoid DOM0 to mess up the clock while everything would be catch via the vuart implementation in Xen.

Perhaps we could propagate any clock related properties from the UART node into the Xen hypervisor node (or a subnode)? The Xen Linux code would then consume those and mark the relevant clocks as in use. I've not looked into the clock bindings to know how plausible this might be.

Ian.

#93 lore raw

Re: [PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line

Quoted 30 lines · Ian Campbell
Quoted 29 lines · Julien Grall

Hi,

Somehow I missed this email.

Quoted 9 lines · Ian Campbell

create !
title it arm: domain 0 disables clocks which are in fact being used thanks

Quoted 4 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 18/20] Osstest/Debian: Add "clk_ignore_unused" to default command line"):

Quoted 2 lines

This stops dom0 from messing with clocks which it should and is required on some platforms. It's harmless even when not needed.

Quoted 6 lines
Quoted 2 lines

This is pretty odd. Doesn't this correspond to some kind of bug, in the dom0 kernel perhaps ?

dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so the bug is probably in the lack of some interface to communicate this from Xen to dom0, or some other mechanism to gate this.

In reality, Xen is only using the clock of the UART. Even though, I think this would also happen with platform device passthrough.

For the latter, it would be fairly easy via a PV drivers. But for UART... gating the clock could be a nightmare because every platform have their own way to enable/disable the clock. Futhermore, the clock could be shared with multiple device...

Quoted 8 lines
Quoted 3 lines

I'm wondering if we could expose the UART to DOM0 without marking as disabled. It would avoid DOM0 to mess up the clock while everything would be catch via the vuart implementation in Xen.

Perhaps we could propagate any clock related properties from the UART node into the Xen hypervisor node (or a subnode)? The Xen Linux code would then consume those and mark the relevant clocks as in use. I've not looked into the clock bindings to know how plausible this might be.

It looks like the bindings for clock is well defined and fairly common (Documentation/devicetree/bindins/clock/clock-bindings.txt). So your solution sounds plausible.

Regards,

Signature · 1 line
Julien Grall
#94 lore raw

PATCH v2 19/20 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.

---
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 eb7464c..9d105b1 100644
@@ -170,7 +170,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 ro root=$root clk_ignore_unused"
 echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
 echo command line: $xenkopt ro root=$root
@@ -178,7 +178,7 @@ echo command line: $xenkopt ro root=$root
 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.1
#95 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

Ian Campbell writes ("[PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 2 lines

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly.

What will happen if they fix u-boot ?

Ian.

#96 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

Quoted 5 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 2 lines

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly.

What will happen if they fix u-boot ?

I've sent http://lists.denx.de/pipermail/u-boot/2014-October/193622.html

Lets see where they consider the bug to be (if anywhere)

Ian.

#97 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

Quoted 10 lines · Ian Campbell
Quoted 5 lines · Ian Jackson

Ian Campbell writes ("[PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 2 lines

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly.

What will happen if they fix u-boot ?

I've sent http://lists.denx.de/pipermail/u-boot/2014-October/193622.html

Lets see where they consider the bug to be (if anywhere)

In the meantime I've added this URL to the commit message.

#98 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

In reply to Ian Campbell

Ian Campbell writes ("Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 10 lines · Ian Jackson
Quoted 5 lines

Ian Campbell writes ("[PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 2 lines

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly.

What will happen if they fix u-boot ?

I've sent http://lists.denx.de/pipermail/u-boot/2014-October/193622.html

Lets see where they consider the bug to be (if anywhere)

Right.

I'm a bit worried that if they fix this by making the value contain a 0x at the start, it will break your workaround.

Ian.

#99 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

Quoted 8 lines · Ian Jackson

Ian Campbell writes ("Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 7 lines · Ian Jackson
Quoted 5 lines

Ian Campbell writes ("[PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 2 lines

$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly.

What will happen if they fix u-boot ?

Quoted 8 lines
Quoted 3 lines

I've sent http://lists.denx.de/pipermail/u-boot/2014-October/193622.html

Lets see where they consider the bug to be (if anywhere)

Right.

I'm a bit worried that if they fix this by making the value contain a 0x at the start, it will break your workaround.

Right.

Note that updating u-boot on these boards requires someone to actually go and reflash them, we don't do it as part of each test run for example.

Ian.

#100 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

Ian Campbell writes ("Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 3 lines

Note that updating u-boot on these boards requires someone to actually go and reflash them, we don't do it as part of each test run for example.

Ah, OK, that makes it less of a potential annoyance.

Ian.

#101 lore raw

Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize

Quoted 6 lines · Ian Jackson

Ian Campbell writes ("Re: [PATCH OSSTEST v2 19/20] Osstest/Debian: Add 0x prefix to $filesize"):

Quoted 3 lines

Note that updating u-boot on these boards requires someone to actually go and reflash them, we don't do it as part of each test run for example.

Ah, OK, that makes it less of a potential annoyance.

Or at least a controlled annoyance which we'll have brought onto ourselves at the time of our choosing ;-)

#102 lore raw

PATCH v2 20/20 ts-kernel-build: Enable CONFIG_PHY_EXYNOS5250_SATA

In reply to Ian Campbell

Enables the disk on an arndale, which isn't enabled by default in v3.16 for some reason.

---
 ts-kernel-build | 2 ++
 1 file changed, 2 insertions(+)
ts-kernel-build +2 -0
index 3b48920..bae118c 100755
@@ -171,6 +171,8 @@ setopt CONFIG_BLK_DEV_NBD y
 # At least with Linux 3.4.77 on wheezy, the nbd module is
 # not loaded automatically.
 
+setopt CONFIG_PHY_EXYNOS5250_SATA y
+
 END
 
 our $config_features= <<END;
Signature · 1 line
2.1.1
#103 lore raw
In reply to Ian Campbell
Quoted 7 lines · Ian Campbell

Since v1 I've reordered to pulled the stuff which relates to updating mg-debian-installer-update and TftpDiVersion to the front, in the hopes of getting that in sooner. This includes everything up to at least "ts-host-install: include console before *and* after the -- marker." which is needed because rerunning mg-debian-installer-update today will pull in a kernel which is affected by that issue. In reality the initial set of acked patches here is larger.

I've pushed the first 8 which were acked:
50d9107 standalone: Provide a helper to clear the host runvar 81f6b3b mg-debian-installer-update: Include any device tree blobs in the tftp dir 5c94792 mg-debian-installer-update: Add more modules when creating initrd overlay 54fdfe0 ts-host-install: Add fdtdir to PXE stanza if dtbs directory exists cd903c2 ts-host-install: Refactor code to construct a Linux console= for a host db26f58 ts-host-install: include console before *and* after the -- marker. d11e246 ts-host-install: Add option to boot debian-installer in rescue mode ff9e0d8 ts-host-install: Add force-mac-address host flag

Once this set has passed osstest's own push gate I intend to followup with a mass rerun of ./mg-debian-installer-update and an update to production-config.

Ian.

#104 lore raw

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

Quoted 3 lines

Once this set has passed osstest's own push gate I intend to followup with a mass rerun of ./mg-debian-installer-update and an update to production-config.

Jolly good. Assuming the config update is what I expect (just a change to the d-i generation date) you have my (pre-emptive) ack for it.

Ian.

#105 lore raw
Quoted 8 lines · Ian Jackson

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

Quoted 3 lines

Once this set has passed osstest's own push gate I intend to followup with a mass rerun of ./mg-debian-installer-update and an update to production-config.

Jolly good. Assuming the config update is what I expect (just a change to the d-i generation date) you have my (pre-emptive) ack for it.

Yes, it will be exactly that, thanks.

BTW, is there some helper which will call mg-debian-installer-update the appropriate number of times with the right args for each arch for a production system update?

AFAIK there is only a helper for standalone mode.

Ian.

#106 lore raw

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

Quoted 3 lines

BTW, is there some helper which will call mg-debian-installer-update the appropriate number of times with the right args for each arch for a production system update?

No.

Quoted 1 line

AFAIK there is only a helper for standalone mode.

Feel free to write one :-).

Ian.

#107 lore raw
Quoted 10 lines · Ian Jackson

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

Quoted 3 lines

BTW, is there some helper which will call mg-debian-installer-update the appropriate number of times with the right args for each arch for a production system update?

No.

Quoted 1 line

AFAIK there is only a helper for standalone mode.

Feel free to write one :-).

It's a bit noddy, but how about:

----8<----------------

Quoted 1 line

From 3ec8b49595849d19e4dfd6ed786f540fba9b3ebd Mon Sep 17 00:00:00 2001

From: Ian Campbell <[email protected]>
Date: Thu, 30 Oct 2014 11:39:17 +0000
Subject: [PATCH] Add simple helper to update DI for all architectures.

Uses DebianNonfreeFirmware, even (especially) for production, so move the README stanza out of standalone only section. The current default matches what is in the current production versions of DI.

---
 README                         | 16 ++++++++--------
 mg-debian-installer-update-all | 31 +++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+), 8 deletions(-)
 create mode 100755 mg-debian-installer-update-all
README +8 -8
index 5ba695d..35532b7 100644
@@ -360,14 +360,6 @@ DebianPreseed
    but you will need to set some NTP servers here if your firewall
    doesn't permit NTP to Debian's pool.ntp.org servers.
 
-DebianNonfreeFirmware
-  List of debs of non-free firmware to include in the massaged
-  debian-installer.  You will need this if you want to use network
-  card which requires non-free firmware.  The default is just
-  "firmware-bnx2'.  If your host operating system doesn't have
-  grep-dctrl (for example because it's not Debian) then you must set
-  this to the empty string, by writing  DebianNonfreeFirmware=''
-
 ========================================
 
 Config settings relevant only to standalone mode
@@ -423,6 +415,14 @@ GuestDebianSuite   defaults to DebianSuite
 
 DebianPreseed      added to existing preseed file
 
+DebianNonfreeFirmware
+  List of debs of non-free firmware to include in the massaged
+  debian-installer.  You will need this if you want to use network
+  card which requires non-free firmware.  The default is just
+  "firmware-bnx2'.  If your host operating system doesn't have
+  grep-dctrl (for example because it's not Debian) then you must set
+  this to the empty string, by writing  DebianNonfreeFirmware=''
+
 TftpFoo_<scope> and TftpFoo
 
     Describes various properties relating to Tftp in a given <scope>,
mg-debian-installer-update-all new file +31 -0
new file mode 100755
index 0000000..eca4a5f
@@ -0,0 +1,31 @@
+#!/bin/bash
+# usage
+#   ./mg-debian-installer-update-all
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2015 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/>.
+
+set -e
+
+. cri-getconfig
+
+suite=`getconfig DebianSuite`
+fws=`getconfig DebianNonfreeFirmware`
+arches="armhf amd64 i386"
+
+for arch in $arches ; do
+    ./mg-debian-installer-update $suite $arch $fws
+done
Signature · 1 line
2.1.1
#108 lore raw

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

Quoted 1 line

It's a bit noddy, but how about:

LGTM. Consider it acked and push it whenever convenient.

Ian.

author Acked-by Ian Jackson
#109 lore raw
In reply to Ian Campbell
Quoted 11 lines · Ian Campbell
Quoted 8 lines · Ian Jackson

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

Quoted 3 lines

Once this set has passed osstest's own push gate I intend to followup with a mass rerun of ./mg-debian-installer-update and an update to production-config.

Jolly good. Assuming the config update is what I expect (just a change to the d-i generation date) you have my (pre-emptive) ack for it.

Yes, it will be exactly that, thanks.

i.e. the below which I've just now pushed.

Quoted 5 lines

BTW, is there some helper which will call mg-debian-installer-update the appropriate number of times with the right args for each arch for a production system update?

AFAIK there is only a helper for standalone mode.

I stuck this helper in there too.

Ian.

commit 4eed3c718ac02dd81dfbee09e8c779fb9f32ec52

Author: Ian Campbell <[email protected]>
Date:   Mon Nov 3 10:20:55 2014 +0000

TftpDiVersion 2014-11-03

Picks up changes on armhf to include dtbs and more modules in the initrd overlay.

production-config +1 -1
index 2b3ec10..8b2c3e1 100644
@@ -68,7 +68,7 @@ TftpPxeDir /
 TftpPxeTemplates %ipaddrhex%/pxelinux.cfg
 
 TftpPxeGroup osstest
-TftpDiVersion 2014-10-20
+TftpDiVersion 2014-11-03
 
 XenUsePath /usr/groups/xencore/systems/bin/xenuse
 XenUseUser osstest