Missing firmware iwlwifi-2030-5.ucode

Missing firmware iwlwifi-2030-5.ucode

[Larry Finger]

Hi,

I am trying to help an openSUSE 12.1 user who is running kernel 3.1.9, who has 
an Intel 802.11 b/g/n card with Bluetooth mounted in an HP dvdt-7000 Quad 
Edition Series computer.

The driver is asking for firmware named "iwlwifi-2030-5.ucode"; however, that 
particular file does not exist in /lib/firmware, nor is in the linux-firmware 
git repo where only the version 6 firmware exists.

I could find no record of the firmware ever being in the git repo, nor could I 
find it using a Google search. For users of kernel 3.1, I request that this 
firmware file be submitted to linux-firmware. In addition, if you send me a copy 
of the file, I will see that the OP on the openSUSE Forum gets a copy.

Thanks,

Larry

Re: Missing firmware iwlwifi-2030-5.ucode

[Thomas Backlund]

16.08.2012 18:06, Larry Finger skrev:
> Hi,
>
> I am trying to help an openSUSE 12.1 user who is running kernel 3.1.9,
> who has an Intel 802.11 b/g/n card with Bluetooth mounted in an HP
> dvdt-7000 Quad Edition Series computer.
>
> The driver is asking for firmware named "iwlwifi-2030-5.ucode"; however,
> that particular file does not exist in /lib/firmware, nor is in the
> linux-firmware git repo where only the version 6 firmware exists.
>
> I could find no record of the firmware ever being in the git repo, nor
> could I find it using a Google search. For users of kernel 3.1, I
> request that this firmware file be submitted to linux-firmware. In
> addition, if you send me a copy of the file, I will see that the OP on
> the openSUSE Forum gets a copy.
>

You need atleast:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=37273f55830f0919d543250d191e1633ff53841c


If this is a distro kernel, you probably need theese too:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=13cb8e3a067538c5aacc846a032985d2b608bccd
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=20d6f19dca576a671ab61403c366c7154f802b36
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=9e8ed57850a9d5157430fb09161a2456171d8684

--
Thomas

Re: Missing firmware iwlwifi-2030-5.ucode

[Johannes Berg]

Hi Larry,

> I am trying to help an openSUSE 12.1 user who is running kernel 3.1.9, who has 
> an Intel 802.11 b/g/n card with Bluetooth mounted in an HP dvdt-7000 Quad 
> Edition Series computer.
> 
> The driver is asking for firmware named "iwlwifi-2030-5.ucode"; however, that 
> particular file does not exist in /lib/firmware, nor is in the linux-firmware 
> git repo where only the version 6 firmware exists.
> 
> I could find no record of the firmware ever being in the git repo, nor could I 
> find it using a Google search. For users of kernel 3.1, I request that this 
> firmware file be submitted to linux-firmware. In addition, if you send me a copy 
> of the file, I will see that the OP on the openSUSE Forum gets a copy.

Unfortunately, I can't just release this firmware, it was mostly
internal experimental builds, we released the -6 version later. However,
as Thomas pointed out, it should be possible to backport some patches to
make the driver in 3.1.9 work with the device, that simply wasn't a
concern for us and it's not entirely clear to me that such patches are
candidates for stable.

johannes

Re: Missing firmware iwlwifi-2030-5.ucode

[Larry Finger]

On 08/20/2012 05:45 AM, Johannes Berg wrote:

Johannes,

> Unfortunately, I can't just release this firmware, it was mostly
> internal experimental builds, we released the -6 version later. However,
> as Thomas pointed out, it should be possible to backport some patches to
> make the driver in 3.1.9 work with the device, that simply wasn't a
> concern for us and it's not entirely clear to me that such patches are
> candidates for stable.

The openSUSE user has gotten his system working by installing the 
compat-wireless package. I do not know if he could patch and compile his own 
kernel, and I don't have that device in my collection, thus I would be unable to 
test any such changes.

I'm still concerned about the bigger picture. I can understand that the -5 
version was experimental, but why was a driver released that needed a firmware 
version that could never be obtained? If any driver version needs a particular 
firmware, the fw must be available as long as anyone might be using that driver. 
To me, that means forever.

Larry

Re: Missing firmware iwlwifi-2030-5.ucode

[Johannes Berg]

On Mon, 2012-08-20 at 10:53 -0500, Larry Finger wrote:

> I'm still concerned about the bigger picture. I can understand that the -5 
> version was experimental, but why was a driver released that needed a firmware 
> version that could never be obtained? If any driver version needs a particular 
> firmware, the fw must be available as long as anyone might be using that driver. 
> To me, that means forever.

Well, yes. That firmware, however, never was never available publicly.
The fact that the driver was released anyway is due to us working on the
driver upstream while working with the experimental internal firmware.

