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.
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 #addrefHum ... 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=000000004ae06704Dom0 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: c0033410To help you, you can use "addr2line -e vmlinux address" to find the faulty line in linux. Where address is your pc. Cheers, -- Julien Grall
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> > > > - 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. * _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> > (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.* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
> 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
BTW, Chen, What kernel are trying to start as Dom0 on your Panda? *Sincerely,* *Andrii Anisov.* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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.
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. >
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
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* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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
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
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
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 AnisovAndrii, 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
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
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
> > 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
> > > 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. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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.
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
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.*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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.* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
Chen, Did you start Dom0 LK with SMP? *Sincerely,* *Andrii Anisov.* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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
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
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
> 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* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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
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* _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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.
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