USB questions
Posted: Sat Aug 20, 2022 7:43 pm
Got a bunch of questions while trying to make usb work:
1. power and PM
I know these are huge areas themselves and have no intention to get into them now, but have 2 questions:
Power:
IIRC software needs to keep track of the total power usage. There are also max current/self-powered fields in configuration descriptor.
But where do I get info on the total amount of power available to a port or to the whole root hub?
Is it okay to simply use devices without looking at their required power and let the port figure that out and go into over current state as needed?
PM:
Not trying to save a few mini watts now and I do disable features like hw LPM.
Does PM have implications other than power usage though? Such as meaningfully damage (heat?) the device/controller because of not allowing them to go into lower power states?
There's also a "Max Exit Latency" field which the software should fill but seems quite difficult to calculate. It seems to be quite closely related to link and topology, and hub is something I don't have any support for.
Is it okay to keep Max Exit Latency 0 on real hardware? What are the downsides of doing so?
2. MSD (BBB)
cmd set:
I only tried qemu's "usb-storage" drive. Some scsi cmds work on it, while others like the 16B read capacity (opcode 0x9E) return a cmd failed error (CSW status 1).
Is there a good list of the subset of scsi cmd set commonly supported by BBB flush drives?
LUN:
As I understand, LUN is a concept about SANs or big raid boxes, where physical disks are "raided" into logical arrays and then exposed as LUNs to the users. How does this apply to a flash drive?
Reliability and error handling:
The word stall appears a lot in the specs. Almost giving me the feeling that a BBB drive is ready to stall on a whim anytime. Fortunately the qemu usb-storage drive seems quite stable.
For real world flush drives though, does the wiki warning "In real hardware, floppy drives are extremely unreliable. On emulators, it doesn't matter -- but for code that is intended for real hardware, make sure to retry every command at least twice more after any error." about floppies apply?
In other words, if the drive indeed stalls the bulk pipe, is it a good idea to retry the same "CBW->DATA->CSW" sequence a few times, or is this unlikely to work if the first attempt failed?
3. HID
More than 1 keycodes per report:
Spec 1.11 says that "the order of keycodes in array fields has no significance".
How should I deal with the situation of more than 1 keycode in a report? For now discarding any reports like that gave the "expected" behavior when typing fast.
But I can't believe that this is the "correct" way, otherwise, why would the keyboard have the feature to report more than 1 keycode?
Maybe this is a general keyboard question, should I try to track the "make" and "break" of non-modifier keys? What would be a good use case where someone would hold down more than 1 (non-modifier) keys at the same time?
Report descriptor parsing:
It seems that report descriptors, at least the qemu ones, are easy to parse manually. But there's a huge usage table and depending on the chosen page there can be lots of variations. Which makes it be difficult to write code to process them automatically.
For now I created a short list of supported devices, and don't operate on any device not on the list.
Is there a good middle ground between this and a "real" HID parser?
1. power and PM
I know these are huge areas themselves and have no intention to get into them now, but have 2 questions:
Power:
IIRC software needs to keep track of the total power usage. There are also max current/self-powered fields in configuration descriptor.
But where do I get info on the total amount of power available to a port or to the whole root hub?
Is it okay to simply use devices without looking at their required power and let the port figure that out and go into over current state as needed?
PM:
Not trying to save a few mini watts now and I do disable features like hw LPM.
Does PM have implications other than power usage though? Such as meaningfully damage (heat?) the device/controller because of not allowing them to go into lower power states?
There's also a "Max Exit Latency" field which the software should fill but seems quite difficult to calculate. It seems to be quite closely related to link and topology, and hub is something I don't have any support for.
Is it okay to keep Max Exit Latency 0 on real hardware? What are the downsides of doing so?
2. MSD (BBB)
cmd set:
I only tried qemu's "usb-storage" drive. Some scsi cmds work on it, while others like the 16B read capacity (opcode 0x9E) return a cmd failed error (CSW status 1).
Is there a good list of the subset of scsi cmd set commonly supported by BBB flush drives?
LUN:
As I understand, LUN is a concept about SANs or big raid boxes, where physical disks are "raided" into logical arrays and then exposed as LUNs to the users. How does this apply to a flash drive?
Reliability and error handling:
The word stall appears a lot in the specs. Almost giving me the feeling that a BBB drive is ready to stall on a whim anytime. Fortunately the qemu usb-storage drive seems quite stable.
For real world flush drives though, does the wiki warning "In real hardware, floppy drives are extremely unreliable. On emulators, it doesn't matter -- but for code that is intended for real hardware, make sure to retry every command at least twice more after any error." about floppies apply?
In other words, if the drive indeed stalls the bulk pipe, is it a good idea to retry the same "CBW->DATA->CSW" sequence a few times, or is this unlikely to work if the first attempt failed?
3. HID
More than 1 keycodes per report:
Spec 1.11 says that "the order of keycodes in array fields has no significance".
How should I deal with the situation of more than 1 keycode in a report? For now discarding any reports like that gave the "expected" behavior when typing fast.
But I can't believe that this is the "correct" way, otherwise, why would the keyboard have the feature to report more than 1 keycode?
Maybe this is a general keyboard question, should I try to track the "make" and "break" of non-modifier keys? What would be a good use case where someone would hold down more than 1 (non-modifier) keys at the same time?
Report descriptor parsing:
It seems that report descriptors, at least the qemu ones, are easy to parse manually. But there's a huge usage table and depending on the chosen page there can be lots of variations. Which makes it be difficult to write code to process them automatically.
For now I created a short list of supported devices, and don't operate on any device not on the list.
Is there a good middle ground between this and a "real" HID parser?