johannes

Re: Missing firmware iwlwifi-2030-5.ucode

[Gábor Stefanik]

On Mon, Aug 20, 2012 at 6:01 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2012-08-20 at 10:53 -0500, Larry Finger wrote:
>
>> I'm still concerned about the bigger picture. I can understand that the -5
>> version was experimental, but why was a driver released that needed a firmware
>> version that could never be obtained? If any driver version needs a particular
>> firmware, the fw must be available as long as anyone might be using that driver.
>> To me, that means forever.
>
> Well, yes. That firmware, however, never was never available publicly.
> The fact that the driver was released anyway is due to us working on the
> driver upstream while working with the experimental internal firmware.
>
> johannes

Perhaps we should add a Kconfig option to disable internal development
hardware - with that option unchecked, support for hardware that is
not on the market is disabled, with a printk warning to upgrade the
driver in case a user tries to use a driver with a card that it thinks
is internal-only. This way, users will get a meaningful error message,
rather than a misleading "missing firmware" one.
The Kconfig option should also come with a big warning of "Say N
unless you are an Intel employee". Maybe it should even be marked
BROKEN, like N-PHY was in b43 before it became usable.

Re: Missing firmware iwlwifi-2030-5.ucode

[Larry Finger]

On 08/20/2012 11:55 PM, Gábor Stefanik wrote:
> On Mon, Aug 20, 2012 at 6:01 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Mon, 2012-08-20 at 10:53 -0500, Larry Finger wrote:
>>
>>> I'm still concerned about the bigger picture. I can understand that the -5
>>> version was experimental, but why was a driver released that needed a firmware
>>> version that could never be obtained? If any driver version needs a particular
>>> firmware, the fw must be available as long as anyone might be using that driver.
>>> To me, that means forever.
>>
>> Well, yes. That firmware, however, never was never available publicly.
>> The fact that the driver was released anyway is due to us working on the
>> driver upstream while working with the experimental internal firmware.
>>
>> johannes
>
> Perhaps we should add a Kconfig option to disable internal development
> hardware - with that option unchecked, support for hardware that is
> not on the market is disabled, with a printk warning to upgrade the
> driver in case a user tries to use a driver with a card that it thinks
> is internal-only. This way, users will get a meaningful error message,
> rather than a misleading "missing firmware" one.
> The Kconfig option should also come with a big warning of "Say N
> unless you are an Intel employee". Maybe it should even be marked
> BROKEN, like N-PHY was in b43 before it became usable.

Your suggestion would handle the case where hardware that is only supposed to be 
available internally has somehow been leaked to the public. In the case of the 
2030, it is a device that was intended to be available to the public, and I 
suspect that Windows and OS X drivers were available with built-in firmware.

My feeling is that the reviewers will need to watch the situation. I certainly 
plan to monitor every Intel patch for a firmware change, and I will NACK every 
instance for which that firmware file is not already in linux-firmware. John 
might not honor my NACK; however, I will be on record. At least Ben Hutchings 
caught the attempt to delete the older version of the firmware for the 6205. His 
diligence saved some users of older kernels from having to scramble to find 
firmware not in the firmware repo.

Larry

Re: Missing firmware iwlwifi-2030-5.ucode

[Johannes Berg]

On Tue, 2012-08-21 at 00:14 -0500, Larry Finger wrote:

> >> Well, yes. That firmware, however, never was never available publicly.
> >> The fact that the driver was released anyway is due to us working on the
> >> driver upstream while working with the experimental internal firmware.

> > Perhaps we should add a Kconfig option to disable internal development
> > hardware - with that option unchecked, support for hardware that is
> > not on the market is disabled, with a printk warning to upgrade the
> > driver in case a user tries to use a driver with a card that it thinks
> > is internal-only. This way, users will get a meaningful error message,
> > rather than a misleading "missing firmware" one.
> > The Kconfig option should also come with a big warning of "Say N
> > unless you are an Intel employee". Maybe it should even be marked
> > BROKEN, like N-PHY was in b43 before it became usable.
> 
> Your suggestion would handle the case where hardware that is only supposed to be 
> available internally has somehow been leaked to the public. In the case of the 
> 2030, it is a device that was intended to be available to the public, and I 
> suspect that Windows and OS X drivers were available with built-in firmware.

Yes, that was likely the case. Except there are no OS X drivers at
all :-)

> My feeling is that the reviewers will need to watch the situation. I certainly 
> plan to monitor every Intel patch for a firmware change, and I will NACK every 
> instance for which that firmware file is not already in linux-firmware. John 
> might not honor my NACK; however, I will be on record.

You're free to, of course, but I don't think we've ever (intentionally)
changed the driver from working with a released firmware image to
working only with unreleased firmware images. In fact, this is the
reason we have firmware versions and try to load multiple versions, so
we can begin working on a newer version internally while the driver
continues to work with older, released versions.

