etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Re: Etherboot/GRUB driver for eepro100 - problem in understanding !

[Donald J C. <dj...@ci...>]

Christoph Plattner wrote:
> 
> Hello Mr. Yap !
> 
> Is it possible for you email the docus you have. I have to port/
> deveop a driver for the 82559ER for an other UNIX-like system
> and the way with INTEL (non-disclosure agreement) is ongoing,
> but take a while. But I will start now.
> 
> Is it possible for you to send me things, like Developer's Software
> Manual and other important things. In the basics of the 82559 and
> 82559ER are identical....
> 
> ith friendly regards
>         Christoph Plattner

I don't know if there are any docs there, but take a look at the
82559(er) driver at www.scyld.com if you are looking for a full
featured Unix-like driver (as opposed to an embedded ROM-level
driver.)

-Don

--
Don Christensen     Senior Software Development Engineer
  dj...@ci...     MMABU - Mid-Market Access Business Unit
  Cisco Systems    ComLOB - Commercial Line of Business
   San Jose, CA   "It was a new day yesterday, but it's an old day now."

[Etherboot-developers] why does scan_bus() in pci.c ....?

[Eno C. <Eno...@Mi...>]

Dear List

Have been looking at the logic in scan_bus() in pci.c. When it finds an
ethernet controller, it sets up a loop to read through the 6 base address
double words The code in the loop ...

1. reads the indicated base address double word. word 0 first, word 1
second, etc
2. if the base address is zero, the code continues at step 1
3. is the base address refers to memory space (as opposed to i/o space), the
code continues at step 1

Otherwise, the code continues, apparently on the assumption, it has what it
needs. It

4. clears the least significant two bits from the i/o space base address,
and
5. reads base address double word 1 into a cell called membase, and
6. reads the rom base address double word into a cell called romaddr, and
7. continues with some other stuff that isn't germane to this topic, and
8. CONTINUES WITH THE LOOP

This last step confuses me. Am I missing something about how pci works?
Ought not the code break from the loop when it has detected the address data
it needs to access the device?

Eno Compton

Re: [Etherboot-developers] Flashing EB in BIOS with CBROM

[Christoph P. <chr...@al...>]

In such a case you discribe, you have the best cards....
When there was a bios extensions for the 82559 then the best
way would be to exactly replace it. So the correct way here
would be to add it as /OEM0 and perhaps without address.

But before you burn in the bios extension, test it with the
floppy. You do

	make bin32/eepro100.fdimg
	dd if=bin32/eepro100.fdimg of=/dev/fd0

And boot from floppy to see if the etherboot code and all
it's settings do in a correct way !

With friendly regards

	Christoph P.


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...



> "Wolf, Paul" wrote:
> 
> I am using 82559 EB, with Intel 810 chipset. I have everything working
> on Pro 100 Lan card with FLASH.  I want to put EB in the BIOS flash so
> I can use the on board LAN controller but there is not enough room.
> Below is the original CBROM dump.  I removed item 7. OEM0 CODE for
> 82559.026 to make space in the ROM.  I flashed the new BIOS without
> the OEM0 and it works, then I put EB in 82559er.rom by following the
> Etherboot suggestions on the web site, which are install as /PCI
> 82559er.rom D000:0  after flashing the BIOS is out-to-lunch no
> booting. Any ideas?
> 
> Paul
> 
> The command used was.
>         CBROM ASUS.BIN /PCI 82559.ROM D000:0
> 
> CBROM V2.01A (C)Award Software 1999 All Rights Reserved.
> 
>               ********     asus.bin BIOS component ********
> 
>  No. Item-Name         Original-Size   Compressed-Size
> Original-File-Name
> ================================================================================
> 
>   0. System BIOS       20000h(128.00K)12F8Fh(75.89K)    original.tmp
>   1. CPU micro code    0B85Eh(46.09K)05D26h(23.29K)     cpucode.exe
>   2. Other(6000:0000)  07233h(28.55K)03D07h(15.26K)     AWARDEXT.ROM
>   3. EPA pattern       00642h(1.56K)002A1h(0.66K)       awardepa.epa
>   4. ACPI table        02C75h(11.11K)010B0h(4.17K)      ACPITBL.BIN
>   5. VRS ROM           01F65h(7.85K)012BBh(4.68K)       cav_shdw.bin
>   6. OEM0 CODE         0D800h(54.00K)08396h(32.90K)     82559.026
>   7. OEM1 CODE         0A000h(40.00K)05F7Dh(23.87K)     vb810401.dat
>   8. Other(0800:0000)  08000h(32.00K)04FCAh(19.95K)     pci32.rom
> 
>   Total compress code space  = 32F8Fh(203.89K)
>   Total compressed code size = 322A5h(200.66K)
>   Remain compress code space = 00CEAh(3.23K)
> 
>                       ** Micro Code Information **
> Update ID  CPUID  |  Update ID  CPUID  |  Update ID  CPUID  |  Update
> ID  CPUID
> ------------------+--------------------+--------------------+-------------------
> 
>

Re: [Etherboot-developers] Re: Etherboot/GRUB driver for eepro100 - problem in understanding !

[Christoph P. <chr...@al...>]

Hello Mr. Yap !

Is it possible for you email the docus you have. I have to port/
deveop a driver for the 82559ER for an other UNIX-like system
and the way with INTEL (non-disclosure agreement) is ongoing,
but take a while. But I will start now.

Is it possible for you to send me things, like Developer's Software
Manual and other important things. In the basics of the 82559 and
82559ER are identical....

ith friendly regards
	Christoph Plattner


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...



Ken Yap wrote:
> 
> |According to Christoph Plattner:
> |> In the probe section of the driver, the RxFD structure is
> |> initialized. Here the field
> |>        ACCESS(rxfd)rx_buf_addr = (int) &nic->packet;
> |> is setup with the address of the packet frame POINTER inside
> |> the nic structure.
> |>
> |> What does the field rx_buf_addr expect ?
> |> The address to a buffer, or the address to a pointer, indicating
> |> the the buffer ?
> |
> |Nothing in the EEPro100 is simple.  You need full docs from Intel to
> |even have a chance at working with it, and for some reason, Intel
> |still(!!!) requires a Non-Disclosure Agreement to get those docs.
> |Sorry.
> 
> I'm not sure, but there may be a PDF data sheet on for the 82559 on the
> Developer CD that they gave out a few years ago. Email me if you want me
> to check. I don't recall if the 82559 is a descendant of the 82586
> design, but IIRC it has more than one mode for Rx/Tx descriptors,
> allowing both inline and linked data buffers. I think the code you are
> seeing is a result of the confusion between those two modes and that the
> mode that's effective is inline data buffer. By inline and linked I mean:
> 
> inline: struct RxD {
>                 length, flags members;
>                 u_char data[ETHER_MAX_LEN];
>         };
> 
> linked: struct RxD {
>                 length, flags members;
>                 u_char *data;
>         };
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Flashing EB in BIOS with CBROM

[Ken Y. <ke...@nl...>]

|I am using 82559 EB, with Intel 810 chipset. I have everything working on
|Pro 100 Lan card with FLASH.  I want to put EB in the BIOS flash so I can
|use the on board LAN controller but there is not enough room.  Below is
|the original CBROM dump.  I removed item 7. OEM0 CODE for 82559.026 to
|make space in the ROM.  I flashed the new BIOS without the OEM0 and it
|works, then I put EB in 82559er.rom by following the Etherboot
|suggestions on the web site, which are install as /PCI 82559er.rom
|D000:0  after flashing the BIOS is out-to-lunch no booting. Any ideas?

Try swapping the Device type IDs around in the ROM image using the
swapdevids.pl script in 4.7.19 to see if it makes any difference. (There
is an ambiguity in the original spec.) Also dump the info in the OEM and
the Etherboot image using disrom.pl, also in 4.7.19, and compare the
fields.

[Etherboot-developers] Flashing EB in BIOS with CBROM

[Wolf, P. <Wo...@Ul...>]

I am using 82559 EB, with Intel 810 chipset. I have everything working on
Pro 100 Lan card with FLASH.  I want to put EB in the BIOS flash so I can
use the on board LAN controller but there is not enough room.  Below is the
original CBROM dump.  I removed item 7. OEM0 CODE for 82559.026 to make
space in the ROM.  I flashed the new BIOS without the OEM0 and it works,
then I put EB in 82559er.rom by following the Etherboot suggestions on the
web site, which are install as /PCI 82559er.rom D000:0  after flashing the
BIOS is out-to-lunch no booting. Any ideas?

Paul


The command used was.
	CBROM ASUS.BIN /PCI 82559.ROM D000:0 


CBROM V2.01A (C)Award Software 1999 All Rights Reserved.

              ********     asus.bin BIOS component ********

 No. Item-Name         Original-Size   Compressed-Size Original-File-Name 
============================================================================
====  
  0. System BIOS       20000h(128.00K)12F8Fh(75.89K)	original.tmp
  1. CPU micro code    0B85Eh(46.09K)05D26h(23.29K)	cpucode.exe
  2. Other(6000:0000)  07233h(28.55K)03D07h(15.26K)	AWARDEXT.ROM
  3. EPA pattern       00642h(1.56K)002A1h(0.66K)	awardepa.epa
  4. ACPI table        02C75h(11.11K)010B0h(4.17K)	ACPITBL.BIN
  5. VRS ROM           01F65h(7.85K)012BBh(4.68K)	cav_shdw.bin
  6. OEM0 CODE         0D800h(54.00K)08396h(32.90K)	82559.026
  7. OEM1 CODE         0A000h(40.00K)05F7Dh(23.87K)	vb810401.dat
  8. Other(0800:0000)  08000h(32.00K)04FCAh(19.95K)	pci32.rom

  Total compress code space  = 32F8Fh(203.89K)
  Total compressed code size = 322A5h(200.66K)
  Remain compress code space = 00CEAh(3.23K)

                      ** Micro Code Information **
