3A+ usbboot/rpiboot

[burtyb]

Sadly it looks like the 3A+ is unable to support rpiboot by default (which the A+ did).

Are there any hardware modifications that can be made to enable it and if so could the rpiboot tool be updated with support?

[hippy]

The first question would be; is it (1) the 3A+ hardware not presenting itself as a USB bootable device or (2) rpiboot simply not recognising how the 3A+ presents itself ?

I have a gut feeling that the BCM2837B0-based 3A+ may present a different VID/PID and description than the BCM2835-based Zeroes and A+ does. If so it should just require a software change to rpiboot and possibly update of driver information.

What does dmesg / lsusb / Device Manager show when the 3A+ is plugged into a USB port ?

[burtyb]

The first question would be; is it (1) the 3A+ hardware not presenting itself as a USB bootable device or (2) rpiboot simply not recognising how the 3A+ presents itself ?

Sorry I should have made my post clearer it doesn't show up as a device at all which is why I asked if there was a hardware mod to enable it.

I've been advised on IRC it's "an unintended consequence of enabling USB boot OTP bit" so that explains why it doesn't just work.

[gsh]

No the problem is that we've enabled host booting on 3A+ without realising the problem this subsequently causes for device booting...

There are two bits in the OTP for the Raspberry Pi chip, one which enables device booting (i.e. using rpiboot so it comes up as a device) and a separate bit to enable host booting (the Pi is the host and it looks for a mass storage device, a LAN9514/5 or LAN7515 and boots from it.)

The first bit is enabled in all Raspberry Pis (and always has been), the second bit has only been available from Pi 3B onwards and was only enabled by default from 3B+.

The problem is what happens when you enable both bits, the OTG port cannot be both a host and a device at the same time, so instead it uses the OTG_ID pin on the BCM2835/6/7 to choose which mode to use. Unfortunately on the PI 3A+ the OTG pin is connected to ground such that it will default to host mode.

We're just thinking about whether we remove the program_usb_host_boot by default...

Gordon

[ShiftPlusOne]

enabling USB boot OTP bit

we've enabled host booting on 3A+

What's the difference?

[hippy]

I guess it's something the beta testers never tested

I would prefer to have device booting as per A+ even if it means users having to explicitly enable host booting for the 3A+. Perhaps there would be some way to tweak NOOBS, Raspi-Config or First Run scripting so life is made easier for those who want to enable host booting ?

[ejolson]

Unfortunately on the PI 3A+ the OTG pin is connected to ground such that it will default to host mode.

Is there anyway to cut that trace and switch to device mode?

[gsh]

No the connection is under the processor

[W. H. Heydt]

I would hazard a guess that both host booting and MSD booting will be used by relatively few people. Still, there is a sort of solution for anyone who wants a host boot Pi3 class device. That is: use a CM3L.

[ejolson]

I would hazard a guess that both host booting and MSD booting will be used by relatively few people. Still, there is a sort of solution for anyone who wants a host boot Pi3 class device. That is: use a CM3L.

Compared to the Pi 3B+ the 3A+ is already targeting a significantly smaller group of people. While there is a weight, size and cost advantage to removing the built-in hubs, for me and perhaps a not insignificant part of the Pi 3A+ market, being able to run the USB port in device mode is a distinguishing feature.

[gsh]

Depends what you mean, you can run the port in device mode fine, you just need to add mode=peripheral to the dwc3 line.

You just can't boot from USB in device mode... And as I sat we're thinking about changing that decision

Gordon

[fanoush]

If some next board revision happens would it make sense to bring the ID pin out so people could cut the trace or even connect it to full otg connector?

[rpdom]

If some next board revision happens would it make sense to bring the ID pin out so people could cut the trace or even connect it to full otg connector?

Changing the connector to a microUSB and bringing the ID connection out to that would work, but would mean a fairly expensive design change and mean people would need to use adaptors for standard USB connectors, the same as they do with the Zero.

[k-pi]

Unfortunately on the PI 3A+ the OTG pin is connected to ground such that it will default to host mode.

We're just thinking about whether we remove the program_usb_host_boot by default...

If this were to be the case, would we still be able to set the OTP bit to boot from USB on a 3A+.