The situation with 2030 devices was different: we worked on a driver and
submitted code into the kernel that given the right firmware could work
with the device. I don't remember, but we may even have thought at the
time that we'd release the -5 firmware version, but then had to use -6.
There was definitely a chance that we could release the right firmware
version and thereby make the previously submitted code work. As it turns
out, we couldn't or didn't (and that we've released a -6 one I can't
just release another one), but that wasn't necessarily something anyone
would have known at the time we submitted the code.

So I guess we could simply not submit the code before the firmware was
released, but it would really just have the same effect on users that
the released code has now -- their old kernel doesn't work with the
device. Today, it's because we ended up releasing the wrong firmware, if
we didn't release the code before the firmware it would be because they
didn't have any driver code at all. I don't see how that would help.


> At least Ben Hutchings 
> caught the attempt to delete the older version of the firmware for the 6205. His 
> diligence saved some users of older kernels from having to scramble to find 
> firmware not in the firmware repo.

Yes, that was indeed a mistake. I guess I got over-excited with the new
firmware being available :-) Different situation though.

johannes

Re: Missing firmware iwlwifi-2030-5.ucode

[antonio]

> > Your suggestion would handle the case where hardware that is only 
supposed to be 
> > available internally has somehow been leaked to the public. In the case 
of the 
> > 2030, it is a device that was intended to be available to the public, 
and I 
> > suspect that Windows and OS X drivers were available with built-in 
firmware.
> 
> Yes, that was likely the case. Except there are no OS X drivers at
> all 
> 
> > My feeling is that the reviewers will need to watch the situation. I 
certainly 
> > plan to monitor every Intel patch for a firmware change, and I will NACK 
every 
> > instance for which that firmware file is not already in linux-firmware. 
John 
> > might not honor my NACK; however, I will be on record.
> 
> You're free to, of course, but I don't think we've ever (intentionally)
> changed the driver from working with a released firmware image to
> working only with unreleased firmware images. In fact, this is the
> reason we have firmware versions and try to load multiple versions, so
> we can begin working on a newer version internally while the driver
> continues to work with older, released versions.
> 
> The situation with 2030 devices was different: we worked on a driver and
> submitted code into the kernel that given the right firmware could work
> with the device. I don't remember, but we may even have thought at the
> time that we'd release the -5 firmware version, but then had to use -6.
> There was definitely a chance that we could release the right firmware
> version and thereby make the previously submitted code work. As it turns
> out, we couldn't or didn't (and that we've released a -6 one I can't
> just release another one), but that wasn't necessarily something anyone
> would have known at the time we submitted the code.
> 
> So I guess we could simply not submit the code before the firmware was
> released, but it would really just have the same effect on users that
> the released code has now -- their old kernel doesn't work with the
> device. Today, it's because we ended up releasing the wrong firmware, if
> we didn't release the code before the firmware it would be because they
> didn't have any driver code at all. I don't see how that would help.
> 
> > At least Ben Hutchings 
> > caught the attempt to delete the older version of the firmware for the 
6205. His 
> > diligence saved some users of older kernels from having to scramble to 
find 
> > firmware not in the firmware repo.
> 
> Yes, that was indeed a mistake. I guess I got over-excited with the new
> firmware being available  Different situation though.
> 
> johannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 
in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

HI,

I am sorry, I cannot really understand why the iwlwifi -2030-5.ucode 
firmware has been removed, just leave it there along with the -6 version for 
people that might need it ! I respect your work, but I am loosing my mental 
health in order to find it and I really need it, I must use MeeGo, a system 
that I am not familiar with. The driver is asking *strictly* for -5 version 
and I don't want to fiddle about kernel compilation every damn time for tiny 
bits of proprietary code, I just want to use as it is (I don't even know if 
there is a possibility to recompile the kernel in MeeGo, and I am not a 
developer)
It should have been in the topic of the post really a link to the -5 version 
if you are the mantainers.
Regards.
Antonio

Re: Missing firmware iwlwifi-2030-5.ucode

[Robbi Nespu]

You are right Antonio, saw your 2013 email[1] which is the same 
frustration happen to me (in year 2021) to hunt firmware not in the 
firmware repository.. Ugh why some released driver needed a firmware 
version that could never be obtained anywhere...

[1] 
https://lore.kernel.org/linux-wireless/loom.20130617T165559-455@post.gmane.org/
-- 
Email : Robbi Nespu <robbinespu AT SPAMFREE gmail DOT com>
PGP fingerprint : D311 B5FF EEE6 0BE8 9C91 FA9E 0C81 FA30 3B3A 80BA
PGP key : https://keybase.io/robbinespu/pgp_keys.asc