Update ID  CPUID  |  Update ID  CPUID  |  Update ID  CPUID  |  Update ID
CPUID
------------------+--------------------+--------------------+---------------
----

 

Re: [Etherboot-developers] Re: Etherboot/GRUB driver for eepro100 - problem in understanding !

[Ken Y. <ke...@nl...>]

|According to Christoph Plattner:
|> In the probe section of the driver, the RxFD structure is
|> initialized. Here the field
|> 	  ACCESS(rxfd)rx_buf_addr = (int) &nic->packet;
|> is setup with the address of the packet frame POINTER inside
|> the nic structure.
|> 
|> What does the field rx_buf_addr expect ?
|> The address to a buffer, or the address to a pointer, indicating
|> the the buffer ?
|
|Nothing in the EEPro100 is simple.  You need full docs from Intel to
|even have a chance at working with it, and for some reason, Intel
|still(!!!) requires a Non-Disclosure Agreement to get those docs.
|Sorry.

I'm not sure, but there may be a PDF data sheet on for the 82559 on the
Developer CD that they gave out a few years ago. Email me if you want me
to check. I don't recall if the 82559 is a descendant of the 82586
design, but IIRC it has more than one mode for Rx/Tx descriptors,
allowing both inline and linked data buffers. I think the code you are
seeing is a result of the confusion between those two modes and that the
mode that's effective is inline data buffer. By inline and linked I mean:

inline:	struct RxD {
		length, flags members;
		u_char data[ETHER_MAX_LEN];
	};

linked:	struct RxD {
		length, flags members;
		u_char *data;
	};

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 -problem in understanding !

[Christoph P. <chr...@al...>]

Sorry, something forgotten...

I forgot to say again, that Linux can be booted on both
versions of GRUB without problems (diskless and local booted),
only the OS with the multiboot header has the problem....

Cheers
	Christoph P.


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...



OKUJI Yoshinori wrote:
> 
> From: Christoph Plattner <chr...@al...>
> Subject: Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem  in understanding !
> Date: Wed, 14 Feb 2001 10:06:52 +0100
> 
> > If I don't use GRUB in the "diskless" mode, and load the
> > kernel plus modules manually per tftp, the kernel works.
> 
> Then, perhaps your Etherboot program doesn't clean up the status of
> the network card properly, before it executes GRUB. Because in GRUB,
> the difference between diskless booting and network booting is only
> their formats (not essential), I don't think GRUB should be blamed
> here. Which version of Etherboot do you use?
> 
> Okuji
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 -problem in understanding !

[Christoph P. <chr...@al...>]

I used two versions, one older (4.6.11) and the newest developer
version 4.7.18.
Up to know, I had no time for further investigation, but tomorrow 
I will know more (I really hope).

I GRUB I also found no difference in an important part. I looked
for all CONFIG_DISKLESS or SUPPORT_DISKLESS (I forgot this here...)
and I saw the changes have nothing to do with this. 
In asm.S the network drive is set as default and in common.c
the ethernet stuff is called.

I saw, that the build process results in a little different
way as I did in the "draft", as my GRUB checks online, if it
was booted diskless or not. So I thought in the beginning the
disk booted GRUb and the diskless boot are exactly the same
binary (exepct stage1 vs. nbi header). But there are different
binaries, but the differences do not influence it, in my oppinion
too.

Best regards
	Christoph


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...

OKUJI Yoshinori wrote:
> 
> From: Christoph Plattner <chr...@al...>
> Subject: Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem  in understanding !
> Date: Wed, 14 Feb 2001 10:06:52 +0100
> 
> > If I don't use GRUB in the "diskless" mode, and load the
> > kernel plus modules manually per tftp, the kernel works.
> 
> Then, perhaps your Etherboot program doesn't clean up the status of
> the network card properly, before it executes GRUB. Because in GRUB,
> the difference between diskless booting and network booting is only
> their formats (not essential), I don't think GRUB should be blamed
> here. Which version of Etherboot do you use?
> 
> Okuji
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 -problem in understanding !

[Christoph P. <chr...@al...>]

Hallo Mr. OKUJI !

No, I don't blame GRUB, especially where the diskless stuff
comes from myself ....

I don't think, that it has to do with networking in any way.
The point is that GRUB always use the exactly same downloading
if booted diskless or local. The BOOTP/TFTP is working in both
modes and used in both test cases.

But booted diskless, the OS kernel crashes (I have to analyse
the consistence of the image loaded into memory !). Booted local,
but loading the kernel in the same way (using TFTP download from
the same server, which is also selected by BOOTP) the kernel boots.
This two cases are to 100% repeatable.

And then there is a test case with a 50:50% result. If I boot
GRUB from disk (local floppy without menu.lst), do the BOOTP and
`root (nd)' and load the menu with 
`configfile /tftpboot/plf/menu.lst' and boot menu controlled
(where in this case I have to add the lines `bootp' and `root (nd)'
to the config file, as this is not the default in local boot),
the kenrel boots sometimes, and sometime it crashes.

The kernel crashes means, that nothing else is printed as the
welcome message, then the machine reboots.

Now comming to your point. Is it possible to have correct
BOOTP communications and can I donwload successfully a config
file if the network card is not initialized correctly (in
connection with the use before in etherboot ?
Or is it possible that I only can receive single frames, but when
I receive a serie of frames, the NIC does not do the right thing.
Perhaps your are right. I have to study the bus master activity
of the NIC. Perhaps the chip uses addresses for data transfer
used before in etherboot, and writes something on wrong memory
locations. I have to check here some things.

Further I will try the boot process with another ISA base NIC.

Thanks,
	Christoph P.


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...



OKUJI Yoshinori wrote:
> 
> From: Christoph Plattner <chr...@al...>
> Subject: Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem  in understanding !
> Date: Wed, 14 Feb 2001 10:06:52 +0100
> 
> > If I don't use GRUB in the "diskless" mode, and load the
> > kernel plus modules manually per tftp, the kernel works.
> 
> Then, perhaps your Etherboot program doesn't clean up the status of
> the network card properly, before it executes GRUB. Because in GRUB,
> the difference between diskless booting and network booting is only
> their formats (not essential), I don't think GRUB should be blamed
> here. Which version of Etherboot do you use?
> 
> Okuji
> 
> _______________________________________________
> Bug-grub mailing list
> Bug...@gn...
> http://mail.gnu.org/mailman/listinfo/bug-grub

[Etherboot-developers] Re: Etherboot/GRUB driver for eepro100 - problem in understanding !

[Chip S. <ch...@va...>]

According to Christoph Plattner:
> In the probe section of the driver, the RxFD structure is
> initialized. Here the field
> 	  ACCESS(rxfd)rx_buf_addr = (int) &nic->packet;
> is setup with the address of the packet frame POINTER inside
> the nic structure.
> 
> What does the field rx_buf_addr expect ?
> The address to a buffer, or the address to a pointer, indicating
> the the buffer ?

Nothing in the EEPro100 is simple.  You need full docs from Intel to
even have a chance at working with it, and for some reason, Intel
still(!!!) requires a Non-Disclosure Agreement to get those docs.
Sorry.

The next best thing to the real docs might be had by reading the
official Intel driver for the EEpro100.  But believe me, you don't
want to do that unless you've got a Really Good Reason.
-- 
Chip Salzenberg            - a.k.a. -            <ch...@va...>
   "Give me immortality, or give me death!"  // Firesign Theatre

[Etherboot-developers] Re: [Etherboot-users] Re: rom-o-matic.net updated with Etherboot 4.7.19

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

On 2/14/2001 6:35 PM Bob Edwards Rob...@an... wrote:
>Alas, there appears to be a configuration bug that affects not only the
>ROM-O-Matic, but Etherboot in general. If you select "NOINT19" in the
>Config file (or the equivalent ROM-O-Matic), it still generates a boot
>ROM with INT19H support. The reason is that the loader.S file needs to
>be re-assembled with nasm or equivalent - this is the only place where
>this Config switch is used.

Thanks for the report, Bob.  I appreciate the feedback.

Could you try using:

  http://rom-o-matic.net/test/

I have enabled the as86 assembler, and deleted all pre-assembled files, 
which should force the .S files to be assembled.

Then could you try:

  http://rom-o-matic.net/4.7.19/

and make the same thing.  I have enabled the assembler there, but have 
not deleted the .pre files. My guess is it will still make the loader 
files and use those in preference to the precompiled ones.  Let us know 
what happens.

Thanks a lot for your help.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

[Etherboot-developers] Re: FYI, I've had a Y2K bug with etherboot

[Ken Y. <ke...@nl...>]

|I just can't tell wether this is in etherboot or my BIOS.
|
|I think I've found the offending statement in lance.c from 4.7.17
|(actually I'm using 4.6.12, 4.7.17+ does not recognize my kernels):
|
|>361:        time = currticks() + TICKS_PER_SEC;             /* wait one seco
>nd */
|>>>362:        while (currticks() < time && (lp->tx_ring.u.base & 0x80000000)
> != 0);
|				
|This seems to cause an overflow and results in my network getting
|flooded with the same ethernet frame all over. 
|It helped to set the bios clock of the machine way back. Quite possibly
|this might be a bug in the machine,
|because the machine is an old 2nd hand compaq deskpro 2000 5120 with
|onboard amd lance/pcnet 32 10 Mbit NIC.

It won't be a Y2K bug, Etherboot has no notion of year. currticks()
returns an unsigned long which are the ticks (units of 1/18.22 seconds)
since midnight of today, providing your BIOS implemented it correctly,
not since some date in the past. However once initialised currticks()
continues to increment correctly past midnight, and wraps around at
about 2700 days.

And anyway I don't see immediately how this statement would cause a
resend of the packet, all it does it provide a timeout for the transmit
completion.

It would help if you inserted some printf statements to display the
value returned by currticks to verify or disprove your bug.

Also in future, please send bug reports to the users or developers list,
not to me directly. The idea is for me not to become a single point of
failure for the project if I decide to drop out to some South Pacific
island where there is no Ethernet. :-)

Re: [Etherboot-developers] MIE and the content-disposition bug

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

On 2/14/2001 7:37 PM Marty Connor md...@th... wrote:
>   http://support.microsoft.com/support/kb/articles/Q267/9/91.ASP
>This article describes a bug in Explorer, which is supposedly fixed in 
>Internet Explorer version 5.5 Service Pack 1.

I had this funny feeling this was too easy... Microsoft never fixes a bug 
without putting in another one. :-) So, I downloaded the 19MB "update" 
from MIE 5.0 to 5.5 SP1.  I dutifully installed it on a Win98 machine, 
and tested it, and it still didn't work!

