support for ARM32 arndale and cubietruck platforms
v5 cover support for ARM32 arndale and cubietruck platforms
I'm preparing a bunch of each of these boards to be racked for inclusion in osstest. This series adds the necessary osstest support:
* Support for platforms which require us to supply a Device Tree
* Removing various hardcoded midway assumptions
* Some new features needed to workaround h/w quirks (of arndale in particular)
* Support for the power relay switch board which these are attached to
* Some new convenience features
The series is completely acked now, reposting just because some of the acks were given preemptively to give a chance for objections etc.
I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)
Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.
I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).
So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.
Stefano, do you have another preference?
WRT deploying we need to figure out the sequence in which we push these patches, reenable the linux-arm-xen branch and commissioning the new boards.
Ian.
PlatformsArmhf midway cubietruck arndale
HostProp_arndale-metrocentre_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 1 HostProp_arndale-westfield_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 2 HostProp_arndale-lakeside_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 3 HostProp_arndale-bluewater_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 4
HostProp_cubietruck-braque_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 5 HostProp_cubietruck-picaso_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 6 HostProp_cubietruck-metzinger_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 7 HostProp_cubietruck-gleizes_PowerMethod eth008 arm-pdu-01.cam.xci-test.com admin password 8
HostGroupProp_arndale_LinuxSerialConsole ttySAC2 HostGroupProp_arndale_Build_Make_Flags -j4 HostGroupProp_arndale_XenSerialConsole dtuart HostGroupProp_arndale_XenDTUARTPath /serial@12C20000 HostGroupProp_arndale_Interface_Force eth0 HostGroupProp_arndale_ExtraInitramfsModules clk-s2mps11 s5m8767 i2c-s3c2410 phy-exynos5250-sata HostGroupProp_arndale_Rootdelay 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 v5 1/14 make-flight: Run a basic test on each arm platform
Unlike x86 there is enough variation in the ARM platforms that it is worth having a basic test on each as part of a standard run. This relies on each host having an appropriate platform-$platform host flag.
The existing test-ARCH-ARCH-xl test is retained as a floating test, while a new variant is added for each distinct platform present in the hostdb which is tied to that platform type. The intention is that only arm platforms will have platforms at first, although perhaps platform-intel and platform-amd could be added in the future too.
There are currently no platform-* flags in the hostdb, so tested with s/platform-/equiv-/ and:
( set -ex ;
source ./cri-getplatforms ;
blessing=real ;
export OSSTEST_CONFIG=production-config ;
for p in '' `getplatforms "armhf"` ; do
set +x ;
echo PLATFORM: $p ;
done )
which prints:
PLATFORM:
PLATFORM: marilith
and with s/armhf/amd64/:
PLATFORM:
PLATFORM: rackservers-s40670
PLATFORM: r310-moth
PLATFORM: rackservers-s40680
PLATFORM: dell-r310
PLATFORM: rackservers-s40679
PLATFORM: rackservers-s40663
PLATFORM: rackservers-q21011
Also tested in standalone mode with a ~/.xen-osstest/config containing:
PlatformsArmhf midway cubietruck arndale
---
v3:
Split /\s+/
v2:
Use platform-* prop not equiv-*
Select platforms from host db
---
Osstest/HostDB/Executive.pm | 28 ++++++++++++++++++++++++++++
Osstest/HostDB/Static.pm | 9 +++++++++
README | 3 +++
cri-getplatforms | 25 +++++++++++++++++++++++++
make-flight | 9 +++++++--
5 files changed, 72 insertions(+), 2 deletions(-)
create mode 100755 cri-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 v5 2/14 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
PATCH v5 3/14 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
PATCH v5 4/14 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 v5 5/14 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
PATCH v5 6/14 Osstest/Debian.pm: Refactor common kernel cmdline setup.
In reply to Ian Campbell---
v5: New patch, based on review of Osstest/Debian: support adding a
rootdelay property to bootargs
--- Osstest/Debian.pm | 23 +++++++++++++++-------- 1 file changed, 15 insertions(+), 8 deletions(-)
Osstest/Debian.pm +15 -8
@@ -114,6 +114,19 @@ sub bl_getmenu_open ($$$) { return $f; } +sub uboot_common_kernel_bootargs ($) +{ + my ($ho) = @_; + + my $root= target_guest_lv_name($ho,"root"); + + my @bootargs; + push @bootargs, "ro"; + push @bootargs, "root=$root"; + + return @bootargs; +} + sub uboot_scr_load_dtb () { return <<'END'; if test -z "\${fdt_addr}" && test -n "\${fdtfile}" ; then
@@ -134,12 +147,8 @@ sub setupboot_uboot ($$$) { my $kern = "vmlinuz-$want_kernver"; my $initrd = "initrd.img-$want_kernver"; - my $root= target_guest_lv_name($ho,"root"); - - my @xenkopt; + my @xenkopt = uboot_common_kernel_bootargs($ho); push @xenkopt, $xenkopt; - push @xenkopt, "ro"; - push @xenkopt, "root=$root"; $xenkopt = join ' ', @xenkopt;
@@ -698,12 +707,10 @@ END } if ( $ho->{Flags}{'need-uboot-bootscr'} ) { - my @bootargs; + my @bootargs = uboot_common_kernel_bootargs($ho); - my $root=target_guest_lv_name($ho,"root"); my $console=get_host_native_linux_console($ho); - push @bootargs, "root=$root"; push @bootargs, "console=$console" unless $console eq "NONE"; my $bootargs = join ' ', @bootargs;
Signature · 1 line
2.1.4
PATCH v5 7/14 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.
---
v5: Rebased over refactoring.
v3: Honour rootdelay when booting dom 0.
--- Osstest/Debian.pm | 2 ++ 1 file changed, 2 insertions(+)
Osstest/Debian.pm +2 -0
@@ -119,10 +119,12 @@ sub uboot_common_kernel_bootargs ($) my ($ho) = @_; my $root= target_guest_lv_name($ho,"root"); + my $rootdelay= get_host_property($ho, "rootdelay"); my @bootargs; push @bootargs, "ro"; push @bootargs, "root=$root"; + push @bootargs, "rootdelay=$rootdelay" if $rootdelay; return @bootargs; }
Signature · 1 line
2.1.4
PATCH v5 8/14 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
@@ -158,9 +158,13 @@ sub setupboot_uboot ($$$) { logm("Linux options: $xenkopt"); my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', ''); + my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef); my $load_dtb = uboot_scr_load_dtb(); + my $set_xen_addr_r = + $xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : ""; + target_cmd_root($ho, <<END); if test ! -f /boot/$kern ; then exit 1
@@ -178,14 +182,11 @@ fdt addr \\\${fdt_addr} fdt resize ${early_commands} +${set_xen_addr_r} fdt set /chosen \\\#address-cells <1> fdt set /chosen \\\#size-cells <1> -setenv xen_addr_r 0x01000000 -# kernel_addr_r=0x02000000 -# ramdisk_addr_r=0x04000000 - ext2load scsi 0 \\\${xen_addr_r} \$xen setenv bootargs "$xenhopt" echo Loaded \$xen to \\\${xen_addr_r} (\\\${filesize})
Signature · 1 line
2.1.4
PATCH v5 9/14 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
This bug is present in at least Wheezy and Jessie so apply this workaround to those.
---
v5: Conditional on wheezy|jessie
v3: More verbiage about why this is done
v2: New patch, previously incorrectly included in "Osstest/Debian:
Workaround oddities in the u-boot script parser."
--- Osstest/Debian.pm | 3 +++ 1 file changed, 3 insertions(+)
Osstest/Debian.pm +3 -0
@@ -151,6 +151,9 @@ sub setupboot_uboot ($$$) { my @xenkopt = uboot_common_kernel_bootargs($ho); push @xenkopt, $xenkopt; + # http://bugs.xenproject.org/xen/bug/45 + push @xenkopt, "clk_ignore_unused" + if $ho->{Suite} =~ m/wheezy|jessie/; $xenkopt = join ' ', @xenkopt;
Signature · 1 line
2.1.4
PATCH v5 10/14 Osstest/Debian: Add 0x prefix to $filesize
In reply to Ian Campbell$filesize is an unprefixed hex number, but fdt set requires the 0x to interpret it properly. See
http://lists.denx.de/pipermail/u-boot/2014-October/193622.html,
http://lists.denx.de/pipermail/u-boot/2014-November/194150.html and
http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.
---
v3: Reference ML thread.
v2: New patch, previously included in "Osstest/Debian: Workaround
oddities in the u-boot script parser.". Note that the oddities with requiring a space before the ">" is no longer reproducible with the latest u-boot.
--- Osstest/Debian.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Osstest/Debian.pm +2 -2
@@ -198,7 +198,7 @@ echo command line: \\\${bootargs} ext2load scsi 0 \\\${kernel_addr_r} $kern fdt mknod /chosen module\@0 fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module" -fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} \\\${filesize}> +fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}> fdt set /chosen/module\@0 bootargs "$xenkopt" echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize}) echo command line: $xenkopt
@@ -206,7 +206,7 @@ echo command line: $xenkopt ext2load scsi 0 \\\${ramdisk_addr_r} $initrd fdt mknod /chosen module\@1 fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module" -fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} \\\${filesize}> +fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}> echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize}) fdt print /chosen
Signature · 1 line
2.1.4
PATCH v5 11/14 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
PATCH v5 12/14 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
@@ -173,12 +173,12 @@ if test ! -f /boot/$kern ; then exit 1 fi # Save a copy of the original -cp -n /boot/boot /boot/boot.bak -cp -n /boot/boot.scr /boot/boot.scr.bak +cp -n /boot/boot.xen /boot/boot.xen.bak +cp -n /boot/boot.scr.xen /boot/boot.scr.xen.bak xen=`readlink /boot/$xen` -cat >/boot/boot <<EOF +cat >/boot/boot.xen <<EOF ${load_dtb} fdt addr \\\${fdt_addr}
@@ -214,7 +214,8 @@ fdt print /chosen echo Booting \\\${xen_addr_r} - \\\${fdt_addr} bootz \\\${xen_addr_r} - \\\${fdt_addr} EOF -mkimage -A arm -T script -d /boot/boot /boot/boot.scr +mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen +cp /boot/boot.scr.xen /boot/boot.scr END };
@@ -732,7 +733,7 @@ r=/target #/ kernel=`readlink \$r/vmlinuz | sed -e 's|boot/||'` initrd=`readlink \$r/initrd.img | sed -e 's|boot/||'` -cat >\$r/boot/boot <<EOF +cat >\$r/boot/boot.deb <<EOF setenv bootargs $bootargs ${load_dtb} echo Loading \$kernel
@@ -743,7 +744,8 @@ echo Booting bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr} EOF -in-target mkimage -A arm -T script -d /boot/boot /boot/boot.scr +in-target mkimage -A arm -T script -d /boot/boot.deb /boot/boot.scr.deb +in-target cp /boot/boot.scr.deb /boot/boot.scr END }
Signature · 1 line
2.1.4
PATCH v5 13/14 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
PATCH v5 14/14 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.
---
v5: Rebased over Linux cmdline refactoring.
v4: New patch
--- Osstest/Debian.pm | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-)
Osstest/Debian.pm +29 -3
@@ -149,16 +149,28 @@ sub setupboot_uboot ($$$) { my $kern = "vmlinuz-$want_kernver"; my $initrd = "initrd.img-$want_kernver"; - my @xenkopt = uboot_common_kernel_bootargs($ho); + logm("Xen options: $xenhopt"); + + # Common kernel options + my @kopt = uboot_common_kernel_bootargs($ho); + + # Dom0 specific kernel options + my @xenkopt = @kopt; push @xenkopt, $xenkopt; # http://bugs.xenproject.org/xen/bug/45 push @xenkopt, "clk_ignore_unused" if $ho->{Suite} =~ m/wheezy|jessie/; $xenkopt = join ' ', @xenkopt; + logm("Dom0 Linux options: $xenkopt"); - logm("Xen options: $xenhopt"); - logm("Linux options: $xenkopt"); + # Native specific kernel options + my $natcons = get_host_native_linux_console($ho); + my @natkopt = @kopt; + push @natkopt, "console=$natcons" unless $natcons eq "NONE"; + + my $natkopt = join ' ', @natkopt; + logm("Native linux options: $natkopt"); my $early_commands = get_host_property($ho, 'UBootScriptEarlyCommands', ''); my $xen_addr_r = get_host_property($ho, 'UBootSetXenAddrR', undef);
@@ -216,6 +228,20 @@ bootz \\\${xen_addr_r} - \\\${fdt_addr} EOF mkimage -A arm -T script -d /boot/boot.xen /boot/boot.scr.xen cp /boot/boot.scr.xen /boot/boot.scr + +# Create boot.scr.nat for convenience too +cat >/boot/boot.nat <<EOF +setenv bootargs $natkopt +${load_dtb} +echo Loading $kern +ext2load scsi 0 \\\${kernel_addr_r} $kern +echo Loading $initrd +ext2load scsi 0 \\\${ramdisk_addr_r} $initrd +echo Booting +bootz \\\${kernel_addr_r} \\\${ramdisk_addr_r}:\\\${filesize} \\\${fdt_addr} +EOF +mkimage -A arm -T script -d /boot/boot.nat /boot/boot.scr.nat + END };
Signature · 1 line
2.1.4
Quoted 12 lines · Ian Campbell
I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)
Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.
I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).
Quoted 7 lines
So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.Stefano, do you have another preference?
We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.
Stefano,
Please could you pull from git://kernel.ubuntu.com/ubuntu/linux.git and the force push::
The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the input tree#branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git#linux-arm-xen
and v3.16.7-ckt4~1 (i.e. the commit before the tag) to the output tree#branch at:
git://xenbits.xen.org/linux-pvops.git#tested/linux-arm-xen
Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.
Ian.
Quoted 2 lines · Ian Campbell
Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.
Actually using the result will require me to push this along with the main series.
8<-------
Quoted 1 line
From
ba72d891c2d97991a4b00d8958883d17e4bc16d1Mon Sep 17 00:00:00 2001
From: Ian Campbell <[email protected]>
Date: Thu, 22 Jan 2015 15:53:35 +0000
Subject: [PATCH] Switch ARM testing back to linux-arm-xen branch.
The cubietruck and arndale boards need a newer kernel than our current baseline of 3.14. Therefore switch all ARM testing to the linux-arm-kernel branch which has been moved up to test v3.16.
This effectively reverts commit 38b2fe2020883 "Switch armhf to use common default Linux."
--- mfi-common | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
mfi-common +6 -5
@@ -73,6 +73,10 @@ create_build_jobs () { xen-4.1-testing) continue;; xen-4.2-testing) continue;; esac + pvops_kernel=" + tree_linux=$TREE_LINUX_ARM + revision_linux=${REVISION_LINUX_ARM:-${DEFAULT_REVISION_LINUX_ARM}} + " pvops_kconfig_overrides=" kconfig_override_y=CONFIG_EXT4_FS "
@@ -81,15 +85,12 @@ create_build_jobs () { case "$branch" in linux-arm-xen) continue;; esac - ;; - esac - - if [ "x$pvops_kernel" = x ] ; then pvops_kernel=" tree_linux=$TREE_LINUX revision_linux=${REVISION_LINUX:-${DEFAULT_REVISION_LINUX}} " - fi + ;; + esac case "$arch" in *) suite=$defsuite;;
Signature · 1 line
2.1.4
Quoted 6 lines · Ian Campbell
Quoted 2 lines · Ian Campbell
Pushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.
Actually using the result will require me to push this along with the main series.
I've have just pushed these to pretest as discussed last week:
$ git log --oneline bb2240e..2e35f88 2e35f88 make-flight: reorganize scheduling related test jobs 25ee621 Switch ARM testing back to linux-arm-xen branch. 339ad81 Debian: create boot.scr.nat when installing Xen on u-boot. fcf00b2 TestSupport: replace power_cycle_timeout with power_cycle_sleep 70b19e1 Debian: Create boot.scr with a suffix and copy to boot.scr e449fed ts-kernel-build: Adjust kernel .config to work on the arndale boards. ee5e442 Osstest/Debian: Add 0x prefix to $filesize 0e24cb2 Osstest/Debian: Add "clk_ignore_unused" to default command line 653d0af Osstest/Debian: Remove hardcoded addresses from boot.scr 2d08c4c Osstest/Debian: support adding a rootdelay property to bootargs 64c57cb Osstest/Debian.pm: Refactor common kernel cmdline setup. 45e3b3c Osstest/Debian: Refactor setting of dom0 kernel command line. 070db63 Osstest/Debian: Support for loading an FDT from u-boot script 781c575 Osstest/Debian: Install dtbs into target filesystem in /boot/dtbs 2d92112 Osstest/PDU: Add eth008.pm method to control the ARM rack PDU 056840c make-flight: Run a basic test on each arm platform
That is: This series, the one extra patch to use linux-arm-xen for kernels and Dario's scheduler rejigging.
I also ran:
OSSTEST_CONFIG=production-config ./mg-hosts setflags marilith-n\* -- platform-midway
So that 056840c does something.
Ian.
Quoted 21 lines · Ian Campbell
Quoted 12 lines · Ian Campbell
I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)
Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.
I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).
Quoted 7 lines
So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.Stefano, do you have another preference?
Quoted 7 lines
We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.
Stefano,
Please could you pull from
git://kernel.ubuntu.com/ubuntu/linux.gitand the force push::
Actually I think we should follow
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.16.y
Quoted 1 line
The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the
I was talking about v3.16.7
Quoted 12 lines
input tree#branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/sstabellini/xen.git#linux-arm-xenand v3.16.7-ckt4~1 (i.e. the commit before the tag) to the output tree#branch at:
git://xenbits.xen.org/linux-pvops.git#tested/linux-arm-xenPushing the ~1 to the output will force a test run, once that is done I will push the osstest patches.
Ian.
Quoted 25 lines · Stefano Stabellini
Quoted 24 lines · Ian Campbell
Quoted 12 lines · Ian Campbell
I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)
Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.
I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).
Quoted 7 lines
So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.Stefano, do you have another preference?
We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.
Quoted 8 lines
Quoted 4 lines
Stefano,
Please could you pull from
git://kernel.ubuntu.com/ubuntu/linux.gitand the force push::Actually I think we should follow
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.gitlinux-3.16.y
There are no more updates to this, since it is not a kernel.org LTS kernel.
The canonical kernel team (ckt in the tag name) are doing ongoing stable support for these kernels (which is also being consumed by Debian).
Quoted 3 lines
Quoted 1 line
The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the
I was talking about v3.16.7
This doesn't have e.g. the swiotlb/dma fixes which you have had backported, those are in the ckt kernels only.
Ian.
Quoted 41 lines · Ian Campbell
Quoted 25 lines · Stefano Stabellini
Quoted 24 lines · Ian Campbell
Quoted 12 lines · Ian Campbell
I've managed to make a habit of forgetting to mention one important point (including hitting send on this bit in reply to v4!)
Both the cubietruck and the arndale are (for different reasons) not supported by the 3.14 kernel which we currently use as a baseline for osstest testing.
I'm not sure if another LTS kernel is due from upstream soon or not, if not then I think we will need to resurrect the linux-arm-xen branch and use it for all arm platforms (including midway, since I don't think we want to take on the complexity of differing per platform).
Quoted 7 lines
So far I've been testing using v3.16.7, which is the last 3.16 longterm release, however canonical are carrying it on at
http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.16.y
(up to 3.16.7-ckt4 at the moment). This is the same base as Debian will be shipping in Jessie. So that is one option.Stefano, do you have another preference?
We discussed this IRL and are going to resurrect the linux-arm-xen branch following the Canonical stable v3.16 branch.
Quoted 8 lines
Quoted 4 lines
Stefano,
Please could you pull from
git://kernel.ubuntu.com/ubuntu/linux.gitand the force push::Actually I think we should follow
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.gitlinux-3.16.yThere are no more updates to this, since it is not a kernel.org LTS kernel.
The canonical kernel team (ckt in the tag name) are doing ongoing stable support for these kernels (which is also being consumed by Debian).
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
The commit pointed to by tag v3.16.7-ckt4 (i.e. v3.16.7-ckt4~0) to the
I was talking about v3.16.7
This doesn't have e.g. the swiotlb/dma fixes which you have had backported, those are in the ckt kernels only.
You are right, I was mistaken. However keep in mind that only the ubuntu stable branch linux-3.16.y-queue has the following important backport:
commit 342443e998bd2dd6406d46c5f7e62540a6d4a170
Author: Stefano Stabellini <[email protected]> Date: Fri Nov 21 11:07:39 2014 +0000
xen/arm/arm64: introduce xen_arch_need_swiotlb
commit a4dba130891271084344c12537731542ec77cb85 upstream.
Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer.
the main linux-3.16.y branch (currently tagged v3.16.7-ckt4) doesn't have it yet.
Without it, DMA is not safe with non-coherent devices.
Quoted 10 lines · Stefano Stabellini
You are right, I was mistaken. However keep in mind that only the ubuntu stable branch linux-3.16.y-queue has the following important backport:
commit
342443e998bd2dd6406d46c5f7e62540a6d4a170Author: Stefano Stabellini <[email protected]> Date: Fri Nov 21 11:07:39 2014 +0000xen/arm/arm64: introduce
xen_arch_need_swiotlb
Quoted 8 lines
commit
a4dba130891271084344c12537731542ec77cb85upstream.Introduce an arch specific function to find out whether a particular dma mapping operation needs to bounce on the swiotlb buffer.
the main linux-3.16.y branch (currently tagged v3.16.7-ckt4) doesn't have it yet.
Without it, DMA is not safe with non-coherent devices.
Hrm, how unfortunate. We expect that patch to land in ckt5 I suppose?
I think we can either wait for ckt5 or you could apply it to your branch, which means future versions would need merging not fast-forwarding. Not horrendous I suppose.