etherboot-developers — Discussion of developer issues

[Etherboot-developers] ELF Parameter Passing....

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

While working on the itanium port of etherboot I have come to the
issue of how best to pass parameters to the newly loaded kernel.  What
I would like to achieve is to have a single method that will work for
all situations, not just etherboot. 

Currently I have three bootloaders I care about etherboot.  kexec
which runs under the Linux kernel.  And the ELF loader in LinuxBIOS.

Requirements.
- Ability to pass different pieces of information, as different
  bootloaders have different information they want to pass.
- C calling convention for ease of use, and cross platform
  predictability.
- Backwards compatibility. Basically it should be possible to
  test to see if you were passed the new parameters instead of
  whatever legacy way of passing parameters is present.
- Extensibility.  Each bootloader can go their own way and add
  additional pieces of information without needing to sync with any
  universal authority.
- Ignoreability.  It should be legal and even recommended for the
  loaded image to ignore the options passed to it, if it has a better
  source for that information.


Getting this right is important because on the Itanium, at least when
running under efi I must pass the memory map to the loaded kernel.

What I am thinking is something like:

typedef uint16_t Elf_Half;
typedef uint32_t Elf_Word;

typedef struct
{
        Elf_Word b_signature;  /* 0xE1FB007 */
        Elf_Word b_size;
        Elf_Half b_checksum;
        Elf_Half b_records;
} Elf_Bhdr;

typedef struct
{
        Elf_Word n_namesz;
        Elf_Word n_desc;
        Elf_Word n_type;
} Elf_Nhdr;

Followed by an array of elf notes.

int entry(Elf_Bhdr *table);

The important parts are passing a single parameter that is a pointer,
so the function signature never needs to change, and for a simple
bootloader everything can be hardcoded.  Tagged table entries, which
know their length, so even unknown entries can be skipped.  And tags
on the table entries that do not need a central authority to assign.
Plus enough redundancy to see that the passed data is valid.

Roughly this is what I have proposed before for a standard except for
using the C calling conventions.

If there is a better proposal, or something more standard (say what
the open firmware platforms are doing) I am still open to discussion.
But if I don't hear anything this is what I will implement.

Eric

Re: [Etherboot-developers] Fwd: etherboot sis900 source code - problem

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

ke...@us... (Ken Yap) writes:

> >Alright, here's a strange problem. It could indicate anything from a  
> >compiler bug to an alignment bug. I am forwarding it in case it makes  
> >sense to anyone else.
> >I've seen this sort of thing, but it is usually an initialization  
> >problem.
> >Does anyone have any ideas?  Clearly the "patch" would be, um,  
> >problematic ;)
> >
> >> This is the change that i have added just for testing:
> >>
> >> printf ("Netcore Solutions\n");
> 
> Ask him to try putting a sleep(5) there instead. That will tell you if
> it's a chip not ready issue.

While I am thinking about it.  With mmio mapped registers sometime strange
things happen because mmio writes can be posted.  That is it is legal to queue
them up and not execute them immediately.  So a read of another register in mmio
space is necessary to explicitly wait until the write is completed.

Eric

[Etherboot-developers] Has anyone successfully flashed etherboot into AMI bios?

[Steven J. <wpg...@ya...>]

Has anyone successfully added an etherboot rom image
into an AMI Bios image and reflashed and having it
work successfully? I have used amibcp and added my
etherboot image but when I reflash, Its not
recoginzed. Any ideas anyone? Any detailed document on
how to do it? Any help would be greatly appreciated. Thanks

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com

[Etherboot-developers] Re: [Etherboot-users] Etherboot 5.1.3 (development) released

[<eth...@li...>]

BTW, the checksums are:

MD5:

f75cefd3dd97bd1ba1f17ba7308767d3  etherboot-5.1.3.tar.bz2

SHA1:

c3e27e38f59540ccd2b3e7a4c3045b12540eccd2  etherboot-5.1.3.tar.bz2

[Etherboot-developers] Etherboot 5.1.3 (development) released

[<eth...@li...>]

I have released Etherboot 5.1.3 at http://www.etherboot.org/

This is development release. It incorporates many new features such as
multicast protocol support, relocation (allows larger images for one
thing, such an all-drivers-in-one image), improved support for
LinuxBIOS, disk driver, booting order, and many others I'm sure Eric
Biederman, to whom we owe these improvements, will remind me if I left
something out.

Eventually this series will be released as 5.2 or 6.0.

Please note that you must use mknbi-1.2-10 or later to build images for
5.1.3. Such images are backward compatible with Etherboot 5.0.x so you
can safely redo all your images.

Please use the mailing list to report bugs, etc.

Re: [Etherboot-developers] Fwd: etherboot sis900 source code - problem

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

>Alright, here's a strange problem. It could indicate anything from a  
>compiler bug to an alignment bug. I am forwarding it in case it makes  
>sense to anyone else.
>I've seen this sort of thing, but it is usually an initialization  
>problem.
>Does anyone have any ideas?  Clearly the "patch" would be, um,  
>problematic ;)
>
>> This is the change that i have added just for testing:
>>
>> printf ("Netcore Solutions\n");

Ask him to try putting a sleep(5) there instead. That will tell you if
it's a chip not ready issue.

[Etherboot-developers] Fwd: etherboot sis900 source code - problem

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

Alright, here's a strange problem. It could indicate anything from a  
compiler bug to an alignment bug. I am forwarding it in case it makes  
sense to anyone else.
I've seen this sort of thing, but it is usually an initialization  
problem.
Does anyone have any ideas?  Clearly the "patch" would be, um,  
problematic ;)

Marty

Begin forwarded message:

> From: "Rajesh S. Ghanekar" <raj...@ne...>
> Date: Sat Nov 9, 2002  2:47:26  AM US/Eastern
> To: md...@th...
> Cc: raj...@ne...
> Subject: etherboot sis900 source code - problem
>
> Hi Marty,
>     First of all sorry that i am sending a personal mail. I have posted
> this in etherboot mailing list, but no luck with answer.
>     I was facing a problem with sis900 etherboot image file
> (sis900.lzdsk). I have on-board sis900 ethernet controller. So i
> downloaded the source code (5.0.7) and recent patches. After  
> recompiling
> still the problem persisted. So i edited sis900.c file and added a
> simple printf for testing. But that simple printf solved my problem and
> i got my machine booting on LAN. I was getting following error  
> messeges:
>
> sis900_probe: Error MAC address not found
> No adapter found
> <sleep>
> <abort>
>
>
> My edited sis900.c file is as follows :
>
> --------------------------- sis900.c ----------------------------------
>
> /* save for use later in sis900_reset() */
>     pci_revision = revision;
>     printf ("Netcore Solutions\n");
>
>     if (revision == SIS630E_900_REV)
>         ret = sis630e_get_mac_addr(pci, nic);
>     else if ((revision > 0x81) && (revision <= 0x90))
>         ret = sis635_get_mac_addr(pci, nic);
>     else
>         ret = sis900_get_mac_addr(pci, nic);
>
>
>     if (ret == 0)
>     {
>         printf ("sis900_probe: Error MAC address not found\n");
>         return NULL;
>     }
>
>     /* 630ET : set the mii access mode as software-mode */
>
> ----------------------------------------------------------------------- 
> --
>
> This is the change that i have added just for testing:
>
> printf ("Netcore Solutions\n");
>
>
> But it worked for my booting. I don't know how it worked because i am
> not a programmer. In the above sample code, the first if statement gets
> executed, i.e.
>      if (revision == SIS630E_900_REV)
>
> So i guess my chip revision is that. I thought this might be helpful to
> you, so i mailed you.
>
>
> Regards,
> Rajesh
>
>

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

Re: [Etherboot-developers] etherboot 5.1.2

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

ke...@us... (Ken Yap) writes:

> >And added a define for tftp in the case it is not compiled in.
> 
> Unfortunately it seems the CVS doesn't have all the updates or
> something.

I think I was not quite coherent last night.  I misspelled DOWNLOAD_PROTO_TFTP.
How I didn't catch it is a great mystery.  Anyway it is fixed.  And you can pick
just the download protocol you want.  Though I recommend always compiling in TFTP support...

There now will be an error generated if you don't select any download protocol.

Eric

Re: [Etherboot-developers] etherboot 5.1.2

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

>And added a define for tftp in the case it is not compiled in.

Unfortunately it seems the CVS doesn't have all the updates or
something.

gcc -DPCBIOS -DCONFIG_PCI -DCONFIG_ISA -DBACKOFF_LIMIT=7 -DCONGESTED
-DTAGGED_IMAGE -DELF_IMAGE -Os -ffreestanding -fstrength-reduce
-fomit-frame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1
-malign-functions=1 -Wall -W -Wno-format -DVERSION_MAJOR=5
-DVERSION_MINOR=1 -DVERSION=\"5.1.3\" -DRELOC=0x20000  -o bin32/nic.o -c
nic.c
nic.c:454: parse error before `0'

This is the header of the tftp function.

Re: [Etherboot-developers] EFI/Itanium port starting....

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

>For various interesting reasons it has been decided that we need an
>Itanium port of etherboot.  The initial version will rely on EFI quite
>a bit, but I should have something working in the next couple of
>weeks.
>...
>When the structure looks stable, or I have a moment I will merge it
>into the development tree.

Sounds great. I've just tagged the current snapshot as Eb_5_1_3 and will
release it as 5.1.3 which Marty can put on rom-o-matic.

[Etherboot-developers] EFI/Itanium port starting....

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

For various interesting reasons it has been decided that we need an
Itanium port of etherboot.  The initial version will rely on EFI quite
a bit, but I should have something working in the next couple of
weeks.

As part of this I am splitting up etherboot into multiple directories
so I can keep track of the code, and so I can have code for different
architectures in different directories.


My current directory structure:
./bin
      For the binaries as previously discussed we will be able to override
      this, in the Config file.
./include
      The general purpose include files go here (updating genrules.pl for
      this was interesting.
./arch/i386/include
./arch/ia64/include
      The architecture specific include files go here.  
./core
      main.c nic.c and all of the protocols all go here.  Basically the
      core of etherboot.
./util
      The helper programs mkrom and kin go here.
./drivers
./drivers/net
      The network drivers go here.
./drivers/disk
      The disk drivers go here.
./firmware
./firmware/efi
      Efi specific code.
./firmware/pcbios
      pcbios specific code.
./firmware/linuxbios
      linuxbios specific code.
./arch
      Everything that is assembly or the least bit archtecture specific
      gets filed in here.
./arch/i386
./arch/i386/core
      Startup entry/exit type code.  Core etherboot code that is
      archtecture specific.
./arch/i386/util
      Utilities that are only applicable to x86 go here.
./arch/i386/firmware
./arch/i386/firmware/pcbios
./arch/i386/prefix
      The prefixes (lilo, com, pxe, loader, etc) that are prepended
      onto etherboot to allow it to boot in various ways go here.

./arch/ia64
      The itanium code will go here.


At the moment I have just made the first pass at shuffling around the
directories.  And getting the code to build again.  

I am hoping that virt_to_bus and bus_to_virt are sufficient for
etherboot to port reliably to ia64 but it might not be.

This will certainly shake out the 32bit size assumptions.

Comments on the directory structure are welcome.  It is a first pass
and I intend to tweak it I uncover problems.

I have reorganized the Makefiles too there is now:

Makefile
Config
Makefile.main 
arch/i386/Makfile
arch/i386/Config
arch/ia64/Makefile
arch/ia64/Config

With the include order being:
Makefile -> arch/i386/Config -> Config -> Makefile.main -> arch/i386/Makefile

This should allow having special config files for building without
replacing the default as previously discussed.  

When the structure looks stable, or I have a moment I will merge it
into the development tree.

Eric

Re: [Etherboot-developers] etherboot 5.1.2

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

ke...@us... (Ken Yap) writes:

> >gcc -DPCBIOS -DCONFIG_PCI -DCONFIG_ISA -DBACKOFF_LIMIT=7 -DCONGESTED -DTAGGED
> >_IMAGE -DELF_IMAGE -DDOWNLOAD_PROTO_NFS -Os -ffreestanding -fstrength-reduce 
> >-fomit-frame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-funct
> >ions=1 -Wall -W -Wno-format -DVERSION_MAJOR=5 -DVERSION_MINOR=1 -DVERSION=\"5
> >.1.2\" -DRELOC=0x20000  -o bin32/nfs.o -c nfs.c
> >nfs.c: In function `await_rpc':
> >nfs.c:67: `udphdr' undeclared (first use in this function)
> >nfs.c:67: (Each undeclared identifier is reported only once
> >nfs.c:67: for each function it appears in.)
> >nfs.c:73: parse error before `return'
> >nfs.c:58: warning: unused parameter `ptype'
> >make: *** [bin32/nfs.o] Error 1
> 
> This has been fixed in the CVS, but Eric you'll find another error in
> main.c in loadkernel() when -DDOWNLOAD_PROTO_NFS is defined.

Thanks.  I finally took a look at this.
I just corrected the prototype to fnc. 

I have also totally removed the #define for download.

And added a define for tftp in the case it is not compiled in.

And I have changed the dhcp/bootp option code to only attempt to get
extra options via tftp.  Attempting to get the extra code over nfs
does not make much sense.

And tftp and nfs can both be compiled in now.

Some old configurations might need to change a little to explicitly
put nfs:// to get loading over nfs.  But now the behavior of the code
does not change depending upon what is compiled in.

Eric

[Etherboot-developers] Sundance Driver for Etherboot

[tlegge <tl...@ro...>]

Hi

 

I am about to restart my prior work on an EB driver for the Sundance
"Alta" based NICs.  Just thought I would make sure that I am still the
only person working on this driver before I begin again.

 

If I am the only one, I would like to put in space holders for the
driver, (i.e. the updates to the various support files).  In the 5.07
branch, I have identified:

 

NIC,

pci_ids.h

Makefile

 

I would also probably throw in a skeleton sundance.c file as well to
allow it to compile.

 

Any comments?

 

Tim

Re: [Etherboot-developers] typo #2

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

>Well I am using it a few places in production.  Except for the spelling
>errors which don't affect how the code executes there are no outstanding
>bug reports.

Keep sending those bug reports guys. I'll probably release 5.1.3 later
this week so that Marty can put it up on rom-o-matic.

Re: [Etherboot-developers] typo #2

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

Adam Sulmicki <ad...@cf...> writes:

> > > -	 *   This case will not be deteced except by timeing out but
> > > +	 *   This case will not be deteced except by timing out but
> > He got one, missed the other one.
> 
> cool, thanks.
> 
> Now more practical question. How much use that ide code got in
> practice? Going over it seems a bit rough on edges and somewhat
> unfinished.

Well I am using it a few places in production.  Except for the spelling
errors which don't affect how the code executes there are no outstanding
bug reports.

It works on compact flash devices, and regular ide disks.

It is probably rough simply because it was the first real disk driver
for etherboot.  The floppy driver is actually much worse.  It only
seems to work under linuxbios.  But the ide disk driver should be
generally useful.

The only code path I haven't had a chance to test is LBA48 support for
very large drives.  My current largest drive comes in just under that
limit.

Eric

Re: [Etherboot-developers] typo #2

[Adam S. <ad...@cf...>]

> > -	 *   This case will not be deteced except by timeing out but
> > +	 *   This case will not be deteced except by timing out but
> He got one, missed the other one.

cool, thanks.

Now more practical question. How much use that ide code got in
practice? Going over it seems a bit rough on edges and somewhat
unfinished.

-- 
Adam
http://www.eax.com 	The Supreme Headquarters of the 32 bit registers

Re: [Etherboot-developers] typo #2

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

Adam Sulmicki wrote:
>  [not on list, cc]
> 
> ========================================================================
> more typos
...
> -	 *   This case will not be deteced except by timeing out but
> +	 *   This case will not be deteced except by timing out but
                                       ^^^

He got one, missed the other one.

-Don

-- 
Don Christensen       Senior Software Development Engineer
dj...@ci...         Cisco Systems, Santa Cruz, CA
   "It was a new day yesterday, but it's an old day now."

[Etherboot-developers] typo #2

[Adam S. <ad...@cf...>]

 [not on list, cc]

========================================================================
more typos

                ---------------------------------

        Adam Sulmicki <ad...@cf...>
        Tue Nov 12 08:14:16 EST 2002
        http://www.eax.com/patches/

-------------------------------------------------------------------------------
Index: etherboot-5.1/src/ide_disk.c
===================================================================
RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/ide_disk.c,v
retrieving revision 1.6
diff -u -u -r1.6 ide_disk.c
--- etherboot-5.1/src/ide_disk.c	12 Nov 2002 13:50:40 -0000	1.6
+++ etherboot-5.1/src/ide_disk.c	12 Nov 2002 15:05:30 -0000
@@ -580,7 +580,7 @@
 			if ((sizeof(sector_t) < sizeof(uint64_t)) &&
 				drive_info[103] || drive_info[102]) {
 				/* FIXME use a 64bit sector number */
-				printf("Drive to big\n");
+				printf("Drive too big\n");
 				return -1;
 			}
 			info->sectors =
@@ -638,7 +638,7 @@
 	/* Put the drives ide channel in a know state and wait
 	 * for the drives to spinup.
 	 *
-	 * In practice IDE disks to not respond to commands until
+	 * In practice IDE disks tend not to respond to commands until
 	 * they have spun up.  This makes IDE hard to deal with
 	 * immediately after power up, as the delays can be quite
 	 * long, so we must be very careful here.
@@ -652,7 +652,7 @@
 	 *   BSY_SET_DURING_SPINUP to 0.
 	 *
 	 * - The BSY bit floats high when no drives are plugged in.
-	 *   This case will not be deteced except by timeing out but
+	 *   This case will not be deteced except by timing out but
 	 *   we avoid the problems by only probing devices we are
 	 *   supposed to boot from.  If we don't do the probe we
 	 *   will not experience the problem.
@@ -677,7 +677,7 @@
 	 *
 	 * For now I will go with just sending commands to the drives
 	 * and assuming filtering out missing drives by detecting registers
-	 * that won't set and, commands that fail to execute properly.
+	 * that won't set and commands that fail to execute properly.
 	 */

 	/* Now initialize the individual drives */
========================================================================

-- 
Adam
http://www.eax.com	The Supreme Headquarters of the 32 bit registers

Re: [Etherboot-developers] typo

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

>diff -u -u -r1.5 ide_disk.c
--- etherboot-5.1/src/ide_disk.c	8 Oct 2002 23:15:35 -0000	1.5
>+++ etherboot-5.1/src/ide_disk.c	12 Nov 2002 13:27:29 -0000
>@@ -176,7 +176,7 @@
> /* IDE_CMD_SET_FEATURE sub commands */
> #define IDE_FEATURE_CFA_ENABLE_8BIT_PIO                     0x01
> #define IDE_FEATURE_ENABLE_WRITE_CACHE                      0x02
>-#define IDE_FEATURE_SET_TRANSFRE_MODE                       0x03
>+#define IDE_FEATURE_SET_TRANSFER_MODE                       0x03
> #define IDE_FEATURE_ENABLE_POWER_MANAGEMENT                 0x05
> #define IDE_FEATURE_ENABLE_POWERUP_IN_STANDBY               0x06
> #define IDE_FEATURE_STANDBY_SPINUP_DRIVE                    0x07

CVSed. Thanks!

[Etherboot-developers] typo

[Adam S. <ad...@cf...>]

[not on list, cc]

Index: etherboot-5.1/src/ide_disk.c
===================================================================
RCS file: /cvsroot/etherboot/etherboot/etherboot-5.1/src/ide_disk.c,v
retrieving revision 1.5
diff -u -u -r1.5 ide_disk.c
--- etherboot-5.1/src/ide_disk.c	8 Oct 2002 23:15:35 -0000	1.5
+++ etherboot-5.1/src/ide_disk.c	12 Nov 2002 13:27:29 -0000
@@ -176,7 +176,7 @@
 /* IDE_CMD_SET_FEATURE sub commands */
 #define IDE_FEATURE_CFA_ENABLE_8BIT_PIO                     0x01
 #define IDE_FEATURE_ENABLE_WRITE_CACHE                      0x02
-#define IDE_FEATURE_SET_TRANSFRE_MODE                       0x03
+#define IDE_FEATURE_SET_TRANSFER_MODE                       0x03
 #define IDE_FEATURE_ENABLE_POWER_MANAGEMENT                 0x05
 #define IDE_FEATURE_ENABLE_POWERUP_IN_STANDBY               0x06
 #define IDE_FEATURE_STANDBY_SPINUP_DRIVE                    0x07
=====================================================================

-- 
Adam
http://www.eax.com	The Supreme Headquarters of the 32 bit registers

Re: [Etherboot-developers] Documentation of -DASK_BOOT in Config in 5.1.2

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

Georg Baum <Geo...@po...> writes:

> Hi,
> 
> The documentation of -DASK_BOOT in Config and the implementation in main.c 
> disagree: the implementation does not ask anything if ASK_BOOT=0 is 
> defined, but according to the docu this means "no timeout".

Yep.  That is a documentation bug.  The problem exists in 5.0.x as well.
Unless someone needs a "no timeout" I will delete that line from the Config file.


Eric

Re: [Etherboot-developers] New eepro100 variant

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

>I tried to etherboot a laptop with an integrated LAN adaptor. It works fine 
>under recent linux kernels (tried 2.2.22 and 2.4.19). According to lspci, 
>it is the "82801CAM (ICH3) Chipset Ethernet Controller".
>The attached patch adds the device id to etherboot 5.1.2 (5.0.7 did not 
>work).

Committed to 5.1 CVS tree. Thanks.

[Etherboot-developers] Documentation of -DASK_BOOT in Config in 5.1.2

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

Hi,

The documentation of -DASK_BOOT in Config and the implementation in main.c 
disagree: the implementation does not ask anything if ASK_BOOT=0 is 
defined, but according to the docu this means "no timeout".


Georg

Re: [Etherboot-developers] etherboot 5.1.2rc8 released

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

Am Montag, 4. November 2002 02:35 schrieb Ken Yap:
> One thing that absolutely must be done is to put a readme just before
> download explaining that existing images must be rebuilt with
> mknbi-1.2-10 or later (or to use the latest LTSP images, which I believe
> are recent enough), otherwise we'll get this flood of why doesn't it
> work with this image I've had since 1972? :-)

The latest LTSP images (3.0.5, that is kernel 2.4.19) don't work. They are 
tagged with mknbi-1.2-7 and without --first32pm.

Ken, I would suggest a different verson numbering scheme for mknbi: Normally 
the number after the '-' distinguishes only different .rpm- or .deb 
revisions. I suggest to use something like 1.2.7 and 1.2.10 if there are 
any functional changes.


Georg

[Etherboot-developers] New eepro100 variant

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

Hi,

I tried to etherboot a laptop with an integrated LAN adaptor. It works fine 
under recent linux kernels (tried 2.2.22 and 2.4.19). According to lspci, 
it is the "82801CAM (ICH3) Chipset Ethernet Controller".
The attached patch adds the device id to etherboot 5.1.2 (5.0.7 did not 
work).

The problem now is that it only works if I use the whereami() routine in 
eepro100.c, otherwise etherboot restarts after downloading the 
linux-kernel-image. So I guess there are some timimg problems. Maybe some 
eepro100 expert can comment on this?


Georg

BTW, I had to apply the patch from Miles Nordin to get it to work.