Then I got to thinking, hmmm, obviously Microsoft is trying to be smarter 
than they should be here;  They believe they can deduce from the URL what 
the file type is going to be, even though they shouldn't be doing that 
yet.  And then, at the Mary Chung Restaurant over Valentines dinner with 
my lovely wife, I had an idea...

What if I:

 - Click on "Get ROM"
 - Wait for usual dialog box
 - Click the radio button that says: "Run from current location"
   (which of course makes no sense, because it's not an known executable
    file type)
 - Wait for SECOND dialog box that now says "Save file to Disk"
   (Which now magically has the right filename and everything :-)
 - Save the file to disk.  
 - Rejoice!

So I guess I have to put a "If you're having problems saving ROM images 
from Microsoft Internet Explorer click here!" link on ROM-o-matic.net for 
people trying to use MIE 5.5. MIE 5.0 works. I don't know what other 
versions might or might not work.  Gee, I can take Windows screen shots 
and maybe find some cute cartoon character animated GIF to liven up the 
presentation of the work-around...    NOT. 

So can I ask folks to try the above and let me know if it seems to do the 
job?  I realize it's unclean, but I have this feeling that Microsoft is 
not going to accept patches to their MIE source code (which nobody has 
anyway :-). 

Thanks,

Marty

P.S. And big thanks to Robb Main who inspired me to dig deeper into this 
problem, and sent helpful debugging info.  I appreciate it.

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in understanding !

[OKUJI Y. <ok...@ku...>]

From: Christoph Plattner <chr...@al...>
Subject: Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem  in understanding !
Date: Wed, 14 Feb 2001 10:06:52 +0100

> If I don't use GRUB in the "diskless" mode, and load the 
> kernel plus modules manually per tftp, the kernel works.

Then, perhaps your Etherboot program doesn't clean up the status of
the network card properly, before it executes GRUB. Because in GRUB,
the difference between diskless booting and network booting is only
their formats (not essential), I don't think GRUB should be blamed
here. Which version of Etherboot do you use?

Okuji

[Etherboot-developers] MIE and the content-disposition bug

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

On 2/14/2001 12:26 PM Bob Andrews bo...@in... wrote:
>For a simple form that gives a file result, it would seem that you have to
>go out of your way to make it work on netscape and not ie. 

For those with real, honest curiosity about the issue please see:

   http://support.microsoft.com/support/kb/articles/Q267/9/91.ASP

This article describes a bug in Explorer, which is supposedly fixed in 
Internet Explorer version 5.5 Service Pack 1.

It is a known problem for people (like me) who write things like this:

      Header("Content-Type: application/x-octet-stream; " .
	     "name=$nicfilename");
      Header("Content-Disposition: attachment; " .
	     "Filename=$nicfilename");
      Header("Content-Location: $nicfilename");
      Header("Content-Length: $len");

Microsoft has improperly implemented response to the Content-Disposition 
header.  When the type is "attachment" it is supposed to prompt the user. 
 It's a known bug. 

I don't know exactly what version(s) of MIE have the bug, but 5.0 on 
Win98 seems to work alright.  They may have broken it in 5.5, so then 
they put out a service pack to fix it. 

It took me just a few moments of search in Google and Microsoft 
searchable knowledge base to find the answer.

Rom-o-matic.net dynamically generates the ROM image, and when you press 
"Get ROM" it sends it to your browser.  I could mail it, but that seemed 
less elegant than the immediacy of sending it in real-time.  There's 
actually quite a bit going on in those 3 seconds or so (mkdir, untar, gen 
Config file from options, make, 10 gccs, a few as86s).

And of course email offered the possibility of abuse/spam.

Anyway, I know there are improvements that can be made, and I appreciate 
honest, well-meaning feedback, and (has been demonstrated) I will track 
bugs down with enthusiasm.

>And to blame
>Microsoft because one can not write a simple cgi is extremely lame.

Thanks for your well-researched and considered input on this topic.

Regards,

Marty

---
    Try: http://rom-o-matic.net/ to make Etherboot images instantly.

   Name: Martin D. Connor
