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."Received on Tue Jun 10 2003 - 16:16:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:11 UTC