Hello,
On Fri, 10 Oct 2003 03:34:18 +0200, Baurjan Ismagulov wrote:
>> ... (unfortunately, Broadcom doesn't offer a packet driver, but I will
>> work on a generic UNDI driver for the Broadcom 5702 in the near future
>> as soon as I have the hardware available)...
>
> Sorry, what is "_generic_ driver _for smth._"? I thought UNDI provided
> some functions via, say, some interrupt, and these were independent of the
> chipset, etc.?
UNDI is a network driver interface specification. It doesn't say
anything about how the driver is implemented internally. netboot
currently uses pre-compiled driver files (namely packet driver and
NDIS 2 driver binaries), and then implements a framework around these
drivers to make them compatible with the UNDI specification. This
has the advantage that drivers for netboot are widely available: just
take a commercial DOS driver, and run makerom and there you have your
bootrom with an UNDI driver. But it also has drawbacks: the binary
footprint of the bootrom is large because the UNDI-to-packet/NDIS-
interface takes a lot of space (it is essentially a small DOS-
simulator), and the commercial drivers usually contain a lot of
unnecessary messages they print out. Another drawback is that the
commercial drivers are written for the processor's real mode, while
UNDI also specifies operation in a protected mode environment. This
is not a big problem as I haven't seen a PXE boot image yet which
runs in protected mode - even FreeBSD uses Virtual-86-mode when
interfacing with the UNDI driver. For these reasons I would like
to write a generic UNDI driver for certain network cards, e.g. a
driver which contains the complete UNDI-to-hardware interface, and
which is not just a shimmy for some other driver. Planned is to
base such drivers on the Linux network driver source code.
>> ... and replace your current PXE bootrom with the netboot bootrom in the
>> system...
>
> This is, unfortunately, what I'm also trying to avoid -- I would really
> prefer software-only solutions.
Why? It's rather simple. If you have an AMI or Award BIOS it is really
easy to remove the commercial PXE bootrom, and replace it with the
netboot bootrom. See the netboot home page for further information.
> --- boot.c.orig Fri Sep 26 11:43:33 2003 +++ boot.c Fri Sep 26 13:55:13
> 2003
> @@ -103,6 +103,7 @@
> } else
> sname = NULL;
>
> +#if 0
> /* Determine name of boot image file to load */ if ((cp =
> get_vend(VEND_BOOTFILE)) != NULL) {
> len = *cp;
> @@ -112,6 +113,9 @@
> } else if (!(overload & VEND_OVR_FILE))
> memcpy(ldparams.tftp.filename, bootp_bufs[BOOTP_REPLY]->bp_file,
> sizeof(ldparams.tftp.filename));
> +#endif
> + strcpy(ldparams.tftp.filename, "vmlinuz"); +
> if (ldparams.tftp.filename[0] == '\0')
> return(PXENV_STATUS_DHCP_NO_FILE);
This doesn't work: the strcpy() function is not implemented in the
runtime library which gets linked into the bootrom (the bootrom doesn't
use the standard libraries). You have to do it with memcpy:
memcpy(ldparams.tftp.filename, "vmlinuz", 8);
Otherwise the linker will include the strcpy() routine form the standard
library, and this will definitely fail because of different segment
register usage.
> However, I don't see the string "vmlinuz" neither in makerom, nor in
> image.flo. Is this normal?
Yes, of course. The string "vmlinuz" will appear in the file kernel.bin.
After compiling the bootrom, this file is in netboot/bootrom/binaries,
and after installation it will be in /usr/local/lib/netboot/binaries or
wherever you placed the installation. makerom will read it and construct
the final bootrom image. Therefore it doesn't appear in the makerom exe-
cutable. This final bootrom image contains the bootrom kernel in a com-
pressed form, so the string is again not readable in there.
> If these problems are solved, do you see a quick way to generate an image
> usable with PXE BIOS? image.rom seems to have magic numbers / header, and
> image.flo works only from floppy... Would it be easy to modify makerom so
> that it generates just an executable image?
I'm personally using AFD (a very old DOS debugger) for debugging the
bootrom. In order to do this, I've written the bootrom so that it doesn't
depend on any specific load address as long as it isn't in the range
0x8000:0 - 0xA000:0. Therefore it might be possible to just place a small
piece of code in front of the bootrom code:
start: mov ax,0xFFFF
mov bx,ax
xor di,di
mov es,di
push cs # simulate a far call
call bootrom + 0x0003
int 0x18 # or int 0x19, depending on how makerom
# has been instructed to generate the bootrom
hangup: jmp hangup
.align 16
bootrom:
.end
This code first calls the bootrom initialization code, and then the
bootrom itself using the interrupt instruction.
After assembly (you might need to adjust this code to your specific
assembler - note that GAS uses the AT&T syntax, the above syntax is
in Intel format) you can concatenate it with the bootrom as generated by
makerom, so that this program comes directly in front of the bootrom.
Then you should be able to use the resulting file as a boot image to a PXE
bootrom. However, please note that I haven't tried it!! It might also
be possible that it sends your computer into the chip heaven - but I
don't think so ;-))
>> And a third solution would be to wait a couple of months: I'm presently
>> working on mknbi-mgl to generate a boot image file which can be loaded
>> using a commercial PXE bootrom. This way it would be possible to write a
>> small MGL script (just a few lines) which takes an arbitrary, user-
>> defined DHCP tag, or a hard-coded file name if you like, and return it
>> as a boot image file name to the bootrom. Since I'm presently short of
>> time this implementation will still take some time, but initial changes
>> are already implemented. Help is always appreciated...
>
> I would be glad to contribute, and I'm happy to see that this is already
> in your TODO list.
If you really like to help me with the netboot project please let me know
by personal mail. You can always get the current development version using
anonymous CVS from sourceforge.
> Do you think it would be possible for me (some C experience, no
> previous netboot hacking except the one above ;) ) to implement raw image
> generation (executable from PXE BIOS) in this period of time, with
> "cleanups" made later?
Depends on how much you work each day... ;-)) No, really, I don't think
that this is possible, as it involves a whole lot of assembly hacking,
and there are still quite a couple of things missing (like a PXE interface
in the netboot client runtime library).
> Is it possible to implement a chipset-independent UNDI interface?
How will you do this? An UNDI driver is an interface between the UNDI
API and the physical hardware. The most hardware-independent solution
is IMHO already implemented in netboot using commercial packet or NDIS2
drivers, so the UNDI interface just has to translate between two driver
interface specifications. However, if you feel destined to write some
other interface, I would suggest to delve into writing a NDIS4 (or later)
shimmy, because it is to be expected that the manufacturers of network
cards are phasing out their DOS driver development. Only ODI will probably
remain for some time due to the large base of installed Novell servers,
so ODI would also be interesting. However, I have enough to do with the
current projects related to netboot, so UNDI driver development is some-
what in a distant.
gero.
--
Gero Kuhlmann Tollenbrink 18 Groote Gracht 33
gero@gkminix.han.de 30659 Hannover 26723 Emden
gero.kuhlmann@arcor.de 04921/997561
===========================================================================
This Mail was sent to netboot mailing list by:
"Gero Kuhlmann" <gero@gkminix.han.de>
To get help about this list, send a mail with 'help' as the only string in
it's body to majordomo@baghira.han.de. If you have problems with this list,
send a mail to netboot-owner@baghira.han.de.
For requests or suggestions regarding this mailing list archive please write to netboot@gkminix.han.de.