Re: iMX6 EOMA-68 CPU Card (or rather arguing over what a boot loader should do)
On Thu, Feb 28, 2013 at 1:03 PM, Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
>
> u-boot began as a mind-f**k merge of parts of uclibc (or equivalent),
> some userspace code and the linux kernel.
Awww. That's about the nicest thing I've heard anyone say about
u-boot in a long time. :-)
(I don't hate u-boot, I just hate the monster people are always trying
to turn it into).
> the problem lennart is that in order to do enough "bring-up" to do
> the kinds of tasks that you're expecting to do - such as initialise a
> screen, a usb, a serial, an sd/mmc, a this, a that - you actually need
> to do *exactly* the same job that the linux kernel already does.
Precisely!
> [except that there happens to be in some devices some additional
> low-level initialisation such as "bring up the DDR3 RAM interface and
> tell it to switch on and to use 8 banks of 4 @ a clock rate of 400mhz"
> and so on, but those kinds of things aren't that hard to add to the
> linux kernel early initialisation phase...]
I'm not insisting that we have to bring all this stuff into Linux too.
In fact, keeping some of these details hidden away inside a true
bootloader is often a good idea because some low-level hardware
details Linux just doesn't care about, or they have to be addressed
before the hardware can deal with the large memory footprint that
Linux requires. In such cases it's essential that you pass the
hardware identifier and bootloader version strings forward in the
kernel command line, so that the kernel and userspace gain visibility
to those details should they need them (and mine always seem to at
some point).
> using kexec actually allows you to write a boot-up application in
> userspace, and test it in userspace.
... and deploy it in userspace, in the form of a kernel+initramfs. In
essence, it becomes what the end user sees as "the bootloader".
b.g.
--
Bill Gatliff
bgat@billgatliff.com
Reply to: