etherboot-developers — Discussion of developer issues

[Etherboot-developers] Re: [Etherboot-users] RTL8139 EEPROM (SOLVED)

[Tania O. <ta...@ce...>]

Hello

I solved my problem of not being able to receive packets via the RTL8139C on our
custom board.  I needed a delay before calling the rtl8139_probe() routine.  I'm
not sure exactly why this is, except I think it is probably specific to my
system.  I have an extremely minimal BIOS and consequently the time from power-on
to when the rtl8139_probe() routine is called is much shorter than on a typical
PC.

I still haven't figured out why it worked without the delay if the EEPROM was
blank (all 0xffff).  If anyone who knows this chip well has a theory I'd be
interested in hearing it.

Incidentally, while I was checking all sorts of things,  I found a couple of
small things in the driver that didn't look right.  I'll mention them here in
case they may be important to someone, but since everything works ok as it is I
wouldn't worry about them otherwise.  (These comments apply to rtl8139.c in
Etherboot 4.7.20, please ignore if they have already been fixed).

1.  The write to Config1 (register offset 0x52)  in rtl8139_probe() under the
comment "Bring the chip out of low-power mode" probably is not having any effect
since bits EEM1-0 in Cfg9346 (register offset 0x50) need to be set first to
unlock the Config1 register for write.

2.  The MultiIntr register (offset 0x5C) should be cleared, according to the
RTL8139C data sheet.


One other thing.  I needed to reset the chip in rtl_disable(), which originally
was empty.  Without doing this I got "Unable to handle kernel paging request"
panics when booting Linux after Etherboot.  I had USE_INTERNAL_BUFFER defined.
The following code (just copied from elsewhere in the driver) worked for me:

static void rtl_disable(struct nic *nic)
{
    int i;

    /* disable TX/RX */
    outb(0x00, ioaddr + ChipCmd);

    /* reset the chip */
    outb(CmdReset, ioaddr + ChipCmd);

    cur_rx = 0;
    cur_tx = 0;

    /* Check that the chip has finished the reset. */
    for (i = 1000; i > 0; i--)
        if ((inb(ioaddr + ChipCmd) & CmdReset) == 0) {
            break;
    }
}

Cheers,
Tania

Ken Yap wrote:

> Some of the bytes in the EEPROM control the NIC's operation. Could some
> of them have an adverse effect on reception? You'd need a 8129
> datasheet.

[Etherboot-developers] rom-o-matic.net updated to Etherboot 4.7.23 (5.0RC3)

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

http://rom-o-matic.net/ has been updated to include Etherboot 4.7.23 

We would greatly appreciate it if you would test this development release 
by making an Etherboot image of whatever format you choose (floppy, ROM, 
lilo, or .COM), and report any problems or things that now work that 
didn't before.

This is the 3rd release candidate for Etherboot 5.0, and reports have 
been quite positive.  Your help in testing this release will give us 
confidence that we are nearing production quality.

With Thanks,

Marty

---
      Martin D. Connor, CEO & President, Entity Cyber, Inc.
       US Mail: P.O. Box 391827, Cambridge, MA 02139  USA
   Voice: (617) 491-6935, Fax: (617) 491-7046, Net: md...@en...
                     Web: http://www.entity.com/

[Etherboot-developers] Etherboot 4.7.23 (5.0RC3) released

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

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

It would be very much appreciated if any breakage with PnP BIOS booting
due to change number 3 are reported. Conversely if BIOSes that didn't
detect before now do, we'd like to know that too. Thanks.

Changes in this release:

+ Reintroduce the old Via-Rhine PCI IDs into file NIC and give the
corresponding ROM images -old suffixes, in case some people are using
the old chips.

+ Peter Kögel contributed patches to the SIS900 driver to make it work
for the SIS640e/SIS730s.

+ Charles Dobson pointed out that when booting from a PnP BIOS, the code
should not hook or restore the INT19H entry point.  Put hooking code
inside #ifndef PCI_PNP_HEADER and changed entry point in PnP structure
from start19h to blockmove.

