PATCH: fix multiple eMagic 6|2m regressions introduced in 2.6.27

[Monty Montgomery-2]

Hello folks,

The eMagic driver code cleanup from 2.6.26->2.6.27 introduces three
new bugs that prevent the emi62 usb audio device from working.  2.6.31
continues to be identically broken. Note that this is the 6|2, not the
2|6; the 2|6 works properly. The 6|2 does not function at all and will
oops the kernel when plugged in.

Bug 1: a mirror of the loop termination bug that was fixed in the 2|6
driver last January, causing a similar oops as the 2|6 did in 2.6.27.

Bug 2: the firmware load loop that is supposed to load the firmware
section that sits in the device's RAM mistakenly uses
ANCHOR_LOAD_EXTERNAL instead of ANCHOR_LOAD_INTERNAL, a bug from
copy/pasting out of the preceeding loop.  This is clearly a regression
from the 2.6.26 source which uses the proper target.

Bug 3: Fixing the first two problems prevents the oops and allows the
USB stack to successfully allocate an endpoint without crashing the
eMagic.  However, the eMagic crashes and lights its red INTERNAL ERROR
led later as it tries to start up.  This problem can be traced to the
linux/firmware/emi62/bistream.HEX file, which is loading different
FPGA firmware as compared to the driver pre-2.6.27.  In fact, it is
loading an exact copy of the bistream firmware file that belongs to
the emi26 driver rather than the firmware that previously belonged to
the emi62. A new firmware/emi62/bitstream.HEX file generated from the
old driver's header corrects the problem and the 6|2 works as it did
before.

Note that the current firmware/emi62/bitstream.HEX mistakenly
identifies itself as:

// VERSION= 1.0.0.191
// DATE= 2002oct28

...this is incorrect and apparently cut out of the old emi62 driver's
firmware header and pasted onto the other firmware file.

Due to the size of the patch (the replacement firmware file is 250kB),
I've not attached it but rather stashed it at:

http://web.mit.edu/xiphmont/Public/emi/emi62.patch

Though it was generated against 2.6.29.4, I've tested it with 2.6.31.6.

(not currently subbed to the kernel list, please make sure I'm CCed on
replies.  Thanks!)

Monty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Monty Montgomery-2]

I should mention that when I first started strated working on this
problem tonight, I saw Clemens Ladisch's patch from a few days ago.
His reported bug and patch is identical to my 'bug 1' and the first
change in my patch.  Unfortunately, this fix only prevented the oops,
it was not enough to make the eMagic actually function.  The other two
bugfixes were absolutely necessary as well.

I included the fix in my patch as well as I was uncertain if it had
yet been applied to the kernel tree, and it is important not to miss
it.

Monty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Clemens Ladisch]

Monty Montgomery wrote:
> The eMagic driver code cleanup from 2.6.26->2.6.27 introduces three
> new bugs that prevent the emi62 usb audio device from working.  2.6.31
> continues to be identically broken. Note that this is the 6|2, not the
> 2|6; the 2|6 works properly. The 6|2 does not function at all and will
> oops the kernel when plugged in.

This has been discussed in this thread:
http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064931.html

> Bug 1: a mirror of the loop termination bug that was fixed in the 2|6
> driver last January, causing a similar oops as the 2|6 did in 2.6.27.

My patch for this has already been picked up by akpm.

> Bug 2: the firmware load loop that is supposed to load the firmware
> section that sits in the device's RAM mistakenly uses
> ANCHOR_LOAD_EXTERNAL instead of ANCHOR_LOAD_INTERNAL, a bug from
> copy/pasting out of the preceeding loop.  This is clearly a regression
> from the 2.6.26 source which uses the proper target.
>
> Bug 3: Fixing the first two problems prevents the oops and allows the
> USB stack to successfully allocate an endpoint without crashing the
> eMagic.  However, the eMagic crashes and lights its red INTERNAL ERROR
> led later as it tries to start up.  This problem can be traced to the
> linux/firmware/emi62/bistream.HEX file, which is loading different
> FPGA firmware as compared to the driver pre-2.6.27.
> [...]
> Due to the size of the patch (the replacement firmware file is 250kB),
> I've not attached it but rather stashed it at:
>
> http://web.mit.edu/xiphmont/Public/emi/emi62.patch

