Date: Mon, 12 Apr 2004 09:06:27 -0700 From: othermark <atkin901@yahoo.com> To: freebsd-current@freebsd.org Subject: Re: puc(4) device not attaching issue in -current: WORKING Message-ID: <c5eeq3$7lo$1@sea.gmane.org> References: <c3qbq4$s0n$1@sea.gmane.org> <200403241430.29558.jhb@FreeBSD.org> <c49g08$lf0$1@sea.gmane.org> <200403291609.44559.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
(saved for context, see comments below).
John Baldwin wrote:
> 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.
I believe the recent PCI Heads UP commit fixed my other 4 BARs since it now
detects it and attaches properly. I can now get FASTINTR to work with APIC
on this card too. Unfortunately APIC breaks my USB mouse, so I have to
revert to using it as PS/2.
--
othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c5eeq3$7lo$1>