Hi,
dmesg and console screen is full of with repeated messages. 
wpi0: could not read firmware file
I think this is kernel related and i have updated whole src/* yesterday =

Using 4.99.31
Is this a bug?
Regards,

--

View this message in context: http://www.nabble.com/wpi0%3A-could-not-read-firmware-file-tf4561941.htm...

Sent from the tech-kern mailing list archive at Nabble.com.

On Wed, 3 Oct 2007 06:52:43 -0700 (PDT)
I don't think so. Try installing the wpi-firmware2 pkg from pkgsrc...
--

Juan Romero Pardines	- The NetBSD Project

http://plog.xtrarom.org	- NetBSD/pkgsrc news in Spanish

By the way, Openbsd has fully open source driver for wpi. You can check

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/ page.
Is not it possible to adopt that driver to netbsd?
Regards,
--

View this message in context: http://www.nabble.com/Re%3A-wpi0%3A-could-not-read-firmware-file-tf45624...

Sent from the tech-kern mailing list archive at Nabble.com.

Good evening,
NetBSD's driver is exactly that: a port of the driver from OpenBSD.
HTH,

--

khorben

Good evening,
NetBSD's driver is exactly what you mean, a port of the one from OpenBSD.
HTH,

--

khorben

OK thanks, what confused is me that, i suppose this is somehow part of the

driver and it is binary ie; part of the driver is open source while a key or

license (or something similar) part of it is binary and open source section

requires binary part because of license type etc... This means, in the end,

it has blob part to work properly.
Regards,
--

View this message in context: http://www.nabble.com/Re%3A-wpi0%3A-could-not-read-firmware-file-tf45624...

Sent from the tech-kern mailing list archive at Nabble.com.

This is not a blob in the sense that it could be potentially dangerous

since the firmware only runs on the card and nothing of that is run on

your computer. All network cards have firmware, some you can flash

yourself and some is resident in ROM on the card (e.g you can not

change it or even read it).
BR

dunceor

Your network card IS in your computer.

If your network card can access memory (and it _must_ be able to, or it

would be mostly useless), then it _is_ potentially dangerous.  It could

probably fairly easily dump anything in RAM over the network to some

other machine.
eric

And this makes it non-dangerous..how, exactly?  Do you never send

anything over your network interfaces or something?  The firmware is

perfectly positioned to meddle with and/or snoop on anything sent or
Only if the DMA mapping is set up to allow it access to that RAM - or

if your machine is so stupidly designed that a DMA bus master can

access memory it hasn't specifically been set up with access to.  While

there are undoubtedly such systems, I would hope that nothing using a

wpi would be quite that low-end.
I do, however, know that it's not going to be used on *my* systems.  (I

won't use an ath either, because of the lack of source to the HAL.)
/~\ The ASCII				der Mouse

\ / Ribbon Campaign

 X  Against HTML	       mouse@rodents.montreal.qc.ca

/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

To really prevent this, you need an MMU between the expansion bus and

the main memory.  While some systems have been built that way for a long

time (e.g. sparc64) others have not: this feature only really began to

appear on i386 systems as the AGP GART, which isn't really flexible

enough to offer the protection needed in this case, and has only really

been present on any common i386 or amd64 system within the past couple

of years -- and AMD and Intel do it differently, and we don't support

either; nor do most other operating systems.
In sum, PCI DMA on most systems with PCI is direct to host memory addresses

and there's no protection mechanism in between.  A malicious device can write

whatever part of host memory it cares to.

It is an exceptional machine that lets you protect memory from bus masters

in this way.  You may find an IOMMU in most 64-bit, non-x86 machines.
AMD says it will introduce an IOMMU in 2009 (used to say 2007).  In the

mean time, AMD's AGP GART can rudimentarily protect memory from PCI

bus masters.
Dave
--

David Young             OJC Technologies

dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24

Sorry, but this is completely bull shit. This "blob" is exactly the same

as a ROM image with the only difference that it is uploaded by the

driver to the card. Do you remove all ROM chips from the hardware you

own? Do you write your own microcode patches for the CPUs?
How do you know that a vendor doesn't have the same backdoors you seem

to fear so much in the ASIC?
Joerg

Joerg,
You are mistaken when you put WiFi firmware in the same category as ROM

chips, microcode, and ASICs.
An ASIC is designed and tested with a lot higher standards than a firmware

is.  You cannot fundamentally change an ASIC's role or performance,

not even temporarily, by exploiting its defects to rewire the gates; you

can exploit a defective firmware to introduce new program instructions.

Firmwares ordinarily add complexity to a microcontroller-based WiFi

that is way out of proportion to what is necessary to use the chip.

Bugs accompany that complexity, but documentation does not.
A ROM BIOS ordinarily has to meet some industry standard, such as

compatibility with the IBM PC and a panoply of extensions (PCI BIOS,

APM, ACPI, ...).  The host side of a WiFi interface needs to meet

PCI standards, but that's all.  There are no objective standards

of interface quality, so anything goes: if the programmer of the

Linux/Windows device driver and the programmer of the firmware can produce

something that works together through a thousand half-measures and some

mutual accomodation---the documentation and the 3rd-party drivers be

damned---then the quality of the firmware will be very low.
Microcode is similar in some respects to ROM BIOS (microcode for IEEE

floating-point math, say, has to meet standards in paper doco) and to
We do not know, but I think that it is prudent to regard an opaque

WiFi firmware that is operating with a 3rd-party device driver as less

trustworthy than either a ROM implementing industry standards or an ASIC.
Dave
--

David Young             OJC Technologies

dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24

It depends. I can understand some of the reasons to put things in the

firmware, the biggest being that it avoids the driver having to deal

with environment specific issues that are very specific to individual

versions of a device. Given all the interactions necessary for good
Fact is, that pure ROM is dying out at least in the consumer sector. If

possible, it gets replaced with loadable firmware images to save money.

Otherwise EEPROM is used. Looking at all the issues for example in ACPI

land that are still resolved by "Update your BIOS", I don't buy the

argument about a ROM implementing industry standards is more

trustworthy. While it is certainly a drive for higher quality it is also

not unlikely to just document the bugs in the ROM image or the ASIC and

expect driver authors to deal with that. The workaround lists in certain

network drivers like bge(4) speak for that or just consider all the

ASICs that *still* don't get all cases of IP checksumming correct. With

firmware images there is at least some change to see that fixed.
About the specific hardware in question -- I don't think there's any

recent WiFi hardware that doesn't have either an EEPROM chip or requires

a load of microcode or a firmware image. Of the three obvious contenders

in this area, Intel has the firmware, Atheros the blob image and Ralink

the microcode. Intel has done a lot of stupid and bad things with the

firmware like constantly changing interfaces. Sure, they should die for

that. They should learn that a Linux driver is no replacement for QA.

But I still maintain that arguing "because it uses a firmware image" is

wrong. I bet that almost noone beside those involved in the driver would

have known about the "issue", if Intel would allow redistribution. Would

you know that Ralink devices require microcode without looking at the

man page or inside /libdata?
Joerg

Joerg,
Do you think you can bring an example of a WiFi firmware with a stable ABI

and documentation, without long-lived and notorious bugs, that strikes

a balance of responsibilities between the host and the microcontroller

so that the firmware is not complicated by fulfilling roles that the

host could do equally well or better?  It seems to me that industry

has not produced such a quality WiFi firmware, and the odds are against

one appearing.
I believe the inherent flexibility of a microcontroller-based design,

as compared with an ASIC or microcode, coupled with the peculiarly low

quality and unnecessary complexity of WiFi firmwares, adds up to a worse

threat than that posed by, say, ASIC bugs.
Dave
--

David Young             OJC Technologies

dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24

David,
You're aware that many of the "microcoded" devices we support are actually

instances of full general-purpose CPU architectures, and that their vendors

call their software load "microcode" simply as a matter of convention?
This has been the case for many, many years (look at "isp" as an example,

or "ti" or "bge" -- noting that the only real difference with bge is

that it loads a *default* software image at power-up, but the driver knows

how to load a new image).
Even the special-purpose CPUs like 53c8xx or the Adaptec SCSI "sequencers"

are certainly as flexible as many simple microcontrollers -- and we provide

toolchains for many of these in our own tree!
I do not believe that it is reasonable to draw a distinction between

programmable, DMA-capable devices as you are doing.
Thor

Yes, I am.  I have and will consistently call that firmware.
Dave
--

David Young             OJC Technologies

dyoung@ojctech.com      Urbana, IL * (217) 278-3933 ext 24

That difference makes a difference to me.  I would perhaps have

explained further, to someone who'd been a bit more polite.
/~\ The ASCII				der Mouse

\ / Ribbon Campaign

 X  Against HTML	       mouse@rodents.montreal.qc.ca

/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

I have noticed that after posting and already deleted original post. Sorry.
--

View this message in context: http://www.nabble.com/Re%3A-wpi0%3A-could-not-read-firmware-file-tf45624...

Sent from the tech-kern mailing list archive at Nabble.com.