<div dir="ltr">Here's a bit more detail on the firmware story I mentioned in my previous message. The following description is an email I sent the kernel mailing-list in January 2011:<br><br>=======================<br><br>In the <span class="il">firmware</span>/keyspan_pda/ directory there is both <span class="il">source</span> code:<br>
keyspan_pda.S and xircom_pgs.S<br>
and pre-built <span class="il">firmware</span>:<br>
keyspan_pda.HEX and xircom_pgs.HEX<br>
<br>
These files are in <span class="il">Linux</span> since 2002 at least. So the question "did<span class="il"> firmware</span> images and <span class="il">firmware</span> <span class="il">source</span> code diverge along these past 8 or
9 years?" can only be answered by building the code and comparing the results byte-by-byte. I did it and got a positive result for xircom.<br><br>
The resulting HEX file is not identical to the pre-built one, but the binary files are equivalent. Mind the first few lines of the original and rebuilt hex files:<br>
<br>
xircom_pgs.HEX<br>
:03000000020200F9<br>
:0400230002055F0073<br>
:0400430002010000B6<br>
:050030000000000000CB<br>
:<div id=":e1m" class="a3s">10010000020296000200000002000000020000004F<br>
:1001100002000000020000000200000002000000D7<br>
:1001200002000000020000000204610002048900D5<br>
<br>
xircom_pgs_rebuilt.HEX<br>
:03000000020200F9<br>
:0400230002059B0037<br>
:0400430002010000B6<br>
:050030000000000000CB<br>
:0D0100000202BA000200000002000000022E<br>
:0E010D000000000200000002000000020000DE<br>
:0E011B000002000000020000000200000002CE<br>
:070129000485000204B90087<br>
<br>
HEX format is:<br>
:<8bit counter><16bit address><0x00><"counter" bytes of data><checksum byte><br>
<br>
If you compare these two files you can see they are 2 alternative representation of the same memory block. It is not trivial to check. I had to write a python script to parse IntelHex and generate a memory image dump (with zeroes in the addresses not referenced by the HEX data and then compare the resulting <span class="il">firmware</span> images byte-by-byte.<br>
<br>
By doing that I got positive result indicating that xircom_pgs.S and xircom_pgs.HEX match perfectly indeed. But I got a one-byte diference between the original image of keyspan_pda.HEX and the result of building keyspan_pda.S The byte value divergence is at memory address 0x0266. The prebuilt image has 0x00 at this address, while the image built from <span class="il">source</span> have 0x53. This address corresponds to the following line in the <span class="il">source</span> code:<br>
<br>
;; setup the serial port. 9600 8N1.<br>
mov a,#0b01010011 ; mode 1, enable rx, clear int<br>
mov SCON, a<br>
<br>
It is configuring the serial port by writting configuration bits to the 8051 SCONS Special Function Register. So let's check the 8051 documentation to see what is the result of storing zero instead of 0x53 (the 0b01010011 in the <span class="il">source</span> code above) in this register.<br>
<br>
Bits 7 (SM0) and 6 (SM1) let us set the serial mode to a value between 0 and 3, inclusive.<br>
SM = 01 in the <span class="il">source</span> code meaning mode 1: 8 bit UART (just like it states in the comments) and SM=00 in the prebuilt <span class="il">firmware</span>, which would mean Mode 0: 8bit shift register...<br>
<br>
As the main function of this device is to behave as a USB-Serial interface, I conclude that the prebuilt <span class="il">firmware</span> is probably completely broken because of this single byte. Does anybody actually have one of these keyspan_pda devices to check ?<br>
<br>
That's the kind of failure I know we'll potentially face again if we continue blindly trusting pre-built <span class="il">firmware</span>.<br>
<br>
I may also assume that this is not a popular device, since the<span class="il"> firmware</span> bug would be simple to detect if people were actually using it: the device would simply not work (I guess).<br>
<br>
Now here is something really weird:<br>
<a href="http://www.mail-archive.com/linux-serial@vger.rutgers.edu/msg00473.html" target="_blank">http://www.mail-archive.com/<span class="il">linux</span>-serial@vger.rutgers.edu/msg00473.html</a><br>
The initial patch that added support for keyspan_pda in <span class="il">Linux</span> 2.2.50 back in march 2000 already have the 0x00 byte at addrees 0x266 :-P So even the person who contributed the initial support did'nt test it in the real device to see it was broken? I dont know how to explain that!<br><br><br>=========================================<br></div><div id=":e1m" class="a3s">Two years after making these initial researching, I got the definitive answer coming from a user of this device. The following is a message I sent to the <a href="mailto:linux-libre@fsfla.org">linux-libre@fsfla.org</a> mailing list in January 2013:<br>=========================================<br><br>And indeed I was right!<br><br>This week I received an email from a user
who had trouble making his xircom device work. Then he googled it and
discovered a message I sent to the <span class="il">linux</span> <span class="il">kernel</span> mailing list. Based on information provided by my investigation, he patched the <span class="il">firmware</span> file and then it worked perfectly with the actual device, confirming my theory that there was a bug in that byte :-)<br>
<br>happy hacking<br>Felipe "Juca" Sanches<br><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 9, 2014 at 4:36 PM, Paul Wise <span dir="ltr"><<a href="mailto:pabs@debian.org" target="_blank">pabs@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 10, 2014 at 2:55 AM, Steven Chamberlain wrote:<br>
<br>
> Really? Do any packages in main ship binary firmware like that? That<br>
> violates the DFSG surely?<br>
<br>
</span>Debian doesn't require things are actually built from source, just<br>
that they can be. For examples look at the firmware-free source<br>
package (or any package that uses autoconf but doesn't build-dep on<br>
dh-autoreconf).<br>
<br>
<a href="http://sources.debian.net/src/firmware-free/latest/" target="_blank">http://sources.debian.net/src/firmware-free/latest/</a><br>
<span class=""><br>
> Either way I think, in order to have free firmware, the free-libre<br>
> distributions need to provide a good toolchain and environment for<br>
> firmware development. Distributing open-source firmware to be built<br>
> from source, would then be a more natural thing to do. (vs. firmware<br>
> that was developed in proprietary software - which even if it were<br>
> open-sourced, we may be unable to build anyway)<br>
<br>
</span>Agreed, however the problem with that is they often use custom chips<br>
so we might end up with one toolchain per supported device.<br>
<span class="im HOEnZb"><br>
--<br>
bye,<br>
pabs<br>
<br>
<a href="https://wiki.debian.org/PaulWise" target="_blank">https://wiki.debian.org/PaulWise</a><br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Fsf-collab-discuss mailing list<br>
<a href="mailto:Fsf-collab-discuss@lists.alioth.debian.org">Fsf-collab-discuss@lists.alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fsf-collab-discuss" target="_blank">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fsf-collab-discuss</a><br>
</div></div></blockquote></div><br></div>