---------- Forwarded message ---------- From: Felipe Sanches <juca@xxxxxxxxxxxxxxx> Date: Tue, Jan 4, 2011 at 4:47 AM Subject: misterious discrepancy between keyspan_pda source code and firmware binary To: warner@xxxxxxxxxx, gregkh@xxxxxxx Hello, Brian and Greg I am working on development of free firmware in the LinuxLibre project: http://jucablues.blogspot.com/2010/12/coordinating-efforts-towards-free.html And today I have tried to add a Makefile for your keyspan firmwares in Linux. But I noticed something interesting and I'd like to have your feedback. The following message is long, sorry. The context is a discussion of whether we should always build firmwares from source code or if it's ok to ship pre-built binaries. While working on the Makefile I found some discrepancy between the source code and the binary of keyspan_pda firmware. Maybe it is a bug. 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 march 2000 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@xxxxxxxxxxxxxxxx/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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
