---------- Forwarded message ---------- From: william wallace <[EMAIL PROTECTED]> Date: Jun 7, 2006 11:13 AM Subject: Re: misc questions about the device&driver arch To: "M. Warner Losh" <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Scott Long <[EMAIL PROTECTED]>
now i amreally in trouble.the cardbus way of probing attaching allocationg as a package deal in kernel make things more tough. now my Broadcom BCM5721 Gigabit Ethernet says no when hot add is implemented. dmesg the below message: ///////////////////////////// pciehp_unconfigure_device:1357: begin to go device_get_children bge0: <Broadcom BCM5721 Gigabit Ethernet, ASIC rev. 0x4101> at device 0.0 on pci7 bge0: RX CPU self-diagnostics failed! bge0: chip initialization failed device_attach: bge0 attach returned 6 ////////////////////////////// and this is printed in bge_chipinit(sc) @if_bge.c of freeBSD 53 : \\\\\\\\\\\\\\\\\\\\\\\\ * Check the 'ROM failed' bit on the RX CPU to see if * self-tests passed. if (CSR_READ_4(sc, BGE_RXCPU_MODE) & BGE_RXCPUMODE_ROMFAIL) { printf("bge%d: RX CPU self-diagnostics failed!\n", sc->bge_unit); return(ENODEV); \\\\\\\\\\\\\\\\\\\\\\\\\\\\ oh ,my god ,the firmware talks ! this card need firmware to be somehow run before the device driver be attached 1 so far as I know linux do this in "/usr/lib/hotplug/firmware/"way ,but Freebsd do not do this . what should i do :( On 6/5/06, M. Warner Losh <[EMAIL PROTECTED]> wrote:
In message: <[EMAIL PROTECTED]> "william wallace" <[EMAIL PROTECTED]> writes: : sir : : thank you for ur reminds : now ,on DELL 2800 ,which use the intel E7520af2 mainboard ,i have : successfully hot remove the bge G NIC card under the pci express : port,my code is attached below . : But still i found it hard to allocate resource when hot plug the NIC : card and to write the code similar to cardbus_alloc_resources , which : in my code corresponds to pcie_alloc_resources. All of cardbus_alloc_resources has moved into the pci layer in -current. maybe that would be a better place to start. : i have referred to the cardbus way ,the linux way ,and the pci : startup way .which way should i head on ,any advise to write : pcie_alloc_resources? my current code cardHP.rar is attached ,it is a : loadable module ,how ever ,now . I'd imagine it would be close to working with -current :-) Warner : On 6/5/06, M. Warner Losh <[EMAIL PROTECTED]> wrote: : > In message: <[EMAIL PROTECTED]> : > "william wallace" <[EMAIL PROTECTED]> writes: : > : now i am dealing with the pciexpress resource release and allocation : > : i found it hard to distinguish between the bus_alloc_resource : > : familiy(type rid and flag) and the rman_get/set_***** family(struct : > : rman and resource ) ,i have heard that memory resource which alloc by : > : the bus_alloc_resource should not be refer to by rid , : > : " SYS_RES_MEMORY : > : Memory-access is done with the bus_space_(read,write)_(1,2,3,4) : > : functions (depends on how many bytes you want to read/write). : > : u_int8_t old; : > : old = bus_space_read_1(sc->bst, sc->bsh, 0); : > : bus_space_write_1(sc->bst, sc->bsh, 0, old); " : > : is that true? : > : > bus_alloc_resources is how you get resources from your parent device. : > It will return a struct resource * that the rman* rouintes can access : > the insides of (let's call it r). : > bus_space_read_1(rman_get_bustag(r), rman_get_bushandle(r), 0); : > or the newer : > bus_read_1(r, 0); : > : > : the second question ,if i do hot swap and donot release the hot remove : > : card 's resource ,how can i attach it to the newly add-in card ? : > : > You must release the resource whent he card exits the system. : > : > : shall i do a : > : pci_write_config(child, rle->rid, rle->start, 4);to pin the resource : > : to the pci space ? : > : > No. The pci code should already handle things correctly. : > : > : i wonder if there 's a find document for the freebsd resource topology, : > : > There's not a centralized document outside of the source. : > : > Warner : > : > : > : thank you ,sir . : > : On 6/4/06, M. Warner Losh <[EMAIL PROTECTED]> wrote: : > : > In message: <[EMAIL PROTECTED]> : > : > "william wallace" <[EMAIL PROTECTED]> writes: : > : > : On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote: : > : > : > From: "william wallace" <[EMAIL PROTECTED]> : > : > : > Subject: Re: misc questions about the device&driver arch : > : > : > Date: Sat, 20 May 2006 13:39:08 +0800 : > : > : > : > : > : > > comparing the method array of pci_pci and cardbusbridge: : > : > : > > what losts in pci bridge but exist in cardbusbridge: : > : > : > > 1 card interface : > : > : > > 2 power interface : > : > : > > 3 some functions : : > : > : > > 3ain bus interface : > : > : > > (bus_driver_added, cbb_driver_added), : > : > : > > (bus_child_detached, cbb_child_detached), : > : > : > > (bus_child_present, cbb_child_present), : > : > : > > 3b in device interface : > : > : > > (device_detach, cbb_detach), : > : > : > > what exists in pci bridge but losts in cardbusbridge: : > : > : > > (pcib_route_interrupt, pcib_route_interrupt), : > : > : > > : > : > : > > not only that ,functions r very different eventhough they realize the : > : > : > > same interface function template : > : > : > > wooo,so long to go to hotplug pci : > : > : > : > : > : > Yes. The hardest part would be to create a pci hot swap bridge : > : > : > driver. The interface for them tend to be underdocumented. : > : > : > : > : > : > The bus_child_present is important for detaching. : > : > : > : > : > : > Also, I think that we may need to start implementing a quiess method : > : > : > to tell the drivers they are about to be removed. For hot plug PCI, : > : > : > the model is that you quess the driver, the os tells you somehow it is : > : > : > safe, and then you remove the card. The details vary (some system are : > : > : > all in software, while others have a complicated interlock and LEDs), : > : > : > but they are similar. Cardbus is harder in some ways because cards : > : > : > leave unannounced (in fact, there's not a good way to announce a card : > : > : > leaving, but there should be). : > : > : > : > : > : > Warner : > : > : > : > : > : > > On 5/20/06, Warner Losh <[EMAIL PROTECTED]> wrote: : > : > : > > : > : > : > > > Busses create devices to represent hardware in the system. The bus : > : > : > > > then causes these devices to be probed and attached. This latter : > : > : > > > usage is for those cases. As drivers are loaded these devices are : > : > : > > > offered to the new (and old) drivers in the system. : > : > : > > > : > : > : > > > FreeBSD inherently dynamic in its device system. The hardest part of : > : > : > > > adding hotplug support is programming the bridge. Adding new devices : > : > : > > > to the tree is easy, but knowing when to add them is hard since you : > : > : > > > have to write a bridge driver... : > : > : > > > : > : > : > > > Warner : > : > : Prior to removing a card from the system, two things must occur: : > : > : : > : > : The device's driver must cease accessing the card. : > : > : : > : > : The card must cease generation transaction and interrupts. : > : > : : > : > : How this is accomplished is OS-specific, but the following must take place: : > : > : : > : > : The OS must stop issuing new requests to the device's driver or must : > : > : instruct the driver to stop accepting new requests. : > : > : : > : > : The driver must terminate or complete all outstanding requests. : > : > : : > : > : The card must be disabled from generating interrupts or transactions. : > : > : : > : > : When the OS commands the driver to quiesce itself and its device, the : > : > : OS must not expect the device to remain in the system (in other words, : > : > : it could be removed and not replaced with a similar card). : > : > : : > : > : How to design and implement quiescing in freebsd? : > : > : > : > device_quiesce? I have it in a p4 tree right now. Specifically, it : > : > hooks up to the MOD_UNLOAD with a QUIESCE flag. The driver's : > : > device_quiesce routine gets called, the driver sleeps there until it : > : > knows that it is good, then returns to the caller. Then the driver's : > : > detach routine can be called. : > : > : > : > Warner : > : > : > : : > : : > : -- : > : we who r about to die,salute u! : > : : > : : > : : : -- : we who r about to die,salute u!
-- we who r about to die,salute u! -- we who r about to die,salute u! _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"