On Fri, 2013-08-09 at 10:16 +0300, Riku Voipio wrote: > Hi, > > With the latest TC1 dts (hdlcd framebuffer and and memreserve at > 0xbf000000) from arm landing team git kvm boots to console. No > graphics, I don't know how the fallback to PL111 should work? When you say kvm, do you mean kvm on real hardware, or kvm on QEMU? If the latter, and QEMU doesn't have HDLCD, then the device-tree used shouldn't claim the hardware exists. However, I'd guess just disabling HDLCD in device-tree won't make the kernel fall-back to the motherboard CLCD, probably more device-tree hacks would be needed. -- Tixy > > [ 1.988746] hdlcd 2b000000.hdlcd: HDLCD: unknown product id: 0x0 > [ 1.990585] hdlcd: probe of 2b000000.hdlcd failed with error -22 > > Riku > > On 8 August 2013 17:19, Jon Medhurst (Tixy) <tixy@xxxxxxxxxx> wrote: > > On Thu, 2013-08-08 at 14:36 +0100, Jon Medhurst (Tixy) wrote: > >> On Thu, 2013-08-08 at 14:59 +0300, Riku Voipio wrote: > >> > On 7 August 2013 20:31, Christoffer Dall <christoffer.dall@xxxxxxxxxx> wrote: > >> > > On Wed, Aug 07, 2013 at 06:53:02PM +0200, Alexander Spyridakis wrote: > >> > >> On 7 August 2013 16:51, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > >> > >> > >> > >> > > I thought that vexpress-v2p-ca15-tc1.dtb was not meant to be used for a > >> > >> > > guest and that it can actually cause problems. > >> > >> > > >> > >> > It's the one I usually use in my tests... If there's a good reason > >> > >> > why we shouldn't be using it I'd be interested to know. > >> > >> > > >> > >> > >> > >> Thanks for clarifying this, I remember specifically not using > >> > >> vexpress-v2p-ca15-tc1.dtb from the arm-dts repository, back in 3.8 era and > >> > >> before. > >> > > > >> > > There was a time when this was out of sync with what the kernel > >> > > expected. At least vexpress-v2p-ca15-tc1.dtb from the kernel tree works > >> > > for me for both TCG and KVM with QEMU. > >> > > >> > I presume with "kernel tree" you mean mainline or something derived. I > >> > see the mainline kernel doesn't have the patch below: > >> > > >> > https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=commitdiff;h=a14098001cdcf6452f45dd9f0ade9961b94f5d6e > >> > > >> > That could explain why you can't reproduce it, if the mainline kernel > >> > doesn't initialize the hdlcd. > >> > > >> > Jon, are you sure the patch is correct? > >> > >> Errmmm.... > >> > >> > the mismatch between > >> > memreserve and framebuffer in the dtb look fishy. > >> > >> Does rather, and vexpress-v2p-ca15-tc1.dts has > >> > >> memory@80000000 { > >> device_type = "memory"; > >> reg = <0 0x80000000 0 0x40000000>; > >> }; > >> > >> So framebuffer = <0 0xff000000 0 0x01000000> is going to cause problems. > >> Shows how long it is since I last plugged in the TC1 CoreTile. > >> > >> TC2 has 2GB, so this probably crept in with some merge or cut'n'paste > >> foobar. > >> > >> I'll fix the patch in my tree, and dust off that TC1 :-) > > > > Real hardware works with a framebuffer at either 0xbf000000 or > > 0xff000000, I guess RAM is aliased at 0xc0000000. > > > > I'll fix this in the Linaro tree though. I assume the memblock_remove > > will fail if the address isn't in RAM leaving the top of memory subject > > to corruption when the kernel starts allocating memory already being > > used for the framebuffer. > > > > -- > > Tixy > > _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
