On Wed, Feb 27, 2013 at 11:24:06AM -0600, Bill Gatliff wrote: > My vote would go in the exact opposite direction: the board has to > boot from NAND (or eMMC), and then step over to SATA if present. > Among other things, that makes it realistic that a new developer boots > it by merely plugging in the USB cable for the serial console.
uboot on microSD has the advantage that it is impossible to brick the board. kernel and ramdisk can certainly be on sata no problem. > And don't go all u-boot on me, either, except as a quick jump to a > Linux kernel+initramfs that most developers will see as the real > "bootloader". That lets you use usb-storage to manage the NAND > partitions, SATA if connected, SSH/telnet to the "bootloader", and so > on. And then kexec to the developer's kernel if they provide their > own. And manpages for same. I actually think uboot is a very nice bootloader and would hate to see anything like the garbage the netwinder had where a stripped down kernel was used to kexec the real kernel. That was a nighmare to deal with. MILO on certain alpha systems was similar and equally terrible to deal with. > That way, all the bad parts of u-boot et. al never see the light of > day. As it should be. :-) > > Viola! Much easier to work with than a lot of existing hardware, and > darned unlikely to brick as well. > > Disclaimer: the above describes how I do my boards. Get me one of > these, and I'll show you. I also make pretty extensive use of > multistrap et. al from the embedded Debian project, to keep the target > filesystem AND developer tools in sync. > > This isn't me self-promoting (ok, not much). Rather, Debian is just > MADE to make this stuff awesome. I'm merely a lowly user thereof. Well a standard firmware that initialized hardware and then calls a dedicated bootloader like grub that resides on sata is certainly very convinient and I wish arm boards would start doing something like that. I am not sure they will ever get taken seriously in the server market if they don't. openfirmware seems to do that nicely on powerpc and sparc systems (and I believe some mips systems too). No reason arm couldn't do that too (and of course switch to devicetree for passing info about the system to the kernel at the same time). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130227182931.gl20...@csclub.uwaterloo.ca
