|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH OSSTEST v4 00/13] support for ARM32 arndale and cubietruck platforms
On Thu, 2015-01-29 at 11:25 +0000, Ian Jackson wrote:
> Nnng.
[...]
> Oh god oh god the horror.
Quite...
> > In theory I could try upgrading the u-boot firmware on these systems
> > (it's still supported by mainline u-boot), but to be honest with Calxeda
> > no longer existing I'm reluctant to do anything which might have any
> > chance of bricking the systems.
> >
> > I'm not sure how specific to make this quirk and whether it is worth
> > doing via the hostdb or just directly in Debian.pm. Options:
> >
> > * Make the addition of the 0x prefix conditional on !
> > platform-midway
>
> I think this would be an abuse of platform-*. You've already done
> this kind of thing once with equiv-marilith in Osstest/CXFabric.pm and
> I think I should have put my foot down then...
I thought you'd say that ;-)
>
> > * A similar host flag to control the addition (or, more likely,
> > the omission of) of the 0x
>
> That would be fine, although AFAICT we don't really have any quirks in
> the hostflags already. It should probably be quirk-something.
>
> > * Add a new host prop e.g. UBootLoadFilesizePrefix, defaulting to
> > 0x and set to '' on midway machines
>
> That would be fine too (although do you expect any values other than
> '' and 0x?)
It seems pretty unlikely, at least I can't think of anything plausible.
Which suggests a hostflag is the right answer...
I propose to append the following to the pretest branch (rather than
trying to fold it into some existing patch, although I can if you want)
Feel free to bikeshed the name, of course ;-)...
8<------
From caee3d8167b107b02293b1e72dae2d76db08437c Mon Sep 17 00:00:00 2001
From: Ian Campbell <ian.campbell@xxxxxxxxxx>
Date: Thu, 29 Jan 2015 11:37:39 +0000
Subject: [PATCH] Debian: Handle systems where u-boot includes 0x on $filesize
Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
---
Osstest/Debian.pm | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 3c4ac5e..9b54e5e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -180,6 +180,22 @@ sub setupboot_uboot ($$$) {
my $set_xen_addr_r =
$xen_addr_r ? "setenv xen_addr_r $xen_addr_r" : "";
+ # According to u-boot policy $filesize is an unprefixed hex
+ # number, but fdt set requires numbers to be prefixed
+ # (e.g. with 0x for a hex number). See:
+ #
+ # http://lists.denx.de/pipermail/u-boot/2014-October/193622.html,
+ # http://lists.denx.de/pipermail/u-boot/2014-November/194150.html and
+ # http://lists.denx.de/pipermail/u-boot/2014-November/194150.html.
+ #
+ # However some older u-boot versions (e.g. on midway) erroneously
+ # include the 0x prefix when setting $filesize from ext*load
+ # commands, meaning we cannot simply unconditionally prepend
+ # the 0x. Base it on a host flag quirk.
+ my $size_hex_prefix =
+ $ho->{Flags}{'quirk-load-filesize-has-0x-prefix'} ?
+ '' : '0x';
+
target_cmd_root($ho, <<END);
if test ! -f /boot/$kern ; then
exit 1
@@ -210,7 +226,7 @@ echo command line: \\\${bootargs}
ext2load scsi 0 \\\${kernel_addr_r} $kern
fdt mknod /chosen module\@0
fdt set /chosen/module\@0 compatible "xen,linux-zimage" "xen,multiboot-module"
-fdt set /chosen/module\@0 reg <\\\${kernel_addr_r} 0x\\\${filesize}>
+fdt set /chosen/module\@0 reg <\\\${kernel_addr_r}
${size_hex_prefix}\\\${filesize}>
fdt set /chosen/module\@0 bootargs "$xenkopt"
echo Loaded $kern to \\\${kernel_addr_r} (\\\${filesize})
echo command line: $xenkopt
@@ -218,7 +234,7 @@ echo command line: $xenkopt
ext2load scsi 0 \\\${ramdisk_addr_r} $initrd
fdt mknod /chosen module\@1
fdt set /chosen/module\@1 compatible "xen,linux-initrd" "xen,multiboot-module"
-fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r} 0x\\\${filesize}>
+fdt set /chosen/module\@1 reg <\\\${ramdisk_addr_r}
${size_hex_prefix}\\\${filesize}>
echo Loaded $initrd to \\\${ramdisk_addr_r} (\\\${filesize})
fdt print /chosen
--
2.1.4
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |