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