So I'm onto to investigating EHCI (USB2). I've already spent some time looking through the specifications and one of the most notable differences compared to UHCI is the way that Queue Heads are used. In UHCI, the Queue Heads are arbitrary structures that are only used by software to organise Transfer Descriptors as it sees fit. In EHCI, the Queue Heads contain all the information that pertains to a single USB Device Endpoint. This makes a lot of sense as the transfer descriptors don't need to duplicate all this information each and every time, they can be linked to the Queue Head which will contain it.
Another significant difference is that the Frame List for periodic, scheduled transfers has been separated away from the "reclamation" list of transfers to happen as soon as possible (what it refers to as the Asynchronous list).
If you read the UHCI article, you'll know that I tried to disable the EHCI controller before by adjusting the CONFIGURE flag. Turns out that I may have missed a fairly vital step from that code that I have implemented this time around. The EHCI controller has a flag in it to indicate if it is "owned" by the BIOS (for USB legacy support of keyboards and whatnot) and another for if it is "owned" by the OS (which is what we want). There is a protocol for requesting ownership from the BIOS so the two code-bases aren't competing and confusing things. That actually explains some of the problems I was having before ...
After writing structures which match the EHCI Queue Head and Transfer Descriptors (called a Queue Element Transfer Descriptor) from the specification, I have used many of same steps as the UHCI code to reset the EHCI controller. I have also created three Queue Head structures as global variables, one for the Control endpoint of the Flash Drive, and one each for the Bulk In and Bulk Out endpoints that the USB Mass Storage Class specification says it should have. I have connected these three Queue Heads together in a linked list, programmed the EHCI adapter with the start address and set it running. My intention is to create Transfer Descriptors as required and add them to the linked list from the relevant Queue Head.
One note about the structures for the Queue Head and the other USB in-memory structures is that they all have to be aligned to specific byte alignments. I'll admit I may have cheated here and padded each of the structures to a multiple of their required alignment. This allows me to create an array of each type of structure and for every element of the array to be correctly aligned.
In order to test that the EHCI controller was actually parsing the list of queue heads, I changed some of the Queue Head values to be gibberish and confirmed that the EHCI controller reported an error (tee hee).
The EHCI controller has the same "Port Status and Control" registers, and I have written some code to loop through these and display the values of the various status bits. This I have used with a single test device to identify which port numbers correspond to which physical ports.
Happy that the Queue Heads are working correctly, I've moved onto forming a few Transfer descriptors to try to get the device descriptor for my test device.
64-bit Woes
At this point, I will spare you many of the details, but there was a lot of swearing and many many hours (days) of reading back and forth through the EHCI specification, my code, a whole load of articles on-line and my book on USB all to try to track down a single issue that had a stupid cause. The issue was that as the EHCI controller processed the transfer descriptor, it experienced a transfer error (not surprising at the moment) but then the USB controller encountered a "Serious Error" and stopped itself. With investigation, the transfer descriptor was being copied into the Queue head (which is correct) but in doing so it appeared to overwrite the beginning of the next queue head, which caused the queue processing to fail. The irritatingly simple answer was that the EHCI controller is 64-bit capable and as such, I need to use the 64-bit version of the Transfer Descriptor, which is longer than the 32-bit one that I had coded. The adapter copied this extra length, and trashed the following data.
Once that was fixed, progress was swift, and I soon had the device returning its device descriptor.
Device Descriptors
In USB, every device has a Device Descriptor which gives basic information about the device, including the number of configurations it has (almost every device only has one configuration though). It then has one Configuration Descriptor for each configuration which includes a number of Interface Descriptors and Endpoint Descriptors. It's important to note here (as it kept me confused for a day) that when you issue the GET_DESCRIPTOR request for each Configuration Descriptor, the Interface and Endpoint Descriptors for that Configuration are returned IN THE SAME REQUEST, then you parse them for the interface and endpoint details.
With all this information, I was able to read the Device Descriptor and read the single Configuration Descriptor (good) which had a single Interface Descriptor (with a class of Mass Storage device, good) and two Endpoint Descriptors (on for data in, one for data out). The interface descriptor also told me that the device used the SCSI command set to actually read and write blocks which is fine because I used this briefly before when writing an ATAPI driver for CD-ROMs.
At this point, I got bored and rather than writing a proper parser to read this information to set up the queue heads for the mass storage endpoints, I just hard-coded the endpoint numbers and the other parameters. They won't change for this device and I'm keen to keep up the progress.
Next thing to do is to actually send the SCSI command to the correct endpoint to request the data. For this, the USB Mass storage specification says that I create a Command Block Wrapper (CBW) structure which wraps the SCSI command for the transfer, and use a Command Status Wrapper structure to receive the SCSI response. I've played around with a few different SCSI commands, but that only one that seems to not error is the READ(10) command (so called because it is a 10-byte buffer that represents the command), but with this IT HAS READ A BLOCK!! tada.wav!
One odd thing here is that if I issue a SCSI command that is invalid, the error is reported by the device endpoint halting. This is really annoying as surely this error should be reported in the SCSI status data. I don't know if all USB mass storage devices do this, but in my view this breaks encapsulation. If the SCSI command is invalid or fails, then the SCSI response should indicate this, not the USB layer.
With this success, I have run a few stress tests, and unfortunately it stopped reading blocks after 50 or so, this was a fairly simple cause in that I wasn't free()ing the CBW and CSW structures, so eventually I was running out of memory (I only keep a small amount of memory available to the kernel to discover such memory leaks).
The Block Device Driver
Now that the EHCI controller is capable of reading blocks, I have created my OS's wrapper structure for the USB mass storage device (this structure is the one that provides a consistent interface for all block devices with such functions as ReadBlock() and WriteBlock()).
In debugging this, I encountered another issue I hadn't expected. Now that I'm testing on real hardware the memory is not clear when the machine boots, instead is contains a good deal of whatever was in it before the last reboot. This caused some issues where I had been sloppy and not properly cleared memory that I had allocated prior to using it and the code had assumed that unset areas were zero (bad practice, I know). A quick tweak to the malloc() routine and all memory is being cleared automatically when it is allocated (although I guess I should use calloc()).
===========================================================================
Commercial product - do not distribute!
Please report software piracy to the SPA: 1-800-388-PIR8
===========================================================================
M_Init: Init miscellaneous info.
R_Init: Init DOOM refresh daemon - Error: W_GetNumForName: PNAMES not found!
Exited!
Ok, now what?
Filesystem Testing
When I encountered this error before, it was because the file seeking wasn't working properly and it couldn't seek to the end of the WAD file where the index is. Rather than continue to use Doom to validate the filesystem code, I thought I'd take a different approach.
I have written a small .NET program which generates a 16Mb file of random data, which it then tweaks so that every 512-byte block of the file checksums to a specific value which is 0xBEEF0000 where the lower 16 bits contain the block number. Using this file on the key and a checksumming algorithm in the kernel (referred to as the Beef Test), I can quickly test various file operations to make sure they are behaving correctly.
With the aid of this, I was able to track down one of those really-simple-but-hard-to-debug issues. It was a simple matter of the USB device driver dereferencing a NULL pointer, then using the resultant information as the size to a memcpy() operation, which wrote beyond the allocated memory block, which trashed the memory block header, which made the memory allocator think it was out of memory, which caused an allocation in a completely different part of the kernel to fail and error.
If I get the OS working with any hair left, it'll be impressive.
Anyway, according to my checksum test file, all the file operations from the USB flash drive are working, the system is capable of reading a 16MB file without issue, and there are no memory leaks being encountered.
So let's change the main() routine back to loading the Doom executable and see what happens.
No comments:
Post a Comment