|
From: Marty C. <md...@th...> - 2001-06-18 20:34:41
|
On 6/18/2001 12:07 PM Peter Lister P.L...@sy... wrote:
>OK, more news from the front... I'm still trying to run Etherboot from a
>PXE based nic boot rom.
I like this idea, and am glad you're doing it. Thanks for your
persistence.
>So, given that one can't install etherboot on the machine somewhere, the
>obvious solution is to use the nic rom (e.g. 3Com "Managed PC Boot
>Agent") to pull Etherboot. However, when I first tried that I just
>seemed to get a silent frozen system. As I have no way of knowing what
>the proprietary nic rom was doing, I tried pxelinux, finding (a) that it
>worked out of the box and (b) a hint to the effect that Etherboot is an
>example of a COMBOOTable application.
I'm going to venture some guesses here, and hope that people who
understand these things better will possibly chime in.
Not being quite sure what precisely a combootable application is, I did a
search and found this link:
http://www.cs.helsinki.fi/u/mjrauhal/linux/cola.archive/1996-04/cola.1996-0
4-27.001
Which seems to answer the question. Etherboot can generate .COM files
using a command like "make bin32/rtl8139.com". This probably isn't
helpful to your current situation, but I thought I'd mention it for
others.
>Anyway, I have just tried *again* to load etherboot directly with MBA, I
>now see a message...
>This image cannot be loaded from a floppy disk
So you must be trying to load a ".lzlilo" image.
>...on the vga console; I must have missed it before, and it wasn't
>immediately obvious that this is an Etherboot message (Note - please
>could you prefix ALL messages with 'Etherboot:' so that it is clear what
>is generating the message).
I agree that we should probably consider being more uniform in output
from Etherboot. Your concern is noted.
>So this confirms that the Etherboot image IS being executed (I also
>added some messages in pxelinux which confirm that pxelinux is NOT
>rejecting the lilo image, it's doing the right thing, just like booting
>a genuine kernel). This message is in the liloprefix code, and should
>never be run.
>What do I need to do here? It would seem to a naive observer that that
>the fix should simply be to redirect to the "right" place. I have tried
>replacing the 'freeze: jmp freeze' loop with 'jmp setup_code' but other
>than a line of garbage on the vga console, I get nothing.
Here's what I think is happening. I hope this makes sense.
An ".lzlilo" image is a "fake" kernel. It is good enough to fool lilo,
syslinux, and hopefully someday LOADLIN. We created it by reading the
source code to various loaders and utilities, and seeing what they needed
in order to believe that something was a kernel. Some do sanity checking
on size, while others do various kinds of peeking at header fields.
I'm not sure what the LANWORKS MBA is doing, and without source code,
help, or disassembly, it would be hard to figure out. But I have an idea.
Here is a link on the Linux Terminal Server Project Site
http://www.ltsp.org/documentation/LTSP-MBA.htm
Which describes how to use a mknbi "tagged image file" with the LANWORKS
MBA.
Here is an excerpt:
"... Support for 3Com Managed PC Boot Agent (MBA).
3Com MBAs will not support the LTSP boot image files by default. This is
because the 3Com boot ROMs do not support the format of boot image files
created using the mknbi=A0 Etherboot utility.=A0 To
address this problem, Lanworks Technologies has developed a Linux boot
image creation utility called imggen.=A0 Imggen patches any Etherboot Linux=
kernel image so that it can be booted using
any Lanworks MBA or BootWare Tri-ROM.=A0 This document details the steps
required to use Lanworks TCP/IP boot ROMs with the Linux Terminal Server.
... "
LTSP distributes kernel images which have been reformatted ("tagged")
with a utility called "mknbi-linux". This allows Etherboot to load them,
because (someone correct me if i'm wrong) it is more complicated (thus
using more code space) to load raw kernel images that have not been
tagged. Tagging allows the loading mechanism in Etherboot to be more
efficient (and fit better in the limited space of the ROM).
Here is a link to the "imggen" utility.
http://prdownloads.sourceforge.net/ltsp/imggen
It takes a tagged kernel image and makes it into an image that the 3COM
MBA can load. Some Doc is at the link above.
I do not know exactly what imggen does, but a binary compare of the
before and after kernel images would probably tell us. I also note that
imggen is only 21K, so it probably wouldn't be hard to disassemble and
figure out what it is doing. It is probably dressing up the tagged image
enough to fool the MBA into loading and executing it. Does anyone have
the source code for imggen?
>I wondered if trying just a rom or lzrom would work, or even the
>3c905x.img (since the code should just enter at the top of _start), but
>nothing seems to work. I'm sure that, to someone who knows the code,
>this is now a trivial problem. Help, please?
With the disclaimer that others probably know a lot more about this than
I do, I'll suggest the following.
1. Make a .lzlilo image. It's a fake kernel, but let's pretend it's
real.
2. Try running mknbi-linux on it. This will give you a "tagged" kernel
(.lzlilo) image.
3. Take the tagged "kernel" (.lzlilo) image from step 2 and run the
"imggen" utility on it.
This might work. I haven't tried it, but I think that even if it doesn't
work, we may have a shot at fixing it to work.
Actually, I just did some experiments, and it seems there are more subtle
problems here. mknbi-linux does a sanity check on the ".lzlilo" image
and fails. The sanity check can be commented out, and it will generate a
tagged image.
The imggen utility is is willing to run on the tagged image, and produces
an output file.
Unfortunately, on my 3C905C board, setting the boot method to TCP/IP and
DHCP, I get:
NODE: 000102C179C7
DHCP..
TFTP....................
And nothing more. It seems the MBA is not happy with our
fake-tagged-imggen'ed file. I'm not sure why.
The daemon.log file shows:
Jun 18 14:48:58 ll dhcpd-2.2.x: DHCPDISCOVER from 00:01:02:c1:79:c7 via
eth0
Jun 18 14:48:58 ll dhcpd-2.2.x: DHCPOFFER on 192.168.2.136 to
00:01:02:c1:79:c7 via eth0
Jun 18 14:48:59 ll dhcpd-2.2.x: DHCPREQUEST for 192.168.2.136 from
00:01:02:c1:79:c7 via eth0
Jun 18 14:48:59 ll dhcpd-2.2.x: DHCPACK on 192.168.2.136 to
00:01:02:c1:79:c7 via eth0
Jun 18 14:49:00 ll in.tftpd[1322]: connect from 192.168.2.136
Jun 18 14:49:00 ll tftpd[1323]: tftpd: trying to get file:
/tftpboot/lts/3c905c-tpo.imggen
I also tried running imggen on a .lzrom file tagged with mknbi-rom with
identical results.
>If we can get EB to run straight away, without pxelinux, this would be
>great. Maybe better yet if EB could snarf enough pxe code from pxelinux
>to be a good pxe citizen (i.e. return control back to pxe if things go
>wrong, rather than looping), and have a "PXEable" image build option.
>And maybe, once successfully demo'd, we can persuade customers to just
>flash Etherboot.
These are interesting ideas. I'm not sure if anyone is interested in
doing this, since Etherboot supports a large number of cards, but I've
occasionally thought this would be an interesting idea, in principle for
people who have PXE cards but want to execute Etherboot before booting
their ultimate OS.
Maybe someone else has some ideas or suggestions. I'm out of ideas and
time for the moment. Let us know if you get any farther. Perhaps some
3Com folks would be willing to help debug this?
Marty
---
Try: http://rom-o-matic.net/ to make Etherboot images instantly.
Name: Marty Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
Voice: (617) 491-6935, Fax: (617) 491-7046
Email: md...@th...
Web: http://www.thinguin.org/
|
