etherboot-developers

[Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

There is now a very-nearly working UNDI driver in 5.1 CVS under
arch/i386/drivers/net.  This driver allows Etherboot to work with any NIC
for which an UNDI option ROM is provided.

The driver does not require Etherboot to be started by chaining from PXE;  
it will scan for an UNDI ROM and initialise it fully from scratch.  I have
been testing by booting from floppy, which works fine.  I imagine that 
PXE-chaining would also work, although I haven't tested it yet.

Note that you cannot yet use the Etherboot UNDI driver to actually boot a
kernel;  although all the routines are working and the driver can get a
DHCP lease and start downloading a file, it dies instantly because the
downloaded file stomps right over the PXE UNDI driver.  In order to fix 
this, I need to sort out a method for allocating base memory in Etherboot.

Question 1: Is there currently any method for allocating base memory?  I
need space for three structures:

1. The PXE UNDI driver code segment (up to 64K, probably 16K)
2. The PXE UNDI driver data segment (up to 64K, probably 16K)
3. Temporary buffers that I can stick data into while calling the 
   real-mode UNDI API (about 2-3K).

I'm currently (as a quick "test-the-driver" method) dumping these at
pseudo-random places in base memory, which works fine up to the point that
a kernel image loads...  :-)


Question 2: I have an assembly routine _undi_call that is a wrapper around 
the real-mode UNDI API calls.  I've placed this in pcbios.S but haven't 
yet checked it in because it seems like a bad place to put it; it would 
end up being compiled in to every Etherboot image, not just the UNDI one.  
Ideally, I'd like to create a file undi_wrapper.S in 
arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
have to edit genrules.pl to achieve this, unless anyone can suggest a 
quick and easy method?


Michael

[Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

The i386 UNDI driver in Etherboot 5.1 CVS should now be functioning
correctly.  Please test and give feedback.

  make bin/undi.zfd0

will give you a bootable floppy that should be able to detect any PXE 
ROMs, load the UNDI drivers and use them to boot as per normal.

I haven't yet got around to testing chaining from PXE, but

  make bin/undi.zpxe

will give the appropriate test image, should anyone wish to try it out.

There are no known issues for systems containing a single NIC and single 
PXE ROM at this time.  (Multiple NICs / multiple PXE ROMs may have 
problems; please let me know.)

Please do give feedback; this driver has to work with any PXE 
implementation, and I have only Intel's to play with.

Michael

Re: [Etherboot-developers] UNDI driver

[Marty C. <md...@et...>]

On Saturday, May 24, 2003, at 03:46  PM, Michael Brown wrote:
> The i386 UNDI driver in Etherboot 5.1 CVS should now be functioning
> correctly.  Please test and give feedback.

This is excellent news, Michael! Congratulations.

>   make bin/undi.zfd0
> will give you a bootable floppy that should be able to detect any PXE
> ROMs, load the UNDI drivers and use them to boot as per normal.
> I haven't yet got around to testing chaining from PXE, but
>   make bin/undi.zpxe
> will give the appropriate test image, should anyone wish to try it out.
> There are no known issues for systems containing a single NIC and 
> single
> PXE ROM at this time.  (Multiple NICs / multiple PXE ROMs may have
> problems; please let me know.)

I am building the appropriate test environment this morning and hope to 
begin testing later today. I'll report back with my results.

> Please do give feedback; this driver has to work with any PXE
> implementation, and I have only Intel's to play with.
> Michael

I have a 3Com 3C905C-xxx with PXE in flash that I use especially for 
occasions like this. I should send you one :)

Thanks for doing 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...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] UNDI driver

[Marty C. <md...@et...>]

On Saturday, May 24, 2003, at 03:46  PM, Michael Brown wrote:
> The i386 UNDI driver in Etherboot 5.1 CVS should now be functioning
> correctly.  Please test and give feedback.
>   make bin/undi.zfd0
> will give you a bootable floppy that should be able to detect any PXE
> ROMs, load the UNDI drivers and use them to boot as per normal.

OK, I have put together a test system, and have two Ethernet cards (an  
Intel EEPRO100, and a 3Com 3C905C-TX-M) with PXE, and an HP branded  
thin client with an on-board VIA 6102 chipset and Intel PXE 2.2 in BIOS  
to test with.

I got the latest copy of Etherboot to my Redhat 8.0 system with:

     $ cvs -d:pserver:ano...@cv...:/cvsroot/etherboot  
login

followed by:

     $ cvs -d:pserver:ano...@cv...:/cvsroot/etherboot  
checkout etherboot

to download it.

I then did:

     $ cd etherboot/etherboot-5.1/src/
     $ make bin/undi.zfd0

to create the test floppy.

My test system is an Intel CA810E motherboard with what I believe is a  
Phoenix derived BIOS (not sure of that).

My first test went well:

NIC: 3C905-TX-M
Boot METHOD: FLOPPY
OUTPUT:
Loading ROM image...............
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Boot from (N)etwork (D)disk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000cc000...PCI:10b7:9200...ok
ROM contains MBA UNDI by 3Com
Located UNDI ROM supporting revision 2.1.0
Installing UNDI driver code to 9d00:0000, data at 99c0:0000
UNDI driver created a pixie at 9d00:0060...ok
API 9d00:00f6 St 0000:0000 UD 9c40:3284 UC 9d00:24c0 BD 0000:0000 BC  
0000:0000
Initialized UNDI NIC with IO 0xdc00, IRQ 11, MAC 00:01:02:59:03:D5
NDIS type DIX+802.3 interface at 100Mbps
Searching for server (DHCP)...
..Me: 192.168.2.137, Server: 192.168.2.37, Gateway 192.168.2.15
Loading 192.168.2.37:/lts/vmlinuz-2.4.19-ltsp-1  
...(NBI)........................
........................................................................ 
........
........................................................................ 
........
......done
mknbi-1.2-7/first32.c (GPL)
Top of ramdisk is 0X07EC0000
Ramdisk at 0X07E0D000, size 0X000B3000
Uncompressing Linux... Ok, booting the kernel.

Works!

My next test was to try the same thing with the other card:

NIC: EEPRO100
Boot METHOD: FLOPPY
OUTPUT:
Loading ROM image...............
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Boot from (N)etwork (D)disk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000cc000...PCI:8086:1229...ok
ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Installing UNDI driver code to 9d80:0000, data at 9a80:0000
UNDI driver created a pixie at 9d80:0070...ok
API 9d80:0106 St 9430:0800 UD 9a80:4d30 UC 9d80:1e70 BD 0000:37c0 BC  
0000:563a
UNDI API call 0x000a failed with status 0x0000
Hunting for ROMS...found 55AA at 000c0000...PCI:8086:7125...not me  
(8086:1229)
...none found
Probing isa nic...
<sleep>
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?

