Re: [XenARM] Problems when booting on OMAP5432 devboard

[Chen Baozi <baozich@xxxxxxxxx>]

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.

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