etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] World domination, anyone?

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

Marty Connor <md...@et...> writes:

> Hello Everyone,
> 
> I've been thinking about additions to Etherboot, and thinking about some of the
> recent discussions we've had, and thought I'd start a thread to discuss what new
> 
> directions people think are valuable. With the recent architecture and
> infrastructure improvements that Eric has worked so hard on, we have a
> springboard for some exciting new additions.
> 
> I'll start by listing some of the things that personally come to mind:
> 
And a few more off the top of my head and from the discussion.
        o Other architectures?
        o Update the Docmuentation
        o Multicast support in more drivers
        o Smaller ROM footprint 
          (Decompress and relocate and free memory < 1MB)
> 	o USB support
> 	o PCMCIA support
> 	o UNDI driver
> 	o PXE Support (FREEBSD_PXEEMU)
 
> Of the list, I think the last two interest me the most right now. We've talked
> about them for some time. The NILO project was working on a free PXE
> implementation, and there is some code there.

If the current code could be made to compile there would be a lot
more incentive to do the incremental steps needed to make it useable.
 
> The recent messages about getting PXELINUX to work with Etherboot sounded like
> fun. The UNDI driver discussion seemed interesting as well, though I need Peter
> or Vasil to explain how it works -- one more time :)
> 
> But what do you think?  If we went for PXE or UNDI, where are the big wins?

Improving PXEEMU to the point of usability without complicating the rest of the
code (as looks possible) is a risk mitigation thing.  If you already use PXE
you can switch to etherboot and all of your old setup can still work.

In addition a really good PXEEMU might be able to replace a vendors version
without qualms.

> I'm
> always thinking about ways Etherboot could be used by more people, and how we
> could become even more useful as a component technology.
> 
> Btw, this is much more than of theoretical interest. I'd like to see us
> implement something really cool for LinuxWorld Expo SF in August, and I may be
> able to swing some limited funding for some of this.

One nice thing is to work on etherboot.zdsk or etherboot-pci.zdsk.  And
have it print out the driver you need to build to support your NIC.
I think we have enough information in etherboot to do that now.
 
> Ok, so go ahead. What do you think would be cool to do? Could you do it? Do you
> know who could or would? And, most importantly, would it bring us closer to
> WoRLd DomINatIoN? ;)


Eric

Re: [Etherboot-developers] World domination, anyone?

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

"Timothy Legge" <tl...@ro...> writes:
> Way out there (is it even possible).  Supercomputer status diskless
> cluster?

One of my favorite lines, and the reason:
Been there, done that.

Eric

RE: [Etherboot-developers] World domination, anyone?

[Timothy L. <tl...@ro...>]

> Just think, Etherboot USB/PCMCIA support and LTSP-4 would be great
> for the world of diskless booting at Linux World.
> 

This has been on the to-do list for quite a while and it may be time to
tackle it.  I am not sure I have the time to dedicate to the subsystems,
but certainly the drivers.

RE: [Etherboot-developers] World domination, anyone?

[Timothy L. <tl...@ro...>]

> doing something in the docs - they seemed quite not to be uptodate at
> some places. But - there was a mailing some days ago that someone
> worked on them, wasn't it? What's the status over there?

The docs need work, especially the developer manual.  I am documenting
the process of porting a Linux driver as I go through the pcnet32 port.

Also the structure of source tree is so different in 5.1 that it should
be documented.  Also, we should document standards for where things go
(USB/PCMCIA).  Documentation of architecture difference would be good as
well.

RE: [Etherboot-developers] World domination, anyone?

[Timothy L. <tl...@ro...>]

> I'll start by listing some of the things that personally come to mind:
> 
> 	o USB support

I am interested in this area.  Right at the moment, I would be more
capable of porting the Pegasus driver than the subsystem.  The spec is
still gathering dust here.

> 	o PCMCIA support

