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

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

> -----Original Message-----
> From: Kapania, Ashish
> Sent: Tuesday, April 29, 2014 9:43 PM
> To: 'Chen Baozi'
> Cc: Julien Grall; Ian Campbell; xen-devel@xxxxxxxxxxxxx
> Subject: RE: [Xen-devel] Problems running Xen 4.4 on OMAP5432 evm
> 
> > -----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

After moving to linux 3.15-rc3, making the DTS changes suggested on the
wiki and disabling a call to omap_smc1() in mach-omap2/timer.c, I was
able to boot dom0 successfully.

Best,
Ashish

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