Domain 0 crashed when booting OMAP5 uEVM

Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

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
(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
(XEN) CPSR:   a00001d3 MODE:32-bit Guest SVC
(XEN)      R0: 00000001 R1: 00000700 R2: fce06704 R3: fce06000
(XEN)      R4: 00000001 R5: c0797920 R6: 000186a1 R7: c07db704
(XEN)      R8: c0807fd8 R9: c07ce850 R10:c07910a0 R11:c07910a0 R12:00000000
(XEN) USR: SP: 00000000 LR: 00000000
(XEN) SVC: SP: c0785f30 LR: c002daa8 SPSR:000001d3
(XEN) ABT: SP: c0806f8c LR: c0806f8c SPSR:00000000
(XEN) UND: SP: c0806f98 LR: c0806f98 SPSR:00000000
(XEN) IRQ: SP: c0806f80 LR: c0806f80 SPSR:00000000
(XEN) FIQ: SP: 00000000 LR: 00000000 SPSR:00000000
(XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000
(XEN) 
(XEN)      SCTLR: 10c5387d
(XEN)        TCR: 00000000
(XEN)      TTBR0: 000000008000406a
(XEN)      TTBR1: 000000008000406a
(XEN)       IFAR: 00000000, IFSR: 00000000
(XEN)       DFAR: 00000000, DFSR: 00000000
(XEN) 
(XEN)   VTCR_EL2: 80002558
(XEN)  VTTBR_EL2: 00010000fedfc000
(XEN) 
(XEN)  SCTLR_EL2: 30cd187f
(XEN)    HCR_EL2: 0000000000282835
(XEN)  TTBR0_EL2: 00000000feed2000
(XEN) 
(XEN)    ESR_EL2: 93800007
(XEN)  HPFAR_EL2: 00000000004ae060
(XEN)      HDFAR: fce06704
(XEN)      HIFAR: 00000000
(XEN) 
(XEN) No stack trace for 32-bit guest kernel-mode
(XEN) domain_crash_sync called from traps.c:1369
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.4-unstable  arm32  debug=y  Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     c0033410
(XEN) CPSR:   a00001d3 MODE:32-bit Guest SVC
(XEN)      R0: 00000001 R1: 00000700 R2: fce06704 R3: fce06000
(XEN)      R4: 00000001 R5: c0797920 R6: 000186a1 R7: c07db704
(XEN)      R8: c0807fd8 R9: c07ce850 R10:c07910a0 R11:c07910a0 R12:00000000
(XEN) USR: SP: 00000000 LR: 00000000
(XEN) SVC: SP: c0785f30 LR: c002daa8 SPSR:000001d3
(XEN) ABT: SP: c0806f8c LR: c0806f8c SPSR:00000000
(XEN) UND: SP: c0806f98 LR: c0806f98 SPSR:00000000
(XEN) IRQ: SP: c0806f80 LR: c0806f80 SPSR:00000000
(XEN) FIQ: SP: 00000000 LR: 00000000 SPSR:00000000
(XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000
(XEN) 
(XEN)      SCTLR: 10c5387d
(XEN)        TCR: 00000000
(XEN)      TTBR0: 000000008000406a
(XEN)      TTBR1: 000000008000406a
(XEN)       IFAR: 00000000, IFSR: 00000000
(XEN)       DFAR: 00000000, DFSR: 00000000
(XEN) 
(XEN)   VTCR_EL2: 80002558
(XEN)  VTTBR_EL2: 00010000fedfc000
(XEN) 
(XEN)  SCTLR_EL2: 30cd187f
(XEN)    HCR_EL2: 0000000000282835
(XEN)  TTBR0_EL2: 00000000feed2000
(XEN) 
(XEN)    ESR_EL2: 93800007
(XEN)  HPFAR_EL2: 00000000004ae060
(XEN)      HDFAR: fce06704
(XEN)      HIFAR: 00000000
(XEN) 
(XEN) No stack trace for 32-bit guest kernel-mode
(XEN) Domain 0 crashed: rebooting machine in 5 seconds.

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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. 

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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.

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Chen Baozi]

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 

Re: Domain 0 crashed when booting OMAP5 uEVM

[Andrii Anisov]

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

Re: Domain 0 crashed when booting OMAP5 uEVM

[Ian Campbell]

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.

Re: Domain 0 crashed when booting OMAP5 uEVM

[Julien Grall]

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