Sorry...

I wrote that I use kernel version 2.2.13 but meant 2.4.13

/Flemming

Flemming wrote:
> 
> Hi,
> 
> I recently bought a Pontis SP600 MP3
> player and was hoping that I could use
> it with Linux for downloading MP3 files.
> The MP3 player identifies itself as a
> mass storage device via USB so with the
> proper drivers installed I hoped that it
> would work. Well it does work most of
> the times but I have faced some problems
> that I have been trying to debug for
> quite some time but now I'm stucked.
> First of all I had to add the following
> section to the unusual_devs.h files in
> the usb/storage directory:
> 
> UNUSUAL_DEV(  0x09bc, 0x0003, 0x0000,
> 0x9999,
>                 "PONTIS",
>                 "SP600",
>                 US_SC_SCSI, US_PR_BULK,
> NULL,
>                 US_FL_START_STOP |
> US_FL_FIX_INQUIRY |  US_FL_MODE_XLATE),
> 
> The US_FL_FIX_INQUIRY & US_FL_MODE_XLATE
> may actually not be needed but they
> don't hurt (I think) so I was just
> including them to be on the safe side.
> That was the easy part :)
> 
> With the above section I was now able to
> mount the /dev/sda1 device as a normal
> vfat drive and I can read and write to
> the drive. I now made a large file which
> just contains the binary numbers from 0
> to 63 repeated over and over again. I
> made a script which copies the file to
> the player, unmounts the drive remounts
> it and reads the file back and does a
> diff. This is then repeated over and
> over. In approx. 8 of 10 times the files
> are the same but some times they differ.
> When I analyze the difference I can see
> that the difference always occurs on a
> 64 byte boundary (USB package size?) and
> what happens is that within a 64 byte
> package data are shifted one byte. The
> first byte is simply replaced by the hex
> value 0x64 and the rest is shifted one
> byte so the last byte has disappeared.
> It is always the first byte in a 64 byte
> package and it is always replaced by
> 0x64 (which don't even exists in the
> file). That was my first problem...
> 
> I then thought that maybe I had a bad
> compact flash module so I tried with a
> different module and now something even
> more weird happened. I formatted the
> FLASH module on a windows machine and
> then when I tried to mount the drive
> under Linux the first 32 sectors was
> gone!. So what Linux thought was the
> first sector was really sector 32.
> Analyzing the raw data on the disk
> showed the everything after the 32
> sectors was indeed OK but since Linux
> skipped the first 32 sectors it couldn't
> find the MBR and didn't see it as a
> valid drive (FAT and root dir was also
> misplaced of course). It was possible to
> re-format the drive under Linux and then
> access it beacuse Linux simply placed
> the MBR at what it believes is the first
> sector but then the MP3 player didn't
> recognize the FAT because it was
> expecting the MBR and the file system to
> start at the real sector 0 - and Windows
> couldn't recognize it either. So does
> anyone has an idea what causes Linux to
> skip the first 32 sectors? Windows can
> see them and the MP3 player can see them
> so I know they are there..
> 
> I'm running Redhat 7.1 with a kernel
> 2.2.13.
> 
> Of course this may all be caused by a
> bug in the MP3 firmware but if anyone
> has ideas that I can try with Linux then
> please let me know.
> 
> Thanks
> 
> Flemming
> 
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to