ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5717
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

USB Boot

Mon Apr 07, 2014 8:09 pm

The schematic implies that the board will boot from USB. Is this from USB Mass Storage, or from a USB host? In either case, will this extend to the Model A? I know that the Model A can boot from a USB host, but this hasn't been documented.

Edit: Just noticed a comment from James Adams saying it's booting from a USB host the same way the Model A can. So then the code to do that will be released and Model A owners and Model B owners willing to mod the hardware a little will be able to do that as well?

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1416
Joined: Sat Sep 10, 2011 11:43 am

Re: USB Boot

Tue Apr 08, 2014 6:06 am

Clone

https://github.com/raspberrypi/tools.git

go into usbboot and type make (you'll need libusb readme describes how to build). You can do all this on a model B Pi.

Then plug a model A into the model B and (with an unprogrammed SD card plugged into the A) it will turn into a mass storage

Then you can plug it into a PC or just image it directly
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

shuckle
Posts: 565
Joined: Sun Aug 26, 2012 11:49 am
Location: Finland

Re: USB Boot

Tue Apr 08, 2014 6:54 am

Thank you very. much. Very usefull.

simplesi
Posts: 2327
Joined: Fri Feb 24, 2012 6:19 pm
Location: Euxton, Lancashire, UK
Contact: Website

Re: USB Boot

Tue Apr 08, 2014 7:11 am

Can the above be translated into something us lesser mortals can understand please :)

It looks very interesting ref Model A and USB connectivity but I didn't understand the sequence/end result :(

Simon
Seeking help with Scratch and I/O stuff for Primary age children
http://cymplecy.wordpress.com/ @cymplecy on twitter

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2011
Joined: Thu Jul 11, 2013 2:37 pm

Re: USB Boot

Tue Apr 08, 2014 8:20 am

You can install the 1st stage bootloader using USB. This effectively loads a modified bootcode.bin (msd.bin).

The protocol for this is simple as it is ROM-driven. It simply uses a control endpoint and a bulk endpoint: you tell the control endpoint how much data you are sending and then you send the data in the bulk endpoint.

To load stuff onto the eMMC, the msd.bin does the job of USB Mass-Storage Device. This makes the entire flash appear as a USB MSD which you can read/write to.

In theory this will also work on a Model A as I believe they both have the OTP bits set for USB boot, but you have to boot without a formatted SD card in it first.
Rockets are loud.
https://astro-pi.org

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5717
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: USB Boot

Tue Apr 08, 2014 2:00 pm

Excellent, thanks! :D

Edit: Amazing how little code that takes, but I suppose the fun stuff is in the .bin.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1416
Joined: Sat Sep 10, 2011 11:43 am

Re: USB Boot

Tue Apr 08, 2014 2:57 pm

Yes it took me about a week to write the 'fun' stuff, which includes a USB state machine to handle the device mode communication. Unfortunately I never had a Mac to test it on so it turns out it won't boot on there, sorry... I can only blame SPL who wouldn't let me test it on the company Mac!

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: USB Boot

Tue Apr 08, 2014 3:06 pm

So the model A (power USB in) has a data connection (B does not), and when the SD has no .bin, it checks the USB master for boot information?

I suppose the best thing that this would allow from my prospective is not to need extra SD cards to run a second Pi. I wonder if a remote boot loader will be released, which not only presents the remote SD for writing (one hopes even an empty slot is possible), but also mounts the master model B drive as a chain boot source, and any model B USB sticks as network root file systems.

Yes, maybe it's true that the model B's file system would not like two writers, but is that not just a different user account is needed to eliminate most conflicts of access? It's just having one master SD and USB rootfs stick for a whole server farm would be useful. Can the model A be plugged via a hub? A remote of the eth0 (and wlan0 too) would also be very, very nice.

Just needs one keyboard mouse combi per model A, and perhaps a remote quarter desktop on the B for each of the four As to make a 4 in 1 family system. :D

Asking too much? :D
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

User avatar
rpdom
Posts: 14483
Joined: Sun May 06, 2012 5:17 am
Location: Chelmsford, Essex, UK

Re: USB Boot

Tue Apr 08, 2014 3:35 pm

jackokring wrote:So the model A (power USB in) has a data connection (B does not)...?
No. The model A and model B Pi boards are identical. There is no data connection to the Power In USB on either of them.

