PCI range checking under qemu-system-sparc64

Marius Strobl marius at alchemy.franken.de
Mon Sep 7 20:32:02 UTC 2015

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:
> 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


More information about the freebsd-sparc64 mailing list