Re: [Xen-devel] Problems running Xen 4.4 on OMAP5432 evm

["Kapania, Ashish" <akapania@xxxxxx>]

> -----Original Message-----
> From: Chen Baozi [mailto:baozich@xxxxxxxxx]
> Sent: Tuesday, April 29, 2014 8:19 PM
> To: Kapania, Ashish
> Cc: Julien Grall; Ian Campbell; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] Problems running Xen 4.4 on OMAP5432 evm
> 
> 
> On Apr 28, 2014, at 20:16, Chen Baozi <baozich@xxxxxxxxx> wrote:
> 
> >
> > On Apr 27, 2014, at 14:30, Kapania, Ashish <akapania@xxxxxx> wrote:
> >
> >> Hi Baozi,
> >>
> >> I managed to resolve the issue of dom0 aborting. The linux kernel I
> >> am using (v3.8.13 that comes with TI's GLSDK) had "zreladdr" set to
> >> 0x80008000 which was causing the kernel to load the page table at
> >> 0x80004000 (address not mapped by xen stage2 mmu table). To fix the
> >> issue, I enabled "CONFIG_AUTO_ZRELADDR" in the config and loaded the
> >> kernel image to 0xC0800000.This moved the page table from 0x80004000
> >> to 0xCxxxxxxx address range which is mapped by xen.
> >
> > I test with the following u-boot cmd:
> >
> > # fatload mmc 0:1 0x825f0000 <dtb-name> # fatload mmc 0:1 0x90000000
> > <xen uImage name> # fatload mmc 0:1 0xa0000000 <dom0 zImage name> #
> > bootm 0x90000000 - 0x825f0000
> >
> > Note that the address zImage loaded to should be the same as the
> > address written in chosen node of DT. And xen image should be 2MiB
> aligned.
> >
> >>
> >> Dom0 no longer aborts but the kernel is now stuck in the
> __delay_loop
> >> function. It never returns. Ian pointed me to an email from you on
> >> the mailing list
> >> (http://lists.xen.org/archives/html/xen-devel/2014-04/msg02620.html)
> >> where you recommended to disable UART port in the kernel for OMAP5.
> >> I am not doing that and was wondering if that could be causing the
> >> kernel to hang ? Could you provide more details on what exactly do I
> >> need to change in the kernel to disable UART port ?
> >
> > The reason to disable UART3 hwmod is that the hypervisor won't map
> the
> > corresponding io memory address for dom0 because the UART is taken by
> > itself. If the dom0 kernel doesn't use hwmod (only use FDT),
> > everything would work fine. Because Xen removes the corresponding
> UART
> > node in the DT passed to dom0. However, since hwmod structure is used
> > in OMAP kernel, the dom0 would still try to write the UART's IO
> > address space hard-coded in the hwmod structure, which could lead
> kernel panic.
> > One of the ugly hack is to remove corresponding     structure in
> > omap54xx_hwmod_ocp_ifs (arch/arm/mach-omap2/omap_hwmod_54xx_data.c).
> > I should say I'm still not very familiar with omap kernel and have no
> > idea whether there would be more elegant ways to solve this problem.
> 
> Just found that in the upstream kernel, there is no such issue. So
> there is no need to disable hwmod manually in the kernel source if
> using the latest upstream kernel :)
> 

Nice, so I only need to make the DTS changes (to mmc, mcbsp, etc.) as per your 
wiki ? I will try using the latest upstream kernel. Thanks for all the help.

Best,
Ashish

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel