Re: PCI range checking under qemu-system-sparc64

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.

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64
To unsubscribe, send any mail to "[email protected]"