Page 1 of 2

how do i load Onboard NIC driver and how to use it ?

Posted: Sun Feb 24, 2008 7:39 pm
by david
most of MainBoard have Onboard NIC, and have the NIC driver .
i want to know how to load the driver , how to use the driver.

Posted: Sun Feb 24, 2008 7:55 pm
by 01000101
you enumerate the onboard NIC through the PCI-bus i believe.

make a PCI BIOS driver and then find the IO/Mem address for the NIC and then you can write the driver for the NIC card based on its chipset (RTL, Intel, etc...).

Re: how do i load Onboard NIC driver and how to use it ?

Posted: Sun Feb 24, 2008 8:55 pm
by Brendan
Hi,
david wrote:most of MainBoard have Onboard NIC, and have the NIC driver .
i want to know how to load the driver , how to use the driver.
The "driver" that comes from ROM (either the NIC's ROM or the BIOS itself) is often not present. If it is present, it includes minimal code for booting the machine from network (ie. it's designed for real mode single tasking situations). It isn't a generic driver that any OS would want to use, just like the BIOS's floppy drive code isn't something any OS would want to use.

In general, you need to write your own device driver if you want something better than "crud". This applies to all hardware.

Now everyone repeat this for a while (until you faint): you need to write your own device driver if you want something better than "crud"; you need to write your own device driver if you want something better than "crud"; you need to write your own device driver if you want something better than "crud"... :lol:


Cheers,

Brendan

Re: how do i load Onboard NIC driver and how to use it ?

Posted: Sun Feb 24, 2008 9:52 pm
by Dex
Brendan wrote:It isn't a generic driver that any OS would want to use, just like the BIOS's floppy drive code isn't something any OS would want to use.
I agree with what your saying about writing your own drivers, but i disagree with you about the bios floppy driver, it's as good if not better than any Pmode driver in linux or windows.

Re: how do i load Onboard NIC driver and how to use it ?

