On Sat, 5 Dec 2009, Andreas Kemnade wrote: > I analyzed it a bit with a thinkpad x31 > The g_file_storage gets upset by some non-zero bytes in the end of a > READ TOC command. > > <7>00000000: 55 53 42 43 42 49 4f 53 0c 00 00 00 80 00 0a 43 > <7>00000010: 00 00 00 00 00 00 00 0c 40 00 00 00 00 00 00 > <7>g_file_storage gadget: SCSI command: READ TOC; Dc=10, Di=12; Hc=10, Hi=12 Yes, it's that 0x40 byte at the end of the command. According to the SCSI-2 spec, that bit is supposed to be vendor-specific. > <7>g_file_storage gadget: bulk-in, length 12: > <7>00000000: 00 00 00 00 00 00 00 00 00 00 00 00 > <7>g_file_storage gadget: sending command-failure status > <7>g_file_storage gadget: sense data: SK x05, ASC x24, ASCQ x00; info x0 > <7>g_file_storage gadget: bulk-in, length 13: > <7>00000000: 55 53 42 53 42 49 4f 53 0c 00 00 00 01 > > And then a sector size of 2048 (instead of 512) as usual for cdrom > drives is assumed. The following should read the el torito info block, > but the BIOS gets the wrong data due to the wrong sector size (offsets > are wrong). > > <7>g_file_storage gadget: bulk-out, length 31: > <7>00000000: 55 53 42 43 42 49 4f 53 00 08 00 00 80 00 0c 28 > <7>00000010: 00 00 00 00 11 00 00 01 00 00 00 00 00 00 00 > <7>SCSI CDB: 28 00 00 00 00 11 00 00 01 00 00 00 > <7>g_file_storage gadget: SCSI command: READ(10); Dc=10, Di=512; Hc=12, Hi=2048 > <7>g_file_storage gadget: READ(10) is buggy! Expected length 10 but we got 12 > <7>g_file_storage gadget-lun0: file read 512 @ 8704 -> 512 > <7>g_file_storage gadget: bulk-in, length 13: > <7>00000000: 55 53 42 53 42 49 4f 53 00 06 00 00 00 > > The following patch solves the problem for the BIOS. I am able to load > a kernel and an initrd with it correctly. Of course, it breaks everything > else but it can be considered as a proof of concept. I can boot from my > my g_file_storage cdrom drive with it on that thinkpad X31, on a mainboard with award > bios (with an AMD Geode 1700+ on it) and also on an INTEL D945GCLF board. No, this isn't a good approach. A better fix would be to change the byte mask in do_scsi_command()'s SC_READ_TOC case. In the fourth argument to check_command(), change (7<<6) to (0xf<<6). It's hard to know whether this will fix the incorrect block size, though. But that's just a workaround. The fact is, the BIOS is sending incorrect data. The same is true with the 12-byte READ(10) command, although here g_file_storage accepts the bad length with only a warning. Alan Stern -- 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
