Merlin U630 problems, HP1448 with pcixx21 (was Re: [Bug 2944] Cardbus cards not seen on ti1620 cardbus controller)

Alex Kavanagh alex at tinwood.homelinux.org
Fri Apr 21 14:11:30 EDT 2006


Hi

At Thu, 20 Apr 2006 20:30:59 +0200 (CEST),
Bernhard Kaindl wrote:
> 
> On Thu, 20 Apr 2006, Alex Kavanagh wrote:
> 
> > I've applied the cardbus patch to a 2.6.16-ck3 kernel with an additional patch
> > that adds the detection of the U630 Merlin G3 card I have.
> ...
> > [4513524.668000] Yenta: CardBus bridge found at 0000:06:09.0 [103c:3080]
> > [4513524.669000] Yenta: Using CSCINT to route CSC interrupts to PCI
> > [4513524.669000] Yenta: Routing CardBus interrupts to PCI
> > [4513524.669000] Yenta TI: socket 0000:06:09.0, mfunc 0x01a01b22, devctl 0x64
> > [4513524.893000] Yenta: ISA IRQ mask 0x0cf8, PCI irq 16
> > [4513524.893000] Socket status: 30000086
> > [4513524.893000] Yenta: Raising subordinate bus# of parent bus (#06) from #06 to #0a
> 
> Indeed, this is the message which I expected, that part is fine as you also found.
> 
> > [4513543.023000] serial_attach()
> > [4513543.023000] serial_config(0xc76b6a00)
> > [4513543.024000] info->multi 1
> > [4513543.024000] S is 0, try is 0
> > [4513543.024000] port was found: io.BasePort1(0x 3f8), io.IOAddrLines(16)
> > [4513543.065000] Going to setup the serial port...
> > [4513543.087000] No idea what the port is.
> > [4513543.089000] serial8250_register_port: iobase(0x 3f8), membase(0x00000000), irq(3), iotype(0), flags(0x11000040)
> > [4513543.089000] Didn't fail configuration
> > [4513543.089000] ds: Checking if it's a pseudo device.
> > [4513543.090000] serial_attach()
> > [4513543.090000] serial_config(0xdda16e00)
> > [4513543.091000] info->multi 1
> > [4513543.091000] S is 0, try is 0
> > [4513543.091000] port was found: io.BasePort1(0x 2f8), io.IOAddrLines(16)
> > [4513543.131000] Going to setup the serial port...
> > [4513543.149000] No idea what the port is.
> > [4513543.150000] serial8250_register_port: iobase(0x 2f8), membase(0x00000000), irq(3), iotype(0), flags(0x11000040)
> > [4513543.150000] Didn't fail configuration
> > [4513543.150000] ds: Checking if it's a pseudo device.
> > 
> > My problem is basically that the actual serial port uarts are not
> > being detected.  Is this related to the Yenta issue?
>  
> No, my Yenta fixup patch is a PCI-bus-configuration-level fixup of the
> parent PCI bride thru which the Cardbus controller is connected to the
> PCI bus of your CPU.

Ah, good, I'm please that I don't need to look any further at that part.

> 
> That level has nothing to do (is far far away) from the kind of UART chip
> which is on your cardbus card. What the my Yenta fixup patch does is
> only that it reconfigures the parent PCI bridge of the all CardBus
> controllers supported by Linux.

Okay.  But does yenta (as a module) deal with configuring the pcixx21
register set to make it 'work' in some way.  e.g. mapping memory
windows, enabling/disabling features on the pcixx21 chip, etc?

> 
> Yenta obvoisly stands for match-maker, it's is integrated driver which
> suppors all the Linux-supported CardBus controllers, and "matches" the
> System with the Cards :-) : http://en.wikipedia.org/wiki/Yenta

Wow!  I love this kind of thing - I think it's a great name for a
piece of code.  So much better than cardbus-mapper or any other
derivation that I might have thought of!!

> 
> My Yenta patch just helps the Yenta to fix the system to make the
> CPU actually "see" CardBus card so they can get married :)
> 
> > was found: ...' line is a debug line where the serial_cs *thinks* it
> > found a port), from this bit of code:
> 
> > DEBUG(0, "port was found: io.BasePort1(0x%4x), io.IOAddrLines(%d)\n", link->io.BasePort1, link->io.IOAddrLines);
> 
> Good, so it at least finds the IO address port of the UART, it
> seems.

