Re: [XenARM] Problems when booting on OMAP5432 devboard

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-07-01 at 19:18 +0800, Chen Baozi wrote:
> On Jul 1, 2013, at 5:57 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> 
> > 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?
> Yes.

Random stab in the dark: are you loading the Xen binary at a 2MB aligned
address?

>  But it is OK if we don't access the its copy in "early boot misc" area. for 
> example:
> 
> 01 memcpy((void *) dest_va, _start, _end - _start);
> 02
> 03 p = (void *) boot_pgtable;
> 04 early_printk("p[%d].pt.base: 0x%lx\n", 0, (unsigned long)p[0].pt.base);
> 05
> 06 p = (void *) boot_pgtable + dest_va - (unsigned long)_start;
> 07 early_printk("hello 1?\n");
> 08 early_printk("p: 0x%lx\n", (unsigned long)p);
> 09 early_printk("hello 2?\n");
> 10 early_printk("p[%d].pt.base: 0x%lx\n", 0, (unsigned long)p[0].pt.base);
> 11 early_printk("hello 3?\n");
> 
> Output:
> 
> p[0].pt.base: 0x802cc
> hello 1?
> p: 0x6d2000
> hello 2?

So it is more than likely faulting on the access at 10. I don't suppose
you have a hardware debugger?

You device has 2GB RAM, what happens if you hack the DTS to say it only
has 1GB?

Ian.


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