I am a long time OpenBSD user and I run it on several servers/desktops.
Last friday I bought Lenovo IdeaPad S10S and I`ve already noticed, that - among some minor glitches - everything works reasonably good.
Everything but not the BCM4312 [probobly] chip-based WLan card.
Actually, it was hard to determine the card chipset, but I figured out other way.
The card is not being detected on on boot. The only interface I get is bge0, which stands for
the ether lan connector, not the actual WLan, which is usually bwi0, or something similar to this.
Anyway - do you have any info? How can I get this running?

When confronted with these types of issues, the best thing to do is play with apropos(1) & peruse the misc@ archives. This reveals that the relevant driver is bwi(4), & the following is what discussion has transpired in the archives:

From scanning this information, I would suggest updating the firmware as discussed in the manpage first. If this does not resolve problems, consider installing -current second since development is ongoing, & all improvements will be found in -current first. Thirdly, it has been true with many wireless vendors that they are often less than forthcoming about releasing information to the public, so reverse engineering is a very slow & time consuming process. In the case, patience is more than a virtue.

Thanks for the tips. That makes me doubting no more - there is no real support for this chipset yet. I just wanted to make sure.
Is there any way to check whether it`s rev. 1 or 2? I know for sure that it has been produced in nov/oct 2008.
BTW I`ve tried with OpenBSD snapshot, one of the recent; but it didn`t even bother to detect this chipset.
Not surprisingly it works with linux, in some distros it`s even available 'out-of-the-box', but I`d hate to stuck using linux and that`s not what I want to accomplish.

Actually, that was the first thing I did and there is no presence of "bwi*" or whatsoever.

Quote:

Search the manufacturer's Webpage.

Well, yes; but there`s only a linux driver.
BTW do you know of any possibility to run some sort of NDISWRAPPER on top of OBSD?

Quote:

As a last resort, determine whether you can find any distinguishing markings on the chip itself.

It`d be a case with the regular PC-set, but I don`t think dissasembling newly bought laptop [which is on a warranty] is a good thing, so I guess I`ll just wait. In the meantime - FreeBSD/NetBSD/Linux testing ...

BTW do you know of any possibility to run some sort of NDISWRAPPER on top of OBSD?

Part of the philosophy of OpenBSD is that no precompiled drivers not written by the OpenBSD developers themselves will ever be integrated into the core system. Such code is not open to inspection & is thus labeled "blobs". The chances of NDISWRAPPER ever being imported into OpenBSD are essentially nil.

Unfortunately, I can`t see anything related to this card/chipset, which is weird because I thought it`d show even unsupported HW, but well ...
I know OpenBSD philosophy quite well. It`s just that I didn`t have to configure any WLan on OBSD, so I couldn`t know the right way, or the possibilities.
I`m rather busy now, but on monday I`ll try to set the whole thing up with any firmware I can find and I`ll write about it.
BTW. I didn`t have much choice with this chipset, as it was just integrated with this notebook and there was not much I could do about it.

Unfortunately, I can`t see anything related to this card/chipset, which is weird because I thought it`d show even unsupported HW, but well ...

Where are you looking? please post the dmesg here in [code] blocks.. perhaps the issue is elsewhere.

Quote:

Originally Posted by marc

I`m rather busy now, but on monday I`ll try to set the whole thing up with any firmware I can find and I`ll write about it.

I don't understand, there is only 1 firmware package available that's compatible with the OpenBSD driver.. and it does NOT work with rev 2 devices. (...if you're unaware, a driver and a firmware are not the same)

Quote:

Originally Posted by marc

BTW. I didn`t have much choice with this chipset, as it was just integrated with this notebook and there was not much I could do about it.

That's the unfortunate situation with laptops/notebooks, most use MiniPCI or MiniPCI-E cards though.. replacement might be possible, baring any sort of BIOS whitelist.

I don't understand, there is only 1 firmware package available that's compatible with the OpenBSD driver.. and it does NOT work with rev 2 devices. (...if you're unaware, a driver and a firmware are not the same)

Yes, I know the difference between driver and firmware. I just remembered two types of FW packages, well; I must be wrong then.

Quote:

Note; most people use the character ' instead of ` for contractions.

Ahh, sure. I just used to this [I live in Poland - it might be an explanation ].

However, note that the developers will be more interested in reports on -current since from their perspective, OpenBSD 4.4 is quite old at this point. Ultimately, all that matters at this time is what is happening at the head of CVS.

At this time, OpenBSD 4.5 has already been labeled in CVS. If you install -current now followed by installing 4.5-release later, you will not potentially be getting new functionality. You might be losing functionality by taking this path.

Quote:

Well, maybe - as some folk suggested - there's a time to try FreeBSD+NDIS?

No, this dmesg(8) output comes from a snapshot dated 28 February. Tagging occurred around 2 March, so although what was installed is very close to 4.5-release, it isn't.

Nevertheless, BSDfan666 is correct is observing that if this kernel was not able to recognize the BCM4315 chipset, there is very little reason to install 4.5-release once it does become available. Chances are very good that nothing will have changed with respect to BCM4315 support.

The OP should simply follow discussion on misc@ to determine if & when work is completed which will support this particular chip.

You apparently haven't followed the tagging process in much detail in past releases. There are many shades of gray involved in cutting the CD images given that so many developers & platforms are involved along with ports stabilizing. Although the CVS Web interface showed the appearance of OPENBSD_4_5_BASE on 28 February, the increased frequency of snapshots which occurs around tagging continued through the first week in March up until the point where Theo went on vacation. The minor platforms typically see snapshot updates every 30+ days, so the appearance of daily snapshots is quite noticeable.

So quoting myself:

Quote:

Originally Posted by ocicat

This means that most of the functionality to OpenBSD 4.5 has been solidified, & (most likely) only major issues found within the next week will be pushed back into this branch.

I intentionally used language to grant myself wiggle room because I know from experience that tagging doesn't preclude showstopper issues from being checked in after tagging occurs. We saw this when 4.4 was tagged.

So sorry, buddy. No contradiction was made. You should apologize to the OP for hijacking his thread.