US Mail: Entity Cyber, Inc.; P.O. Box 391827; Cambridge, MA 02139; USA
  Voice: (617) 491-6935, Fax: (617) 491-7046 
  Email: md...@th...
    Web: http://www.thinguin.org/

Re: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list archives

[Donald J C. <dj...@ci...>]

Bob Andrews wrote:
> 
> For a simple form that gives a file result, it would seem that you have to
> go out of your way to make it work on netscape and not ie.  And to blame
> Microsoft because one can not write a simple cgi is extremely lame.

Man, this guy just doesn't know when to stop.

-Don

--
Don Christensen     Senior Software Development Engineer
  dj...@ci...     MMABU - Mid-Market Access Business Unit
  Cisco Systems    ComLOB - Commercial Line of Business
   San Jose, CA   "It was a new day yesterday, but it's an old day now."

RE: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list archives

[Bob A. <bo...@in...>]

For a simple form that gives a file result, it would seem that you have to
go out of your way to make it work on netscape and not ie.  And to blame
Microsoft because one can not write a simple cgi is extremely lame.

-----Original Message-----
From: ja...@mc... [mailto:ja...@mc...]
Sent: Wednesday, February 14, 2001 7:22 AM
Subject: Re: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list
archives

Eno's message here is pretty good.

Of course you have to consider that some people are
just better off staying on a Microsoft platform.  ;-)

Jim McQuillan
ja...@lt...

Re: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: list archives

[Jim M. <ja...@Mc...>]

Eno's message here is pretty good.

Of course you have to consider that some people are
just better off staying on a Microsoft platform.  ;-)

Jim McQuillan
ja...@lt...

Eno Compton wrote:
> 
> Dear Bob,
> 
> Your impertinent note works simply to define the author as unwilling (which
> most suspect probably means unable) to do the analysis, invest the time, and
> shoulder the burden of original work.
> 
> The simple truth is, etherboot provides a substantial foundation which, when
> combined with genuine professionalism, is an excellent contribution to
> industry.
> 
> You should reconsider the means by which you express your frustrations. Try
> to understand frustration is usually a direct function of unenviable traits
> such as ignorance and sloth. By your unpleasantness, you simply expose your
> own inadequacies.
> 
> Be still. Sit down and study. When you don't understand, study some more. Be
> slow to query. Great rewards accrue to those who quietly, vigorously seek
> them. If you adopt this different attitude in your notes, I think you will
> be rewarded with thoughtful, helpful answers. There is substantial depth on
> this list.
>

RE: [Etherboot-developers] RE: [Etherboot-users] Adminstrivia: li st archives

[Eno C. <Eno...@Mi...>]

Dear Bob,

Your impertinent note works simply to define the author as unwilling (which
most suspect probably means unable) to do the analysis, invest the time, and
shoulder the burden of original work.

The simple truth is, etherboot provides a substantial foundation which, when
combined with genuine professionalism, is an excellent contribution to
industry.

You should reconsider the means by which you express your frustrations. Try
to understand frustration is usually a direct function of unenviable traits
such as ignorance and sloth. By your unpleasantness, you simply expose your
own inadequacies.

Be still. Sit down and study. When you don't understand, study some more. Be
slow to query. Great rewards accrue to those who quietly, vigorously seek
them. If you adopt this different attitude in your notes, I think you will
be rewarded with thoughtful, helpful answers. There is substantial depth on
this list.

:)

Eno Compton

 

 -----Original Message-----
From: 	Bob Andrews [mailto:bo...@in...] 
Sent:	Tuesday, February 13, 2001 7:02 PM
To:	eth...@li...
Subject:	[Etherboot-developers] RE: [Etherboot-users] Adminstrivia:
list archives

Ken,

The rom-o-matic did not work on win98/IE, all you obtain are small useless
html files.  It did work under Linux.  I wonder if the links were absolute
not relative, since I have Apache server w/php on my other machine.

I pulled down the distro from sourceforge, and to be honest the
documentation was so crappy I did not even bother.  Why clutter my disk when
I don't know it works (or even what it does), and yes I did read the doc
files.  You mention that new stuff is on a mailing list, just say how to get
it easily, or why anyone would care.  Getting you to complete a sentence is
like pulling hen's teeth.  Try to finish a thought for once so we don't have
to make 10 questions out of each phrase you spit out.  If I actually cared,
I'd have to ask you what you meant (ie., English) or just guess where it was
and plod along.  My expectations are that you would reply with an irrelevant
or totally usely cryptic remark that solves nothing.

What we are trying to do here should be simple (under 2 hours) - but you
make it into a full-time effort for a week.  If one have to read every line
of someone's code to use it, it's trash - don't bother.

So you understand the problem clearly:  I have ami, 256 ram that can be
written to.  I have an rt8139 ethernet card.  I want to make bootp or rarp
work (linux).  I want an eprom for that card OR reprogram the bios.  The
module for realtek card is 16K.  HOW do I integrate it????


-----Original Message-----
From: eth...@li...
[mailto:eth...@li...]On Behalf Of Ken Yap
Sent: Tuesday, February 13, 2001 4:56 PM
To: eth...@li...;
eth...@li...
Subject: [Etherboot-users] Adminstrivia: list archives

A couple of subscribers have pointed out to me that the archive link
from the page Project Info -> Mailing Lists is most up to date and
different from the one you get when you go to the Mailman web interface,
which goes no further than end Dec 2000. I'm asking Sourceforge for
clarification, it seems to be a side effect of their recent relocation.
In the meantime, bear in mind that the most up to date archives are
accessed from the Mailing List web page.

_______________________________________________
Etherboot-users mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-users


_______________________________________________
Etherboot-developers mailing list
Eth...@li...
http://lists.sourceforge.net/lists/listinfo/etherboot-developers

Re: [Etherboot-developers] Flashing EB into BIOS ROM

[Christoph P. <chr...@al...>]

For AWARD it can be downloaded on different locations. I have 
downloaded some versions of the tool, called CBROM. This
tool can append BIOS extesionst to the BIOS binary. But you will
have problems, if the BIOS ignore such extended modules.

If you are the person I think (at Alcatel Austria) then
we can meet and discuss this topic (DW: 3706).
You can search the tool with the search engine with "CBROM".

For AMI I have not fount any tool yet, nor for Phoenix.
On an old embedded machine, I replaced the AMI Bios by a 
suitable Award Bios (for private use and experiments)...

With friendly regards

	Christoph P.


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...




> "Wolf, Paul" wrote:
> 
> I am looking for a utility that I can append Etherboot in the BIOS
> ROM.  Does anybody have information on this.  I found one for AWARD
> for $3000.  I am would like one for Award and AMI BIOS.
> 
> Thanks
> 
> Paul

-- 
  +--------V--------+	Chr...@al...
  |  A L C A T E L  |	-----------------------------
  +-----------------+	Phone: +43 1 27722 3706	
         T A S		Fax:   +43 1 27722 3955

[Etherboot-developers] Etherboot 4.7.19 (development) released

[Ken Y. <ke...@nl...>]

I have released Etherboot 4.7.19 at http://etherboot.sourceforge.net

Changes in this release:

+ Pavel Tkatchouk verifies that lance.c can handle PCnet-FAST III
79c973. Added a new entry to lance.c and NIC. NIC entry not verified
yet.

+ Enhanced disnbi to decode ELF images too.

+ Arrgh! There are old BIOSes that rely on the wrong order of the bytes
in the device identifier in the PCIR and PnP structures. Wrote a Perl
program swapdevids.pl to swap these bytes. Apply this to image file just
before programming the EPROM.

+ Marty Connor suggested that the specs state that for PnP ROMs the
unsuccessful return from boot should be int 0x18 rather than int 0x19.
Using int 0x19, selecting L for local device doesn't work. Fixes needed
in both loader.S and start32.S (get lret to work properly, instead of
doing an int 0x19 directly, involved saving ss and sp in real mode
instead of in protected mode).

+ Wrote a Perl program disrom.pl to display key structures of a ROM
image.

+ Added call to binmode() in various Perl utilities so they should work
under other OSes.

+ Added check in makerom.c to warn if 55 AA not found at start of image.
It seems some people don't read the warning not to use the Linux
supplied as86.

+ It seems Z is a recent addition to pack/unpack formats in Perl and
even a Perl as recent as 5.004 doesn't implement it. Change Z5 in
mknbi.pl and TruncFD.pm to a5 since we only need to compare it against
'FAT12' and 'FAT16'.

+ Some errors found in osloader.c in the #ifdef IMAGE_MULTIBOOT
sections.  kernel should be KERNEL_BUF and union info should have
unsigned short s[256];. Also kernel -> KERNEL_BUF for IMAGE_FREEBSD,
obviously few FREEBSD users have tried compiling it.

+ Explain in docs that .com and .(lz)lilo images can be generated and
touch briefly on how to use them.

+ Donald Christensen contributed translations of floppyload.S and
loader.S to gas syntax. Currently they are in contrib/gassyntax/.  They
potentially allow us to throw away as86 and/or nasm and use GNU tools
throughout, but I have to do some work on them: 1. I have to check what
versions of gas accept the syntax, the 16-bit mode in gas was a recent
enhancement; 2. I have to put back the #ifdef PCI_PNP_HEADER into
loader.S and also bring it up to date to the recent patches.
floppyload.S should be usable as is.

MD5 sums:

b29e6b81cd86effdfabb25dc18198026  etherboot-4.7.19.tar.bz2
a2e5b5f6bcfd0edeaacc941e3f809c61  etherboot-4.7.19.tar.gz

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in understanding !

[Ken Y. <ke...@nl...>]

