Re: iMX6 EOMA-68 CPU Card
On Wed, Feb 27, 2013 at 01:32:18PM -0600, Bill Gatliff wrote:
> 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. :-)
I really think that one way could work for all, including what you are
doing. No one says that firmware has to be as slow as many PCs seem to
be able to make it. I remember my 486 hit grub in under 3 seconds from
power on. It can be done.
I do think that there are way too many different ways done on arm systems,
and most arm systems end up in a state of not being supported because
they are all different and the manufacturer often doesn't care once they
have shipped the product.
I would love to see ARM servers and desktops and such which are as simple
to install Debian on as any random PC, and I really hope the 64bit arm
servers that are starting to appear will push things in that direction.
I know for powerpc, the linux kernel made it quite clear that no new
powerpc system would be accepted if it didn't use devicetree (some of
the first IBM powerpc systems supported in linux did something messy
and very different and not scalable at all). ARM has managed to be
a mess for years now, with every system doing its own thing, which
certainly explains why Linus had a bit of a temper explosion over the
state of ARM last year.
--
Len Sorensen
Reply to: