* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 12:47 ` Julien Grall
@ 2013-08-12 14:15 ` Andrii Anisov
2013-08-12 14:30 ` Andrii Anisov
` (2 subsequent siblings)
3 siblings, 0 replies; 39+ messages in thread
From: Andrii Anisov @ 2013-08-12 14:15 UTC (permalink / raw)
To: Julien Grall; +Cc: Chen Baozi, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 4855 bytes --]
Chen,
What I can say is that omap's kernel accesses number of devices not
actually listed in device-tree.
Yes, omap has real problems with support via dt, it still has a lot of
stuff buried in board files. So you have to do manual mappings of IOMEM
ranges like it is done in exynos5_specific_mapping().
Andrii Anisov | Software Engineer
GlobalLogic
Kyiv, 03038, Protasov Business Park, M.Grinchenka, 2/1
P +38.044.492.9695x3664 M +380505738852 S andriyanisov
www.globallogic.com
<http://www.globallogic.com/>
http://www.globallogic.com/email_disclaimer.txt
On Mon, Aug 12, 2013 at 3:47 PM, Julien Grall <julien.grall@linaro.org>wrote:
> On 08/12/2013 01:24 PM, Chen Baozi wrote:
> > Hi Ian & Julien,
> >
> > I've added SMP "cpu kicking" & "mode switching" codes for OMAP5 today and
> > trying to boot Xen on my board again. And it looks that I still got some
> > work to do to boot my board.
> >
> > I attach the log in the end of mail. Any ideas for what I should have
> > missed?
> >
> > Cheers,
> >
> > Baozi
> >
> > ---
> > Starting kernel ...
> >
> > - UART enabled -
> > - CPU 00000000 booting -
> > - Machine ID 00000ec1 -
> > - Started in Hyp mode -
> > - Zero BSS -
> > - Setting up control registers -
> > - Turning on paging -
> > - Ready -
> > fdt: node `cpu@0': invalid #address-cells or #size-cellsfdt: node `cpu@1
> ':
> > - invalid #addref
>
> Hum ... this is why Xen can't find the other cpus. Could you paste the
> content of the node cpus here?
>
> > MODULE[1]: 00000000a0000000 - 00000000a0400000
> > Placing Xen at 0x00000000fee00000-0x00000000ff000000
> > Xen heap: 262144 pages Dom heap: 258048 pages
> > Looking for UART console serial2
> > __ __ _ _ _ _ _ _ _
> > \ \/ /___ _ __ | || | | || | _ _ _ __ ___| |_ __ _| |__ | | ___
> > \ // _ \ '_ \ | || |_| || |_ __| | | | '_ \/ __| __/ _` | '_ \| |/ _
> \
> > / \ __/ | | | |__ _|__ _|__| |_| | | | \__ \ || (_| | |_) | |
> __/
> > /_/\_\___|_| |_| |_|(_) |_| \__,_|_|
> |_|___/\__\__,_|_.__/|_|\___|
> >
> > (XEN) Xen version 4.4-unstable (cbz@) (arm-linux-gnueabihf-gcc
> (crosstool-NG
> > linaro-1.13.3
> > (XEN) Latest ChangeSet: Wed Aug 7 11:38:25 2013 +0800 git:47f28d7-dirty
> > (XEN) Processor: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2
> > (XEN) 32-bit Execution:
> > (XEN) Processor Features: 00001131:00011011
> > (XEN) Instruction Sets: AArch32 Thumb Thumb-2 ThumbEE Jazelle
> > (XEN) Extensions: GenericTimer Security
> > (XEN) Debug Features: 02010555
> > (XEN) Auxiliary Features: 00000000
> > (XEN) Memory Model Features: 10201105 20000000 01240000 02102211
> > (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142
> 00000000
> > (XEN) Platform: TI OMAP5
> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> > (XEN) Using generic timer at 6144 KHz
> > (XEN) GIC initialization:
> > (XEN) gic_dist_addr=0000000048211000
> > (XEN) gic_cpu_addr=0000000048212000
> > (XEN) gic_hyp_addr=0000000048214000
> > (XEN) gic_vcpu_addr=0000000048216000
> > (XEN) gic_maintenance_irq=25
> > (XEN) GIC: 192 lines, 2 cpus, secure (IID 0000043b).
> > (XEN) Waiting for 0 other CPUs to be ready
> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
> > (XEN) Allocated console ring of 16 KiB.
> > (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0
> > (XEN) Brought up 1 CPUs
> > (XEN) *** LOADING DOMAIN 0 ***
> > (XEN) Populate P2M 0x80000000->0x90000000
> > (XEN) Loading kernel from boot module 1
> > (XEN) Loading zImage from 00000000a0000000 to
> > 0000000080008000-00000000803f6d70
> > (XEN) Loading dom0 DTB to 0x000000008fe00000-0x000000008fe04e46
> > (XEN) Std. Loglevel: All
> > (XEN) Guest Loglevel: All
> > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to
> > Xen)
> > (XEN) Freed 220kB init memory.
> > (XEN) Guest data abort: Translation fault at level 3
> > (XEN) gva=fce06704
> > (XEN) gpa=000000004ae06704
>
> Dom0 is trying to access to 4ae06704 which is not mapped. Do you know
> where does this address come from (device tree, hardcoded, ...)?
>
> > (XEN) size=2 sign=0 write=0 reg=0
> > (XEN) eat=0 cm=0 s1ptw=0 dfsc=7
> > (XEN) dom0 IPA 0x000000004ae06704
> > (XEN) P2M @ 02fdbf80 mfn:0xfedfc
> > (XEN) 1ST[0x1] = 0x00000000fedfe6ff
> > (XEN) 2ND[0x57] = 0x00000000ac9796ff
> > (XEN) 3RD[0x6] = 0x0000000000000000
> > (XEN) ----[ Xen-4.4-unstable arm32 debug=y Not tainted ]----
> > (XEN) CPU: 0
> > (XEN) PC: c0033410
>
> To help you, you can use "addr2line -e vmlinux address" to find the
> faulty line in linux. Where address is your pc.
>
> Cheers,
>
> --
> Julien Grall
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
[-- Attachment #1.2: Type: text/html, Size: 8368 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 12:47 ` Julien Grall
2013-08-12 14:15 ` Andrii Anisov
@ 2013-08-12 14:30 ` Andrii Anisov
2013-08-12 15:08 ` Julien Grall
2013-08-13 7:56 ` Chen Baozi
2013-08-12 14:54 ` Andrii Anisov
2013-08-13 9:10 ` Chen Baozi
3 siblings, 2 replies; 39+ messages in thread
From: Andrii Anisov @ 2013-08-12 14:30 UTC (permalink / raw)
To: Julien Grall, Chen Baozi; +Cc: Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1065 bytes --]
>
>
> > - Turning on paging -
> > - Ready -
> > fdt: node `cpu@0': invalid #address-cells or #size-cellsfdt: node `cpu@1
> ':
> > - invalid #addref
>
> Hum ... this is why Xen can't find the other cpus. Could you paste the
> content of the node cpus here?
>
>
I bet, something like this:
};
cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
cpu@0 {
+ device_type = "cpu";
compatible = "arm,cortex-a15";
+ reg = <0>;
operating-points = <
/* kHz uV */
/* Only for Nominal Samples */
@@ -48,7 +53,9 @@
clock-latency = <300000>; /* From omap-cpufreq
driver */
};
cpu@1 {
+ device_type = "cpu";
compatible = "arm,cortex-a15";
+ reg = <1>;
};
};
will help to Chen.
*Sincerely,*
*Andrii Anisov. *
[-- Attachment #1.2: Type: text/html, Size: 1847 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 14:30 ` Andrii Anisov
@ 2013-08-12 15:08 ` Julien Grall
2013-08-12 15:32 ` Andrii Anisov
2013-08-13 7:56 ` Chen Baozi
1 sibling, 1 reply; 39+ messages in thread
From: Julien Grall @ 2013-08-12 15:08 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Chen Baozi, Ian Campbell, xen-devel
On 08/12/2013 03:30 PM, Andrii Anisov wrote:
>
>
>
> > - Turning on paging -
> > - Ready -
> > fdt: node `cpu@0': invalid #address-cells or #size-cellsfdt: node
> `cpu@1':
> > - invalid #addref
>
> Hum ... this is why Xen can't find the other cpus. Could you paste the
> content of the node cpus here?
>
>
> I bet, something like this:
>
> };
>
> cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> cpu@0 {
> + device_type = "cpu";
> compatible = "arm,cortex-a15";
> + reg = <0>;
> operating-points = <
> /* kHz uV */
> /* Only for Nominal Samples */
> @@ -48,7 +53,9 @@
> clock-latency = <300000>; /* From omap-cpufreq
> driver */
> };
> cpu@1 {
> + device_type = "cpu";
> compatible = "arm,cortex-a15";
> + reg = <1>;
> };
> };
I thought these nodes was a requirement in the device tree.
Xen relies on these nodes and I guess Linux plan to do the same thing
for multi-platform support.
Perhaps it's a patch to send upstream? :)
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 15:08 ` Julien Grall
@ 2013-08-12 15:32 ` Andrii Anisov
2013-08-12 15:40 ` Andrii Anisov
0 siblings, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-12 15:32 UTC (permalink / raw)
To: Julien Grall; +Cc: Chen Baozi, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 303 bytes --]
> I thought these nodes was a requirement in the device tree.
> Xen relies on these nodes and I guess Linux plan to do the same thing
> for multi-platform support.
OMAP is yet specific here (dt in general I mean)
> Perhaps it's a patch to send upstream? :)
Good point :)
Sincerely,
Andrii Anisov.
[-- Attachment #1.2: Type: text/html, Size: 711 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 15:32 ` Andrii Anisov
@ 2013-08-12 15:40 ` Andrii Anisov
2013-08-13 2:40 ` Chen Baozi
0 siblings, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-12 15:40 UTC (permalink / raw)
To: Julien Grall; +Cc: Chen Baozi, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 97 bytes --]
BTW, Chen,
What kernel are trying to start as Dom0 on your Panda?
*Sincerely,*
*Andrii Anisov.*
[-- Attachment #1.2: Type: text/html, Size: 250 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 15:40 ` Andrii Anisov
@ 2013-08-13 2:40 ` Chen Baozi
0 siblings, 0 replies; 39+ messages in thread
From: Chen Baozi @ 2013-08-13 2:40 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 12, 2013, at 11:40 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> BTW, Chen,
>
> What kernel are trying to start as Dom0 on your Panda?
I use the upstream kernel plus 2 clock data patches.
Also Roger Quadros from TI gave me a 3.11 git branch that contains all
patches required including ethernet driver and clock data.
You can get the necessary stuff from branch
usbhost-uevm-3.11-rc3
in git tree
git://github.com/rogerq/linux.git
Cheers,
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 14:30 ` Andrii Anisov
2013-08-12 15:08 ` Julien Grall
@ 2013-08-13 7:56 ` Chen Baozi
2013-08-13 8:45 ` Chen Baozi
1 sibling, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-13 7:56 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 12, 2013, at 10:30 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>
>
>
> > - Turning on paging -
> > - Ready -
> > fdt: node `cpu@0': invalid #address-cells or #size-cellsfdt: node `cpu@1':
> > - invalid #addref
>
> Hum ... this is why Xen can't find the other cpus. Could you paste the
> content of the node cpus here?
>
>
> I bet, something like this:
>
> };
>
> cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> cpu@0 {
> + device_type = "cpu";
> compatible = "arm,cortex-a15";
> + reg = <0>;
> operating-points = <
> /* kHz uV */
> /* Only for Nominal Samples */
> @@ -48,7 +53,9 @@
> clock-latency = <300000>; /* From omap-cpufreq driver */
> };
> cpu@1 {
> + device_type = "cpu";
> compatible = "arm,cortex-a15";
> + reg = <1>;
> };
> };
>
> will help to Chen.
I used the original 3.8 kernel's dts from TI. And the cpu node (I've modified
to move the timer node outside it) is like:
cpus {
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
};
And I checked the latest git tree I've used, it is:
cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
};
I'll check if the missing address-cells and size-cells caused my
issues.
Thanks.
Baozi
>
> Sincerely,
> Andrii Anisov.
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 7:56 ` Chen Baozi
@ 2013-08-13 8:45 ` Chen Baozi
2013-08-13 9:55 ` Julien Grall
0 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-13 8:45 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 13, 2013, at 3:56 PM, Chen Baozi <baozich@gmail.com> wrote:
>
> On Aug 12, 2013, at 10:30 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>
>>
>>
>>
>>> - Turning on paging -
>>> - Ready -
>>> fdt: node `cpu@0': invalid #address-cells or #size-cellsfdt: node `cpu@1':
>>> - invalid #addref
>>
>> Hum ... this is why Xen can't find the other cpus. Could you paste the
>> content of the node cpus here?
>>
>>
>> I bet, something like this:
>>
>> };
>>
>> cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> cpu@0 {
>> + device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> + reg = <0>;
>> operating-points = <
>> /* kHz uV */
>> /* Only for Nominal Samples */
>> @@ -48,7 +53,9 @@
>> clock-latency = <300000>; /* From omap-cpufreq driver */
>> };
>> cpu@1 {
>> + device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> + reg = <1>;
>> };
>> };
>>
>> will help to Chen.
>
> I used the original 3.8 kernel's dts from TI. And the cpu node (I've modified
> to move the timer node outside it) is like:
>
> cpus {
> cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> };
> cpu@1 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x1>;
> };
> };
>
> And I checked the latest git tree I've used, it is:
>
> cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
>
> cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> };
> cpu@1 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x1>;
> };
> };
>
> I'll check if the missing address-cells and size-cells caused my
> issues.
>
Yes, it is because of lacking #address-cells and #size-cells.
>
>>
>> Sincerely,
>> Andrii Anisov.
>
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 8:45 ` Chen Baozi
@ 2013-08-13 9:55 ` Julien Grall
0 siblings, 0 replies; 39+ messages in thread
From: Julien Grall @ 2013-08-13 9:55 UTC (permalink / raw)
To: Chen Baozi; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On 13 August 2013 09:45, Chen Baozi <baozich@gmail.com> wrote:
>
> On Aug 13, 2013, at 3:56 PM, Chen Baozi <baozich@gmail.com> wrote:
>
>>
>> On Aug 12, 2013, at 10:30 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>> And I checked the latest git tree I've used, it is:
>>
>> cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>>
>> cpu@0 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x0>;
>> };
>> cpu@1 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x1>;
>> };
>> };
>>
>> I'll check if the missing address-cells and size-cells caused my
>> issues.
>>
>
> Yes, it is because of lacking #address-cells and #size-cells.
Hum, according to Linux Documentation/devicetree/booting-without-of.txt
(section III.5.b):
"This node is the parent of all individual CPU nodes. It doesn't
have any specific requirements, though it's generally good practice
to have at least:
#address-cells = <00000001>
#size-cells = <00000000>
This defines that the "address" for a CPU is a single cell, and has
no meaningful size. This is not necessary but the kernel will assume
that format when reading the "reg" properties of a CPU node, see
below"
So Xen doesn't have the right behaviour. I will send a patch later to fix
this issue.
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 12:47 ` Julien Grall
2013-08-12 14:15 ` Andrii Anisov
2013-08-12 14:30 ` Andrii Anisov
@ 2013-08-12 14:54 ` Andrii Anisov
2013-08-13 9:10 ` Chen Baozi
3 siblings, 0 replies; 39+ messages in thread
From: Andrii Anisov @ 2013-08-12 14:54 UTC (permalink / raw)
To: Julien Grall; +Cc: Chen Baozi, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 3326 bytes --]
> > (XEN) size=2 sign=0 write=0 reg=0
> > (XEN) eat=0 cm=0 s1ptw=0 dfsc=7
> > (XEN) dom0 IPA 0x000000004ae06704
> > (XEN) P2M @ 02fdbf80 mfn:0xfedfc
> > (XEN) 1ST[0x1] = 0x00000000fedfe6ff
> > (XEN) 2ND[0x57] = 0x00000000ac9796ff
> > (XEN) 3RD[0x6] = 0x0000000000000000
> > (XEN) ----[ Xen-4.4-unstable arm32 debug=y Not tainted ]----
> > (XEN) CPU: 0
> > (XEN) PC: c0033410
>
> To help you, you can use "addr2line -e vmlinux address" to find the
> faulty line in linux. Where address is your pc.
>
>
long time ago, when we faced similar problems, we did a debug patch:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f3f88d4..76ec21c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -862,6 +862,27 @@ done:
if (first) unmap_domain_page(first);
}
+#ifdef DEBUG_DOMAIN
+static uint32_t exec_vector_base(void) {
+ if (READ_SYSREG(SCTLR_EL1) & SCTLR_V)
+ return EXC_BASE_ADDR_HI;
+ else if (READ_SYSREG32(ID_PFR1_EL1) & PFR1_SE_MASK)
+ return READ_SYSREG(VBAR_EL1);
+ else
+ return EXC_BASE_ADDR_LO;
+}
+
+static void domain_data_abort(struct cpu_user_regs *regs) {
+ printk("Data abort invokation on the domain side...\n");
+ regs->spsr_abt = regs->cpsr;
+ regs->lr_abt = regs->pc + 8;
+ WRITE_SYSREG(READ_SYSREG(HCR_EL2) | HCR_VA, HCR_EL2);
+ regs->cpsr &= ~(PSR_JAZELLE | PSR_IT_MASK | PSR_MODE_MASK);
+ regs->cpsr |= PSR_MODE_ABT | PSR_IRQ_MASK | PSR_ABT_MASK;
+ regs->pc = exec_vector_base() + DATA_ABORT_OFFSET;
+}
+#endif
+
static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
struct hsr_dabt dabt)
{
@@ -917,7 +938,11 @@ bad_data_abort:
else
dump_guest_s1_walk(current->domain, info.gva);
show_execution_state(regs);
+#ifndef DEBUG_DOMAIN
domain_crash_synchronous();
+#else
+ domain_data_abort(regs);
+#endif
}
asmlinkage void do_trap_hypervisor(struct cpu_user_regs *regs)
diff --git a/xen/include/asm-arm/arm32/processor.h
b/xen/include/asm-arm/arm32/processor.h
index a782d96..4de8431 100644
--- a/xen/include/asm-arm/arm32/processor.h
+++ b/xen/include/asm-arm/arm32/processor.h
@@ -107,6 +107,11 @@ struct cpu_user_regs
#define READ_SYSREG(R...) READ_SYSREG32(R)
#define WRITE_SYSREG(V, R...) WRITE_SYSREG32(V, R)
+#define EXC_BASE_ADDR_HI 0xffff0000
+#define EXC_BASE_ADDR_LO 0x00000000
+
+#define DATA_ABORT_OFFSET 0x10
+
#endif /* __ASSEMBLY__ */
#endif /* __ASM_ARM_ARM32_PROCESSOR_H */
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 3333399..a07a33c 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -228,6 +228,10 @@ typedef uint64_t xen_callback_t;
#define PSR_BIG_ENDIAN (1<<9) /* Big Endian Mode */
#define PSR_JAZELLE (1<<24) /* Jazelle Mode */
+/* If-Then execution state bits mask for the Thumb IT (If-Then)
instruction */
+#define PSR_IT_MASK (0x3F<<10 | 0x3<<25)
+#define PFR1_SE_MASK (0xF<<4) /* PFR1 Security Extensions bits
mask */
+
#endif /* __XEN_PUBLIC_ARCH_ARM_H__ */
/*
--
1.7.9.5
The idea was to invoke data abort on domain side, to see call stack. This
patch applied to the code we forked near the March this year, I don't know
if it would fit current code. It worked for Dom0 only.
*Sincerely,*
*Andrii Anisov.*
[-- Attachment #1.2: Type: text/html, Size: 7055 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-12 12:47 ` Julien Grall
` (2 preceding siblings ...)
2013-08-12 14:54 ` Andrii Anisov
@ 2013-08-13 9:10 ` Chen Baozi
2013-08-13 9:36 ` Andrii Anisov
3 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-13 9:10 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, xen-devel
On Mon, Aug 12, 2013 at 01:47:37PM +0100, Julien Grall wrote:
> > (XEN) size=2 sign=0 write=0 reg=0
> > (XEN) eat=0 cm=0 s1ptw=0 dfsc=7
> > (XEN) dom0 IPA 0x000000004ae06704
> > (XEN) P2M @ 02fdbf80 mfn:0xfedfc
> > (XEN) 1ST[0x1] = 0x00000000fedfe6ff
> > (XEN) 2ND[0x57] = 0x00000000ac9796ff
> > (XEN) 3RD[0x6] = 0x0000000000000000
> > (XEN) ----[ Xen-4.4-unstable arm32 debug=y Not tainted ]----
> > (XEN) CPU: 0
> > (XEN) PC: c0033410
>
> To help you, you can use "addr2line -e vmlinux address" to find the
> faulty line in linux. Where address is your pc.
$addr2line -e vmlinux 0xc0033410
/home/cbz/src/linux/arch/arm/mach-omap2/prminst44xx.c:52
I checked the codes around line 52 in prminst44xx:
45 /* Read a register in a PRM instance */
46 u32 omap4_prminst_read_inst_reg(u8 part, s16 inst, u16 idx)
47 {
48 BUG_ON(part >= OMAP4_MAX_PRCM_PARTITIONS ||
49 part == OMAP4430_INVALID_PRCM_PARTITION ||
50 !_prm_bases[part]);
51 return __raw_readl(_prm_bases[part] + inst + idx);
52 }
So I think I have to implement a .specific_mapping such as
exynos5_specific_mapping in arch/arm/platforms/exynos5.c?
Just one more question. Read from OMAP5 datasheet, its IO memory address
space ranges from 0 to 2G (with holes of course). Do I have to map all
of them?
Cheers,
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 9:10 ` Chen Baozi
@ 2013-08-13 9:36 ` Andrii Anisov
2013-08-13 9:40 ` Chen Baozi
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Andrii Anisov @ 2013-08-13 9:36 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 833 bytes --]
Chen,
> So I think I have to implement a .specific_mapping such as
> exynos5_specific_mapping in arch/arm/platforms/exynos5.c?
>
> I gave this hint a few messages ago in this thread ;)
> Just one more question. Read from OMAP5 datasheet, its IO memory address
> space ranges from 0 to 2G (with holes of course). Do I have to map all
> of them?
It really depends on what you want to achieve.
If you need things up and running ASAP - just map all the range. But
mention following:
- exclude GIC range
- exclude your xen console UART range
Other hints:
- set kernel console to hvc0
- disable printings from LK decompressor (it writes directly to omap
debug UART3, and if you give it to xen and don't map to Dom0 - will have
data abort)
BTW, have you got CPU1 brought up by XEN?
*Sincerely,*
*Andrii Anisov*
[-- Attachment #1.2: Type: text/html, Size: 1502 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 9:36 ` Andrii Anisov
@ 2013-08-13 9:40 ` Chen Baozi
2013-08-13 9:58 ` Julien Grall
2013-08-14 9:53 ` Chen Baozi
2 siblings, 0 replies; 39+ messages in thread
From: Chen Baozi @ 2013-08-13 9:40 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 13, 2013, at 5:36 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> Chen,
>
> So I think I have to implement a .specific_mapping such as
> exynos5_specific_mapping in arch/arm/platforms/exynos5.c?
>
> I gave this hint a few messages ago in this thread ;)
I should have read more carefully, ;-)
>
> Just one more question. Read from OMAP5 datasheet, its IO memory address
> space ranges from 0 to 2G (with holes of course). Do I have to map all
> of them?
>
> It really depends on what you want to achieve.
> If you need things up and running ASAP - just map all the range. But mention following:
> • exclude GIC range
> • exclude your xen console UART range
> Other hints:
> • set kernel console to hvc0
> • disable printings from LK decompressor (it writes directly to omap debug UART3, and if you give it to xen and don't map to Dom0 - will have data abort)
> BTW, have you got CPU1 brought up by XEN?
Yes, :-)
Thanks.
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 9:36 ` Andrii Anisov
2013-08-13 9:40 ` Chen Baozi
@ 2013-08-13 9:58 ` Julien Grall
2013-08-14 9:46 ` Chen Baozi
2013-08-14 9:53 ` Chen Baozi
2 siblings, 1 reply; 39+ messages in thread
From: Julien Grall @ 2013-08-13 9:58 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Chen Baozi, Ian Campbell, xen-devel
On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> disable printings from LK decompressor (it writes directly to omap debug
> UART3, and if you give it to xen and don't map to Dom0 - will have data
> abort)
With Chen's patch series and the latest Xen, you don't need to disable
LK decompressor.
Xen has a basic emulation for "stolen" UART.
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 9:58 ` Julien Grall
@ 2013-08-14 9:46 ` Chen Baozi
2013-08-14 9:55 ` Julien Grall
0 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-14 9:46 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>> disable printings from LK decompressor (it writes directly to omap debug
>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>> abort)
>
> With Chen's patch series and the latest Xen, you don't need to disable
> LK decompressor.
> Xen has a basic emulation for "stolen" UART.
BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
Cheers,
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 9:46 ` Chen Baozi
@ 2013-08-14 9:55 ` Julien Grall
2013-08-14 12:38 ` Chen Baozi
2013-08-14 16:07 ` Andrii Anisov
0 siblings, 2 replies; 39+ messages in thread
From: Julien Grall @ 2013-08-14 9:55 UTC (permalink / raw)
To: Chen Baozi; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
>
> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
>
>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>>> disable printings from LK decompressor (it writes directly to omap debug
>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>>> abort)
>>
>> With Chen's patch series and the latest Xen, you don't need to disable
>> LK decompressor.
>> Xen has a basic emulation for "stolen" UART.
>
> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
Unfortunately, no. The UART emulation is too simple to handle the real driver.
I'm currently preparing a patch series which will remove this hack in the DTS.
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 9:55 ` Julien Grall
@ 2013-08-14 12:38 ` Chen Baozi
2013-08-15 9:13 ` Julien Grall
2013-08-14 16:07 ` Andrii Anisov
1 sibling, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-14 12:38 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
>>
>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>
>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>>>> disable printings from LK decompressor (it writes directly to omap debug
>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>>>> abort)
>>>
>>> With Chen's patch series and the latest Xen, you don't need to disable
>>> LK decompressor.
>>> Xen has a basic emulation for "stolen" UART.
>>
>> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
>
> Unfortunately, no. The UART emulation is too simple to handle the real driver.
> I'm currently preparing a patch series which will remove this hack in the DTS.
Another question.
Before I saw Linux booting message, there is a line of message:
(XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong CPUTargetList
Is it a big issue for booting dom0?
Thanks.
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 12:38 ` Chen Baozi
@ 2013-08-15 9:13 ` Julien Grall
2013-08-15 9:47 ` Chen Baozi
0 siblings, 1 reply; 39+ messages in thread
From: Julien Grall @ 2013-08-15 9:13 UTC (permalink / raw)
To: Chen Baozi; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On 14 August 2013 13:38, Chen Baozi <baozich@gmail.com> wrote:
>
> On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@linaro.org> wrote:
>
>> On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
>>>
>>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>
>>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>>>>> disable printings from LK decompressor (it writes directly to omap debug
>>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>>>>> abort)
>>>>
>>>> With Chen's patch series and the latest Xen, you don't need to disable
>>>> LK decompressor.
>>>> Xen has a basic emulation for "stolen" UART.
>>>
>>> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
>>
>> Unfortunately, no. The UART emulation is too simple to handle the real driver.
>> I'm currently preparing a patch series which will remove this hack in the DTS.
>
> Another question.
>
> Before I saw Linux booting message, there is a line of message:
>
> (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong CPUTargetList
>
> Is it a big issue for booting dom0?
I don't think so. Linux is trying to send an SGI to a non-running VCPU.
I'm curious to know why Linux is trying to do this. Can you try to
apply the patch below and paste dom0 output log?
============================================================
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index ee7c503..73161cc 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -652,6 +652,9 @@ void gic_raise_softirq(const struct cpumask *mask,
unsigned int irq)
for_each_cpu(cpu, mask)
map |= gic_cpu_map[cpu];
+ if ( map == 0xfe )
+ dump_stack();
+
/*
* Ensure that stores to Normal memory are visible to the
* other CPUs before issuing the IPI.
============================================================
--
Julien Grall
^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 9:13 ` Julien Grall
@ 2013-08-15 9:47 ` Chen Baozi
2013-08-15 10:07 ` Julien Grall
0 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 9:47 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On Thu, Aug 15, 2013 at 10:13:15AM +0100, Julien Grall wrote:
> On 14 August 2013 13:38, Chen Baozi <baozich@gmail.com> wrote:
> >
> > On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@linaro.org> wrote:
> >
> >> On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
> >>>
> >>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
> >>>
> >>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> >>>>> disable printings from LK decompressor (it writes directly to omap debug
> >>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
> >>>>> abort)
> >>>>
> >>>> With Chen's patch series and the latest Xen, you don't need to disable
> >>>> LK decompressor.
> >>>> Xen has a basic emulation for "stolen" UART.
> >>>
> >>> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
> >>
> >> Unfortunately, no. The UART emulation is too simple to handle the real driver.
> >> I'm currently preparing a patch series which will remove this hack in the DTS.
> >
> > Another question.
> >
> > Before I saw Linux booting message, there is a line of message:
> >
> > (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong CPUTargetList
> >
> > Is it a big issue for booting dom0?
>
> I don't think so. Linux is trying to send an SGI to a non-running VCPU.
>
> I'm curious to know why Linux is trying to do this. Can you try to
> apply the patch below and paste dom0 output log?
>
FYI,
[ 1.139260] CPU: Testing write buffer coherency: ok
[ 1.140167] /cpus/cpu@0 missing clock-frequency property
[ 1.140181] /cpus/cpu@1 missing clock-frequency property
[ 1.140214] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 1.140245] Setting up static identity map for 0xc0511478 - 0xc05114d0
[ 1.143730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #19
[ 1.143766] [<c001b5ec>] (unwind_backtrace+0x0/0xf8) from [<c0017b90>] (show_stack+0x1)
[ 1.143786] [<c0017b90>] (show_stack+0x10/0x14) from [<c0506940>] (dump_stack+0x70/0x8)
[ 1.143806] [<c0506940>] (dump_stack+0x70/0x8c) from [<c02bca50>] (gic_raise_softirq+0)
[ 1.143823] [<c02bca50>] (gic_raise_softirq+0x64/0x70) from [<c00192f8>] (arch_send_wa)
[ 1.143844] [<c00192f8>] (arch_send_wakeup_ipi_mask+0x18/0x1c) from [<c002e6ec>] (omap)
[ 1.143860] [<c002e6ec>] (omap4_boot_secondary+0xf4/0x174) from [<c0018f78>] (__cpu_up)
[ 1.143877] [<c0018f78>] (__cpu_up+0x84/0x130) from [<c004408c>] (_cpu_up+0xd4/0x154)
[ 1.143894] [<c004408c>] (_cpu_up+0xd4/0x154) from [<c0044184>] (cpu_up+0x5c/0x84)
[ 1.143916] [<c0044184>] (cpu_up+0x5c/0x84) from [<c0740ba4>] (smp_init+0x9c/0xd4)
[ 1.143935] [<c0740ba4>] (smp_init+0x9c/0xd4) from [<c072789c>] (kernel_init_freeable+)
[ 1.143954] [<c072789c>] (kernel_init_freeable+0x70/0x1c4) from [<c0501d2c>] (kernel_i)
[ 1.143972] [<c0501d2c>] (kernel_init+0x8/0xe4) from [<c0013f48>] (ret_from_fork+0x14/)
[ 2.152167] CPU1: failed to come online
[ 2.152516] Brought up 1 CPUs
[ 2.152527] SMP: Total of 1 processors activated (12.28 BogoMIPS).
[ 2.152535] CPU: All CPU(s) started in SVC mode.
Cheers,
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 9:47 ` Chen Baozi
@ 2013-08-15 10:07 ` Julien Grall
2013-08-15 10:54 ` Andrii Anisov
2013-08-15 10:59 ` Chen Baozi
0 siblings, 2 replies; 39+ messages in thread
From: Julien Grall @ 2013-08-15 10:07 UTC (permalink / raw)
To: Chen Baozi; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On 15 August 2013 10:47, Chen Baozi <baozich@gmail.com> wrote:
> On Thu, Aug 15, 2013 at 10:13:15AM +0100, Julien Grall wrote:
>> On 14 August 2013 13:38, Chen Baozi <baozich@gmail.com> wrote:
>> >
>> > On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> >
>> >> On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
>> >>>
>> >>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
>> >>>
>> >>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>> >>>>> disable printings from LK decompressor (it writes directly to omap debug
>> >>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>> >>>>> abort)
>> >>>>
>> >>>> With Chen's patch series and the latest Xen, you don't need to disable
>> >>>> LK decompressor.
>> >>>> Xen has a basic emulation for "stolen" UART.
>> >>>
>> >>> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
>> >>
>> >> Unfortunately, no. The UART emulation is too simple to handle the real driver.
>> >> I'm currently preparing a patch series which will remove this hack in the DTS.
>> >
>> > Another question.
>> >
>> > Before I saw Linux booting message, there is a line of message:
>> >
>> > (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong CPUTargetList
>> >
>> > Is it a big issue for booting dom0?
>>
>> I don't think so. Linux is trying to send an SGI to a non-running VCPU.
>>
>> I'm curious to know why Linux is trying to do this. Can you try to
>> apply the patch below and paste dom0 output log?
>>
>
> FYI,
>
> [ 1.139260] CPU: Testing write buffer coherency: ok
> [ 1.140167] /cpus/cpu@0 missing clock-frequency property
> [ 1.140181] /cpus/cpu@1 missing clock-frequency property
> [ 1.140214] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [ 1.140245] Setting up static identity map for 0xc0511478 - 0xc05114d0
> [ 1.143730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #19
> [ 1.143766] [<c001b5ec>] (unwind_backtrace+0x0/0xf8) from [<c0017b90>] (show_stack+0x1)
> [ 1.143786] [<c0017b90>] (show_stack+0x10/0x14) from [<c0506940>] (dump_stack+0x70/0x8)
> [ 1.143806] [<c0506940>] (dump_stack+0x70/0x8c) from [<c02bca50>] (gic_raise_softirq+0)
> [ 1.143823] [<c02bca50>] (gic_raise_softirq+0x64/0x70) from [<c00192f8>] (arch_send_wa)
> [ 1.143844] [<c00192f8>] (arch_send_wakeup_ipi_mask+0x18/0x1c) from [<c002e6ec>] (omap)
> [ 1.143860] [<c002e6ec>] (omap4_boot_secondary+0xf4/0x174) from [<c0018f78>] (__cpu_up)
> [ 1.143877] [<c0018f78>] (__cpu_up+0x84/0x130) from [<c004408c>] (_cpu_up+0xd4/0x154)
> [ 1.143894] [<c004408c>] (_cpu_up+0xd4/0x154) from [<c0044184>] (cpu_up+0x5c/0x84)
> [ 1.143916] [<c0044184>] (cpu_up+0x5c/0x84) from [<c0740ba4>] (smp_init+0x9c/0xd4)
> [ 1.143935] [<c0740ba4>] (smp_init+0x9c/0xd4) from [<c072789c>] (kernel_init_freeable+)
> [ 1.143954] [<c072789c>] (kernel_init_freeable+0x70/0x1c4) from [<c0501d2c>] (kernel_i)
> [ 1.143972] [<c0501d2c>] (kernel_init+0x8/0xe4) from [<c0013f48>] (ret_from_fork+0x14/)
> [ 2.152167] CPU1: failed to come online
> [ 2.152516] Brought up 1 CPUs
> [ 2.152527] SMP: Total of 1 processors activated (12.28 BogoMIPS).
> [ 2.152535] CPU: All CPU(s) started in SVC mode.
Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
bring up the CPU with omap callbacks which is wrong.
Did you add a PSCI node in your device tree?
psci {
compatible = "arm,psci";
method = "hvc";
cpu_on = <2>;
};
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 10:07 ` Julien Grall
@ 2013-08-15 10:54 ` Andrii Anisov
2013-08-15 11:00 ` Chen Baozi
2013-08-15 10:59 ` Chen Baozi
1 sibling, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-15 10:54 UTC (permalink / raw)
To: Julien Grall; +Cc: Chen Baozi, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 413 bytes --]
> Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
> bring up the CPU with omap callbacks which is wrong.
>
> Did you add a PSCI node in your device tree?
> psci {
> compatible = "arm,psci";
> method = "hvc";
> cpu_on = <2>;
> };
>
>
I'm not sure this will work for OMAP kernel.
On our side we skipped guests SMP so far.
*Sincerely,*
*Andrii Anisov*
[-- Attachment #1.2: Type: text/html, Size: 817 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 10:54 ` Andrii Anisov
@ 2013-08-15 11:00 ` Chen Baozi
2013-08-15 11:07 ` Andrii Anisov
0 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 11:00 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 15, 2013, at 6:54 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>
> Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
> bring up the CPU with omap callbacks which is wrong.
>
> Did you add a PSCI node in your device tree?
> psci {
> compatible = "arm,psci";
> method = "hvc";
> cpu_on = <2>;
> };
>
>
> I'm not sure this will work for OMAP kernel.
Andrii, it works!
> On our side we skipped guests SMP so far.
>
> Sincerely,
> Andrii Anisov
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 11:00 ` Chen Baozi
@ 2013-08-15 11:07 ` Andrii Anisov
0 siblings, 0 replies; 39+ messages in thread
From: Andrii Anisov @ 2013-08-15 11:07 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 815 bytes --]
On Thu, Aug 15, 2013 at 2:00 PM, Chen Baozi <baozich@gmail.com> wrote:
>
> On Aug 15, 2013, at 6:54 PM, Andrii Anisov <andrii.anisov@globallogic.com>
> wrote:
>
> >
> > Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
> > bring up the CPU with omap callbacks which is wrong.
> >
> > Did you add a PSCI node in your device tree?
> > psci {
> > compatible = "arm,psci";
> > method = "hvc";
> > cpu_on = <2>;
> > };
> >
> >
> > I'm not sure this will work for OMAP kernel.
>
> Andrii, it works!
>
> > On our side we skipped guests SMP so far.
> >
> > Sincerely,
> > Andrii Anisov
>
It's good to know it works on your site.
We are playing around 3.8 as Dom0 and Android 3.4 as DomU. I will check the
stuff later on my table.
*Sincerely,*
*Andrii Anisov*
[-- Attachment #1.2: Type: text/html, Size: 1463 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 10:07 ` Julien Grall
2013-08-15 10:54 ` Andrii Anisov
@ 2013-08-15 10:59 ` Chen Baozi
2013-08-15 12:24 ` Ian Campbell
1 sibling, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 10:59 UTC (permalink / raw)
To: Julien Grall; +Cc: Ian Campbell, Andrii Anisov, xen-devel
On Aug 15, 2013, at 6:07 PM, Julien Grall <julien.grall@linaro.org> wrote:
> On 15 August 2013 10:47, Chen Baozi <baozich@gmail.com> wrote:
>> On Thu, Aug 15, 2013 at 10:13:15AM +0100, Julien Grall wrote:
>>> On 14 August 2013 13:38, Chen Baozi <baozich@gmail.com> wrote:
>>>>
>>>> On Aug 14, 2013, at 5:55 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>>
>>>>> On 14 August 2013 10:46, Chen Baozi <baozich@gmail.com> wrote:
>>>>>>
>>>>>> On Aug 13, 2013, at 5:58 PM, Julien Grall <julien.grall@linaro.org> wrote:
>>>>>>
>>>>>>> On 13 August 2013 10:36, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>>>>>>>> disable printings from LK decompressor (it writes directly to omap debug
>>>>>>>> UART3, and if you give it to xen and don't map to Dom0 - will have data
>>>>>>>> abort)
>>>>>>>
>>>>>>> With Chen's patch series and the latest Xen, you don't need to disable
>>>>>>> LK decompressor.
>>>>>>> Xen has a basic emulation for "stolen" UART.
>>>>>>
>>>>>> BTW, does it mean that we don't need to set the UART status "disabled" in DTS?
>>>>>
>>>>> Unfortunately, no. The UART emulation is too simple to handle the real driver.
>>>>> I'm currently preparing a patch series which will remove this hack in the DTS.
>>>>
>>>> Another question.
>>>>
>>>> Before I saw Linux booting message, there is a line of message:
>>>>
>>>> (XEN) vgic.c:435:d0 vGICD: GICD_SGIR write r=fe0000 vcpu_mask=fe, wrong CPUTargetList
>>>>
>>>> Is it a big issue for booting dom0?
>>>
>>> I don't think so. Linux is trying to send an SGI to a non-running VCPU.
>>>
>>> I'm curious to know why Linux is trying to do this. Can you try to
>>> apply the patch below and paste dom0 output log?
>>>
>>
>> FYI,
>>
>> [ 1.139260] CPU: Testing write buffer coherency: ok
>> [ 1.140167] /cpus/cpu@0 missing clock-frequency property
>> [ 1.140181] /cpus/cpu@1 missing clock-frequency property
>> [ 1.140214] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
>> [ 1.140245] Setting up static identity map for 0xc0511478 - 0xc05114d0
>> [ 1.143730] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc3+ #19
>> [ 1.143766] [<c001b5ec>] (unwind_backtrace+0x0/0xf8) from [<c0017b90>] (show_stack+0x1)
>> [ 1.143786] [<c0017b90>] (show_stack+0x10/0x14) from [<c0506940>] (dump_stack+0x70/0x8)
>> [ 1.143806] [<c0506940>] (dump_stack+0x70/0x8c) from [<c02bca50>] (gic_raise_softirq+0)
>> [ 1.143823] [<c02bca50>] (gic_raise_softirq+0x64/0x70) from [<c00192f8>] (arch_send_wa)
>> [ 1.143844] [<c00192f8>] (arch_send_wakeup_ipi_mask+0x18/0x1c) from [<c002e6ec>] (omap)
>> [ 1.143860] [<c002e6ec>] (omap4_boot_secondary+0xf4/0x174) from [<c0018f78>] (__cpu_up)
>> [ 1.143877] [<c0018f78>] (__cpu_up+0x84/0x130) from [<c004408c>] (_cpu_up+0xd4/0x154)
>> [ 1.143894] [<c004408c>] (_cpu_up+0xd4/0x154) from [<c0044184>] (cpu_up+0x5c/0x84)
>> [ 1.143916] [<c0044184>] (cpu_up+0x5c/0x84) from [<c0740ba4>] (smp_init+0x9c/0xd4)
>> [ 1.143935] [<c0740ba4>] (smp_init+0x9c/0xd4) from [<c072789c>] (kernel_init_freeable+)
>> [ 1.143954] [<c072789c>] (kernel_init_freeable+0x70/0x1c4) from [<c0501d2c>] (kernel_i)
>> [ 1.143972] [<c0501d2c>] (kernel_init+0x8/0xe4) from [<c0013f48>] (ret_from_fork+0x14/)
>> [ 2.152167] CPU1: failed to come online
>> [ 2.152516] Brought up 1 CPUs
>> [ 2.152527] SMP: Total of 1 processors activated (12.28 BogoMIPS).
>> [ 2.152535] CPU: All CPU(s) started in SVC mode.
>
> Xen uses PSCI to bring up secondary VCPU. It seems Linux is trying to
> bring up the CPU with omap callbacks which is wrong.
>
> Did you add a PSCI node in your device tree?
> psci {
> compatible = "arm,psci";
> method = "hvc";
> cpu_on = <2>;
> };
Oops, that is the point. I didn't add it. And it would be OK after adding.
Thanks.
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 10:59 ` Chen Baozi
@ 2013-08-15 12:24 ` Ian Campbell
2013-08-15 12:43 ` Julien Grall
0 siblings, 1 reply; 39+ messages in thread
From: Ian Campbell @ 2013-08-15 12:24 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Stefano Stabellini, Andrii Anisov, xen-devel
On Thu, 2013-08-15 at 18:59 +0800, Chen Baozi wrote:
> > Did you add a PSCI node in your device tree?
> > psci {
> > compatible = "arm,psci";
> > method = "hvc";
> > cpu_on = <2>;
> > };
>
> Oops, that is the point. I didn't add it. And it would be OK after adding.
I really thought we added this automatically, Stefano did you not do
that when you implemented this stuff?
I suppose not because I'm not seeing it in
xen/arch/arm/domain_build.c:write_properties which is where I would have
thought it would live.
Ian.
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 12:24 ` Ian Campbell
@ 2013-08-15 12:43 ` Julien Grall
0 siblings, 0 replies; 39+ messages in thread
From: Julien Grall @ 2013-08-15 12:43 UTC (permalink / raw)
To: Ian Campbell
Cc: Chen Baozi, Julien Grall, Stefano Stabellini, Andrii Anisov, xen-devel
On 08/15/2013 01:24 PM, Ian Campbell wrote:
> On Thu, 2013-08-15 at 18:59 +0800, Chen Baozi wrote:
>
>>> Did you add a PSCI node in your device tree?
>>> psci {
>>> compatible = "arm,psci";
>>> method = "hvc";
>>> cpu_on = <2>;
>>> };
>>
>> Oops, that is the point. I didn't add it. And it would be OK after adding.
>
> I really thought we added this automatically, Stefano did you not do
> that when you implemented this stuff?
I have a patch series which automatically add the PSCI node. It's part
of device tree editing.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 9:55 ` Julien Grall
2013-08-14 12:38 ` Chen Baozi
@ 2013-08-14 16:07 ` Andrii Anisov
2013-08-14 19:47 ` Julien Grall
1 sibling, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-14 16:07 UTC (permalink / raw)
To: Julien Grall; +Cc: Chen Baozi, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 437 bytes --]
>
> > BTW, does it mean that we don't need to set the UART status "disabled"
> in DTS?
>
> Unfortunately, no. The UART emulation is too simple to handle the real
> driver.
> I'm currently preparing a patch series which will remove this hack in the
> DTS.
>
Julien,
As per 4.3 release "status=disabled" is not handled at all.
I have a patch for it. I'm not sure if somebody have pushed something
similar yet.
Sincerely,
Andrii Anisov.
[-- Attachment #1.2: Type: text/html, Size: 822 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 16:07 ` Andrii Anisov
@ 2013-08-14 19:47 ` Julien Grall
0 siblings, 0 replies; 39+ messages in thread
From: Julien Grall @ 2013-08-14 19:47 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Chen Baozi, Ian Campbell, xen-devel
On 14 August 2013 17:07, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>> > BTW, does it mean that we don't need to set the UART status "disabled"
>> > in DTS?
>>
>> Unfortunately, no. The UART emulation is too simple to handle the real
>> driver.
>> I'm currently preparing a patch series which will remove this hack in the
>> DTS.
>
>
> Julien,
>
> As per 4.3 release "status=disabled" is not handled at all.
> I have a patch for it. I'm not sure if somebody have pushed something
> similar yet.
Actually I have completely rewrote device tree creation for dom0.
Instead of browsing the Flat Device Tree, it uses the tree structure
(defined via struct dt_device_node). It's simpler to add/remove
node from the dom0 device tree.
Cheers,
--
Julien Grall
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-13 9:36 ` Andrii Anisov
2013-08-13 9:40 ` Chen Baozi
2013-08-13 9:58 ` Julien Grall
@ 2013-08-14 9:53 ` Chen Baozi
2013-08-14 16:03 ` Andrii Anisov
2 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-14 9:53 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 13, 2013, at 5:36 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> Chen,
>
> So I think I have to implement a .specific_mapping such as
> exynos5_specific_mapping in arch/arm/platforms/exynos5.c?
>
> I gave this hint a few messages ago in this thread ;)
>
> Just one more question. Read from OMAP5 datasheet, its IO memory address
> space ranges from 0 to 2G (with holes of course). Do I have to map all
> of them?
>
> It really depends on what you want to achieve.
> If you need things up and running ASAP - just map all the range. But mention following:
> • exclude GIC range
> • exclude your xen console UART range
> Other hints:
> • set kernel console to hvc0
> • disable printings from LK decompressor (it writes directly to omap debug UART3, and if you give it to xen and don't map to Dom0 - will have data abort)
> BTW, have you got CPU1 brought up by XEN?
>
> Sincerely,
> Andrii Anisov
Andrii,
Did you face any mmc problem when booting dom0?
After I did some io mappings, I could finally get Linux kernel booting message now. But it seems it still has some problems with mmc0:
mmc0: unrecognised SCR structure version 1
mmc0: error -22 whilst initializing SD card
...
Any ideas?
Cheers,
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 9:53 ` Chen Baozi
@ 2013-08-14 16:03 ` Andrii Anisov
2013-08-15 2:31 ` Chen Baozi
0 siblings, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-14 16:03 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 459 bytes --]
>
> Did you face any mmc problem when booting dom0?
>
> After I did some io mappings, I could finally get Linux kernel booting
> message now. But it seems it still has some problems with mmc0:
>
> mmc0: unrecognised SCR structure version 1
> mmc0: error -22 whilst initializing SD card
>
Chen,
Make sure you have
CONFIG_MMC=y
CONFIG_MMC_OMAP_HS=y
in your linux config.
We faced something similar with LK 3.8 omap2plus_defconfig.
Sincerely,
Andrii Anisov.
[-- Attachment #1.2: Type: text/html, Size: 849 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-14 16:03 ` Andrii Anisov
@ 2013-08-15 2:31 ` Chen Baozi
2013-08-15 7:37 ` Chen Baozi
0 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 2:31 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 15, 2013, at 12:03 AM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> Did you face any mmc problem when booting dom0?
>
> After I did some io mappings, I could finally get Linux kernel booting message now. But it seems it still has some problems with mmc0:
>
> mmc0: unrecognised SCR structure version 1
> mmc0: error -22 whilst initializing SD card
>
> Chen,
>
> Make sure you have
> CONFIG_MMC=y
> CONFIG_MMC_OMAP_HS=y
> in your linux config.
Yes, I have.
Actually, I ccan use this kernel to boot my board natively. So I think the driver is OK.
Cheers,
Baozi.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 2:31 ` Chen Baozi
@ 2013-08-15 7:37 ` Chen Baozi
2013-08-15 8:34 ` Andrii Anisov
2013-08-15 8:45 ` Andrii Anisov
0 siblings, 2 replies; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 7:37 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 15, 2013, at 10:31 AM, Chen Baozi <baozich@gmail.com> wrote:
>
> On Aug 15, 2013, at 12:03 AM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
>
>> Did you face any mmc problem when booting dom0?
>>
>> After I did some io mappings, I could finally get Linux kernel booting message now. But it seems it still has some problems with mmc0:
>>
>> mmc0: unrecognised SCR structure version 1
>> mmc0: error -22 whilst initializing SD card
>>
>> Chen,
>>
>> Make sure you have
>> CONFIG_MMC=y
>> CONFIG_MMC_OMAP_HS=y
>> in your linux config.
>
> Yes, I have.
>
> Actually, I ccan use this kernel to boot my board natively. So I think the driver is OK.
Seems I need to map more io memory... I mapped some more address. And it looks to have some positive effects when booting dom0, though still has some problem to open root device.
Curiously, why xen doesn't panic that I haven't mapped enough io memory?
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 7:37 ` Chen Baozi
@ 2013-08-15 8:34 ` Andrii Anisov
2013-08-15 8:51 ` Chen Baozi
2013-08-15 8:45 ` Andrii Anisov
1 sibling, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-15 8:34 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 411 bytes --]
Chen,
It looks you have problem with DMA.
I've checked your patches. You missed
+static uint32_t omap5_quirks(void)
+{
+ return PLATFORM_QUIRK_DOM0_MAPPING_11;
+}
In your omap5.c.
There is one more specific. OMAP5 has non ARM interconnect (it is L3
from Arteris), so physically have no IOMMU at all. In future, when xen will
support ARM IOMMU, omap5 will stick with hacks.
*Sincerely,*
*Andrii Anisov.*
[-- Attachment #1.2: Type: text/html, Size: 650 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 8:34 ` Andrii Anisov
@ 2013-08-15 8:51 ` Chen Baozi
2013-08-15 9:12 ` Andrii Anisov
0 siblings, 1 reply; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 8:51 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 15, 2013, at 4:34 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> Chen,
>
> It looks you have problem with DMA.
> I've checked your patches. You missed
>
> +static uint32_t omap5_quirks(void)
> +{
> + return PLATFORM_QUIRK_DOM0_MAPPING_11;
> +}
>
> In your omap5.c.
>
> There is one more specific. OMAP5 has non ARM interconnect (it is L3 from Arteris), so physically have no IOMMU at all. In future, when xen will support ARM IOMMU, omap5 will stick with hacks.
Aha, so it is! I used to wonder what the PLATFORM_QUIRK_DOM0_MAPPING_11 is used for, but never think of that in this problem.
Now I could ssh to the dom0 successfully.
Thanks a lot!
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 8:51 ` Chen Baozi
@ 2013-08-15 9:12 ` Andrii Anisov
2013-08-15 9:17 ` Chen Baozi
0 siblings, 1 reply; 39+ messages in thread
From: Andrii Anisov @ 2013-08-15 9:12 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 70 bytes --]
Chen,
Did you start Dom0 LK with SMP?
*Sincerely,*
*Andrii Anisov.*
[-- Attachment #1.2: Type: text/html, Size: 250 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 9:12 ` Andrii Anisov
@ 2013-08-15 9:17 ` Chen Baozi
0 siblings, 0 replies; 39+ messages in thread
From: Chen Baozi @ 2013-08-15 9:17 UTC (permalink / raw)
To: Andrii Anisov; +Cc: Julien Grall, Ian Campbell, xen-devel
On Aug 15, 2013, at 5:12 PM, Andrii Anisov <andrii.anisov@globallogic.com> wrote:
> Chen,
>
> Did you start Dom0 LK with SMP?
Actually, I didn't try to boot dom0 not with SMP. However, read from the log, the hypervisor did bring up 2 cpus, while the dom0 said not.
Cheers,
Baozi
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Domain 0 crashed when booting OMAP5 uEVM
2013-08-15 7:37 ` Chen Baozi
2013-08-15 8:34 ` Andrii Anisov
@ 2013-08-15 8:45 ` Andrii Anisov
1 sibling, 0 replies; 39+ messages in thread
From: Andrii Anisov @ 2013-08-15 8:45 UTC (permalink / raw)
To: Chen Baozi; +Cc: Julien Grall, Ian Campbell, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 541 bytes --]
Chen,
> Seems I need to map more io memory... I mapped some more address. And it
> looks to have some positive effects when booting dom0, though still has
> some problem to open root device.
>
> Curiously, why xen doesn't panic that I haven't mapped enough io memory?
>
This is very strange, all mappings are granted by second stage MMU in the
end, so you should have an exception accessing IOMEM you did not map.
Could you describe these positive effects you see?
Could it be you treat your results wrong?
*Sincerely,*
*Andrii Anisov.*
[-- Attachment #1.2: Type: text/html, Size: 965 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 39+ messages in thread