Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Jun 2003 17:38:28 -0700
From:      John-Mark Gurney <gurney_j@efn.org>
To:        ticso@cicely.de
Cc:        "M. Warner Losh" <imp@bsdimp.com>
Subject:   Re: PCI bus numbering and orphaned devices
Message-ID:  <20030611003828.GC39701@funkthat.com>
In-Reply-To: <20030610231649.GD26807@cicely12.cicely.de>
References:  <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> <20030610231649.GD26807@cicely12.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
Bernd Walter wrote this message on Wed, Jun 11, 2003 at 01:16 +0200:
> On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote:
> > So, the question is, does other arch's do something nasty like this
> > too?  Should I change the check to just do ofw_pci_find_node?  Is this
> > why pciconf -r is returning 0xffffffff when reading the ebus and firewire
> > parts of the SME2300BGA?  Simply because it isn't in the ofw tree?
> 
> Possible - in fact I was very surprised that a disabled device was not
> readable on some registers.
> We have a similar situation on alpha, where we get traps for reading non
> available devices.
> It's handled in that we tell the system to expect traps before accessing
> registers.
> This is done by reading with the badaddr function, which sets a flag for
> our trap handler so it can continue in case the device doesn't exist.
> badaddr() returns a flags which tells if reading was successfull.
> 
> > I don't have any data sheets or the PCI spec, so making heads or tails
> > of this is going be hard.
> 
> It's OK to get errors when reading locations that aren't available.
> Some chipsets nerver trap, others only trap for type2 access (behind
> Bridges) and some always trap.

It's amazing what reading the specs for a CPU can do.  The US-IIi
specificly has a section on this.  16.2.1 Probing PCI durning boot
using deferred errors.

Guess I'll be looking at implementing that.  Then we can get ride
of that ickyness in the psycho_read_config function.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030611003828.GC39701>