Re: [XenARM] Problems when booting on OMAP5432 devboard

[Chen Baozi <baozich@xxxxxxxxx>]

On Jul 1, 2013, at 7:31 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

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

Bingo! Compared to Arndale board, OMAP5432 uEVM's RAM is not yet 
0x40000000~0xbfffffff, but 0x80000000~0xffffffff. After make the following 
change to DTS:

        memory {
                device_type = "memory"
-               reg = <0x80000000 0x80000000>; /* 2 GB */
+               reg = <0x80000000 0x40000000>; /* 1 GB */
        };

I can reach the output "Xen heap: 131072 pages  Dom heap: 131072 pages". 

Cheers,

Baozi.
> 
> Ian.
> 


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