etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Allocating memory...

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

>void *allot(size_t size);
>void forget(void *ptr);

Do you perhaps need a second argument to allot to be able to allocate in
different arenas, say under 1 MB, under 16 MB (for ISA DMA), and
anywhere else? Or maybe jsut the first and third categories.

[Etherboot-developers] Allocating memory...

[Eric W B. <ebi...@ln...>]

If for nothing else except the multicast there is a need to allocate
memory in etherboot.  Implementing malloc and free is completely overkill for
the problem.  GNU obstacks are close to what I want but have the potential
to be confused normall malloc and free.  So I have dug out my FORTH
references and have found another set of names.

void *allot(size_t size);
void forget(void *ptr);

allot allocates memory of a given size with a worst case alignment
just like malloc, but memory is freed differently.

forget frees the indicated object and all other ojbects allocated
after the indicated object.

allot and forget work with a stack instead of the more common
random access heap.  Using a stack allows a much simpler allocation
and freeing code (push,pop).  Management is much simpler because
you can generally allot and not explictly forget the memory.  Just
so long as you aren't restarted without forgetting there isn't a
memory leak.

Eric

Re: [Etherboot-developers] Etherboot 5.0.7 (production) released

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

On Wed, 31 Jul 2002 ke...@us... wrote:
> Major changes from 5.0.6:
> More useful DHCP behaviour: ignores useless DHCPOFFERs (those without
> client IP address or boot file).
> New drivers: for wireless NICs based on the Prism2 chipset, and the
> 3c515.
> Improved driver: for the SMC EtherEZ using PIO mode.
> New config entries: for more EEPro100 models. Fixed config entry for
> Comet 983.
> Bug fixes: for rtl8139 driver, 3c90x driver, SiS900 driver and cs89x0
> driver.
> Better memory detection: for INT15H/E801 method.
> New behaviour: sends PCI and ISA PnP identifiers in DHCPREQUEST.

"Use of DHCP encapsulated options"?

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

[Etherboot-developers] rom-o-matic.net updated to Etherboot 5.0.7, source code released GPL

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

I have updated http://www.rom-o-matic.net/ to support Etherboot version 5.0.7.

Also, for those who are interested, I have released the source code for
the rom-o-matic.net site.  It is available via the Etherboot project
page, which is at 

   <http://sourceforge.net/projects/etherboot>.

I hope for and expect others to set up rom-o-matic-like sites, and to
make and share improvements to the code so that lots of people can
benefit. It is a privilege to run a site that provides a useful service
and has proven extremely popular to the community.  Thanks for the
opportunity.

Here's the README file for the initial release of the rom-o-matic source
code.  

Enjoy.  

See you at LinuxWorld Expo, SF Aug 12-15 2002 http://
www.linuxworldexpo.com/ :)

Marty

--- Included file begins ---

This is the README file for rom-o-matic source code.

LEGAL

   Copyright (C) 2002 Entity Cyber, Inc.

   Author: Marty Connor (md...@en...) (http://www.entity.com/)

   This software may be used and distributed according to the terms
   of the GNU Public License (GPL), incorporated herein by reference.

   This file must accompany any redistribution.

   Home site for Etherboot: http://www.etherboot.org/

WHY

I am releasing the code for the rom-o-matic.net because I think it
will help make the world a better place.  I am releasing it under the
GPL because I believe in Free Software, and I believe in the things
that the GPL asks of people and gives in return. I want improvements
to the rom-o-matic code to benefit everyone.  I act freely, in
accordance with my beliefs.

Please use and enjoy this software.  I am happy to release it to the
Free Software community.  I ask that you abide by the terms of the GPL
in letter and spirit, and use it carefully and wisely.

WHAT IT IS

http://www.rom-o-matic.net/ is a site I created to allow Etherboot
users (http://www.etherboot.org/) to create ROM images without having
to download the Etherboot distribution and compile their own images.

Basically, it is a a web form that communicates via PHP with a server
and compiles a requested piece of code, delivering it to the
requesting user immediately.

The rom-o-matic code consists of a set of PHP and configuration files
that reside on an Apache (http://www.apache.org/) web server and when
activated by a web server create and send a ROM image file to a user.

In about two years of operation, (October 2000 - August 2002)
http://www.rom-o-matic.net/, running this software, has served over
120,000 free Etherboot ROM images to users worldwide.

WHAT YOU NEED TO USE IT

In order to install and use rom-o-matic source code, the following is
required: 

   - X86 architecture Linux box

   - Apache web server running with PHP4 enabled

   - kgcc or a version of gcc that is not 2.96 installed on server
     machine (gcc 2.96 does not compile Etherboot properly)

I'm not going to describe how to install PHP here. There are plenty of
places where you can find out how to do that.  You also need to know
how to set up Apache, and that is also easy to find out.  Many Linux 
distributions come set up and ready to go.  Sometimes distributions do
not enable PHP by default, or you'll need to add .php3 as an extension
that is recognized as a PHP file.

HOW TO SET IT UP

Let's say your web server files are in

      /var/www/html

I suggest putting the contents of tar file there with something like:

      $ cd /var/www/html/
      $ tar -zxvf ~/rom-o-matic-5.0.6.tar.gz
      $ cd rom-o-matic-5.0.6

You'll get something that looks like this:

      $ ls
      COPYING      latest-production-release   top.php3     
      5.0.6        index.php3                  mieprobs.php3
      bottom.php3  latest-development-release  README
      
Now you'll need an Etherboot distribution.  Download the tar file for
Etherboot-5.0.6.tar.gz.

Unpack it:

      $ tar -zxvf ~/etherboot-5.0.6.tar.gz

Now move the src directory of the just unpacked Etherboot distribution to the
appropriate place:

      $ mv etherboot-5.0.6/src  5.0.6/src-5.0.6

Now copy the file 5.0.6/Config.template-5.0.6 to 5.0.6/src-5.0.6/
Config.template

      $ cd 5.0.6
      $ cp Config.template-5.0.6 src-5.0.6/Config.template

and that should do it.

You now should be able to point your web browser to:

      http://www.YOURWEBSERVERNAMEHERE.net/rom-o-matic-5.0.6/

and get a rom-o-matic Etherboot form.

TROUBLESHOOTING

Obviously there are a lot of things that could go wrong, and this
process is not for newbies.  You might not have kgcc installed.  You
might have your apache server misconfigured or configured not to allow
PHP, or have an older version of PHP.

If you have problems, you might ask on the Etherboot-Users mailing
list (see mailing lists on http://www.etherboot.org/) there is also an
archive of the mailing list.  I and others who read the list will help
as we can.

I don't have much time to answer direct emails about rom-o-matic, but
fan mail is always welcome (md...@et...) ;) I'll do the best I
can. 

THANKS

I thank all Etherboot users and developers, especially Ken Yap and
Markus Gutschke of the Etherboot project for their help and
friendship, and I thank my wife, Julie for her constant support and
wise counsel.

Marty Connor
md...@et...
md...@en...

--- Included file ends ---

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

[Etherboot-developers] Etherboot 5.0.7 production at rom-o-matic

[Boris R. <bo...@th...>]

Excellent...The latest etherboot is out!! Will rom-o-matic update their website now with the latest 5.0.7?

[Etherboot-developers] Etherboot 5.0.7 (production) released

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

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

Thanks are due this round to: Michael Brown, Timothy Legge,  Andrew
Bettison, Michael Rendell, Richard Chan, Samuel Clemens, Eric Biederman,
Fotis Andritsopoulos, and Patrik Weiskircher. And as always, thanks to
Marty Connor for the rom-o-matic site.

Major changes from 5.0.6:

More useful DHCP behaviour: ignores useless DHCPOFFERs (those without
client IP address or boot file).

New drivers: for wireless NICs based on the Prism2 chipset, and the
3c515.

Improved driver: for the SMC EtherEZ using PIO mode.

New config entries: for more EEPro100 models. Fixed config entry for
Comet 983.

Bug fixes: for rtl8139 driver, 3c90x driver, SiS900 driver and cs89x0
driver.

Better memory detection: for INT15H/E801 method.

New behaviour: sends PCI and ISA PnP identifiers in DHCPREQUEST.

MD5 sums:

6ca11d70fbf0bfac90a4635bf8ec3444  etherboot-5.0.7.tar.bz2
4629deaa5a11ceaed49efc5cfacaa4ae  etherboot-5.0.7.tar.gz

SHA1 sums:

af2bd5a0e8c6b9eff8377faa9329e955b0bf0b84  etherboot-5.0.7.tar.bz2
11e9a08c99b8abf87d61bcf11992201c5297f99b  etherboot-5.0.7.tar.gz

Marty (and maybe Markus) will be demonstrating at the Linuxworld Expo
Aug 12-15 (http://www.linuxworldexpo.com/). Drop by and say hello.

[Etherboot-developers] rom-o-matic 5.0.7 released

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

Marty Connor has kindly released the PHP source for rom-o-matic under
the GPL. You can find it in the release area now. Here are notes from
the README:

This is the README file for rom-o-matic source code.

LEGAL

   Copyright (C) 2002 Entity Cyber, Inc.

   Author: Marty Connor (mdcATSIGNentity.com) (http://www.entity.com/)

   This software may be used and distributed according to the terms
   of the GNU Public License (GPL), incorporated herein by reference.

   This file must accompany any redistribution.

   Home site for Etherboot: http://www.etherboot.org/

WHY

I am releasing the code for the rom-o-matic.net because I think it
will help make the world a better place.  I am releasing it under the
GPL because I believe in Free Software, and I believe in the things
that the GPL asks of people and gives in return. I want improvements
to the rom-o-matic code to benefit everyone.  I act freely, in
accordance with my beliefs.

Please use and enjoy this software.  I am happy to release it to the
Free Software community.  I ask that you abide by the terms of the GPL
in letter and spirit, and use it carefully and wisely.

WHAT IT IS

http://www.rom-o-matic.net/ is a site I created to allow Etherboot
users (http://www.etherboot.org/) to create ROM images without having
to download the Etherboot distribution and compile their own images.

Basically, it is a a web form that communicates via PHP with a server
and compiles a requested piece of code, delivering it to the
requesting user immediately.

The rom-o-matic code consists of a set of PHP and configuration files
that reside on an Apache (http://www.apache.org/) web server and when
activated by a web server create and send a ROM image file to a user.

In about two years of operation, (October 2000 - August 2002)
http://www.rom-o-matic.net/, running this software, has served over
120,000 free Etherboot ROM images to users worldwide.

[Etherboot-developers] Windows DHCP and TFPT Servers

[Aaron G. <aar...@be...>]

Hello,
    I was wondering whether there is a general DHCP servers availiable for
Windows, for versions of Windows that do not have DHCP, ie 95/98/ME and XP ?
Preferably with source code. There is the ISC's reference version but that
does not seem to have been tested on Windows.

I am also looking for a TFTP Server for Windows also. Again preferably with
source.

Many thanks in advance,

Aaron Gray

[Etherboot-developers] IDE implementation ramblings....

[Eric W B. <ebi...@ln...>]

Starting with the IDE driver that has been in various etherboot
patches I am successfully booting from ide.  Hopefully I will check
this in the next couple of days.

IDE is a strange beast.  Reading and writing to a drive is easy.

Reliably finding a drive immediately after power up is hard.
Especially if you don't want to wait 31 seconds which is the worst
case drive spinup time.  The problem is that IDE drives don't respond
to any commands until after they have spunup.  And the maximum legal
spinup delay is 31 seconds so there is quite a wait before a command
can be said to have failed.

So I don't have to wait 31 seconds in every case I depend on the BSY
bit being set on the drive during spinup.  And then I just wait for
that bit to clear.  According to the IDE spec, IDE drives must set
their BSY bit during spinup, and on every board I have tested this
works the IDE controller relays this bit.  But I have reports this
technique does not work on every board.

Past that I weed out a lot of false positives, by writing 
multiple drive registers with different values, reading them back, and
seeing if any of the values are different.  This quickly weeds out
empty cables and the like.  So only in very rare circumstances do I
need to worry about waiting for a full command timeout to detect a
drive is actually missing from the system.

I don't plan to implement drive speed tuning.  For boot up that should
not be an issue.  I don't do DMA transfers either but that is just
because the PIO transfers are trivial to setup, and since I
performance isn't a major objective this shouldn't be an issue.

There are still a lot of pieces of the code that need little bits of
attention before it integrates in well with etherboot.  Roughly I need
to make IDE a layer like pci, or ISA_PNP.  And put my ide_disk code on
top of that, allowing for further developments like cdrom support.
Plus I need to implement code to actually find the image to boot on
the hard drive instead of just hard coding a fixed offset. 

But as I take the little problems one at a time they all seem to have
pretty decent solutions so I'm not to worried.

Sizewise the ide driver has about a 2k text section.  So it is about
the same size as a NIC driver.  So no extraordinary size impacts are
present.

Eric

Re: [Etherboot-developers] MOTD options?

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

>Is it worth leaving in the ability to print simple, text-only MOTDs direct
>from Etherboot?  I have found text MOTDs to be very useful in debugging
>DHCP server / Etherboot configuration problems.

If you mean debug whether the right image was loaded, I organise my
tftpboot directory this way:

dhcpd.conf contains

host burner {
	...
	filename "burner.nb"
	...
}

and in tftpboot I have a symbolic link from burner.nb to the real image,
which may be shared amongst several machines.  This way the filename
displayed reflects the machine identity and not the image loaded. It
also allows me to switch the images for testing without having to
restart dhcpd.

With the external menu you could even go further, you could make it
display all the fields of interest in the DHCP reply if you wanted.

Will this suffice?

Re: [Etherboot-developers] Etherboot 5.0.7 release planning

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

>Are external menus stable and complete (i.e. can I do everything with an
>external menu that I can do with an internal menu and expect it to work)?
>I have some systems that currently make heavy use of the internal menus
>(ANSI graphics sequences, lots of TFTP-included files eg. icons) - if the
>external menu code is already able to support this then I'll migrate now
>instead of waiting for 5.2.

The external menu code does everything internal menu does (as it's the
same code) except for two aspects: TFTP includes, and being able to
specify the server and gateway in the tag. You can implement icons by
attaching a resource segment to external menu code, say starting at
0x20000. E.g. bundle the icons in some sort of archive format and then
add routines to the menu code to find icons by name from the resource
segment.

Refinement of the menu code or development of alternative menu programs
is encouraged since it's no longer tied to Etherboot development and you
can fix menu code problems without worrying about how to upgrade ROMs in
the field.

Re: [Etherboot-developers] MOTD options?

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

On Fri, 26 Jul 2002, Ken Yap wrote:
> >In 5.1.2 we are requesting MOTD options but are never using
> >them anyway.  Is this something we still want to request?
> No. The menu options aren't needed either.

Is it worth leaving in the ability to print simple, text-only MOTDs direct
from Etherboot?  I have found text MOTDs to be very useful in debugging
DHCP server / Etherboot configuration problems.

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] Etherboot 5.0.7 release planning

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

On Sat, 27 Jul 2002, Ken Yap wrote:
> >BTW, was the external menu stuff added to the stable branch?  I got the
> >impression that it was going into 5.1.x but the Config file for 5.0.7
> >suggests otherwise.
> The external menu code went into mknbi-1.2-8. 5.0 will still support
> internal menus but no longer by default. 5.1 will only have external
> menus.

Are external menus stable and complete (i.e. can I do everything with an
external menu that I can do with an internal menu and expect it to work)?
I have some systems that currently make heavy use of the internal menus
(ANSI graphics sequences, lots of TFTP-included files eg. icons) - if the
external menu code is already able to support this then I'll migrate now
instead of waiting for 5.2.

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] Etherboot 5.0.7 release planning

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

>BTW, was the external menu stuff added to the stable branch?  I got the
>impression that it was going into 5.1.x but the Config file for 5.0.7
>suggests otherwise.

The external menu code went into mknbi-1.2-8. 5.0 will still support
internal menus but no longer by default. 5.1 will only have external
menus.

Re: [Etherboot-developers] Etherboot 5.0.7 release planning

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

On Tue, 16 Jul 2002, Michael Brown wrote:
> > Barring serious problems, I'm planning on releasing 5.0.7 at the end of
> > July. If you have stuff you have not checked into contrib/ (Michael) or
> > patches you have not verified (the Natsemi blues guy and Marty), please
> > start the ball rolling or those changes will have to go into the patches
> > area or held over for 5.0.8. Thanks.
> Thanks for the warning.  I'll be updating initrd in contrib/ - no other
> changes planned.

Now checked in.  initrd stuff now uses the new binary nic-dev-id
structure.

BTW, was the external menu stuff added to the stable branch?  I got the
impression that it was going into 5.1.x but the Config file for 5.0.7
suggests otherwise.

Michael Brown
http://www.fensystems.co.uk
--
Fen Systems: Linux made easy for schools

Re: [Etherboot-developers] last call for 5.0.7 check-ins

[Eric W B. <ebi...@ln...>]

"Timothy Legge" <tl...@ro...> writes:

> > Timothy, does it hurt if ISA_PNP is always defined when compiling
> > 3c515.c? I.e. are BIOS detection and driver detection mutually
> > exclusive? If not you could add it to 3C515FLAGS and it will be used
> > when compiling that file. If yes, perhaps in 5.0.8, the code could check
> > if BIOS detection has been done and if not, do its own detection.
> 
> I will look into it, but it won't be until next week.  I suspect that I can
> do something to make it work without the define.  However, ISA_PNP is not
> supposed to be used if the PC's BIOS already enabled the card.

There are two cases of interest here.  
Using ISA_PNP to detect the card, but not set it's resources
  (because the BIOS already has).
Setting the resources on a card that the BIOS neglected, to handle. 

Unless I have missed a detail ISA_PNP for detection should always work.

Allocating I/O ports on the fly is a very interesting exercise, because
you have to avoid everything that has already been allocated.  Which
in a primarily ISA system can be a challenge to figure out.  

The same problem can theoretically also affect PCI devices so the
solution needn't be PNP_ISA specific.  Say something like.
-DALLOCATE_RESOURCES
And we compile in a resource allocator that does it's best to come up
with a non-conflicting device address if the device doesn't have
resources allocated to it.

A card specific hack that assigns some hard coded I/O address may
be smaller and more manageable.  Especially if we disable the device
and remove the resource allocations when we are done with it.

Eric

Re: [Etherboot-developers] Re: Pushing LinuxBIOS inspired changes back to etherboot.

[Eric W B. <ebi...@ln...>]

ollie lho <ol...@si...> writes:

> Well, we encountered various problems with those flash IDE devices.
> These device works fine under Linux but have problems with etherboot.

Ah, interesting.  Definitely something worth looking into then.

> I saw this on Etherboot mail list archive last week. So you use virtual
> memory to achieve relocation ?? BTW, how do you remap physical memory
> to virtual memory ?? Identical mapping ??

I implement it with a flat 32bit segment with a non-zero base.  But
in practice I am using virtual addresses, and could implement it with
a page table I just don't yet.


> > 2) I have ported the compressor to 32bit code allowing the LinuxBIOS
> >    etherboot romimage to be self uncompressing.  
> > 3) I have done most of the work so that the etherboot drives will now
> >    use virt_to_bus, bus_to_virt && ioremap allowing them to be
> >    portable.
> 
> One problem of the GRUB file system code (or Etherboot itself) is that
> it has no idea of memory allocation nor virtual address space. For
> example, it used a predefined FSYSxxx as a pointer to some physical
> address and uses it as buffer for disk I/O, I believe there are various
> other places in the code which assume logical address == physical
> address.

Ouch!  In the core of etherboot I have removed all of the assumptions,
but I haven't walked through all of the drivers yet.  FSYS comes from the
borrowed grub code.  Basically if you need an absolute addresses
virt_to_phys/phys_to_virt will let you use it.  

So far I only know of one case in etherboot where I actually need a
memory allocator (The multicast download code).  Dynamic memory
allocation is definitely something that is handy but at the same time
if the problem can be solved with static buffers, you probably have a
less error prone solution so I am approaching it cautionsly. 

What I want is something more in the line the GNU obstack malloc
variant then a full general purpose malloc.  Especially the ability to
free everything after a certain point is very handy.  Plus it keeps
from making promises we really can't keep.

> > 4) I have discussed on the mailing list and have gotten some approval
> >    on how to do disk support when configuration via DHCP is in
> >    control.  Basically: ``filename "file::///disk0"'' or if we have a
> >    filesystem, "file:///disk0/{partion number}/{filesystem path}
> 
> IIRC, I proposed something similiar on the list long time ago, we need
> something like URL for both networked and filesystem boot.
> 
> > 5) I have incorporated your windows ce loader into etherboot, though
> >    it isn't as clean as it might be.
> > 
> > As for menuing and how to be more interactive with users as your code
> > does I'm not certain.  But take each each issue up on the list and I
> > am fairly certain we can work something out.
> > 
> 
> I have no idea if the interactive mode is vital for general users. It
> is good for us to debugg since 550 does not have a serial port, I 
> believe we will remove all the interactive stuff in the production
> image.

At the simplest I have the requirement to at least be able to use
a CMOS setting instead of DHCP request so there is the stand alone
boot.

If you are not interactive I don't see how being able to boot off
of a filesystem actually helps.  And I had someone point out an
interesting advantage of a lilo type scheme to me.  With lilo you know
if your new kernel can be found before you reboot :)  

I don't think interaction is bad perse but it does take some changes.

Eric

RE: [Etherboot-developers] last call for 5.0.7 check-ins

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

> Timothy, does it hurt if ISA_PNP is always defined when compiling
> 3c515.c? I.e. are BIOS detection and driver detection mutually
> exclusive? If not you could add it to 3C515FLAGS and it will be used
> when compiling that file. If yes, perhaps in 5.0.8, the code could check
> if BIOS detection has been done and if not, do its own detection.

I will look into it, but it won't be until next week.  I suspect that I can
do something to make it work without the define.  However, ISA_PNP is not
supposed to be used if the PC's BIOS already enabled the card.

Tim

Re: [Etherboot-developers] Re: Pushing LinuxBIOS inspired changes back to etherboot.

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

>Are you working on 5.0 or 5.1 ?? I got no clue about your work from
>ViewCVS.

Eric's working on 5.1. Odd minor numbers are broken-edge development.

The work that Eric's done on relocation of Etherboot simultaneously
removes several limitations:

+ 48kB limit on execution footprint.
+ Need to run in 0x80000-9x9ffff zone, which competes with
many Flash BIOS extensions.
+ Assumption that physmem = virtmem.
+ Etc.

I'd give him a medal if I could.

[Etherboot-developers] Re: Pushing LinuxBIOS inspired changes back to etherboot.

[ollie l. <ol...@si...>]

On Fri, 2002-07-26 at 13:54, Eric W Biederman wrote:
> 
> Currently I have cvs access, and etherboot has a cvs development
> branch open on sourceforge that I have been pushing my changes into
> when the look like the will work.  I don't intend to stop until
> everything works again but there has been a little bit of breakage.
> 

Are you working on 5.0 or 5.1 ?? I got no clue about your work from
ViewCVS.

Ollie

[Etherboot-developers] Re: Pushing LinuxBIOS inspired changes back to etherboot.

[ollie l. <ol...@si...>]

On Fri, 2002-07-26 at 13:54, Eric W Biederman wrote:
> > 
> > > Though it should be noted that working with different drives and
> > > different controlles seems to give some noticeably different results
> > > so even after the code looks solid to everyone we need to keep our
> > > eyes peeled for a while.
> > > 
> > 
> > I think a proper controller driver and Identify/Set feature sequence
> > is necessary to to cope with various IDE drives.
> 
> In this case all I have identified so far is the need for proper error
> checking :) But we will see.
> 

Well, we encountered various problems with those flash IDE devices.
These device works fine under Linux but have problems with etherboot.

> Let me summarize for you what changes I have been making to support
> LinuxBIOS better, in etherboot.  And we can figure out where to work
> your stuff in from there.
> 
> Currently I have cvs access, and etherboot has a cvs development
> branch open on sourceforge that I have been pushing my changes into
> when the look like the will work.  I don't intend to stop until
> everything works again but there has been a little bit of breakage.
> 
> 1) I have added relocation code so that etherboot now will relocate
>    itself to the top of memory after it has loaded, and I have done
>    most of the surgery so this works with normal etherboot as well.
>    With the relocation code in place we are free to expand the code
>    size of etherboot to > 64K.

I saw this on Etherboot mail list archive last week. So you use virtual
memory to achieve relocation ?? BTW, how do you remap physical memory
to virtual memory ?? Identical mapping ??

> 2) I have ported the compressor to 32bit code allowing the LinuxBIOS
>    etherboot romimage to be self uncompressing.  
> 3) I have done most of the work so that the etherboot drives will now
>    use virt_to_bus, bus_to_virt && ioremap allowing them to be
>    portable.

One problem of the GRUB file system code (or Etherboot itself) is that
it has no idea of memory allocation nor virtual address space. For
example, it used a predefined FSYSxxx as a pointer to some physical
address and uses it as buffer for disk I/O, I believe there are various
other places in the code which assume logical address == physical
address.

> 4) I have discussed on the mailing list and have gotten some approval
>    on how to do disk support when configuration via DHCP is in
>    control.  Basically: ``filename "file::///disk0"'' or if we have a
>    filesystem, "file:///disk0/{partion number}/{filesystem path}

IIRC, I proposed something similiar on the list long time ago, we need
something like URL for both networked and filesystem boot.

> 5) I have incorporated your windows ce loader into etherboot, though
>    it isn't as clean as it might be.
> 
> As for menuing and how to be more interactive with users as your code
> does I'm not certain.  But take each each issue up on the list and I
> am fairly certain we can work something out.
> 

I have no idea if the interactive mode is vital for general users. It
is good for us to debugg since 550 does not have a serial port, I 
believe we will remove all the interactive stuff in the production
image.

Ollie

[Etherboot-developers] Re: Pushing LinuxBIOS inspired changes back to etherboot.

[ollie l. <ol...@si...>]

On Fri, 2002-07-26 at 13:54, Eric W Biederman wrote:
> 
> Currently I have cvs access, and etherboot has a cvs development
> branch open on sourceforge that I have been pushing my changes into
> when the look like the will work.  I don't intend to stop until
> everything works again but there has been a little bit of breakage.
> 

What is the tag of your branch ??

Ollie

[Etherboot-developers] last call for 5.0.7 check-ins

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

Please check-in any anticipated 5.0.7 material by this weekend, or it
won't be included in the release. Thanks.

Timothy, does it hurt if ISA_PNP is always defined when compiling
3c515.c? I.e. are BIOS detection and driver detection mutually
exclusive? If not you could add it to 3C515FLAGS and it will be used
when compiling that file. If yes, perhaps in 5.0.8, the code could check
if BIOS detection has been done and if not, do its own detection.

Generally I would like to keep the number of #define options down.
#ifdefs make code less readable and increase the number of combinations
of code that have to be tested. If something can be detected
automatically, do it that way, even if it means a little more code. If
always having the extra functionality without any ill-effects costs only
a few bytes, do it that way. If options can be grouped into fewer ones
or turning on one option implies another, do it that way.

At some point I guess I should review the options for 5.1 to see if they
can be trimmed down.

Re: [Etherboot-developers] Pushing LinuxBIOS inspired changes back to etherboot.

[Eric W B. <ebi...@ln...>]

Eric W Biederman <ebi...@ln...> writes:

> ollie lho <ol...@si...> writes:
> 
> > I think a proper controller driver and Identify/Set feature sequence
> > is necessary to to cope with various IDE drives.

Lack of context wow.  I hadn't looked at the set feature command and if
the drive powers up in standby mode we definitely need to wake it up.
I knew there were a lot of angles to IDE that it was easy to miss,
I hadn't realized I'd missed a whole dimension.  The nice thing in
that case is that IDENTIFY DEVICE should actually respond and give us
some information so it shouldn't affect our boot time unless the
device isn't present.

Eric

[Etherboot-developers] Pushing LinuxBIOS inspired changes back to etherboot.

[Eric W B. <ebi...@ln...>]

ollie lho <ol...@si...> writes:

> On Fri, 2002-07-26 at 12:57, Eric W Biederman wrote:
> > > 
> > > Not yet, but I can send you .tgz. I am consider committing patches
> > > to etherboot project in near future.
> > 
> > We should probably sync up then, because I am in a similiar process.
> > Though I have still not been convinced that we need filesystem code...
> > 
> 
> I am about to ask you on this. I am not familiar with Etherboot guys
> and how should I reform my code. Features in my version:

First step.  Subscribe to the etherboot-developers list, I am taking the
conversation there now.
 
> 	1. SiSFb Lite support, with stupid vga console code.
> 	2. Filesystem code from grub, currently only FAT and EXT2
> 	   were tested but other file system code could be imported
> 	   from grub easily.
> 
> There are various quick hack in both Etherboot original part and my
> own addition. One problem I have is that Etherboot has a flat src
> directory, it would be very ugly to put all my code in it.
> 
> > Though it should be noted that working with different drives and
> > different controlles seems to give some noticeably different results
> > so even after the code looks solid to everyone we need to keep our
> > eyes peeled for a while.
> > 
> 
> I think a proper controller driver and Identify/Set feature sequence
> is necessary to to cope with various IDE drives.

In this case all I have identified so far is the need for proper error
checking :) But we will see.

Let me summarize for you what changes I have been making to support
LinuxBIOS better, in etherboot.  And we can figure out where to work
your stuff in from there.

Currently I have cvs access, and etherboot has a cvs development
branch open on sourceforge that I have been pushing my changes into
when the look like the will work.  I don't intend to stop until
everything works again but there has been a little bit of breakage.

1) I have added relocation code so that etherboot now will relocate
   itself to the top of memory after it has loaded, and I have done
   most of the surgery so this works with normal etherboot as well.
   With the relocation code in place we are free to expand the code
   size of etherboot to > 64K.
2) I have ported the compressor to 32bit code allowing the LinuxBIOS
   etherboot romimage to be self uncompressing.  
3) I have done most of the work so that the etherboot drives will now
   use virt_to_bus, bus_to_virt && ioremap allowing them to be
   portable.
4) I have discussed on the mailing list and have gotten some approval
   on how to do disk support when configuration via DHCP is in
   control.  Basically: ``filename "file::///disk0"'' or if we have a
   filesystem, "file:///disk0/{partion number}/{filesystem path}
5) I have incorporated your windows ce loader into etherboot, though
   it isn't as clean as it might be.

As for menuing and how to be more interactive with users as your code
does I'm not certain.  But take each each issue up on the list and I
am fairly certain we can work something out.

Eric