+ I have one report that gas 2.91 doesn't assemble loader.S because it
can't handle all the 16-bit code. Since the benefits of using gas for
all assembly code are great, and gas 2.95 has been out there for a long
time, I regretfully say to affected users: upgrade your tools. Otherwise
there may be a workaround by specifying the opcodes literally.  I leave
it to interested parties to try. If you do this, put in an #ifdef
GAS291, naturally.

+ Updated contrib/tftp-hpa to 0.16 from ftp.kernel.org.

MD5 sums:

7909168a3c2c7aca986fb6150ac4c8f6  etherboot-4.7.23.tar.bz2
03a821af724b778fc844c9bb7a8b81f8  etherboot-4.7.23.tar.gz

Re: [Etherboot-developers] tulip.c and NIC based on DEC 21140

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

On 3/28/01 5:53 AM Joerg Friedrich Joe...@un... 
wrote:
>I tried to use etherboot with a Kingston KNE100TX Card and failed.
>I always get TX timeouts when searching a DHCP-Server.
>This card is based on a DEC 21140-AF chip, which should work with the
>tulip-driver. 

Yes, the tulip.c driver of Etherboot needs to be updated to support more 
cards.  It does not have the MII code of the Linux driver, which can 
support well over 100 cards.

>The Problem is, that discribed at 
>http://www.scyld.com/network/tulip-media.html
>As far as I can see the linux-driver from Donald Becker can handle this 
>issue. I'll try if I'm able to rewrite the tulip-driver from Donald to 
>work with etherboot.

Many people would be very grateful to you if you added support for the 
DEC 21xxx based cards.  If I had one of those cards to play with, I might 
have done it by now, but all my tulip cards are clones.

If you decide to work on rewriting the Linux driver for Etherboot, I'd be 
happy to help. (I wrote the current tulip driver).  I'd also love to get 
hold of a 21xxx-based card for testing.  If anyone wants to send me one,  
I'll trade you a different card, or will buy it from you and pay shipping.

Regards,

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

[Etherboot-developers] tulip.c and NIC based on DEC 21140

[Joerg F. <Joe...@un...>]

Hi!

I tried to use etherboot with a Kingston KNE100TX Card and failed.
I always get TX timeouts when searching a DHCP-Server.

This card is based on a DEC 21140-AF chip, which should work with the
tulip-driver. 

The Problem is, that discribed at http://www.scyld.com/network/tulip-media.html

As far as I can see the linux-driver from Donald Becker can handle this 
issue. I'll try if I'm able to rewrite the tulip-driver from Donald to work with
etherboot.

Yours Joerg

[Etherboot-developers] rom-o-matic.net update / sis900 fixes

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

I have updated rom-o-matic.net with Etherboot version 4.7.22.  

I have also incorporated fixes to the SIS900 driver that were generously 
provided by Peter K=F6gel.  These fixes may solve some of the problems 
reported with various SIS900-based cards.

Please test this version (4.7.22) which is a release candidate for 
Etherboot 5.0.   Note that the SIS900 fixes are not in the official 
4.7.22 distribution, but are only on rom-o-matic.net to facilitate 
testing.  I ask all SIS900 users to try building an image using 
rom-o-matic.net version 4.7.22 so we can see if we are closer to a 
version that supports more variations of cards based on the SIS900.

Thanks are due to a great many people who have sent suggestions, patches, 
and constructive criticism.  It is a little overwhelming (to me anyway), 
but in a pleasant way.  I'll try to be more responsive in between other 
commitments.  Thanks for your patience as I attempt to make more time for 
hacking :-)


---
      Martin D. Connor, CEO & President, Entity Cyber, Inc.
       US Mail: P.O. Box 391827, Cambridge, MA 02139  USA
   Voice: (617) 491-6935, Fax: (617) 491-7046, Net: md...@en...
                     Web: http://www.entity.com/

Re: [Etherboot-developers] lzhuf compression program hangs

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

