OSDev.org

Hello,

I have been working on a mass storage device driver for ehci for a while now.
The idea is to run it on my emulator (qemu) and on real hardware.

The system detects the class of the attached device on real hardware and on the emulator.
Also the function of selecting a configuration works.
Getting the max lun works aswell which is on real hardware and on the emulator 0.

The things that are not working comes at this point.
I start with issuing the command "inquiry" via the scsi protocol.
Here the first strange things are happening.
The first thing is that on the emulator, I need to send the command via endpoint 2 and then recieve it at endpoint 1.
At real hardware, this causes a "halt" error unless I send and recieve data on endpoint 1.
The second problem is that according to the specifications of the mass storage devices for usb, you should wait for the controll block to be recieved.
On emulator this works perfectly but on real hardware it keeps waiting forever (more then 5 seconds and then my software issues a timeout).
The third problem was when I tried to load a sector from the device. qemu somehow only sends data in chunks of 144 bytes of data while real hardware uses the full 512 bytes at once.
The fourth problem was that when I read the first sector (0) then the emulator makes the sector end with 0x55 0xAA like I expected but on real hardware it returns different things and it does not look like anything I expect at all.

This is the code for the stick:
https://github.com/AdeRegt/SanderOSUSB/ ... ci_stick.c

This is the code for EHCI:
https://github.com/AdeRegt/SanderOSUSB/ ... dev/ehci.c

I hope someone can help.
Thank you in advantage

Which can be the case. Different hardware, different endpoints.

A device can have the bulk out at EP1 with the bulk in at EP2. A different device may have just the opposite. A different device may have both the in and the out on the same endpoint number.
Do you check the bits within the Endpoint Descriptor to determine which endpoint is the IN and which is the OUT?


I don't know what you mean by this. Are you talking about the Command Block Wrapper, the 31 byte block you send to the device when using the BBB protocol?

When reading data from the device, you send the CBW, then wait for the data to arrive, including the Command Status Wrapper, of course checking for stalls/etc. at all packets. When writing data, you send the Command Block Wrapper and wait for the device to accept the block before you start writing data.

Ben

Thank you for your answer.

I did read it and try to apply it in a way I understand.
I did now read the descriptor and this is showing that bulk in and bulk out on real hardware are on ep1 and on the emulator on ep1 and ep2.
I just do not understand why I need to chunk it down into pieces of 144 in the emulator and 512 on real hardware. I do not see where this is defined.

I wrote a CommandBlockWrapper of 31 bytes and put me command inside there.
On the emulators it runs perfectly and I can run more then 1 command and after recieving each command I wait for the CommandStatusWrapper.
On real hardware I can only run it once and after sending the CommandBlockWrapper I get right away the CommandStatusWrapper followed by data which is partly hidden by the CommandStatusWrapper. After trying to send the next command or when Im trying to get the rest of the data, my system issues a timeout after waiting for 5 seconds.

I do not understand this behavour

This is a great example of why you have to read in the EndPoint Descriptors and write your driver to allow different numbers and directions on these numbers.
Your actual hardware is using the same number for both IN and OUT (which is perfectly legal), yet the emulator uses two different numbers, one for IN and one for OUT.


You don't. There is clearly a mistake somewhere. The value of 144 is not a valid transfer length, unless it is the last packet and then not likely. What I would look at is the MaxPacket field of the Endpoint Descriptor. The emulator might have it as 512 (for a super speed device) yet the real hardware may have it a different size, maybe 256 or even 64, though 512 would be likely.

Also, since you are using the xHCI, you will need to make sure you have set up your CONTEXTs correctly to mirror the endpoint values. The CONTEXT max packet size must match the endpoint max packet size, etc.


I don't understand it either. If you are receiving the CSW just after sending the command, you most likely have an error in your CBW.

Check the command you are sending. Different BBB devices will either use the RBC (Reduced Block Command) commands, actual SCSI commands, MMC5 commands (usually a CDROM), as well as a few other variants. The Device Descriptors will tell you which Command Set you can use for this device.

After determining the Command Set, a Super-Speed Thumb Drive then might use UAS or BBB transport. A Full- or High-speed device will use BBB, with some High-speed devices using UAS.

USB is far from simple. It takes a lot of work and a lot of reading to get all of it. I still have issues with my code on some machines using some devices and I have been at it for 20+ years. :-)

Good luck,
Ben

Edit: I need to read the subject lines more often. I was still in your xHCI thread and not thinking I was in your EHCI thread. Sorry about that. Anyway, most of the above still is valid for EHCI.

Good afternoon,

I am working on EHCI for a while and I am able to read a sector on real hardware ( read_10 instead of read_8) and I am able to do a controll takeover from the BIOS. The thing is, that all answers begin with the CommandStatusWrapper in the beginning, missing the first 13 bytes of the sector. the rest of the 512 bytes are correct ( I tested it on my ubuntu computer to read the contents of these sectors).

This is my code: https://github.com/AdeRegt/SanderOSUSB/ ... sb_stick.c

I hope someone can help me to find out why the CSW is at the beginning.

Thank you in advantage!