Re: Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 21/08/12 12:51, Jessica Allison wrote:
> 
> 
> ________________________________
> From: jessica.allison.2012@xxxxxxxxxxx
> To: marc.zyngier@xxxxxxx
> Date: Tue, 21 Aug 2012 12:43:09 +0100
> CC: kvmarm@xxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree
> 
> 
> 
>> Date: Wed, 15 Aug 2012 16:54:35 +0100
>> From: marc.zyngier@xxxxxxx
>> To: jessica.allison.2012@xxxxxxxxxxx
>> CC: peter.maydell@xxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx
>> Subject: Re:  Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree
>>
>> On 15/08/12 16:32, Jessica Allison wrote:
>>>
>>>
>>>> Date: Wed, 15 Aug 2012 16:20:12 +0100
>>>> From: marc.zyngier@xxxxxxx
>>>> To: jessica.allison.2012@xxxxxxxxxxx
>>>> CC: peter.maydell@xxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx
>>>> Subject: Re:  Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree
>>>>
>>>> On 15/08/12 16:13, Jessica Allison wrote:
>>>>>
>>>>>
>>>>>> Date: Wed, 15 Aug 2012 16:06:49 +0100
>>>>>> From: marc.zyngier@xxxxxxx
>>>>>> To: peter.maydell@xxxxxxxxxx
>>>>>> CC: jessica.allison.2012@xxxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx
>>>>>> Subject: Re:  Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree
>>>>>>
>>>>>> On 15/08/12 15:50, Peter Maydell wrote:
>>>>>>> On 15 August 2012 15:45, Jessica Allison
>>>>>>> <jessica.allison.2012@xxxxxxxxxxx> wrote:
>>>>>>>> Yes, when I quickly remove that check in the code, it boots up just fine.
>>>>>>>
>>>>>>> Good (although we should probably do a proper fix and make sure
>>>>>>> we handle 64 bit sizes correctly in the following code).
>>>>>>>
>>>>>>>> Is there already a way to boot up a full graphical user environment on the
>>>>>>>> FastModel simulator with the KVM on ARM kernel?
>>>>>>>> I use
>>>>>>>> http://git.kernel.org/?p=linux/kernel/git/maz/arm-platforms.git;a=summary
>>>>>>>> for my kernel and the system boots fine into a root shell.
>>>>>>>> Is there a kernel driver for the LCD by now, and included in the device
>>>>>>>> tree?
>>>>>>>
>>>>>>> Graphics via the pl11x should work fine, but I don't think anybody has
>>>>>>> actually tested because the effect of stacking KVM on top of the Fast
>>>>>>> Model means it would run pretty slowly. Try getting it running with
>>>>>>> plain QEMU on x86 first, then the same kernel config should behave
>>>>>>> the same on KVM.
>>>>>>
>>>>>> Only the A9 tile code has some support for its private pl111. The new DT
>>>>>> code has no knowledge of the VE baseboard pl111. Not to mention the
>>>>>> HDLCD on TC1/TC2, which doesn't even have a driver.
>>>>>>
>>>>>> As mentioned in an email to Jessica a while ago, this bit is waiting for
>>>>>> a kind soul who'd actually cares about video output to pick it up...
>>>>>
>>>>> When my kernel boots with the rtsm_ve-cortex_a15x2.dts device tree I see the following error which, I assume, is related to the pl111 not working?
>>>>>
>>>>> clcd-pl11x: probe of 1c1f0000.clcd failed with error -22
>>>>
>>>> That's one of the many problems. I have a really ugly workaround in one
>>>> of my branches that allows the frame buffer to be used, but that patch
>>>> will not go anywhere near mainline:
>>>>
>>>> http://git.us.kernel.org/?p=linux/kernel/git/maz/arm-platforms.git;a=commitdiff;h=de81b299148b84548fe6c563d8d70dcfddf3145c;hp=edf2c53a89824cb5752d42b89997ae8bc96dcff8
>>>
>>> With that patch, I still get an error:
>>>
>>> clcd-pl11x mb:clcd: PL111 rev0 at 0x1c1f0000
>>> clcd-pl11x: probe of mb:clcd failed with error -2
>>
>> No idea. You'll have to trace it, I'm afraid.
> 
> I found what the problem is here.
> 
> This line in amba-clcd.c fails
> fb->clk = clk_get(&fb->dev->dev, NULL);
> 
> And I think when merging your patch I mixed up osc1_clk and osc2_clk. Why does CLCD use osc2_clk and not osc1_clk like other components?

CLCD on the MB *is* using OSC1. That's the CLCD clock, as described here:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0447f/CACEIGDJ.html

All the other peripherals are using the 24MHz reference clock (aka OSC2).

	M.
-- 
Jazz is not dead. It just smells funny...


_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm


[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux