[Fsf-Debian] A small thought on how Debian might be able to help.

Tue Sep 9 20:27:22 UTC 2014

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:

=======================

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
binary 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 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!

=========================================
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 linux-libre at fsfla.org mailing list in January 2013:
=========================================

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, Sep 9, 2014 at 4:36 PM, Paul Wise <pabs at debian.org> wrote:

> On Wed, Sep 10, 2014 at 2:55 AM, Steven Chamberlain wrote:
>
> > Really?  Do any packages in main ship binary firmware like that?  That
> > violates the DFSG surely?
>
> Debian doesn't require things are actually built from source, just
> that they can be. For examples look at the firmware-free source
> package (or any package that uses autoconf but doesn't build-dep on
> dh-autoreconf).
>
> http://sources.debian.net/src/firmware-free/latest/
>
> > Either way I think, in order to have free firmware, the free-libre
> > distributions need to provide a good toolchain and environment for
> > firmware development.  Distributing open-source firmware to be built
> > from source, would then be a more natural thing to do. (vs. firmware
> > that was developed in proprietary software - which even if it were
> > open-sourced, we may be unable to build anyway)
>
> Agreed, however the problem with that is they often use custom chips
> so we might end up with one toolchain per supported device.
>
> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>
> _______________________________________________
> Fsf-collab-discuss mailing list
> Fsf-collab-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/fsf-collab-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/fsf-collab-discuss/attachments/20140909/3627cbb4/attachment-0001.html>