On 16 September 2013 10:53, Tom Sutcliffe <tom.sutcliffe@xxxxxxxxxxx> wrote: > I don't have much yet to comment on the patch itself, but I've > had it booting as successfully as the vexpress-a15 platform. > (There's a caveat there as my vexpress setup isn't exactly > perfect in the first place). The UART support is a great help > while debugging boot issues, although it occurs to me it would > be better still if the virt memory map placed it in the same location > as the vexpress-a15, which I assume might be enough to get the > earlyprintk CONFIG_DEBUG_VEXPRESS_UART0_RS1 option > to work. I realise this is a big old hack, and might not work anyway, > but it seems like it can only be a good thing to reduce the amount > of variation in how UARTs are setup across different platforms. Even vexpress TC1 (ie 2xA15) and TC2 (ie 2xA15+3xA7) put the UART in different places. I think the kernel folk should just sort out the earlyprintk mess so we can say in the device tree where the UART is and have it work. The kernel can't rely on compile-time deciding where it is, this just won't work in a multiple-boards-per-kernel world. > One issue I've found is that virt mounts drives in the opposite order > compared to the vexpress-a15. On vexpress-a15 I have to reverse > the order of the -device parameters when I use multiple virtio drives: > Whereas on virt they have to be in natural order: > I'd prefer to have vexpress behave like virt and have the first device > be the first on the command line, but if there's compatibility concerns > just having them both behave the same would be a start. That does seem like it would make sense... I cunningly stuck a note in the 1.6 release notes to the effect that the virtio-mmio in vexpress was still experimental status, so we're free to change it around a bit still. So I think the reason that the two platforms differ is that for vexpress-a15 I put in specific code to enumerate the virtio devices backwards so that they appear in the device tree in forwards order (since our "add node" code seems to put things in last-first for some reason). However presumably the kernel then scans them the other way round. Or maybe it's the dtc output that is confusing? If you flip the loop in vexpress.c:find_int_controller() it will probably make the vexpress command line work like virt. Can you use '-machine dumpdtb=file.dtb' in both cases to dump the dtb (qemu will just write to the file rather than starting) and have a look at it with dtc? (I'm not in a position to do this at the moment, I'm afraid.) It would be worth checking which order virt and vexpress-a15 are putting nodes in the device tree... -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