I may have access to a Laptop in the near future and this may be of some
interest.  I suspect that supporting this with a hack (similar to the
3c515's ISAPNP) would be fairly easy.

> 	o UNDI driver
> 	o PXE Support
> 
???

> But what do you think?  If we went for PXE or UNDI, where are the big
> wins? I'm always thinking about ways Etherboot could be used by more
> people, and how we could become even more useful as a component
> technology.

To throw it out there is there any possibility of Etherboot replacing
PXE as a Standard?  

Also, if there was a way to end the need to tag kernels that would
probably win some points.

> Btw, this is much more than of theoretical interest. I'd like to see
us
> implement something really cool for LinuxWorld Expo SF in August, and
I
> may be able to swing some limited funding for some of this.

Cooler than booting an OS through a NIC? ;-)

> Ok, so go ahead. What do you think would be cool to do? Could you do
> it? Do you know who could or would? And, most importantly, would it
> bring us closer to WoRLd DomINatIoN? ;)
> 
Way out there (is it even possible).  Supercomputer status diskless
cluster?

Re: [Etherboot-developers] World domination, anyone?

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

Marty,

You've brought up some excellent ideas.  I'll comment on each below.


On Thu, 24 Apr 2003, Marty Connor wrote:

> Hello Everyone,
> 
> I've been thinking about additions to Etherboot, and thinking about 
> some of the recent discussions we've had, and thought I'd start a 
> thread to discuss what new directions people think are valuable. With 
> the recent architecture and  infrastructure improvements that Eric has 
> worked so hard on, we have a springboard for some exciting new 
> additions.
> 
> I'll start by listing some of the things that personally come to mind:
> 
> 	o USB support
> 	o PCMCIA support

I'll lump these 2 together, as they are kind of similar.

By offering etherboot support for USB and PCMCIA, that opens us
up to a whole new world of capabilities.  Booting from USB and PCMCIA
wireless cards is something I'd really like to see.


> 	o UNDI driver

I think I understand this to be a "generic" driver that PXE would load,
that wouldn't have to be written for any specific NIC.  It would talk
through some UNDI api to the pxe code.



> 	o PXE Support

What do you mean by PXE support ?  As I understand it, we already
have pxe support in the work that peter and Vasil have provided.

If you are thinking PXE instead of Etherboot, i'm not sure that
is a goal we need.


> 
> Of the list, I think the last two interest me the most right now. We've 
> talked about them for some time. The NILO project was working on a free 
> PXE implementation, and there is some code there.
> 
> The recent messages about getting PXELINUX to work with Etherboot 
> sounded like fun. The UNDI driver discussion seemed interesting as 
> well, though I need Peter or Vasil to explain how it works -- one more 
> time :)
> 
> But what do you think?  If we went for PXE or UNDI, where are the big 
> wins? I'm always thinking about ways Etherboot could be used by more 
> people, and how we could become even more useful as a component 
> technology.
> 
> Btw, this is much more than of theoretical interest. I'd like to see us 
> implement something really cool for LinuxWorld Expo SF in August, and I 
> may be able to swing some limited funding for some of this.
> 
> Ok, so go ahead. What do you think would be cool to do? Could you do 
> it? Do you know who could or would? And, most importantly, would it 
> bring us closer to WoRLd DomINatIoN? ;)


If you are looking to make a big splash at Linux world, I think that
PCMCIA or USB support is the thing that would make the biggest 
impression.  I just don't think that people would get excited about
UNDI or PXE.


As for who can do the work, i'll have to say that i'm happy to
provide opinions wherever possible, but i'm not likely to be of
much help during the next couple of months.  We are working like
crazy to get LTSP-4 out the door by LWCE.


Just think, Etherboot USB/PCMCIA support and LTSP-4 would be great
for the world of diskless booting at Linux World.

Thanks Marty, keep up the good work,

Jim McQuillan
ja...@Lt...

Re: [Etherboot-developers] World domination, anyone?

[Anselm M. H. <an...@ho...>]

Hello Marty,

Thursday, April 24, 2003, 8:26:39 PM, you wrote:

> I've been thinking about additions to Etherboot, and thinking about
> some of the recent discussions we've had, and thought I'd start a 
> thread to discuss what new directions people think are valuable. With 
> the recent architecture and  infrastructure improvements that Eric has 
> worked so hard on, we have a springboard for some exciting new 
> additions.

As you talk about it - something I had in mind the last days, as my PC
needs a reinstall anyway :-)

AFAIK there is some disk support there already. If one could tell
etherboot not to DHCP but have a standard filename argument (e.g.
pointing to a partition where a menu file is stored on), that again
could trampoline us to any partition boot - just a bootmanager then.
This is just an idea (so don't beat me please) - I think etherboot
could be altered as it accepts a default filename; if that starts with
dsk:// (or what was it? Have been away from it too long), no network
stuff is necessary. If that file's a menu, by returning a network
filename, network boot could be started at the second step, with a
predefined filename. This could be reasonable in cases where there is
a disk anyway and only very randomly network boot is needed - as I
wrote, only an idea. Probably this needed proper filesystem support,
so much to difficult in reality.

> But what do you think?  If we went for PXE or UNDI, where are the big
> wins? I'm always thinking about ways Etherboot could be used by more 
> people, and how we could become even more useful as a component 
> technology.

I'm not sure what PXE means exactly. I thought up to now, etherboot
can be loaded by PXE, unloads the PXE stack, loads its own drivers for
the card and does its stuff as usual - correct me if wrong. Would "PXE
support" mean instead of unloading the PXE stack using it - as
consequence, any PXE hardware would be supported?

> Btw, this is much more than of theoretical interest. I'd like to see us 
> implement something really cool for LinuxWorld Expo SF in August

Pity SF is just a third of the way round the earth from here and
RyanAir cheap flights are inner-European only :-(

> Ok, so go ahead. What do you think would be cool to do? Could you do 
> it? Do you know who could or would? And, most importantly, would it 
> bring us closer to WoRLd DomINatIoN? ;)

LiNuX rulez anyway. Who needs world domination? Quite a to great risk
someone doesn't like my face and sends his Marines for me ;-= The last
German to have those dreams coming partly true had birthday quite
yesterday, ya know? (Some neighbours like to celebrate that day, very
unlike me of course)

I'm in work up to the ears right now, but that's not to last more than
a week or three. I'd prefer honestly more than adding features myself
doing something in the docs - they seemed quite not to be uptodate at
some places. But - there was a mailing some days ago that someone
worked on them, wasn't it? What's the status over there?

Greetings,

Anselm

[Etherboot-developers] World domination, anyone?

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

Hello Everyone,

I've been thinking about additions to Etherboot, and thinking about 
some of the recent discussions we've had, and thought I'd start a 
thread to discuss what new directions people think are valuable. With 
the recent architecture and  infrastructure improvements that Eric has 
worked so hard on, we have a springboard for some exciting new 
additions.

I'll start by listing some of the things that personally come to mind:

	o USB support
	o PCMCIA support
	o UNDI driver
	o PXE Support

Of the list, I think the last two interest me the most right now. We've 
talked about them for some time. The NILO project was working on a free 
PXE implementation, and there is some code there.

The recent messages about getting PXELINUX to work with Etherboot 
sounded like fun. The UNDI driver discussion seemed interesting as 
well, though I need Peter or Vasil to explain how it works -- one more 
time :)

But what do you think?  If we went for PXE or UNDI, where are the big 
wins? I'm always thinking about ways Etherboot could be used by more 
people, and how we could become even more useful as a component 
technology.

Btw, this is much more than of theoretical interest. I'd like to see us 
implement something really cool for LinuxWorld Expo SF in August, and I 
may be able to swing some limited funding for some of this.

Ok, so go ahead. What do you think would be cool to do? Could you do 
it? Do you know who could or would? And, most importantly, would it 
bring us closer to WoRLd DomINatIoN? ;)

Marty

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

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

[Etherboot-developers] txfd structure definition difference between linux and etherboot eepro100.

[Ashish a. <ash...@in...>]

Hello,

I was trying to make eepro100.c ( IN ETHERBOOT) in my bootloader for tftp
download of my kernel image.


1. Etherboot version seems to be non-concerned about endianness issues so
i am trying to fix the passing of COMMAND and LINK fields of txfd and rxfd 
by using a cpu_to_le32 kind of macro.
have some body tested etherboot eepro100 driver on a big endian machine..?
and does it work fine for 82559 ( dev id 0x1229 vendor id 0x8086)..?
 

2.secondly i have also observed one objectionable issue betwwen linux
eepro100.c and etherboot one.

in etherboot the txfd and commandbits has been defined like,
 
in ETHERBOOT
enum commands {
        CmdNOp = 0, CmdIASetup = 0x10000, CmdConfigure = 0x20000,
        CmdMulticastList = 0x30000, CmdTx = 0x40000, CmdTDR = 0x50000,
        CmdDump = 0x60000, CmdDiagnose = 0x70000,
        CmdSuspend = 0x40000000,        /* Suspend after completion. */
        CmdIntr = 0x20000000,           /* Interrupt after completion. */
        CmdTxFlex = 0x00080000,         /* Use "Flexible mode" for CmdTx
command. */
};


and in LINUX version it is,
enum commands { 
  CmdNOp = 0,
  CmdIASetup = 1,
  CmdConfigure = 2,
  CmdMulticastList = 3,
  CmdTx = 4,
  CmdTDR = 5,
  CmdDump = 6,
  CmdDiagnose = 7,
  CmdSuspend = 0x4000,     
  CmdIntr = 0x2000,         
  CmdTxFlex = 0x0008, 
             };

in ETHERBOOT version the structure TxFD is 
static struct TxFD {
  volatile s16 status;
  s16 command; 
  u32 link;         
  u32 tx_desc_addr; 
  s32 count;        
                    
  u32 tx_buf_addr0; 
  s32 tx_buf_size0; 
  u32 tx_buf_addr1; 
  s32 tx_buf_size1;
) txfd;

in LINUX version ,

struct TxFD {                                   
        s32 status;
        u32 link;                               
        u32 tx_desc_addr;                      
        s32 count;                             
#define TX_DESCR_BUF_OFFSET 16
u32 tx_buf_addr0;          
        s32 tx_buf_size0;  
        u32 tx_buf_addr1;  
        s32 tx_buf_size1;  

};

my question is why in linux txfd there  is one single s32 status 
field instead of s16 status + s16 command field as in etherboot version..?


Best Regards,
Ashish Anand


in linux version TxFD structure defined like,

    

[Etherboot-developers] Re: [Etherboot-users] txfd structure definition difference between linux and etherboot eepro100.

[<ke...@us...>]

>1. Etherboot version seems to be non-concerned about endianness issues so
>i am trying to fix the passing of different 
>pointers between card and driver.
>
>2.secondly i have also observed one objectionable issue betwwen linux
>eepro100.c and etherboot one.

Both issues are because the author of the Etherboot driver based it on
an early Linux driver where the mistake was to assume that all the world
is a x86. The Linux driver repented of its endianness sin but the
Etherboot one remained in error.

>in etherboot the txfd and commandbits has been defined like,
> 
>in ETHERBOOT
>enum commands {
>        CmdNOp = 0, CmdIASetup = 0x10000, CmdConfigure = 0x20000,
>        CmdMulticastList = 0x30000, CmdTx = 0x40000, CmdTDR = 0x50000,
>        CmdDump = 0x60000, CmdDiagnose = 0x70000,
>        CmdSuspend = 0x40000000,        /* Suspend after completion. */
>        CmdIntr = 0x20000000,           /* Interrupt after completion. */
>        CmdTxFlex = 0x00080000,         /* Use "Flexible mode" for CmdTx
>command. */
>};
>
>
>and in LINUX version it is,
>enum commands { 
>  CmdNOp = 0,
>  CmdIASetup = 1,
>  CmdConfigure = 2,
>  CmdMulticastList = 3,
>  CmdTx = 4,
>  CmdTDR = 5,
>  CmdDump = 6,
>  CmdDiagnose = 7,
>  CmdSuspend = 0x4000,     
>  CmdIntr = 0x2000,         
>  CmdTxFlex = 0x0008, 
>             };

