Raspberry Pi Model A USB Boot

If the Model A Raspberry Pi is started up without a formatted SD card, it will default to USB Boot mode. In this mode, you can install a “first stage bootloader” via USB from another computer running the necessary Boot Server code This then turns the Pi into a Mass Storage Device, which you can either keep plugged in, or even unplug (keeping power connected) and move to another system. You can then copy your disc image to the SD card as though the Pi was a simple card reader.

I’ve installed this code on Raspbian on a Pi, and sure enough, plugging in a Model A causes the server to find the Model A and send the bootloader code to it, turning it into a Mass Storage device.

Plugging the unformatted Model A into a PC (not running the Boot Server code) causes the PC to see an unknown USB device. It is still possible to read the USB Descriptors from it through.

Now we come to the problem. Plugging an unformatted Model A into a RISC OS Pi causes the Pi to become unresponsive for around 7secs (mouse moves on screen, but keyboard and mouse buttons unresponsive), then control is returned, but the Pi doesn’t report the Model A as being present (!USBInfo does not show it, nor does it acquire a USB$Device system variable).

Is there any obvious reason why RISC OS is not seeing the Model A as a USB device? If it did, then it should (hah!) be fairly easy to port the Boot Server code and allow us to boot a Model A via RISC OS.

The USB Descriptors are as below:

Device Descriptor:
bcdUSB:             0x0110
bDeviceClass:         0x00
bDeviceSubClass:      0x00
bDeviceProtocol:      0x00
bMaxPacketSize0:      0x40 (64)
idVendor:           0x0A5C (Broadcom Corp.)
idProduct:          0x2763
bcdDevice:          0x0000
iManufacturer:        0x01
0x0409: "Broadcom"
iProduct:             0x02
0x0409: "BCM2708 Boot"
iSerialNumber:        0x00
bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected

Current Config Value: 0×00

Device Bus Speed:     Full

Device Address:       0×04

Open Pipes:              0
Configuration Descriptor:

wTotalLength:       0×0020

bNumInterfaces:       0×01

bConfigurationValue:  0×01

iConfiguration:       0×00

bmAttributes:         0xC0 (Bus Powered Self Powered )

MaxPower:             0×32 (100 Ma)
Interface Descriptor:

bInterfaceNumber:     0×00

bAlternateSetting:    0×00

bNumEndpoints:        0×02

bInterfaceClass:      0xFF

bInterfaceSubClass:   0×00

bInterfaceProtocol:   0×00

iInterface:           0×00
Endpoint Descriptor:

bEndpointAddress:     0×01  OUT

Transfer Type:        Bulk

wMaxPacketSize:     0×0040 (64)

bInterval:            0×00
Endpoint Descriptor:

bEndpointAddress:     0×82  IN

Transfer Type:        Bulk

wMaxPacketSize:     0×0040 (64)

bInterval:            0×00

I assume you’ve got it plugged in via a powered hub? Although it claims it only draws 100mA and is self-powered I doubt that’s the case.

If using a hub doesn’t fix it, you’ll probably have to resort to using a debug build of the USB modules to find out what’s going wrong.

I’d got the Model A powered in the usual way, via the microUSB socket, using a 4A PSU! Oh, and it’s 18s that RISC OS is unresponsive for, not 7s as previously stated.

If there’s a debug version of the USB modules you could point me towards (and some idiot-proof instructions), I’ll have a play when I’m back after Easter. Thanks.

I’d got the Model A powered in the usual way, via the microUSB socket, using a 4A PSU!

Ah, I’d assumed that the microUSB would be being used for both power and programming. But I guess it makes sense for them to use the USB A socket instead.

If there’s a debug version of the USB modules you could point me towards (and some idiot-proof instructions), I’ll have a play when I’m back after Easter. Thanks.

Sure, I can upload a build of the modules (or possibly just a full ROM) for you.

Ah, I’d assumed that the microUSB would be being used for both power and programming. But I guess it makes sense for them to use the USB A socket instead.

The microUSB data lines aren’t connected, it’s only ever used for power!

Sure, I can upload a build of the modules (or possibly just a full ROM) for you.

Great, thanks.

Over here is a debug build of the USB modules for the Pi. Try doing the following:

• Make sure the modules are saved to your SD card! Softloading USB modules from a USB stick doesn’t work too well :)
• Run DADebug first, USBDriver and DWCDriver second
• Open a taskwindow and enter the following, to set a ‘moderate’ level of debug output:

*usbdebug 10 10
*dwcdebug 11 0

• Now enter *dadreset to clear the log buffer, and connect the model A Pi
• Once the OS recovers, enter the following to reduce logging to a minimum, and to dump the log:

*usbdebug 0 0
*dwcdebug 0 0
*dadprint

For the *dadprint you might want to send the output straight to a file, e.g. *dadprint { > $.foo }, as it’s often quicker than waiting for the tons of text to finish scrolling by. Once you have the log, email it to me and I’ll see if I can spot anything obvious that’s causing the problem.

Thanks Jeffrey, I’ll be home again tomorrow so will give it a go soon. What’s your email address?

me at phlamethrower dot co dot uk

Thanks!

Debug info emailed.