OSDev.org

I don't know what you mean by changing Bochs settings.
The USB specification states that, for the Control Pipe, a low-speed device must have a MPS of 8, a full-speed device can have a MPS of 8, 16, 32, or 64, while a high-speed device must have a MPS of 64.
There is no settings to change that, and there shouldn't be.

If you declare the MSD as full speed, Bochs currently sets the Control Pipe MPS to 64. You can change this in the source code to either 8, 16, 32, or 64. If you do, remember to change the Device Descriptor and the d.endpoint_info[0] information as well.

Depending on the speed you choose, there are a few places in the code that you have to do this. Hence, it shouldn't really be changed.

Also, Bochs absolutely does allow you to change the speed of the device.

In your bochsrc.txt file, you can set the speed to full, high, or super. However, since you are currently using the uhci, full is the only option. An MSD device must not be low-speed.

Here is the bochsrc.txt file I use to run your latest image:

The serial.txt file has:


Ben

I'm sorry for my poor phrasing, I'm not practical with Bochs I meant to declare the USB device as a specific speed and not leave the default but obviously you already tried that I'm sorry. Since my driver relies on the status of the USB port to choose the packet size and somehow it doesn't recognize the port to be connected to a full speed device before initialization it outputs a zero as a packet size and so divides the size of the data in N packets of size zero.


This is weird, in the last commit I added some more logging to the image that should at least suggest where the crash happened. Anyway I'm pushing a new image that hardcodes the packet size to 8 if the port is in an unknown state (?). Basically I'm modifying this line.

Here is the image

Got it. Will try it out when I get a chance.


There is nothing wrong with using an 8-byte packet size on any device (for the control pipe). It is perfectly legal.
However, usually, and it is stated in the specs, you assume an 8-byte MPS for low-speed, and 64-byte MPS for full- and high-speed. Once you retrieve the first 8 bytes of the Device Descriptor, you then adjust accordingly.

Ben

It looks like you get everything up to and including the "INQUIRY" CBW out, but your fail on the Data IN.

This is the first time you read from the Bulk IN endpoint, correct? The Toggle should be 0.
Remember, each endpoint (and most of the time, each direction), has its own toggle bit.

Are you using a toggle bit of 0 for the CBW, then "carrying" this over to the Data IN? That would be wrong.

The Toggle will be 0 for the CBW, 0 for the Data IN, and then assuming only one data IN for the INQUIRY, a toggle of 1 for the CSW.
The next out (which should be another CBW) will have a toggle of 1 now, with the first in having a toggle of 0.

Ben

Hm no every time i initialize a new transfer operation i hardcode a start value for the toggle and all the packets of the same request follow the sequence.
This means that for example if I start a control in transfer of 6 packets they'll have toggle: [ 1, 0, 1, 0, 1, 0 ]
Same thing for bluks. I'm not sure why my code starts toggle at 0 for out transfers and at 1 for in transfer. Maybe I misunderstood some documents...
Here, here and here. So you are suggesting keeping a flag stored along the infos for the endpoint and using that to have consistencies along transfers?

EDIT:
From the wiki:

So for control transfers, I got it right by starting every new transfer at zero and going forward flipping for each packet, since the toggle state resets for each new transfer (since it always starts with a setup packet). Instead for bulk I'm a bit confused. "0 upon any configuration event" means every time a control packet with SET_CONFIGURATION in the setup is sent to another endpoint? or something else? Does this mean that even if the bulk transfer ends I should keep track of the current toggle to continue the sequence for the next one?

Exactly. Bulk endpoints don't understand when a "new transfer" begins. Every Bulk TD toggles its toggle bit. Only on an EP reset does it "start over" at 0.
An EP reset can be a CONFIG request, CLEAR_FEATURE request, or an actual hard reset.

Ben

YES! kinda, the device answers to the inquiry and the read capacy commands successfully. I'm correctly printing the product ID, the LBA size and the block size.
Trying to read the first LBA fails tho... I'm not sure how to decide the max packet size so I'm using the read12 command which be supported on any scsi device theoretically. IDK maybe I'm missing some bits somewhere, still working on QEMU but not in real hw... well I pushed the image with the updated code and some other logs. Meanwhile I'm scanning back and forth the SCSI specs looking for some dumb mistake.
Thanks a lot again :)
I really doubt after this there is going to be anything else wrong (i really hope)

The difference between a read10 and read12 is the transfer length, which is a count of logical blocks to transfer.

Assuming a block size of 512 bytes, that allows for a transfer size of about 32MB (16 bit count, 25 bits total) with read10, and read12 allows for considerably larger transfers, probably bigger than most USB media (32 bit count, 41 bits total.)

Given that read10/write10 is completely practical for use with most USB drives, it wouldn't surprise me if read12 wasn't supported.

Have you tried with read10?

The block size of the device is of 0x20000, so I assumed read12 could be fine, but yea! read10 works great! I'm able to read from the device. This last one was dumb I could've figured that out XD

So... I'm calling this driver a success :) It all works. now I need to make the code actually look pretty and work for some other special cases but yea other than that, thanks a lot for the awesome help! I think this thread has fulfilled it's purpose

I noticed such a difference between hardware and QEMU.
When you are waiting to resetting "Status active" in"qTD_Token", in QEMU you need to make something like "sleep". In my "sleep" role I had a call to interrupt the BIOS for display.
It may be useful for you to look at the GitHub repository https://github.com/Alex0vSky/TinyEhci, although it is purely assembler (nasm) and everything is confusing to fit into 512 bytes.

I think you should always assume the maximum packet size is eight bytes unless you know otherwise from the descriptor

Yeah. I mean, it makes little difference. The only things you need in order to know the correct packet size are the "address device" and "get descriptor" requests (for the first 8 bytes of the device descriptor), and those all fit inside 8 bytes. Unless you are on XHCI, then you don't even need "address device".

Hm the max packet size in the device descriptor for my hardware is 64 but I have to use read10 cause any larger read won't work for some reason.

That's something different. The max packet size for EP 0 just tells you how big the packets on the control pipe can be. What you are talking about is what part of SCSI is implemented. That is a completely different layer of communication.

I'm sorry I'm still not that proficient with SCSI I mistakenly assumed it was the same from the USB descriptor. So this is a specific length for SCSI, how do I get it? is it in the inquiry result or another specific command I must send?