free firmware mistakenly removed by LinuxLibre

[Felipe Sanches]

And indeed I was right!

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
linux kernel mailing list. Based on information provided by my
investigation, he patched the firmware file and then it worked perfectly
with the actual device, confirming my theory that there was a bug in that
byte :-)

happy hacking
Felipe "Juca" Sanches

On Tue, Jan 4, 2011 at 12:34 AM, Felipe Sanches <juca at members.fsf.org>wrote:

> On Mon, Jan 3, 2011 at 9:37 PM, Alexandre Oliva <lxoliva at fsfla.org> wrote:
> > On Jan  3, 2011, Felipe Sanches <juca at members.fsf.org> wrote:
> >
> >> What I meant is that the kernel source shouldnt ship binaries.
> >
> > Why not?  It doesn't harm any freedom to ship them along with the
> > sources, and it makes perfect sense IMHO to not require people who build
> > their own kernel binaries to have to have assemblers and compilers and
> > FPGA tools etc for tons of different targets.
>
> My personal opinion is that there should be a clear separation of
> source code repositories and packages of pre-built binaries. I agree
> that there is no freedom harm in shipping binaries even if you have
> the source code to build too. But not building something from source
> may lead to a situation where the source code may get neglected and
> people may eventually update the binaries without updating the source
> and it would not be trivial to keep track of it. You have asked me
> whether the shipped binary for dabusb 8051 fimrware is equivalent to
> the firmware source code. That is not an easy question to answer. The
> safest way to be sure that the shipped binary is equivalent to the
> free code is by making sure it is always the result of a firmware
> build directly from source code.
>
> People would have to install the development tools for the selected
> targets they have setup in their kernel configuration.  For instance,
> it is acceptable that for a certain application, people have to
> install libwhatever package if they want to build a certain feature
> that uses such lib, but they dont have to install other libraries that
> are only required for other non-selected features. Let me stretch it a
> bit just for fun: people have to install gcc if they whant to build
> their C code :-D
>
> People who are concerned about the possible hassle of having to
> install fpga development tools and assemblers for several different
> targets (for example people in charge of preparing kernel packages for
> distros) can make use of a separate package of pre-built images (that
> somebody else could be held responsible for mantaining, perhaps), but
> the kernel source code should stick to source code only, while the
> proper place for pre-built binaries is in pre-built kernel
> images/packages. And yes, perhaps pcmcia .ct files should also be
> always translated into CIS files at build time too for the same
> reason.
>
> Here is a more pragmatic argument, though:
>
> In the firmware/keyspan_pda/ directory there is both source code:
> keyspan_pda.S and xircom_pgs.S
> and pre-built firmware:
> keyspan_pda.HEX and xircom_pgs.HEX
>
> These files are in Linux since 2002 at least. So the question "did
> firmware images and firmware source 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.
> The resulting HEX file is not identical to the pre-built one, but the
> files are equivalent. Mind the first few lines of the original and
> rebuilt hex files:
>
> xircom_pgs.HEX
> :03000000020200F9
> :0400230002055F0073
> :0400430002010000B6
> :050030000000000000CB
> :10010000020296000200000002000000020000004F
> :1001100002000000020000000200000002000000D7
> :1001200002000000020000000204610002048900D5
>
> xircom_pgs_rebuilt.HEX
> :03000000020200F9
> :0400230002059B0037
> :0400430002010000B6
> :050030000000000000CB
> :0D0100000202BA000200000002000000022E
> :0E010D000000000200000002000000020000DE
> :0E011B000002000000020000000200000002CE
> :070129000485000204B90087
>
> HEX format is:
> :<8bit counter><16bit address><0x00><"counter" bytes of data><checksum
> byte>
>
> 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 firmware images byte-by-byte.
>
> 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 source have 0x53. This address corresponds to the following
> line in the source code:
>
>         ;; setup the serial port. 9600 8N1.
>         mov a,#0b01010011               ; mode 1, enable rx, clear int
>         mov SCON, a
>
> 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 source code above) in this register.
>
>  Bits 7 (SM0) and 6 (SM1) let us set the serial mode to a value
> between 0 and 3, inclusive.
> SM = 01 in the source code meaning mode 1: 8 bit UART (just like it
> states in the comments) and SM=00 in the prebuilt firmware, which
> would mean Mode 0: 8bit shift register...
>
> As the main function of this device is to behave as a USB-Serial
> interface, I conclude that the prebuilt firmware is probably
> completely broken because of this single byte. Does anybody actually
> have one of these keyspan_pda devices to check ?
>
> That's the kind of failure I know we'll potentially face again if we
> continue blindly trusting pre-built firmware.
>
> I may also assume that this is not a popular device, since the
> firmware bug would be simple to detect if people were actually using
> it: the device would simply not work (I guess).
>
> Now here is something really weird:
> http://www.mail-archive.com/linux-serial@vger.rutgers.edu/msg00473.html
> The initial patch that added support for keyspan_pda in Linux 2.2.50
> back in march 2000 already have the 0x00 byte at addrees 0x266 :-P I
> dont know how to explain that!
>
> Felipe Sanches
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20130122/6eedd3b1/attachment.html>