Jump to content

Intel Wireless 2100, 2200bg, 2915bg, 3945abg, 4965agn

jalavoui

By jalavoui,
in LAN and Wireless

 Share
3,411 posts in this topic

Recommended Posts

sbrungardt
sbrungardt
Posted
Posted
Feb 7 14:15:53 netwarriors-mac-pro kernel[0]: iwi3945: : BSM uCode verification failed at addr 0x00003800+0 (of 900), is 0xa5a5a5a1, s/b 0xf802020\

 

This looks to me like the driver's not accessing the hardware properly; that is to say that some of the settings isn't working right. As for the specifics, like what the BSM uCode is, I found the following in Wikipedia:

 

http://en.wikipedia.org/wiki/OpenBSM

 

And

 

http://en.wikipedia.org/wiki/Persistent_Un...esource_Locator

 

The nutshell of what it looks like to me is that the BSM is the Basic Security Module; probably a part of the device to ensure that the system has the proper rights to access it, and uCode looks to me like an abbreviation for Unicode, based on that second link. So, putting those together, if I had to hazard a guess I'd say that the way the driver is attempting to access the hardware, via Unicode or something similar, isn't passing a security audit on the device itself.

 

Of course, this is entirely speculation, but I hope it helps!

Link to comment
Share on other sites
jalavoui
jalavoui
Posted
  • Author
Posted

TNW,

 

i checked your code and find some things to fix:

 

>> in iwl_read_ucode()

you need to replace all IOMallocContiguous() by MemoryDmaAlloc()

if you use IOMallocContiguous() you'll get lots of firmware errors (as i got in iwi2200)

copy source code of MemoryDmaAlloc() from here and replace it in iwi3945

you should also replace it in iwl_tx_queue_alloc(), iwl_tx_queue_init(), iwl_hw_set_hw_setting() and iwl_rx_queue_alloc()

 

or

you can try this

instead of using

