On 16 Sep 2013, at 12:26, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote:
> On 16 September 2013 10:53, Tom Sutcliffe <tom.sutcliffe@xxxxxxxxxxx> wrote:
>> 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.
Ah well just a thought.
> 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.
Yes that does seem like the most sensible solution.
> 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.
That's good to know. In that case I'd vote for a few more slots on vexpress too - I've eaten three of the four just with disks, then there's framebuffers and balloon devices and such. If it is possible to raise it to 8 it would make thinks a bit easier to juggle while I'm sorting out the right minimal config. The error messages when you exceed the number of supported devices could be more descriptive too - you get a generic "No 'virtio-bus' bus found for device 'virtio-balloon-device'" type of message which prompted some head-scratching and experimentation to figure out.
> 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...
For vexpress the mmio nodes appear to go in address ascending order:
virtio_mmio@1c130000 {
interrupts = <0x0 0x28 0x1>;
interrupt-parent = <0x1>;
reg = <0x0 0x1c130000 0x0 0x200>;
compatible = "virtio,mmio";
};
virtio_mmio@1c130200 {
interrupts = <0x0 0x29 0x1>;
interrupt-parent = <0x1>;
reg = <0x0 0x1c130200 0x0 0x200>;
compatible = "virtio,mmio";
};
virtio_mmio@1c130400 {
interrupts = <0x0 0x2a 0x1>;
interrupt-parent = <0x1>;
reg = <0x0 0x1c130400 0x0 0x200>;
compatible = "virtio,mmio";
};
virtio_mmio@1c130600 {
interrupts = <0x0 0x2b 0x1>;
interrupt-parent = <0x1>;
reg = <0x0 0x1c130600 0x0 0x200>;
compatible = "virtio,mmio";
};
And for virt, they are descending:
virtio_mmio@2003e00 {
interrupts = <0x0 0x2f 0x1>;
reg = <0x0 0x2003e00 0x0 0x200>;
compatible = "virtio,mmio";
};
virtio_mmio@2003c00 {
interrupts = <0x0 0x2e 0x1>;
reg = <0x0 0x2003c00 0x0 0x200>;
compatible = "virtio,mmio";
};
virtio_mmio@2003a00 {
interrupts = <0x0 0x2d 0x1>;
reg = <0x0 0x2003a00 0x0 0x200>;
compatible = "virtio,mmio";
};
virtio_mmio@2003800 {
interrupts = <0x0 0x2c 0x1>;
reg = <0x0 0x2003800 0x0 0x200>;
compatible = "virtio,mmio";
};
... etc for another 28 entries
So I assume that means that the kernel is reading them in reverse order too. A quick skim of the kernel source and I'm none the wiser.
Cheers,
Tom
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
