|
From: jessica.allison.2012@xxxxxxxxxxx To: marc.zyngier@xxxxxxx Date: Tue, 21 Aug 2012 13:58:44 +0100 CC: kvmarm@xxxxxxxxxxxxxxxxxxxxx Subject: Re: Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree > Date: Tue, 21 Aug 2012 13:29:20 +0100 > From: marc.zyngier@xxxxxxx > To: jessica.allison.2012@xxxxxxxxxxx > CC: kvmarm@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: Boot fails with Unexpected/invalid #address-cells/#size-cells in device tree > > 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). I found the problem in the end - the patch didn't quite apply properly and I had to replace 1c1f0000.clcd with "mb:clcd" for the clk_lookup structs. Now it runs up the CLCD. Jess |
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