Well, I think so, but I'm not convinced, because the serial uart
detection code bails out without finding the 16650 that is supposed to
be on the card.
> 
> > My problem, and it's a lack of familiarity with how the kernel
> > schedules threads, is how the card insert event
> > (CS_EVENT_CARD_INSERTION) actually eventually runs the code that takes
> > the fact that the card has a function 2 (serial ?) and gets a driver
> > to locate the serial ports.
> 
> Not knowing how CS_EVENT_CARD_INSERTION actually runs the code does
> not appear to be a problem, your debug messages reaches the right
> place:

Thanks for confirming that.  I've reached the same conclusion.  I'm
spending hours looking at the code and trying to work out what happens
and when and tracing things through ...

I *think* I've found that there is an error on the CIS for the card
and I've managed to fix it and create an appropriate dummy firmware
for the card.  Now I'm trying to get the kernel to load it ... and
running into a wall trying to understand.  I put it in the place where
it says it should get loaded (/etc/firmware/cis) but the firmware
loader doesn't:  (e.g. with my added debug:)

[4632516.877000] ds: pcmcia_devmatch - before firmware (manfid =0x00a4, 0x0276
[4632516.877000] ds: pcmcia_devmatch - passed PCMCIA_DEV .... FAKE_CIS flag check
[4632516.877000] ds: trying to load firmware MerlinU630.cis
[4632516.961000] ds: firmware wasn't loaded, I think!

i.e. I've added a few debug messages around the firmware loading
stuff.  As soon as I've eliminated this CIS problem as an issue
(unless it fixes the issue), I'll be back to trying to work out if it
is a pcixx21 set up issue, a bug in serial_cs or plain serial or
something else.

If I get it fixed I will let people know.

Just out of interest, I had a problem with the serial_cs and getting
my CIS firmware detected.  Basically, there was already an entry for
the U630 card in serial_cs even though an additional patch has been
entered in the kernel for it.  I don't know if it is still there (I'm
adding it to my todo to check in the latest when I get a moment):

from serial_cs.c

	PCMCIA_DEVICE_MANF_CARD(0x0089, 0x0301),
/*	PCMCIA_DEVICE_MANF_CARD(0x00a4, 0x0276), */   <--- I commented
this out
	PCMCIA_DEVICE_MANF_CARD(0x0101, 0x0039),

....


	PCMCIA_DEVICE_MANF_CARD(0x0137, 0x0052),
	PCMCIA_DEVICE_PROD_ID134("ADV", "TECH", "COMpad-32/85", 0x67459937, 0x916d02ba, 0x8fbe92ae),
	PCMCIA_DEVICE_PROD_ID124("GATEWAY2000", "CC3144", "PCMCIA MODEM", 0x506bccae, 0xcb3685f1, 0xbd6c43ef),
	PCMCIA_DEVICE_PROD_ID14("MEGAHERTZ", "PCMCIA MODEM", 0xf510db04, 0xbd6c43ef),
	PCMCIA_DEVICE_PROD_ID124("TOSHIBA", "T144PF", "PCMCIA MODEM", 0xb4585a1a, 0x7271409c, 0xbd6c43ef),
	PCMCIA_DEVICE_PROD_ID123("FUJITSU", "FC14F ", "MBH10213", 0x6ee5a3d8, 0x30ead12b, 0xb00f05a0),
/*	PCMCIA_DEVICE_PROD_ID123("Novatel Wireless", "Merlin UMTS
Modem", "U630", 0x32607776, 0xd9e73b13, 0xe87332e), */

^^^^^ This is the one added from the patch into 2.6.16 
/*	PCMCIA_DEVICE_CIS_PROD_ID123("Novatel Wireless", "Merlin UMTS
Modem", "U630", 0x32607776, 0xd9e73b13, 0xe87332e, "MerlinU630.cis"),
*/
^^^^^ This is one I tried.

  PCMCIA_DEVICE_CIS_MANF_CARD(0x00a4, 0x0276, "MerlinU630.cis"),
^^^^ This is what I've ended up with 

Note that the MerlinU630.cis is my attempt at fixing the CIS - I'm not
sure if it works yet.

Cheers
Alex.



More information about the linux-pcmcia mailing list