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