libaums

libaums copied to clipboard

Forwarding from EtchDroid: https://github.com/EtchDroid/EtchDroid/issues/130

Not really an issue but I'm bringing this up since someone reported this. It might make sense to support the 16-bytes command set to support larger drives.

What do you think?

Hmm yeah I guess in general it definitely to exhaust the whole standard... But its time consuming to implement as you know :D

In this case though I guess it makes sense as larger disks are more and more common.

Can you maybe expand on what is wrong exactly? Is it the ReadCapacity command which fails?

So I guess yes, we only have the ReadCapacity(10) command and there is a ReadCapacity(16) command I assume. I think it is the same situation for the read/write commands.

I guess this can be determined from the inquiry response? Do have any more info on that?

Hmm yeah I guess in general it definitely to exhaust the whole standard

Alright, yes I wanted to know whether you considered it out of scope.

... But its time consuming to implement as you know :D

I know :) FWIW this can be an "up-for-grab" long-term goal.

I guess this can be determined from the inquiry response? Do have any more info on that?

The user reports seeing a negative size in the UI. The code responsible for it is this spaghetti mess:

https://github.com/EtchDroid/EtchDroid/blob/develop/app/src/main/java/eu/depau/etchdroid/ui/activities/ConfirmationActivity.kt#L109

Those values come straight from the InquiryResponse IIRC (toHRSize adds G, M, T, etc multipliers but otherwise expects a positive number).

I haven't checked yet if this is the case but it's possible that we're reading the value from the inquiry response as a signed integer and most likely the spec expects an unsigned integer.

If that's the case we can easily make another order of magnitude of USB drive sizes work.