Gihun Jung
2013-Apr-30 09:08 UTC
Data Abort while in booting when using Julien''s new patches on Arndale Board
Hello,
I am trying to boot Arndale board with Julien''s new XenARM patch
series.
But I have got "Data Abort" while in booting.
My environment is:
- Arndale Board
- Xen-4.3-unstable from branch "arm" in
git://xenbits.xen.org/people/julieng/xen-unstable.git
- Dom0 Kernel from branch "dev-arndale-dom0-3.9" in
git://xenbits.xen.org/people/julieng/linux-arm.git
I have found the causing "Data Abort" code while I am some debugging.
static int exynos5_specific_mapping(struct domain *d)
{
....snip....
p2m_populate_ram(d, 0x0, 0x1000 - 1);
res = gvirt_to_maddr(0, &ma);
...snip....
}
From above code, "gvirt_to_maddr" calls "gva_to_ma_par":
static inline uint64_t gva_to_ma_par(vaddr_t va)
{
uint64_t par, tmp;
tmp = READ_CP64(PAR);
WRITE_CP32(va, ATS12NSOPR);
isb(); /* Ensure result is available. */
par = READ_CP64(PAR);
WRITE_CP64(tmp, PAR);
return par;
}
When I have tired to debugging, I have found " WRITE_CP32(va,
ATS12NSOPR)[1]" that cause data abort. It seems [1] translates stage 1
and 2 MMU and returns PA corresponding input va.
Does anybody see same problem? I attach my log below:
=== log ==(XEN) /voltage-regulator nirq = 0 naddr = 0
(XEN) handle /fixedregulator@0
(XEN) /fixedregulator@0 nirq = 0 naddr = 0
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN) ----[ Xen-4.3-unstable arm32 debug=y Tainted: C ]----
(XEN) CPU: 0
(XEN) PC: 0024d78c exynos5_specific_mapping+0x30/0xf4
(XEN) CPSR: 2000015a MODE:Hypervisor
(XEN) R0: 00000000 R1: 00000000 R2: 00000000 R3: 00000000
(XEN) R4: 40011000 R5: 00000001 R6: 00000001 R7: 0028fb54
(XEN) R8: 00004d24 R9: 7fffa000 R10:00000000 R11:0028fad4 R12:80000001
(XEN) HYP: SP: 0028fab4 LR: 0024718c
(XEN)
(XEN) HTTBR bfed2000
(XEN) HDFAR 0
(XEN) HIFAR 0
(XEN) HPFAR 0
(XEN) HCR 00002835
(XEN) HSR 94000155
(XEN) VTTBR 0000000000
(XEN)
(XEN) DFSR 0 DFAR 0
(XEN) IFSR 0 IFAR 0
(XEN)
(XEN) Xen stack trace from sp=0028fab4:
(XEN) 0024d784 00000fff 00000000 00000001 00000001 0028fb54 40028000 0028fadc
(XEN) 0026850c 0028fee4 00243404 b0000000 00000000 00020000 00000000 00000000
(XEN) 40037f58 4003f000 0025c4b4 fffffd48 00255c90 00000008 40011000 00000001
(XEN) 00000001 00000000 00000000 10000000 00000000 50000000 00000000 00255b78
(XEN) 00000000 00255b38 00000001 7ffe0f08 0028fb5c 01000000 0f000000 080f0000
(XEN) 000000b0 00000200 00000000 00000000 2c6e6578 2d6e6578 00332e34 2c6e6578
(XEN) 006e6578 00000001 00000001 00000001 00000001 00000001 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000001 00000001 00000000 00000000 00000000 00000000 00000000
(XEN) 30303030 61303430 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 40028000 00000000 00000001 00000000 50000000 00000000 10000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 50000100 00000000 50008000
(XEN) 00000000 00000000 00000000 a0000000 00000000 50008000 00000000 001be4c0
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN) Xen call trace:
(XEN) [<0024d78c>] exynos5_specific_mapping+0x30/0xf4
(XEN) [<0026850c>] ???
(XEN) [<00243404>] construct_dom0+0x8d4/0xae4
(XEN) [<002690c0>] ???
(XEN) [<00200518>] puts+0x8/0x1c
Ian Campbell
2013-Apr-30 09:37 UTC
Re: Data Abort while in booting when using Julien''s new patches on Arndale Board
On Tue, 2013-04-30 at 10:08 +0100, Gihun Jung wrote:> static int exynos5_specific_mapping(struct domain *d) > { > > ....snip.... > p2m_populate_ram(d, 0x0, 0x1000 - 1); > > res = gvirt_to_maddr(0, &ma); > ...snip....Did you snip a check of the "res" from this? If the code just goes on to use the ma unconditionally then it could well fail I think.
Julien Grall
2013-Apr-30 16:36 UTC
Re: Data Abort while in booting when using Julien''s new patches on Arndale Board
On 04/30/2013 10:08 AM, Gihun Jung wrote:> Hello,Hello,> I am trying to boot Arndale board with Julien''s new XenARM patch series. > But I have got "Data Abort" while in booting.Thanks for trying my patch series :).> My environment is: > - Arndale Board > - Xen-4.3-unstable from branch "arm" in > git://xenbits.xen.org/people/julieng/xen-unstable.git > - Dom0 Kernel from branch "dev-arndale-dom0-3.9" in > git://xenbits.xen.org/people/julieng/linux-arm.gitThis is not related, but this branch doesn''t work. If you want to try Linux 3.9 I advise you use to "dev-arndale-dom0-3.9-rc4". I use this branch for my test. - DTS: arch/arm/boot/exynos5250-arndale.dts - config: arch/arm/configs/xen_dom0_arndale_defconfig I will add this tree on the wiki page as soon as possible.> I have found the causing "Data Abort" code while I am some debugging. > > static int exynos5_specific_mapping(struct domain *d) > { > > ....snip.... > p2m_populate_ram(d, 0x0, 0x1000 - 1); > > res = gvirt_to_maddr(0, &ma); > ...snip.... > } > > From above code, "gvirt_to_maddr" calls "gva_to_ma_par": > > static inline uint64_t gva_to_ma_par(vaddr_t va) > { > uint64_t par, tmp; > tmp = READ_CP64(PAR); > WRITE_CP32(va, ATS12NSOPR); > isb(); /* Ensure result is available. */ > par = READ_CP64(PAR); > WRITE_CP64(tmp, PAR); > return par; > } > > > When I have tired to debugging, I have found " WRITE_CP32(va, > ATS12NSOPR)[1]" that cause data abort. It seems [1] translates stage 1 > and 2 MMU and returns PA corresponding input va. > > Does anybody see same problem? I attach my log below:I have noticed this issue yesterday. The lines between p2m_populate_ram... and unmap_domain_page... should be removed. But there is another issue with linux 3.7. If you want to use this version you need to checkout "arndale" branch in my xen git. Otherwise you can use the branch "arm" with linux 3.9. Let me know if you have any issue with this patch series. Thanks, -- Julien
Gihun Jung
2013-May-02 02:46 UTC
Re: Data Abort while in booting when using Julien''s new patches on Arndale Board
2013/5/1 Julien Grall <julien.grall@citrix.com>:> This is not related, but this branch doesn''t work. If you want to try > Linux 3.9 I advise you use to "dev-arndale-dom0-3.9-rc4". I use this > branch for my test. > > - DTS: arch/arm/boot/exynos5250-arndale.dts > - config: arch/arm/configs/xen_dom0_arndale_defconfigI have tried "dev-arndale-dom0-3.9-rc4" and followed what you suggest. FYI, I am using the latest u-boot version from linaro-stable (git://git.linaro.org/git-ro/boot/u-boot-linaro-stable.git)> I have noticed this issue yesterday. The lines between > p2m_populate_ram... and unmap_domain_page... should be removed.I have removed it; available to go next step without data abort.> But there is another issue with linux 3.7. If you want to use > this version you need to checkout "arndale" branch in my xen git. > Otherwise you can use the branch "arm" with linux 3.9. > > Let me know if you have any issue with this patch series.But, I am still facing a problem to booting :( According to log, it seems to success to load the zImage to newly mapping area for dom0. It was not working; It was hang on Guest ABT In here, I have questions. When I used "1:1 mapping for dom0" from Anthony''s patch (i.e. that is removed and improved by your new patch series), Xen told me that it populated P2M for dom0 (i.e. mem size = 256M) from 0x40000000 - 0x50000000. It is exactly same start address of physical RAM of Arndale Board. Buy, in your patch series, it is in 0x50000000 - 0x60000000. Is it possible to be a cause of Data Abort? Please see attached log: (XEN) Brought up 2 CPUs (XEN) *** LOADING DOMAIN 0 *** (XEN) Device-tree contains "xen,xen" node. Ignoring. (XEN) Populate P2M 0x50000000->0x60000000 (1:1 mapping for dom0) (XEN) Loading kernel from boot module 1 ... many snips ... (XEN) Loading zImage from 00000000a0008000 to 0000000050008000-00000000503b5ea0 (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type ''CTRL-a'' three times to switch input to X) (XEN) Freed 224kB init memory. (XEN) *** Serial input -> Xen (type ''CTRL-a'' three times to switch input to DO) (XEN) ''d'' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU0 guest state (d0:v0): *** (XEN) ----[ Xen-4.3-unstable arm32 debug=y Tainted: C ]---- (XEN) CPU: 0 (XEN) PC: ffff000c (XEN) CPSR: 200001d7 MODE:32-bit Guest ABT (XEN) R0: c0b3b114 R1: 000000ff R2: c0e00000 R3: c0e00001 (XEN) R4: c0b3b114 R5: ffff308d R6: 0000085a R7: c0619c48 (XEN) R8: c06e88ac R9: c0b2e174 R10:c07f304c R11:00000000 R12:c0510dc4 (XEN) USR: SP: 00000000 LR: 00000000 (XEN) SVC: SP: c071dec0 LR: c03db50c SPSR:000001d3 (XEN) ABT: SP: c077c5cc LR: ffff0010 SPSR:200001d7 (XEN) UND: SP: c077c5d8 LR: c077c5d8 SPSR:00000000 (XEN) IRQ: SP: c077c5c0 LR: c077c5c0 SPSR:00000000 (XEN) FIQ: SP: 00000000 LR: 00000000 SPSR:00000000 (XEN) FIQ: R8: 00000000 R9: 00000000 R10:00000000 R11:00000000 R12:00000000 (XEN) (XEN) TTBR0 0050003000 TTBR1 0050007000 TCR b5023500 (XEN) SCTLR 30c5387d (XEN) IFAR ffff000c DFAR c0e00000 (XEN) (XEN) HTTBR bfed2000 (XEN) HDFAR 0 (XEN) HIFAR 0 (XEN) HPFAR 0 (XEN) HCR 00002835 (XEN) HSR 4a000000 (XEN) VTTBR 10000a040e000 (XEN) (XEN) DFSR 206 DFAR c0e00000 (XEN) IFSR 206 IFAR ffff000c (XEN) (XEN) GUEST STACK GOES HERE (XEN) (XEN) *** Dumping CPU1 host state: *** (XEN) ----[ Xen-4.3-unstable arm32 debug=y Tainted: C ]---- (XEN) CPU: 1 (XEN) PC: 00241b84 idle_loop+0x160/0x198 (XEN) CPSR: 6000015a MODE:Hypervisor (XEN) R0: 00000000 R1: 00000000 R2: 00000001 R3: 00000000 (XEN) R4: 002d7614 R5: 002d7614 R6: 002d7614 R7: 002d7614 (XEN) R8: 002d6308 R9: 80200000 R10:80000000 R11:40017f54 R12:ffffffff (XEN) HYP: SP: 40017f34 LR: 00226bdc (XEN) (XEN) HTTBR 60018000 (XEN) HDFAR 0 (XEN) HIFAR 0 (XEN) HPFAR 0 (XEN) HCR 00002835 (XEN) HSR 0 (XEN) VTTBR 0000000000 (XEN) (XEN) DFSR 0 DFAR 0 (XEN) IFSR 0 IFAR 0 (XEN) (XEN) Xen stack trace from sp=40017f34: (XEN) 00241b8c 40017f58 00000001 002d4298 e9920be5 3497a020 802d7700 40017f4 (XEN) 002481fc 00000000 00000000 00000000 00000000 00000000 00000000 0000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000000 (XEN) 00000000 00000000 00000000 (XEN) Xen call trace: (XEN) [<00241b84>] idle_loop+0x160/0x198 (XEN) [<002481fc>] start_secondary+0x14c/0x164 (XEN)
Julien Grall
2013-May-02 12:10 UTC
Re: Data Abort while in booting when using Julien''s new patches on Arndale Board
On 05/02/2013 03:46 AM, Gihun Jung wrote:> 2013/5/1 Julien Grall <julien.grall@citrix.com>: > >> This is not related, but this branch doesn''t work. If you want to try >> Linux 3.9 I advise you use to "dev-arndale-dom0-3.9-rc4". I use this >> branch for my test. >> >> - DTS: arch/arm/boot/exynos5250-arndale.dts >> - config: arch/arm/configs/xen_dom0_arndale_defconfig > > I have tried "dev-arndale-dom0-3.9-rc4" and followed what you suggest. > FYI, I am using the latest u-boot version from linaro-stable > (git://git.linaro.org/git-ro/boot/u-boot-linaro-stable.git) > >> I have noticed this issue yesterday. The lines between >> p2m_populate_ram... and unmap_domain_page... should be removed. > > I have removed it; available to go next step without data abort. > >> But there is another issue with linux 3.7. If you want to use >> this version you need to checkout "arndale" branch in my xen git. >> Otherwise you can use the branch "arm" with linux 3.9. >> >> Let me know if you have any issue with this patch series. > > But, I am still facing a problem to booting :( > According to log, it seems to success to load the zImage to newly > mapping area for dom0. > It was not working; It was hang on Guest ABT > > In here, I have questions. When I used "1:1 mapping for dom0" from > Anthony''s patch (i.e. that is removed and improved by your new patch > series), > Xen told me that it populated P2M for dom0 (i.e. mem size = 256M) from > 0x40000000 - 0x50000000. > It is exactly same start address of physical RAM of Arndale Board. > Buy, in your patch series, it is in 0x50000000 - 0x60000000. > Is it possible to be a cause of Data Abort?I don''t think so. I don''t see usefull things in the log, you need to enable more debug for linux. Could you apply this hacky patch on linux? diff --git a/kernel/printk.c b/kernel/printk.c index abbdd9e..6975215 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1652,6 +1652,8 @@ asmlinkage int printk_emit(int facility, int level, } EXPORT_SYMBOL(printk_emit); +void xen_raw_console_write(const char *buf); + /** * printk - print a kernel message * @fmt: format string @@ -1677,6 +1679,7 @@ asmlinkage int printk(const char *fmt, ...) { va_list args; int r; + static char buf[512]; #ifdef CONFIG_KGDB_KDB if (unlikely(kdb_trap_printk)) { @@ -1687,9 +1690,12 @@ asmlinkage int printk(const char *fmt, ...) } #endif va_start(args, fmt); - r = vprintk_emit(0, -1, NULL, 0, fmt, args); +// r = vprintk_emit(0, -1, NULL, 0, fmt, args); + r = vsnprintf(buf, sizeof(buf), fmt, args); va_end(args); + xen_raw_console_write(buf); + return r; } EXPORT_SYMBOL(printk); -- Julien