PCI range checking under qemu-system-sparc64
Mark Cave-Ayland
mark.cave-ayland at ilande.co.uk
Mon Sep 7 21:13:56 UTC 2015
On 07/09/15 21:31, Marius Strobl wrote:
> On Sun, Sep 06, 2015 at 12:48:59PM +0000, Alexey Dokuchaev wrote:
>> On Sun, Sep 06, 2015 at 01:16:13PM +0100, Mark Cave-Ayland wrote:
>>> On 06/09/15 12:03, Alexey Dokuchaev wrote:
>>>> Mark did you have any success with getting the boot process further?
>>>
>>> Not really - due to changes with my job and involvment in GSoC this year
>>> then my QEMU SPARC64 work hasn't really progressed much :(
>>>
>>> I don't have my FreeBSD environment setup right now (due to OS upgrade)
>>> but can you post the console output for the boot as far as it gets with
>>> the current version of the patch applied?
>>
>> Last few lines:
>>
>> [...]
>> eeprom0: <EEPROM/clock> addr 0x1400002000-0x1400003fff on ebus0
>> eeprom0: cannot allocate resources
>> device_attach: eeprom0 attach returned 6
>> ebus0: <fdthree> addr 0 (no driver attached)
>> ebus0: <su> addr 0x14000003f8-0x14000003ff irq 43 (no driver attached)
>
> This suggests that there's something wrong with the emulation of
> the PCI-EBus-bridge (child space maps to a region not covered by
> the BARs, child space not covered by the mapping, wrong resource
> type in the ranges table or something like that), causing the
> allocation of child resources to fail as in the eeprom(4) case
> above. Such a problem would also explain why uart(4) doesn't try
> to attach to 'su' albeit it should: uart_bus_probe() already
> allocates the resource, failing silently if that doesn't work
> and, thus, causing uart_bus_attach() never to be called.
>
>> Full log available here:
>>
>> http://193.124.210.26/head-r287497-sparc64-qemu.log
>>
>> ebus0: <PCI-EBus2 bridge> port 0x4000-0x7fff mem 0x3000000-0x3ffffff at device 3.0 on pci0
>
> 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, 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
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?
ATB,
Mark.
More information about the freebsd-sparc64
mailing list