Hi, I''m having some problems with getting the latest linux kernel and xen build working on ARM''s Fast Model simulator ( Cortex A15 ). I tried a lot of different configurations and I''m having trouble with all of them. I got all my information from the wiki pages at http://wiki.xen.org/wiki/Xen_ARMv7_with_Virtualization_Extensions#Building_Xen_on_ARM . I was hoping someone could help getting the latest xen working with the latest kernel. First of all I tried the most logic setup. Device Tree: git://xenbits.xen.org/people/sstabellini/device-trees.git Dom0 Kernel: git://github.com/torvalds/linux.git ( latest ) Xen: git://xenbits.xen.org/xen.git I''m having the same results with the xen-arm-3.8.y branch of git:// xenbits.xen.org/people/ianc/linux.git for dom0 kernel. The wiki states that this should work. All the necesarry patches for the kernel were merged in 3.8 it states. This results in Xen freezing when loading dom0: ... [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32512 pages, LIFO batch:7 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/arm/mach-vexpress/v2m.c:431 v2m_dt_init_early+0x4c/0x70() [ 0.000000] [<c000d51c>] (unwind_backtrace+0x0/0xe0) from [<c0014e20>] (warn_slowpath_common+0x48/0x60) [ 0.000000] [<c0014e20>] (warn_slowpath_common+0x48/0x60) from [<c0014ef0>] (warn_slowpath_null+0x18/0x1c) [ 0.000000] [<c0014ef0>] (warn_slowpath_null+0x18/0x1c) from [<c0361610>] (v2m_dt_init_early+0x4c/0x70) [ 0.000000] [<c0361610>] (v2m_dt_init_early+0x4c/0x70) from [<c035dbdc>] (setup_arch+0x570/0x62c) [ 0.000000] [<c035dbdc>] (setup_arch+0x570/0x62c) from [<c035a520>] (start_kernel+0x70/0x2bc) [ 0.000000] [<c035a520>] (start_kernel+0x70/0x2bc) from [<80008074>] (0x80008074) [ 0.000000] ---[ end trace 1b75b31a2719ed1c ]--- [ 0.000000] vexpress: DT HBI (237) is not matching hardware (0)! [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [ 0.000000] Kernel command line: earlyprintk=xenboot lpj=8000000 console=ttyAMA1 root=/dev/mmcblk0 debug rw init=/bin/bash [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] __ex_table already sorted, skipping sort [ 0.000000] Memory: 128MB = 128MB total [ 0.000000] Memory: 126028k/126028k available, 5044k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) [ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] .text : 0xc0008000 - 0xc0359be8 (3399 kB) [ 0.000000] .init : 0xc035a000 - 0xc037c884 ( 139 kB) [ 0.000000] .data : 0xc037e000 - 0xc039ef80 ( 132 kB) [ 0.000000] .bss : 0xc039ef80 - 0xc03c1434 ( 138 kB) [ 0.000000] NR_IRQS:16 nr_irqs:16 16 I won''t go through all the configurations I tried of course but just one that I got ''semi'' working. Device Tree: git://xenbits.xen.org/people/sstabellini/device-trees.git Dom0 Kernel: git://xenbits.xen.org/people/ianc/linux.git the arm-privcmd-for-3.8 branch Xen: git://xenbits.xen.org/xen.git reset to e662eca49cf7c6ab16f874331b6893649b5cfee7 Notice the huge reset of the xen repository. I had an old branch working somewhere and just took the commit hash from that one. This combination hangs in the "Calculating delay loop" when booting dom0. After adding a loops per jiffy count to the kernel arguments manually ( lpj=8000000, read somewhere this should be about it for the model ) it passes the loop but then a bunch of other errors show up of course, all like this one: [ 0.000000] ERROR: could not get clock /smb/motherboard/iofpga@3 ,00000000/sysctl@020000:apb_pclk(2) Thanks, Sander _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Wed, 2013-03-06 at 18:20 +0000, Sander Bogaert wrote:> [ 0.000000] NR_IRQS:16 nr_irqs:16 16A 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 ;-) Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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.
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@eu.citrix.com>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@lists.xen.org http://lists.xen.org/xen-devel
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@elis.ugent.be>> 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@eu.citrix.com> 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@lists.xen.org > http://lists.xen.org/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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@gmail.com> 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@elis.ugent.be> > >> 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@eu.citrix.com> 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@lists.xen.org >> http://lists.xen.org/xen-devel >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Sun, 2013-03-10 at 17:50 +0000, Sander Bogaert wrote:> 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.The right answer here depends on whether disk.img contains a partition table or not and which partition contains the actual filesystem. If disk.img has no partition table then "mmcblk0" is correct. If it does have a partition table then "mmcblk0p<N>" is correct where <N> is the partition number. IIRC the kernel prints out the partitions as it discovers them, or you can investigate with fdisk in the host. You should also check that your kernel includes the relevant filesystem. Ian.