(I've just bought one with the intention of USB booting it.)

[DougieLawson]

At the moment the USBboot OTP bit is set in the factory on the production boards.

[W. H. Heydt]

If some next board revision happens would it make sense to bring the ID pin out so people could cut the trace or even connect it to full otg connector?

Or go with the approach on the CMIO boards...use a jumper on the board.

[W. H. Heydt]

Unfortunately on the PI 3A+ the OTG pin is connected to ground such that it will default to host mode.

We're just thinking about whether we remove the program_usb_host_boot by default...

If this were to be the case, would we still be able to set the OTP bit to boot from USB on a 3A+.

(I've just bought one with the intention of USB booting it.)

It would make MSD booting work the same way as the Pi3B and Pi2Bv1.2. First boot it to set the bit, then shut it down, remove the SD card and connect the MSD with the OS on it.

[hippy]

If some next board revision happens would it make sense to bring the ID pin out so people could cut the trace or even connect it to full otg connector?

Or go with the approach on the CMIO boards...use a jumper on the board.

The almost zero-cost option would be the accessible three-pad trick, [0V]-[signal]-[V+] with the default bridged, allowing the user to easily cut that and solder-bridge as required.

Personally I would have done that on all Pi and the same on the USB bus signals to the USB/LAN chips, so signals separated and all Pi's could have been made A's if someone had desired that.

The engineers at the RPT are undoubtedly very good engineers, but there doesn't seem to be anyone whose job it is to spot opportunities for maximal flexibility at minimal cost. There's a few tricks they've missed in that respect. I suspect it's probably because it is an engineering team not a product team. That seems most evidenced in their failure to appreciate how popular the Zero was going to be.

[HawaiianPi]

Unfortunately on the PI 3A+ the OTG pin is connected to ground such that it will default to host mode.

Then shouldn't that allow USB booting?

Or did I misunderstand something here...

There are two bits in the OTP for the Raspberry Pi chip, one which enables device booting (i.e. using rpiboot so it comes up as a device) and a separate bit to enable host booting (the Pi is the host and it looks for a mass storage device, a LAN9514/5 or LAN7515 and boots from it.)

[Gavinmc42]

I love the USB boot mode on Zero's, it's become the major way I develop VC4 code.
It saves so much sd card wear.

Obviously the standard USB A type connector does not have the ID pin.
If it did boot as a device would 100-500ma be enough for 4 cores?
So it would need to be powered via the normal methods.

But a bunch of 3A+'s as USB devices to a 3B+, 20 x 64bit cores online
That would be fun to play with, rev 1.1 please?

[ejolson]

Then shouldn't that allow USB booting?

Or did I misunderstand something here...

I'm surprised the 3A+ didn't use a micro USB socket same as on the Zero and Zero W except with some protection against being back powered.

What was expected, can be done with previous A models but can't be done with the 3A+, is to connect it to another computer and load the kernel, driver blobs and an initial RAM disk using rpiboot. After booting, the Pi would then remain in device mode and communicate as a serial or Ethernet gadget with the host computer. This is how Arduino boards are programmed. It also turns out to be a convenient way to implement distributed processing in the context of robotics and embedded devices. My guess is that this is about half the market for the A models, but maybe someone is putting most of them inside of refrigerators instead.

[k-pi]

Perhaps it could be clearly stated as to which ways each model can be booted, so as to take any worries away from us not so technical users.

Personally, I like to USB boot, but on occasion, do want to use a mSDHC card, as it is still faster - perhaps, as & when we get USB3, we will have an alternative fast booting method.

[hippy]

Unfortunately on the PI 3A+ the OTG pin is connected to ground such that it will default to host mode.

Then shouldn't that allow USB booting?

Yes, and that's fine. It's device boot mode which is the issue. It's all a bit complicated.

There are two different USB modes -

Host mode - Where the Pi's USB is configured as a host which allows a Pi to read USB memory sticks, USB HDD, have hubs, keyboards, mice and other USB devices attached and used.

Device Mode - Where the Pi can be accessed as if it were itself a USB device, eg plugged into a USB socket on a PC or other Pi.

In addition there are two USB boot modes, where there is no need for an SD Card to be present on the Pi -

Host boot mode - Where the Pi can boot from a USB memory stick or USB HDD.

Device boot mode - Where the Pi appears as a USB device to the PC or other Pi and can have bootcode.bin and other files required to boot it injected into it from that PC or other Pi.

For the Zeroes it's all pretty clear-cut because that uses a micro-USB connector and behaves just like mobile phones do which we are familiar with. Insert an 'OTG cable' and that sets host mode, provides a USB-A socket which memory sticks, USB HDD, hubs, keyboards and mice can plug into. Use a 'charger data cable' and plug it into a PC or other Pi and that sets device mode, allows the Zero to be accessed as a USB device from the PC or Pi.

Don't fit an SD card to a Zero and it comes up in device boot mode, needs to be connected to a PC or other Pi with a 'charger data cable' and have code injected into it for it to do anything.

For the A, A+ and 3A+, it's more complicated because those have a standard USB-A socket, the OTG signalling pin to the SoC is tied to 0V, and are, by default, expected to be in host mode. They can potentially allow host boot mode from USB memory sticks etc without any SD Card fitted, but only the 3A+ actually provides for that.

The A, A+ and 3A+ can be set to device mode even though the OTG signalling pin is tied to 0V if booted from SD Card, an appropriate software configuration is used, and a suitable cable can be found to connect them to a PC or other Pi.

The A+ ( and I believe A but haven't confirmed ) will also enter device boot mode if it has no SD Card fitted so a PC or other Pi can push bootcode.bin to it.

The 3A+ can do the same, but having the 'host boot mode' OTP fuse set on the production line causes it to enter host boot mode and, AIUI, when that fails, it doesn't allow the 3A+ to enter device boot mode.

That's the TL:DR issue. Set the 'host boot mode' OTP bit and that prevents device boot mode. Don't set the OTP bit and it allows device boot mode but users then have to set it themselves to use host boot mode.

[hippy]

I'm surprised the 3A+ didn't use a micro USB socket same as on the Zero and Zero W except with some protection against being back powered.

I presume that was to make it a drop-in replacement for the A+.

I think that decision is right; it's an upgraded A+, not an upgraded Zero / Zero W.

It would be nice to have a similarly upgraded Zero / Zero W. Perhaps a 3A+ with micro-USB and OTG ID connected to that could be developed. We would have to accept that it would however also have $25 pricing.

[hippy]

But a bunch of 3A+'s as USB devices to a 3B+, 20 x 64bit cores online
That would be fun to play with, rev 1.1 please?

A USB connected cluster using 3A+'s rather than Zeroes is already possible but requires all 3A+'s to boot from their own SD Cards. It's only booting without SD Cards in the 3A+'s which is not currently available.