Looks like an UNDI call failed. Please let me know if I can help debug  
this one further.

> I haven't yet got around to testing chaining from PXE, but
>   make bin/undi.zpxe
> will give the appropriate test image, should anyone wish to try it out.

Chaining didn't go so well for me. I wasn't able to get it to work.  
Here's a relevant part of my dhcpd.conf file:

# 3COM PXE Card
     host ws137 {
         hardware ethernet     00:01:02:59:03:d5;
         fixed-address         192.168.2.137;
         if        substring (option vendor-class-identifier, 0, 9) =  
"PXEClient" {
             filename "/undi.zpxe";
         } else if substring (option vendor-class-identifier, 0, 9) =  
"Etherboot" {
             filename              "/lts/vmlinuz-2.4.19-ltsp-1";
             option vendor-encapsulated-options  
3c:09:45:74:68:65:72:62:6f:6f:74:ff;
         }
     }

Here's the output using the 3Com Card:

Managed PC Boot Agent (MBA) v4.00
(C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com  
Corporation
All rights reserved.

Pre-boot eXecution Environment (PXE) v2.00
(C) Copyright 1999 Intel Corporation.
(C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com  
Corporation
All rights reserved.

DHCP MAC ADDR: 00 01 02 59 03 D5
CLIENT IP: 192.168.2.137  MASK: 255.255.255.0  DHCP IP: 192.167.2.37
GATEWAY IP: 192.168.2.15
PXE loader for etherboot
0x27FK low memory
  PXENV+ unloaded
ROM segment 0x0000 length 0x0000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [0000c070,0001b780) to [07eb08f0,07ec0000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
Probing pci nic...
[UNDI]Hunting for PnP BIOS... found $PnP at f000:2c30...ok
Hunting for pixies...found !PXE at 0009d7a0...ok

It hangs here.

Please let me know how I can help debug this. It would be way cool to  
make this work such that any PXE card could use Etherboot just by  
chaining the Etherboot PXE loader.

> There are no known issues for systems containing a single NIC and  
> single
> PXE ROM at this time.  (Multiple NICs / multiple PXE ROMs may have
> problems; please let me know.)
> Please do give feedback; this driver has to work with any PXE
> implementation, and I have only Intel's to play with.
> Michael

We might consider sending a message to the etherboot-users list once  
things are a little farther along asking for testers. Once they see how  
easy it is to get a cvs version and make the required test images, we  
might get a few people to give it a whirl.

Thanks for your efforts, Michael. This UNDI driver could be a useful  
addition for people who   have PXE and use it to boot Etherboot as well  
as some other cases we haven't even thought of yet.

Marty

P.S. The screen texts above might have minor typos as I copied them by  
hand. I tried my best to check the numbers to give you the best  
information I could.

-- 
     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...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

> [UNDI]Hunting for PnP BIOS...found $PnP at f000:2c30...ok
> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000cc000...PCI:8086:1229...ok
> ROM contains Intel UNDI, PXE-2.0 (build 067) by Intel Corporation
> Located UNDI ROM supporting revision 2.1.0
> Installing UNDI driver code to 9d80:0000, data at 9a80:0000
> UNDI driver created a pixie at 9d80:0070...ok
> API 9d80:0106 St 9430:0800 UD 9a80:4d30 UC 9d80:1e70 BD 0000:37c0 BC  
> 0000:563a
> UNDI API call 0x000a failed with status 0x0000
> <snip> 
> Looks like an UNDI call failed. Please let me know if I can help debug  
> this one further.

Call 0x000a is PXENV_UNDI_SET_STATION_ADDRESS (you can find the numbers in 
arch/i386/include/pxe.h; I left textual descriptions of the API numbers 
out of the code to save space).  Interestingly, status 0x0000 is 
PXENV_STATUS_SUCCESS, so there's a bug in the Intel code if it's returning 
exit = PXENV_EXIT_FAILURE with status = PXENV_STATUS_SUCCESS.

I suspect this means that PXENV_UNDI_SET_STATION_ADDRESS isn't properly 
implemented.  You can try commenting out the call as follows:



--- arch/i386/drivers/net/undi.c        24 May 2003 20:16:25 -0000      1.12
+++ arch/i386/drivers/net/undi.c        29 May 2003 01:17:30 -0000
@@ -443,7 +443,7 @@
 }

 int eb_pxenv_undi_set_station_address ( void ) {
-       return undi_call ( PXENV_UNDI_SET_STATION_ADDRESS );
+       return 1; /* undi_call ( PXENV_UNDI_SET_STATION_ADDRESS ); */
 }

 int eb_pxenv_undi_get_information ( void ) {



PXE spec requires that we make this call, so it may be a case of "make the 
call, ignore failures and continue".

> Chaining didn't go so well for me. I wasn't able to get it to work.  
> Here's a relevant part of my dhcpd.conf file:
> # 3COM PXE Card
>      host ws137 {
>          hardware ethernet     00:01:02:59:03:d5;
>          fixed-address         192.168.2.137;
>          if        substring (option vendor-class-identifier, 0, 9) =  
> "PXEClient" {
>              filename "/undi.zpxe";
>          } else if substring (option vendor-class-identifier, 0, 9) =  
> "Etherboot" {
>              filename              "/lts/vmlinuz-2.4.19-ltsp-1";
>              option vendor-encapsulated-options  
> 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
>          }
>      }
> Here's the output using the 3Com Card:
> Managed PC Boot Agent (MBA) v4.00
> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com  
> Corporation
> All rights reserved.
> Pre-boot eXecution Environment (PXE) v2.00
> (C) Copyright 1999 Intel Corporation.
> (C) Copyright 1999 Lanworks Technologies Co. a subsidiary of 3Com  
> Corporation
> All rights reserved.
> DHCP MAC ADDR: 00 01 02 59 03 D5
> CLIENT IP: 192.168.2.137  MASK: 255.255.255.0  DHCP IP: 192.167.2.37
> GATEWAY IP: 192.168.2.15
> PXE loader for etherboot
> 0x27FK low memory
>   PXENV+ unloaded
> ROM segment 0x0000 length 0x0000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [0000c070,0001b780) to [07eb08f0,07ec0000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS... found $PnP at f000:2c30...ok
> Hunting for pixies...found !PXE at 0009d7a0...ok
> It hangs here.
> Please let me know how I can help debug this. It would be way cool to  
> make this work such that any PXE card could use Etherboot just by  
> chaining the Etherboot PXE loader.

Hmmm, it looks as though the PXE loader is unloading the stack but leaving 
the empty shell of the !PXE structure resident in memory, so that we pick 
it up on a scan and try to use memory that has already been freed.  
Two-stage fix:

1. Possibly perform further validity checks on the !PXE structure,
   although we're already checking the signature and checksum.

2. PXE loader should trash the UNDI code segment if it unloads the PXE 
   stack.

You might get it to work if you define PXELOADER_KEEP_UNDI when compiling 
pxeprefix.S; this should prevent the PXE loader from unloading the PXE 
stack.  I haven't tested this, just an idea.

I am off to Manchester for the next two days, but I'll take a look at the 
weekend.

> P.S. The screen texts above might have minor typos as I copied them by  
> hand. I tried my best to check the numbers to give you the best  
> information I could.

Many thanks; it's always useful to get detailed bug reports.

Michael

Re: [Etherboot-developers] UNDI driver

[Marty C. <md...@et...>]

On Wednesday, May 28, 2003, at 09:24  PM, Michael Brown wrote:
> I suspect this means that PXENV_UNDI_SET_STATION_ADDRESS isn't properly
> implemented.  You can try commenting out the call as follows:
>  int eb_pxenv_undi_set_station_address ( void ) {
> -       return undi_call ( PXENV_UNDI_SET_STATION_ADDRESS );
> +       return 1; /* undi_call ( PXENV_UNDI_SET_STATION_ADDRESS ); */
>  }
> PXE spec requires that we make this call, so it may be a case of "make 
> the
> call, ignore failures and continue".

Success! With this patch both the 3Com and the Intel cards boot from 
floppy using the UNDI driver.

>> Chaining didn't go so well for me. I wasn't able to get it to work.
>> PXE loader for etherboot
>> 0x27FK low memory
>>   PXENV+ unloaded
>> ROM segment 0x0000 length 0x0000 reloc 0x00020000
>> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
>> Relocating _text from: [0000c070,0001b780) to [07eb08f0,07ec0000)
>> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal?
>> Probing pci nic...
>> [UNDI]Hunting for PnP BIOS... found $PnP at f000:2c30...ok
>> Hunting for pixies...found !PXE at 0009d7a0...ok
>> It hangs here.
> Hmmm, it looks as though the PXE loader is unloading the stack but 
> leaving
> the empty shell of the !PXE structure resident in memory, so that we 
> pick
> it up on a scan and try to use memory that has already been freed.
> Two-stage fix:
> 1. Possibly perform further validity checks on the !PXE structure,
>    although we're already checking the signature and checksum.
> 2. PXE loader should trash the UNDI code segment if it unloads the PXE
>    stack.

I think we're pretty close on this, and with some debugging we should 
be able to get it going.

Vasil and Peter, could you possibly make a version of (or patch for) 
pxeprefix.S for 5.1.8 that would implement strategy 2 above? I'm going 
to try to invalidate the checksum, but my assembler is rusty, and it 
will take a me a little while to get back up to speed. Many thanks for 
your help.

> You might get it to work if you define PXELOADER_KEEP_UNDI when 
> compiling
> pxeprefix.S; this should prevent the PXE loader from unloading the PXE
> stack.  I haven't tested this, just an idea.

I tried this, and it got a bit farther on some cards, but on others it 
hung.
I suspect the Etherboot UNDI driver is getting confused by the pieces 
of PXE and UNDI structure hanging around in memory. The other thing 
that comes to mind is so other machine state that is confusing at 
startup for Etherboot such as register contents or hooked INTs.

> I am off to Manchester for the next two days, but I'll take a look at 
> the
> weekend.

Thanks for replying before you left.
Have a nice trip!

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...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

On Thu, 29 May 2003, Marty Connor wrote:
> > I suspect this means that PXENV_UNDI_SET_STATION_ADDRESS isn't properly
> > implemented.  You can try commenting out the call as follows:
> >  int eb_pxenv_undi_set_station_address ( void ) {
> > -       return undi_call ( PXENV_UNDI_SET_STATION_ADDRESS );
> > +       return 1; /* undi_call ( PXENV_UNDI_SET_STATION_ADDRESS ); */
> >  }
> > PXE spec requires that we make this call, so it may be a case of "make 
> > the
> > call, ignore failures and continue".
> Success! With this patch both the 3Com and the Intel cards boot from 
> floppy using the UNDI driver.

Excellent.  I have committed an update that fixes this permanently; it 
will simply ignore failures from PXENV_UNDI_SET_STATION_ADDRESS and 
suppress the API call failed message.

> > I am off to Manchester for the next two days, but I'll take a look at 
> > the
> > weekend.
> Thanks for replying before you left.
> Have a nice trip!

Am still in Manchester at the moment (isn't ssh wonderful? :) - will get 
on to pxeprefix stuff tomorrow, unless anyone else wants to sort it out.

Michael

Re: [Etherboot-developers] UNDI driver

[Georg B. <gb...@us...>]

Am Samstag, 24. Mai 2003 21:46 schrieb Michael Brown:
> I haven't yet got around to testing chaining from PXE, but
>
>   make bin/undi.zpxe
>
> will give the appropriate test image, should anyone wish to try it out.

I did, but it did not work (cvs from today). The PXE implementation is Intel 
Boot Agent Version 4.0.22, the NIC is an onboard eepro100. Here are the 
messages:

PXE loader for etherboot
0x27EK low memory
 PXE    unloaded
ROM segment 0x000 length 0x000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [00007e70,00017b80) to [076f02f0,07700000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N

Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
Hunting for pixies...found !PXE at 0009de0...ok
UNDI API call 0x0000 failed with status 0x006a
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000e0000...PCI:8086:1031...ok
ROM contains IBA 4.0.22 Slot 0140 by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Installing UNDI driver code to 9d00:0000, data at 9380:0000
UNDI driver created a pixie at 9d00:0070...ok
API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
0000:5f86
Initialized UNDI NIC with IO 0x7000, IRQ 11, MAC 00:00:E2:8C:5F:43
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
..Me: 192.168.0.3, Server: 192.168.0.1
Loading 
192.168.0.1:/tftpboot/lts/vmlinuz-2.4.19-ltsp-1-mknbi-1.2.7-10...(NBI)segment 
[00092800, 000093A00) overlaps used basemem [00093000, 000A0000)
error: not a valid image
Unable to load file.
<sleep>


Note that the kernel image _is_ valid. After the sleep, it tries again with 
different results and finally hangs after printing the "API 9d00:0106..." 
line, but I think this is only a side-effect and the real error occurs 
earlier.

Then I tried chaining from Etherboot, and the result is:


ROM segment 0x1000 length 0x8000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [0000241b0,00033ec0) to [076f02f0,07700000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N

Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000e0000...PCI:8086:3577...not me 
(8086:1031)
...none found
Probing isa nic...
<sleep>


Michael, I hope this is of help to you. Please tell if I should do anything 
further to track the problem down.


Georg

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

On Thu, 29 May 2003, Georg Baum wrote:
> I did, but it did not work (cvs from today). The PXE implementation is Intel 
> Boot Agent Version 4.0.22, the NIC is an onboard eepro100. Here are the 
> messages:
> PXE loader for etherboot
> 0x27EK low memory
>  PXE    unloaded
> ROM segment 0x000 length 0x000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [00007e70,00017b80) to [076f02f0,07700000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
> Hunting for pixies...found !PXE at 0009de0...ok
> UNDI API call 0x0000 failed with status 0x006a

PXE chaining is failing.  I will try to sort out the pxeloader code so
that it leaves the !PXE structure in a valid state (unless one of Peter or
Vasil has already done this).  This looks like the same problem Marty was 
experiencing.

> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000e0000...PCI:8086:1031...ok
> ROM contains IBA 4.0.22 Slot 0140 by Intel Corporation
> Located UNDI ROM supporting revision 2.1.0
> Installing UNDI driver code to 9d00:0000, data at 9380:0000
> UNDI driver created a pixie at 9d00:0070...ok
> API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
> 0000:5f86

And here we see one of the nice features of the driver at work: even 
though it failed to PXE-chain, it's trying to reload the PXE driver from 
ROM as a fallback strategy.  :)

> Initialized UNDI NIC with IO 0x7000, IRQ 11, MAC 00:00:E2:8C:5F:43
> NDIS type DIX+802.3 interface at 100 Mbps
> Searching for server (DHCP)...
> ..Me: 192.168.0.3, Server: 192.168.0.1
> Loading 
> 192.168.0.1:/tftpboot/lts/vmlinuz-2.4.19-ltsp-1-mknbi-1.2.7-10...(NBI)segment 
> [00092800, 000093A00) overlaps used basemem [00093000, 000A0000)
> error: not a valid image
> Unable to load file.
> <sleep>
> Note that the kernel image _is_ valid. After the sleep, it tries again with 
> different results and finally hangs after printing the "API 9d00:0106..." 
> line, but I think this is only a side-effect and the real error occurs 
> earlier.

The "not a valid image" message is misleading: the real error is the 
previous line talking about a segment overlap.  The image you are trying 
to load wants to be loaded at a location that would tread on the UNDI 
driver code.

Can you try enabling DEBUG_BASMEM in arch/i386/firmware/pcbios/basemem.c?  
This should print out diagnostic messages about base memory allocation, 
which will help us see what is going on.  It's possible (likely) that the 
!PXE structure from the first attempt is not being freed properly and so 
the second time round it loads it much lower in base memory than it would 
normally.  The alternative is that your UNDI driver is huge, in which case 
you will need to create an image that doesn't need to tread on that area 
of memory.

> Then I tried chaining from Etherboot, and the result is:
> ROM segment 0x1000 length 0x8000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [0000241b0,00033ec0) to [076f02f0,07700000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000e0000...PCI:8086:3577...not me 
> (8086:1031)
> ...none found
> Probing isa nic...
> <sleep>

It's not seeing the PXE ROM.  Do you have LAN enabled as part of the BIOS 
boot sequence?  I have found that some BIOSes (or possibly some PXE ROMs) 
will hide the PXE ROM if LAN is not listed as a BIOS boot device.

Michael

Re: [Etherboot-developers] UNDI driver

[Vasil V. <vas...@sy...>]

On Fri, 30 May 2003, Michael Brown wrote:

> On Thu, 29 May 2003, Georg Baum wrote:
> > I did, but it did not work (cvs from today). The PXE implementation is Intel
> > Boot Agent Version 4.0.22, the NIC is an onboard eepro100. Here are the
> > messages:
> > PXE loader for etherboot
> > 0x27EK low memory
> >  PXE    unloaded
> > ROM segment 0x000 length 0x000 reloc 0x00020000
> > Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> > Relocating _text from: [00007e70,00017b80) to [076f02f0,07700000)
> > Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N
> > Probing pci nic...
> > [UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
> > Hunting for pixies...found !PXE at 0009de0...ok
> > UNDI API call 0x0000 failed with status 0x006a
>
> PXE chaining is failing.  I will try to sort out the pxeloader code so
> that it leaves the !PXE structure in a valid state (unless one of Peter or
> Vasil has already done this).  This looks like the same problem Marty was
> experiencing.

I am bit rusty on this and don't have much time right now to try it, but
wouldn't it be enough to define PXELOADER_KEEP_UNDI? The only thing it does is
actually not to reduce the the memory as to free the UNDI memory.

Alternatively, if "leaving !PXE structure in a valid state" means we don't
stop the the UNDI, then just don't include the whole of pxeprefix.c .

I didn't quite follow what the UNDI driver requires, but once this is clear it
shouldn't be hard to just skip whichever steps shouldn't be done. I guess that
the whole of pxeprefix shouldn't be there.

Gread job, Michael. Now, I can just specify to a vendor that I want PXE
support and not what the NIC is. If the NIC has a driver in etherboot, then
great. If not, then I can still use etherboot.

In general, etherboot is turning into a great infrastructure.

Vasil

Re: [Etherboot-developers] UNDI driver

[Georg B. <gb...@us...>]

Am Freitag, 30. Mai 2003 15:58 schrieb Michael Brown:
> On Thu, 29 May 2003, Georg Baum wrote:
> > I did, but it did not work (cvs from today). The PXE implementation is
> > Intel Boot Agent Version 4.0.22, the NIC is an onboard eepro100. Here
> > are the messages:
> > PXE loader for etherboot
> > 0x27EK low memory
> >  PXE    unloaded
> > ROM segment 0x000 length 0x000 reloc 0x00020000

Is this         ^            ^
correct?

> > Initialized UNDI NIC with IO 0x7000, IRQ 11, MAC 00:00:E2:8C:5F:43
> > NDIS type DIX+802.3 interface at 100 Mbps
> > Searching for server (DHCP)...
> > ..Me: 192.168.0.3, Server: 192.168.0.1
> > Loading
> > 192.168.0.1:/tftpboot/lts/vmlinuz-2.4.19-ltsp-1-mknbi-1.2.7-10...(NBI)s
> >egment [00092800, 000093A00) overlaps used basemem [00093000, 000A0000)
> > error: not a valid image
> > Unable to load file.
> > <sleep>
> > Note that the kernel image _is_ valid. After the sleep, it tries again
> > with different results and finally hangs after printing the "API
> > 9d00:0106..." line, but I think this is only a side-effect and the real
> > error occurs earlier.
>
> The "not a valid image" message is misleading: the real error is the
> previous line talking about a segment overlap.  The image you are trying
> to load wants to be loaded at a location that would tread on the UNDI
> driver code.

> Can you try enabling DEBUG_BASMEM in arch/i386/firmware/pcbios/basemem.c?

I did. The result:

PXE loader for etherboot
0x27EK low memory
 PXE    unloaded
ROM segment 0x000 length 0x000 reloc 0x00020000
Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
Relocating _text from: [00007e70,00017c80) to [076f01f0,07700000)
Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N

Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
Trying to allocate 1 kB of base memory, 638 kB free
Hunting for pixies...found !PXE at 0009de0...ok
UNDI API call 0x0000 failed with status 0x006a
Hunting for pixies...none found
Hunting for ROMs...found 55AA at 000e0000...PCI:8086:1031...ok
ROM contains IBA 4.0.22 Slot 0140 by Intel Corporation
Located UNDI ROM supporting revision 2.1.0
Trying to allocate 9 kB of base memory, 637 kB free
Trying to allocate 38 kB of base memory, 628 kB free
Installing UNDI driver code to 9d00:0000, data at 9380:0000
UNDI driver created a pixie at 9d00:0070...ok
API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
0000:5f86
Initialized UNDI NIC with IO 0x7000, IRQ 11, MAC 00:00:E2:8C:5F:43
NDIS type DIX+802.3 interface at 100 Mbps
Searching for server (DHCP)...
Trying to allocate 2 kB of base memory, 590 kB free
..Me: 192.168.0.3, Server: 192.168.0.1
Loading 192.168.0.1:/tftpboot/lts/eb-5.1.8cvs-undi.nbi...(NBI)segment 
[00093E00, 000094000) overlaps used basemem [00093000, 000A0000)
error: not a valid image
Unable to load file.
<sleep>

This was with an etherboot NBI.

> This should print out diagnostic messages about base memory allocation,
> which will help us see what is going on.  It's possible (likely) that the
> !PXE structure from the first attempt is not being freed properly and so
> the second time round it loads it much lower in base memory than it would
> normally.  The alternative is that your UNDI driver is huge, in which
> case you will need to create an image that doesn't need to tread on that
> area of memory.

Do you know a way to get the size of the UNDI driver?

> > Then I tried chaining from Etherboot, and the result is:
>
> It's not seeing the PXE ROM.  Do you have LAN enabled as part of the BIOS
> boot sequence?  I have found that some BIOSes (or possibly some PXE ROMs)
> will hide the PXE ROM if LAN is not listed as a BIOS boot device.

It was enabled, but not the first option. If I do PXE -> Etherboot(eepro100) 
-> Etherboot(undi) the undi driver behaves exactly as it does when loading 
directly from PXE.
The BIOS of this machine is even worse: It seems that the PXE ROM is not 
shown unless it was successfully executed.


Georg

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

On Sat, 31 May 2003, Georg Baum wrote:
> > > I did, but it did not work (cvs from today). The PXE implementation is
> > > Intel Boot Agent Version 4.0.22, the NIC is an onboard eepro100. Here
> > > are the messages:
> > > PXE loader for etherboot
> > > 0x27EK low memory
> > >  PXE    unloaded
> > > ROM segment 0x000 length 0x000 reloc 0x00020000
> Is this         ^            ^
> correct?

I think that's normal when Etherboot doesn't boot from ROM.

> > Can you try enabling DEBUG_BASMEM in arch/i386/firmware/pcbios/basemem.c?
> I did. The result:
> PXE loader for etherboot
> 0x27EK low memory
>  PXE    unloaded
> ROM segment 0x000 length 0x000 reloc 0x00020000
> Etherboot 5.1.8 (GPL) Tagged ELF for [UNDI]
> Relocating _text from: [00007e70,00017c80) to [076f01f0,07700000)
> Boot from (N)etwork (D)isk (F)loppy or from (L)ocal? N
> Probing pci nic...
> [UNDI]Hunting for PnP BIOS...found $PnP at f000:6e20...ok
> Trying to allocate 1 kB of base memory, 638 kB free

Your BIOS has a 2kB Extended BIOS Data Area, which is what is occupying 
the top 2 kB of base memory.  Nothing to worry about yet, and it shows 
that the memory allocated to the PXE driver that loaded Etherboot has been 
freed.

The 1kB allocated here is for real-mode parameter structures used by the 
Etherboot UNDI driver in making UNDI API calls.

> Hunting for pixies...found !PXE at 0009de0...ok

Whoops, this is in an area of base memory marked as free.  (This is the 
"PXE loader not trashing !PXE structure" problem.)

I've added a check to the routine that scans for !PXE structures ("hunts 
for pixies") - it will now give a warning and ignore any valid !PXE 
structures found in free base memory.

> UNDI API call 0x0000 failed with status 0x006a
> Hunting for pixies...none found
> Hunting for ROMs...found 55AA at 000e0000...PCI:8086:1031...ok
> ROM contains IBA 4.0.22 Slot 0140 by Intel Corporation
> Located UNDI ROM supporting revision 2.1.0
> Trying to allocate 9 kB of base memory, 637 kB free
> Trying to allocate 38 kB of base memory, 628 kB free

OK, this looks like the problem.  Your UNDI driver (the one in ROM) needs 
to be given 9kB for its code segment and 38kB(!) for its data segment.  
There's no way around this; these are values hard-coded into the PXE ROM.

> Installing UNDI driver code to 9d00:0000, data at 9380:0000
> UNDI driver created a pixie at 9d00:0070...ok
> API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
> 0000:5f86
> Initialized UNDI NIC with IO 0x7000, IRQ 11, MAC 00:00:E2:8C:5F:43
> NDIS type DIX+802.3 interface at 100 Mbps
> Searching for server (DHCP)...
> Trying to allocate 2 kB of base memory, 590 kB free

This is the last memory allocation that takes place.  It's for the 
transmit buffer; Etherboot needs to copy the data to be transmitted into 
base memory so that it can be passed to the real-mode UNDI API call.

> ..Me: 192.168.0.3, Server: 192.168.0.1
> Loading 192.168.0.1:/tftpboot/lts/eb-5.1.8cvs-undi.nbi...(NBI)segment 
> [00093E00, 000094000) overlaps used basemem [00093000, 000A0000)
> error: not a valid image
> Unable to load file.
> <sleep>
> This was with an etherboot NBI.

The conclusion is that you have the following demands on base memory:

 2 kB BIOS data area
 1 kB Etherboot real-mode API call parameter area
 9 kB PXE UNDI driver code segment
38 kB PXE UNDI driver data segment
 2 kB Etherboot real-mode API call transmit buffer area

52 kB total

This 52kB is at the top of base memory and so occupies the addresses 
[00093000, 000A0000).  The image you are trying to load wants to be loaded 
into this area, but this is not possible.

The only solution is to create an image that doesn't want to be loaded 
into this area.  I believe it's possible for mknbi to create images that 
load elsewhere - Ken?

> > This should print out diagnostic messages about base memory allocation,
> > which will help us see what is going on.  It's possible (likely) that the
> > !PXE structure from the first attempt is not being freed properly and so
> > the second time round it loads it much lower in base memory than it would
> > normally.  The alternative is that your UNDI driver is huge, in which
> > case you will need to create an image that doesn't need to tread on that
> > area of memory.
> Do you know a way to get the size of the UNDI driver?

You can see it in the line

  API 9d00:0106 St 8c40:0800 UD 9380:94b0 UC 9d00:2050 BD 0000:3930 BC 
  0000:5f86

This breaks down as:

API entry point 9d00:0106
Real-mode stack 8c40:0000 to 8c40:0800 (ignored)
UNDI driver data segment 9380:0000 to 9380:94b0
UNDI driver code segment 9d00:0000 to 9d00:2050
Base code data segment unused (0000:xxxx)
Base code code segment unused (0000:xxxx)

From this you can see the size of the UNDI driver segments: data is 0x94b0
bytes = 37.2 kB, code is 0x2050 bytes = 8.1 kB.  BIOS memory allocation 
has a granularity of 1 kB so these are rounded up to 38 kB and 9 kB.

> > > Then I tried chaining from Etherboot, and the result is:
> > It's not seeing the PXE ROM.  Do you have LAN enabled as part of the BIOS
> > boot sequence?  I have found that some BIOSes (or possibly some PXE ROMs)
> > will hide the PXE ROM if LAN is not listed as a BIOS boot device.
> It was enabled, but not the first option. If I do PXE -> Etherboot(eepro100) 
> -> Etherboot(undi) the undi driver behaves exactly as it does when loading 
> directly from PXE.
> The BIOS of this machine is even worse: It seems that the PXE ROM is not 
> shown unless it was successfully executed.

I don't know what we can do about that; I'm not sure how Option ROMs can 
hide themselves.  Any ideas?

Michael

Re: [Etherboot-developers] UNDI driver

[Georg B. <gb...@us...>]

Am Samstag, 31. Mai 2003 16:22 schrieb Michael Brown:
> This 52kB is at the top of base memory and so occupies the addresses
> [00093000, 000A0000).  The image you are trying to load wants to be
> loaded into this area, but this is not possible.
>
> The only solution is to create an image that doesn't want to be loaded
> into this area.  I believe it's possible for mknbi to create images that
> load elsewhere - Ken?

I tried mknbi with --relocseg 0x8000, and it works! Really nice work, and 
thanks very much for the nice explanations Michael!

> > > It's not seeing the PXE ROM.  Do you have LAN enabled as part of the
> > > BIOS boot sequence?  I have found that some BIOSes (or possibly some
> > > PXE ROMs) will hide the PXE ROM if LAN is not listed as a BIOS boot
> > > device.
> >
> > It was enabled, but not the first option. If I do PXE ->
> > Etherboot(eepro100) -> Etherboot(undi) the undi driver behaves exactly
> > as it does when loading directly from PXE.
> > The BIOS of this machine is even worse: It seems that the PXE ROM is
> > not shown unless it was successfully executed.
>
> I don't know what we can do about that; I'm not sure how Option ROMs can
> hide themselves.  Any ideas?

I don't know. Since the UNDI driver found the ROM when PXE was executed 
before and did not find it when it was enabled but not executed, I thought 
that in this case the BIOS did not show the PXE ROM, but this may be wrong.
But never mind, this BIOS is broken anyway (I have two menus where I can 
alter the boot sequence, one called something with "Network" and the other 
"Boot". It seems that the selected options in both must be identical).


Georg

[Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

I have checked the UNDI driver from 5.1 in to 5.3 CVS.  It compiles 
without problems, but I haven't yet tested it.  I have some new PXE NICs 
with which to test it and I'm expecting to make some changes over the next 
few days.

Not sure whether to add it to 5.2 or wait until it's working with a wider 
variety of cards.

Michael

Re: [Etherboot-developers] UNDI driver

[Marty C. <ma...@et...>]

On Thursday, October 9, 2003, at 12:56  PM, Michael Brown wrote:
> I have checked the UNDI driver from 5.1 in to 5.3 CVS.  It compiles
> without problems, but I haven't yet tested it.  I have some new PXE 
> NICs
> with which to test it and I'm expecting to make some changes over the 
> next
> few days.

Many thanks, Michael. I'll plan to try it this weekend, along with a 
rom-o-matic.net update.

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...@et...
     Web: http://www.etherboot.org/

Re: [Etherboot-developers] UNDI driver

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> There is now a very-nearly working UNDI driver in 5.1 CVS under
> arch/i386/drivers/net.  This driver allows Etherboot to work with any NIC
> for which an UNDI option ROM is provided.
> 
> The driver does not require Etherboot to be started by chaining from PXE;  
> it will scan for an UNDI ROM and initialise it fully from scratch.  I have
> been testing by booting from floppy, which works fine.  I imagine that 
> PXE-chaining would also work, although I haven't tested it yet.
> 
> Note that you cannot yet use the Etherboot UNDI driver to actually boot a
> kernel;  although all the routines are working and the driver can get a
> DHCP lease and start downloading a file, it dies instantly because the
> downloaded file stomps right over the PXE UNDI driver.  In order to fix 
> this, I need to sort out a method for allocating base memory in Etherboot.
> 
> Question 1: Is there currently any method for allocating base memory?  I
> need space for three structures:

Memory should be taken off of the TOP of the 640K chunk of memory.
That is the only way ancient DOS memory reporting APIs can cope.

And in etherboot that should not be hard to report.  We might want to
think of bounce buffers to hold data that will eventually go there.

Losing 128K of memory will have some interesting affects on mknbi and
friends.

> 1. The PXE UNDI driver code segment (up to 64K, probably 16K)
> 2. The PXE UNDI driver data segment (up to 64K, probably 16K)
> 3. Temporary buffers that I can stick data into while calling the 
>    real-mode UNDI API (about 2-3K).

Plan on the UNDI drivers taking 64K the ones for at least
Broadcom's gigabit NIC almost certainly will.

For the temporary can you just use real_call and a buffer allocated on
the stack?  It has provisions for coping with data left on the return
stack.   This does not solve the issue but it means we only need the
temporary stack.

> I'm currently (as a quick "test-the-driver" method) dumping these at
> pseudo-random places in base memory, which works fine up to the point that
> a kernel image loads...  :-)
> 
> 
> Question 2: I have an assembly routine _undi_call that is a wrapper around 
> the real-mode UNDI API calls.  

Does _undi_call use real_call?

> I've placed this in pcbios.S but haven't 
> yet checked it in because it seems like a bad place to put it; it would 
> end up being compiled in to every Etherboot image, not just the UNDI one.  
> Ideally, I'd like to create a file undi_wrapper.S in 
> arch/i386/drivers/net and have this linked in.  I suspect I'm going to 
> have to edit genrules.pl to achieve this, unless anyone can suggest a 
> quick and easy method?

The big question is how small is undi_call?  If it is small enough
placing it pcbios.S may make sense.  As it could be packed into some
of the space usually used for alignment or what not.  But I do see
the point, if it has size putting it in every driver is probably
worse.

Eric

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

> > Question 1: Is there currently any method for allocating base memory?  I
> > need space for three structures:
> Memory should be taken off of the TOP of the 640K chunk of memory.
> That is the only way ancient DOS memory reporting APIs can cope.
> And in etherboot that should not be hard to report.  We might want to
> think of bounce buffers to hold data that will eventually go there.

OK, but am I right in thinking that there is currently no mechanism for 
doing this in Etherboot?  I remember HPA mentioning code in MEMDISK that 
could be ripped out for this purpose.

> Losing 128K of memory will have some interesting affects on mknbi and
> friends.

It won't always be 128K; the UNDI driver specifies how much space it needs 
for its code and data segments, so we can allocate only what's necessary.

> For the temporary can you just use real_call and a buffer allocated on
> the stack?  It has provisions for coping with data left on the return
> stack.   This does not solve the issue but it means we only need the
> temporary stack.

The largest chunk of data I need is the whole transmit buffer; I need to 
make this available to the real-mode UNDI API transmit call, which AFAIK 
means copying it into base memory.  Is there enough room for this on the 
stack and, if so, can you give me some pointers on how it works?  I'll 
need to know the addresses of the structures before going into the 
assembler code, otherwise my assembler wrappers will have to be 
significantly more complex.

> > Question 2: I have an assembly routine _undi_call that is a wrapper around 
> > the real-mode UNDI API calls.  
> Does _undi_call use real_call?

Yes.  I've checked in the code to pcbios.S temporarily, so that (a) people 
can build and test the driver and (b) you can see exactly what the wrapper 
currently does.

Please note that I've basically learnt x86 assembler over the past four 
days, so there's bound to be a much simpler way of doing it.

> The big question is how small is undi_call?  If it is small enough
> placing it pcbios.S may make sense.  As it could be packed into some
> of the space usually used for alignment or what not.  But I do see
> the point, if it has size putting it in every driver is probably
> worse.

It's tiny; just a small wrapper around real_call.  I pass in a structure
that contains the address of the UNDI API routine and 3 words to push onto
the stack before making the API call.  _undi_call just switches to real 
mode, pushes the parameters onto the stack, jumps to the specified 
address, cleans up the stack and returns.  It's not far away from being a 
generic "call any real-mode routine" wrapper.  (It might be handy to have 
one of these, thinking about it.)

Michael

Re: [Etherboot-developers] UNDI driver

[H. P. A. <hp...@zy...>]

Michael Brown wrote:
>>>Question 1: Is there currently any method for allocating base memory?  I
>>>need space for three structures:
>>
>>Memory should be taken off of the TOP of the 640K chunk of memory.
>>That is the only way ancient DOS memory reporting APIs can cope.
>>And in etherboot that should not be hard to report.  We might want to
>>think of bounce buffers to hold data that will eventually go there.
> 
> 
> OK, but am I right in thinking that there is currently no mechanism for 
> doing this in Etherboot?  I remember HPA mentioning code in MEMDISK that 
> could be ripped out for this purpose.
> 

There are two things: reserving low (DOS) memory, which is just a matter 
of poking a variable in low memory, and reserving high memory, which is 
a matter of hooking INT 15h and and intercepting the AX=88h, AX=E801h, 
AX=E881h and AX=E820h calls.  The latter is quite complex, especially 
since the E820h memory map is frequently insane in various ways.

MEMDISK contains code to read out the memory map, canonicalize it, and 
provide the INT 15h hooks.

	-hpa

Re: [Etherboot-developers] UNDI driver

[<ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> > > Question 1: Is there currently any method for allocating base memory?  I
> > > need space for three structures:
> > Memory should be taken off of the TOP of the 640K chunk of memory.
> > That is the only way ancient DOS memory reporting APIs can cope.
> > And in etherboot that should not be hard to report.  We might want to
> > think of bounce buffers to hold data that will eventually go there.
> 
> OK, but am I right in thinking that there is currently no mechanism for 
> doing this in Etherboot?  I remember HPA mentioning code in MEMDISK that 
> could be ripped out for this purpose.

There are 2 cases of interest.
1) Code using etherboot as a library
2) Etherboot using an UNDI driver.

Unless an UNDI driver is allowed to allocate memory for itself
we don't need the code in MEMDISK.  That code is only needed
if we are not going to sever as a library.

In etherboot we currently keep track of which memory is available for
allocation.  See the e820 structure and it's kin.  We refuse
to step on any memory that is listed as used.

As for bounce buffers it would simply take a specialized memcpy to
use in osloader.c  

We currently have routines to allocate memory in a general fashion
but the heap is placed above 1M.   So we call allocate bounce
buffers but the below 1M case still needs to be handled.  It should
be relatively straight forward however.

> > Losing 128K of memory will have some interesting affects on mknbi and
> > friends.
> 
> It won't always be 128K; the UNDI driver specifies how much space it needs 
> for its code and data segments, so we can allocate only what's necessary.

Agreed.  I am just thinking we will need to make certain it works when
we allocate 128K.

The important point is that low addresses especially those below
1M are precious because the loaded image can count on them being
available.
 
> > For the temporary can you just use real_call and a buffer allocated on
> > the stack?  It has provisions for coping with data left on the return
> > stack.   This does not solve the issue but it means we only need the
> > temporary stack.
> 
> The largest chunk of data I need is the whole transmit buffer; I need to 
> make this available to the real-mode UNDI API transmit call, which AFAIK 
> means copying it into base memory.  Is there enough room for this on the 
> stack and, if so, can you give me some pointers on how it works? 

Ok.  I have something that works for returning data in real_call
but I don't have a parameter for passing extra data on the stack.
That probably would not be too hard but I can certainly see the
value in just allocating a buffer from the top of low memory.

Since we are already allocating relatively fixed buffers it should
not be hard to allocate one more.

> I'll 
> need to know the addresses of the structures before going into the 
> assembler code, otherwise my assembler wrappers will have to be 
> significantly more complex.
> 
> > > Question 2: I have an assembly routine _undi_call that is a wrapper around 
> > > the real-mode UNDI API calls.  
> > Does _undi_call use real_call?
> 
> Yes.  I've checked in the code to pcbios.S temporarily, so that (a) people 
> can build and test the driver and (b) you can see exactly what the wrapper 
> currently does.
> 
> Please note that I've basically learnt x86 assembler over the past four 
> days, so there's bound to be a much simpler way of doing it.
> 
> > The big question is how small is undi_call?  If it is small enough
> > placing it pcbios.S may make sense.  As it could be packed into some
> > of the space usually used for alignment or what not.  But I do see
> > the point, if it has size putting it in every driver is probably
> > worse.
> 
> It's tiny; just a small wrapper around real_call.  I pass in a structure
> that contains the address of the UNDI API routine and 3 words to push onto
> the stack before making the API call.  _undi_call just switches to real 
> mode, pushes the parameters onto the stack, jumps to the specified 
> address, cleans up the stack and returns.  It's not far away from being a 
> generic "call any real-mode routine" wrapper.  (It might be handy to have 
> one of these, thinking about it.)

1) A generic "call any real-mode routine" wrappers suffers from 2
things.  That handling the segment:offset addressing is a pain.
That there are different calling conventions in the dos world.

2) real_call is as close to fully generic as you can get and not
address those issues.

3) a generic interface for the calling convention used in the undi
code would be fine.  Then you can make cute little stubs for the
undi entry points in your driver.

Hopefully I have pointed you enough in the correct direction for
a while.

Eric

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

> In etherboot we currently keep track of which memory is available for
> allocation.  See the e820 structure and it's kin.  We refuse
> to step on any memory that is listed as used.
> <snip>
> We currently have routines to allocate memory in a general fashion
> but the heap is placed above 1M.   So we call allocate bounce
> buffers but the below 1M case still needs to be handled.  It should
> be relatively straight forward however.
> <snip>
> The important point is that low addresses especially those below
> 1M are precious because the loaded image can count on them being
> available.

An image loading via PXE would not be able to count on them being
available; PXE drivers expect to be placed at the top of base memory.  By
using up base memory in the case of the Etherboot UNDI driver, we're doing
no worse than PXE does.  We don't have a choice about loading the UNDI
driver under 1M; some of the API calls have to be made in real mode.

I'm proposing the following solution, based on discussion thus far:

1. Add arch/i386/firmware/pcbios/basemem.c, #ifdeffed with PCBIOS, 
   containing routines to allocate base memory in the BIOS-expected way 
   (i.e. by simply updating the value at 40:13).

2. Add a check in prep_segment() in core/osloader.c, also #ifdeffed with
   PCBIOS, that will check that the segment being prepared doesn't overlap 
   the BIOS allocated low memory area.

3. The Etherboot UNDI driver will allocate space for the UNDI driver's 
   code and data segments in base memory, which is where it expects to be 
   put.  These have to go under 1M anyway; they are used in real mode.

4. The Etherboot UNDI driver will also allocate ETH_FRAME_LEN bytes of 
   base memory for the real-mode transmit buffer, plus a few tens of bytes 
   for structures like the UNDI API call parameter structure and the UNDI 
   transmit buffer descriptor.

Total base memory usage will be around 2K + UNDI driver data segment + 
UNDI driver code segment.

> > It's tiny; just a small wrapper around real_call.  I pass in a structure
> > that contains the address of the UNDI API routine and 3 words to push onto
> > the stack before making the API call.  _undi_call just switches to real 
> > mode, pushes the parameters onto the stack, jumps to the specified 
> > address, cleans up the stack and returns.  It's not far away from being a 
> > generic "call any real-mode routine" wrapper.  (It might be handy to have 
> > one of these, thinking about it.)
> 1) A generic "call any real-mode routine" wrappers suffers from 2
> things.  That handling the segment:offset addressing is a pain.
> That there are different calling conventions in the dos world.
> 2) real_call is as close to fully generic as you can get and not
> address those issues.
> 3) a generic interface for the calling convention used in the undi
> code would be fine.  Then you can make cute little stubs for the
> undi entry points in your driver.

(3) is what we've got at the moment.  For the sake of elegance, I'm 
proposing to split the tiny _undi_call routine into a separate 
undi_wrapper.S file and modify the Makefiles in some way to accommodate 
this.

Final comments / suggestions welcome; coding will probably happen this 
evening (UK time).

Michael

Re: [Etherboot-developers] UNDI driver

[Michael B. <mb...@fe...>]

> 1. Add arch/i386/firmware/pcbios/basemem.c, #ifdeffed with PCBIOS, 
>    containing routines to allocate base memory in the BIOS-expected way 
>    (i.e. by simply updating the value at 40:13).

This is now in place.  I had great fun tracking down why my allocated 
memory was being trodden on every time I did a printf().  Eventually 
discovered that get_memsizes() resets the position of the real mode stack 
to be the top of free base memory, which meant that my allocated base 
memory was being written all over as soon as _real_call got called.  Now 
fixed in that I adjust real_mode_stack each time I allocate or free 
memory.

Question: is there any reason why _real_call can't just calculate the 
stack base each time (by reading 40:13)?  (This would work with PCBIOS, 
but I don't know about LinuxBIOS.)

Michael