Lennart: On Wed, Feb 27, 2013 at 12:54 PM, Lennart Sorensen <[email protected]> wrote: > > What you are doing is to me a terrible idea that I hate and have always > hated. I hated it on the netwinder in the late 90s, I hated it on the > alpha in the form of MILO. They were always getting out of date and > would be unable to boot newer kernels and they were difficult if not > impossible to get the full source code for in many cases (A problem I > hope you are at least avoiding).
I think you and I might be solving different problems, hence your disagreement. And while I have a certain gut-level negative reaction to the notion of BIOS in all forms, I can see that in the cases you have mentioned it would genuinely be helpful. In my case, however, your approach is going completely in the wrong direction and I have a decade of personal experience with its implications to back that up. And I think that the majority (but by no means all) of ARM CPU adopters would find it counterproductive as well. I'm not saying you are fundamentally wrong, only that there is a very large part of your target audience that would find a different approach more helpful. Your suggestion is great for a platform that has a uniformity of installation use cases e.g. workstation-like, tablet-like, cell-phone-like, media-center-like devices. They are all variations on a few common themes, and within some limits a standardized base platform configuration is helpful to the application stack and vise versa. And both can be generalized to the point where a lot of the details just don't matter. The problem and solution have both been been well-framed, in other words. By the numbers, however, a substantial set of ARM users are delivering highly-differentiated devices where a cookie-cutter approach just won't work. My devices are in the control and/or data visualization paths for factory automation equipment, spacecraft, aircraft, trains, medical devices, earth-moving equipment, set-top boxes, and such (all true, by the way). There is no one-size-fits-all possibility, and there's no substitute for a system architecture that can be safely adapted---even in the extreme---to meet the fundamental requirements of the overall application: boot times well under a second, in some cases; layered, possibly concurrent operational modes; fallback operation for dealing with several different types of failures including watchdog timeouts in both software and hardware; and so on. What's super-cool about Debian is that if you use it well, it can be safely adapted---even in the extreme---to meet many of those use cases. But that possible only if you as much as you can inside the concepts of Debian, and as little as possible elsewhere. And that's why if you are going to make me use a BIOS, it's going to look like Linux+initramfs that eventually pivot-roots into Debian. You can deliver the platform already configured like that, or I will get out my JTAG adapter. Because I have learned through trial and error that eventually, something like u-boot or a BIOS will get in the way because it represents a chunk of code that and design decisions that I'm forbidden to adapt to my own needs in the moment. It becomes an all-or-nothing proposition, and I take the latter because I work at that level now. One other thing. If I have a Linux+initramfs with enough code to "phone home" and wget an initial filesystem image or the Debian installer, then I don't even need the JTAG adapter. I just tell the user in Nowheredistan to hook the thing to the internet, and hold down a button at boot. Then multistrap takes over from there. ... which is kinda cool even for a workstation or a media device. Which is why I end up back at making Linux+initramfs my BIOS for all ARM machines, even though I started this conversation by agreeing with you. I'm not making any of this up: it's how I do business. And again, I'm not saying your approach is objectively wrong. I'm just saying that nowadays, there are some really interesting alternatives once we break free of the traditional notion of "bootloader". I'm done now. :-) b.g. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/CADkCAuuYwRB57cOK35KpC1pMjvSsbL3Rr=2jbyasz9ov0em...@mail.gmail.com
