Gerald Murray: > Quoting Lauri Pirttiaho <lauri.pirtti...@luukku.com>: >=20 > The genesys backend gl841 MAY be the closest to what=20 > you are describing here, but some details you mention > show small variance from the gl841. The backend for the > gl841 probably best described as an early start, or a stalled > project. The project remains blocked due to access to the=20 > registers, and unknown vendor read/write commands. From my > tests on Canon LiDE 35 that scanner NAKs every attempt I have > tried so far.
I took a look at the LiDE35 log that Pierre Willenbrock had on his www page. That does not look anything like the log of 3200F. There are few logs from 3200F on page http://www.coriolys.org/Sane/index.html, for comparison. > Providing details on what went down the usb bus would=20 > certainly help. The log from a scan may provide some clues > to what is currently unknown. Example of the boot of 3200F looks like following (this is abbreviated log of vendor specific control transfer messages in format time-out/time-in:URB dir request-type/request value inde= x length data): 000252/000252:0005 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dfe1f bl=3D0001 dt=3D26 000253/000253:0006 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffef bl=3D0001 dt=3D00 000253/000254:0007 > rt/rq=3D40/04 vl=3D00e0 ix=3Dffef bl=3D0002 dt=3D20 00 000254/000254:0008 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffb4 bl=3D0001 dt=3D8f 000254/000255:0009 > rt/rq=3D40/04 vl=3D00e0 ix=3Dffb4 bl=3D0002 dt=3Daf 00 000255/000255:0010 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffed bl=3D0001 dt=3D03 000255/000256:0011 > rt/rq=3D40/04 vl=3D00e0 ix=3Dffed bl=3D0002 dt=3D03 00 000256/000256:0012 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffe3 bl=3D0001 dt=3D05 000256/000257:0013 > rt/rq=3D40/04 vl=3D00e0 ix=3Dffe3 bl=3D0002 dt=3D05 00 000257/000257:0014 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffe2 bl=3D0001 dt=3D00 000258/000259:0015 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000259/000259:0016 > rt/rq=3D40/04 vl=3D00f0 ix=3D0000 bl=3D0005 dt=3D00 00= 00 00 00 000259/000260:0017 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000260/000260:0018 > rt/rq=3D40/04 vl=3D00f3 ix=3D0000 bl=3D0004 dt=3D00 4e= 00 00 > bl=3D009c00 00000000: 02 90 af 02 98 f0 d2 38 d2 34 22 02 86 e6 7e 00 First ten transfers are manipulations of the high addresses in the MCU address space. I wrote a program to dump the whole address space using these single byte accesses and I find the downloaded blocks in the dump (including the firmware) so I am confident about that. Address 0xffe2 contains an indicator about firmware upload so finding 0 there makes the driver to upload. If there is 0xbf the driver assumes the firmware is already uploaded and checks the version of the firmware. Write to value 0x00f0 indicates 32 bit address (in 16 bit words) for the following upload and write to 0x00f3 indicates length (again in 16-bit words). The data following is the MCS51 machine code. (The block uploads must start at 16-byte boudary and be a multiple of 16 bytes.) After the upload the driver actually downloads the same data, obviously for verification: 000268/000269:0020 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000269/000269:0021 > rt/rq=3D40/04 vl=3D00f0 ix=3D0000 bl=3D0005 dt=3D00 00= 00 00 00 000269/000270:0022 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000270/000270:0023 > rt/rq=3D40/04 vl=3D00f4 ix=3D0000 bl=3D0004 dt=3D00 4e= 00 00 < bl=3D009c00 00000000: 02 90 af 02 98 f0 d2 38 d2 34 22 02 86 e6 7e 00 =20 Now the write of the transfer length to value 0x00f4 initiates download; the download length seems to have to be multiple of 64 bytes. After verification of the code there are further settings like: 000282/000283:0025 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dfdf6 bl=3D0001 dt=3D3f 000283/000284:0026 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000284/000284:0027 > rt/rq=3D40/04 vl=3D00b0 ix=3D0000 bl=3D0003 dt=3D00 00= 00 000284/000315:0028 < rt/rq=3Dc0/04 vl=3D002c ix=3D0001 bl=3D0002 dt=3Dff 00 000315/000315:0029 > rt/rq=3D40/04 vl=3D002b ix=3D0001 bl=3D0002 dt=3Dbe 00 000315/000316:0030 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000316/000317:0031 > rt/rq=3D40/04 vl=3D00d0 ix=3D0020 bl=3D0003 dt=3D00 80= 00 000317/000317:0032 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000317/000318:0033 > rt/rq=3D40/04 vl=3D00d0 ix=3D0021 bl=3D0003 dt=3D00 80= 00 000318/000319:0034 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000319/000319:0035 > rt/rq=3D40/04 vl=3D00d0 ix=3D0022 bl=3D0003 dt=3D00 80= 00 000319/000320:0036 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000320/000321:0037 > rt/rq=3D40/04 vl=3D00d0 ix=3D0028 bl=3D0003 dt=3D00 4b= 00 000321/000321:0038 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000321/000322:0039 > rt/rq=3D40/04 vl=3D00d0 ix=3D0029 bl=3D0003 dt=3D00 4b= 00 000322/000323:0040 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000323/000323:0041 > rt/rq=3D40/04 vl=3D00d0 ix=3D002a bl=3D0003 dt=3D00 4b= 00 000323/000324:0042 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dfe00 bl=3D0001 dt=3D01 000324/000324:0043 < rt/rq=3Dc0/0c vl=3D002c ix=3D0006 bl=3D0001 dt=3D00 000342/000343:0044 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffb0 bl=3D0001 dt=3D30 000343/000343:0045 > rt/rq=3D40/04 vl=3D00e0 ix=3Dffb0 bl=3D0002 dt=3D30 00 000344/000344:0046 < rt/rq=3Dc0/0c vl=3D00e1 ix=3Dffb1 bl=3D0001 dt=3D3b 000344/000345:0047 > rt/rq=3D40/04 vl=3D00e0 ix=3Dffb1 bl=3D0002 dt=3D3b 00 000345/000345:0048 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000345/000346:0049 > rt/rq=3D40/04 vl=3D002b ix=3D0008 bl=3D000b dt=3D00 1f= 00 a7 01 cf 01 cf 03 ff 00 000346/000347:0050 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000347/000347:0051 > rt/rq=3D40/04 vl=3D00f0 ix=3D0000 bl=3D0005 dt=3D80 6e= 00 00 00 000347/000348:0052 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000348/000349:0053 > rt/rq=3D40/04 vl=3D00f3 ix=3D0000 bl=3D0004 dt=3D00 0f= 00 00 > bl=3D001e00 00000000: 07 07 07 07 07 07 07 07 06 06 06 06 06 06 06 06 The first read from address 0xfdf6 is some kind of counter ticking up at 1.1 counts per second and saturating to 200 (0xc8). The following write to=20 value 0x002b seems to be obtained by subtracting that counter, first adjusted by truncating multiplication by 25/24, from the value read from 0x002c. Meaning of this is yet unknown to me. Next writes to value 0x00d0 with various indices seem to be similar found in ScanMaker SM3840, a S&Q SCAN08 device, and they set the scanner black and gain values. Next there are reads and writes that are mystery, as well as the write to value 0x002b index 8 and the following upload to (byte) address 0xdd00. The upload has some structure in it, some 15 different kind of blocks. I have not deciphered their meaning, but the driver uploads different blocks for different purposes and the blocks seem to affect how the scans come out and how fast the head moves. I have more, but I think that shows that the procedure is unlike that found in Genesys based devices. I took a look at GL841 spec and there are several items that do not match, like the length of the gamma curve which for the 3200F seems to be 8kB (13-bit -> 8-bit map). My question is, has anybody seen this kind of protocol in other devices? That would give some hint about the Chip. > My read of the gl841 registers show that the home position > sensor would be in register 0x0041 >=20 > > values 0x0023 and 0x0024 index 0 which move the >=20 > Here the gl841 seems to show register 0x0022 and 0x0023 > for this, probably. What you see from the value 0x0040 index 0 looks like 000486/000487:0097 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 00 000487/000488:0099 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D20 00 000589/000590:0104 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D21 ff 000855/000856:0121 < rt/rq=3Dc0/04 vl=3D0040 ix=3D0000 bl=3D0002 dt=3D00 ff The first you see when the head is home, the second when the head has started moving out, third when it is moving further out ad the last when the head is out but stopped. The move-forward commad looks like 000487/000487:0098 > rt/rq=3D40/04 vl=3D0023 ix=3D0000 bl=3D0005 dt=3D00 02= 26 02 00 Where the first word (two bytes, LSB first) is the distance to move and the fourth byte seems to affect the speed (2 for low speed, 4 for high). Move-backward seems similar but has value 0x0024. > The logs that would show data being written to the address > of a MPU are of interest, as the gl841 still has some=20 > unknown problems that stall that backend. I am currently in process of crawling through the disassembled firmware (typical compiler output of loop type scheduled control program, with c-init, hw-initialization code and an event loop, events of which seem to be generated by interrupts). I hope from that I can get more hint on how the system is controlled and what the mystery uploads to 0xdd00 do (or it may also be that the HW other than the MCU actually uses those blocks). I will keep you posted when I get more publishable results. With best regards, Lauri Pirttiaho Oulu Finland ................................................................... Luukku Plus paketilla p=E4=E4set eroon tila- ja turvallisuusongelmista. Hanki Luukku Plus ja helpotat el=E4m=E4=E4si. http://www.mtv3.fi/luukku
