Etherboot

On Wednesday, March 2, Michael Brown wrote:
> 
> You're asking us to do something that's not theoretically possible.

Now that I think about it, this is largely true.  Coffee had not kicked
in when I wrote the previous...


> Your BIOS is also broken, in that case.  Not that broken BIOSes are 
> unusal.  :)

Yes, broken biosen are common.  However, I've been doing this for the
better part of, well since the 80286 and 80386DX came on the scene.  In
most biosen that I've seen, the limits in real mode are not 64K.

I have seen more than one bios break if you feed them 64K limits.


> Etherboot is not broken.  I agree that the whole concept of 16-bit
> real-mode is inherently broken, but that's a whole different rant.

Unfortunately, in this case it is.  :-)  I suppose we could argue semantics
forever.  Anyways, in general, I doubt a non-64K limit real mode selector
will cause you any sort of great trouble, but may prevent future pain on
other fronts.


> Whenever Etherboot makes real-mode calls (e.g. to read from the keyboard),
> we are paranoid and make sure to load and activate a GDT from a
> real-mode-addressable location before attempting to access anything over a
> 64kB offset.  There's no viable alternative.  OpenBSD needs to adopt this
> approach.  It's an intrinsic limitation of the x86; you can't get around
> it.

That is what we will be doing in the future.  Not to be more correct, but
to be more paranoid.  We'll still be using the non-64K limit real mode
segments, along with 64K limit paranoid offsets in instructions.

--Toby.

Michael Brown wrote:
> 
> As I understand it, the process goes as follows:
> 
>   pxeboot loads a GDT for a flat memory model with 4GB limits
> 
>   pxeboot loads the segment registers with selectors referencing this GDT.  
>   The segment registers therefore end up with 4GB limits.
> 
>   ...
> 
>   pxeboot switches the CPU into real mode the quick way (without first
>   loading special "about to switch to real mode" protected-mode selectors
>   into the segment registers to set 64kB limits).  The selector portions
>   of the segment registers are overwritten with real-mode selectors; the
>   limit portions remain unchanged at 4GB.
> 
>   pxeboot calls into the PXE stack (via the !PXE entry point)
> 

AAAAAAAAAAAAAAAAAAAAAAAAAAARGH!!!!!!!!!!!!!!!!!!!!!!!

That is absolutely BAD, BAD, BAD, BAD!

	-hpa

Joyce Yu - System Software wrote:
> Tim,
> 
> The driver is still in prototype stage. I need to solve the following two 
> problems before putback to the cvs.
> 
> .. How to get MAC address from the current expansion rom's VPD data structure. 
> The current expansion rom has open firmware's fcode image in it. I hard coded 
> the MAC address right now. It shouldn't take me to long to figure it out. (There 
> is no eeprom on all of our released NIC products)

Sorry, I won't be much help for this.  I assume you have to find the 
option rom in memory and then read the mac address but I am not sure.

> .. How to create a rom image with both fcode and etherboot images on it. The 
> system will load fcode image for SPARC system, and load etherboot image for X86 
> system. I need some help on this issue. I know there is a 'Code Type' field in 
> the expansion rom's data structure to distinguish the SPARC and x86. But I don't 
> have enough knowledge to solve the issue.

It might be just easier to port Etherboot to Sparc.  ;-)  Someone on the 
list may know the intricate details of how the expansion rom works.

You can still send the driver as is but I know the feeling of wanting it 
to work correctly first.  There is a good many times I have almost had a 
driver completely working, broke it and wished the earlier version was 
in cvs...;-(

Tim

> ->From: Timothy Legge <tlegge@...>
> ->Subject: RE: [Etherboot-developers] help
> ->To: Joyce Yu - System Software <Joyce.Yu@...>
> ->Cc: timothy.legge@..., stappers@..., Etherboot developers list 
> <etherboot-developers@...>
> ->MIME-version: 1.0
> ->Content-transfer-encoding: 7BIT
> ->Original-recipient: rfc822;Joyce.Yu@...
> ->
> ->On Thu, 2005-02-24 at 16:50 -0800, Joyce Yu - System Software wrote:
> ->> Tim,
> ->> 
> ->> It is working now !! I did run into the descriptor ring filled and not being 
> ->> freed problem. Thanks for all the help and advice.
> ->> 
> ->> Thanks,
> ->> Joyce
> ->
> ->That's fabulous, I am looking forward to seeing a patch/driver file make
> ->its way to the list.  
> ->
> ->I don't remember if we have offered you developer access to the cvs yet
> ->but if not, all you need is a sourceforge account.  Just let us know if
> ->you want access (and your account name).  If I remember correctly you
> ->plan on a couple of drivers so developer cvs access would probably be
> ->needed.
> ->
> ->Regards
> ->
> ->Tim
> ->
> ->
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers@...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

On Tue, 1 Mar 2005, Joyce Yu - System Software wrote:
> . How to create a rom image with both fcode and etherboot images on it.
> The system will load fcode image for SPARC system, and load etherboot
> image for X86 system. I need some help on this issue. I know there is a
> 'Code Type' field in the expansion rom's data structure to distinguish
> the SPARC and x86. But I don't have enough knowledge to solve the issue.

You want to look at page 228 in version 2.2 of the PCI specification.  
Immediately following the "Code Type" field is a field called "Indicator", 
which indicates whether or not this is the last image in the ROM.

I think you just put two separate images in the same ROM, then set bit 7 
of the "Indicator" field in the first image to zero.  The second image 
will need to be 512-byte aligned, and presumably will need to start 
exactly where the first image ends (according to the "Image Length" 
field for the first image).

HTH,

Michael

On Mon, 28 Feb 2005, Tim Fletcher wrote:
> > FreeBSD 5.3 release: boots the pxeboot stage 1 loader which crashes but
> > I can't get a -DTRACE_PXE dump off this as for some reason the serial
> > output stops as soon as pxeboot starts to execute. I have a photo of the
> > crash in case anyone on the list is interested. The same setup using the
> > hardware PXE ROM works. 
> 
> I remembered today that OpenBSD have added pxeboot recently (well about
> 9 months ago but :), so I thought I should test that too.
> 
> The first stage loader downloads successfully and starts to execute but
> then hangs, after printing out "pxe![2.1]" the next bit that prints if I
> boot off a rom is "mem[639K 255M a20=on]. I have built etherboot with
> tracepxe but again this doesn't seem to produce any output. 

I'd recommend bochs for testing this sort of thing.  Can you send me the 
file /openbsd/pxeboot?  Also, if you happen to have a direct link to the 
source code for this file, it would save me tracking it down.

Michael

On Tue, 2005-03-01 at 02:12, Michael Brown wrote:

> I'd recommend bochs for testing this sort of thing.  Can you send me the 
> file /openbsd/pxeboot?  Also, if you happen to have a direct link to the 
> source code for this file, it would save me tracking it down.

I'll try and give it a go with bochs later on today but here are links
to the various bits of openbsd pxeboot:

Current CVS source (doesn't seem to have been any changes to this in a
while)
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/stand/pxeboot/

The binary I was trying to boot: (from 3.6)
ftp://ftp.openbsd.org/pub/OpenBSD/3.6/i386/pxeboot

The man page for pxeboot:
http://www.openbsd.org/cgi-bin/man.cgi?query=pxeboot&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

-- 
Tim Fletcher 
Learning Technologies Manager - Parrs Wood Technology College

tim@...

Tel: 0161 448 0361

Tim Fletcher 
C/O Parrs Wood Technology College
Wilmslow Road
Manchester
M20 5PG

On Sun, Feb 27, 2005 at 03:36:43PM +0000, Tim Fletcher wrote:
 <snip/>
> I suspect that RIS is trying to hook something out of the rom
> environment that tells it about the Intel network card and is getting
> confused.
In Dutch we call "vendor lock in" the single word for it.


GSt

On Tue, 1 Mar 2005, Tim Fletcher wrote:
> > I'd recommend bochs for testing this sort of thing.  Can you send me
> > the file /openbsd/pxeboot?  Also, if you happen to have a direct link
> > to the source code for this file, it would save me tracking it down.
> 
> I'll try and give it a go with bochs later on today but here are links
> to the various bits of openbsd pxeboot:

Thanks for the links.  It was remarkably straightforward to track down.  
bochs is a piece of software that I just keep getting more impressed with, 
not least because of the accuracy of its x86 emulation even under obscure 
error conditions.

Enabling -DTRACE_PXE gave me

  Me: 10.254.254.1, DHCP: 10.254.254.2, TFTP: 10.254.254.2, Gateway 10.0.0.6
  Loading 10.254.254.2:pxeboot ...(PXE).....................................done
  probing: pc0 com0 pci pxe![2.1][PXENV_GET_CACHED_INFO 3]

and an immediate lockup.  bochs showed the CPU quite literally stuck at
the real-mode address 4012:403c; attempting to single-step to the next
instruction would not advance the program counter.

I added a BOCHSBP instruction in _pxe_in_call_far in realmode_asm.S and
examined the cpu state on entry to the first PXE API call
(PXENV_GET_CACHED_INFO), then stepped over the API call and started
single-stepping back into pxeboot.  Five instructions later, I hit the 
lockup point at 4012:403c.  The instruction causing the problem is:

  addrsize opsize lgdt [ds:0x45e80]

which is the line marked "Load the GDT" in the following code from 
pxe_call.S in the OpenBSD source:

  /*
   * real_to_prot()
   *
   * Switch the processor back into protected mode.
   */
	  .globl	real_to_prot
  real_to_prot:
	  .code16

	  xorw	%ax, %ax
	  movw	%ax, %ds		/* Load %ds so we can get at Gdtr */
	  data32 addr32 lgdt Gdtr	/* Load the GDT */
          ...

Note the address [ds:0x45e80] that this resolves to in the pxeboot binary.  
In particular, note that the offset contains five hexadecimal digits.  
We're allegedly in real-mode at this point.  We can't access more than 64k
in each segment, yet this instruction is trying to access data at an
offset of approximately 279k.  The CPU doesn't like this.

I suspect that OpenBSD's pxeboot cheats and switches into flat real mode
(with 4GB limits) rather than genuine real mode (with 64kB limits).  It
probably assumes that the PXE stack will not perform any mode switching,
and so assumes that when the PXE API call returns the CPU will still be in
flat real mode, and that it can get away with using addresses like
%ds:0x45e80.  It shouldn't make this assumption.

Etherboot transitions into protected mode and back again whenever a PXE
API call is made.  It exits in genuine real mode (64kB limits).  Callers
should assume that this is the mode of the CPU upon exit from the PXE API
call (since callers are supposed to make the PXE API call in genuine real
mode).

The following patch to arch/i386/core/realmode_asm.S works around the 
problem by changing Etherboot's real-mode GDT to be a flat real-mode GDT 
instead of a genuine real-mode GDT:

--- arch/i386/core/realmode_asm.S       3 Feb 2005 08:34:57 -0000   1.12
+++ arch/i386/core/realmode_asm.S       1 Mar 2005 19:55:15 -0000
@@ -371,11 +371,11 @@
 p2r_rmcs:
        /* 16 bit real mode code segment */
        .word   0xffff,(0&0xffff)
-       .byte   (0>>16),0x9b,0x00,(0>>24)
+       .byte   (0>>16),0x9b,0x80,(0>>24)
 p2r_rmds:
        /* 16 bit real mode data segment */
        .word   0xffff,(0&0xffff)
-       .byte   (0>>16),0x93,0x00,(0>>24)
+       .byte   (0>>16),0x93,0x80,(0>>24)
 p2r_gdt_end:

        /* This is the end of the trampoline prefix code.  When used


With this patch, I get as far as:

  Me: 10.254.254.1, DHCP: 10.254.254.2, TFTP: 10.254.254.2, Gateway 10.0.0.6
  Loading 10.254.254.2:pxeboot ...(PXE).....................................done
  probing: pc0 com0 pci pxe![2.1] mem[639K 29M a20=on]
  disk: fd0 fd1
  net: mac fe:fd:00:00:00:01, ip 10.254.254.1, server 10.254.254.2
  >> OpenBSD/i386 PXEBOOT 1.00
  boot>
  booting tftp:/bsd: open tftp:/bsd: No such file or directory
   failed(2). will try /obsd
  boot>
  booting tftp:/obsd: open tftp:/obsd: No such file or directory
   failed(2). will try /bsd.old
  boot>
  booting tftp:/bsd.old: open tftp:/bsd.old: No such file or directory
   failed(2). will try /bsd
  boot>
  booting tftp:/bsd: open tftp:/bsd: No such file or directory
   failed(2). will try /obsd
  boot>
  booting tftp:/obsd: open tftp:/obsd: No such file or directory
   failed(2). will try /bsd.old
  boot>
  booting tftp:/bsd.old: open tftp:/bsd.old: No such file or directory
   failed(2). will try /bsd
  Turning timeout off.
  boot>

i.e. it seems to now be working (except that I don't actually have a BSD 
kernel for it to boot, only the pxeboot bootloader itself).

I don't think we should add this patch to Etherboot, because it's OpenBSD
that's broken and the proper solution is to fix OpenBSD.  Do you want to
contact the people responsible for pxeboot and get them involved?

Michael

On Tue, 2005-03-01 at 20:01 +0000, Michael Brown wrote:
> On Tue, 1 Mar 2005, Tim Fletcher wrote:
> > > I'd recommend bochs for testing this sort of thing.  Can you send me
> > > the file /openbsd/pxeboot?  Also, if you happen to have a direct link
> > > to the source code for this file, it would save me tracking it down.
> > 
> > I'll try and give it a go with bochs later on today but here are links
> > to the various bits of openbsd pxeboot:
> 
> Thanks for the links.  It was remarkably straightforward to track down.  
> bochs is a piece of software that I just keep getting more impressed with, 
> not least because of the accuracy of its x86 emulation even under obscure 
> error conditions.
> 
> Enabling -DTRACE_PXE gave me
> 
>   Me: 10.254.254.1, DHCP: 10.254.254.2, TFTP: 10.254.254.2, Gateway 10.0.0.6
>   Loading 10.254.254.2:pxeboot ...(PXE).....................................done
>   probing: pc0 com0 pci pxe![2.1][PXENV_GET_CACHED_INFO 3]

Odd I had -DTRACE_PXE set (and working from the same image when using
RIS) I think that why I have been testing is causing some other problems
to appear. To understand the problems I am seeing a quick explaination
of how I boot etherboot tests:

1. boot a machine off a hardware PXE rom (I have an rtl8139 and a
eepro100 559) 
2. load pxegrub which pulls up my netboot menus giving my various
options
3. boot an etherboot zlilo image which with the magic of dhcpd if
statements gets a different set of information and boots whatever I am
testing. 

If I remove the pxegrub stage and chain etherboot (as a zpxe) straight
from the hardware pxe rom openbsd's pxeboot works fine if I include the
pxegrub stage then openbsd's pxeboot hangs at the same point as it did
before Micheal's patch. 

I'm not quite sure where to go with this but I have removed this from my
testing method at present. I will see if I can get a pxegrub image that
works on bochs (my present one complains about pci) - Micheal would the
pxegrub image I use to do this be of any use to you to test with?

> I suspect that OpenBSD's pxeboot cheats and switches into flat real mode
> (with 4GB limits) rather than genuine real mode (with 64kB limits).  It
> probably assumes that the PXE stack will not perform any mode switching,
> and so assumes that when the PXE API call returns the CPU will still be in
> flat real mode, and that it can get away with using addresses like
> %ds:0x45e80.  It shouldn't make this assumption.

This is a question of specs vs implementations and also bug for bug
compatibility 

> Etherboot transitions into protected mode and back again whenever a PXE
> API call is made.  It exits in genuine real mode (64kB limits).  Callers
> should assume that this is the mode of the CPU upon exit from the PXE API
> call (since callers are supposed to make the PXE API call in genuine real
> mode).
> 
> The following patch to arch/i386/core/realmode_asm.S works around the 
> problem by changing Etherboot's real-mode GDT to be a flat real-mode GDT 
> instead of a genuine real-mode GDT:

<snip patch>

> i.e. it seems to now be working (except that I don't actually have a BSD 
> kernel for it to boot, only the pxeboot bootloader itself).

I can confirm that with this patch and both bochs and real hardware can
get to a openbsd shell with pxeboot as a loader

> I don't think we should add this patch to Etherboot, because it's OpenBSD
> that's broken and the proper solution is to fix OpenBSD.  Do you want to
> contact the people responsible for pxeboot and get them involved?

I agree that this is not something that we might want to do but as at
least the openbsd people rely on it (and there doesn't seem to be any
reports of it breaking either) then others might so I think that it
might be something to enable / disable with the -DPXE_STRICT flag
(assuming you can do that I don't know enough about compilers and make
to know if you can do this with asm)

I have reported the bug to the openbsd bug email address, I'll keep you
posted about progress.

-- 
Tim Fletcher
Learning Technologies Manager - Parrs Wood High School

tim@...

Tel: 0161 445 8786

Tim Fletcher
C/O Parrs Wood High School
Wilmslow Road
Manchester
M20 5PG

On Tue, 2005-03-01 at 22:10 +0000, Tim Fletcher wrote:
> > i.e. it seems to now be working (except that I don't actually have a BSD 
> > kernel for it to boot, only the pxeboot bootloader itself).
> 
> I can confirm that with this patch and both bochs and real hardware can
> get to a openbsd shell with pxeboot as a loader

Also thought it might be worth testing pxeboot from freebsd but the
patch makes no difference still crashes in the same place

-- 
Tim Fletcher
Learning Technologies Manager - Parrs Wood High School

tim@...

Tel: 0161 445 8786

Tim Fletcher
C/O Parrs Wood High School
Wilmslow Road
Manchester
M20 5PG

On Mon, 2005-02-28 at 12:41, Michael Brown wrote:
> I've just added interrupt support (aka PXEfication) to the eepro100 
> driver, then discovered that the on-board card that I thought was an 
> eepro100 is in fact an e1000, and that I don't have any eepro100 cards to 
> test it with.  Could someone who has such a card please try the floppy 
> disk image from
> 
>   http://www.fensystems.co.uk/~mcb30/eepro100.zdsk
> 

I'll give this a go when I get home tonight, also would you like a an
eepro100 or 2? (as I have a number of them spare)

-- 
Tim Fletcher 
Learning Technologies Manager - Parrs Wood Technology College

tim@...

Tel: 0161 448 0361

Tim Fletcher 
C/O Parrs Wood Technology College
Wilmslow Road
Manchester
M20 5PG

I ran a very quick test with an EEPRO100 card, and got the output below.
I note the UNDI driver thinks the link is at 10 mb/s, when I am sure it 
is 100.
I need to play with this some more to run more exhaustive tests, but 
here is some preliminary data.  Please let me know if I can test 
anything else.

Marty

--

Etherboot 5.3.14 (GPL) http://etherboot.org
Drivers: EEPRO100   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP
Relocating _text from: [00010420,00023490) to [0f6ecf90,0f700000)
Boot from (N)etwork or (Q)uit?
Probing pci nic...
[eepro100]Ethernet addr: 00:02:B3:45:EB:99
Searching for server (DHCP).....
Me: 192.168.2.153, DHCP: 192.168.2.64, TFTP: 192.168.2.64, Gateway 
192.168.2.223
Loading 192.168.2.64:/test/undi.zpxe ...(PXE)..................done

Etherboot 5.3.14 (GPL) http://etherboot.org
Drivers: UNDI UNDI   Images: NBI ELF PXE   Exports: PXE
Protocols: DHCP TFTP
Relocating _text from: [0008b410,0009de40) to [0f6da550,0f6ecf80)
Boot from (N)etwork or (Q)uit?
Probing pci nic...
[UNDI]Hunting for PnP BIOS...found $PnP at f000:bf60...ok
Hunting for pixies...found !PXE at 0009f000...ok
API 9f00:0680 St 9e00:1000 UD 9e00:1000 UC 9f00:0ab0 BD 0000:0000 BC 
0000:0000
Resetting pixie...
API 9f00:0680 St 0000:1000 UD 9e00:1000 UC 9f00:0ab0 BD 0000:0000 BC 
0000:0000
Initializing UNDI driver.  Please wait...
Probing pci nic...
[eepro100]Ethernet addr: 00:02:B3:45:EB:99
Initialized UNDI NIC with IO 0xec00, IRQ 11, MAC 00:02:B3:45:EB:99
NDIS type Etherboot interface at 10 Mbps
Searching for server (DHCP)....No IP address
.No IP address
.No IP address


On Feb 28, 2005, at 7:41 AM, Michael Brown wrote:
> I've just added interrupt support (aka PXEfication) to the eepro100
> driver, then discovered that the on-board card that I thought was an
> eepro100 is in fact an e1000, and that I don't have any eepro100 cards 
> to
> test it with.  Could someone who has such a card please try the floppy
> disk image from
>
>   http://www.fensystems.co.uk/~mcb30/eepro100.zdsk
>
> with dhcpd configured to hand out "undi.zpxe" as the filename, and
> undi.zpxe taken from
>
>   http://www.fensystems.co.uk/~mcb30/undi.zpxe
>
> If it works, you should see output along the lines of:
>
>   Etherboot 5.3.14 (GPL) http://etherboot.org
> 1 Drivers: RTL8139   Images: NBI ELF PXE   Exports: PXE
>   Protocols: DHCP TFTP
>   Relocating _text from: [00010420,00023a90) to [0f6ec990,0f700000)
>   Boot from (N)etwork or (Q)uit? N
>
>   Probing pci nic...
>   [rtl8139] - ioaddr 0XEC00, irq 11, addr 00:01:80:34:5E:FD 100Mbps 
> full-duplex
>   Searching for server (DHCP).....
>   Me: 10.0.0.82, DHCP: 10.0.0.6, TFTP: 10.0.0.6, Gateway 10.0.0.1
> 2 Loading 10.0.0.6:undi.zpxe ...(PXE)..................done
>   Etherboot 5.3.14 (GPL) http://etherboot.org
> 3 Drivers: UNDI UNDI   Images: NBI ELF PXE   Exports: PXE
>   Protocols: DHCP TFTP
>   Relocating _text from: [0008b410,0009de40) to [0f6d9f50,0f6ec980)
>   Boot from (N)etwork or (Q)uit? N
>
>   Probing pci nic...
>   [UNDI]Hunting for PnP BIOS...found $PnP at f000:c060...ok
> 4 Hunting for pixies...found !PXE at 0009f000...ok
>   API 9f00:0680 St 9e00:1000 UD 9e00:1000 UC 9f00:0ab0 BD 0000:0000 BC 
> 0000:0000
>   Resetting pixie...
>   API 9f00:0680 St 0000:1000 UD 9e00:1000 UC 9f00:0ab0 BD 0000:0000 BC 
> 0000:0000
>   Initializing UNDI driver.  Please wait...
>   Probing pci nic...
>   [rtl8139] - ioaddr 0XEC00, irq 11, addr 00:01:80:34:5E:FD 100Mbps 
> full-duplex
> 5 Initialized UNDI NIC with IO 0xec00, IRQ 11, MAC 00:01:80:34:5E:FD
>   NDIS type Etherboot interface at 10 Mbps
>   Searching for server (DHCP).....
>   Me: 10.0.0.82, DHCP: 10.0.0.6, TFTP: 10.0.0.6, Gateway 10.0.0.1
> 6 Loading 10.0.0.6:undi.zpxe ...(PXE)..................done
>   Etherboot 5.3.14 (GPL) http://etherboot.org
>   Drivers: UNDI UNDI   Images: NBI ELF PXE   Exports: PXE
>   Protocols: DHCP TFTP
>   Relocating _text from: [00088c10,0009b640) to [0f6c7510,0f6d9f40)
>   Boot from (N)etwork or (Q)uit?
>
> except that your output should say eepro100 instead of rtl8139.  Key
> points are:
>
> 1. eepro100.zdsk loads from floppy disk
>
> 2. eepro100.zdsk downloads undi.zpxe via TFTP
>
> 3. undi.zpxe starts up
>
> 4. undi.zpxe finds the !PXE created by eepro100.zdsk
>
> 5. undi.zpxe initialises the eepro100 card via the Etherboot PXE stack
>    exported by eepro100.zdsk, with IRQ != 0 (i.e. not cheating and 
> using
>    the timer interrupt).
>
> 6. undi.zpxe successfully re-downloads itself from the TFTP server,
>    indicating that packet reception is working.
>
> The combination of packet reception working in stage 6 combined with 
> IRQ
> being non-zero in stage 5 means that the eepro100 driver is 
> successfully
> enabling and acknowledging interrupts.
>
> Thanks in advance to anyone who can test this for me.  Both images are
> compiled with serial console support, so it should be easy to capture 
> the
> output if you need to.
>
> Michael
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Etherboot-developers mailing list
> Etherboot-developers@...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

> I ran a very quick test with an EEPRO100 card, and got the output below.
> I note the UNDI driver thinks the link is at 10 mb/s, when I am sure it 
> is 100.

Thanks for testing it for me.  It looks as though it's not working; the
UNDI driver never receives the DHCP reply which suggests that the receive
interrupt isn't firing properly.

Tim has kindly offered to send me an eepro100, so I should be able to 
debug it myself now.  :)

Michael

Michael Brown <mbrown@...> writes:

> On Tue, 15 Feb 2005, Eric W. Biederman wrote:
> > The strange interrupts chaining to the original BIOS interrupt handler
> > instead of handling the interrupt ourselves is the way to go.  I think
> > that is actually more robust than what we have been doing, but I am may
> > be wrong.  I'm hoping this works out so that when we start seeing
> > systems that don't use the i8259 and instead purely use apics things
> > will continue to work.
> 
> I've just tried using this code.  It doesn't seem to work.  For a start,
> you've taken out all the code that actually enables the interrupts on the
> PIC.  This means that the device interrupts are being ignored.  When I add
> a quick hack outb() to forcibly enable the interrupt I'm interested in, I
> find that you've also removed the interrupt-acknowledging code.  I presume
> you were hoping that the BIOS interrupt handler would acknowledge the
> interrupt, but I can't find any code you've inserted that would cause our
> ISR to actually chain to the BIOS interrupt handler.

Something is confused then. I implemented chaining.  And chaining
is very much something to worry about in the case hardware interrupts are
shared.  Otherwise we have the potential to break something.
 
> Even though I could fix the chaining issue, I don't see any way around the 
> fact that we have to, at some point, write to the PIC in order to enable 
> the relevant interrupt.

This is a good question.  And it lies in the murky land of what does
a traditional BIOS do.  I think all interrupts are enabled by default.
But I have not rigorously verified that.  And if all we need
to do is enable interrupts I am disappointed but I don't object.

> I have reverted the relevant changes to pic8259.[ch], and re-added the 
> interrupt-acknowledging code into undi.c.

We are now in a state where the bug fixes for your setup do not work
for my setup.  
 
> I noticed that while fixing up the UNDI driver to cope with ISA cards, you
> subtly changed the sequence of startup calls.  Given that this was
> previously known to work, but only after a hell of a lot of testing and
> tweaking, and given that there are at least four different initialisation
> paths for the UNDI driver, I have reverted this change as well rather than
> trying to prove to myself that it doesn't make any difference.  I have put
> in an alternative method for coping with ISA cards, but I don't have any
> to test with; could you try yours?

It will probably be a little bit but I will take a look.

As far as I can tell the only thing that moved was START_UNDI.  And that only
because as best I can tell START_UNDI is not appropriate if you are not
acting as the base code.  So I isolated it to the case where we are acting
as the base code.

Not copying the pci structure was:
1) because we only use it at initialization time so there is no need to save it.
2) Because having a copy of the pci data structure stored makes it easy
   get confused about when we actually have pci information.

I do agree we need to be conservative with this code as testing is hard.  However
please let's not fall into the trap that Werner Almesberger did with LILO where
he reached a point he was afraid to touch the code.

Eric

On Mon, 28 Feb 2005, Eric W. Biederman wrote:
> Something is confused then. I implemented chaining.  And chaining is
> very much something to worry about in the case hardware interrupts are
> shared.  Otherwise we have the potential to break something.

Are you sure you checked in all your changes?  I looked in pic8259.c but I
couldn't find anything that filled in the chain_to and chain fields.

I'm not sure that chaining is definitely the way to go.  I have a vague
recollection that the default action, for some interrupts, for some
BIOSes, is to disable the interrupt on the PIC.  This is definitely not
what we want, and it's the main reason why I didn't implement chaining in
the first place.

> This is a good question.  And it lies in the murky land of what does a
> traditional BIOS do.  I think all interrupts are enabled by default.

Unfortunately not in all cases, it seems.

> > I have reverted the relevant changes to pic8259.[ch], and re-added the
> > interrupt-acknowledging code into undi.c.
> We are now in a state where the bug fixes for your setup do not work for
> my setup.

I'd rather keep my setup (which works with commonly-used cards such as
RTL8139 and the standard 8259 PIC plus any APIC that emulates it) rather
than yours (which seems to be specifically for a PC with an obscure PIC
and an old ISA NIC).  Ideally both should be working, but until you can
demonstrate a fix that doesn't break the common case, I'd rather stick
with the current situation.

> As far as I can tell the only thing that moved was START_UNDI.  And that
> only because as best I can tell START_UNDI is not appropriate if you are
> not acting as the base code.  So I isolated it to the case where we are
> acting as the base code.

Which PXE API calls are appropriate at which times is a remarkably black 
art, and the specification doesn't even get close to reality.  PXE 
startup, shutdown and memory allocation/freeing is one part of the code 
that I really would rather not touch unless there's an incredibly good 
reason.

If you can prove that your changes result in the same sequence of API 
calls as before under *all* circumstances (entered via pxeprefix which 
successfully unloaded the PXE stack, entered via pxeprefix which tried to 
unload the PXE stack but failed, entered via pxeprefix which didn't even 
try to unload the PXE stack, entered with no PXE stack in memory, entered 
with an old PXE stack that a previous instance of Etherboot loaded but was 
then unable to free, etc.), then I don't mind the code being changed.  
Otherwise, I won't trust it.

> Not copying the pci structure was:
> 1) because we only use it at initialization time so there is no need to save it.
> 2) Because having a copy of the pci data structure stored makes it easy
>    get confused about when we actually have pci information.

I agree; this makes sense.  However, it's subordinate to the need to not 
alter the PXE API call sequence.  Your change (passing around a struct 
pci_device *) required you to change the call sequence, and therefore 
cannot be done exactly that way for the reasons outlined above.  If you 
can find a method that doesn't involve copying the PCI structure and also 
doesn't involve refactoring any of the code, then I'll be happy.

Michael