> Hmm, nobody has tried lzhuf with images that large, because no Etherboot
> image is that large. So you are on unchartered territory. Remember that
> you can't pick any arbitrary algorithm, it has to be the inverse of the
> one on loader.S. Also the loader.S implementation may have size
> limitations too. I don't know if these limits can be raised.

loader.S is heavily optimized for size. This results in several
limitations. I know that there is no way it will uncompress more
than 64kB, because of using offsets and segment registers. It might
even be restricted to less memory, but I haven't checked that. When
I wrote it, the target was to be able to uncompress 32kB images.

If you find a solution to the restricted addressing modes you can
increase the uncompressed size to more than 64kB, but I am not sure
whether there is a limit on the compressed size. Also, please note
that loader.S does not include code to reset the frequencies in case
of an integer overrun. This problem can theoretically occur as soon
as after the first 64kB; in real life it will probably hit a little
bit later.

Please include the extra code, only if you have a real problem with
the current limitations. Increasing the size of the uncompressor
is noticeably more expensive than increasing the size of the
compressed data. For every byte that loader.S grows, you lose several
bytes of compressed code. I don't think there are that many people
out there still using 8kB ROMs (that was the original reason why I
wrote the compressor), but 16kB ROMs are probably still used by
several of the people on this list.


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] lzhuf compression program hangs

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

|lzhuf hangs when attempting compression of a file 131072 in size, but works
|on a file 114688 in size;  also, the make of lzhuf fails if either -DENCODE
|or -DDECODE compilation flags is missing (ie.  its currently only possible
|to create lzhuf with both decode and encode elements);  does anybody know of
|any other lz compression programs out there with available source?

Hmm, nobody has tried lzhuf with images that large, because no Etherboot
image is that large. So you are on unchartered territory. Remember that
you can't pick any arbitrary algorithm, it has to be the inverse of the
one on loader.S. Also the loader.S implementation may have size
limitations too. I don't know if these limits can be raised.

[Etherboot-developers] Re: [Etherboot-users] sis 630e bootrom and etherboot/netboot rom image

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

|Thanks for your previous answer.
|I worked on my mb and now the problem is the following: etherboot
|supports sis 900 lan adapter but asus cusi-fx (sis630e (award 6.00)
|based mb that includes sis900/7016 lan adapter) shares bootrom with
|bios  memory. I tried to make a Etherboot boot floppy for sis 900. While
|booting, the adapter is found and recognized, but the following message
|appears:
|
|'Found SIS900 at 0xD400, ROM address 0x0000'
|'Probing...[SIS900]sis900_probe: Error EEPROM read: 0000'
|'No adapter found'

Redirected to developers list.

Ah, I think you need something even more recent then. 

http://www.geocrawler.com/lists/3/SourceForge/5298/0/5387617/

is a patch that was posted on the developers list for newer SiS900 NICs.
I haven't had time to look at it yet and I won't for the next week.
Unfortunately the archive doesn't contain the patch, geocrawler seems to
strip attachments, but you should be able to contact the author directly
or hopefully he will see this. Please give this a workout.

Re: [Etherboot-developers] lzhuf compression program hangs

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

> lzhuf hangs when attempting compression of a file 131072 in size, but works
> on a file 114688 in size;  also, the make of lzhuf fails if either -DENCODE
> or -DDECODE compilation flags is missing (ie.  its currently only possible
> to create lzhuf with both decode and encode elements);  does anybody know of
> any other lz compression programs out there with available source?

The compression program that comes with Etherboot is really only
intended for ROM images. The decompressor will fail if the image
grows too big. The compressor should do somewhat better, but it has
never been tested with large images. There is a good chance that
the "reconst()" function has bugs, because it is never used for
the size of images that come with etherboot. All of these bugs should
be relatively easy to fix, but I cannot really see why you'd even
encounter them; "etherboot" cannot deal with uncompressed images
that large anyway.


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...

[Etherboot-developers] lzhuf compression program hangs

[Jim F. <fre...@Za...>]

hi,
lzhuf hangs when attempting compression of a file 131072 in size, but works
on a file 114688 in size;  also, the make of lzhuf fails if either -DENCODE
or -DDECODE compilation flags is missing (ie.  its currently only possible
to create lzhuf with both decode and encode elements);  does anybody know of
any other lz compression programs out there with available source?
-thanks, jim fredette

[Etherboot-developers] RTL8139 EEPROM

[Tania O. <ta...@ce...>]

Hi all

I have a problem which seems to be affected by the contents of the
EEPROM on the Realtek RTL8139C ethernet controller.  We are using this
controller embedded on a custom board (rather than on an adapter card).
In its factory default state, the EEPROM is clear (reads all 0xFFFF).
In this state (with only the MAC address set up) the Etherboot rtl8139.c
driver (from version 4.7.20) works like a charm.  However linux 2.4.1
fails to recognize the controller as an 8139 because the PCI
configuration space device ID field reads 8129.

If I set up the EEPROM to match values read from an RTL8139 adapter card
we bought for test purposes, the linux driver for the 8139 works fine,
however Etherboot stops working.  Transmit looks ok but receive is dead.

Any ideas or suggestions?

EEPROM contents (linux ok but Etherboot receive not working):

8129 10EC 8139 10EC 8139 4020 E112 8000
996D 0300 8D14 F7C2 8801 43B9 B0F2 0711
DF43 8A3E EF83 4D26 8389 B0FA 4848 4848
0000 0000 0000 0000 0000 0000 0000 0000
...

Thanks,
Tania

Re: [Etherboot-developers] boot1a failure for a 64kB lzrom image

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

|i am getting an error while attempting a lzrom image boot from a floppy
|using boot1a  taken from etherboot 4.7.22 (latest);  the error that comes to
|the screen is "Rd err" (i did try using a different floppy);  smaller sized

You should probably ask Luigi Rizzo, who submitted boot1a.s, for help.
There may be limitation on what boot1a can load, which a little hacking
*might* fix. All Etherboot images are 32kB or less so boot1a has never
been stretched in that direction.

[Etherboot-developers] boot1a failure for a 64kB lzrom image

[Jim F. <fre...@Za...>]

hi,
i am getting an error while attempting a lzrom image boot from a floppy
using boot1a  taken from etherboot 4.7.22 (latest);  the error that comes to
the screen is "Rd err" (i did try using a different floppy);  smaller sized
images work fine, but it is important that it work for this sized, and
possibly larger images;  i have made no changes to any make-file sizing or
image loading destination parameters (ie. ROMLIMIT, and RELOCADDR are
untouched from the 4.7.22 tarball);  is there some restriction boot1a has on
the size of images it can load?;  if so, how to change it? 
-thanks in advance, jim fredette

Re: [Etherboot-developers] sis640e/sis730s support for etherboot sis900 driver

[Peter <pet...@to...>]

On Tuesday 20 March 2001 08:48, you wrote:
> >I found folowing in my sis630e_get_mac_addr function:
> >Eterboot doesn`t find the PCItoISA bridge with the scan_bus()-function
> >because the ioaddr of that device is 0x0000
>
> Perhaps instead of inventing a new function you should delete the test
> for ioaddr == 0 from the scan_bus function since it will still have to
> pass the vendor and device ID tests anyway. I doubt if the ioaddr == 0
> test catches any accidental matches.

I've made some changes in my first patch that uses the scan_bus function.

Is there any problems if the scan_bus()-function fills out devfn an bus entry 
of a card that mach to the search-list even if the card has no ioaddr ?

Can I say that if  (bus == 0) && (devfn==0) this is not a PCI-card / 
PCItoXX-bridge? I think it would be a good thing to do this in the  
sis630e_get_mac_addr()-function to decide which pci_isa_bridge_list to use.
 
Peter

Re: [Etherboot-developers] RE: [Etherboot-users] etherboot 32K size limitation

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

Incidentally there is another way you can get access to the firmware and
that is to read it directly from the ROM behind the Etherboot image,
assuming your firmware can map that much of ROM into the memory space.
You will notice that Etherboot displays the ROM address and length on
bootup from ROM.  This is extracted from the %cs and ROM length when
the boot code is entered.  You could use this to find the location of
the firmware. Of course you'd have to arrange something different for
testing from floppy.

Re: [Etherboot-developers] RE: [Etherboot-users] etherboot 32K size limitation

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

|i) the executable portion of the .rom image for my ethernet card is 32K;
|however, i would append on an additional 73K of firmware, making the total
|size 105K;
|ii) i would modify floppyload.S to load this 105K image by upping the
|SYSSIZE parameter, and by disabling the 64K byte boundary crossing check,
|label "die:" in the code;

Probably doable, might be a squeeze into 512 bytes. BTW, floppyload.S is
obsolete and has been replaced by boot1a.s.

|iii) i would change the etherboot RELOCADDR to 78000h, leaving me with 164K
|of space up to a0000h;  the firmware would reside immediately after the
|executable etherboot image,  at 80000h; 

The problem with this is Etherboot is going to relocate itself (using
loader.S) to 0x94000. The space from 0x90000-9xA0000 has to be kept
free.  Therefore you should locate your firmware at 0x90000 - 73k at
most. Better still I suggest loading the firmware, then Etherboot, at
0x90000 - 105k, then let Etherboot do its thing as normal. Your firmware
will be below Etherboot.

|iv) etherboot executable code, which again, is 32K in size,  ultimately
|exercises my driver's probe entry point, which can then read the firmware
|from 80000h and load it into the giganet card;  to do this last step, i
|assume that the processor must be running in protected mode ... but i'm
|almost positive that its not;  in that event, ie. in real-mode, is there a

Why do you think it's not in protected mode?

|way that my probe routine can access this data that will certainly cross a
|64K boundary?

BTW it has always been possible to access more than 64kB in real mode, you
just have to diddle with the segment registers to achieve this, which is
why segmented architecture is such a pain.

|another question:
|the giganet card's 16K of registers and memory is accessible via pci memory
|space (as opposed to i/o space for all other cards supported by etherboot);
|i pencilled-in some changes to pci.c to identify the bar register for memory
|space access, and i am able to read and write to the card using a memory
|address of 10000000h;  seems to me that the processor must be running in
|real mode if i am able to do this;  yes?

Not necessarily, it could be running in protected mode with physical
memory mapped 1:1. Virtual memory mapping is something over and above
protected mode. Etherboot's protected mode simply gives access to the
CPU of all of memory as a flat space. The advantage of PM is of course
that one has a 32 bit processor.

Re: [Etherboot-developers] RE: [Etherboot-users] etherboot 32K si ze limitation

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

Jim Fredette <fre...@Za...> writes:

I'm just a kibitzer on etherboot so my opinion carries no weight...

> hi erik,
> thanks for the reply;  am i to understand that at the time my driver_probe
> entry point is executing, the processor is in protected mode?;  
yes 

> does my
> proposal for appending my firmware blob after the executable portion of the
> .rom image seem feasible?;  
Possibly.

> regarding your comment about extended bios's
> occupation of memory near a0000h, thanks;  do you feel it would be safe if i
> set RELOCADDR to 10000h, and then loaded the 105K .rom/firmware blob from
> that point? 

I don't know, I was just saying watch out...

Eric

Re: [Etherboot-developers] RE: [Etherboot-users] etherboot 32K size limitation

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

Jim Fredette <fre...@Za...> writes:

> hi ken,
> 
> thanks for the reply;  i read the documentation, and am sufficiently scared
> at this point to avoid making changes with regard to protected mode;
> however, i must come up with a solution;  again, i've got this 73K worth of
> giganet card firmware payload that must be somehow attached to, and be made
> available to the etherboot image;
> 
> i would appreciate your comments on my latest proposal to accomplish this:
> (using floppyload for development and testing)
> 
> i) the executable portion of the .rom image for my ethernet card is 32K;
> however, i would append on an additional 73K of firmware, making the total
> size 105K;
> ii) i would modify floppyload.S to load this 105K image by upping the
> SYSSIZE parameter, and by disabling the 64K byte boundary crossing check,
> label "die:" in the code;
> iii) i would change the etherboot RELOCADDR to 78000h, leaving me with 164K
> of space up to a0000h; 

Note many times you don't get all the way to a0000 because the
extended bios data area tends to live there.

>  the firmware would reside immediately after the
> executable etherboot image,  at 80000h; 
> iv) etherboot executable code, which again, is 32K in size,  ultimately
> exercises my driver's probe entry point, which can then read the firmware
> from 80000h and load it into the giganet card;  to do this last step, i
> assume that the processor must be running in protected mode ... but i'm
> almost positive that its not;  in that event, ie. in real-mode, is there a
> way that my probe routine can access this data that will certainly cross a
> 64K boundary?
> 
> another question:
> the giganet card's 16K of registers and memory is accessible via pci memory
> space (as opposed to i/o space for all other cards supported by etherboot);
> i pencilled-in some changes to pci.c to identify the bar register for memory
> space access, and i am able to read and write to the card using a memory
> address of 10000000h;  seems to me that the processor must be running in
> real mode if i am able to do this;  yes?

Nope.  You can't do that in ``real mode'' as that is 16 bit mode.  To do this
easily you just need to be in ``protected mode'', with virtual memory disabled.
The normal mode of operation for ehterboot.

You will want to check the memory size because you don't want to wire
in a window at 256MB.

Eric

[Etherboot-developers] RE: [Etherboot-users] etherboot 32K size limitation

[Jim F. <fre...@Za...>]

hi ken,

i just realized that i can't place my firmware payload immeadiately after
the .rom executable, because of the space requirement for the stack ... so,
i alter my proposal append a 3096 buffer to the .rom executable, and then
the firmware payload.

-jim fredette

-----Original Message-----
From: Ken Yap [mailto:ke...@nl...]
Sent: Monday, March 19, 2001 9:58 PM
To: eth...@li...
Cc: Jim Fredette; Vikram Biyani; Tomasz Barszczak; Olaf Manczak; Shankar
Iyer; Betsy Zeller
Subject: Re: [Etherboot-users] etherboot 32K size limitation 


>hi,
>i have run hard against the 32K byte size limitation for an etherboot rom
>image size while trying to add support for an ethernet card;  the main
>problem is that the particular ethernet chip on this card requires its 73K
>worth of firmware to be downloaded from the driver; which means, that the

Further discussion directed to etherboot-developers where it belongs.

With the current approach, there is a limit of close to 64kB on the
Etherboot code due to the way the real mode and protected mode code
share a stack.  Etherboot does not run totally in protected mode, it has
to switch to real mode for some services, like console output, memory
sizing, etc.  These are in first32.S.  You can read all about the way
the stack is shared in the latest developer manual at

	etherboot.sourceforge.net/doc/html/devman.html

To remove this limit you would have to make radical changes in the way
real mode services are called from protected mode.

loader.S is not the real problem (sorry bad pun), again read the
developer manual, once it has done its job, it's not a concern.

[Etherboot-developers] RE: [Etherboot-users] etherboot 32K size limitation

[Jim F. <fre...@Za...>]

hi ken,

thanks for the reply;  i read the documentation, and am sufficiently scared
at this point to avoid making changes with regard to protected mode;
however, i must come up with a solution;  again, i've got this 73K worth of
giganet card firmware payload that must be somehow attached to, and be made
available to the etherboot image;

i would appreciate your comments on my latest proposal to accomplish this:
(using floppyload for development and testing)

i) the executable portion of the .rom image for my ethernet card is 32K;
however, i would append on an additional 73K of firmware, making the total
size 105K;
ii) i would modify floppyload.S to load this 105K image by upping the
SYSSIZE parameter, and by disabling the 64K byte boundary crossing check,
label "die:" in the code;
iii) i would change the etherboot RELOCADDR to 78000h, leaving me with 164K
of space up to a0000h;  the firmware would reside immediately after the
executable etherboot image,  at 80000h; 
iv) etherboot executable code, which again, is 32K in size,  ultimately
exercises my driver's probe entry point, which can then read the firmware
from 80000h and load it into the giganet card;  to do this last step, i
assume that the processor must be running in protected mode ... but i'm
almost positive that its not;  in that event, ie. in real-mode, is there a
way that my probe routine can access this data that will certainly cross a
64K boundary?

another question:
the giganet card's 16K of registers and memory is accessible via pci memory
space (as opposed to i/o space for all other cards supported by etherboot);
i pencilled-in some changes to pci.c to identify the bar register for memory
space access, and i am able to read and write to the card using a memory
address of 10000000h;  seems to me that the processor must be running in
real mode if i am able to do this;  yes?

-thanks in advance, jim fredette

>hi,
>i have run hard against the 32K byte size limitation for an etherboot rom
>image size while trying to add support for an ethernet card;  the main
>problem is that the particular ethernet chip on this card requires its 73K
>worth of firmware to be downloaded from the driver; which means, that the

Further discussion directed to etherboot-developers where it belongs.

With the current approach, there is a limit of close to 64kB on the
Etherboot code due to the way the real mode and protected mode code
share a stack.  Etherboot does not run totally in protected mode, it has
to switch to real mode for some services, like console output, memory
sizing, etc.  These are in first32.S.  You can read all about the way
the stack is shared in the latest developer manual at

	etherboot.sourceforge.net/doc/html/devman.html

To remove this limit you would have to make radical changes in the way
real mode services are called from protected mode.

loader.S is not the real problem (sorry bad pun), again read the
developer manual, once it has done its job, it's not a concern.

Re: [Etherboot-developers] sis640e/sis730s support for etherboot sis900 driver

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

>I found folowing in my sis630e_get_mac_addr function:
>Eterboot doesn`t find the PCItoISA bridge with the scan_bus()-function 
>because the ioaddr of that device is 0x0000

