MLO and u-boot.bin distro agnostic?

pretty sure i know the answer to this, but are the MLO and
u-boot.bin images you flash to the SD card independent of the distro
you install on the rest of the card?

  i would think so, but i ask since, if you check this:

http://elinux.org/BeagleBoard#Binaries

that page links you to the angstrom distro page to grab copies of MLO
and u-boot.bin, perhaps leading a new reader to think that different
versions of those binaries are tied to specific distros.

  if they *are* distro-independent, it might be worth mentioning that
on that page so that there's no confusion.

rday

p.s. part of the presentation might involve discussing why you might
want to build your own MLO and u-boot.bin images from scratch, but i
think i'll leave that until later. i'm assuming that build process is
pretty straightforward.

Robert P. J. Day wrote:

  pretty sure i know the answer to this, but are the MLO and
u-boot.bin images you flash to the SD card independent of the distro
you install on the rest of the card?

  i would think so, but i ask since, if you check this:

Beagleboard:Main Page - eLinux.org

that page links you to the angstrom distro page to grab copies of MLO
and u-boot.bin, perhaps leading a new reader to think that different
versions of those binaries are tied to specific distros.

  if they *are* distro-independent, it might be worth mentioning that
on that page so that there's no confusion.

No, they are not distro dependent. It's just that angstrom most regularly build the binaries from recent sources. Yes, it would be nice to clarify this in above wiki. It's a wiki, so do you like to clarify this?

p.s. part of the presentation might involve discussing why you might
want to build your own MLO and u-boot.bin images from scratch, but i
think i'll leave that until later. i'm assuming that build process is
pretty straightforward.

Yes, it is.

http://elinux.org/BeagleBoard#U-Boot

Many thanks and best regards

Dirk

Actually the proper answer is: MLO and u-boot.bin are not distro-agnostic.
However. MLO and u-boot.bin *are* kernel agnostic.
There are intricate dependencies. E.g. the latest u-boot won't
properly boot the angstrom 2.6.27 kernel, and the 2.6.27 u-boot will
not boot the 2.6.29 angstrom kernel. One of the causes seem to be that
there are (were?) some dependencies between u-boot and kernel where
the kernel relied on certain initialisations being done by u-boot.
Especially this seems to be an issue wrt USB.

I'm not an MLO wizard, but there the incompatibilities seem to be much less.

BTW: a while ago (in april I think) I build the 2.6.27 kernel, but I
did not manage to find a u-boot which would work with this kernel
(although I am sure I had this early jan). Rationale is that I wanted
to compare SD handling between .27 and .29 (as my SDHC card worked
with .26 and if I recall correctly also .27, but won't work properly
any more with .28 and .29. If anyone has a solution, please let me
know.

Frans

I'm not an MLO wizard, but there the incompatibilities seem to be much
less.

I just checked the MLO source and it's really simple basically only loading
u-boot from MMC in case present. In case not present, it will try to load it
from the NAND flash instead.

As such it's kernel/distro independent, but some kernels/distros might rely
on the fact, that MLO sets up the MMC interface in order to search for a
u-boot binary.

In case this is one day changed due to whatever reason some stuff might
eventually go wrong...
As such, I think it's pretty safe to assume that the kernel and u-boot
should be independent off the MLO. In case they aren't I at least would
consider it a problem that should be solved in u-boot and/or kernel...

Best regards
  Søren

that's the impression i got -- even if u-boot is somehow tied to the
kernel in a distro-dependent way, MLO is so basic that it shouldn't
have any issues working with *any* properly-built u-boot.bin.
however, just to play it safe, it's always a good idea to get
everything from the same place, so that's how i'll word it on my wiki.
thanks.

rday

thanks to all for the feedback on this issue. i realize it was a
fairly nitpicky question but i've learned over the years that
sometimes it's those nitpicky issues that cause minutes or hours of
teeth-grinding frustration.

  i still plan on asking trivially dumb questions on a regular basis
and documenting the answers. i long ago stopped being embarrassed by
making a fool of myself that way. :slight_smile:

  coming soon: what's up with toolchains?

rday