pci probing "fixed" (was Re: PCI bus numbering and orphaned devices)
Well, I implemented PCI probing as per the UltraSparc IIi user's manual, and now, I get quite a bit more than I bargined for: bash-2.05b$ pciconf -l | wc 38 2283106 The complete pciconf -l -v is at: http://people.freebsd.org/~jmg/pciconf-lv.sparc64 Now, I seem to be getting duplicates on some functions, and then of course, I am now seeing the firewire part of the SME2300BGA that doesn't have a phys attached to it. (The driver does attach to the firewire part, but fails trying to talk to the phys.) This also required updating the pci_read_device to ignore a all zero return value for PCIR_DEVVENDOR, and not probe higher functions in that case. If I tried to probe higher functions (such as 0.0.2), the system would hang. A dmesg output of the boot is at: http://people.freebsd.org/~jmg/dmesg.sparc64 I don't include the dmesg that shows me attaching the firewire driver. I have posted the patch to produce this at: http://people.freebsd.org/~jmg/sparc.patch Warning, this contains much debugging data, and probes for PCI devices that previously didn't get probed for. P.S. Sorry for the duplicate post to -sparc64. I forgot that some of the -current crowd is interested in this work too. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
: > I'm thinking that the loop should be more like: : > : > pcifunchigh = 0; : > f = 0; : > hdrtype = REG(PCIR_HEADERTYPE, 1); : > if (hdrtype & 0x7f > 2) : > continue; : : My only complaint about this is that if no device is present in the : slot, won't you just get all bits set in whatever you read? If so, : the headertype check should be better bounded. hdrtype would be 0xff. 0xff & 0x7f is 0x7f, which is greater than 2. Sorry. Read the test backwards. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
In message: <[EMAIL PROTECTED]> "Justin T. Gibbs" <[EMAIL PROTECTED]> writes: : > I'm thinking that the loop should be more like: : > : > pcifunchigh = 0; : > f = 0; : > hdrtype = REG(PCIR_HEADERTYPE, 1); : > if (hdrtype & 0x7f > 2) : > continue; : : My only complaint about this is that if no device is present in the : slot, won't you just get all bits set in whatever you read? If so, : the headertype check should be better bounded. hdrtype would be 0xff. 0xff & 0x7f is 0x7f, which is greater than 2. What would the problem be? The only valid header types are 0, 1, and 2 (at least the only ones that we understand). Technically, if it is a header type we don't know, we're supposed to disable the device in the command register too. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
+*
+* If we don't hardware the bus down, pciconf gets confused.
*/
if (sc->secbus != 0) {
- child = device_add_child(dev, "pci", -1);
+ child = device_add_child(dev, "pci", sc->secbus);
if (child != NULL)
return (bus_generic_attach(dev));
} else
This one looks good, please commit. The comment above is outdated, so
it might be better to just remove it completely.
At least fix the typo in the comment if you aren't going to remove it.
--
Justin
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
I'm thinking that the loop should be more like: pcifunchigh = 0; f = 0; hdrtype = REG(PCIR_HEADERTYPE, 1); if (hdrtype & 0x7f > 2) continue; My only complaint about this is that if no device is present in the slot, won't you just get all bits set in whatever you read? If so, the headertype check should be better bounded. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Wed, Jun 11, 2003 at 04:26:27PM +0200, Thomas Moestl wrote: > On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > > Ok, the only problem is that is then we have the same problem the ACPI > > code does in that hot swapping cards would have a problem. Since it > > appears to me that the OFW tree doesn't get updated upon a swap. (At > > least the usb part of the tree doesn't.) > > We do not support hotplugging at the moment anyway. If a bridge driver > would implement that in the future without using any firmware support > however, it will then need to know everything information about the > interrupt routing required for its devices if it cannot use the > firmware for this. in that case, it can just prevent the ofw_pci bus > from attaching to it (this will be easily possible). > I'd hope that machines that support hot-plugging of PCI devices would > have firmware methods available to support that though. I have no clue about cardbus, but for PCI hotplugging you need hardware specific support to power down the slots. But hotplug PCI is not a realm of specific machines, as you can attach add-on hotplug frames to any PCI system. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Wed, 2003/06/11 at 08:34:39 -0600, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Thomas Moestl <[EMAIL PROTECTED]> writes: > : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > : > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > : > Ok, the only problem is that is then we have the same problem the ACPI > : > code does in that hot swapping cards would have a problem. Since it > : > appears to me that the OFW tree doesn't get updated upon a swap. (At > : > least the usb part of the tree doesn't.) > : > : We do not support hotplugging at the moment anyway. If a bridge driver > : would implement that in the future without using any firmware support > : however, it will then need to know everything information about the > : interrupt routing required for its devices if it cannot use the > : firmware for this. in that case, it can just prevent the ofw_pci bus > : from attaching to it (this will be easily possible). > : I'd hope that machines that support hot-plugging of PCI devices would > : have firmware methods available to support that though. > > We'll need to do so for the cardbus bridges. Yes, I was just speaking of PCI. > However, the interupt is routed to the bridge and has to be shared > with the cardbus/pccard cards. That should be far less of a problem with the new code, since it will make interrupt routing work right finally (right now, everything needs to be prerouted). > : > Does this mean that we should eliminate most of the Sun specific pci > : > bus drivers in favor of OFW specific ones like ACPI? or? > : > : No, it means introducing an OFW bus driver, which uses the firmware to > : enumerate the devices and to support interrupt routing. The bridge > : drivers would be mostly unaffected by this. > : The only problem with this approach is that it can change the device > : enumeration; I hope that the resulting one will be the same one that is > : printed on the boxen, so it should be advantageous for new > : installations, but a minor migration problem for old ones. > : > : I've got some code for this already, it just isn't done yet. > > So are you talking about doing something akin to the acpi bridge code > or something else? Would this more properly be called a OFW PCI bus > driver, Yes, that's what I meant to say. It will "override" some of the PCI methods (by using it's own method table), and use the rest of them unaltered. It will attach to PCI bridges which offer an additional method to get the firmware device node (but with a higher priority than the standard PCI bus), so bridges can choose which bus driver they want to have attached by offering or not offering that method. Of course, there will need to be a generic OFW PCI-PCI bridge driver that adds this method, but it's needed anyway to override the standard interrupt routing method. - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
In message: <[EMAIL PROTECTED]> Thomas Moestl <[EMAIL PROTECTED]> writes: : On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: : > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: : > > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: : > > There's a similar problem with hme devices in some Netra models, and : > > so far I have just ignored this because of the ugliness involved : > > (there were patches floating around at one point, but I did not commit : > > them). : > > : > > The real fix (and the way I wanted to implement things from the : > > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This : > > is high on my list, waiting for time to become available :) : > : > Yikes, I just started looking at the acpi code, and there's a lot of : > code in it! : : There's much setup to be done that the firmware is too lazy to do for : us. : : > > > Is this why pciconf -r is returning 0x when reading the ebus : > > > and firewire parts of the SME2300BGA? Simply because it isn't in : > > > the ofw tree? : > > : > > Could be. We just cannot handle devices without firmware nodes - we : > > don't know whether we can safely access them, cannot assign interrupts : > > etc. : > : > Ok, the only problem is that is then we have the same problem the ACPI : > code does in that hot swapping cards would have a problem. Since it : > appears to me that the OFW tree doesn't get updated upon a swap. (At : > least the usb part of the tree doesn't.) : : We do not support hotplugging at the moment anyway. If a bridge driver : would implement that in the future without using any firmware support : however, it will then need to know everything information about the : interrupt routing required for its devices if it cannot use the : firmware for this. in that case, it can just prevent the ofw_pci bus : from attaching to it (this will be easily possible). : I'd hope that machines that support hot-plugging of PCI devices would : have firmware methods available to support that though. We'll need to do so for the cardbus bridges. However, the interupt is routed to the bridge and has to be shared with the cardbus/pccard cards. : > Does this mean that we should eliminate most of the Sun specific pci : > bus drivers in favor of OFW specific ones like ACPI? or? : : No, it means introducing an OFW bus driver, which uses the firmware to : enumerate the devices and to support interrupt routing. The bridge : drivers would be mostly unaffected by this. : The only problem with this approach is that it can change the device : enumeration; I hope that the resulting one will be the same one that is : printed on the boxen, so it should be advantageous for new : installations, but a minor migration problem for old ones. : : I've got some code for this already, it just isn't done yet. So are you talking about doing something akin to the acpi bridge code or something else? Would this more properly be called a OFW PCI bus driver, or would the OFW 'bus' reach over into other busses to add children? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Tue, 2003/06/10 at 16:41:44 -0700, John-Mark Gurney wrote: > Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200: > > On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > > There's a similar problem with hme devices in some Netra models, and > > so far I have just ignored this because of the ugliness involved > > (there were patches floating around at one point, but I did not commit > > them). > > > > The real fix (and the way I wanted to implement things from the > > beginning) is to write an OFW PCI bus, analogous to the ACPI one. This > > is high on my list, waiting for time to become available :) > > Yikes, I just started looking at the acpi code, and there's a lot of > code in it! There's much setup to be done that the firmware is too lazy to do for us. > > > Is this why pciconf -r is returning 0x when reading the ebus > > > and firewire parts of the SME2300BGA? Simply because it isn't in > > > the ofw tree? > > > > Could be. We just cannot handle devices without firmware nodes - we > > don't know whether we can safely access them, cannot assign interrupts > > etc. > > Ok, the only problem is that is then we have the same problem the ACPI > code does in that hot swapping cards would have a problem. Since it > appears to me that the OFW tree doesn't get updated upon a swap. (At > least the usb part of the tree doesn't.) We do not support hotplugging at the moment anyway. If a bridge driver would implement that in the future without using any firmware support however, it will then need to know everything information about the interrupt routing required for its devices if it cannot use the firmware for this. in that case, it can just prevent the ofw_pci bus from attaching to it (this will be easily possible). I'd hope that machines that support hot-plugging of PCI devices would have firmware methods available to support that though. > Does this mean that we should eliminate most of the Sun specific pci > bus drivers in favor of OFW specific ones like ACPI? or? No, it means introducing an OFW bus driver, which uses the firmware to enumerate the devices and to support interrupt routing. The bridge drivers would be mostly unaffected by this. The only problem with this approach is that it can change the device enumeration; I hope that the resulting one will be the same one that is printed on the boxen, so it should be advantageous for new installations, but a minor migration problem for old ones. I've got some code for this already, it just isn't done yet. - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Wed, 2003/06/11 at 01:16:50 +0200, Bernd Walter wrote: > On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: > > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > > : > This needs to be tested on that given hardware. > > > : > I don't know if REG will work as expected because it asks function 0, > > > : > which is disabled. > > > : > > > : I've reread John-Mark's last mail about the readable registers. > > > : So - yes it should work. > > > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > > of tweaking to make it actually compile and be neat. > > > > Ok, attached is a patched I tried, but sad to say, this doesn't work > > out to well. I added a printf before and after the REG statement, and > > a boot with the kernel give this output: > > found-> vendor=0x108e, dev=0x5000, revid=0x13 > > bus=0, slot=1, func=1 > > class=06-04-00, hdrtype=0x01, mfdev=1 > > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > > about to read HEADERTYPE > > panic: trap: data access error > > cpuid = 0; > > Uptime: 1s > > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > > cpuid = 0; > > Uptime: 1s > > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > > cpuid = 0; > > Uptime: 1s > > > > the last three lines repeate for a while, but this is because of: > > psycho_read_config(...) > > [...] > > /* > > * The psycho bridge does not tolerate accesses to unconfigured PCI > > * devices' or function's config space, so look up the device in the > > * firmware device tree first, and if it is not present, return a value > > * that will make the detection code think that there is no device here. > > * This is ugly... > > */ > > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > > return (0x); > > > > Which obviously will fail if reg != 0 which we try to do when reading > > the PCIR_HEADERTYPE.. > > > > 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 0x 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. I don't have the standard handy, but from my reading of the Shanley book, it seems that for the vendor ID register, a host bridge is required to return 0x if no device is present. Loading this task off to the software is a bit annoying. There is no mention of other registers, so reading them in the probe might theoretically cause problems even on host bridges that handle the vendor ID register correctly. - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
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 0x 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." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
Thomas Moestl wrote this message on Wed, Jun 11, 2003 at 01:02 +0200:
> On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote:
> >
> > Ok, attached is a patched I tried,
>
> Hmmm, you seem to have forgotten to actually attach it.
Ok, this time I'll attach it!
> > but sad to say, this doesn't work
> > out to well. I added a printf before and after the REG statement, and
> > a boot with the kernel give this output:
> > found-> vendor=0x108e, dev=0x5000, revid=0x13
> > bus=0, slot=1, func=1
> > class=06-04-00, hdrtype=0x01, mfdev=1
> > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords)
> > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns)
> > about to read HEADERTYPE
> > panic: trap: data access error
> >
> > [...]
> >
> > the last three lines repeate for a while, but this is because of:
> > psycho_read_config(...)
> > [...]
> > /*
> > * The psycho bridge does not tolerate accesses to unconfigured PCI
> > * devices' or function's config space, so look up the device in the
> > * firmware device tree first, and if it is not present, return a value
> > * that will make the detection code think that there is no device here.
> > * This is ugly...
> > */
> > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0)
> > return (0x);
> >
> > Which obviously will fail if reg != 0 which we try to do when reading
> > the PCIR_HEADERTYPE..
> >
> > 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?
>
> You could safely (it would just be slow), but that alone would not
> help you, since you would also be ignoring requests to the registers
> you want to read without further hackery. You could, of course, look
> into the device tree to see if there are devices at higher functions,
> that would just make that kludge more ugly than it already is :)
Ok, right now in order to get the machine back up and functional I
did remove the reg == 0, and running scanning all the functions.
> There's a similar problem with hme devices in some Netra models, and
> so far I have just ignored this because of the ugliness involved
> (there were patches floating around at one point, but I did not commit
> them).
>
> The real fix (and the way I wanted to implement things from the
> beginning) is to write an OFW PCI bus, analogous to the ACPI one. This
> is high on my list, waiting for time to become available :)
Yikes, I just started looking at the acpi code, and there's a lot of
code in it!
> > Is this why pciconf -r is returning 0x when reading the ebus
> > and firewire parts of the SME2300BGA? Simply because it isn't in
> > the ofw tree?
>
> Could be. We just cannot handle devices without firmware nodes - we
> don't know whether we can safely access them, cannot assign interrupts
> etc.
Ok, the only problem is that is then we have the same problem the ACPI
code does in that hot swapping cards would have a problem. Since it
appears to me that the OFW tree doesn't get updated upon a swap. (At
least the usb part of the tree doesn't.)
Does this mean that we should eliminate most of the Sun specific pci
bus drivers in favor of OFW specific ones like ACPI? or?
Thanks, I have plenty of time to hack on this right now, so any pointers
would be useful.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Index: pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.214
diff -u -r1.214 pci.c
--- pci.c 2003/04/16 03:15:08 1.214
+++ pci.c 2003/06/10 21:40:16
@@ -816,25 +816,32 @@
void
pci_add_children(device_t dev, int busno, size_t dinfo_size)
{
+#define REG(n, w) PCIB_READ_CONFIG(pcib, busno, s, f, n, w)
device_t pcib = device_get_parent(dev);
struct pci_devinfo *dinfo;
int maxslots;
int s, f, pcifunchigh;
+ u_int8_t hdrtype;
KASSERT(dinfo_size >= sizeof(struct pci_devinfo),
("dinfo_size too small"));
maxslots = PCIB_MAXSLOTS(pcib);
for (s = 0; s <= maxslots; s++) {
pcifunchigh = 0;
+ f = 0;
+ hdrtype = REG(PCIR_HEADERTYPE, 1);
+ if ((hdrtype & ~PCIM_MFDEV) > 2)
+ continue;
+ if (hdrtype & PCIM_MFDEV)
+ pcifunchigh = PCI_FUNCMAX;
for (f = 0; f <= pcifunchigh; f++) {
dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
if (dinfo != NULL) {
- if (dinfo->cfg.mfdev)
- pcifunchigh = PCI_FUNCMAX;
pci_add_child(dev, dinfo);
}
}
}
+#undef RE
Re: PCI bus numbering and orphaned devices
On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > : > This needs to be tested on that given hardware. > > : > I don't know if REG will work as expected because it asks function 0, > > : > which is disabled. > > : > > : I've reread John-Mark's last mail about the readable registers. > > : So - yes it should work. > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > of tweaking to make it actually compile and be neat. > > Ok, attached is a patched I tried, but sad to say, this doesn't work > out to well. I added a printf before and after the REG statement, and > a boot with the kernel give this output: > found-> vendor=0x108e, dev=0x5000, revid=0x13 > bus=0, slot=1, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > about to read HEADERTYPE > panic: trap: data access error > cpuid = 0; > Uptime: 1s > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > cpuid = 0; > Uptime: 1s > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > cpuid = 0; > Uptime: 1s > > the last three lines repeate for a while, but this is because of: > psycho_read_config(...) > [...] > /* >* The psycho bridge does not tolerate accesses to unconfigured PCI >* devices' or function's config space, so look up the device in the >* firmware device tree first, and if it is not present, return a value >* that will make the detection code think that there is no device here. >* This is ugly... >*/ > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > return (0x); > > Which obviously will fail if reg != 0 which we try to do when reading > the PCIR_HEADERTYPE.. > > 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 0x 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. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Tue, 2003/06/10 at 15:34:36 -0700, John-Mark Gurney wrote: > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > : > This needs to be tested on that given hardware. > > : > I don't know if REG will work as expected because it asks function 0, > > : > which is disabled. > > : > > : I've reread John-Mark's last mail about the readable registers. > > : So - yes it should work. > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > of tweaking to make it actually compile and be neat. > > Ok, attached is a patched I tried, Hmmm, you seem to have forgotten to actually attach it. > but sad to say, this doesn't work > out to well. I added a printf before and after the REG statement, and > a boot with the kernel give this output: > found-> vendor=0x108e, dev=0x5000, revid=0x13 > bus=0, slot=1, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > about to read HEADERTYPE > panic: trap: data access error > > [...] > > the last three lines repeate for a while, but this is because of: > psycho_read_config(...) > [...] > /* >* The psycho bridge does not tolerate accesses to unconfigured PCI >* devices' or function's config space, so look up the device in the >* firmware device tree first, and if it is not present, return a value >* that will make the detection code think that there is no device here. >* This is ugly... >*/ > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > return (0x); > > Which obviously will fail if reg != 0 which we try to do when reading > the PCIR_HEADERTYPE.. > > 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? You could safely (it would just be slow), but that alone would not help you, since you would also be ignoring requests to the registers you want to read without further hackery. You could, of course, look into the device tree to see if there are devices at higher functions, that would just make that kludge more ugly than it already is :) There's a similar problem with hme devices in some Netra models, and so far I have just ignored this because of the ugliness involved (there were patches floating around at one point, but I did not commit them). The real fix (and the way I wanted to implement things from the beginning) is to write an OFW PCI bus, analogous to the ACPI one. This is high on my list, waiting for time to become available :) > Is this why pciconf -r is returning 0x when reading the ebus > and firewire parts of the SME2300BGA? Simply because it isn't in > the ofw tree? Could be. We just cannot handle devices without firmware nodes - we don't know whether we can safely access them, cannot assign interrupts etc. - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > : > This needs to be tested on that given hardware. > : > I don't know if REG will work as expected because it asks function 0, > : > which is disabled. > : > : I've reread John-Mark's last mail about the readable registers. > : So - yes it should work. > > That's what inspired me. Also, I'd expected that we'd need some kind > of tweaking to make it actually compile and be neat. Ok, attached is a patched I tried, but sad to say, this doesn't work out to well. I added a printf before and after the REG statement, and a boot with the kernel give this output: found-> vendor=0x108e, dev=0x5000, revid=0x13 bus=0, slot=1, func=1 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) about to read HEADERTYPE panic: trap: data access error cpuid = 0; Uptime: 1s panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 cpuid = 0; Uptime: 1s panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 cpuid = 0; Uptime: 1s the last three lines repeate for a while, but this is because of: psycho_read_config(...) [...] /* * The psycho bridge does not tolerate accesses to unconfigured PCI * devices' or function's config space, so look up the device in the * firmware device tree first, and if it is not present, return a value * that will make the detection code think that there is no device here. * This is ugly... */ if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) return (0x); Which obviously will fail if reg != 0 which we try to do when reading the PCIR_HEADERTYPE.. 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 0x when reading the ebus and firewire parts of the SME2300BGA? Simply because it isn't in the ofw tree? I don't have any data sheets or the PCI spec, so making heads or tails of this is going be hard. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
In message: <[EMAIL PROTECTED]>
Bernd Walter <[EMAIL PROTECTED]> writes:
: On Tue, Jun 10, 2003 at 01:56:15PM +0200, Bernd Walter wrote:
: > On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote:
: > > I'm thinking that the loop should be more like:
: > >
: > > pcifunchigh = 0;
: > > f = 0;
: > > hdrtype = REG(PCIR_HEADERTYPE, 1);
: > > if (hdrtype & 0x7f > 2)
: > > continue;
: > > if (hdrtype & 0x80)
: > s/0x80/PCIM_MFDEV/
: > Maybe we should add a PCIM_REGLAYOUT as well.
: >
: > > pcifunchigh = PCI_FUNCMAX;
: > > for (f = 0; f <= pcifunchigh; f++) {
: > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
: > > if (dinfo != NULL)
: > > pci_add_child(dev, dinfo);
: > > }
: > >
: > > might be better code (REG likely needs to be correctly defined for
: > > this context).
: >
: > This needs to be tested on that given hardware.
: > I don't know if REG will work as expected because it asks function 0,
: > which is disabled.
:
: I've reread John-Mark's last mail about the readable registers.
: So - yes it should work.
That's what inspired me. Also, I'd expected that we'd need some kind
of tweaking to make it actually compile and be neat.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Tue, Jun 10, 2003 at 01:56:15PM +0200, Bernd Walter wrote:
> On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote:
> > I'm thinking that the loop should be more like:
> >
> > pcifunchigh = 0;
> > f = 0;
> > hdrtype = REG(PCIR_HEADERTYPE, 1);
> > if (hdrtype & 0x7f > 2)
> > continue;
> > if (hdrtype & 0x80)
> s/0x80/PCIM_MFDEV/
> Maybe we should add a PCIM_REGLAYOUT as well.
>
> > pcifunchigh = PCI_FUNCMAX;
> > for (f = 0; f <= pcifunchigh; f++) {
> > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
> > if (dinfo != NULL)
> > pci_add_child(dev, dinfo);
> > }
> >
> > might be better code (REG likely needs to be correctly defined for
> > this context).
>
> This needs to be tested on that given hardware.
> I don't know if REG will work as expected because it asks function 0,
> which is disabled.
I've reread John-Mark's last mail about the readable registers.
So - yes it should work.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Mon, Jun 09, 2003 at 10:46:21PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> John-Mark Gurney <[EMAIL PROTECTED]> writes:
> : > > +#ifdef __sparc64__
> : > > + /*
> : > > +* XXX - some sparc hardware has valid hardware when the
> : > > +* function 0 doesn't probe. Scan all functions.
> : > > +*/
> : > > + pcifunchigh = PCI_FUNCMAX;
> : > > +#else
> : > > pcifunchigh = 0;
> : > > +#endif
> : > > for (f = 0; f <= pcifunchigh; f++) {
> : > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
> : > > if (dinfo != NULL) {
> : >
> : > This is problematic as it ignores the fact about single function
> : > devices which may react to all function numbers.
> :
> : Wouldn't this happen with the current logic? since if function 0 is
> : found, it scans the rest... (Might be getting confused with SCSI
> : buses).
No - it checks the mfdev flag before increasing pcifunchigh.
> Actually, there's no reason not to scan the hardware. we likely
> should be checking the multi function status differently than we are
> right now. We also shouldn't be rejecting based on the vendor id.
> while that provides a convenient way to chek to see if it really isn't
> there, a better sanity check would be to check the header type to see
> if it a one we know about (0, 1 or 2). If so, then we know if the
> device is there. that might be a better hueristic to see if we need
> to scan everything.
>
> : Actually, I was thinking that we could check to see if the next word
> : is not -1. The chip responds to the rest of the registers, but just
> : doesn't respond to the DEVVENDOR (first word).
>
> since header type is a required field, this likely is a better way to
> go. maybe keep the test against -1 for adding it as a child, but
> don't assume nothing is there unless the header type is bogus.
>
> : I'm also thinking of adding support code to the pci bus to let the
> : userland add a new device node to be probed. It shouldn't be too hard,
> : but would be help in these cases.
>
> I'd rather tht we fix the pci probe code to do the right thing.
> Kludges like this tend to live for a long time because nobody bothers
> to fix them correctly...
>
> I'm thinking that the loop should be more like:
>
> pcifunchigh = 0;
> f = 0;
> hdrtype = REG(PCIR_HEADERTYPE, 1);
> if (hdrtype & 0x7f > 2)
> continue;
> if (hdrtype & 0x80)
s/0x80/PCIM_MFDEV/
Maybe we should add a PCIM_REGLAYOUT as well.
> pcifunchigh = PCI_FUNCMAX;
> for (f = 0; f <= pcifunchigh; f++) {
> dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
> if (dinfo != NULL)
> pci_add_child(dev, dinfo);
> }
>
> might be better code (REG likely needs to be correctly defined for
> this context).
This needs to be tested on that given hardware.
I don't know if REG will work as expected because it asks function 0,
which is disabled.
> this is based on my limited understanding that function 0 shouldn't be
> attached and function 1 should...
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Mon, 2003/06/09 at 16:58:38 -0700, John-Mark Gurney wrote:
> Hello,
>
> I've recently started work on making FreeBSD work better on a sparc64
> box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz).
>
> So far I have found out that the pci bus numbering has problems. We
> don't attach pci busses as they are numbered in the bridge/OFW info.
> This causes problems with pciconf -l and pciconf -{w,r} not agreeing.
> It isn't too hard to tie down the busses to make pciconf agree with
> itself.
>
> [...]
>
> Index: apb.c
> ===
> RCS file: /home/ncvs/src/sys/sparc64/pci/apb.c,v
> retrieving revision 1.4
> diff -u -r1.4 apb.c
> --- apb.c 2002/03/24 02:10:56 1.4
> +++ apb.c 2003/06/09 23:33:07
> @@ -207,9 +207,11 @@
>* number, we should pick a better value. One sensible alternative
>* would be to pick 255; the only tradeoff here is that configuration
>* transactions would be more widely routed than absolutely necessary.
> + *
> + * If we don't hardware the bus down, pciconf gets confused.
>*/
> if (sc->secbus != 0) {
> - child = device_add_child(dev, "pci", -1);
> + child = device_add_child(dev, "pci", sc->secbus);
> if (child != NULL)
> return (bus_generic_attach(dev));
> } else
This one looks good, please commit. The comment above is outdated, so
it might be better to just remove it completely.
- Thomas
--
Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
<[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
In message: <[EMAIL PROTECTED]>
Bernd Walter <[EMAIL PROTECTED]> writes:
: On Mon, Jun 09, 2003 at 04:58:38PM -0700, John-Mark Gurney wrote:
: > Hello,
: >
: > I've recently started work on making FreeBSD work better on a sparc64
: > box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz).
: >
: > So far I have found out that the pci bus numbering has problems. We
: > don't attach pci busses as they are numbered in the bridge/OFW info.
: > This causes problems with pciconf -l and pciconf -{w,r} not agreeing.
: > It isn't too hard to tie down the busses to make pciconf agree with
: > itself.
I have similar issues with cardbus cards...
...
: > Of course the correct way to fix it would be to mirror the OFW tree,
: > and then probe any devices that exist in the OFW tree, but not in our
: > device tree.
why is this the correct way to fix it? don't mean to be difficult,
just don't see why sparc64 needs to eb different.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
In message: <[EMAIL PROTECTED]>
John-Mark Gurney <[EMAIL PROTECTED]> writes:
: > > +#ifdef __sparc64__
: > > + /*
: > > + * XXX - some sparc hardware has valid hardware when the
: > > + * function 0 doesn't probe. Scan all functions.
: > > + */
: > > + pcifunchigh = PCI_FUNCMAX;
: > > +#else
: > > pcifunchigh = 0;
: > > +#endif
: > > for (f = 0; f <= pcifunchigh; f++) {
: > > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
: > > if (dinfo != NULL) {
: >
: > This is problematic as it ignores the fact about single function
: > devices which may react to all function numbers.
:
: Wouldn't this happen with the current logic? since if function 0 is
: found, it scans the rest... (Might be getting confused with SCSI
: buses).
Actually, there's no reason not to scan the hardware. we likely
should be checking the multi function status differently than we are
right now. We also shouldn't be rejecting based on the vendor id.
while that provides a convenient way to chek to see if it really isn't
there, a better sanity check would be to check the header type to see
if it a one we know about (0, 1 or 2). If so, then we know if the
device is there. that might be a better hueristic to see if we need
to scan everything.
: Actually, I was thinking that we could check to see if the next word
: is not -1. The chip responds to the rest of the registers, but just
: doesn't respond to the DEVVENDOR (first word).
since header type is a required field, this likely is a better way to
go. maybe keep the test against -1 for adding it as a child, but
don't assume nothing is there unless the header type is bogus.
: I'm also thinking of adding support code to the pci bus to let the
: userland add a new device node to be probed. It shouldn't be too hard,
: but would be help in these cases.
I'd rather tht we fix the pci probe code to do the right thing.
Kludges like this tend to live for a long time because nobody bothers
to fix them correctly...
I'm thinking that the loop should be more like:
pcifunchigh = 0;
f = 0;
hdrtype = REG(PCIR_HEADERTYPE, 1);
if (hdrtype & 0x7f > 2)
continue;
if (hdrtype & 0x80)
pcifunchigh = PCI_FUNCMAX;
for (f = 0; f <= pcifunchigh; f++) {
dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
if (dinfo != NULL)
pci_add_child(dev, dinfo);
}
might be better code (REG likely needs to be correctly defined for
this context).
this is based on my limited understanding that function 0 shouldn't be
attached and function 1 should...
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
Bernd Walter scribbled this message on Jun 10:
> On Mon, Jun 09, 2003 at 04:58:38PM -0700, John-Mark Gurney wrote:
> > +#ifdef __sparc64__
> > + /*
> > +* XXX - some sparc hardware has valid hardware when the
> > +* function 0 doesn't probe. Scan all functions.
> > +*/
> > + pcifunchigh = PCI_FUNCMAX;
> > +#else
> > pcifunchigh = 0;
> > +#endif
> > for (f = 0; f <= pcifunchigh; f++) {
> > dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
> > if (dinfo != NULL) {
>
> This is problematic as it ignores the fact about single function
> devices which may react to all function numbers.
Wouldn't this happen with the current logic? since if function 0 is
found, it scans the rest... (Might be getting confused with SCSI
buses).
> What about reverting the logic:
> Initialy set pcifunchigh = PCI_FUNCMAX and set pcifunchigh = 0 in case
> we catched a single function device.
> I don't think it should be sparc specific.
Actually, I was thinking that we could check to see if the next word
is not -1. The chip responds to the rest of the registers, but just
doesn't respond to the DEVVENDOR (first word). So, if we check if the
first function's first word returns -1, check the second word, and if
that is not -1, then probe all the rest of the functions.
-bash-2.05b$ pciconf -r pci1:5:0 0x0:0x4
0282
I'm also thinking of adding support code to the pci bus to let the
userland add a new device node to be probed. It shouldn't be too hard,
but would be help in these cases.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PCI bus numbering and orphaned devices
On Mon, Jun 09, 2003 at 04:58:38PM -0700, John-Mark Gurney wrote:
> Hello,
>
> I've recently started work on making FreeBSD work better on a sparc64
> box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz).
>
> So far I have found out that the pci bus numbering has problems. We
> don't attach pci busses as they are numbered in the bridge/OFW info.
> This causes problems with pciconf -l and pciconf -{w,r} not agreeing.
> It isn't too hard to tie down the busses to make pciconf agree with
> itself.
>
> The second problem is that this has two SME2300BGA chips on it. They
> are combo ebus/usb/1394/ethernet chips. The problem is that SUN in
> order to only have one ebus on the machine, removed function 0 of the
> device from probing. This means that the other functions of the pci
> card never get probed. This can be fixed by making sure we probe all
> the functions on all the devices on the PCI buses. This then gets the
> second ethernet and USB to probe and attach.
>
> Of course the correct way to fix it would be to mirror the OFW tree,
> and then probe any devices that exist in the OFW tree, but not in our
> device tree.
>
> Attached are the two patches to fix both the issues.
> Index: pci.c
> ===
> RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v
> retrieving revision 1.214
> diff -u -r1.214 pci.c
> --- pci.c 2003/04/16 03:15:08 1.214
> +++ pci.c 2003/06/09 23:35:56
> @@ -825,7 +825,15 @@
> ("dinfo_size too small"));
> maxslots = PCIB_MAXSLOTS(pcib);
> for (s = 0; s <= maxslots; s++) {
> +#ifdef __sparc64__
> + /*
> + * XXX - some sparc hardware has valid hardware when the
> + * function 0 doesn't probe. Scan all functions.
> + */
> + pcifunchigh = PCI_FUNCMAX;
> +#else
> pcifunchigh = 0;
> +#endif
> for (f = 0; f <= pcifunchigh; f++) {
> dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
> if (dinfo != NULL) {
This is problematic as it ignores the fact about single function
devices which may react to all function numbers.
What about reverting the logic:
Initialy set pcifunchigh = PCI_FUNCMAX and set pcifunchigh = 0 in case
we catched a single function device.
I don't think it should be sparc specific.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PCI bus numbering and orphaned devices
Hello,
I've recently started work on making FreeBSD work better on a sparc64
box that a friend has. It's a Netra AX1105-500 (UltraSPARC-IIe 500MHz).
So far I have found out that the pci bus numbering has problems. We
don't attach pci busses as they are numbered in the bridge/OFW info.
This causes problems with pciconf -l and pciconf -{w,r} not agreeing.
It isn't too hard to tie down the busses to make pciconf agree with
itself.
The second problem is that this has two SME2300BGA chips on it. They
are combo ebus/usb/1394/ethernet chips. The problem is that SUN in
order to only have one ebus on the machine, removed function 0 of the
device from probing. This means that the other functions of the pci
card never get probed. This can be fixed by making sure we probe all
the functions on all the devices on the PCI buses. This then gets the
second ethernet and USB to probe and attach.
Of course the correct way to fix it would be to mirror the OFW tree,
and then probe any devices that exist in the OFW tree, but not in our
device tree.
Attached are the two patches to fix both the issues.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Index: pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.214
diff -u -r1.214 pci.c
--- pci.c 2003/04/16 03:15:08 1.214
+++ pci.c 2003/06/09 23:35:56
@@ -825,7 +825,15 @@
("dinfo_size too small"));
maxslots = PCIB_MAXSLOTS(pcib);
for (s = 0; s <= maxslots; s++) {
+#ifdef __sparc64__
+ /*
+* XXX - some sparc hardware has valid hardware when the
+* function 0 doesn't probe. Scan all functions.
+*/
+ pcifunchigh = PCI_FUNCMAX;
+#else
pcifunchigh = 0;
+#endif
for (f = 0; f <= pcifunchigh; f++) {
dinfo = pci_read_device(pcib, busno, s, f, dinfo_size);
if (dinfo != NULL) {
Index: apb.c
===
RCS file: /home/ncvs/src/sys/sparc64/pci/apb.c,v
retrieving revision 1.4
diff -u -r1.4 apb.c
--- apb.c 2002/03/24 02:10:56 1.4
+++ apb.c 2003/06/09 23:33:07
@@ -207,9 +207,11 @@
* number, we should pick a better value. One sensible alternative
* would be to pick 255; the only tradeoff here is that configuration
* transactions would be more widely routed than absolutely necessary.
+*
+* If we don't hardware the bus down, pciconf gets confused.
*/
if (sc->secbus != 0) {
- child = device_add_child(dev, "pci", -1);
+ child = device_add_child(dev, "pci", sc->secbus);
if (child != NULL)
return (bus_generic_attach(dev));
} else
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