Perhaps instead of inventing a new function you should delete the test
for ioaddr == 0 from the scan_bus function since it will still have to
pass the vendor and device ID tests anyway. I doubt if the ioaddr == 0
test catches any accidental matches.

Re: [Etherboot-developers] sis640e/sis730s support for etherboot sis900 driver

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

>>I have written a patch that adds sis640e / sis730s support to the etherboot 
>>sis900 driver. I have testet it on a board with sis730s chipset and an 
>>ics1893 phy.
>>
>>Peter Koegel                                            

Incidentally I made one small change, I made the two *get_mac_addr*
functions static.

Re: [Etherboot-developers] sis640e/sis730s support for etherboot sis900 driver

[Peter <pet...@to...>]

I found folowing in my sis630e_get_mac_addr function:
Eterboot doesn`t find the PCItoISA bridge with the scan_bus()-function 
because the ioaddr of that device is 0x0000

yesterday I've send a patch to Marty Connor who wrote the sis driver to test 
it.

Peter

[Etherboot-developers] Re: [Etherboot-users] etherboot 32K size limitation

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

>hi,
>i have run hard against the 32K byte size limitation for an etherboot rom
>image size while trying to add support for an ethernet card;  the main
>problem is that the particular ethernet chip on this card requires its 73K
>worth of firmware to be downloaded from the driver; which means, that the

Further discussion directed to etherboot-developers where it belongs.

With the current approach, there is a limit of close to 64kB on the
Etherboot code due to the way the real mode and protected mode code
share a stack.  Etherboot does not run totally in protected mode, it has
to switch to real mode for some services, like console output, memory
sizing, etc.  These are in first32.S.  You can read all about the way
the stack is shared in the latest developer manual at

	etherboot.sourceforge.net/doc/html/devman.html

To remove this limit you would have to make radical changes in the way
real mode services are called from protected mode.

loader.S is not the real problem (sorry bad pun), again read the
developer manual, once it has done its job, it's not a concern.