Re: [XenARM] Problems when booting on OMAP5432 devboard

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-07-01 at 17:19 +0800, Chen Baozi wrote:
> On Jul 1, 2013, at 4:50 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > On Mon, 2013-07-01 at 11:54 +0800, Chen Baozi wrote:
> >> On Thu, Jun 27, 2013 at 01:10:01PM +0100, Ian Campbell wrote:
> >>> On Thu, 2013-06-27 at 19:55 +0800, Chen Baozi wrote:
> >>>> Hi Ian,
> >>>> 
> >>>> After enabling the UART, I have been tring to finish the rest of booting.
> >>>> However, the output information stops at "Placing Xen at XXXX-XXXX" like
> >>>> following:
> >>>> 
> >>>> Starting kernel ...
> >>>> 
> >>>> - UART enabled -
> >>>> - CPU 00000000 booting -
> >>>> - Machine ID 00000ec1 -
> >>>> - Started in Hyp mode -
> >>>> - Zero BSS -
> >>>> - Setting up control registers -
> >>>> - Turning on paging -
> >>>> - Ready -
> >>>> RAM: 0000000080000000 - 00000000ffffffff
> >>>> 
> >>>> MODULE[1]: 00000000a0000000 - 00000000a0400000 
> >>>> Placing Xen at 0x00000000ffe00000-0x0000000100000000
> >>>> 
> >>>> What could be the most possible problem of this case?
> >>> 
> >>> This is a about the point where we would shift from early_printk to the
> >>> proper console driver, so I expect you simply don't have the console
> >>> setup.
> >>> 
> >> Hi Ian,
> >> 
> >> I guess that it might not all about console driver, because early_printk
> >> does not work properly just after we have updated "the copy of boot_pgtable
> >> to use the new paddrs" in setup_pagetables(). It seems that
> >> FIXMAP_ADDR(FIXMAP_CONSOLE) has been destroyed after the updating without
> >> being restored.
> > 
> > Hrm, I think the expectation is that the fixmap will be copied as part
> > of that and doesn't need (or receive) any additional fixups (see around
> > "Link in the fixmap pagetable"), but it is worth checking for sure.
> > 
> > You could probably profitably sprinkle some more early_print around the
> > place during that sequence for debugging purposes.
> That's exactly what I did just now. And it is interesting that
> early_printk doesn't work just after the updated boot_pgtable (p =
> (void *) boot_pgtable + dest_va - (unsigned long) _start;) has been
> accessed (e.g. access to p[i].pt.base).

How odd, that set of tables isn't even used until the call to WRITE_TTBR
several lines below! I'm pretty certain it isn't updating anything which
is live.

Unless perhaps the new destination overlaps the current location of Xen,
I bet we don't handle that case well...

Ian.


_______________________________________________
Xen-arm mailing list
Xen-arm@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm