Re: iMX6 EOMA-68 CPU Card (or rather arguing over what a boot loader should do)
On Thu, Feb 28, 2013 at 6:51 PM, Lennart Sorensen
<lsorense@csclub.uwaterloo.ca> wrote:
> 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.
u-boot began as a mind-f**k merge of parts of uclibc (or equivalent),
some userspace code and the linux kernel.
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.
[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...]
the *specific* problem that u-boot has, as has been illustrated by the
builds of u-boot distributed by default with the OpenRD Ultimate, is
that the people who "just grab a version of u-boot, any version of
u-boot", fail to provide the features which people expect to have,
such as "recognise the SD/MMC card properly" or in the case of OpenRD
Ultimate, "fail to recognise the eSATA interface properly".
yet, once booted, the linux kernel that is on them *does* properly
recognise the SD/MMC card and the eSATA interface.
so there is version discrepancy... because the maintainers of u-boot
fail to keep up-to-date their cut/pasted versions of the linux kernel
drivers that access specific hardware.
using kexec actually allows you to write a boot-up application in
userspace, and test it in userspace.
l.
Reply to: