On Fri, Aug 09, 2013 at 09:13:47AM +0100, Jon Medhurst (Tixy) wrote: > 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. > We don't have support for emulating the virtualization extensions in QEMU, so it must be KVM on real hardware - using QEMU for device emulation. Any KVM testing we've done so far has been with -nographic to QEMU, and I don't think there has been a lot of interest in supporting graphics yet. > > > > > [ 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
