Ron. I'm CC the list as I doubt you are the only one
getting in and out of this kind of confusion.
Ronald G Minnich <[EMAIL PROTECTED]> writes:
> ok, confused again.
>
> memtest86 is an elf file. You even supply one (memtest86.ebi) that from
> the syms looks like it is ready to go.
Yes it is. It is memtest86-2.5. But it is tested and works.
> is memtest86.ebi the output of a mkelfimage run?
No. mkelfImage really should be mkelfImage-linux. As it is linux kernel
specific.
> I made a mistake in the config tool with the 'linux' command -- not
> thinking hard enough -- it should have been a 'payload' command with a
> file name. This will have to change.
Right. I have generaly just put etherboot as my payload and then booted
various images simply by changing my dhcp configuration.
> For now, though, what is your path from memtest86 to an elf image that
> linuxbios can load?
For memtest86-2.7 (the latest) the path is:
get memtest86-2.7.tar.gz and untar.
get memtest86-2.7.eb3.diff and apply the patch.
edit config.h SERIAL_BAUD_RATE to my prefered serial port speed.
run make.
Grab the memtest binary. It is an interrmediate file in the build but
it is an ELF image.
memtest is 100% o.k. for using with linuxBIOS, or etherboot.
It doesn't require any information about the machine it is running on.
mkelfImage was a nice idea, but I think it is generally better to
move the support code into the programs build environment then the
other way around. With a linuxBIOS having stable interface supporting
linuxBIOS is a snap. And you can take advantages of a lot of
shortcuts, building an ELF image for an individual program. Except
for extremely nasty build environments like memtest86 (before it was
patched) it is trivial to modify the build process to make an
appropriate ELF image.
The reason I am working on a general purpose device tree is because
that is the one area where we really lack in a stable interface for
passing parameters. Hopefully I can modify the linux kernel in 2.5
so that it can take advantage of tht interface.
Eric