The single USB port on the model A is capable of working as a USB slave (OTG mode). The model B cannot do that because of the USB hub/LAN chip being in the way.

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: USB Boot

Tue Apr 08, 2014 4:01 pm

rpdom wrote:
jackokring wrote:So the model A (power USB in) has a data connection (B does not)...?
No. The model A and model B Pi boards are identical. There is no data connection to the Power In USB on either of them.

The single USB port on the model A is capable of working as a USB slave (OTG mode). The model B cannot do that because of the USB hub/LAN chip being in the way.
OK. So still useful as a concept, but any multiple keyboard stuff must be connected to the model B. Not too much of a limit. Nice.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5717
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: USB Boot

Tue Apr 08, 2014 4:17 pm

jackokring wrote:So the model A (power USB in) has a data connection (B does not), and when the SD has no .bin, it checks the USB master for boot information?
Note that this is not the micro-usb port, but the actual usb port you would normally connect a device to, so the issue isn't to do with data connections. As I understand it, the only issue is that the Model B has the USB HUB + NIC chip in the way, which works in host mode. The model A, on the other hand, has the SoC's USB lines going straight to the USB port. If you look closely at a Model B under the USB ports (on the other side of the board), you should see that r36 an r37 are missing. If you short those (not to each other), you will connect one of the usb ports straight to the SoC's D+/D- lines. However, it would also be connected to the LAN chip, which may cause issues, so it might be a good idea to remove it altogether. But then you would just end up with a more expensive model A with 512MB RAM.
jackokring wrote: I suppose the best thing that this would allow from my prospective is not to need extra SD cards to run a second Pi. I wonder if a remote boot loader will be released, which not only presents the remote SD for writing (one hopes even an empty slot is possible), but also mounts the master model B drive as a chain boot source, and any model B USB sticks as network root file systems.

Yes, maybe it's true that the model B's file system would not like two writers, but is that not just a different user account is needed to eliminate most conflicts of access? It's just having one master SD and USB rootfs stick for a whole server farm would be useful. Can the model A be plugged via a hub? A remote of the eth0 (and wlan0 too) would also be very, very nice.

Just needs one keyboard mouse combi per model A, and perhaps a remote quarter desktop on the B for each of the four As to make a 4 in 1 family system. :D

Asking too much? :D
I don't know how this works 100%, so maybe jdb or gsh can correct me.

The SoC has some boot code burned in which initializes the SD card, reads the fat32 partition and fires up bootcode.bin, which takes over. As we found out a while back, if bootcode.bin is not found, the pi also tries to get the firmware from a USB host. The released code shows how to send a .bin file over USB for the pi to boot from. These .bin files run on the GPU, not the CPU, so they're very tricky. Eben and Gordon have mentioned the possibility of releasing an open bootcode.bin and start.elf, but it's unclear when that might happen and what they would be capable of. If it happens, it opens up the possibility for all kinds of fancy bootloaders. There aren't many people who can work with the GPU and the ones that can also have full time jobs and other interests, so even with fully open firmware, there's no guarantee that much will come out of it.

What you would want is something like the current firmware, but with the ability to load kernel.img over USB as well. I suspect the current firmware is already capable of that, but I don't know.

If you can load the kernel, then the rest if a lot simpler. You can specify an NFS root and the rest will depend on what the server farm actually does. I would forget about actually sharing a single rootfs 'as is'. It should be read-only with a way to handle local changes some other way (separate NFS mount points, aufs, tmpfs, and so on). 'Back in the day' the whole point of /usr was to share it over the network across multiple machines (and /usr/local for the local stuff).

I have no idea if this can be done with multiple pis over a hub. I am not familiar with USB overall yet.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1416
Joined: Sat Sep 10, 2011 11:43 am

Re: USB Boot

Tue Apr 08, 2014 5:32 pm

Yeah that's actually quite a lot of work to get the linux to boot with no SDCard at all, plus there's nowhere to get the filesystem from when you boot linux (mass storage devices don't work 'the other way round') so it would only work with a buildroot or something similar.

Overall there's no real point to doing it unless we find a big customer with this specific use case (i.e. think 500K compute modules)

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

User avatar
jackokring
Posts: 816
Joined: Tue Jul 31, 2012 8:27 am
Location: London, UK
Contact: ICQ

Re: USB Boot

Tue Apr 08, 2014 9:22 pm

The no SD is just a minor cost save possibilities. The more real idea is having one SD with the master firmware and kernel revision on. So assuming say each model A has an 8GB card, then it's just a matter of not putting a bootcode.bin on, fetching that from the model B, booting the kernel off the model A SD, performing a networked copy of /boot from the model B to any model A except the .bin, and forcing reboot if any files were different. And the minor point of keeping the model A in slave USB mode. Given that the linux kernel is then running on both (or more) devices, how easy would it be for the model A to have virtual devices using the real model B device in a kind of masquerade proxy?

Is this then just a kernel driver issue, with an insmod based on the existence of /boot/bincode.bin? This is the last post on this topic by me, to edificate and clarify the nature of the booty

EDIT: If it's so then software controlled reboot from the msd.bin is the only extra requested feature.
Pi[NFA]=B256R0USB CL4SD8GB Raspbian Stock.
Pi[Work]=A+256 CL4SD8GB Raspbian Stock.
My favourite constant 1.65056745028

blamarpa
Posts: 454
Joined: Thu May 23, 2013 4:02 pm
Location: España

Re: USB Boot

Mon Apr 28, 2014 11:01 am

May be a easy mode to format/prepare the eMMC in the new compute module but more interesting in a slave device conected to a pc as a external display adapter, external media player, external h264 cámera, external ..... any think you can build, only having to integrate in the board a bcm2835 and it's memory, no needed eMMC.

I can imagine a raspberrypi host whith his disk acting as a iscsi tarjet, with ip over usb, and as raspberrypi booter thru usb, and 16 slaves (raspberrypis) booting first from usb and latte mounting his iscsi disk (like berryboot) to work as a cheap cluster, web hosting, multi screen wall, multi camera in a vehicle or traffic control point, multi video encoder-decoder, multiuser/net/classroom in a box, been able to bring them on or off individually or anything you can imagine with minimal electronics and costs.

so, is it possible to send, not only the code for the gpu, also a minifs for the arm and a start_arm signal?

plugwash
Forum Moderator
Forum Moderator
Posts: 3418
Joined: Wed Dec 28, 2011 11:45 pm

Re: USB Boot

Tue Apr 29, 2014 12:21 am

gsh wrote:Yeah that's actually quite a lot of work to get the linux to boot with no SDCard at all, plus there's nowhere to get the filesystem from when you boot linux (mass storage devices don't work 'the other way round') so it would only work with a buildroot or something similar.
In principle I guess you could use G_ETHER with a NFS root.

Of course that would mean needing someone to work on tying the Pi's USB driver into the linux gadget driver stack.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1416
Joined: Sat Sep 10, 2011 11:43 am

Re: USB Boot

Tue Apr 29, 2014 5:20 am

I was told that it had been tested and works fine...

I've never tried it myself although the device interface is very much simpler (and far less buggy) than the host one

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

mikerr
Posts: 2768
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: USB Boot

Fri May 02, 2014 10:16 am

For USB boot:

a) Model A still needs an SD card inserted (though unformatted) ?
- would just a missing bootcode.bin cause it to try usb boot ?

b) Boot up is ONLY to use the SD card/mmc as mass storage from the remote USB host,
NOT able to use any features of the GPIO / HDMI/ CPU/ Video etc

c) Is there any way to reboot the slave from the host, after the SD/mmc has been written ?
Android app - Raspi Card Imager - download and image SD cards - No PC required !

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5717
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: USB Boot

Fri May 02, 2014 10:35 am

mikerr wrote: b) Boot up is ONLY to use the SD card/mmc as mass storage from the remote USB host,
NOT able to use any features of the GPIO / HDMI/ CPU/ Video etc
It can be used for arbitary GPU kernels as well. Instead of loading the mass storage binary, any custom bootcode.bin-type file can be uploaded. Although the possibilities are limited right now, there's a lot of potential there.

jdb
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2011
Joined: Thu Jul 11, 2013 2:37 pm

Re: USB Boot

Fri May 02, 2014 10:45 am

As an example, if you loaded a different "msd.bin", you could turn the Compute Module into a ridiculously overpowered GPIO expander. The interface presented would just be a generic HID that lets you set/clear pins or send/receive I2C commands.

It would be a silly use of a multimedia SoC, but a demonstration of what you can load instead of USB mass storage.
Rockets are loud.
https://astro-pi.org

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1416
Joined: Sat Sep 10, 2011 11:43 am

