Re: [XenARM] Problems when booting on OMAP5432 devboard

[Chen Baozi <baozich@xxxxxxxxx>]

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. 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?



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