Fwd: misc questions about the device&driver arch

[william wallace]

---------- Forwarded message ----------
From: william wallace <avalonwallace at gmail.com>
Date: Jun 7, 2006 11:13 AM
Subject: Re: misc questions about the device&driver arch
To: "M. Warner Losh" <imp at bsdimp.com>
Cc: jhb at freebsd.org, Scott Long <scottl at samsco.org>


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 <imp at bsdimp.com> wrote:
> In message: <87ab37ab0606050510v46e8619du18c1481ffa0e3d4 at mail.gmail.com>
>            "william wallace" <avalonwallace at gmail.com> 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 <imp at bsdimp.com> wrote:
> : > In message: <87ab37ab0606040823k73cf27b1q787d544ce19a9687 at mail.gmail.com>
> : >            "william wallace" <avalonwallace at gmail.com> 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 <imp at bsdimp.com> wrote:
> : > : > In message: <87ab37ab0606040029u67edc35ende0b34e39e80bd37 at mail.gmail.com>
> : > : >            "william wallace" <avalonwallace at gmail.com> writes:
> : > : > : On 5/20/06, Warner Losh <imp at bsdimp.com> wrote:
> : > : > : > From: "william wallace" <avalonwallace at gmail.com>
> : > : > : > 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 <imp at bsdimp.com> 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!