Re: [XenARM] Problems when booting on OMAP5432 devboard

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-07-01 at 17:49 +0800, Chen Baozi wrote:
> On Jul 1, 2013, at 5:30 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > 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.
> Yes. And I found it happened even if reading the p[i].pt.base. I have
> tried to print the p[i].pt.base before updating its content. Then,
> all the early_printk would fail after it.

That's just weird. Any chance that reading/writing p[i]...base is
actually causing a fault of some description such that the following
prints never even get run?



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