Re: iMX6 EOMA-68 CPU Card (or rather arguing over what a boot loader should do)
On Thu, Feb 28, 2013 at 09:58:19AM -0600, Bill Gatliff wrote:
> 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.
For the systems I work with, uboot is in flash and the kernel and such
is on compact flash and uboot knows how to read ext2 and files from the
compact flash along with a boot config using similar syntax to grub.
Worst case, the user swaps out the compact flash card with another one.
Using a kernel as essentially a bootloader to me is the opposite of
your goal of making the lines of code less for your startup process.
You have made it huge by using a linux kernel for what should be a simple
boot loader problem.
> 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.
Well I think grub2 is a perfect example of what a boot loader should
aim to be. I doubt you agree.
> 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.
I prefer making things as similar as possible. It is less confusing,
makes it easier to make the installer work and less work to maintain.
Installing Debian on various arm systems is currently a mess because there
are so many different ways to do it, and the debian installer doesn't
handle most of them. As long as every arm system keeps insisting on
doing booting its own custom way, there is no hope of making it easy to
install Debian on any of these systems. I suppose some people might
consider that job security. I would rather see a problem like that
solved so I can become redundant for that task and go work on a new kind
of problem.
> 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!)
That happens to everyone at some point. :)
> 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.
That is terrible. I want the boot loader smart enough to get the boot
config, kernel and other files from the normal filesystem.
> 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? :-)
Perhaps.
--
Len Sorensen
Reply to: