Created attachment 579720 [details]
correct emi26/bitstream.fw file
Description of problem:
The firmware files shipping for the emi62 are nonfunctional; they result in a locked-up device with the internal error light on.
The firmware files being shipped for the emi26 are out of date; they're a prerelease version.
Note that the firmware files being shipped in the stock kernel are also broken; it appears the problem happened during a 'cleanup' just before 2.6.27 when the original files that were shipped with the kernel were replaced with the ones there now.
Version-Release number of selected component (if applicable):
All versions to date
Steps to Reproduce:
1. Plug in emi62m or emi26
Emi6|2 lights internal not ready/error red LED; light remains lit with device locked up.
Emi2|6 functions, but missing several capabilities of the hardware (such as 96kHz sampling).
Emi6|2m lights red light for approximately a second, followed by its startup sequence of several green light patterns. Device at that point is ready to operate.
Emi2|6 starts up normally with green light pattern; 96kHz sampling is listed in endpoint capabilities. The newer firmware contains several other bugfixes as well.
Will be adding seven attachments for correct firmware files
Created attachment 579721 [details]
correct emi26/firmware.fw file
Created attachment 579722 [details]
correct emi26/loader.fw file
Created attachment 579723 [details]
correct emi62/bitstream.fw file
Created attachment 579724 [details]
correct emi62/loader.fw file
Created attachment 579725 [details]
correct emi62/midi.fw file
Created attachment 579726 [details]
correct emi62/spdif.fw file
Where did you get these files from? Also, is there a reason they haven't been sent to the upstream linux-firmware project?
We essentially package what is in there, so if the files are stale they're stale for everyone using that. It's probably better to send them to the linux-firmware maintainers upstream, with the proper information on where they came from.
> Where did you get these files from?
They were extracted (by me) from the last driver update Apple offered for download for the device in ~2004 for Mac OS X 10.4.
> Also, is there a reason they haven't been
> sent to the upstream linux-firmware project?
I offered them to upstream, who was leery that the update from Apple contained no license information (at least, none I can find. I have grepped the entire contents of the .dmg, including the binaries. Apple bought eMagic in 2002 shortly after Tapio finished his original driver).
The discussion then got bogged down into whether or not Tapio had ever had explicit permission to distribute the firmware that was put in the kernel in 2002. No one succeeded in contacting him.
In the end they did nothing; they did not restore the old firmware that worked but was buggy, update to the new firmware with no explicit license, or remove the driver that's been nonfunctional for nearly five years.
I'll also point out the clobber that accidentally replaced the working firmware from 2.6.26 with the broken files in 2.6.27 (I think I have those version right) also stripped out the original license text.
> We essentially package what is in there, so if the files are stale they're
> stale for everyone using that. It's probably better to send them to the
> linux-firmware maintainers upstream, with the proper information on where they
> came from.
That would be nice :-) OK, I'll try again, especially as the firmware loader in the kernel is itself broken now and in need of patching.
Aplogies-- what is the correct mailing list to contact linux-firmware these days? I think perhaps my problem in the past was going through the ALSA maintainers.
(In reply to comment #9)
> Aplogies-- what is the correct mailing list to contact linux-firmware these
> days? I think perhaps my problem in the past was going through the ALSA
Send them to David Woodhouse <firstname.lastname@example.org> and Ben Hutchings <email@example.com>, probably with firstname.lastname@example.org CC'd, and maybe the ALSA list as well.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
I've updated the firmware in Fedora git this morning. An update will roll out to the releases shortly.
linux-firmware-20140131-34.gitd7f8a7c8.fc19 has been submitted as an update for Fedora 19.
linux-firmware-20140131-35.gitd7f8a7c8.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing linux-firmware-20140131-34.gitd7f8a7c8.fc19'
as soon as you are able to, then reboot.
Please go to the following url:
then log in and leave karma (feedback).
linux-firmware-20140131-35.gitd7f8a7c8.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
linux-firmware-20140131-34.gitd7f8a7c8.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.