Re: Using Linux as a boot loader -- status and RFH
On Sun, Jan 30, 2011 at 4:39 PM, Eric Cooper <ecc@cmu.edu> wrote:
> I've been experimenting with using a stripped-down Linux kernel
> instead of u-boot. I'm working with a Seagate DockStar, but the same
> approach should work with the Sheevaplug or other variants. The idea
> (which is not original -- you can find several other similar projects
> via Google) is to use the power of the Linux networking, filesystem,
> and USB stacks to load whatever kernel you want, and then the kexec
> system call to warm-boot into it.
>
> Unfortunately, I've hit a brick wall: after loading a kernel (via
> "kexec -l ...") and executing it ("kexec -e"), the new kernel hangs
> during initialization when it tries to access various hardware
> registers. These same hardware registers are accessed when the kernel
> is booted via u-boot, so there's some bug here I haven't been able to
> track down.
this reminds me of what it was necessary to do when utilising HARET 4
years ago to boot into linux. HARET (and gnuharet) is a WINCE
application that is the ARM equivalent of LOADLIN.EXE (remember that?
DOS / Win95 linux booter?)
the problem that you're running into is probably identical to the
problem that HARET solves. HARET doesn't just "run a random kernel",
it actually shuts down all the prior OS'es bits and pieces. DMA
operations, low-level interrupt handlers etc. etc.
in other words, you _can't_ just "run a random kernel", because when
you start up a kernel "from scratch", the machine state is assumed to
be from "cold boot". i.e. no ongoing DMA, no non-maskable interrupts,
no watchdog timers, nothing.
you'll probably find that the linux kernel has, as part of its
initialisation, changed the address of some very low-level IRQ handler
before it gets started up in the next few instructions, but, duhh,
that interrupt routine hasn't been initialised yet but it's called
BECAUSE that's what the previous OS wants to happen, asked to happen
and has set up to happen.
u-boot isn't just there for "no good reason", and the experimentation
you're doing is basically to re-learn and to re-invent absolutely all
of that low-level expertise. which is fine if that's what you want to
do, but... i am... how can i say this best... ok, i got it. "with the
greatest respect to your curiosity and desire to experiment, can i
advise you to consider being curious and experimental in *some other*
area that will actually be of benefit and advancement to free
software, rather than a rather specialist area called u-boot"?
now that may sound strange or perhaps you might even consider it to
be patronising (for which i can only apologise but really don't care
one way or the other), but you have to bear in mind that u-boot's
device driver code *is* the linux kernel source code, literally
cut/paste in most cases. so you are in danger of cutting up (or
cutting down) the linux kernel in order to create yet another u-boot,
because there's no way in hell that, except *at* kernel level, you're
going to be able to shut down all DMA, NMIs, watchdog timers and also
shut down all virtual memory addressing, in order to get what you want
done, done.
remember that gnuharet gets away with booting up linux so easily (and
it doesn't work every time) because wince is not actually an OS, it's
a "program runner". everything's global access.
l.
Reply to: