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

[Jim Klimov]

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.

> 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 ;)


>> 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?..
>
> 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 :)

Thanks,
//Jim