Device enumeration

[Alok Barsode]

Hi,
I am a newbie working on FreeBSD 4.10.

I am a bit confused between  i386/conf/GENERIC and
i386/conf/GENERIC.hints.

Does a device driver's probe/attach routine is invoked
when a enty is made for it in the GENERIC file?
for example an enty in the GENERIC file will be :
device  nge    # NatSemi DP83820 gigabit Ethernet  
Does the probe routine in if_nge.c invoked when the
kernel encounters the above entry?

How can I probe/attach a device which is not
self-identifying? Like a memory mapped device? Does an
entry in the GENERIC file make sure the probe/attach
function will be called for it?

How can I identify where in the device hierarchy is it
located? The device is not connected to any BUS. so
will it be a independent device?

In GENERIC.hints a device's bus, port,irq are
mentioned. What is the actual purpose of doing so? is
this hard coding the values (like irqs)? what
information has to be mentioned in this file?

I was unable to find a good document on the newbus
architecture and device enumeration.If anybody knows
of one, plz let me know.

Thanks,
Alok.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[Ruslan Ermilov]

On Thu, Sep 28, 2006 at 03:24:37AM -0700, Alok Barsode wrote:

> Hi,
> I am a newbie working on FreeBSD 4.10.
>
> I am a bit confused between  i386/conf/GENERIC and
> i386/conf/GENERIC.hints.
>
> Does a device driver's probe/attach routine is invoked
> when a enty is made for it in the GENERIC file?
> for example an enty in the GENERIC file will be :
> device  nge    # NatSemi DP83820 gigabit Ethernet  
> Does the probe routine in if_nge.c invoked when the
> kernel encounters the above entry?
>

No.  The magic is in the following line in if_nge.c:

DRIVER_MODULE(if_nge, pci, nge_driver, nge_devclass, 0, 0);

It attaches the nge_driver to the pci bus.

> How can I probe/attach a device which is not
> self-identifying? Like a memory mapped device? Does an
> entry in the GENERIC file make sure the probe/attach
> function will be called for it?
>
Like ISA non-PnP devices?

> How can I identify where in the device hierarchy is it
> located?
>
On modern FreeBSD versions, 5,x and 6.x, there's a devinfo(8)
utility that allows to retrieve this kind of information.

> The device is not connected to any BUS. so
> will it be a independent device?
>
I think you'll have to use some kind of a bus.  When I
worked on a port of adm5120 for NetBSD, we used the obio
bus which stands for the "onboard I/O" and is not a real
bus.  The configuration on that bus was static.

> In GENERIC.hints a device's bus, port,irq are
> mentioned. What is the actual purpose of doing so?
>
This is for legacy non-PnP ISA devices mostly, and
for some slave devices, like floppy drivers attached
to a floppy controller, and PS/2 mouse and AT keyboard
to the AT keyboard controller:

$ grep -w at GENERIC.hints | grep -vw "isa"
hint.fd.0.at="fdc0"
hint.fd.1.at="fdc0"
hint.atkbd.0.at="atkbdc"
hint.psm.0.at="atkbdc"

GENERIC.hints doesn't exist in 4.10, by the way.


Cheers,
--
Ruslan Ermilov
ru@...
FreeBSD committer

[M. Warner Losh]

In message: <20060928102437.93193.qmail@...>
            Alok Barsode <namaskar_alok@...> writes:
: I am a bit confused between  i386/conf/GENERIC and
: i386/conf/GENERIC.hints.

OK.

: Does a device driver's probe/attach routine is invoked
: when a enty is made for it in the GENERIC file?

Not necessarily.  The presense of the driver in the GENERIC file means
that if there are busses to which the driver attaches, and the
bus-dependent code thinks there's reason to believe the device is
present, then its probe routine will be called.

In the case of PCI, the bus dependent code assumes that if the PCI
config registers say there's a device there, then that's enough for it
to present to all the PCI probe routines to see who is interested in it.

: for example an enty in the GENERIC file will be :
: device  nge    # NatSemi DP83820 gigabit Ethernet  
: Does the probe routine in if_nge.c invoked when the
: kernel encounters the above entry?