I don't have much time; David, please handle this.


Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Monty Montgomery-2]

> This has been discussed in this thread:
> http://lists.linuxaudio.org/pipermail/linux-audio-user/2009-November/064931.html

Ah, you got 80% of the way to where I did :-)

My 'bug 2' is the EXTERNAL->INTERNAL change that fixes the error -110
and allows the firmware to load.  However, as you've noticed, although
you get an endpoint the device then crashes because although it
succeeded in loading the firmware--- it was loading the  wrong
firmware.

The new bitstream.HEX file fixes that last problem.  It is merely a
reversion to the same firmware used in 2.6.26.  I assume that
overwriting the emi62s firmware with the firmware from the emi26 was a
mistake on someone's part.

As you've already got the loop fix and the EXTERNAL->INTERNAL fix, all
you need is the replacement bitstream.HEX:

http://web.mit.edu/xiphmont/Public/emi/bitstream.HEX

Monty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[David Woodhouse-7]

On Tue, 2009-11-24 at 10:27 +0100, Clemens Ladisch wrote:

>
> > Bug 3: Fixing the first two problems prevents the oops and allows
> the
> > USB stack to successfully allocate an endpoint without crashing the
> > eMagic.  However, the eMagic crashes and lights its red INTERNAL
> ERROR
> > led later as it tries to start up.  This problem can be traced to
> the
> > linux/firmware/emi62/bistream.HEX file, which is loading different
> > FPGA firmware as compared to the driver pre-2.6.27.
> > [...]
> > Due to the size of the patch (the replacement firmware file is
> 250kB),
> > I've not attached it but rather stashed it at:
> >
> > http://web.mit.edu/xiphmont/Public/emi/emi62.patch
>
> I don't have much time; David, please handle this.

Where did the new firmware come from?

I think the best option at this point is to remove it from the firmware/
directory and add the new one to the linux-firmware.git repository.

--
dwmw2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Clemens Ladisch]

David Woodhouse wrote:
> Where did the new firmware come from?

Sorry, I snipped that part of Monty's mail:

> > This problem can be traced to the
> > linux/firmware/emi62/bistream.HEX file, which is loading different
> > FPGA firmware as compared to the driver pre-2.6.27.  In fact, it is
> > loading an exact copy of the bistream firmware file that belongs to
> > the emi26 driver rather than the firmware that previously belonged to
> > the emi62. A new firmware/emi62/bitstream.HEX file generated from the
> > old driver's header corrects the problem and the 6|2 works as it did
> > before.
> >
> > Note that the current firmware/emi62/bitstream.HEX mistakenly
> > identifies itself as:
> >
> > // VERSION= 1.0.0.191
> > // DATE= 2002oct28
> >
> > ...this is incorrect and apparently cut out of the old emi62 driver's
> > firmware header and pasted onto the other firmware file.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Monty Montgomery-2]

> Where did the new firmware come from?

It is the firmware as originally appeared in in Tapio's original out
of tree driver in 2002-ish, was committed to the tree in 2.6.12, and
remained unchanged until it was removed in the firmware cleanup in
2.6.27.  The firmware header at that time held the bitstream, loader
and SPIDF/MIDI firmware images all in one header file.  In 2.6.27,
they were all split back out into their original ihex sources but this
operation seems to have been botched.  I wrote a quick script to
redump the data from the original header back into ihex format as I
couldn't locate the original ihex files Tapio apparently originally
worked from (the comments and partial original ihex inclusion in
Tapio's header are admittedly confusing and apparently led the
cleaner-upper astray).

Monty
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[alfie carroll]

Hi monty
excuse my ignorance but how can i actually download the bitstream.HEX file? there seems to be no actual option to download it.