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