>While code reading of eepro100.c I got a problem in understanding
>one detail:
>
>In the probe section of the driver, the RxFD structure is
>initialized. Here the field
>	  ACCESS(rxfd)rx_buf_addr = (int) &nic->packet;
>is setup with the address of the packet frame POINTER inside
>the nic structure.
>
>What does the field rx_buf_addr expect ?
>The address to a buffer, or the address to a pointer, indicating
>the the buffer ?

Ok, I didn't write the code, so understand that this is my best guess.

ACCESS is a macro that expands ACCESS(x) to either x-> or x. depending
on a define. So ignoring why sometimes a pointer and sometimes a struct,
rx_buf_addr is a field in rxfd. Let's just say rxfd is a pointer to a
struct for the same of explanation.

>The point I cannot understand here is the following.
>The setup in the probe functions sets the `rx_buf_addr' to the
>packet buffer, defined in `config.c'. This means, that an received
>packet is transfered there by the i8255[789] chip. On the
>other hand, in the `poll' routine, I found following code:
>
>    nic->packetlen =  ACCESS(rxfd)count & 0x3fff;
>    memcpy (nic->packet, ACCESS(rxfd)packet, nic->packetlen);
>
>Here the contents from the packet field of the `rxfd' is copied into
>the nic->packet frame. But how does the frame come in `rxfd'-packet
>field ?? The hardware has to send the data directly to nic->packet.

The frame is deposited into the memory region pointed to by rxfd by the
*hardware* of the ethernet adaptor.  The EEPRO100 is quite a smart
adaptor. Very roughly speaking, you give the hardware a pointer to a
receive descriptor (the struct RxFD, which is a convenient way to
describe a set of consecutive memory locations), and in turn that struct
contains fields for the data, the packet receive status, the packet
length, etc. Thus when the status word indicates that the receive is
complete, the data field will "magically" have the requested data.

It is quite likely either the assignment to rx_buf_addr or the memcpy is
useless. I suspect the assignment to rx_buf_addr.  To understand it
fully you would have to get hold of the data sheet of the EEPRO100
controller.

Re: [Etherboot-developers] how to get RTL8139 ROM

[Markus G. <ma...@gu...>]

> Now that I have counted to 100 after your accusations, let me say that
> you misunderstand the nature of the location of the knowledge in this
> project. I DO NOT HAVE ALL OF IT, and I say so in the documentation.  I
> DO NOT have all the possible variations of hardware that people have
> tried Etherboot on.

Ken, I have to applaud you for your sense humor. This must have
been one of the funniest ways I have ever seen anybody avoid a flame
fest.


Markus

-- 
Markus Gutschke                                Resonate, Inc.
3637 Fillmore Street #106                      385 Moffett Park Drive
San Francisco, CA 94123-1600                   Sunnyvale, CA 94089
+1-415-567-8449                                +1-408-548-5528
ma...@gu...                            mgu...@re...

Re: [Etherboot-developers] Etherboot/GRUB driver for eepro100 - problem in understanding !

[Christoph P. <chr...@al...>]

This is not the problem, the eepro100 chip is not know by the
OS now (I will port/write the driver). So this is no topic.

<Etherboot problem, see below....>

The problem is that the kernel crashes in the very beginning,
as if the kernel images is destryed.
The last status of my investigation is, that the eepro100 driver
in GRUB is not the problem (or not primary).

If I don't use GRUB in the "diskless" mode, and load the 
kernel plus modules manually per tftp, the kernel works.

So I must analyse the diskless grub stuff (and that's bad, as
this is my stuff).

The problem, again.
Linux works.
The OS we use in our company (multiboot, kernel + 2 modules)
crasehd 100% if it is loaded into the diskless GRUB manually
and automatic per menu.
The OS sometimes crashes if same GRUB booted from DISK and the
use of automatic loading per menu
The OS boots successful on GRUB booted from DISK and kernel+modules
loaded manually by tftp.

--------

But this has nothing to do with the point I ask etherboot-developers:

Question was: I do not understand the use of the files
rx_buf_addr of RxFD, as it is loaded with the address of 
&nic->packet.
(1) is the & necessary, as the NIC seems to expect the buffer address
and not a pointer showing to a field with the buffer address...
(2) why the nic->packet, as in the poll routine the packet is
copied from the rxfd->packet to nic->packet.

This point I cannot understand, and this point is independent from
the problems described above.

Cheers
	Christoph P.


-----------------------------------------------------------------
private:        chr...@do...
company:        chr...@al...




Ken Yap wrote:
> 
> |I have the problem downloading the OS kernel image to 1MB
> |(0x00100000), via GRUB / tftpboot (*** not etherboot here ! ***)
> |Booting the same kernel from the disk works !
> 
> Before you go off chasing bugs in eepro100.c, make sure that the source
> in GRUB is recent. There was a bug fixed in recent Etherboot
> distributions where the NIC was not turned off after loading and
> deposited stray packets in memory. (eepro100_disable was not
> implemented.) As I understand it the source in GRUB is a bit behind.
> 
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> http://lists.sourceforge.net/lists/listinfo/etherboot-developers