free firmware mistakenly removed by LinuxLibre

[Felipe Sanches]

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