PCI range checking under qemu-system-sparc64
Mark Cave-Ayland
mark.cave-ayland at ilande.co.uk
Sun Sep 13 17:36:54 UTC 2015
On 13/09/15 03:21, Marius Strobl wrote:
>>> That's already unusual; real PCI-EBus-bridges have two memory
>>> BARs (although children may use I/O ports which are translated
>>> to memory resources upstream) rather than an I/O port and a
>>> memory one. However, the above actually should also work code-
>>> wise, iff the resource types are encoded correctly in the ranges
>>> table.
>>
>> While the QEMU PCI-ebus properties don't necessarily reflect a real
>> ultra2
>
> You probably mean Ultra5/10 here; Ultra2 are SBus- rather than PCI-
> based. Still, the machine QEMU emualtes only looks similar to a
> real Ultra5/10 from a 10 km distance ...
Ooops, yes.
>> , they should be consistent in terms of ranges as several patches
>> along those lines were required to enable NetBSD and OpenBSD to boot
>> under qemu-system-sparc64. For reference I've included the properties
>> from OpenBIOS below:
>>
>>
>> 0 > cd /pci/ ok
>> 0 > .properties
>> name "pci"
>> reg 000001fe 00000000 00000000 02000000
>> vendor-id 108e
>> device-id a000
>> revision-id 0
>> class-code 60000
>> min-grant 0
>> max-latency 0
>> devsel-speed 0
>> fast-back-to-back <empty>
>> 66mhz-capable <empty>
>> subsystem-vendor-id 1af4
>> subsystem-id 1100
>> cache-line-size 0
>> device_type "pci"
>> model "SUNW,sabre"
>> compatible {"pci108e,a000", "pciclass,0"}
>> #address-cells 3
>> #size-cells 2
>> #interrupt-cells 1
>> ranges -- 54 : 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 01 fe 01 00 00 00 00 00 00 00 02 00 00 00 01 00 00 00 00 00 00 00 00
>> 00 00 00 00 00 01 fe 02 00 00 00 00 00 00 00 00 01 00 00 02 00 00 00 00
>> 00 00 00 00 10 00 00 00 00 01 ff 00 10 00 00 00 00 00 00 10 00 00 00
>> virtual-dma -- 8 : c0 00 00 00 20 00 00 00
>> #virtual-dma-size-cells 1
>> #virtual-dma-addr-cells 1
>> no-streaming-cache <empty>
>> interrupts -- 10 : 00 00 07 f0 00 00 07 ee 00 00 07 ef 00
>> 00 07 e5
>> upa-portid 1f
>> bus-range -- 8 : 00 00 00 00 00 00 00 02
>> available -- 28 : 02 00 00 00 00 00 00 00 04 04 00 00 00
>> 00 00 00 0b fc 00 00 01 00 00 00 00 00 00 00 00 00 83 80 00 00 00 00 00
>> 00 7c 80
>> interrupt-map -- 30 : 00 00 20 00 00 00 00 00 00 00 00 00 00
>> 00 00 01 ff e2 b7 40 00 00 00 10 00 00 28 00 00 00 00 00 00 00 00 00 00
>> 00 00 01 ff e2 b7 40 00 00 00 14
>> interrupt-map-mask -- 10 : 00 00 f8 00 00 00 00 00 00 00 00 00 00
>> 00 00 07
>> ok
>> 0 > cd ebus ok
>> 0 > .properties
>> name "ebus"
>> vendor-id 108e
>> device-id 1000
>> revision-id 1
>> class-code 68000
>> min-grant 0
>> max-latency 0
>> devsel-speed 0
>> fast-back-to-back <empty>
>> 66mhz-capable <empty>
>> subsystem-vendor-id 1af4
>> subsystem-id 1100
>> cache-line-size a00
>> model "ebus"
>> compatible {"pci108e,1000", "pciclass,068000"}
>> #address-cells 2
>> #size-cells 1
>> #interrupt-cells 1
>> assigned-addresses -- 28 : 02 00 18 10 00 00 00 00 03 00 00 00 00
>> 00 00 00 01 00 00 00 01 00 18 14 00 00 00 00 00 00 40 00 00 00 00 00 00
>> 00 40 00
>> reg 00001800 00000000 00000000 00000000 00000000
>> 02001810 00000000 00000000 00000000 01000000
>> 01001814 00000000 00000000 00000000 00004000
>> interrupt-map -- 14 : 00 00 00 14 00 00 03 f8 00 00 00 01 ff
>> e1 b9 48 00 00 00 2b
>> interrupt-map-mask -- c : 00 00 01 ff ff ff ff ff 00 00 00 03
>> ranges -- 30 : 00 00 00 10 00 00 00 00 02 00 18 10 00
>> 00 00 00 00 00 00 00 01 00 00 00 00 00 00 14 00 00 00 00 01 00 18 14 00
>> 00 00 00 00 00 00 00 00 00 40 00
>> ok
>> 0 > cd su ok
>> 0 > .properties
>> name "su"
>> device_type "serial"
>> reg 00000014 000003f8 00000008
>> interrupts 1
>> ok
>>
>
> Okay, so the address of "su" actually is mapped to the I/O port space
> at the EBus bridge. Again that doesn't match any real machine but at
> least is consistent with the BAR setup QEMU employs on the PCI side.
Yes. It's to do with the way that OpenBIOS expects to access ioport X at
base + X which doesn't sit too well with the PCI-EBus bridge; at least
it would require some terrific special case hacks to get this working
correctly.
>> I wonder if the problem is the same as that in
>> https://reviews.freebsd.org/D2791 which is that some assumptions about
>> the device tree are hard-coded rather than being read and/or calculated
>> from the PROM properties?
>>
>
> The first generations of PCI-based sun4u machines don't adhere to
> the IEEE 1754-1994 bus binding specifications (on the other hand,
> I only ever got draft versions of these so I've no idea whether
> they went final). E450 are worst in that regard, closely followed
> by Ultra30. To that matter, even the interpretation of the ranges
> property for the PCI-ISA-bridges found in PCI-Express-based sun4u
> machines still doesn't follow the relevant bus binding document.
> Thus, assuming the behavior of real hardware built by Fujitsu and
> Sun - which includes distrusting knowingly incorrect OFW properties
> in quite a few occasions - in sparc64 bus code rather than basing
> it on the OFW standards generally is sane.
> That said, later device-tree-related code in FreeBSD/sparc64 is
> rather generic and has quite a few heuristics, which made things
> work out-of-the box on several models we didn't have access to
> ourselves. Actually, in some cases FreeBSD performed even better
> than Linux, Net- and OpenBSD did in that regard, i. e. while these
> latter needed changes, FreeBSD required none. This also is why -
> apparently - the FreeBSD kernel manages to attach the 16550 of
> QEMU as low-level console device, although the BAR layout of the
> PCI-EBus-bridge doesn't match any real hardware.
Whilst working with other OSs, what tends to happen is that the basic
kernel output gets sent via prom_printf() or similar which means that
you see the output fine until you switch to userspace and your console
driver kicks in. Now that may not be the case for FreeBSD but that's why
I'm keen to get the ebus device attach working first to eliminate this
as a possibility.
> However, looking at ebus(4), I've spotted a bug in the conversion
> to NEW_PCIB. Interested parties might want to give the attached
> patch a try. That bug definitely can lead to the problem seen with
> QEMU, I'm not sure it's the only one in that regard, though; I'm
> fairly certain in this case there's no problem with interpreting
> the device-tree involved, given that the same code is used for
> ISA busses which - at least in reality - unlike EBus ones use
> I/O port instead of memory space for the resources of devices
> such as UARTs etc. There could be other spots not prepared for
> EBus devices suddenly requesting SYS_RES_IOPORT, too, though.
Thank you! I'm the process of clearing out space to set everything up so
I would hope to be in place to start looking at this again in a couple
of weeks.
ATB,
Mark.
More information about the freebsd-sparc64
mailing list