Re: [Xen-devel] Latest Xen on ARM Fast Models

[Sander Bogaert <sander.bogaert@xxxxxxxxxxxxx>]

Hi,

It seems like I explained myself wrong. I have an unmodified dts file EXCEPT the root argument in "xen,dom0-bootargs = ..." where I tried both '/dev/mmcblk0p2' and '/dev/mmcblk0'. I also tried applying the mmc patch to the linux  kernel ( mentioned on the wiki ) because it seems to have helped before ( http://lists.xen.org/archives/html/xen-devel/2013-03/msg00561.html ), this didn't work for me.

Sander

On 11 March 2013 02:07, Josh Zhao <joshsystem@xxxxxxxxx> wrote:

It should be modified.You may re-compile device-tree and xen after modifying /dev/mmcblk0p2.

josh zhao

2013/3/11 Sander Bogaert <sander.bogaert@xxxxxxxxxxxxx>

Hi,

Thanks for this. I updated FastModels to the latest version and everything boots now ( also pulled in some commits in linux & xen so might be those ). 

Quick last question; I use a debianhf filesystem and pass it to the model_shell with this argument:

... -C motherboard.mmc.p_mmc_file=../../../../source/disk.img

The device-tree is unmodified so the kernel argument is root=/dev/mmcblk0. I also tried /dev/mmcblk0p2 because I read this in a Linaro FastModels guide. Booting dom0 gets me the following panic. Any idea on what I'm doing wrong here?

[    2.713635] VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6

[    2.713697] Please append a correct "root=" boot option; here are the available partitions:

[    2.713788] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

[    2.713963] [<c000d3a8>] (unwind_backtrace+0x0/0xe0) from [<c02abeec>] (panic+0x70/0x1c0)

[    2.714101] [<c02abeec>] (panic+0x70/0x1c0) from [<c0362de0>] (mount_block_root+0x1e0/0x220)

[    2.714316] [<c0362de0>] (mount_block_root+0x1e0/0x220) from [<c0362ff4>] (mount_root+0xec/0x10c)

[    2.714458] [<c0362ff4>] (mount_root+0xec/0x10c) from [<c0363170>] (prepare_namespace+0x15c/0x1b0)

[    2.714603] [<c0363170>] (prepare_namespace+0x15c/0x1b0) from [<c0362a30>] (kernel_init_freeable+0x164/0x1a8)

[    2.714749] [<c0362a30>] (kernel_init_freeable+0x164/0x1a8) from [<c02ab080>] (kernel_init+0x8/0xe4)

[    2.714881] [<c02ab080>] (kernel_init+0x8/0xe4) from [<c0009378>] (ret_from_fork+0x14/0x3c)

Thanks!

On 7 March 2013 04:46, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx> wrote:

On Thu, 7 Mar 2013, Ian Campbell wrote:
> On Wed, 2013-03-06 at 18:20 +0000, Sander Bogaert wrote:
>
> > [    0.000000] NR_IRQS:16 nr_irqs:16 16
>
> A hang here is usually down to the device tree being not quite to either
> Xen or the kernel's liking.  I've attached the one I use with the
> upstream kernel and Xen trees, it's based on
> arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts from the kernel tree and I
> use it by dumping it into the kernel tree and "make dtbs".
>
> Stefano, I think we need to nuke the
> git://xenbits.xen.org/people/sstabellini/device-trees.git stuff from the
> wiki and replace it with something which actually works ;-)

Actually I think that device tree should be correct.

However some Fast Models had a bug in the virtual timer that could cause
an hang like that. I would recommend upgrading your Fast Model to the
very last version, or disable the virtual timer:


diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
index c8ef207..3a2d7a7 100644
--- a/arch/arm/kernel/arch_timer.c
+++ b/arch/arm/kernel/arch_timer.c
@@ -42,7 +42,7 @@ static int arch_timer_ppi[MAX_TIMER_PPI];
 static struct clock_event_device __percpu **arch_timer_evt;
 static struct delay_timer arch_delay_timer;

-static bool arch_timer_use_virtual = true;
+static bool arch_timer_use_virtual = false;

 /*
  * Architected system timer support.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel