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.
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.
Asking too much?
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.