Posted: Mon Feb 25, 2008 12:02 am
by david
Thanks!
Brendan wrote: it includes minimal code for booting the machine from network (ie. it's designed for real mode single tasking situations).
yeah, i think it is true.
i just need the simple NIC driver. i use it to download a bootstrap routine from network server which support PXE.
the bootstrap routine include perfect NIC driver .

what is the inferface ?
UNDI or other ?

i think most of diskless network use the driver .(PXE)

i know intel PAE use it too.

who have some useful information about the driver ?

Re: how do i load Onboard NIC driver and how to use it ?

Posted: Mon Feb 25, 2008 3:15 am
by jal
david wrote:i just need the simple NIC driver. i use it to download a bootstrap routine from network server which support PXE.
If you set your BIOS to 'boot from network', it will invoke the 'driver' (it's just BIOS code actually) which will try to load something from the network (e.g. your OS). The 'driver' code very probably relies on a tight integration with the mainboard BIOS (if it's not exactly in the BIOS already, as it is with many integrated NICs), so there's no way you can use that.


JAL

Re: how do i load Onboard NIC driver and how to use it ?

Posted: Mon Feb 25, 2008 3:28 am
by Brendan
Hi,
Dex wrote:
Brendan wrote:It isn't a generic driver that any OS would want to use, just like the BIOS's floppy drive code isn't something any OS would want to use.
I agree with what your saying about writing your own drivers, but i disagree with you about the bios floppy driver, it's as good if not better than any Pmode driver in linux or windows.
Yeah, the BIOS floppy code is great if you like having hundreds of dollars worth of electronics doing nothing under heavy load while the BIOS waits for the floppy. I guess that's why they invented SMP - so you can actually do something *useful* while an entire CPU's time is wasted for nothing... :roll:


Cheers,

Brendan

Re: how do i load Onboard NIC driver and how to use it ?

Posted: Mon Feb 25, 2008 3:31 am
by Brendan
Hi,
david wrote:
Brendan wrote: it includes minimal code for booting the machine from network (ie. it's designed for real mode single tasking situations).
yeah, i think it is true.
i just need the simple NIC driver. i use it to download a bootstrap routine from network server which support PXE.
the bootstrap routine include perfect NIC driver.
Ahh, my apologies - the NIC's ROM *is* good for that :-)

Note: For this purpose, if the NIC doesn't include a ROM you can use something like etherboot (which will provide the same functionality, but can be booted from ROM, or floppy, or hard-disk, etc). Also (for testing) I found VirtualPC to be easy - the virtual machine can boot from your LAN with very little setup.

Of course you do need a properly configured DHCP server capable of handling PXE, and a TFTP server. The DHCP and TFTP servers don't necessarily need to be on the same computer, but it's easier if they are.
david wrote:what is the inferface ?
UNDI or other ?
The interface is described in the Preboot Execution Environment (PXE) Specification.

It uses UNDI, but there's functions for TFTP (a simplified form of FTP) that are easier to use (functions that are similar to "open()", "read()" and "close()").
david wrote:i think most of diskless network use the driver .(PXE)
Yes.
david wrote:i know intel PAE use it too.
You mean the "Physical Addressing Extensions" CPU feature???
david wrote:who have some useful information about the driver ?
See if this code helps - it's NASM source code for an older version of my PXE boot loader.


Cheers,

Brendan

Posted: Mon Feb 25, 2008 7:50 pm
by david
Brendan wrote:
david wrote: i know intel PAE use it too.
You mean the "Physical Addressing Extensions" CPU feature???
Intel PAE means 'Intel® Platform Administration Technology'.
Brendan wrote: Ahh, my apologies - the NIC's ROM *is* good for that
yes, i just program the NIC's option ROM routine.
Brendan wrote: See if this code helps - it's NASM source code for an older version of my PXE boot loader.
your website can't open.

Posted: Mon Feb 25, 2008 9:54 pm
by Brendan
Hi,
david wrote:
Brendan wrote: See if this code helps - it's NASM source code for an older version of my PXE boot loader.
your website can't open.
Hmm - http://www.websiteoptimization.com/services/analyze/ says may website (and that page specifically) is fine. Usually when my site is down it's because I deliberately turned it off, but I haven't done that lately.

Your profile says you're in China - I wonder if that has something to do with the problem?


Cheers,

Brendan

Posted: Mon Feb 25, 2008 11:59 pm
by david
so, would you like to send a copy to my e-mail ([email protected] or [email protected]).

Thanks !

Posted: Tue Feb 26, 2008 2:04 am
by Brendan
Hi,
david wrote:so, would you like to send a copy to my e-mail
Done. :)


Cheers,

Brendan

Posted: Tue Feb 26, 2008 7:19 pm
by david
i have received it. :D

i will read it in earnest.

thanks again :!:

Posted: Wed Feb 27, 2008 1:25 am
by david
hi , Brendan

i have a question in your 'init.asm' .

Code: Select all

;Input
; ES:BX		Address of the PXENV+ structure (obsolete)
; SS:SP+4	Address of the !PXE structure

START:
        clr ax
        mov ds,ax                               ;Set DS segment register

        mov [PXENVplusOffset],bx                ;Set offset for PXENV+ structure
        mov [PXENVplusSeg],es                   ;Set segment for PXENV+ structure

        cmp sp,0xFFFC                           ;Is SP sane?
        ja .badSPforPXE                         ; no

        mov bp,sp
        mov ax,[bp+4]                           ;ax = offset for !PXE structure
        mov cx,[bp+6]                           ;cx = segment for !PXE structure
        mov [PXEoffset],ax                      ;Set offset for !PXE structure
        mov [PXEseg],cx                         ;Set segment for !PXE structure
.badSPforPXE:
how do you know the segment and offset value of 'PXENV+' structure ?

according to PXE specification 2.1

PXE Installation Check

Code: Select all

   Real mode (Int 1Ah Function 5650h)

Enter:
   AX := 5650h (VP)

Exit:
   AX := 564Eh (VN)
   ES := 16-bit segment address of the PXENV+ structure.
   BX := 16-bit offset of the PXENV+.
   EDX := may be trashed by the UNDI INT 1Ah handler.
   All other register contents are preserved.
   CF is cleared.
   IF is preserved.
   All other flags are undefined.
i do a test.

1. hook int 19h
2. call int 1Ah(call it in my own int 19h interrupt routine)

but, CF=1, bx=0...
in all, failed.

so , i guess BIOS doesn't load Onboard NIC driver before call int 19h.

how do you get the segment and offset value of 'PXENV+' structure ?

thanks !

Posted: Wed Feb 27, 2008 3:04 am
by Brendan
Hi,
david wrote:i do a test.

1. hook int 19h
2. call int 1Ah(call it in my own int 19h interrupt routine)

but, CF=1, bx=0...
in all, failed.

so , i guess BIOS doesn't load Onboard NIC driver since Power On.
Let's start from the start, just to make sure you've got the right idea....

Step 1: Write some testing code like this:

Code: Select all

        ORG 0x7C00

        BITS 16

START:
    mov ax,0xB800                 ;ax = segment for video display memory (text mode assumed)
    mov ds,ax                     ;ax = segment for video display memory
    mov dword [0],0x12345678      ;Trash the top left 2 characters on the screen
.die:
    jmp .die                      ;Lock up
Step 2: Assemble this code, and copy the binary into your TFTP server's directory. For me this directory is "/tftproot", so I'd end up with (for e.g.) the file "/tftproot/bootpxe.bin".

Step 3: Setup your DHCP server so that it tells remote clients to download the file "bootpxe.bin" from the TFTP server. For an example, I'm using Gentoo Linux and my "/etc/dhcp/dhcpd.conf" file looks like this:

Code: Select all

authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;

# DHCP configuration file for DHCP ISC 3.0

ddns-update-style none;

default-lease-time 86400;
max-lease-time 86400;
deny unknown-clients;


# Definition of PXE-specific options
# Code 1: Multicast IP address of boot file server
# Code 2: UDP port that client should monitor for MTFTP responses
# Code 3: UDP port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
#         to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
#         a MTFTP transfer

option space PXE;
option PXE.mtftp-ip               code 1 = ip-address;
option PXE.mtftp-cport            code 2 = unsigned integer 16;
option PXE.mtftp-sport            code 3 = unsigned integer 16;
option PXE.mtftp-tmout            code 4 = unsigned integer 8;
option PXE.mtftp-delay            code 5 = unsigned integer 8;
option PXE.discovery-control      code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr   code 7 = ip-address;

next-server 10.0.0.2;


subnet 10.0.0.0 netmask 255.255.255.0 {

  class "pxeclients" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
    option vendor-class-identifier "PXEClient";
    vendor-option-space PXE;

    # At least one of the vendor-specific PXE options must be set in
    # order for the client boot ROMs to realize that we are a PXE-compliant
    # server.  We set the MCAST IP address to 0.0.0.0 to tell the boot ROM
    # that we can't provide multicast TFTP (address 0.0.0.0 means no
    # address).

    option PXE.mtftp-ip 0.0.0.0;

    # This is the name of the file the boot ROMs should download.
    filename "/bootpxe.bin";
  }


  host test1 {
       # Use your slave's MAC address
       hardware ethernet                00:0F:EA:C4:B8:45;
       # Give your slave a static IP
       fixed-address                    10.0.0.3;
       server-name                      "master";
       # Use your gateway IP, if required
       #option routers                   10.0.0.138;
       # Use your DNS IP, if required
       #option domain-name-servers       10.0.0.138;
       #option domain-name               "mydomain.com";
       # Use your slave hostname
       #option host-name                 "test1";

       # Etherboot and pxe boot with a mac specific image
       #option root-path                 "/tftproot/10.0.0.3";
       #option root-path                 "/tftproot";

       if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
                        filename "/bootpxe.bin";
       } else if substring (option vendor-class-identifier, 0,9) ="PXEClient" {
                        filename "/bootpxe.bin";
       }
  }

  host test2 {
       hardware ethernet                00:80:C8:E7:E7:FD;
       fixed-address                    10.0.0.8;
       server-name                      "master";

       if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
                        filename "/bootpxe.bin";
       } else if substring (option vendor-class-identifier, 0,9) ="PXEClient" {
                        filename "/bootpxe.bin";
       }
  }

  host test3 {
       hardware ethernet                00:09:5B:1A:E8:C4;
       fixed-address                    10.0.0.9;
       server-name                      "master";

       if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
                        filename "/bootpxe.bin";
       } else if substring (option vendor-class-identifier, 0,9) ="PXEClient" {
                        filename "/bootpxe.bin";
       }
  }

  host test4 {
       hardware ethernet                00:03:FF:21:D2:C3;
       fixed-address                    10.0.0.16;
       server-name                      "master";
       if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
                        filename "/bootpxe.bin";
       } else if substring (option vendor-class-identifier, 0,9) ="PXEClient" {
                        filename "/bootpxe.bin";
       }
  }
}
There's probably a cleaner way to do this (e.g. one "generic client" entry rather than one entry for each client), but I'm lazy and it works for me.. ;)

