[oi-dev] Broadcom BCM4312 wireless on OpenIndiana 64-bit

Jean-Pierre jean-pierre.andre at wanadoo.fr
Fri Mar 22 14:54:59 UTC 2013


Hi,

Jim Klimov wrote:
> On 2013-03-21 21:28, Jean-Pierre André wrote:
>> Hi Jim,
>>
>> Can you please post the unanswered questions on the
>> mailing list, so that I replay publicly to-morrow, avoiding
>> the same questions to be asked by other users ?
>
> Ok, comments and questions inline below.
>
>>
>> Jim Klimov wrote:
>>> Sorry, I typo'd. My PCI ID was 14e4,4727 (not 4327).
>>>
>>> Anyhow, the Dell driver INFs that I used (from R....exe download)
>>> and that likely you used, don't list this ID. The newer Lenovo
>>> (also used under Windows on the same laptop) and HP Broadcom
>>> drivers include the ID, but failed to build into a binary that
>>> can be modload'ed (same missing symbols). I tried those "-N -dy"
>>> flags to no avail, too.
>>
>> I understand the -N option has to be followed by the
>> dependencies, you should probably use something like
>> -N misc/mac -N misc/ndisapi
>
> I tried that initially, but, apparently, that caused the linker
> to try using a file named "./misc/ndisapi" as one of the objects
> in the resulting bcmndis - which failed to link (absent file,
> and even when I forged this by symlinks - incorrect object file).
> I am not sure now what was the cause - the "man ld" page on OI
> agrees that "-N string" should specify the dependencies. Maybe it
> used a wrong "ld"?.. I'll look with greater attention next time.

I have tried : "/usr/bin/ld -r -dy -N misc/ndisapi -N misc/mac -o 
bcmndis.try driver.o if_ndis.o"
with ld from the oi_151a5 install DVD :
linux at openindiana:~/broadcom/devel$ ls -l /usr/bin/ld
-rwxr-xr-x   1 root     bin        18020 Sep 12  2011 /usr/bin/ld
and this creates the output bcmndis.try with the .dynamic section
with the correct dependencies on misc/ndisapi and misc/mac.

However this use of "-N" is not what is described in "man ld",
so there remains some mystery about it.

Also, in your log there are missing symbols which cannot
be caused by the ndis emulator. For instance the symbol
IoRegisterPlugPlayNotification is mentioned as unresolved,
but this symbol appears nowhere in the emulator, you were
probably using a recent driver with requires more functions
to be emulated.

>> There is another kind of error in your message.zip about
>> illegal relocations : this is probably caused by driver.s
>> being assembled in 32-bit mode. Try using option -m64.
>
> Makes sense, I'll see if that helps. However, about other object
> files (made from *.c) the linker did complain explicitly if they
> were ELFCLASS32 trying to combine with ELFCLASS64, that's how
> most of those -m64 flags got into my fixed Makefile ;)

Oh yes. The log mentions a relocation of type R_AMD64_32, which is
a relocation in 64-bit mode, but it is a 32-bit relocation which
cannot be used in a driver (it can only be used in the lower 2GB
of memory), so some compilation option must be missing.

I am stunned about changes which have to be made in the original
Makefile which was supposed to be correct.

My expertise on OpenIndiana is too weak to help you on such
matters.

>>> BTW, an interesting observation: while your binary module does
>>> modload (though useless for my chip), modunloading it panics the
>>> kernel. This is probably not worth much investigation now, but
>>> still an interesting "feature" to know about...
>>
>> I do not have that, must be caused by the
>> hardware not being recognized.
>
> Ok, good to know.
>
>>> Apparently, your builds on Linux are for some reason more
>>> capable than those on OI. Maybe that's the essential difference
>>> between ndis-1.2.6 and older ones?..

Following you suggestion I have rebased my modifications on
ndis-1.2.6, and I did not meet in the build process any major
difference from ndis-1.2.2 (the one which I posted and which
you used).

On my computer the version based on ndis-1.2.6 sometimes
panics, and I do not know why. I will post a new tarball
if I can fix it.

>> The .inf file provides the needed parameters for each
>> supported device. You definitely cannot use a piece
>> of hardware not described in the .inf (which is compiled
>> into bcmndis). You may try merging the data from the
>> .inf valid for id 0x4727, but this would much depend
>> on the hardware compatibility.
>>
>> Also please note that drivers for Windows 7 use a newer
>> version NDIS6, whereas ndis-1.2.x emulates the older
>> version NDIS5. They are said to be much different and
>> not compatible, but I have not tested myself.
>
> Ok. Since none of the drivers worked for me yet, I can only report
> that "by the look of things" they built cleanly. But didn't work :)

I am unlikely to do anything specific for a hardware I do
not have myself, so I will probably stop there and just
use my own solution, unless somebody else contributes.

Another possible way is to adapt the driver which Broadcom
makes available for Linux (as a relocatable module, same
format as on OpenIndiana). However this could be a big task
as there are about 900 imported symbols to implement, so
there must be a clear need... and contributors.

Regards

Jean-Pierre





More information about the oi-dev mailing list