You have them swapped around actually.

>in ETHERBOOT version the structure TxFD is 
>static struct TxFD {
>  volatile s16 status;
>  s16 command; 
>  u32 link;         
>  u32 tx_desc_addr; 
>  s32 count;        
>                    
>  u32 tx_buf_addr0; 
>  s32 tx_buf_size0; 
>  u32 tx_buf_addr1; 
>  s32 tx_buf_size1;
>) txfd;
>
>in LINUX version ,
>
>struct TxFD {                                   
>        s32 status;
>        u32 link;                               
>        u32 tx_desc_addr;                      
>        s32 count;                             
>#define TX_DESCR_BUF_OFFSET 16
>u32 tx_buf_addr0;          
>        s32 tx_buf_size0;  
>        u32 tx_buf_addr1;  
>        s32 tx_buf_size1;  
>
>};
>
>why these two drivers using different structure for driving the same chip.

The Linux one is more correct because it allows the endianess to be
adjusted with a call to cpu_to_le32.

If you could fix the endian sensitivity by changing all the places that
use status and command to use a single 32 bit status field, that would
be a lovely contribution.  Thanks.

RE: [Etherboot-developers] Problems Booting 5.1 cvs

[Timothy L. <tl...@ro...>]

> >I will develop on 5.0 for now.  Hopefully someone can sort out the
> >vmware issue in 5.1
> 
> Did you use a .z?lilo image to fool VMWare into thinking it's a Linux
> image?

It never crossed my mind.  5.0 works from a floppy image generated via
make bin32/driver.fd0

Tim

Re: [Etherboot-developers] Problems Booting 5.1 cvs

[<ke...@us...>]

>Started.  The only pcnet card I have is a vmware virtual card.  That
>should be enough, but the current cvs for 5.1 does not work with
>Etherboot 5.1.  It reports that it is OS/2 or some other unsupported os.
>
>I will develop on 5.0 for now.  Hopefully someone can sort out the
>vmware issue in 5.1

Did you use a .z?lilo image to fool VMWare into thinking it's a Linux
image?

RE: [Etherboot-developers] Problems Booting 5.1 cvs

[Timothy L. <tl...@ro...>]

> If you are still hungry for work, a pcnet32 (32 bit Lance) driver
needs
> to be ported from Linux. The 24 bit Lance cannot be made relocatable
> without a lot of messiness, Linux has two drivers too.

Started.  The only pcnet card I have is a vmware virtual card.  That
should be enough, but the current cvs for 5.1 does not work with
Etherboot 5.1.  It reports that it is OS/2 or some other unsupported os.

I will develop on 5.0 for now.  Hopefully someone can sort out the
vmware issue in 5.1

Tim

Re: [Etherboot-developers] nothing after "Ramdisk at" on 5.1

[<ke...@us...>]

>With an rtl8139 and etherboot 5.1 from CVS, I get familair picture
>[lots of dots]
>mknbi-1.2-12/first32.c (ELF) (GPL)
>Top of ramdisk is 0X04000000
>Ramdisk at 0X03F43000, size 0X000BD000
>[cursor]
>
>and is frozen.
>
>To me it looks like a mismatch between eb-5.1 and mknbi-1.2.
>
>Are there successes reported with the new Etherboot and the old mknbi ?

What happens with mknbi-1.4.0?

Re: [Etherboot-developers] nothing after "Ramdisk at" on 5.1

[<Gee...@xs...>]

A while ago

Mon, Mar 03, 2003 at 10:05:55AM +1100,

> >A computer with a 5.1 etherboot
> >shows [lots of dots]
> >....done
> >rhine disable
> >mknbi-1.2-12/first32.c (ELF) (GPL)
> >Top of ramdisk is 0X04000000
> >Ramdisk at 0X03F4300, size 0X000BD000
> >[cursor]
> >
> >and is frozen
> >
> >The image is tagged with 'mkelf-linux'.
> >When using the same image with a 5.0.8, it works fine.
> >
> >Where should I solve this problem?
> >* 5.1.5 code?
> >* mknbi code?
>=20
> I think there were some fixes for the 5.1 Rhine driver after 5.1.5 for
> relocation.  5.1.6 is the latest dev release and there are also some
> updates only in CVS at the moment.
>=20

With an rtl8139 and etherboot 5.1 from CVS, I get familair picture
[lots of dots]
mknbi-1.2-12/first32.c (ELF) (GPL)
Top of ramdisk is 0X04000000
Ramdisk at 0X03F43000, size 0X000BD000
[cursor]

and is frozen.

To me it looks like a mismatch between eb-5.1 and mknbi-1.2.

Are there successes reported with the new Etherboot and the old mknbi ?


Geert Stappers

Re: [Etherboot-developers] files that CVS may ignore

[<ke...@us...>]

>The avoid all the outputlines that start with '? src/bin/',
>I made a cvs ignore file. IMHO it should go into CVS.

Ok, done.

Re: [Etherboot-developers] files that CVS may ignore

[<Gee...@xs...>]

On Sun, Apr 20, 2003 at 01:28:24PM +0200, Geert Stappers wrote:
> Hello,
>=20
> On a `cvs update` you will get a lot of warnings
> of unregistered files in the src/bin/ directory
>=20
> The avoid all the outputlines that start with '? src/bin/',
> I made a cvs ignore file. IMHO it should go into CVS.
>=20
> Could someone do
>=20
> echo "*.rom
> *.bin
> *.img
> *.zimg
> *.fi
*.dsk

> *.zfi
*.zdsk

> nrv2b" > src/bin/.cvsignore

So after "the eye opener" it should be

echo "*.rom
*.bin
*.img
*.zimg
*.dsk
*.zdsk
nrv2b" > src/bin/.cvsignore

>=20
> and commit it into the repository?
>=20
>=20
Geert Stappers

Re: [Etherboot-developers] no floppy drive on build system

[<Gee...@xs...>]

On Sun, Apr 20, 2003 at 09:12:58PM +1000, Ken Yap wrote:
> >+# rules to write the .img/.zimg image as a floppy image
> >+#  and put that image another way on a floppy disk
> >+# Give the directory name, e.g. bin/via-rhine-6105.fi as the target.
> >+%.fi:  %.img $(DISKLOADER) $(START16)
> >+       cat $(DISKLOADER) $(START16) $< > $@
> >+
> >+%.zfi: %.zimg $(DISKLOADER) $(START16)
> >+       cat $(DISKLOADER) $(START16) $< > $@
> >+
> >+# end of Makefile
> >
> >
> >Now I just type=3D20
> > make bin/my-nic.fi
> >and can continue directly with my work.
> >
> >When it is usefull for me, then it is probably usefull for others.
> >Could some please apply the patch?
>=20
> Er, that's what the .dsk and .zdsk targets already do just a few lines
> above.
>=20

Oops.
Thanks for opening my eyes.

Geert Stappers


>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>=20

[Etherboot-developers] files that CVS may ignore

[<Gee...@xs...>]

Hello,

On a `cvs update` you will get a lot of warnings
of unregistered files in the src/bin/ directory

The avoid all the outputlines that start with '? src/bin/',
I made a cvs ignore file. IMHO it should go into CVS.

Could someone do

echo "*.rom
*.bin
*.img
*.zimg
*.fi
*.zfi
nrv2b" > src/bin/.cvsignore

and commit it into the repository?


Geert Stappers

Re: [Etherboot-developers] no floppy drive on build system

[<ke...@us...>]

>+# rules to write the .img/.zimg image as a floppy image
>+#  and put that image another way on a floppy disk
>+# Give the directory name, e.g. bin/via-rhine-6105.fi as the target.
>+%.fi:  %.img $(DISKLOADER) $(START16)
>+       cat $(DISKLOADER) $(START16) $< > $@
>+
>+%.zfi: %.zimg $(DISKLOADER) $(START16)
>+       cat $(DISKLOADER) $(START16) $< > $@
>+
>+# end of Makefile
>
>
>Now I just type=20
> make bin/my-nic.fi
>and can continue directly with my work.
>
>When it is usefull for me, then it is probably usefull for others.
>Could some please apply the patch?

