Re: iMX6 EOMA-68 CPU Card
Lennart:
On Wed, Feb 27, 2013 at 12:54 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> 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.
Reply to: