etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Porting report

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

Yannis Mitsos <gm...@te...> writes:

> Hi all,
> 
> The "porting"  of the etherboot is proceeding smoothly, I have managed to
> overcome some problems. I have also studied the COFF file format and based on
> the aout_loader I am able to download the minimum needed sections, namely, the
> .text and .data.
> 
> One question that I have is the following (always refering to version 5.0.8):
> Inside the tftp function I had to add in two different places some small
> delays. namely:
> Quoted from the main.c:
> ----------------------------
> 
>         udelay(10000);   <------------1st
> 664:    for (;;)
>     {
>         long timeout;
> #ifdef    CONGESTED
>         timeout = rfc2131_sleep_interval(block?TFTP_REXMT: TIMEOUT, retry);
> #else
>         timeout = rfc2131_sleep_interval(TIMEOUT, retry);
> #endif
>     udelay(2000);   <------------2st
>         if (!await_reply(AWAIT_TFTP, iport, NULL, timeout))
>         {
> ----------------------------
> 
> If I omit the udelays, from the tcpdump I can see that the processor sends a lot
> 
> of tftp requests before it gets an aknowledge from the server.
> 
> Any ideas on this ?

currticks() appears not to be working.

Eric

Re: [Etherboot-developers] NetBSD ELF/a.out support

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

Wojciech Puchar <wo...@te...> writes:

> > - Alternative 2 (writing a converter).
> >
> > You can write a little stub piece of code that reads etherboot's
> > elf boot structure and converts it into a form that NetBSD can
> > use today.
> >
> Alternative 3
> 
> 
> mknbi-netbsd?

Well that was Alternative 2 but perhaps I explained it badly.

Eric

Re: [Etherboot-developers] 5.1.7pre3 problem.

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

Boris Reisig <bo...@bo...> writes:

> I just downloaded the latest etherboot 5.1.xx cvs and I compiled all the
> drivers into one file and write it to a disk [make bin/etherboot.fd0]. That
> works fine but each time etherboot tries to boot it automatically reboots
> the PC before showing the etherboot screen. I have tested this on 3 machines
> and they all do the same thing! Anyone else having this problem?

Hmm.  I have not gotten that far with it.  I think
there is a bug somewhere in the floppy loader with regard to loading large
> 36K binaries.

Eric

Re: [Etherboot-developers] 5.1.7pre3 problem.

[Gustavo J. A. <al...@co...>]

Here I got a blue screen (this remember another software ;-) ) and
everything freezes, with nothing on the screen. I tryied with 2 machines
with etherboot.zfd0 and etherboot-pci.zfd0.


Boris Reisig wrote:

>I just downloaded the latest etherboot 5.1.xx cvs and I compiled all the
>drivers into one file and write it to a disk [make bin/etherboot.fd0]. That
>works fine but each time etherboot tries to boot it automatically reboots
>the PC before showing the etherboot screen. I have tested this on 3 machines
>and they all do the same thing! Anyone else having this problem?
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Scholarships for Techies!
>Can't afford IT training? All 2003 ictp students receive scholarships.
>Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
>www.ictp.com/training/sourceforge.asp
>_______________________________________________
>Etherboot-developers mailing list
>Eth...@li...
>https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>  
>

[Etherboot-developers] 5.1.7pre3 problem.

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

I just downloaded the latest etherboot 5.1.xx cvs and I compiled all the
drivers into one file and write it to a disk [make bin/etherboot.fd0]. That
works fine but each time etherboot tries to boot it automatically reboots
the PC before showing the etherboot screen. I have tested this on 3 machines
and they all do the same thing! Anyone else having this problem?

Re: [Etherboot-developers] Porting report

[Yannis M. <gm...@te...>]

Geert Stappers wrote:

>Why not developing on development version?
>
>( 5.1.16 )
>  
>
Because I have started working on the 5.0.8. When I will finish with the 
coff loader, I will move-on with the 5.1.16 version.

Yannis

-- 
Research Associate
National Technical University of Athens
Electrical & Computers Engineering Department
Computer Science Division, Telecommunications Laboratory
Heroon Polytechneiou 9, Zographou Campus, 157 73, Athens, Greece

E-mail:gm...@te...
Tel.: (+30)-210- 772 3939
Fax: (+30)-210- 772 2534

Re: [Etherboot-developers] Porting report

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

On Wed, Feb 26, 2003 at 04:14:47PM +0200, Yannis Mitsos wrote:
> Hi all,
> 
> The "porting"  of the etherboot is proceeding smoothly, I have managed 
> to overcome some problems. I have also studied the COFF file format and 
> based on the aout_loader I am able to download the minimum needed 
> sections, namely, the .text and .data.
> 
> One question that I have is the following
> (always refering to version  5.0.8):
[ snip ]
> 
> Any ideas on this ?

Why not developing on development version?

( 5.1.16 )

[Etherboot-developers] Porting report

[Yannis M. <gm...@te...>]

Hi all,

The "porting"  of the etherboot is proceeding smoothly, I have managed 
to overcome some problems. I have also studied the COFF file format and 
based on the aout_loader I am able to download the minimum needed 
sections, namely, the .text and .data.

One question that I have is the following (always refering to version 
5.0.8):
Inside the tftp function I had to add in two different places some small 
delays. namely:
Quoted from the main.c:
----------------------------

        udelay(10000);   <------------1st
664:    for (;;)
    {
        long timeout;
#ifdef    CONGESTED
        timeout = rfc2131_sleep_interval(block?TFTP_REXMT: TIMEOUT, retry);
#else
        timeout = rfc2131_sleep_interval(TIMEOUT, retry);
#endif
    udelay(2000);   <------------2st
        if (!await_reply(AWAIT_TFTP, iport, NULL, timeout))
        {
----------------------------

If I omit the udelays, from the tcpdump I can see that the processor 
sends a lot of tftp requests before it gets an aknowledge from the server.

Any ideas on this ?

Regards

Yannis

-- 
Research Associate
National Technical University of Athens
Electrical & Computers Engineering Department
Computer Science Division, Telecommunications Laboratory
Heroon Polytechneiou 9, Zographou Campus, 157 73, Athens, Greece

E-mail:gm...@te...
Tel.: (+30)-210- 772 3939
Fax: (+30)-210- 772 2534

Re: [Etherboot-developers] NetBSD ELF/a.out support

[Wojciech P. <wo...@te...>]

> - Alternative 2 (writing a converter).
>
> You can write a little stub piece of code that reads etherboot's
> elf boot structure and converts it into a form that NetBSD can
> use today.
>
Alternative 3


mknbi-netbsd?

Re: [Etherboot-developers] NetBSD ELF/a.out support

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

Wojciech Puchar <wo...@te...> writes:

> anyone working on it?
> 
> how can i help?
> 
> all i found is that kernel should be loaded beginning from
> LMA(VMA)-c0000000 (which is 1MB in all kernels i looked at from version
> 1.3.3 to 1.6)
> 
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         0014df54  c0100000  c0100000  00001000  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .rodata       000287a1  c024df60  c024df60  0014ef60  2**5
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   2 .data         0001acf0  c0277720  c0277720  00177720  2**5
>                   CONTENTS, ALLOC, LOAD, DATA
>   3 .bss          0003e1fc  c0292420  c0292420  00192420  2**5
> 
> 
> kernel should be started in flat mode with paging off, given parameters on
> stack with C standard:
> 
> (howto, [bootdev], bootinfo, esym, basemem, extmem)
> 
> howto is (2 if single user)|(1 if ask for boot device)|(4 if start
> debugger)
> 
> it could be always 0 for etherboot
> 
> bootdev should be 0 for new kernels - not used.
> 
> esym is used for debugger if kernel symbols are loaded to memory. it's
> probably offset from kernel code to beginning of symbols, 0 if no symbols.
> 
> bootinfo is a pointer to bootinfo structure. first 4 bytes says how many
> elements it has, then there are elements (like boot console info, bios
> disk geometry etc.) - all well defined in NetBSD's bootinfo.h
> 
> 
> how can i help to support it (my assembly isn't best right now)?
> 
> tried using FreeBSD support in etherboot - kernel is loaded fine then
> hangs.
> 
> 
> NetBSD already has ROM files but for only few cards and needs 32K ROMs,
> and
> pxeboot.bin that works for any PXE capable cards.
> 
> anyway having this in etherboot will give user a flexibility to run any OS
> without reprogramming EPROM

We have that:

There are 2 ways to go.  
Either small modifications to NetBSD, or write a mkelf-BSD.

- Alternative 1 (tweaking BSD).

Modify the linker script so the LMA is 0x100000.  Once the physical
addresses are correct etherboot will load your ELF executable into
memory just fine.

The ELF loader in 5.1.x with no special options passes a pointer
to a structure using the standard C calling conventions.  After
the header the structure contains an array of tagged records, allowing
etherboot or whomever use the format to pass whatever values make
sense.

The structure has a magic number at the start, and a checksum so
you can test to see if you were actually passed the appropriate
structure.  It is fairly well defined in etherboot's elf_boot.h
The memory size information along with the dhcp options is present
there.  And this same format (with different tagged values is used on
multiple architectures).

So with a little extra code to parse the etherboot's elf boot
structure, and a small tweak to your linker script you can have
native support of etherboot.

- Alternative 2 (writing a converter).

You can write a little stub piece of code that reads etherboot's
elf boot structure and converts it into a form that NetBSD can
use today.

In addition this requires a stub program to glue the converter
code and the NetBSD kernel together into one image.  Examples
are out there for several other formats.  See mknbi/mkelf and
mkelfImage.

I hope this helps,

And my apologies for not sending this off earlier I got distracted
just before I hit send.

Eric

Re: [Etherboot-developers] Self booting with 5.1

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

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

> Hi
> 
> I am trying to determine whether there is a problem with the current
> cvs.  It seems that after a file is grabbed from the tftp (done shows on
> the screen) my clients either reboot or freeze.  So far I have tried
> several different drivers (3c509, 3c515, ne, sundance, etc) and they all
> have a similar result.  I have done the following:
> 
> 1) downloaded mknbi-1.4.0 and untarred
> 2) cd mknbi-1.4.0; make; make install
> 3) cd etherboot/etherboot-5.1/src; make bin/3c509.fd0
> 4) mknbi-rom bin/3c509.rom > /tftproot/lts/3c509.rom
> 
> Is there anything wrong with my steps?  Has anyone gotten this to work,
> if so with which driver?  

Hmm.  The only piece I can claim to have working and tested is:

make bin/eepro100.elf
make bin/tg3.elf
make bin/e1000.elf

So it may be a bug has crept into the tagged loader.

Or alternatively I wonder if mknbi-rom is not relocation safe?
We had that problem with mknbi-linux but I don't know if I have
ever tested mknbi-rom.

Eric

Re: [Etherboot-developers] tg3 progress...

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

ebi...@ln... (Eric W. Biederman) writes:

> ebi...@ln... (Eric W. Biederman) writes:
> 
> > Well I instead made the code work so I could be more certain
> > of my cutting so I have a working driver in:
> > 3726 lines of code.
> > 
> > Hopefully tomorrow I can find something to prune away.  It looks like I must
> > trim it with a thousand cuts, so...
> 
> One little snip at a time.  I have done the basic analysis and know where
> the big chunks of code are, and have just started the small snips to
> make the driver smaller.  I have the code down to  3458 lines of
> code and reduced in size by a 1/2 or so.
> 
> In another week I might even have a small comprehensible driver.

Of course I am dreaming but progress is being made.

The driver is now down to 2700 lines, of code.  And the text segment
has reduced in size from about 17K to 14K.  So far this was achieved
with a bit of dead code elimination but mostly by introducing
tables of register/value pairs to initialize the chip, and introducing
small subroutines to handle the common idioms.

I don't know if there is any opportunity to squeeze the tg3 driver or not,
we shall see.

I have committed this most recent version, and checked in some bug
fixes with respect to handling of 64bit bars.  Basically in etherboot
we now return an error if the top half of a 64bit bar is populated
and we are on a 32bit platform.

I had a bug in LinuxBIOS that let that left the top half of the BAR
populated and the driver failed in entertaining ways.

Eric

[Etherboot-developers] Self booting with 5.1

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

Hi

I am trying to determine whether there is a problem with the current
cvs.  It seems that after a file is grabbed from the tftp (done shows on
the screen) my clients either reboot or freeze.  So far I have tried
several different drivers (3c509, 3c515, ne, sundance, etc) and they all
have a similar result.  I have done the following:

1) downloaded mknbi-1.4.0 and untarred
2) cd mknbi-1.4.0; make; make install
3) cd etherboot/etherboot-5.1/src; make bin/3c509.fd0
4) mknbi-rom bin/3c509.rom > /tftproot/lts/3c509.rom

Is there anything wrong with my steps?  Has anyone gotten this to work,
if so with which driver?  

Tim

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.458 / Virus Database: 257 - Release Date: 2/24/2003
 

Re: [Etherboot-developers] NetBSD ELF/a.out support

[Wojciech P. <wo...@te...>]

>
> Wojciech Puchar writes:
> | anyone working on it?
> |
> | how can i help?
>
> One thing I've done to boot NetBSD/OpenBSD/Linux off the same is to
> use Grub.  I had to patch grub for OpenBSD if I recall right.  I found
> patches on the net.  So I used Etherboot to boot Grub to then boot the
> OS of choice.  I setup a menu in Grub to select that OS I wanted.

unfortunately i can't compile nbgrub under NetBSD

Re: [Etherboot-developers] NetBSD ELF/a.out support

[Doug A. <amb...@am...>]

Wojciech Puchar writes:
| anyone working on it?
| 
| how can i help?

One thing I've done to boot NetBSD/OpenBSD/Linux off the same is to
use Grub.  I had to patch grub for OpenBSD if I recall right.  I found 
patches on the net.  So I used Etherboot to boot Grub to then boot the
OS of choice.  I setup a menu in Grub to select that OS I wanted.

Doug A.

Re: [Etherboot-developers] problems inside the await_reply

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

Yannis Mitsos <gm...@te...> writes:

> Hi all,
> 
> It seems that the porting is moving smoothly, I have managed to configure the
> processor and fire-up a second serial port to act as console. Thus, I managed to
> 
> configure the cs8900A device without a configuration ROM.
> 
> The problem I faced is the following:
> After sending the bootp request, I get a reply and I enter in the await_reply
> function with the corresponding parameters. There, in line 1068 of main.c
> (Etherboot version 5.0.8) you set the pointer "bootpreply" to point in the
> nic.packet at the position : ETH_HLEN + sizeof(struct iphdr) + sizeof(struct
> udphdr).

This is fixed in the 5.1.x development versions.  Which are a much better
candidate for a port.  The packet structure is offset by 2 bytes deliberately
to align the data.

> The value (sizeof(struct iphdr) + sizeof(struct udphdr)) is word aligned but the
> 
> ETH_HLEN which is set to 14 makes the aforementioned position NON word aligned.
> 
> So the value (bootpreply->bp_xid) returns wrong values. If you wish I can send
> you details with addresses e.t.c.
> 
> To overcome the problem I allocate in the stack a structure of type bootp_t
> instead of a pointer to a structure and I copy the data from the nic.packet to
> the bootpreply structure. Now, since the bootpreply structure is allocated in
> the stack is word alligned and I do not have a problem.

But this explodes the stack size, and etherboot tends to run with
a small stack.

Also fixed in 5.1.x is handling of IP options which can also misalign
the data.
 
> Any comments on this ?

Yes, please work against the development version where:
(a) all of the alignment issues have been fixed (except possibly in the drivers)
(b) There is a good infrastructure for handling porting issues.

Please check the development version out of cvs, or grab the recent 5.1.6 snapshot.
 
> Regards
> 
> Yannis
> 
> P.S: If I understand correctly the current_tick increments by one value every
> 55.555 ms ?

Roughly that is a define.   A couple of impolite drivers depend on it.
For the rest as long as TICKS_PER_SEC is defined properly they will be o.k.

Eric

[Etherboot-developers] problems inside the await_reply

[Yannis M. <gm...@te...>]

Hi all,

It seems that the porting is moving smoothly, I have managed to 
configure the processor and fire-up a second serial port to act as 
console. Thus, I managed to configure the cs8900A device without a 
configuration ROM.

The problem I faced is the following:
After sending the bootp request, I get a reply and I enter in the 
await_reply function with the corresponding parameters. There, in line 
1068 of main.c (Etherboot version 5.0.8) you set the pointer 
"bootpreply" to point in the nic.packet at the position : ETH_HLEN + 
sizeof(struct iphdr) + sizeof(struct udphdr).

The value (sizeof(struct iphdr) + sizeof(struct udphdr)) is word aligned 
but the ETH_HLEN which is set to 14 makes the aforementioned position 
NON word aligned.

So the value (bootpreply->bp_xid) returns wrong values. If you wish I 
can send you details with addresses e.t.c.

To overcome the problem I allocate in the stack a structure of type 
bootp_t instead of a pointer to a structure and I copy the data from the 
nic.packet to the bootpreply structure. Now, since the bootpreply 
structure is allocated in the stack is word alligned and I do not have a 
problem.

Any comments on this ?

Regards

Yannis

P.S: If I understand correctly the current_tick increments by one value 
every 55.555 ms ?

-- 
Research Associate
National Technical University of Athens
Electrical & Computers Engineering Department
Computer Science Division, Telecommunications Laboratory
Heroon Polytechneiou 9, Zographou Campus, 157 73, Athens, Greece

E-mail:gm...@te...
Tel.: (+30)-210- 772 3939
Fax: (+30)-210- 772 2534

[Etherboot-developers] NetBSD ELF/a.out support

[Wojciech P. <wo...@te...>]

anyone working on it?

how can i help?

all i found is that kernel should be loaded beginning from
LMA(VMA)-c0000000 (which is 1MB in all kernels i looked at from version
1.3.3 to 1.6)

Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0014df54  c0100000  c0100000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       000287a1  c024df60  c024df60  0014ef60  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         0001acf0  c0277720  c0277720  00177720  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          0003e1fc  c0292420  c0292420  00192420  2**5


kernel should be started in flat mode with paging off, given parameters on
stack with C standard:

(howto, [bootdev], bootinfo, esym, basemem, extmem)

howto is (2 if single user)|(1 if ask for boot device)|(4 if start
debugger)

it could be always 0 for etherboot

bootdev should be 0 for new kernels - not used.

esym is used for debugger if kernel symbols are loaded to memory. it's
probably offset from kernel code to beginning of symbols, 0 if no symbols.

bootinfo is a pointer to bootinfo structure. first 4 bytes says how many
elements it has, then there are elements (like boot console info, bios
disk geometry etc.) - all well defined in NetBSD's bootinfo.h


how can i help to support it (my assembly isn't best right now)?

tried using FreeBSD support in etherboot - kernel is loaded fine then
hangs.


NetBSD already has ROM files but for only few cards and needs 32K ROMs,
and
pxeboot.bin that works for any PXE capable cards.

anyway having this in etherboot will give user a flexibility to run any OS
without reprogramming EPROM

Re: [Etherboot-developers] Porting question

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

Yannis Mitsos <gm...@te...> writes:

> Eric W. Biederman wrote:
> 
> >May I ask which RISC processor you are using?
> >
> Ok, the processor is Hyperstone's E132-XS (http://www.hyperstone.com).
> Actually we have a project to port Linux to the aforementioned
> processor. Currently, we have done almost everything done in the architecture
> dependent part of the kernel and we are working on the libc as well as on the
> executable file loader (the processor doesn't have an MMU so we are following
> the uClinux aaproach).
> 
> The problem that arises is that the kernel needs almost 3-4 minutes to download
> through the serial port which imposes us a significant delay. This is the reason
> why we started looking into the etherboot.

That makes sense.
> 
> >I am trying to think of a RISC processor that only has COFF support
> >in binutils.  I know linux won't build without ELF support.  So I
> >don't know which embedded OS the board is targeted for.
> >
> You are not exactly right :-) When using the uClinux approach there is no need
> to have ELF capable tools. This is due to the fact that all the executables have
> to be converted to the "flat" file format before executing them. So even if you
> had ELF tools you still have to convert to the "flat" file format.

I guess I was thinking that multiple sections were needed for the kernel
to build correctly.  There are several tables in the kernel build that
are build as ELF sections, and gradually accumulated.

The "flat" file format makes sense.  Though there is no reason an ELF
loader would not work as well.  But it may not be the best fit for the
problem.  And I certainly seem to remember uClinux using a different 
methodology.

 
> >>>Etherboot is already running on the Itanium so 64bit issues, and
> >>>alignment issues are already sorted out.  Though not all of the
> >>>drivers have been tested.
> >>>
> >>>
> >>I need only the well-konwn cs89x0 driver :-)
> >>
> >
> >That makes it easy then.
> >
> Yes this is exactly what I thought, still the driver needs a little bit of
> hacking because there is no provision for implementations without an EPROM (most
> embedded systems do not include a ROM to store the onfiguration data like the
> standard NICs do).

That makes sense.  Still it should not be to difficult.
Probably a special build option that hard codes the result of
the eeprom probe would be a good fit.
 
> I will keep you inform on the progress of my work but most probably prior to
> this I will come back with more questions :-)

Questions we can answer. :)

Eric

Re: [Etherboot-developers] Porting question

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

>You are not exactly right :-) When using the uClinux approach there is 
>no need to have ELF capable tools. This is due to the fact that all the 
>executables have to be converted to the "flat" file format before 
>executing them. So even if you had ELF tools you still have to convert 
>to the "flat" file format.

Well in that case it's easy then, start from the flat file. All you need
to do is wrap an ELF format around it, and any ramdisks you are sending
along.

Re: [Etherboot-developers] Porting question

[Yannis M. <gm...@te...>]

Eric W. Biederman wrote:

>May I ask which RISC processor you are using?
>
Ok, the processor is Hyperstone's E132-XS (http://www.hyperstone.com).
Actually we have a project to port Linux to the aforementioned 
processor. Currently, we have done almost everything done in the 
architecture dependent part of the kernel and we are working on the libc 
as well as on the executable file loader (the processor doesn't have an 
MMU so we are following the uClinux aaproach).

The problem that arises is that the kernel needs almost 3-4 minutes to 
download through the serial port which imposes us a significant delay. 
This is the reason why we started looking into the etherboot.

>I am trying to think of a RISC processor that only has COFF support
>in binutils.  I know linux won't build without ELF support.  So I
>don't know which embedded OS the board is targeted for.
>  
>
You are not exactly right :-) When using the uClinux approach there is 
no need to have ELF capable tools. This is due to the fact that all the 
executables have to be converted to the "flat" file format before 
executing them. So even if you had ELF tools you still have to convert 
to the "flat" file format.

>>>Etherboot is already running on the Itanium so 64bit issues, and
>>>alignment issues are already sorted out.  Though not all of the
>>>drivers have been tested.
>>>
>>>      
>>>
>>I need only the well-konwn cs89x0 driver :-)
>>    
>>
>
>That makes it easy then.
>  
>
Yes this is exactly what I thought, still the driver needs a little bit 
of hacking because there is no provision for implementations without an 
EPROM (most embedded systems do not include a ROM to store the 
onfiguration data like the standard NICs do).

I will keep you inform on the progress of my work but most probably 
prior to this I will come back with more questions :-)

Regards

Yannis

Re: [Etherboot-developers] Award BIOS and int 18h problems

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

> > As far as I can tell from reading around, there are no preconditions on
> > calling int 0x18 other than that "data areas such as the interrupt vector
> > table, the BDA, and the Extended BIOS Data Area must remain unchanged
> > [from when the BEV was called]".  Since by BEV is currently pointing
> > straight to an int 0x18 instruction, it's hard to see where I might be
> > violating this requirement.
> Since this code used to work it sounds reasonable, that the BIOS is the
> culprit.
> Is this one of those BIOSes that allow you to specify etherboot in
> the boot order?

Yes; I can specify up to three boot devices, with choices such as
"Floppy", "LAN", "HDD-0", "HDD-1", "CDROM", "SCSI" etc.

Interestingly, I've discovered that Etherboot will not be invoked if LAN
is the second boot device.  If I specify an order of "Floppy", "LAN",
"HDD-0" and boot with no floppy in the drive then Etherboot never starts
up.  Changing the order to "LAN", "Floppy", "HDD-0" brings up Etherboot as
expected.

I'm thinking that I might need to hook straight into int 19, using the
code designed for legacy BIOSes that don't support the BIOS Boot
Specification.  I'm running out of ideas to try.

> > The most annoying aspect of this is that the only to test code changes is
> > to burn them into silicon, and I don't have an EPROM eraser...
> > Any ideas are more than welcome.
> If you have an eepro100 plugin NIC I have an mtd driver that allows it
> to be written/erased in software...

I might have to buy one of those if this goes on much longer.

Michael

Re: [Etherboot-developers] Porting question

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

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

> >>Etherboot needs to be stripped down?
> >>
> >It was a wrong phrase of mine. I mean that I am trying to comment-out 
> >everything related to x86.
> 
> Still the wrong idea. You shouldn't need to do that. Eric has done a
> brilliant job separating out the non-architecture specific components
> from the architecture specific ones. 

Thank you.  Although I keep finding things in misc.c that really should
be moved.  But don't matter at the moment as they are covered in 
#ifdef PCBIOS
#endif

> Ideally you should only need to
> create a new branch in arch and new config files at the top level.  If
> not tell us what needs to be fixed.
> 
> >>I would recommend writing a mkelf for your platform that packages
> >>kernels ramdisks and everything together, instead of adding a COFF
> >>handler.  But it is your port...
> >>
> >This is not very clear to me. Initially I will try to add the COFF 
> >loader and if it is not possible I will come-back again.
> 
> Whatever loader format you choose, it has to have some kind of directory
> at the beginning to indicate where the pieces go in memory. 

Ken COFF actually has this.  The downside is simply that COFF is
about as standard as a.out.  There are lots of minor variations.

> Etherboot supports NBI and ELF. 

But everything but ELF is currently limited to x86. The ELF loader
is arch independent.  It just requires to I think two defines from
an arch dependent header file.

> Instead of writing COFF support, try to see if you
> can write an ELF generator, then you don't need to implement it in
> Etherboot since it already has an ELF loader. You may need to write a
> custom one anyway because of the need to load ramdisks.
> 

Eric

Re: [Etherboot-developers] Porting question

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

Yannis Mitsos <gm...@te...> writes:

> Hi Eric,
> 
> Thank you for your answer.
> 
> >Etherboot needs to be stripped down?
> >
> It was a wrong phrase of mine. I mean that I am trying to comment-out everything
> related to x86.

As Ken has already pointed out this has already been done.
I admit there a few small bits left but those are all covered by config options,
and so they should be noops.

If you find something you need to change let us know.  For 5.1.x it should
be feasible to properly modify the core.

> >It should be possible to take the 5.1.x source and to do a real port.
> >
> Yes this is what I am doing...

Nice.  It will be a pleasure to see it.
 
> >The tricky bits I see are the self decompresser, which is a screen
> >Some support code like setjmp and longjmp.
> >
> For the time being I am commenting these out and I will figure out later what I
> will do with those

O.k. Sounds good.

> >And whatever you need for platform support.
> >Any big endian issues that may come with your RISC processor.
> >Any firmware/hardware interfacing issues you may have.
> >
> Actually the processor utilizes a big-endian scheme for its memories...

Which is what I meant x86 and ia64 are both little-endian.  So there
may be a bug or two.

May I ask which RISC processor you are using?

I am trying to think of a RISC processor that only has COFF support
in binutils.  I know linux won't build without ELF support.  So I
don't know which embedded OS the board is targeted for.

> >Etherboot is already running on the Itanium so 64bit issues, and
> >alignment issues are already sorted out.  Though not all of the
> >drivers have been tested.
> >
> I need only the well-konwn cs89x0 driver :-)

That makes it easy then.

> >I would recommend writing a mkelf for your platform that packages
> >kernels ramdisks and everything together, instead of adding a COFF
> >handler.  But it is your port...
> >

> This is not very clear to me. Initially I will try to add the COFF loader and if
> it is not possible I will come-back again.

Let me see if I can clarify this a bit.

In practice it usually happens that the kernel, a ramdisk and a command line
all need to be loaded into memory where the kernel can access them.

The etherboot recommended way is to create an external utility that combines
all of these into an ELF executable.  For linux on x86 normally
mkelf-linux is used to accomplish this task.  So the recommendation is
to write the companion utility mkelf-arch-os for your embedded
platform.  This is useful because this allows the same firmware to
load multiple OS's.  Which is the primary point keeping OS details
out of etherboot, as much as possible.

ELF was picked because it is stable cross platform file format, that
cleanly handles both 32bit and 64bit executables, and has enough
flexibility so OS peculiarities can be kept out of etherboot.  Instead
we have stub added by mkelf-linux and it's companions to handle the
weird stuff.

Eric

Re: [Etherboot-developers] Award BIOS and int 18h problems

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

Michael Brown <mb...@fe...> writes:

> I'm having major problems with Award Modular BIOS v6.00PG and the latest
> Etherboot 5.0.8.  Booting from the network works fine; the problem is when
> you choose "(L)ocal" and attempt to boot from the hard disk instead.  It
> displays the message "PRESS A KEY TO REBOOT" and stops.
> 
> This occurs only when booting from a real EPROM (.lzrom).  Booting the
> exact same code from a floppy (.lzfd0) has no problems.
> 
> I've been working back through the code, adding exit points at various
> stages.  I'm now at the stage that loader.S executes an int 0x18 as soon
> as the BIOS calls its Boot Execution Vector.  This was achieved with the
> following modification to loader.S:
> 
>         .word 0x0000                    /* boot connection vector */
>         .word 0x0000                    /* disconnect vector */
> -       .word pnpentry
> +/*     .word pnpentry */
> +       .word pnpreturn
>         .word 0x0000                    /* reserved */
> 
> i.e. the BEV points to pnpreturn instead of pnpentry.  pnpreturn contains
> simply:
> 
> pnpreturn:
> 	int	$0x18			/* As per BIOS Boot Spec, next dev */
> 
> 
> Even with this modification, the machine *STILL* fails with the "PRESS A
> KEY TO REBOOT" message.
> 
> "Aha," I thought.  Maybe the implementation of int 0x18 is screwed in this
> BIOS.  So I tried adding a second HDD.  Both HDDs have a standard DOS MBR
> and DOS partition tables.  By deactivating the boot partition on one
> drive, I can make the BIOS fall through and try the next drive.  This, as
> far as I am aware without disassembling the MBR, involves the same int
> 0x18 mechanism.
> 
> 
> As far as I can tell from reading around, there are no preconditions on
> calling int 0x18 other than that "data areas such as the interrupt vector
> table, the BDA, and the Extended BIOS Data Area must remain unchanged
> [from when the BEV was called]".  Since by BEV is currently pointing
> straight to an int 0x18 instruction, it's hard to see where I might be
> violating this requirement.

Since this code used to work it sounds reasonable, that the BIOS is the
culprit.

Is this one of those BIOSes that allow you to specify etherboot in
the boot order?

> The most annoying aspect of this is that the only to test code changes is
> to burn them into silicon, and I don't have an EPROM eraser...
> 
> Any ideas are more than welcome.

If you have an eepro100 plugin NIC I have an mtd driver that allows it
to be written/erased in software...

Eric