No.  Not when it encountered the above entry.  It will get called once
per PCI device on each of the PCI busses.

: How can I probe/attach a device which is not
: self-identifying?

Identify routine.  device_identify gives some details.  Not all busses
allow one to have an identify routine (pci tells you what devices are
present, isa lets you tell it what devices are present).

: Like a memory mapped device? Does an
: entry in the GENERIC file make sure the probe/attach
: function will be called for it?

You need to attach it to a bus.  That bus can then deside to call your
probe/attach routine.

: How can I identify where in the device hierarchy is it
: located? The device is not connected to any BUS. so
: will it be a independent device?

All devices are attached to a bus, by definition.  There's some bus
that you can attach it to.  In general, a device such as you describe
would be attached to 'isa' on the i386 port.  Isa is the catch-all bus
for things, not just those funny old-school cards.

: In GENERIC.hints a device's bus, port,irq are
: mentioned. What is the actual purpose of doing so? is
: this hard coding the values (like irqs)? what
: information has to be mentioned in this file?

GENERIC.hints is 5.x and newer.  Are you sure you are looking at 4.10?
In 4.10, you'd have a line that looks like:

device          fdc0    at isa? port IO_FD1 iomem XXXX irq 6 drq 2

your device, since it is memory mapped, it would look like:

device     fred0 at isa? iomem 0xfc000000 irq 9

(assuming it is memory mapped to 0xfc000000 and has been wired to
IRQ9, omit that part if not).

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[Alok Barsode]

hello,

Thanks a lot for the reply.

A question which arises is, If the kernel calls the
probe routine (in case of PCI)for all the devices
attached to it during bus-enumeration, whats the point
of having the device entries in GENERIC?does the
bus-dependent code call the probe routine of the
device-driver,for only those devices which are
mentioned in GENERIC file.

I am writing a device driver for a memory mapped
ethernet device.Does it HAVE to be attached to a
bus?Its the only device I want to support(right
now).Is it not possible to hard-code the probe-attach
routine calls?

Can i attach it to nexus? OR Can I attach it to the
PCI bus (though its not a PCI device) through some
hack?

This is not a i386 port hence the ISA bus is absent.
Will i have to implement a pseudo-bus (write the
bus-dependent code)in order to attach my device?
       

Thank you,
Alok.


"Let the wisdom of the old guide the buoyancy and vitality of the youth; let the buoyancy and vitality of the youth sustain the wisdom of the old." - Stanislavski

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[M. Warner Losh]

In message: <20060930120043.41538.qmail@...>
            Alok Barsode <namaskar_alok@...> writes:
: A question which arises is, If the kernel calls the
: probe routine (in case of PCI)for all the devices
: attached to it during bus-enumeration, whats the point
: of having the device entries in GENERIC?

Smaller kernels can be created by omitting unwanted/unneeded devices.

: does the
: bus-dependent code call the probe routine of the
: device-driver,for only those devices which are
: mentioned in GENERIC file.

Only for those modules that are loaded, would be a better way to say
it.  The GENERIC file effectively specifies which modules to load by
creating a makefile that preloads them.

: I am writing a device driver for a memory mapped
: ethernet device.Does it HAVE to be attached to a
: bus?

Yes.  It must be attached to a bus.  The device, in hardware, is
attached to a bus by definition.  The software reflects this hardware
definition and requires that you attach it to a bus.  The word bus in
software just means that it has to attach somewhere.

: Its the only device I want to support(right
: now).Is it not possible to hard-code the probe-attach
: routine calls?

Not really, but creating a bus is easy.

: Can i attach it to nexus? OR Can I attach it to the
: PCI bus (though its not a PCI device) through some
: hack?

It would be better not to do that.

: This is not a i386 port hence the ISA bus is absent.
: Will i have to implement a pseudo-bus (write the
: bus-dependent code)in order to attach my device?

Ah, in that case, can you describe the hardware a little better?  I'm
always curious about non-i386 ports...

For the Atmel ARM AT91RM9200 port that I've been working on, we placed
all the devices that were on the SoC part in their own bus (called
atmelarm).  This bus manages the resources and attachment points for
all the devices on the atmel chip.  At the moment, I've hard coded the
devices that are present and add them (see src/sys/arm/at91/at91.c for
the details).  I'd like to make it even easier to create a generic-ish
bus like this, but this is the best example in the tree right now.

You could attach this to nexus, and hard wire the resources that the
ethernet driver uses.  This would be a quick and dirty way of dealing
to get things rolling, but isn't very flexible or expandable and will
likely bite you in the long run...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[Alok Barsode]

Hi,
Thanks for ur earliers replies. They helped me a lot
in understanding the newbus architecture.
I am involved in a freeBSD port to a freescale board.

I still had a few doubts:
I am looking at the autoconf.c file for the i386
architecture.

When i/o configuration is in progress during startup,
are the drivers for specific busses alreay assosciated
with them or the association happens at run time ?
for example :
when nexus is being attached to root_bus,
the method devclass_find_internal("nexus", 0, TRUE) is
invoked(in method make_device).Now does a nexus
devclass already exist ( it is created through the
macro DRIVER_MODULE(nexus, root, nexus_driver,
nexus_devclass, 0, 0);) or it is created at runtime ?

if it is created at runtime how the nexus_driver get
assciated with nexus?

Thanks,
Alok.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[M. Warner Losh]

In message: <20061006073434.71730.qmail@...>
            Alok Barsode <namaskar_alok@...> writes:
: Thanks for ur earliers replies. They helped me a lot
: in understanding the newbus architecture.
: I am involved in a freeBSD port to a freescale board.

Cool!  Remind me: is the freescale an arm design or a Power PC one?

: When i/o configuration is in progress during startup,
: are the drivers for specific busses alreay assosciated
: with them or the association happens at run time ?

The drivers are associated with the busses at compile time (as
extended via modules that are loaded).  The assignment of specific
device nodes to drivers is done at run time.

: for example :
: when nexus is being attached to root_bus,
: the method devclass_find_internal("nexus", 0, TRUE) is
: invoked(in method make_device).Now does a nexus
: devclass already exist ( it is created through the
: macro DRIVER_MODULE(nexus, root, nexus_driver,
: nexus_devclass, 0, 0);) or it is created at runtime ?
:
: if it is created at runtime how the nexus_driver get
: assciated with nexus?

nexus_driver gets associated with nexus here:

/*
 * Determine i/o configuration for a machine.
 */
static void
configure_first(dummy)
        void *dummy;
{
 
        /* nexus0 is the top of the i386 device tree */
        device_add_child(root_bus, "nexus", 0);
}
 
at least tenatively associated.  configure_first is run via the
SYSINIT at SI_SUB_CONFIGURE as the first thing.  In fact, all the
autoconf look similar in this respect.  The arm one does the same
thing.

If you look at sys/arm/at91/at91.c, you'll see code:

static void
at91_identify(driver_t *drv, device_t parent)
{

        BUS_ADD_CHILD(parent, 0, "atmelarm", 0);
}

which is how the atmelbus gets added to nexus.  Again, the atmelbus is
about the best example I can easily find in the tree...

Warner
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."

[Alok Barsode]

Hello,
I am working on FreeBSD 4.10.
I am looking at /net/hostcache.c.
The functions hc_insert(), hc_timeout, hc_rele and
hc_timeout access a structure called mono_time.
The search for this structure did not yield much
information.
I couldn't find the declaration of this particular
structure.(in FreeBSD6 its declared in
sys/netinet6/ipsec.c)  


Am I missing something?

Thanks,
Alok.



 
____________________________________________________________________________________
Sponsored Link

Degrees online in as fast as 1 Yr - MBA, Bachelor's, Master's, Associate
Click now to apply http://yahoo.degrees.info
_______________________________________________
freebsd-new-bus@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-new-bus
To unsubscribe, send any mail to "freebsd-new-bus-unsubscribe@..."