priv->ucode_code.v_addr=IOMallocContiguous( priv->ucode_code.len, sizeof(__le32)

try

priv->ucode_code.v_addr=IOMallocContiguous( priv->ucode_code.len, sizeof(__le32*)

 

but i'm shure MemoryDmaAlloc() is much better

 

 

>> in iwl_send_cmd()

remove this line - if the driver can't send commands we should not force it

if (rc==HOST_COMPLETE_TIMEOUT) priv->status &= ~STATUS_HCMD_ACTIVE;//hack

i have a problem with IODelay(HOST_COMPLETE_TIMEOUT) - be shure you don't get firmware errors because of this

 

>> in init()

if you like to change the debug messages change the values in here

this need to be fixed later when the driver is ready to show less debug messages

 

>> this is the function from iwi2200 you should replace in iwi3945

IOBufferMemoryDescriptor*

darwin_iwi2200::MemoryDmaAlloc(UInt32 buf_size, dma_addr_t *phys_add, void *virt_add)

{

IOBufferMemoryDescriptor *memBuffer;

void *virt_address;

dma_addr_t phys_address;

IOMemoryMap *memMap;

 

memBuffer = IOBufferMemoryDescriptor::inTaskWithOptions(kernel_task,

kIODirectionOutIn | kIOMemoryPhysicallyContiguous |

kIOMapInhibitCache | kIOMemoryAutoPrepare , buf_size,

PAGE_SIZE);

 

 

 

memMap = memBuffer->map();

 

if (memMap == NULL) {

IWI_DEBUG("mapping failed\n");

memBuffer->release();

memBuffer = NULL;

 

return NULL;

}

 

if (phys_add!=NULL)

phys_address = memMap->getPhysicalAddress();

 

if (virt_add!=NULL)

{

virt_address = (void *)memMap->getVirtualAddress();

 

if (virt_address == NULL || phys_address == NULL) {

memMap->release();

memBuffer->release();

memBuffer = NULL;

 

return NULL;

}

}

if (phys_add!=NULL) *phys_add = phys_address;

if (virt_add!=NULL) *(IOVirtualAddress*)virt_add = (IOVirtualAddress)virt_address;

memMap->release();

 

return memBuffer;

}

 

>> change the code in networkSelector.xcodeproj to allow the user to turn the card on/off

try to find a way to make it show the scan results

 

>> copy the code from iwi2200 of nsGUI.xcodeproj

it will not work in iwi3945 but it's the latest version

with some changes you can use it in iwi3945

 

you should use the iwidarwin tree to commit you changes in code

this will make it easier for developers to check your code

you'll need to install Subversion-1.4.3.pkg for svn acess

and RapidSVN.app to commit your changes

i think you should create a folder called "iwi3945-osx10.5" in "trunk" in the svn tree for your project

 

 

iwi3945

please post logs to help developers understand what the driver is doing

saying "it doesn't work" doesn't help at all

Link to comment
Share on other sites
nexus665
nexus665
Posted
Posted
[...], and uCode looks to me like an abbreviation for Unicode, based on that second link. So, putting those together, if I had to hazard a guess I'd say that the way the driver is attempting to access the hardware, via Unicode or something similar, isn't passing a security audit on the device itself.

 

Of course, this is entirely speculation, but I hope it helps!

Hiya,

uCode is a common way to abbreviate Microcode, like in uTorrent (microTorrent). Usually it's not really a u but a micro sign (u with the left side elongated below). Nothing to do with Unicode, really :D

 

µ is the one it represents - HTH.

 

Now for some working wireless drivers :wacko: Thanks for your work up to now, Jalavoui, symuc and TNW!

Link to comment
Share on other sites
TNW
TNW
Posted
Posted

Hi I think the probleme is that we have too many interruptions ...

 

If I made interupts myself (2 on log) I've this

 

iwi3945: iwl_pci_probe *** LOAD DRIVER ***

iwi3945: iwl_pci_probe iwl3945: Detected Intel PRO/Wireless 3945ABG Network Connection

iwi3945: iwl_set_rxon_channel Staging channel set to 6 [3]

iwi3945: iwl_read_ucode f/w package hdr ucode version = 0x20e0004

iwi3945: iwl_read_ucode f/w package hdr runtime inst size = 80524

iwi3945: iwl_read_ucode f/w package hdr runtime data size = 32768

iwi3945: iwl_read_ucode f/w package hdr init inst size = 2668

iwi3945: iwl_read_ucode f/w package hdr init data size = 32768

iwi3945: iwl_read_ucode f/w package hdr boot inst size = 900

iwi3945: iwl_read_ucode Copying (but not loading) uCode instr len 80524

iwi3945: iwl_read_ucode uCode instr buf vaddr = 0x0x1acc8000, paddr = 0x037f1000

iwi3945: iwl_read_ucode Copying (but not loading) uCode data len 32768

iwi3945: iwl_read_ucode Copying (but not loading) init instr len 2668

iwi3945: iwl_read_ucode Copying (but not loading) init data len 32768

iwi3945: iwl_read_ucode Copying (but not loading) boot instr len 900

iwi3945: iwl_pci_probe Queing UP work.

iwi3945: iwl_hw_nic_init DEBUG

iwi3945: iwl_hw_nic_init HW Revision ID = 0x2

iwi3945: iwl_hw_nic_init ALM-MM type

iwi3945: iwl_hw_nic_init SKU OP mode is basic

iwi3945: iwl_hw_nic_init 3945ABG revision is 0xF1

iwi3945: iwl_hw_nic_init Card M type B version is 0x2

iwi3945: iwl_hw_nic_init SW RF KILL supported in EEPROM.

iwi3945: iwl_hw_nic_init HW RF KILL supported in EEPROM.

iwi3945: iwl_hw_nic_init Rx queue [ALOCATED]

iwi3945: power state (1)

iwi3945: configureInterface

darwin_iwi3945: Ethernet address 00:13:02:15:d8:12

iwi3945: ifnet_t en4 = 318f004

iwi3945: ifconfig up

iwi3945: ifconfig going up

iwi3945: ifconfig down

iwi3945: ifconfig going down

: Grabbing access while already held at line 892.

iwi3945: iwl_hw_nic_init DEBUG

iwi3945: iwl_hw_nic_init HW Revision ID = 0x2

iwi3945: iwl_hw_nic_init ALM-MM type

iwi3945: iwl_hw_nic_init SKU OP mode is basic

iwi3945: iwl_hw_nic_init 3945ABG revision is 0xF1

iwi3945: iwl_hw_nic_init Card M type B version is 0x2

iwi3945: iwl_hw_nic_init SW RF KILL supported in EEPROM.

iwi3945: iwl_hw_nic_init HW RF KILL supported in EEPROM.

iwi3945: iwl_hw_nic_init Rx queue [RESETED]

iwi3945: iwl_load_bsm Begin load bsm

iwi3945: iwl_verify_bsm Begin verify bsm

iwi3945: iwl_verify_bsm BSM bootstrap uCode image OK

iwi3945: iwl_load_bsm BSM write complete, poll 1 iterations

iwi3945: iwl_up MAC address: 00:13:02:15:d8:12

iwi3945: connect

2

inta 0x80000009, enabled 0x00000000, fh 0x00010000

iwi3945: iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x9

iwi3945: iwl_rx_reply_alive Initialization Alive received.

iwi3945: iwl_rx_handle r = 1, i = 0, rx_handler REPLY_ALIVE

iwi3945: iwl_verify_inst_sparse ucode inst image size is 900

iwi3945: iwl_verify_inst_sparse ucode inst image size is 2668

iwi3945: iwl_verify_ucode Initialize uCode is good in inst SRAM

iwi3945: iwl_init_alive_start Initialization Alive received.

iwi3945: iwl_set_ucode_ptrs Runtime uCode pointers are set.

2

inta 0x80000009, enabled 0x00000000, fh 0x00010000

iwi3945: iwl_rx_reply_alive Alive ucode status 0x00000001 revision 0x1 0x0

iwi3945: iwl_rx_reply_alive Runtime Alive received.

iwi3945: iwl_disable_events Selected uCode log events may be disabled

iwi3945: iwl_disable_events by writing "1"s into disable bitmap

iwi3945: iwl_disable_events in SRAM at 0x8015f4, size 47 u32s

iwi3945: iwl_rx_handle r = 2, i = 1, rx_handler REPLY_ALIVE

iwi3945: iwl_alive_start Runtime Alive received.

iwi3945: iwl_verify_inst_sparse ucode inst image size is 900

iwi3945: iwl_verify_inst_sparse ucode inst image size is 2668

iwi3945: iwl_verify_inst_sparse ucode inst image size is 80524

iwi3945: iwl_verify_ucode Runtime uCode is good in inst SRAM

iwi3945: iwl_alive_start RFKILL status: 0x1

iwi3945: iwl_init_channel_map Initializing regulatory info from EEPROM

iwi3945: iwl_init_channel_map Parsing data for 56 channels.

iwi3945: iwl3945: Tunable channels: 13 802.11bg, 23 802.11a channels

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_BT_CONFIG (#9b), seq: 0x0400, 16 bytes at 0[0]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: iwl_commit_rxon Sending RXON

* without RXON_FILTER_ASSOC_MSK

* channel = 1

* bssid = 00:00:00:00:00:00

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_RXON (#10), seq: 0x0401, 48 bytes at 1[1]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_TX_PWR_TABLE_CMD (#97), seq: 0x0402, 56 bytes at 2[2]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: iwl_add_station Adding STA ID 24: ff:ff:ff:ff:ff:ff

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_ADD_STA (#18), seq: 0x0403, 68 bytes at 3[3]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: : Error: Response NULL in 'REPLY_ADD_STA'

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_TX_LINK_QUALITY_CMD (#4e), seq: 0x0404, 60 bytes at 4[4]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: iwl3945_init_hw_rate_table Select G mode rate scale

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_RATE_SCALE (#47), seq: 0x0405, 56 bytes at 5[5]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: : iwl_equeue_hcmd ---------------------

iwi3945: iwl_enqueue_hcmd Sending command REPLY_RATE_SCALE (#47), seq: 0x0406, 56 bytes at 6[6]:4

iwi3945: iwl_enqueue_hcmd iwl_tx_queue_update_write_ptr()

iwi3945: iwl_alive_start ALIVE processing complete.

Link to comment
Share on other sites
jalavoui
jalavoui
Posted
  • Author
Posted

TNW,

 

check this linux log

http://forum.insanelymac.com/index.php?sho...;p=479426

 

you don't need iwl_update_power_cmd -> but you can try

 

try to disable checkfirstup()

in older versions i use networkselector to turn the card on/off and call iwl_bg_up()

 

you might have a bug on the REPLY_ADD_STA handling

 

i think the linux log will help you to check what the driver should do

Link to comment
Share on other sites
jalavoui
jalavoui
Posted
  • Author
Posted
When the driver is activated lot of interuption come :/

 

yes because in start() you have checkfirstup() wich calls iwl_bg_up()

if this is the problem just remove checkfirstup()

but youl'll need to use networkselector to turn the card on - or - you can try to press the switch button

 

it's normal to get lots of interrupts -> see the linux log

you can check the IODelay(HOST_COMPLETE_TIMEOUT) if you think the interrupts are coming to fast

 

i think the driver is going in the right direction :)

Link to comment
Share on other sites
BlackCH
BlackCH
Posted
Posted

Great job guys. I hope you get it working (3945).

 

In the meantime I attach a few logs. The Zip contains ioreg, dmesg, system log, and a profiler screenshot using the kext from post 64.

 

the other is a system log using the kext from post 69. This one doesnt let me boot, but I managed to copy the log from the command line as -s user.

 

keep it up!

post64.zip

System.Post69.rtf

Link to comment
Share on other sites
TNW
TNW
Posted
Posted

I'm fine now ^^

there is a KP on iwl_enqueue_hcmd in base.c

 

 

if some have the time for =)

 

you have just to put a return after a line in iwl_enqueue_hcmd() and test , if it's ok put it after another line ...again and again ... it's crappy ,I know XD

Link to comment
Share on other sites
sbandol
sbandol
Posted
Posted

Hi guys,

 

I've just instaled last realease of the driver , and i have the folowing problem

in the network selector i got this text:

 

Last login: Fri Feb 8 01:00:20 on console

/Users/alexbandol/Desktop/networkSelector ; exit;

alex-bandols-mac-pro:~ alexbandol$ /Users/alexbandol/Desktop/networkSelector ; exit;

Could not get ID for kernel control. 2

logout

 

[Process completed]

 

 

when i normaly boot to mac i got the kernel panic , then i booted with -v -s and its booted fine but stil no network and the same text in network selector.

 

mayby i didnt install it good, i just used

 

i'm using a kalyway 10.5.1 on a Thinkpad R61

 

if other info needed i'm ready to offer them...

 

Than you ...

Link to comment
Share on other sites
sbandol
sbandol
Posted
Posted

Hi TNW and others,

 

Like i have posted before , i didnt succed to instal this driver (i dont see the network adapter in about this mac) , so i'm asking you if you can write a step-by-step to instal tutoril,

 

 

I will be honest , i'm a windows user trying to swith to mac so i dont even know exactly how to use a .kext file .

Thats way im asking that tutorial.

 

Thank you in advance, i know writing a tutorial is not the most interesting thing.

Link to comment
Share on other sites
antaholics
antaholics
Posted
Posted

jalavoui and TNW,

 

Thanks for all the work on these drivers! I'm really glad people are working on this!

 

However, I have a Intel wireless 4965... and there doesn't seem to be any news on that ATM. Is the 3945 driver supposed to be really similar? If the 3645 driver eventually works, will it work for 4965 too?

 

Thanks!!

Ant

Link to comment
Share on other sites
Symuc
Symuc
Posted
Posted

Wow, it looks as though a lot has happened while I've been away. Good job TNW.

 

I've got a question for javaloui, now: in working on getting minimally-modified drivers to do something. Anything. Right now they compile, but I'm coming up with compatability routines, for example a function called pci_free_consistent that actually calls IOFreeContiguous. So far, with the exception of replacing all instances like skb->data with a call to skb_data() (then writing a function skb_data()) and stripping the Linux-specific include files, it is working entirely without modification.

 

Do you think this is a viable, beneficial approach?

Link to comment
Share on other sites
@irBOrNE
@irBOrNE
Posted
Posted

Wow, I accidentally lost my link to this forum topic and MAN was it hard to find! The search function in this forum is pretty useless at times. Anyway, defaulting back to a good old google search eventually got me here.

 

jalavoui - you might want to update the forum link to this on your http://code.google.com/p/iwidarwin/ page.

 

TNW and Symuc - make sure to work together on this, your combined knowledge will get you a much faster and better end product than trying to go separate routes in my opinion.. jalavoui, you're doing a fantastic job keeping it all tied together, thanks.

Link to comment
Share on other sites
darval
darval
Posted
Posted
I'm booring =_= by this !#@ driver ...if someone can help me to dev this ...I've got problem with the interrupts but I dont't what ...I compiled the iwi2200 for leo ... but i can't test it...
I just tried this with a fair amount of success. It loads (no KP at least), sees the network (using nsGUI) and lets me connect. It looks like it has a problem when it tries to get the address setup (dhcp wise). Log files attached.
Do you think this is a viable, beneficial approach?
If the driver designs are compatible enough to make this work "fairly" easily, this is a fantastic approach. It allows the linux community to maintain the driver and us to gain the advantage if they make changes, improvements, bug fixes, etc..If you want some help with that, let me know. I have done some linux driver work, but am new to it in OSX.

logs.zip

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...