Date: Fri, 27 Aug 2004 03:37:08 -0400 From: Mike Goumans <freebsd@nrw.ca> To: freebsd-mobile@freebsd.org Subject: Sierra Wireless Aircard 555 adventures Message-ID: <412EE4A4.3080607@nrw.ca>
next in thread | raw e-mail | index | archive | help
After reading the previous posts on the subject, and having one of these cards drop in my lap, I have decided to try and get this card working correctly in RELENG_5_2. I have reached somewhat of a stumbling block, mostly because I dont completely understand some of what is involved. After reading over the Linux and OSX fixes for this card, the best way to get it working as a serial device only, is to change the CIS information on the card. I have been trying to use cis quirks to accomplish the first task, which is changing the function id from network card to serial port. This was quite simple, but looking over the complete CIS information provided, it seems to also have to create its own set of cftable entries to direct the proper io addresses and irq mask for the card. This is where I am stuck. I dont understand the pccard_config_entry struct enough to make the proper changes. I have been making semi-educated guesses, but am still falling short. Below I am going to dump all the information that I think is somewhat valid in this endeavour, including what I think I'm missing and some other notes regarding it. The original tuple before any changes is as follows. cis mem map 0xda2be000 (resource: 0x88000000) pccard0: CIS tuple chain: CISTPL_DEVICE type=null speed=null 01 02 00 ff CISTPL_DEVICE_A type=eeprom speed=250ns 17 03 41 00 ff CISTPL_MANFID 20 04 92 01 55 a5 CISTPL_FUNCID 21 02 06 00 CISTPL_VERS_1 15 2a 07 00 53 69 65 72 72 61 20 57 69 72 65 6c 65 73 73 00 41 69 72 43 61 72 64 20 35 35 35 00 41 35 35 35 00 52 65 76 20 31 00 ff CISTPL_CONFIG 1a 05 01 03 00 07 73 CISTPL_CFTABLE_ENTRY 1b 09 c1 41 19 01 55 66 30 f8 ff CISTPL_END ff cis mem map da2be000 CISTPL_LINKTARGET expected, code ff observed pccard0: check_cis_quirks pccard0: CIS version PC Card Standard 7.0 pccard0: CIS info: Sierra Wireless, AirCard 555, A555, Rev 1 pccard0: Manufacturer code 0x192, product 0xa555 pccard0: function 0: network adapter, ccr addr 700 mask 73 pccard0: function 0, config table entry 1: I/O card; irq mask fff8; iomask 6, iospace 0-3f; rdybsy_active io8 io16 irqlevel pccard0: functions scanning pccard0: Card has 1 functions. pccard_mfc is 0 pccard0: I/O rid 0 start 0 end ffffffff pccard0: ccr_res == 88000000-880003ff, base=700 pccard0: function 0 CCR at 0 offset 700: 41 0 0 0, 0 0 0 0, 0 pccard0: <unknown card> (manufacturer=0x0192, product=0xa555) at function 0 pccard0: CIS info: Sierra Wireless, AirCard 555, A555 This shows the first major issue with getting this working, the fact that its telling the system its a network card. Now I looked at the Linux cis info from http://centerclick.org/aircard555/ /etc/pcmcia/cis/aircard555.cis: dev_info no_info attr_dev_info EEPROM 250ns, 512b manfid 0x013f, 0x0710 funcid serial_port vers_1 7.0, "Sierra Wireless", "AirCard 555", "A555", "Rev 1" config base 0x0700 mask 0x0073 last_index 0x03 cftable_entry 0x20 [default] io 0x03f8-0x03ff [lines=3] [8bit] [range] irq mask 0x3fbc [level] cftable_entry 0x21 io 0x02f8-0x02ff [lines=3] [8bit] [range] cftable_entry 0x22 io 0x03e8-0x03ef [lines=3] [8bit] [range] cftable_entry 0x23 io 0x02e8-0x02ef [lines=3] [8bit] [range] cftable_entry 0x24 io 0x0000-0x0007 [lines=3] [8bit] From the OSX driver change // Hack to replace CIS data cisdump_t cisinfo = { 122, { 0x01, 0x01, 0xff, 0x17, 0x03, 0x41, 0x00, 0xff, 0x20, 0x04, 0x3f, 0x01, 0x10, 0x07, 0x21, 0x02, 0x02, 0x00, 0x15, 0x2a, 0x07, 0x00, 0x53, 0x69, 0x65, 0x72, 0x72, 0x61, 0x20, 0x57, 0x69, 0x72, 0x65, 0x6c, 0x65, 0x73, 0x73, 0x00, 0x41, 0x69, 0x72, 0x43, 0x61, 0x72, 0x64, 0x20, 0x35, 0x35, 0x35, 0x00, 0x41, 0x35, 0x35, 0x35, 0x00, 0x52, 0x65, 0x76, 0x20, 0x31, 0x00, 0xff, 0x1a, 0x05, 0x01, 0x03, 0x00, 0x07, 0x73, 0x1b, 0x0b, 0xe0, 0x01, 0x18, 0xa3, 0x60, 0xf8, 0x03, 0x07, 0x30, 0xbc, 0x3f, 0x1b, 0x08, 0xa1, 0x01, 0x08, 0xa3, 0x60, 0xf8, 0x02, 0x07, 0x1b, 0x08, 0xa2, 0x01, 0x08, 0xa3, 0x60, 0xe8, 0x03, 0x07, 0x1b, 0x08, 0xa3, 0x01, 0x08, 0xa3, 0x60, 0xe8, 0x02, 0x07, 0x1b, 0x04, 0xa4, 0x01, 0x08, 0x23, 0x14, 0x00, 0xff, 0x00 } }; Extrapolating from the above, I have come up with the following equivlant in the standard way that the kernel dumps the cis ( THIS MAY BE COMPLETELY INCORRECT, AND I WOULDNT BE SURPRISED IF IT WAS ) CIS_TPL_DEVICE 01 01 FF CISTPL_DEVICE_A 17 03 41 00 ff CISTPL_MANFID 20 04 3f 01 10 07 CISTPL_FUNCID 21 02 02 00 CISTPL_VERS_1 15 2a 07 00 53 69 65 72 72 61 20 57 69 72 65 6c 65 73 73 00 41 69 72 43 61 72 64 20 35 35 35 00 41 35 35 35 00 52 65 76 20 31 00 ff CISTPL_CONFIG 1a 05 01 03 00 07 73 CISTPL_CFTABLE_ENTRY 1b 0b e0 01 18 a3 60 f8 03 07 30 bc 3f 1b 09 a1 01 08 a3 60 f8 02 07 1b 08 a2 01 08 a3 60 e8 03 07 1b 08 a3 01 08 a3 60 e8 02 07 1b 04 a4 01 08 23 14 00 ff CISTPL_END NULL?? I have yet to figure out what the changes in CIS_TPL_DEVICE actually do. I also can't figure out why the MANFID would be changed. I thought initially this was an attempt to just clone the MANFID from a currently working modem card. I checked and 0x013f is used by Racore Computer Products, which doesnt seem to make modem cards. I dont think that changing MANFID on this card is even useful in this instance, but anything is possible. Changing FUNCID from 06 (network) to 02 ( serial ) is straightforward. One part that I am not sure of ( because I do not know the standard structures of tuples, is does a FUNCID of 21 02 06 00 mean that its capable of both network and serial. Im assuming its not because of the change, but it would make sense if it did. To make this change, I created the following struct static struct pccard_function pccard_a555_func0 = { 0, /* function number */ PCCARD_FUNCTION_SERIAL, 0x4, /* last cfe number */ 0x700, /* ccr_base */ 0x73, /* ccr_mask */ }; I am not sure that the last cfe number is correct. The next changes are in the CFTABLE_ENTRY. This seems alot longer than the standard entry there, and this is where I am confused. I see from the Linux text cis file, that its creating 5 entries. Since the first ( last? ) byte is 1b, and its repeated 5 times, I'm assuming thats the start/end of the cftable entry. I can also see where the port addresses are written, and the entire entry makes perfect sense. What I dont know, is how to create the pccard_config_entry struct in pccard_cis_quirks to change the cftables properly. Do I only make a cfe0 ? do I have to make 0-4 because of the 5 different entries?. I tried duplicating it from the 3cxem556 entry and modifying it about 30 times with no success. I spent an incredibly long time trying to figure out why my changes in pccarddevs wasnt registering the card, but until I figured out until it has attached to a driver, its going to show up as <unknown card> The card is now detected as a serial port, assigned sio4, but because the cftable entries are not correct / complete, the port and irq assignments are wrong, the uart is not properly detected, and the system freezes. If required I can copy the final part of the screen I still see post lockup, but its just the incorrect port / irq assignments ( which im assuming what is held in the current CFTABLE ENTRY as its not being changed properly yet ) Any ideas on what the pccard_config_entry structs should look like in this case? I have tried going through the NetBSD changes for this file also, and I can see the changes that were made, but they make little sense to me because I cant see what the previous CIS looked like to compare it to, and I also dont have any information on the PCCARD specifications so this all has been just flying by the seat of my pants. Thanks alot, Mike Linux Fix Website http://centerclick.org/aircard555/ OSX Fix Patch http://www.cs.ucsd.edu/~snoeren/aircard555.patch
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412EE4A4.3080607>