support for ARM32 arndale and cubietruck platforms
v4 cover support for ARM32 arndale and cubietruck platforms
I'm preparing a bunch of each of these boards to be racked for inclusion in osstest. This series adds the necessary osstest support:
* Support for platforms which require us to supply a Device Tree
* Removing various hardcoded midway assumptions
* Some new features needed to workaround h/w quirks (of arndale in particular)
* Support for the power relay switch board which these are attached to
* Some new convenience features
I have run a full (including host reinstall) build-* job on each platform on v3, but not on v4 which is mostly functionality unchanged.
Since v4 I've wrapped the commit messages. Resending with that done on your request.
The system is also now in the osstest rack here in Cambridge (pending move to the new colo). For reference the relevant bits of my ~/.xen-osstest/config are below, updated for new DNS and boards renamed with the their type as a prefix (per discussion IRL).
A bunch of the early patches have gone in already, including all the mg-debian-installer-update related stuff, and it has been rerun so there is no longer a dependency on rerunning it.
Ian.
PlatformsArmhf midway cubietruck arndale
HostProp_arndale-metrocentre_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 1 HostProp_arndale-westfield_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 2 HostProp_arndale-lakeside_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 3 HostProp_arndale-bluewater_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 4
HostProp_cubietruck-braque_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 5 HostProp_cubietruck-picaso_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 6 HostProp_cubietruck-metzinger_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 7 HostProp_cubietruck-gleizes_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 8
HostGroupProp_arndale_LinuxSerialConsole ttySAC2 HostGroupProp_arndale_Build_Make_Flags -j4 HostGroupProp_arndale_XenSerialConsole dtuart HostGroupProp_arndale_XenDTUARTPath /serial@12C20000 HostGroupProp_arndale_Interface_Force eth0 HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata HostGroupProp_arndale_Rootdelay 3HostGroupProp_arndale_UBootSetXenAddrR 0x41000000HostGroupProp_arndale_Serial sympathy osstser1 HostGroupProp_arndale_PowerCycleTime 15HostGroupProp_arndale_TftpScope xenclient
HostGroupFlags_arndale suite-wheezy,platform-arndale,need-kernel-deb-armmp,no-di-kernel,force-mac-address,need-uboot-bootscr
HostGroup_arndale-metrocentre arndale HostProp_arndale-metrocentre_Fqdn arndale-metrocentre.cam.xci-test.com HostProp_arndale-metrocentre_Ether 9e:04:00:59:64:5a
HostGroup_arndale-westfield arndale HostProp_arndale-westfield_Fqdn arndale-westfield.cam.xci-test.com HostProp_arndale-westfield_Ether a6:46:13:77:e8:2f
HostGroup_arndale-lakeside arndale HostProp_arndale-lakeside_Fqdn arndale-lakeside.cam.xci-test.com HostProp_arndale-lakeside_Ether e2:e7:75:3f:df:4c
HostGroup_arndale-bluewater arndale HostProp_arndale-bluewater_Fqdn arndale-bluewater.cam.xci-test.com HostProp_arndale-bluewater_Ether f2:dc:22:d7:e9:e9
HostGroupProp_cubietruck_LinuxSerialConsole ttyS0 HostGroupProp_cubietruck_Build_Make_Flags -j4 HostGroupProp_cubietruck_XenSerialConsole dtuart HostGroupProp_cubietruck_XenDTUARTPath /soc@01c00000/serial@01c28000 HostGroupProp_cubietruck_UBootSetXenAddrR 0x41000000 HostGroupProp_cubietruck_Serial sympathy arm-serial-01 HostGroupProp_cubietruck_TftpScope xenclient
HostGroupFlags_cubietruck suite-wheezy,platform-cubietruck,need-kernel-deb-armmp,no-di-kernel,need-uboot-bootscr
HostGroup_cubietruck-braque cubietruck HostProp_cubietruck-braque_Fqdn cubietruck-braque.cam.xci-test.com
HostGroup_cubietruck-picaso cubietruck HostProp_cubietruck-picaso_Fqdn cubietruck-picaso.cam.xci-test.com
HostGroup_cubietruck-metzinger cubietruck HostProp_cubietruck-metzinger cubietruck-metzinger.cam.xci-test.com
HostGroup_cubietruck-gleizes cubietruck HostProp_cubietruck-gleizes_Fqdn cubietruck-gleizes.cam.xci-test.com
PATCH v4 1/13 make-flight: Run a basic test on each arm platform
Unlike x86 there is enough variation in the ARM platforms that it is worth having a basic test on each as part of a standard run. This relies on each host having an appropriate platform-$platform host flag.
The existing test-ARCH-ARCH-xl test is retained as a floating test, while a new variant is added for each distinct platform present in the hostdb which is tied to that platform type. The intention is that only arm platforms will have platforms at first, although perhaps platform-intel and platform-amd could be added in the future too.
There are currently no platform-* flags in the hostdb, so tested with s/platform-/equiv-/ and:
( set -ex ;
source ./cri-getplatforms ;
blessing=real ;
export OSSTEST_CONFIG=production-config ;
for p in '' `getplatforms "armhf"` ; do
set +x ;
echo PLATFORM: $p ;
done )
which prints:
PLATFORM:
PLATFORM: marilith
and with s/armhf/amd64/:
PLATFORM:
PLATFORM: rackservers-s40670
PLATFORM: r310-moth
PLATFORM: rackservers-s40680
PLATFORM: dell-r310
PLATFORM: rackservers-s40679
PLATFORM: rackservers-s40663
PLATFORM: rackservers-q21011
Also tested in standalone mode with a ~/.xen-osstest/config containing:
PlatformsArmhf midway cubietruck arndale
---
v3:
Split /\s+/
v2:
Use platform-* prop not equiv-*
Select platforms from host db
---
Osstest/HostDB/Executive.pm | 28 ++++++++++++++++++++++++++++
Osstest/HostDB/Static.pm | 9 +++++++++
README | 3 +++
cri-getplatforms | 25 +++++++++++++++++++++++++
make-flight | 9 +++++++--
5 files changed, 72 insertions(+), 2 deletions(-)
create mode 100755 cri-getplatformsOsstest/HostDB/Executive.pm +28 -0
@@ -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
@@ -65,6 +65,15 @@ sub get_flags ($$) { #method return $flags; } +sub get_arch_platforms ($$) { + my ($hd, $blessing, $arch) = @_; + + my $prop = "Platforms".ucfirst($arch); + + return split /\s+/, $c{$prop} if $c{$prop}; + return () unless $c{$prop}; +} + sub default_methods ($$) { #method my ($hd, $ho) = @_;
README +3 -0
@@ -396,6 +396,9 @@ The keys in ~/.ssh/id_{rsa,dsa}.pub and ~/.ssh/authorized_keys TestHostKeypairPath +Platforms<Arch> + List of platforms (i.e. distinct host types) to run a basic test on. + HostProp_GenEtherPrefixBase 5e:36:0e:f5 # :00:01 guest number in job appended # in standalone jobdb, ^^^^^ xor'd with low 16 bits of your uid
cri-getplatforms new file +25 -0
@@ -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
@@ -27,6 +27,7 @@ buildflight=$4 flight=`./cs-flight-create $blessing $branch` . cri-common +. cri-getplatforms . ap-common . mfi-common
@@ -284,10 +285,14 @@ do_passthrough_tests () { test_matrix_do_one () { # Basic PV Linux test with xl + for platform in '' `getplatforms $xenarch` ; do + suffix=${platform:+-$platform} + hostflags=${most_hostflags}${platform:+,platform-$platform} - job_create_test test-$xenarch$kern-$dom0arch-xl test-debian xl \ + job_create_test test-$xenarch$kern-$dom0arch-xl$suffix test-debian xl \ $xenarch $dom0arch \ - $debian_runvars all_hostflags=$most_hostflags + $debian_runvars all_hostflags=$hostflags + done job_create_test test-$xenarch$kern-$dom0arch-libvirt test-debian libvirt \ $xenarch $dom0arch \
Signature · 1 line
2.1.4
PATCH v4 2/13 Osstest/PDU: Add eth008.pm method to control the ARM rack PDU
In reply to Ian CampbellThis controls the eth008 relay board:
http://www.robot-electronics.co.uk/htm/eth008tech.htm
Due to the use of the CGI interface this requires firmware version 4+.
---
v3: Use LWP::UserAgent
v2: Pass username and password via a netrc file.
--- Osstest/PDU/eth008.pm | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 65 insertions(+) create mode 100644 Osstest/PDU/eth008.pm
Osstest/PDU/eth008.pm new file +65 -0
@@ -0,0 +1,65 @@ +# This is part of "osstest", an automated testing framework for Xen. +# Copyright (C) 2014 Citrix Inc. +# +# This program is free software: you can redistribute it and/or modify +# it under the terms of the GNU Affero General Public License as published by +# the Free Software Foundation, either version 3 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Affero General Public License for more details. +# +# You should have received a copy of the GNU Affero General Public License +# along with this program. If not, see <http://www.gnu.org/licenses/>. + +package Osstest::PDU::eth008; + +use strict; +use warnings; + +use Osstest; +use Osstest::TestSupport; +use LWP::UserAgent; + +BEGIN { + use Exporter (); + our ($VERSION, @ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS); + $VERSION = 1.00; + @ISA = qw(Exporter); + @EXPORT = qw(); + %EXPORT_TAGS = ( ); + + @EXPORT_OK = qw(); +} + +sub new { + my ($class, $ho, $methname, $pdu, $user, $pass, $port, @opts) = @_; + return bless { Host => $ho, + PDU => $pdu, + User => $user, + Pass => $pass, + Port => $port, + Opts => \@opts }, $class; +} + +sub pdu_power_state { + my ($mo, $on) = @_; + my $op= $on ? "DOA" : "DOI"; # Digital Output (In)Active + + # Use the CGI interface since it is less prone to being firewalled + # off, unlike the standard interface on port 17494. This is only + # available from firmware v4 onwards. + + my $ua = LWP::UserAgent->new; + + $ua->credentials("$mo->{PDU}:80", "Protected", $mo->{User}, $mo->{Pass}); + + my $resp = $ua->get("http://$mo->{PDU}/io.cgi?$op$mo->{Port}=0"); + + die "failed" unless $resp->is_success; + logm($resp->decoded_content); +} + +1;
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 02/13] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU
Ian Campbell writes ("[PATCH OSSTEST v4 02/13] Osstest/PDU: Add eth008.pm method to control the ARM rack PDU"):
Quoted 4 lines
This controls the eth008 relay board:
http://www.robot-electronics.co.uk/htm/eth008tech.htmDue to the use of the CGI interface this requires firmware version 4+.
PATCH v4 3/13 Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs
In reply to Ian CampbellThis is done whenever dtbs.tar.gz exists. mg-debian-installer-update produces the necessary inputs on the relevant platform (armhf).
---
v3: More careful check/stat for existence of dtbs.tar.gz
v2: Install dtbs iff dtbs.tar.gz exists.
--- Osstest/Debian.pm | 28 +++++++++++++++++++++++++--- 1 file changed, 25 insertions(+), 3 deletions(-)
Osstest/Debian.pm +25 -3
@@ -20,6 +20,8 @@ package Osstest::Debian; use strict; use warnings; +use POSIX; + use IO::File; use File::Copy;
@@ -514,6 +516,9 @@ sub preseed_create ($$;@) { my $disk= $xopts{DiskDevice} || '/dev/sda'; my $suite= $xopts{Suite} || $c{DebianSuite}; + my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'. + $c{TftpDiVersion}.'-'.$ho->{Suite}; + my $hostsq= $dbh_tests->prepare(<<END); SELECT val FROM runvars WHERE flight=? AND name LIKE '%host'
@@ -627,12 +632,29 @@ $overlays echo latecmd done. END + my $dtbs = "$d_i/dtbs.tar.gz"; + if (!stat $dtbs) { + $!==&ENOENT or die "dtbs $!"; + } elsif (-e _) { + my $durl = create_webfile($ho, "dtbs", sub { + copy("$d_i/dtbs.tar.gz", $_[0]) + or die "Copy dtbs failed: $!"; + }); + preseed_hook_command($ho, 'late_command', $sfx, <<END); +#!/bin/sh +set -ex + +r=/target + +wget -O \$r/tmp/dtbs.tar.gz $durl + +in-target tar -C /boot -xaf /tmp/dtbs.tar.gz +END + } + foreach my $kp (keys %{ $ho->{Flags} }) { $kp =~ s/need-kernel-deb-// or next; - my $d_i= $ho->{Tftp}{Path}.'/'.$ho->{Tftp}{DiBase}.'/'.$r{arch}.'/'. - $c{TftpDiVersion}.'-'.$ho->{Suite}; - my $kurl = create_webfile($ho, "kernel", sub { copy("$d_i/$kp.deb", $_[0]) or die "Copy kernel failed: $!";
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 03/13] Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs
Ian Campbell writes ("[PATCH OSSTEST v4 03/13] Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs"):
Quoted 2 lines
This is done whenever dtbs.tar.gz exists. mg-debian-installer-update produces the necessary inputs on the relevant platform (armhf).
PATCH v4 4/13 Osstest/Debian: Support for loading an FDT from u-boot script
In reply to Ian CampbellThe 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
@@ -114,6 +114,15 @@ sub bl_getmenu_open ($$$) { return $f; } +sub uboot_scr_load_dtb () { + return <<'END'; +if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then + echo Loading dtbs/\${fdtfile} + ext2load scsi 0 \${fdt_addr_r} dtbs/\${fdtfile} + setenv fdt_addr \${fdt_addr_r} +fi +END +} sub setupboot_uboot ($$$) { my ($ho,$want_kernver,$xenhopt,$xenkopt) = @_; my $bl= { };
@@ -132,6 +141,8 @@ sub setupboot_uboot ($$$) { my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', ''); + my $load_dtb = uboot_scr_load_dtb(); + target_cmd_root($ho, <<END); if test ! -f /boot/$kern ; then exit 1
@@ -143,9 +154,7 @@ cp -n /boot/boot.scr /boot/boot.scr.bak xen=`readlink /boot/$xen` cat >/boot/boot <<EOF - -mw.l 800000 0 10000 -scsi scan +${load_dtb} fdt addr \\\${fdt_addr} fdt resize
@@ -692,6 +701,8 @@ END my $bootargs = join ' ', @bootargs; + my $load_dtb = uboot_scr_load_dtb(); + preseed_hook_command($ho, 'late_command', $sfx, <<END); #!/bin/sh set -ex
@@ -703,11 +714,13 @@ initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'` cat >\$r/boot/boot <<EOF setenv bootargs $bootargs -mw.l 800000 0 10000 -scsi scan +${load_dtb} +echo Loading \$kernel ext2load scsi 0 \\\${kernel_addr_r} \$kernel +echo Loading \$initrd ext2load scsi 0 \\\${ramdisk_addr_r} \$initrd -bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} 0x1000 +echo Booting +bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr} EOF in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr
Signature · 1 line
2.1.4
PATCH v4 5/13 Osstest/Debian: Refactor setting of dom0 kernel command line.
In reply to Ian CampbellThis will make it easier to make components optional in the future.
--- Osstest/Debian.pm | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
Osstest/Debian.pm +9 -2
@@ -136,6 +136,13 @@ sub setupboot_uboot ($$$) { my $root= target_guest_lv_name($ho,"root"); + my @xenkopt; + push @xenkopt, $xenkopt; + push @xenkopt, "ro"; + push @xenkopt, "root=$root"; + + $xenkopt = join ' ', @xenkopt; + logm("Xen options: $xenhopt"); logm("Linux options: $xenkopt");
@@ -177,9 +184,9 @@ ext2load scsi 0 \\\${kernel_addr_r} $kern fdt mknod /chosen module\@0 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module" fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}> -fdt set /chosen/module\@0 bootargs "$xenkopt ro root=$root" +fdt set /chosen/module\@0 bootargs "$xenkopt" echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize}) -echo command line: $xenkopt ro root=$root +echo command line: $xenkopt ext2load scsi 0 \\\${ramdisk_addr_r} $initrd fdt mknod /chosen module\@1
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 05/13] Osstest/Debian: Refactor setting of dom0 kernel command line.
Ian Campbell writes ("[PATCH OSSTEST v4 05/13] Osstest/Debian: Refactor setting of dom0 kernel command line."):
Quoted 1 line
This will make it easier to make components optional in the future.
Ian.
PATCH v4 6/13 Osstest/Debian: support adding a rootdelay property to bootargs
In reply to Ian Campbellarndale appears to be quite slow (and asynchronous) at finding it's scsi controller. rootdelay=3 seems to do the trick.
For the dom0 case this involved refactoring the existing provision of the commandline to be less open-coded in the boot script here doc.
---
v3: Honour rootdelay when booting dom 0.
--- Osstest/Debian.pm | 4 ++++ 1 file changed, 4 insertions(+)
Osstest/Debian.pm +4 -0
@@ -135,11 +135,13 @@ sub setupboot_uboot ($$$) { my $initrd = "initrd.img-$want_kernver"; my $root= target_guest_lv_name($ho,"root"); + my $rootdelay=get_host_property($ho, "rootdelay"); my @xenkopt; push @xenkopt, $xenkopt; push @xenkopt, "ro"; push @xenkopt, "root=$root"; + push @xenkopt, "rootdelay=$rootdelay" if $rootdelay; $xenkopt = join ' ', @xenkopt;
@@ -701,9 +703,11 @@ END my @bootargs; my $root=target_guest_lv_name($ho,"root"); + my $rootdelay=get_host_property($ho, "rootdelay"); my $console=get_host_native_linux_console($ho); push @bootargs, "root=$root"; + push @bootargs, "rootdelay=$rootdelay" if $rootdelay; push @bootargs, "console=$console" unless $console eq "NONE"; my $bootargs = join ' ', @bootargs;
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs
Ian Campbell writes ("[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):
Quoted 5 lines
arndale appears to be quite slow (and asynchronous) at finding it's scsi controller. rootdelay=3 seems to do the trick.
For the dom0 case this involved refactoring the existing provision of the commandline to be less open-coded in the boot script here doc.
The two hunks in this patch are starting to be rather similar. Perhaps it would be worth combining them ? (I notice that the setup_uboot one doesn't handle the console - presumably it is right by default, but perhaps it ought to use the common console selection, if it does the right thing by default.)
Quoted 2 lines
Signed-off-by Ian Campbell <[email protected]>Acked-by Ian Jackson <[email protected]>
Ian.
Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs
Quoted 9 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):
Quoted 5 lines
arndale appears to be quite slow (and asynchronous) at finding it's scsi controller. rootdelay=3 seems to do the trick.
For the dom0 case this involved refactoring the existing provision of the commandline to be less open-coded in the boot script here doc.
The two hunks in this patch are starting to be rather similar. Perhaps it would be worth combining them ?
Yes it would. Below is the incremental patch to the end of the series, which I will fold appropriately back into a precursor to do the refactor and then this patch adding the rootdelay (nb I fixed the spacing you complained about elsewhere while I was here).
Are you OK with me keeping your ack on this one once updated? It would be essentially either of the two current hunks applied to the new function instead.
BTW, another side effect is adding "ro" in the Xen case, which I think was a bug to omit until now, I'll find an appropriate place to fix that.
Ian.
Osstest/Debian.pm +17 -12
@@ -114,6 +114,21 @@ sub bl_getmenu_open ($$$) { return $f; } +sub uboot_common_kernel_bootargs ($) +{ + my ( $ho ) = @_; + + my $root= target_guest_lv_name($ho,"root"); + my $rootdelay= get_host_property($ho, "rootdelay"); + + my @bootargs; + push @bootargs, "ro"; + push @bootargs, "root=$root"; + push @bootargs, "rootdelay=$rootdelay" if $rootdelay; + + return @bootargs; +} + sub uboot_scr_load_dtb () { return <<'END'; if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
@@ -134,18 +149,12 @@ sub setupboot_uboot ($$$) { my $kern = "vmlinuz-$want_kernver"; my $initrd = "initrd.img-$want_kernver"; - my $root= target_guest_lv_name($ho,"root"); - my $rootdelay=get_host_property($ho, "rootdelay"); my $natcons=get_host_native_linux_console($ho); logm("Xen options: $xenhopt"); # Common kernel options - my @kopt; - - push @kopt, "ro"; - push @kopt, "root=$root"; - push @kopt, "rootdelay=$rootdelay" if $rootdelay; + my @kopt = uboot_common_kernel_bootargs($ho); # Dom0 specific kernel options my @xenkopt = @kopt;
@@ -731,14 +740,10 @@ END } if ( $ho->{Flags}{'need-uboot-bootscr'} ) { - my @bootargs; + my @bootargs = uboot_common_kernel_bootargs($ho); - my $root=target_guest_lv_name($ho,"root"); - my $rootdelay=get_host_property($ho, "rootdelay"); my $console=get_host_native_linux_console($ho); - push @bootargs, "root=$root"; - push @bootargs, "rootdelay=$rootdelay" if $rootdelay; push @bootargs, "console=$console" unless $console eq "NONE"; my $bootargs = join ' ', @bootargs;
Ian Jackson
Acked-byRe: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs
Ian Campbell writes ("Re: [PATCH OSSTEST v4 06/13] Osstest/Debian: support adding a rootdelay property to bootargs"):
Quoted 3 lines
Are you OK with me keeping your ack on this one once updated? It would be essentially either of the two current hunks applied to the new function instead.
Yes.
Osstest/Debian.pm sub bl_getmenu_open ($$$) { · line 119
Quoted 6 lines
BTW, another side effect is adding "ro" in the Xen case, which I think was a bug to omit until now, I'll find an appropriate place to fix that.
Osstest/Debian.pm +3
-0+sub uboot_common_kernel_bootargs ($) +{ + my ( $ho ) = @_;
^ ^
Coding style.
Otherwise,
Ian.
PATCH v4 7/13 Osstest/Debian: Remove hardcoded addresses from boot.scr
In reply to Ian CampbellThose are specific to the midway platform.
This depends on a change to the hostdb to add "0x01000000" as the value of a new UBootSetXenAddrR property of the midway machines.
Most platforms will need something similar. For both cubietruck and arndale 0x41000000.
---
v3: Move the property to a specific one like I was supposed to last
time
v2: s/go along with/depends on/
--- Osstest/Debian.pm | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
Osstest/Debian.pm +5 -4
@@ -149,9 +149,13 @@ sub setupboot_uboot ($$$) { logm("Linux options: $xenkopt"); my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', ''); + my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef); my $load_dtb = uboot_scr_load_dtb(); + my $set_xen_addr_r = + $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : ""; + target_cmd_root($ho, <<END); if test ! -f /boot/$kern ; then exit 1
@@ -169,14 +173,11 @@ fdt addr \\\${fdt_addr} fdt resize ${early_commands} +${set_xen_addr_r} fdt set /chosen \\\#address-cells <1> fdt set /chosen \\\#size-cells <1> -setenv xen_addr_r 0x01000000 -# kernel_addr_r=0x02000000 -# ramdisk_addr_r=0x04000000 - ext2load scsi 0 \\\${xen_addr_r} \$xen setenv bootargs "$xenhopt" echo Loaded \$xen to \\\${xen_addr_r} (\\\${filesize})
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr
Ian Campbell writes ("[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr"):
Quoted 7 lines
Those are specific to the midway platform.
This depends on a change to the hostdb to add "
0x01000000" as the value of a new UBootSetXenAddrR property of the midway machines.Most platforms will need something similar. For both cubietruck and arndale
0x41000000.
(I expect you agree with me that the fact we can't get this information some other way is a defect elsewhere, but this is a fine workaround.)
Ian.
Re: [PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr
Quoted 6 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 07/13] Osstest/Debian: Remove hardcoded addresses from boot.scr"):
Quoted 5 lines
Those are specific to the midway platform.
This depends on a change to the hostdb to add "
0x01000000" as the value of a new UBootSetXenAddrR property of the midway machines.
Quoted 8 lines
Quoted 2 lines
Most platforms will need something similar. For both cubietruck and arndale
0x41000000.Acked-by Ian Jackson <[email protected]>(I expect you agree with me that the fact we can't get this information some other way is a defect elsewhere, but this is a fine workaround.)
Yeah, all the other similar envvars are part of the board configuration in the u-boot source. We could start trying to upstream a patch for each platform to define an address for Xen, but I don't know how well it would go down, or we could try and (ab)use e.g. $script_addr.
For now I prefer to just add it to the hostdb and the relevant wiki page for the platform.
Ian.
PATCH v4 8/13 Osstest/Debian: Add "clk_ignore_unused" to default command line
In reply to Ian Campbelldom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so this stops the kernel from messing with (specifically, disabling) those clocks. It's harmless even when not needed.
Really there ought to be some interface to communicate this from Xen to dom0, or some other mechanism to gate things. See
http://bugs.xenproject.org/xen/bug/45
---
v3: More verbiage about why this is done
v2: New patch, previously incorrectly included in "Osstest/Debian:
Workaround oddities in the u-boot script parser."
--- Osstest/Debian.pm | 1 + 1 file changed, 1 insertion(+)
Osstest/Debian.pm +1 -0
@@ -141,6 +141,7 @@ sub setupboot_uboot ($$$) { push @xenkopt, $xenkopt; push @xenkopt, "ro"; push @xenkopt, "root=$root"; + push @xenkopt, "clk_ignore_unused"; # http://bugs.xenproject.org/xen/bug/45 push @xenkopt, "rootdelay=$rootdelay" if $rootdelay; $xenkopt = join ' ', @xenkopt;
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line
Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
Quoted 7 lines
dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so this stops the kernel from messing with (specifically, disabling) those clocks. It's harmless even when not needed.
Really there ought to be some interface to communicate this from Xen to dom0, or some other mechanism to gate things. See
http://bugs.xenproject.org/xen/bug/45
Ian.
Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line
In reply to Ian CampbellIan Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
Quoted 7 lines
dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so this stops the kernel from messing with (specifically, disabling) those clocks. It's harmless even when not needed.
Really there ought to be some interface to communicate this from Xen to dom0, or some other mechanism to gate things. See
http://bugs.xenproject.org/xen/bug/45
Actually, despite my email just now acking this: perhaps you could gate this on $suite ?
That way at the very least we'll be prompted every couple of years to see if this is still needed.
Ian.
Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line
Quoted 9 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 08/13] Osstest/Debian: Add "
clk_ignore_unused" to default command line"):Quoted 7 lines
dom0 is not aware that some clocks are actually in use (e.g. by the hypervisor), so this stops the kernel from messing with (specifically, disabling) those clocks. It's harmless even when not needed.
Really there ought to be some interface to communicate this from Xen to dom0, or some other mechanism to gate things. See
http://bugs.xenproject.org/xen/bug/45
Quoted 5 lines
Actually, despite my email just now acking this: perhaps you could gate this on $suite ?
That way at the very least we'll be prompted every couple of years to see if this is still needed.
Sure. Since I know already that this won't be fixed in Jessie I propose to insert an "if $ho->{Suite} =~ m/wheezy|jessie/;" right from the get go, as below.
Are you OK with your Ack being retained with that? (I'll mention Jessie in the commit log too).
Ian.
Osstest/Debian.pm +3 -1
@@ -159,7 +159,9 @@ sub setupboot_uboot ($$$) { # Dom0 specific kernel options my @xenkopt = @kopt; push @xenkopt, $xenkopt; - push @xenkopt, "clk_ignore_unused"; # http://bugs.xenproject.org/xen/bug/45 + # http://bugs.xenproject.org/xen/bug/45 + push @xenkopt, "clk_ignore_unused" + if $ho->{Suite} =~ m/wheezy|jessie/; $xenkopt = join ' ', @xenkopt; logm("Dom0 Linux options: $xenkopt");
Ian Jackson
Acked-byRe: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line
Ian Campbell writes ("Re: [PATCH OSSTEST v4 08/13] Osstest/Debian: Add "clk_ignore_unused" to default command line"):
Quoted 7 lines · Ian Jackson
Quoted 2 lines
That way at the very least we'll be prompted every couple of years to see if this is still needed.
Sure. Since I know already that this won't be fixed in Jessie I propose to insert an "if $ho->{Suite} =~ m/wheezy|jessie/;" right from the get go, as below.
Right.
Quoted 2 lines
Are you OK with your Ack being retained with that? (I'll mention Jessie in the commit log too).
Thanks,
Ian.
PATCH v4 9/13 Osstest/Debian: Add 0x prefix to $filesize
In reply to Ian Campbell$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly. See
http://lists.denx.de/pipermail/u-boot/2014-October/193622.html
---
v3: Reference ML thread.
v2: New patch, previously included in "Osstest/Debian: Workaround
oddities in the u-boot script parser.". Note that the oddities with requiring a space before the ">" is no longer reproducible with the latest u-boot.
--- Osstest/Debian.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Osstest/Debian.pm +2 -2
@@ -187,7 +187,7 @@ echo command line: \\\${bootargs} ext2load scsi 0 \\\${kernel_addr_r} $kern fdt mknod /chosen module\@0 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module" -fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}> +fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}> fdt set /chosen/module\@0 bootargs "$xenkopt" echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize}) echo command line: $xenkopt
@@ -195,7 +195,7 @@ echo command line: $xenkopt ext2load scsi 0 \\\${ramdisk_addr_r} $initrd fdt mknod /chosen module\@1 fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module" -fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}> +fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}> echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize}) fdt print /chosen
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize
Ian Campbell writes ("[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):
Quoted 3 lines
$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly. See
http://lists.denx.de/pipermail/u-boot/2014-October/193622.html
It seems that u-boot think there is a bug here and perhaps even intend to fix it. So this workaround could be gated on $suite ? (Or on the u-boot version somehow if we are making our own - I forget.)
Ian.
Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize
Quoted 7 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):
Quoted 3 lines
$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly. See
http://lists.denx.de/pipermail/u-boot/2014-October/193622.htmlIt seems that u-boot think there is a bug here and perhaps even intend to fix it. So this workaround could be gated on $suite ?
The conversation continued into November, which the archives helpfully don't reflect:
http://lists.denx.de/pipermail/u-boot/2014-November/194070.html (I'll add that one to the commit log too). The end result is "documentation bug" http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.
Quoted 1 line
(Or on the u-boot version somehow if we are making our own - I forget.)
I am providing the u-boot, but it is outside of osstest (via [1]) and TBH once deployed (esp. remotely) I don't expect to want to change it.
Ian.
[1]
http://xenbits.xen.org/gitweb/?p=people/ianc/osstest/boards.git;a=summary
Ian Jackson
Acked-byRe: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize
Ian Campbell writes ("Re: [PATCH OSSTEST v4 09/13] Osstest/Debian: Add 0x prefix to $filesize"):
Quoted 6 lines · Ian Jackson
The conversation continued into November, which the archives helpfully don't reflect:
http://lists.denx.de/pipermail/u-boot/2014-November/194070.html (I'll add that one to the commit log too). The end result is "documentation bug" http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.
Bah. OK then.
Ian.
PATCH v4 10/13 ts-kernel-build: Adjust kernel .config to work on the arndale boards.
In reply to Ian CampbellVarious drivers are missing from multi_v7_defconfig in v3.16, also some drivers which don't play nice are enabled by default, so remove them.
---
v3: This is a more extensive version of "ts-kernel-build: Enable
CONFIG_PHY_EXYNOS5250_SATA". Ian acked that but this does a lot more so I've dropped it.
--- ts-kernel-build | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
ts-kernel-build +35 -0
@@ -171,6 +171,41 @@ setopt CONFIG_BLK_DEV_NBD y # At least with Linux 3.4.77 on wheezy, the nbd module is # not loaded automatically. +# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't +# support that platform anyway. +setopt CONFIG_ARCH_EXYNOS4 n + +# Having these on breaks USB +setopt CONFIG_SAMSUNG_USB2PHY n +setopt CONFIG_SAMSUNG_USB3PHY n + +# These cause i2c bus timeout errors on boot. +# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU? +# http://patchwork.ozlabs.org/patch/337812/ +setopt CONFIG_SENSORS_LM90 n +setopt CONFIG_ICS932S401 n + +# Enable some additional drivers for Arndale. +setopt CONFIG_PHY_EXYNOS5250_SATA m +setopt CONFIG_USB_EHCI_EXYNOS m +setopt CONFIG_USB_OHCI_EXYNOS m +setopt CONFIG_USB_HSIC_USB3503 m +setopt CONFIG_USB_DWC3 m +setopt CONFIG_USB_DWC3_HOST y +setopt CONFIG_USB_DWC3_EXYNOS m +setopt CONFIG_USB_DWC3_PCI n +setopt CONFIG_PHY_SAMSUNG_USB2 m +setopt CONFIG_PHY_EXYNOS5250_USB2 y +setopt CONFIG_PHY_EXYNOS5_USBDRD m +setopt CONFIG_RTC_DRV_S5M y +setopt CONFIG_COMMON_CLK_S2MPS11 m +setopt CONFIG_I2C_S3C2410 y +setopt CONFIG_MMC_DW m +setopt CONFIG_MMC_DW_EXYNOS m +setopt CONFIG_REGULATOR_S5M8767 m + +#### + END our $config_features= <<END;
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 3 lines
Various drivers are missing from
multi_v7_defconfigin v3.16, also some drivers which don't play nice are enabled by default, so remove them.
...
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186
Quoted 13 lines
ts-kernel-build +13
-0+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't +# support that platform anyway. +setopt CONFIG_ARCH_EXYNOS4 n + +# Having these on breaks USB +setopt CONFIG_SAMSUNG_USB2PHY n +setopt CONFIG_SAMSUNG_USB3PHY n + +# These cause i2c bus timeout errors on boot. +# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU? +# http://patchwork.ozlabs.org/patch/337812/ +setopt CONFIG_SENSORS_LM90 n +setopt CONFIG_ICS932S401 n
I think these should be gated on the kernel version and/or arch or something. After all, disabling modules is a workaround (and risks making things not work in the future in an annoyingly mysterious way).
Quoted 8 lines
ts-kernel-build +8
-0+# Enable some additional drivers for Arndale. +setopt CONFIG_PHY_EXYNOS5250_SATA m +setopt CONFIG_USB_EHCI_EXYNOS m +setopt CONFIG_USB_OHCI_EXYNOS m +setopt CONFIG_USB_HSIC_USB3503 m +setopt CONFIG_USB_DWC3 m +setopt CONFIG_USB_DWC3_HOST y +setopt CONFIG_USB_DWC3_EXYNOS m
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 205
Quoted 10 lines
ts-kernel-build +10
-0+setopt CONFIG_USB_DWC3_PCI n +setopt CONFIG_PHY_SAMSUNG_USB2 m +setopt CONFIG_PHY_EXYNOS5250_USB2 y +setopt CONFIG_PHY_EXYNOS5_USBDRD m +setopt CONFIG_RTC_DRV_S5M y +setopt CONFIG_COMMON_CLK_S2MPS11 m +setopt CONFIG_I2C_S3C2410 y +setopt CONFIG_MMC_DW m +setopt CONFIG_MMC_DW_EXYNOS m +setopt CONFIG_REGULATOR_S5M8767 m
This part is all fine.
Thanks,
Ian.
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Quoted 14 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 3 lines
Various drivers are missing from
multi_v7_defconfigin v3.16, also some drivers which don't play nice are enabled by default, so remove them....
Quoted 9 lines
ts-kernel-build +9
-0+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't +# support that platform anyway. +setopt CONFIG_ARCH_EXYNOS4 n + +# Having these on breaks USB +setopt CONFIG_SAMSUNG_USB2PHY n +setopt CONFIG_SAMSUNG_USB3PHY n + +# These cause i2c bus timeout errors on boot.
Quoted 8 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186
Quoted 4 lines
ts-kernel-build +4
-0+# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU? +# http://patchwork.ozlabs.org/patch/337812/ +setopt CONFIG_SENSORS_LM90 n +setopt CONFIG_ICS932S401 nI think these should be gated on the kernel version and/or arch or something. After all, disabling modules is a workaround (and risks making things not work in the future in an annoyingly mysterious way).
Arch I can easily do.
Not sure how easy it will be to get the kern ver, currently we get it from the name of the subdir created in /lib/modules by the kernel install, which is too late of course.
Not sure if there is some other surrogate we could use.
FWIW LM90 is some i2c temperature sensor thing which I doubt we are exercising (i.e. we aren't installed lmsensors packages) and ICS932S401 is some equally uninteresting i2c sensor device. I think it's pretty unlikely we would suddenly trip over an x86 system with these and for ARM each new platform is likely to need some dev work to add etc anyway. In neither case do I think we would miss these devices in practice.
Ian.
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Quoted 24 lines · Ian Campbell
Quoted 14 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 3 lines
Various drivers are missing from
multi_v7_defconfigin v3.16, also some drivers which don't play nice are enabled by default, so remove them....
Quoted 9 lines
ts-kernel-build +9
-0+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't +# support that platform anyway. +setopt CONFIG_ARCH_EXYNOS4 n + +# Having these on breaks USB +setopt CONFIG_SAMSUNG_USB2PHY n +setopt CONFIG_SAMSUNG_USB3PHY n + +# These cause i2c bus timeout errors on boot.Quoted 8 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186
Quoted 4 lines
ts-kernel-build +4
-0+# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU? +# http://patchwork.ozlabs.org/patch/337812/ +setopt CONFIG_SENSORS_LM90 n +setopt CONFIG_ICS932S401 nI think these should be gated on the kernel version and/or arch or something. After all, disabling modules is a workaround (and risks making things not work in the future in an annoyingly mysterious way).
Quoted 3 lines
Arch I can easily do.
Not sure how easy it will be to get the kern ver,
"make kernelversion" will return the version from the Makefile (i.e. not including any localversion stuff). The question then becomes what the white/blacklist should look like.
Should I list all the current linux-* branch versions? How should we handle e.g. linux-next and linux-linus?
Ian.
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
In reply to Ian CampbellIan Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 17 lines · Ian Jackson
Quoted 6 lines
Ian Campbell writes ("[PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 3 lines
Various drivers are missing from
multi_v7_defconfigin v3.16, also some drivers which don't play nice are enabled by default, so remove them....
Quoted 9 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 186
Quoted 5 lines
ts-kernel-build +5
-0+# These cause i2c bus timeout errors on boot. +# https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/f1DW9NcSPVU? +# http://patchwork.ozlabs.org/patch/337812/ +setopt CONFIG_SENSORS_LM90 n +setopt CONFIG_ICS932S401 nI think these should be gated on the kernel version and/or arch or something. After all, disabling modules is a workaround (and risks making things not work in the future in an annoyingly mysterious way).
Quoted 5 lines
Arch I can easily do.
Not sure how easy it will be to get the kern ver, currently we get it from the name of the subdir created in
/lib/modulesby the kernel install, which is too late of course.
Hmm.
Quoted 8 lines
Not sure if there is some other surrogate we could use.
FWIW LM90 is some i2c temperature sensor thing which I doubt we are exercising (i.e. we aren't installed lmsensors packages) and ICS932S401 is some equally uninteresting i2c sensor device. I think it's pretty unlikely we would suddenly trip over an x86 system with these and for ARM each new platform is likely to need some dev work to add etc anyway. In neither case do I think we would miss these devices in practice.
That answers my concerns for the ones above. But:
Quoted 3 lines
Quoted 3 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 176
Quoted 3 lines
ts-kernel-build +3
-0+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't +# support that platform anyway. +setopt CONFIG_ARCH_EXYNOS4 n
This is a particular kind of board ? In which case, fine.
Quoted 3 lines
Quoted 3 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 180
Quoted 3 lines
ts-kernel-build +3
-0+# Having these on breaks USB +setopt CONFIG_SAMSUNG_USB2PHY n +setopt CONFIG_SAMSUNG_USB3PHY n
I don't know what this is. Convince me it's harmless to disable ? :-)
Ian.
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Quoted 5 lines · Ian Jackson
Quoted 3 lines
Quoted 3 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 176
Quoted 3 lines
ts-kernel-build +3
-0+# Enabling Exynos4 forces wierd CONFIG_HZ==200, and we don't +# support that platform anyway. +setopt CONFIG_ARCH_EXYNOS4 nThis is a particular kind of board ? In which case, fine.
It's a class of SoC (i.e. SoC models 4xxx), however virtualisation support was only added to EXYNOS 5xxx onwards, so I don't think we will ever care about EXYNOS4 in osstest.
However:
https://www.mail-archive.com/[email protected]/msg41070.html
might cause this to change at some point.
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
ts-kernel-build setopt CONFIG_BLK_DEV_NBD y · line 180
Quoted 3 lines
ts-kernel-build +3
-0+# Having these on breaks USB +setopt CONFIG_SAMSUNG_USB2PHY n +setopt CONFIG_SAMSUNG_USB3PHY nI don't know what this is. Convince me it's harmless to disable ? :-)
They are phy drivers for the USB on some samsung SoC or other, I'm not sure which. I do know that they aren't needed for any of the peripherals on the Arndale which we need, like the USB Ethernet.
Exynos' support for multiplatform kernels (i.e. ones which run on several SoCs instead of being compiled for a single system) is pretty immature at the moment, since it is pretty new. I'd expect that eventually some of these quirks will go away, but at that point we still won't care about these options, I think.
Ian.
Ian Jackson
Acked-byRe: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 4 lines · Ian Jackson
Quoted 1 line
I don't know what this is. Convince me it's harmless to disable ? :-)
[stuff]
OK, thanks.
Ian.
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Quoted 9 lines · Ian Jackson
Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 4 lines · Ian Jackson
Quoted 1 line
I don't know what this is. Convince me it's harmless to disable ? :-)
[stuff]
OK, thanks.
Acked-by Ian Jackson <[email protected]>
Thanks.
I think that means everything is now acked. I'll repost one final time (likely tomorrow), since I've changed a few things (as discussed), then we can talk about commissioning etc.
Cheers,
Ian.
Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards.
Ian Campbell writes ("Re: [PATCH OSSTEST v4 10/13] ts-kernel-build: Adjust kernel .config to work on the arndale boards."):
Quoted 5 lines
Thanks.
I think that means everything is now acked. I'll repost one final time (likely tomorrow), since I've changed a few things (as discussed), then we can talk about commissioning etc.
Right.
Ian.
PATCH v4 11/13 Debian: Create boot.scr with a suffix and copy to boot.scr
In reply to Ian CampbellThis ensures that we always have a boot script to boot at least the native Debian kernel and Xen available, even after multiple iterations of installation, which is handy when debugging a system.
--- Osstest/Debian.pm | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
Osstest/Debian.pm +8 -6
@@ -162,12 +162,12 @@ if test ! -f /boot/$kern ; then exit 1 fi # Save a copy of the original -cp -n /boot/boot /boot/boot.bak -cp -n /boot/boot.scr /boot/boot.scr.bak +cp -n /boot/boot.xen /boot/boot.xen.bak +cp -n /boot/boot.scr.xen /boot/boot.scr.xen.bak xen=`readlink /boot/$xen` -cat >/boot/boot <<EOF +cat >/boot/boot.xen <<EOF ${load_dtb} fdt addr \\\${fdt_addr}
@@ -203,7 +203,8 @@ fdt print /chosen echo Booting \\\${xen_addr_r} - \\\${fdt_addr} bootz \\\${xen_addr_r} - \\\${fdt_addr} EOF -mkimage -A arm -T script -d /boot/boot /boot/boot.scr +mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen +cp /boot/boot.scr.xen /boot/boot.scr END };
@@ -725,7 +726,7 @@ r=/target #/ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'` initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'` -cat >\$r/boot/boot <<EOF +cat >\$r/boot/boot.deb <<EOF setenv bootargs $bootargs ${load_dtb} echo Loading \$kernel
@@ -736,7 +737,8 @@ echo Booting bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr} EOF -in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr +in-target mkimage -A arm -T script -d /boot/boot.deb /boot/boot.scr.deb +in-target cp /boot/boot.scr.deb /boot/boot.scr END }
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr
Ian Campbell writes ("[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr"):
Quoted 3 lines
This ensures that we always have a boot script to boot at least the native Debian kernel and Xen available, even after multiple iterations of installation, which is handy when debugging a system.
I confess I don't quite see how this works, due to my lack of understanding of u-boot et al's plumbing, but I see nothing to object to.
Ian.
Re: [PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr
Quoted 8 lines · Ian Jackson
Ian Campbell writes ("[PATCH OSSTEST v4 11/13] Debian: Create boot.scr with a suffix and copy to boot.scr"):
Quoted 3 lines
This ensures that we always have a boot script to boot at least the native Debian kernel and Xen available, even after multiple iterations of installation, which is handy when debugging a system.
I confess I don't quite see how this works, due to my lack of understanding of u-boot et al's plumbing, but I see nothing to object to.
u-boot essential does "load $script_addr $boot_script ; source $script_addr", all this does is mean one can conveniently do "setenv boot_script boot.scr.$foo; boot" (for foo in deb, nat, xen) to override the default of boot.scr if you've borked it somehow.
Quoted 1 line
Acked-by Ian Jackson <[email protected]>
Thanks.
Ian.
PATCH v4 12/13 TestSupport: replace power_cycle_timeout with power_cycle_sleep
In reply to Ian CampbellWhich does the actual sleep and logs that it is doing so.
Otherwise on a machine which has a longish PowerCycleTime I keep wondering why osstest has hung...
--- Osstest/TestSupport.pm | 10 ++++++---- ts-host-install | 2 +- 2 files changed, 7 insertions(+), 5 deletions(-)
Osstest/TestSupport.pm +6 -4
@@ -66,7 +66,7 @@ BEGIN { selecthost get_hostflags get_host_property get_host_native_linux_console - power_state power_cycle power_cycle_time + power_state power_cycle power_cycle_sleep serial_fetch_logs propname_massage
@@ -712,9 +712,11 @@ sub power_cycle_host_setup ($) { $ho->{PowerMethobjs} = $methobjs; } -sub power_cycle_time ($) { +sub power_cycle_sleep ($) { my ($ho) = @_; - return get_host_property($ho, 'power-cycle-time', 5); + my $to = get_host_property($ho, 'power-cycle-time', 5); + logm("power-cycle: waiting ${to}s"); + sleep($to); } sub power_cycle ($) {
@@ -724,7 +726,7 @@ sub power_cycle ($) { " possibly shared with other jobs\n" if $ho->{SharedMaybeOthers}; power_state($ho, 0); - sleep(power_cycle_time($ho)); + power_cycle_sleep($ho); power_state($ho, 1); }
ts-host-install +1 -1
@@ -63,7 +63,7 @@ d-i netcfg/get_ipaddress string $ho->{Ip} END setup_pxeboot_firstboot($ps_url); - sleep(power_cycle_time($ho)); + power_cycle_sleep($ho); my $logtailer= Osstest::Logtailer->new($c{WebspaceLog}); power_state($ho, 1);
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 12/13] TestSupport: replace power_cycle_timeout with power_cycle_sleep
Ian Campbell writes ("[PATCH OSSTEST v4 12/13] TestSupport: replace power_cycle_timeout with power_cycle_sleep"):
Quoted 4 lines
Which does the actual sleep and logs that it is doing so.
Otherwise on a machine which has a longish PowerCycleTime I keep wondering why osstest has hung...
PATCH v4 13/13 Debian: create boot.scr.nat when installing Xen on u-boot.
In reply to Ian CampbellThis boots the kernel we've build natively, where boot.xen boots Xen and boot.deb boots the original Debian kernel.
Sometimes convenient when debugging issues.
---
v4: New patch
--- Osstest/Debian.pm | 40 ++++++++++++++++++++++++++++++++++------ 1 file changed, 34 insertions(+), 6 deletions(-)
Osstest/Debian.pm +34 -6
@@ -136,18 +136,32 @@ sub setupboot_uboot ($$$) { my $root= target_guest_lv_name($ho,"root"); my $rootdelay=get_host_property($ho, "rootdelay"); + my $natcons=get_host_native_linux_console($ho); - my @xenkopt; + logm("Xen options: $xenhopt"); + + # Common kernel options + my @kopt; + + push @kopt, "ro"; + push @kopt, "root=$root"; + push @kopt, "rootdelay=$rootdelay" if $rootdelay; + + # Dom0 specific kernel options + my @xenkopt = @kopt; push @xenkopt, $xenkopt; - push @xenkopt, "ro"; - push @xenkopt, "root=$root"; push @xenkopt, "clk_ignore_unused"; # http://bugs.xenproject.org/xen/bug/45 - push @xenkopt, "rootdelay=$rootdelay" if $rootdelay; $xenkopt = join ' ', @xenkopt; + logm("Dom0 Linux options: $xenkopt"); - logm("Xen options: $xenhopt"); - logm("Linux options: $xenkopt"); + # Native specific kernel options + + my @natkopt = @kopt; + push @natkopt, "console=$natcons" unless $natcons eq "NONE"; + + my $natkopt = join ' ', @natkopt; + logm("Native linux options: $natkopt"); my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', ''); my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef);
@@ -205,6 +219,20 @@ bootz \\\${xen_addr_r} - \\\${fdt_addr} EOF mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen cp /boot/boot.scr.xen /boot/boot.scr + +# Create boot.scr.nat for convenience too +cat >/boot/boot.nat <<EOF +setenv bootargs $natkopt +${load_dtb} +echo Loading $kern +ext2load scsi 0 \\\${kernel_addr_r} $kern +echo Loading $initrd +ext2load scsi 0 \\\${ramdisk_addr_r} $initrd +echo Booting +bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr} +EOF +mkimage -A arm -T script -d /boot/boot.nat /boot/boot.scr.nat + END };
Signature · 1 line
2.1.4
Re: [PATCH OSSTEST v4 13/13] Debian: create boot.scr.nat when installing Xen on u-boot.
Ian Campbell writes ("[PATCH OSSTEST v4 13/13] Debian: create boot.scr.nat when installing Xen on u-boot."):
Quoted 17 lines
This boots the kernel we've build natively, where boot.xen boots Xen and boot.deb boots the original Debian kernel.
Sometimes convenient when debugging issues.
Signed-off-by Ian Campbell <[email protected]>---
v4: New patch--- Osstest/Debian.pm | 40 ++++++++++++++++++++++++++++++++++------ 1 file changed, 34 insertions(+), 6 deletions(-)Osstest/Debian.pm +0
-0
Osstest/Debian.pm sub setupboot_uboot ($$$) { · line 139
Quoted 4 lines
Osstest/Debian.pm +1
-0@@ -136,18 +136,32 @@ sub setupboot_uboot ($$$) { my $root= target_guest_lv_name($ho,"root"); my $rootdelay=get_host_property($ho, "rootdelay"); + my $natcons=get_host_native_linux_console($ho);
The coding style here (missing spaces to rhs of =) is getting worse. The existing code is inconsistent between = ' and = ' but I think adding `=' too is not helping...
Osstest/Debian.pm sub setupboot_uboot ($$$) { · line 161
Quoted 4 lines
Osstest/Debian.pm +4
-0+ # Native specific kernel options + + my @natkopt = @kopt; + push @natkopt, "console=$natcons" unless $natcons eq "NONE";
Ah I think this answers my question about native console, from earlier.
Ian.
On Wed, 2015-01-21 at 11:17 +0000, Ian Campbell wrote:
I initially forgot to set the new UBootSetXenAddrR property on the existing midway systems, as required by 653d0af2fd70 "Osstest/Debian:
Remove hardcoded addresses from boot.scr", so the initial flight failed.
The flight which is currently in progress (33888) has failed ts-host-reboot on arm with (from the serial log):
12349569 bytes read in 401 ms (29.4 MiB/s)
Sorry, I could not convert "xbc7081>"
Loaded initrd.img-3.16.7-ckt4+ to 0x04000000 (0xbc7081)The ts-xen-install log shows that the relevant fragment of boot.scr is:
ext2load scsi 0 \${ramdisk_addr_r} initrd.img-3.16.7-ckt4+
fdt mknod /chosen module@1
fdt set /chosen/module@1 compatible "xen,linux-initrd" "xen,multiboot-module"
fdt set /chosen/module@1 reg <\${ramdisk_addr_r} 0x\${filesize}>
echo Loaded initrd.img-3.16.7-ckt4+ to \${ramdisk_addr_r} (\${filesize})I think this is a combination of ee5e442f15eb "Osstest/Debian: Add 0x prefix to $filesize" from this series and a much older change in e6e9078c80d6 "Debian: more corrections to arm u-boot rune" which removed a space from before the ">", probably because I couldn't remember what it was for...
It turns out that the ext2load command on midway only sets filesize with the 0x prefix, but e.g. tftp doesn't. This doesn't occur on arndale or cubietruck which has much newer u-boot which has this bug fixed (not sure by what but [0] look like candidates).
Based on the email threads referenced by ee5e442f15e[1] I think we should consider this a quirk/bug on the midway platform.
In theory I could try upgrading the u-boot firmware on these systems (it's still supported by mainline u-boot), but to be honest with Calxeda no longer existing I'm reluctant to do anything which might have any chance of bricking the systems.
I'm not sure how specific to make this quirk and whether it is worth doing via the hostdb or just directly in Debian.pm. Options:
* Make the addition of the 0x prefix conditional on ! platform-midway
* Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to 0x and set to '' on midway machines
* A similar host flag to control the addition (or, more likely, the omission of) of the 0x
Ian.
[0] http://git.denx.de/?p=u-boot.git;a=commit;h=b770e88a6c2548727f0d57a3e9e8bb0830f977b5
http://git.denx.de/?p=u-boot.git;a=commit;h=3f83c87ee58d86e9a9d2e50b62f38c728bfb31f6
[1] http://lists.denx.de/pipermail/u-boot/2014-October/193622.html,
http://lists.denx.de/pipermail/u-boot/2014-November/194150.html and http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.
Ian Campbell writes ("Re: [Xen-devel] [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms"):
Quoted 5 lines
I think this is a combination of
ee5e442f15eb"Osstest/Debian: Add 0x prefix to $filesize" from this series and a much older change ine6e9078c80d6"Debian: more corrections to arm u-boot rune" which removed a space from before the ">", probably because I couldn't remember what it was for...
Nnng.
Quoted 4 lines
It turns out that the ext2load command on midway only sets filesize with the 0x prefix, but e.g. tftp doesn't. This doesn't occur on arndale or cubietruck which has much newer u-boot which has this bug fixed (not sure by what but [0] look like candidates).
Oh god oh god the horror.
Quoted 2 lines
Based on the email threads referenced by ee5e442f15e[1] I think we should consider this a quirk/bug on the midway platform.
OK.
Quoted 10 lines
In theory I could try upgrading the u-boot firmware on these systems (it's still supported by mainline u-boot), but to be honest with Calxeda no longer existing I'm reluctant to do anything which might have any chance of bricking the systems.
I'm not sure how specific to make this quirk and whether it is worth doing via the hostdb or just directly in Debian.pm. Options:
* Make the addition of the 0x prefix conditional on ! platform-midway
I think this would be an abuse of platform-*. You've already done this kind of thing once with equiv-marilith in Osstest/CXFabric.pm and I think I should have put my foot down then...
Quoted 2 lines
* A similar host flag to control the addition (or, more likely, the omission of) of the 0x
That would be fine, although AFAICT we don't really have any quirks in the hostflags already. It should probably be quirk-something.
Quoted 2 lines
* Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to 0x and set to '' on midway machines
That would be fine too (although do you expect any values other than '' and 0x?)
Thanks,
Ian.
Quoted 1 line · Ian Jackson
Nnng.
[...]
Quoted 1 line
Oh god oh god the horror.
Quite...
Quoted 8 lines
Quoted 8 lines
In theory I could try upgrading the u-boot firmware on these systems (it's still supported by mainline u-boot), but to be honest with Calxeda no longer existing I'm reluctant to do anything which might have any chance of bricking the systems.
I'm not sure how specific to make this quirk and whether it is worth doing via the hostdb or just directly in Debian.pm. Options:
Quoted 6 lines
Quoted 2 lines
* Make the addition of the 0x prefix conditional on ! platform-midway
I think this would be an abuse of platform-*. You've already done this kind of thing once with equiv-marilith in Osstest/CXFabric.pm and I think I should have put my foot down then...
I thought you'd say that ;-)
Quoted 4 lines
Quoted 3 lines
* A similar host flag to control the addition (or, more likely, the omission of) of the 0x
Quoted 8 lines
That would be fine, although AFAICT we don't really have any quirks in the hostflags already. It should probably be quirk-something.
Quoted 2 lines
* Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to 0x and set to '' on midway machines
That would be fine too (although do you expect any values other than '' and 0x?)
It seems pretty unlikely, at least I can't think of anything plausible. Which suggests a hostflag is the right answer...
I propose to append the following to the pretest branch (rather than trying to fold it into some existing patch, although I can if you want)
Feel free to bikeshed the name, of course ;-)...
8<------
Quoted 1 line
From
caee3d8167b107b02293b1e72dae2d76db08437cMon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Thu, 29 Jan 2015 11:37:39 +0000
Subject: [PATCH] Debian: Handle systems where u-boot includes 0x on $filesize
--- Osstest/Debian.pm | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
Osstest/Debian.pm +18 -2
@@ -180,6 +180,22 @@ sub setupboot_uboot ($$$) { my $set_xen_addr_r = $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : ""; + # According to u-boot policy $filesize is an unprefixed hex + # number, but fdt set requires numbers to be prefixed + # (e.g. with 0x for a hex number). See: + # + # http://lists.denx.de/pipermail/u-boot/2014-October/193622.html, + # http://lists.denx.de/pipermail/u-boot/2014-November/194150.html and + # http://lists.denx.de/pipermail/u-boot/2014-November/194150.html. + # + # However some older u-boot versions (e.g. on midway) erroneously + # include the 0x prefix when setting $filesize from ext*load + # commands, meaning we cannot simply unconditionally prepend + # the 0x. Base it on a host flag quirk. + my $size_hex_prefix = + $ho->{Flags}{'quirk-load-filesize-has-0x-prefix'} ? + '' : '0x'; + target_cmd_root($ho, <<END); if test ! -f /boot/$kern ; then exit 1
@@ -210,7 +226,7 @@ echo command line: \\\${bootargs} ext2load scsi 0 \\\${kernel_addr_r} $kern fdt mknod /chosen module\@0 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module" -fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}> +fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} ${size_hex_prefix}\\\${filesize}> fdt set /chosen/module\@0 bootargs "$xenkopt" echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize}) echo command line: $xenkopt
@@ -218,7 +234,7 @@ echo command line: $xenkopt ext2load scsi 0 \\\${ramdisk_addr_r} $initrd fdt mknod /chosen module\@1 fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module" -fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}> +fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} ${size_hex_prefix}\\\${filesize}> echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize}) fdt print /chosen
Signature · 1 line
2.1.4
Quoted 8 lines · Ian Campbell
8<------
From
caee3d8167b107b02293b1e72dae2d76db08437cMon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Thu, 29 Jan 2015 11:37:39 +0000
Subject: [PATCH] Debian: Handle systems where u-boot includes 0x on $filesizeSigned-off-by Ian Campbell <[email protected]>
Acked on IRC + pushed to pretest + "./mg-hosts setflags marilith-n\* -- quirk-load-filesize-has-0x-prefix" + killed in-progress flight 33888.
Ian.