Er, that's what the .dsk and .zdsk targets already do just a few lines
above.

[Etherboot-developers] no floppy drive on build system

[<Gee...@xs...>]

Hello,

On the computer where I build the etherboot testfloppies,
I don't have a (working) floppy drive.

To avoid waiting on the anonying time-out message,=20
I modified a Makefile:

RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/arch/i386/Makefile=
,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- src/arch/i386/Makefile      9 Apr 2003 09:54:23 -0000       1.20
+++ src/arch/i386/Makefile      20 Apr 2003 10:38:58 -0000
@@ -274,3 +274,14 @@

 %.zfd0:        %.zimg $(DISKLOADER) $(START16)
        cat $(DISKLOADER) $(START16) $< > /dev/fd0
+
+# rules to write the .img/.zimg image as a floppy image
+#  and put that image another way on a floppy disk
+# Give the directory name, e.g. bin/via-rhine-6105.fi as the target.
+%.fi:  %.img $(DISKLOADER) $(START16)
+       cat $(DISKLOADER) $(START16) $< > $@
+
+%.zfi: %.zimg $(DISKLOADER) $(START16)
+       cat $(DISKLOADER) $(START16) $< > $@
+
+# end of Makefile


Now I just type=20
 make bin/my-nic.fi
and can continue directly with my work.

When it is usefull for me, then it is probably usefull for others.
Could some please apply the patch?


Geert Stappers

[Etherboot-developers] Re: [Etherboot-users] patch from 5.1.7 to 5.1.8rc1

[Georg B. <Geo...@po...>]

Am Samstag, 19. April 2003 03:46 schrieb Ken Yap:
> >For my Problem, I've wrote it to the list few day's ago, this patch
> >does not help. For me it's very imortant that the eepro100.lzpxe + an
> >dos tagged image works, but against the realy good working
> >3c905c.lzpxe it hard hangs directly after the start of the dos tagged
> >image. It works great for the 3com nic's but the eepro100 onboard nic
> >of my compaq en sff machines it doesn't work for all I have done.
>
> The e100 driver can be found in recent 2.5 kernel sources. If somebody
> could hack this in (with the obvious changes to register names etc) and
> let us know if it helps, that would be good.

Sebastian, try the attached patch. Note that it is untested since I have no 
DOS image.

Georg

[Etherboot-developers] Re: [Etherboot-users] patch from 5.1.7 to 5.1.8rc1

[<ke...@us...>]

>For my Problem, I've wrote it to the list few day's ago, this patch
>does not help. For me it's very imortant that the eepro100.lzpxe + an
>dos tagged image works, but against the realy good working
>3c905c.lzpxe it hard hangs directly after the start of the dos tagged
>image. It works great for the 3com nic's but the eepro100 onboard nic
>of my compaq en sff machines it doesn't work for all I have done.

The eepro100.c driver in both Etherboot and Linux is unusual in the way
the close is done, it issues a PortPartialReset.  However a look at the
e100/ which is the driver Intel released, shows that this driver does
more. A *_close calls e100_sw_reset with reset_cmd ==
PORT_SELECTIVE_RESET:

e100_sw_reset(struct e100_private *bdp, u32 reset_cmd)
{
        /* Do  a selective reset first to avoid a potential PCI hang */
        writel(PORT_SELECTIVE_RESET, &bdp->scb->scb_port);
        readw(&(bdp->scb->scb_status)); /* flushes last write, read-safe */

        /* wait for the reset to take effect */
        udelay(20);
        if (reset_cmd == PORT_SOFTWARE_RESET) {
                writel(PORT_SOFTWARE_RESET, &bdp->scb->scb_port);

                /* wait 20 micro seconds for the reset to take effect */
                udelay(20);
        }

        /* Mask off our interrupt line -- its unmasked after reset */
        e100_dis_intr(bdp);
}

PORT_SELECTIVE_RESET == PortPartialReset (different names for the same
constant in different drivers).  The interesting bit is the last
operation and the comment.  Linux doesn't seem to mind finding the NIC
after a PortPartialReset but it could be that the DOS driver doesn't
like finding interrupts unmasked after it loads. Perhaps Etherboot
should issue a disable interrupts too.  This is done in the e100 by:

static inline void
e100_dis_intr(struct e100_private *bdp)
{
        /* Disable interrupts on our PCI board by setting the mask bit */
        writeb(SCB_INT_MASK, &bdp->scb->scb_cmd_hi);
        readw(&(bdp->scb->scb_status)); /* flushes last write, read-safe */
}

The e100 driver can be found in recent 2.5 kernel sources. If somebody
could hack this in (with the obvious changes to register names etc) and
let us know if it helps, that would be good.

[Etherboot-developers] Re: [Etherboot-users] Problem on FREEBSD_PXEEMU

[<ke...@us...>]

>  stdint.h:4: redefinition of `uint8_t'
>  /usr/include/sys/types.h:84: `uint8_t' previously 
>declared 
>  here
>  stdint.h:5: redefinition of `uint16_t'
>  /usr/include/sys/types.h:89: `uint16_t' previously 
>  declared here
>  stdint.h:6: conflicting types for `uint32_t'
>  /usr/include/sys/types.h:94: previous declaration of 
>  `uint32_t'
>  stdint.h:7: redefinition of `uint64_t'
>  /usr/include/sys/types.h:99: `uint64_t' previously 
>  declared here
>  stdint.h:9: redefinition of `int8_t'
>  /usr/include/sys/types.h:64: `int8_t' previously 
>declared 
>  here
>  stdint.h:10: redefinition of `int16_t'
>  /usr/include/sys/types.h:69: `int16_t' previously 
>declared 
>  here
>  stdint.h:11: conflicting types for `int32_t'
>  /usr/include/sys/types.h:74: previous declaration of 
>  `int32_t'
>  stdint.h:12: redefinition of `int64_t'
>  /usr/include/sys/types.h:79: `int64_t' previously 
>declared 
>  here
>  main.c: In function `default_netmask':
>  main.c:438: warning: implicit declaration of function 
>  `ntohl'
>  main.c:440: warning: implicit declaration of function 
>  `htonl'
>  main.c: In function `udp_transmit':
>  main.c:463: warning: implicit declaration of function 
>  `htons'
>  main.c: In function `tftp':
>  main.c:700: warning: implicit declaration of function 
>  `ntohs'
>  gmake: *** [bin32/main.o] Error 1

Somebody really needs to fix up the FREEBSD_PXEEMU code to use private
include files instead of system includes.  This will also give the code
a chance to compile on non-FreeBSD systems. Any takers from the FreeBSD
community?

[Etherboot-developers] Re: [Etherboot-users] patch from 5.1.7 to 5.1.8rc1

[loki d. q. <lok...@we...>]

now having nice success on dell 2650s with tg3 driver.

thanks very much for everyone's work and help.
loki


On Wednesday, April 16, 2003, at 03:54 AM,  
ke...@us... wrote:

> In order to give 5.1.8 (development branch) wider testing, I have
> uploaded a patch from 5.1.7 to 5.1.8rc1 at this URL:
>
> http://sourceforge.net/tracker/ 
> index.php?func=detail&aid=722329&group_id=4233&atid=304233
>
> This will make it easier for people to test it without access to CVS.
> You need compiler tools though.  Please report successes and problems  
> to
> the developers list.
>
> Preemptive FAQs:
>
> You want to do "make bin/3c509.zdsk" or "make bin/3c509.zfd0" for
> example, not make bin32/3c509.lzdsk, etc.
>
> The EEPRO100 timing patch hasn't been included yet, you can get them
> from a mail by Georg Baum of about a week ago.
>
> You need to retag the kernel with a recent mknbi if you are trying to
> boot LTSP.
>
> Etherboot will not respond to DHCP offers without a filename; this is
> expected.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etherboot-users mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-users
>