Step 4: Configure the BIOS (or NIC ROM) on the client machine to boot from network, then (with the server running) boot the client.

Note: for step 4, a properly configured etherboot floppy (e.g. etherboot compiled as a boot floppy to suit your NIC) is a good alternative if the client's ROMs don't actually support booting from network.

If everything is right, the client should configure networking (using the DHCP server), download your boot loader from the TFTP server, then execute your boot loader. In this case the top left 2 characters on the screen will be trashed and the computer will lock up (because that's what the code above does).


Now, if you've got all of the above working, then...

From the PXE Specification ("3.1 PXE Installation Check"):

"The primary users of these installation check methods are protocol drivers designed to use the PXE
APIs. NBPs do not need to use these installation check procedures because the address of the !PXE
structure is passed to them on the stack.
Note: For backward compatibility with existing applications, the address of the PXENV+ structure
must also be passed in the ES:BX register pair. Since support for the PXENV+ structure is not
planned for future versions, new applications (for example, universal protocol drivers) should be
written to !PXE.
"

The "NBP" is your Network Bootstrap Program (your bootloader) so no installation check is necessary, and the address of the !PXE structure is passed to your bootloader on the stack. For backward compatability with an older version of the PXE specification the address of the PXENV+ structure is also passed in ES:BX.

The !PXE structure is a newer structure that contains the segment and offset for the !PXE API. The PXENV+ structure is an older structure that contains the segment and offset for the PXENV+ API. This is 2 different structures with 2 different APIs. However, the different APIs are functionally equivelent - the only difference is the calling conventions.

Because of this I use a wrapper around the API itself, so that my boot loader will use the !PXE API calling conventions and !PXE entry point if !PXE was supported, and use PXENV+ calling conventions and PXENV+ entry point if !PXE isn't supported. This just means that I can call my wrapper and don't need to care if !PXE is supported or not (ie. my boot loader should work fine on newer NICs that comply with version 2.1 of the PXE specification and older NICs that only comply with older versions of the PXE specification).

My init code just tries to get the address of the !PXE and PXENV+ structures so that later code (in the file "bcos/80x86/sys_src/p1/bootpxe/_doc/main.html") can check if either of the structures were sane (and setup the API wrapper so that I can use it easily).


Cheers,

Brendan