Re: iMX6 EOMA-68 CPU Card
Lennart:
On Wed, Feb 27, 2013 at 2:00 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> I really think that one way could work for all, including what you are
> doing.
Yes. For example, the approach I described. :-)
> 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.
It isn't always about speed per se, but it is always about flexibility
without fundamentally destabilizing the fundamentals of the system.
Consider what it would take to modify grub so that if it didn't find a
filesystem, after checking in several places, then it would phone home
over all available network connections in including any USB ethernet
adapters. And then consider how you would facilitate a new developer
changing that code without breaking it.
> 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.
Nah, don't drink the kool-aid. This diversity is good when the
alternative is locking us into a BIOS-like universe that says e.g.
Thou Shalt Frame Your Solution Like A Tablet Computer.
> 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.
I think the origins of Linus' tantrum lie in a misunderstanding of the
problems that ARM machines face (a point I made on LKML and LAK back
in the day). The solution isn't to demand that all problems must be
solved in the same way; rather, it's to bring an infrastructure that
isn't so brittle. You can't simplify the universe.
The "mess" you see in ARM isn't the problem, it's merely a symptom of
the problem.
Devicetree is a step in the right direction, but basically because it
brings two fundamentally different capabilities: you can describe the
device model in something that doesn't require kernel recompilation to
change, and you can describe the device model in something that you
can parse pre-kernel boot.
But I digress...
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Reply to: