Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Mar 2004 16:09:44 -0500
From:      John Baldwin <jhb@FreeBSD.org>
To:        freebsd-current@freebsd.org
Cc:        othermark <atkin901@yahoo.com>
Subject:   Re: puc(4) device not attaching issue in -current
Message-ID:  <200403291609.44559.jhb@FreeBSD.org>
In-Reply-To: <c49g08$lf0$1@sea.gmane.org>
References:  <c3qbq4$s0n$1@sea.gmane.org> <200403241430.29558.jhb@FreeBSD.org> <c49g08$lf0$1@sea.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 29 March 2004 10:39 am, othermark wrote:
> John Baldwin wrote:
> > On Tuesday 23 March 2004 05:58 pm, othermark wrote:
> >> Doug White wrote:
> >> > On Tue, 23 Mar 2004, othermark wrote:
> >> >> none0@pci0:6:1: class=0x070002 card=0x00000000 chip=0x01811407
> >> >> rev=0x00 hdr=0x00
> >> >>     vendor   = 'Lava Computer Manufacturing Inc'
> >> >>     device   = 'Lava Octopus PCI Ports 5-8'
> >> >>     class    = simple comms
> >> >>     subclass = UART
> >> >>
> >> >> device 6.1 has chip 0x018111407=and pucdata.c has only has an entry
> >> >> for 0x0180, so I'm not sure how it was picking up 0x0181 in earlier
> >> >> releases, or that it still does and something else is blocking it
> >> >> from happening...
> >> >
> >> > What happens if you add that PCI ID to the driver?
> >>
> >> If I add a duplicate the entry in pucdata.c so it looks like this:
> >>
> >>
> >>         /* Lava Computers Octopus-550 serial ports */
> >>         {   "Lava Computers Octopus-550 8-port serial part B",
> >>             NULL,
> >>             {   0x1407, 0x0181, 0,      0       },
> >>             {   0xffff, 0xfffc, 0,      0       },
> >
> > The 0xfffc is a mask meaning that this matches 0x0180, 0x0181, 0x0182,
> > and 0x0183 by the way, so you don't need an extra entry.  Can you do a
> > boot -v? I'm curious if the second device has its BAR's setup.
>
> I've attached a verbose boot to this message.   How do you tell if the BAR
> is setup or not?

The map lines for the dump of PCI config registers.  Here is your working 
device:

$PIR: 0:5 INTA routed to irq 5
found->	vendor=0x1407, dev=0x0180, revid=0x00
	bus=0, slot=5, func=0
	class=07-00-02, hdrtype=0x00, mfdev=1
	cmdreg=0x0001, statreg=0x0480, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=5
	map[10]: type 4, range 32, base 0000f888, size  3, enabled
	map[14]: type 4, range 32, base 0000f890, size  3, enabled
	map[18]: type 4, range 32, base 0000f898, size  3, enabled
	map[1c]: type 4, range 32, base 0000f8a0, size  3, enabled

And below it is the one that isn't working:

$PIR: 0:5 INTA routed to irq 5
found->	vendor=0x1407, dev=0x0181, revid=0x00
	bus=0, slot=5, func=1
	class=07-00-02, hdrtype=0x00, mfdev=1
	cmdreg=0x0001, statreg=0x0480, cachelnsz=0 (dwords)
	lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
	intpin=a, irq=5
	map[10]: type 1, range 32, base feaff000, size 12, enabled
	map[14]: type 4, range 32, base 0000fc40, size  6, enabled
	map[18]: type 1, range 32, base fe700000, size 20, enabled

Note that the working one has 4 BARs (10, 14, 18, and 1c) that are all I/O 
ports (type 4) and 8 bytes long (2 ^ size).  The second one only has 3 bars 
(10, 14, and 18), of which only the second is an I/O port (the other two are 
memory) and which have very different sizes.  There must be some other way to 
talk to the other 4 ports or perhaps the board needs to be configured somehow 
in order to work.

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200403291609.44559.jhb>