Re: iMX6 EOMA-68 CPU Card
Lennart:
On Thu, Feb 28, 2013 at 9:14 AM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
>
> That bit would be tricky unless you had a part of your storage that was
> never written to that contained the code to boot when nothing else worked.
At some point, that's essential. And since you can't change it, you
want the LOC for that part to be as small as possible so that you
reduce your exposure to defects. That means stripping out everything
you can live without.
A brain-dead simple u-boot is just fine here, since in the nominal
case all it needs to do is pull a kernel+initramfs into memory from a
predictable location. That kernel+initramfs is also unlikely to
change, at least in my case, because I almost always have enough
storage to keep the customer's own kernel and rootfs elsewhere. When
I find that (detected by a /boot/zImage in the customer filesystem,
for example) I kexec to it.
So the customer "updates the kernel" in the device via an ordinary
package installation, just like a workstation. But unlike a
workstation, the customer doesn't have to worry about really screwing
up the system because their kernel isn't the one responsible for
initially bringing the core platform to life.
On the other hand, I don't have to worry about bringing a kernel that
can do EVERYTHING the customer wants it to do, because I know that
they can just supplement the system with their own kernel once they
decide to do so. The job for my kernel+initramfs is, in most cases,
to provide a bare minimum of functionality that either gets me to
their kernel, or allows the platform to "phone home" to restore the
user's filesystem if necessary. (Kind of like what the recovery
partition does on an Android device, but implemented differently).
But if things go really bad, and that kernel+initramfs is somehow
lost, then it's ok to be much more restrictive about the recovery
process since it's a much less likely event. I'll do a board swap,
tftp, or something similar.
> There is no need to do things 500 different ways. Maybe 10 or 20
> different ways is sufficient (certainly 1 way is likely to be too
> restrictive).
Agreed. But to be clear, I think what you and I are defining as
"different ways" may in fact be different.
You and I both run Debian workstations, and both behave in generally
the same way even though we both probably have significant differences
in e.g. how our networks are set up. And yet we can still manage both
machines with the same packaging concepts and sysadmin procedures.
Thus, from one perspective our machines are identical: the underlying
framework. But we use are using that identical framework to achieve
different work products, which is precisely what the framework was
designed to allow.
I have found that the Debian Way is pretty much the One True Way for
dealing robustly with a shockingly wide range of use cases, both yours
and mine. I'm just saying that rather than crowding it out by making
larger and more functional bootloaders, we should consider going the
opposite direction: "debianizing" more and more of what we now think
of as the bootloader concept, and marginalizing our true bootloaders
farther and farther into the background where they came from.
The Debian installer is another instance of what I'm talking about: it
sits above the hardware, and does intelligent things. Then it hands
control over to the filesystem after it decides everything is ready to
go. In fact, it was kind of my inspiration.
> Diversity does not mean sprawl is required.
Correct. Debian is proof of that. Your workstation, compared to
mine, is proof of that. As are all the devices I have here that are
running Debian-like configurations, none of which look or act like
workstations at all.
(The one downside? They all look so similar here that I have to be
very careful when I issue a reboot command over SSH. Whoops, wrong
target!)
> I really hope the ARM servers can do something sane so that they have
> a common interface for installation and booting. If they don't I doubt
> they will ever be taken seriously. That would be a shame.
I agree! But "server" is just one use case, and ARM is a broadly
applicable family of SoCs that does wayyyyy more than server
workloads. If we are smart about it, we can accommodate a lot of
those use cases within a consistent, flexible, and sane framework.
Some of us already are.
The n2100/n4100 devices are a perfect example of a server-like device
that was almost perfectly-executed from a Debian perspective. The
only flaw, in my opinion, is that the startup sequence depends on
having just one kernel in the system, and that kernel has to live in
flash. If that kernel+initramfs instead just did a kexec+pivot_root
over to whatever it found on disk, I could put my serial cables away
forever.
Martin Michlmayr is really, really good. But I think he has as little
time as I do for these kinds of things!
Does anyone else smell dead horse? :-)
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Reply to: