Re: DeviceFS USB reading problems

In message <0b4fb81a4e.james@xxxxxxxxxxxx>
James Pea*** <news@xxxxxxxxxxxxxxxx> wrote:

Christian Ludlam wrote:

On 20 Apr James Pea*** wrote:

[snip]

I've no idea what I'm doing wrong here. I could accept the device
is broken or mis-configured, but OS_GBPB appears to be returning
bogus data, which should never happen.

I think this is a bug in the RISC OS USB drivers. I had the same
problem trying to write a driver for a device I built: transfers work
fine when you send data in multiples of wMaxPacketSize (the number
after the blue and white square in USBInfo), but as soon as you send
an incomplete transfer the receive buffer would become full of
uninitialised data, and OS_GBPB would always return 1024 bytes.

But aren't USB devices allowed to send short transfers over bulk
endpoints to mark the end of a multi-packet transfer?

I've just tried 512 bytes (wMaxPacketSize). I still get over-sized
packets - but there is no crud at the end, which is a modest
improvement.

There was a problem with the way that the interface to the mass storage
device layer was implemented, in that not all devices were returning the
expected number of bytes, and since this call was being made using a
blocking call the system was locking up. This was rather inconvenient in
the context of a filing system, and from where I was, the easiest
solution seemed to be to fill up to the end of the call with zeroes so
that the OS_GBPB call would actually return.

The exact behaviour is: if a non-maxpacket sized request is received but
there are still bytes outstanding on the transfer, then the rest of the
transfer is filled in (although only the first maxpacket sized chunk will
be zeroes):

if ((xfer->actlen % UGETW(xfer->pipe->endpoint->edesc->wMaxPacketSize)) &&
str->count != str->totalcount && !xfer->pipe->repeat)
{
char zero[ UGETW(xfer->pipe->endpoint->edesc->wMaxPacketSize)];
memset (zero, 0, sizeof zero);
/* fill up the rest of the request with garbage! */
_kernel_swi_regs r;
r.r[0] = BM_InsertBlock;
r.r[1] = (int) str->buffer_id;
r.r[2] = (int) zero;
r.r[3] = str->totalcount - str->count;
CallBufMan (&r);
}

I clearly missed the case that the fragment might occur before the last
maxpacket, so the comment is more correct than it should be.

So indeed you will unfortunately find that there is never a remainder
returned from the OS_GBPB call.

This value is accessible but not in a very satisfactory way. When the
stream is created, the driver handle is exposed in UpCall_StreamCreated
in R1. This is a pointer to a structure which contains details including
the real number of bytes sent at word 12 (str->count in the fragment
above), and the total size of the transfer at word 13 (str->totalcount in
the fragment above) (just in case you want to check you've got the right
position). I've only got these numbers by inspection of the structure - I
haven't tested that these are the right offsets, so please verify that
totalcount is what you expect.

I tried to sort this out with Dan, but I don't think we got to the
bottom of it. I eventually worked around it by changing the device
itself, so not sure if this helps you :-/

Unfortunally, the device is a off the shelf thing I picked up cheap
based on the AX88172 chip. The data*** is somewhat lacking in vital
information, though the NetBSD driver is more helpful.

This is annoying as I've almost got everything working.

Sorry about that. I'd moved onto other pastures when the mass storage
problem occured and wasn't able to provide a better fix.

To be honest, you could probably do with a better API to get good
performance from a USB ethernet chip. After doing RISC OS USB I worked
with other OSes, and did quite a bit on chips like that, optimising the
performane.

Good luck!

--
Dan Ellis
.

Loading