Using usbboot to boot, format microSD, and replicate one PiZero to another

[hh]

Can we make viral software that replicates with $5 hardware?

Let's make it it easy for people starting out and without dependency on internet or other hardware to replicate / flash PiZero's using only PiZeros?

[SDCARD][RPI_SRC] <==usb otg cable ==><==usb micro==>[RPI_TARTGET][BLANKSDCARD]

The target rpi would start with an unformatted or emtpy microSD card.
Using usbboot on the source rpi we could boot a kernel + rootfs on the target rpi, that would let the target device show up as a mass_storage gadget exporting the blank microSD card.

We could format the target rpi with whatever we needed to at that point, preferably with the ability to do what we just accomplished to yet another target rpi.

/cc @lurch

[hh]

In trying to start from source, does anyone know where these binaries come from:

    cp usbbootcode.bin /usr/share/rpiboot
    cp msd.elf /usr/share/rpiboot
    cp buildroot.elf /usr/share/rpiboot

https://github.com/raspberrypi/tools/blob/master/usbboot/usbbootcode.bin
https://github.com/raspberrypi/tools/blob/master/usbboot/msd.elf
https://github.com/raspberrypi/tools/blob/master/usbboot/buildroot.elf

I can't quite tell if they all come from buildroot.patch or somewhere else.

[hh]

I think this may be of interest to some of the folks who worked on getting usb gadget support up in the first place: /CC #1212

[P33M]

Is this a bug report?

[lurch]

It's quite a while since I last played with this - the person to ask would obviously be @ghollingworth

I think that usbbootcode.bin is analogous to bootcode.bin from https://github.com/raspberrypi/firmware/tree/master/boot , and msd.elf and buildroot.elf are then analogous to start.elf from that same firmware directory. I.e. these are all closed-source low-level binaries that run on the GPU itself, and so can only be made by Raspberry Pi engineers.

Given that it's not recommended to try DD-ing from a mounted filesystem, I guess for one RPi-Zero to be able to write a complete OS to another RPi-Zero containing a blank SD card, the booted RPi-Zero would need to have a copy of the raspbian.img on it's filesystem. So for that img file to then be self-replicating, is an interesting chicken-and-egg problem... ;-) (I'm sure it's probably possible, I'm just too tired to think about it right now)

[hh]

@lurch I wouldn't dd directly, I'd suggest formatting the disk / partitons, mounting them,, then cp -a or equivalent from the source to the target. :)

@P33M This is more for discussion not a bug report. Using github allows mentioning and including the people directly responsible for different portions of the raspberry pi source in a way that is less integrated than a mailing list. Can you use a different github issue label for this so it's not looked at as a bug report or should I try and move this elsewhere?

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=53007 has the final discussion on the binary bootloader matters. I didn't realize the internal hardware / software dependencies. No biggy.

[P33M]

I'd suggest requesting the feature on the forums. That way you can
a) get a wider audience of people that may be interested in the feature
b) get feedback that modifies the original idea

which then feeds into specific feature requests. We get notified of open issues anyway so pinging us doesn't add much to the discussion. if there's a specific requirement for feature Z then with requirements identified you can put the requests in the right place, e.g. firmware or NOOBS. As it stands, this request doesn't require any Linux-specific changes.

[hh]

Closing for now, will update with a link to a forum post for further discussion.

[t3chguy]

@hh, have you got a forum thread up on this? Interests me.