Re: USB Boot

Fri May 02, 2014 10:46 am

mikerr wrote:For USB boot:
a) Model A still needs an SD card inserted (though unformatted) ?
- would just a missing bootcode.bin cause it to try usb boot ?
Yes if it cannot find or load bootcode.bin it will fall back to USB boot. For the compute module (where the eMMC device is not removable) we have actually provided a mechanism to break the SD communication so that you can do this (otherwise you could 'brick' the compute module!)
mikerr wrote: b) Boot up is ONLY to use the SD card/mmc as mass storage from the remote USB host,
NOT able to use any features of the GPIO / HDMI/ CPU/ Video etc
No the usbbootcode.bin just does MSD it doesn't even turn on the ARM!
mikerr wrote: c) Is there any way to reboot the slave from the host, after the SD/mmc has been written ?
[/quote]

No... I like the idea but It's quite hard to do, how would you communicate with the MSD over SCSI ?
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

mikerr
Posts: 2768
Joined: Thu Jan 12, 2012 12:46 pm
Location: UK
Contact: Website

Re: USB Boot

Tue May 06, 2014 4:22 pm

gsh wrote:
mikerr wrote: c) Is there any way to reboot the slave from the host, after the SD/mmc has been written ?
No... I like the idea but It's quite hard to do, how would you communicate with the MSD over SCSI ?
Well a (hackish) solution would be a "magic file" Create the file "rebootme" on the MSD and the GPU resets.

I was thinking of using the USB boot/MSD for imaging, then after that magic reboot,
the bootcode.bin is found on the SD/MMC and it boots normally.

That would make a nice self-initialising array of pi or modules
Android app - Raspi Card Imager - download and image SD cards - No PC required !

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1416
Joined: Sat Sep 10, 2011 11:43 am

Re: USB Boot

Tue May 06, 2014 5:44 pm

So, that would be a driver running on the VPU (the thing that actually runs the mass storage code) understanding what it is you are writing to the blocks on the disk (the SCSI interface is literally write block X, read block X so you have no idea where the FAT is, etc etc.

You'd have to work out what the operating system is trying to do as you go along!

I might have a look sometime, but if you want a rack of Pi's re-writing cards, I'd suggest having another Pi controlling the reset signals!

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

fanoush
Posts: 454
Joined: Mon Feb 27, 2012 2:37 pm

Re: USB Boot

Tue May 06, 2014 8:13 pm

gsh wrote:
mikerr wrote: c) Is there any way to reboot the slave from the host, after the SD/mmc has been written ?
No... I like the idea but It's quite hard to do, how would you communicate with the MSD over SCSI ?
You could map reboot to eject command that cd-roms and usb card readers support?

blamarpa
Posts: 454
Joined: Thu May 23, 2013 4:02 pm
Location: España

Re: USB Boot

Tue May 06, 2014 9:57 pm

fanoush wrote:
gsh wrote:
mikerr wrote: c) Is there any way to reboot the slave from the host, after the SD/mmc has been written ?
No... I like the idea but It's quite hard to do, how would you communicate with the MSD over SCSI ?
You could map reboot to eject command that cd-roms and usb card readers support?
Hy, it can be done if the 5 volts of yours "slave" model A or C.M. pis are managed from the "master" gpio using, in example, a cheap ULN2803 (up to 500 mA and 8 outputs) so when you finish saving the new image in the "slave" pi, a power down and up can be done. Also can save energy disabling unneeded nodes.
Now, an image with the _pi's usb in slave mode (OTG), Ethernet over USB enabled (http://www.raspberrypi.org/forums/viewt ... 44&t=45344) and nfs mount could be done. Only a usb cord is needed to feed and comunícate with each slave and, of course a good USB hub and power supply.
what do you think?

Dutch_Master
Posts: 360
Joined: Sat Jul 27, 2013 11:36 am

Re: USB Boot

Tue May 06, 2014 10:14 pm

There's an important flaw in your design: the ULN28xx series have a common ground, not power rail. That means that you can't use it to control power to an RPi. Mind, the extra transistor will lower the voltage by ca 0.7V, and result in unstable power conditions. You may try a MOSFET in the power rail, but that again introduces a voltage drop that you'd need to compensate for from a separate power supply.

Return to “Compute Module”