MollenOS wrote:
My problem is that I'm having some issues with bulk transfers (not in general, but specific data transfers when using the scsi protocol). I send the SCSI_READ_10 command to the MSD device, and I can see from the bochs logs that it correctly recognizes the command:
We then move on, and queue up some bulk-in td's for 512 bytes in total + 13 bytes for the CSW. So that is 9 td's in total. This is where it gets a little bit iffy, as I can see the behaviour is that bochs 'defer' my tds, I then inspected the source code of bochs and found that it does this to simulate the seek delay of a disk drive. It fires an interrupt in spite of not having transfered any data yet. I don't do anything, and my Td's are untouched (still active, ioc bit still set), so I leave them there for now. I can then see it keeps trying to handle my td's untill data is ready:
Do you have the latest build of Bochs? Not necessarily the last released version, but the latest from the
SVN? Up until recently, the Debug output would incorrectly print the deferred message multiple times. That has now been fixed in the latest source.
MollenOS wrote:
Now here comes my issue, it seems that now that the data is ready, it then tries to handle my Td's again, but it still does not transfer any data untill it encounters my CSW td, if you notice the <r_actlen = 0x000D r_maxlen = 0x000D>, this means the td is actually being executed. Why does it never execute my data td's asking for the 512 bytes of data? But only handles my CSW td?
The technique for a BBB (Bulk/Bulk/Bulk) transfer is to send the CBW and wait for a successful packet transfer. If there is no stall or NAK, you can then start to send or expect to receive the Data Packets. Your driver should check for a Stall on each packet.
Then, no matter the success or failure of the Data Packets, (the middle 'B' of 'BBB'), the device will send a CSW. However, remember to clear the stall before you expect the CSW.
Are you able to compile/build the latest Bochs source? If so, I recommend that you do. This will eliminate the confusion you are getting with the deferred debug messages.
Also, don't try to receive the CSW until you are sure the other packets either succeeded or failed and you have cleared the fail.
My guess is that Bochs received your CBW, failed on the Data Packets, then you expect the CSW. However, look at:
Code:
00198099950d[USBMSD] E9 C9 11 50 53 88 E3 C0 E3 04 24 0F 08
That is not a valid CSW signature. Could that be part of the sector you are expecting on the read?
Another note: I did not code Bochs to check for the toggle bit (this is a TODO on my long list), but you need to verify that the toggle bit is correct on all packet transfers. This gets a little tricky when there is an error with the 'middle B' transfers and then the CSW packet expects a valid toggle bit. Your code needs to make sure the toggle bit is preserved. Please note that if you clear a stall, the next toggle bit expected is a zero.
Ben
http://www.fysnet.net/the_universal_serial_bus.htm