etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Q: does xstart work?

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

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

> >Staring at the assembly in xstart there is the following code
> >snippet:
> >	pushl	%eax
> >	ADDR32	LJMPI(_execaddr-_start16)
> >1:
> >...
> >_execaddr:
> >	.long	0
> >
> >What I don't get is how this snippet of code successfully jumps
> >to an application.  ADDR32 should ljmpi should take a m16:32.
> >Where the offset which comes first is 32 bits, and the segment
> >that comes after is 16bits.  I just don't see how that works when
> >we pass it a m16:16 in execaddr.
> 
> _execaddr is filled in with a linear address.

For 32 bit code yes.  But for 16bit code it is clearly a filled with
a segment offset to jump to.
From the nbi spec:

          |                     |
          | Initial Magic No.   |  4 bytes
          +---------------------+
          |                     |
          | Flags and length    |  double word
          +---------------------+
          |                     |
          | Location Address    |  double word in ds:bx format
          +---------------------+
          |                     |
          | Execute Address     |  double word in cs:ip format 
          +---------------------+
  ______________________________________________________________________

And Execute Address is the ultimate source of the address.

Eric

Re: [Etherboot-developers] Q: does xstart work?

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

>Staring at the assembly in xstart there is the following code
>snippet:
>	pushl	%eax
>	ADDR32	LJMPI(_execaddr-_start16)
>1:
>...
>_execaddr:
>	.long	0
>
>What I don't get is how this snippet of code successfully jumps
>to an application.  ADDR32 should ljmpi should take a m16:32.
>Where the offset which comes first is 32 bits, and the segment
>that comes after is 16bits.  I just don't see how that works when
>we pass it a m16:16 in execaddr.

_execaddr is filled in with a linear address.

[Etherboot-developers] Q: does xstart work?

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

Staring at the assembly in xstart there is the following code
snippet:
	pushl	%eax
	ADDR32	LJMPI(_execaddr-_start16)
1:
...
_execaddr:
	.long	0

What I don't get is how this snippet of code successfully jumps
to an application.  ADDR32 should ljmpi should take a m16:32.
Where the offset which comes first is 32 bits, and the segment
that comes after is 16bits.  I just don't see how that works when
we pass it a m16:16 in execaddr.

The code has looked like this since 4.6.x so I don't doubt it works
for someone but a confirmation, or even more an explanation would be
nice. 


Eric

[Etherboot-developers] Relocation successs...

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

I am probably certifiable at this point but I have a working
relocatable etherboot.  Including the framework for 16bit
calls.  But the 16bit code isn't done.

The fun part is putting etherboot in an endless loop booting itself :)

What I have for 16bit code, is a 16bit that you pass a stack below
1M and it will pop all of it's arguments of the registers, and the
address of the function to jmp to off of the stack.  Leaving just
a prepopulated return address, and whatever arguments came with
the stack.

I aimed at a single general purpose function because I felt that
writing multiple stub functions, and handling everything else would
start getting quite complicated, and push the amount of memory
we need below 1MB.

Currently below 1MB I need about 400 bytes + 1k or so for a stack.

I'm a little frustrated because it feels like whenever I try something
to make the code smaller the size actually grows a little.  Everything
except the decompressor code anyway :)  The practical growth is only
a couple of hundred bytes...

With respect to decompressor code.  There should be enough space in
the low 640K to hold both the compressed, and the uncompressed
etherboot so I don't need an inplace decompressor.  I plan on placing
the decompressor at 0x10000 and etherboot at something like 0x24000,
when using relocation.

Relocating polling drivers isn't to much of a hassle.  It is just
a matter of placing calls to virt_to_bus in all of the appropriate
places.  For the few drivers we have that used memory mapped io
devices we will need calls to ioremap as well.  And sorting
that out will be a little interesting.

I'm to tired to safely commit anything tonight, but sometime in the
next couple of days, I will commit my work to date.

Eric

Re: [Etherboot-developers] been testing 5.0.7rc2 and 5.1.2rc1

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

>O.k. I just decided to look for these, and I cannot find where
>the release cannidates are kept on sourceforge or the etherboot
>web page.
>
>Since I assume the code for these is in CVS this isn't a big deal
>but it is unfortunate.

I mentioned the URLs on the developer list perhaps a bit too casually.
They are in the top directory of the website. I.e.

http://etherboot.sourceforge.net/etherboot-5.0.7rc2.tar.bz2
http://etherboot.sourceforge.net/etherboot-5.1.2rc1.tar.bz2

There is one update to 5.0.7rc2 that in CVS only, the LinuxBIOS compile
problem that Marty hit.

Re: [Etherboot-developers] been testing 5.0.7rc2 and 5.1.2rc1

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

ke...@us... writes:

> I've just tested 5.0.7rc2 and just as well I did because I had
> introduced a embarrassing bug, but I've fixed it in the CVS now. I
> should be able to hand it to Marty for wider testing on rom-o-matic
> soonish.
> 
> I also gave 5.1.2rc1 a whirl, no special options, and found that it
> wasn't able to complete loading FreeDOS. It ended with Unable to load
> file. Linux was ok. But I don't think it's anything to do with the OSes.
> I think it's a termination condition in the TFTP loader code that's not
> right and the FreeDOS image just happened to be the right length to
> tickle the bug.  Haven't looked into it closely.

O.k. I just decided to look for these, and I cannot find where
the release cannidates are kept on sourceforge or the etherboot
web page.

Since I assume the code for these is in CVS this isn't a big deal
but it is unfortunate.

Eric

Re: [Etherboot-developers] Q: USE_LOWMEM_BUFFER?

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

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

> >I'm a little curious about the history of USE_LOWMEM_BUFFER, and
> >the reasons for it.  The primary reason is that when I start
> >compiling I can easily get a huge .bss section, because all of the
> >drivers have a seperate transmit buffer.
> >
> >I'm not advocating reviving USE_LOWMEM_BUFFER but instead looking
> >at what it would take to use the old USE_LOWMEM_BUFFER infrastructure
> >to have a common transmit buffer.
> 
> USE_LOWMEM_BUFFER is a hack that Klaus Espenlaub created for some 4.x
> drivers because at that time Etherboot only had 32kB-- from 0x98000
> upwards. In 5.x by refining mknbi and juggling the segments around I
> gave Etherboot 48kB-- from 0x94000 upwards, obviating the need for
> USE_LOWMEM_BUFFER which I thought was ugly.
> 
> It would probably be better to rework the means by which drivers get
> buffers, possibly by providing a library which returns pointers to a
> common buffer area. Then the decision where to put the buffer area is
> concentrated in the library, not scattered throughout drivers.

Sounds good.  But USE_LOWMEM_BUFFER is useful in point out what areas 
need to be changed.

Eric

Re: [Etherboot-developers] Q: USE_LOWMEM_BUFFER?

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

>I'm a little curious about the history of USE_LOWMEM_BUFFER, and
>the reasons for it.  The primary reason is that when I start
>compiling I can easily get a huge .bss section, because all of the
>drivers have a seperate transmit buffer.
>
>I'm not advocating reviving USE_LOWMEM_BUFFER but instead looking
>at what it would take to use the old USE_LOWMEM_BUFFER infrastructure
>to have a common transmit buffer.

USE_LOWMEM_BUFFER is a hack that Klaus Espenlaub created for some 4.x
drivers because at that time Etherboot only had 32kB-- from 0x98000
upwards. In 5.x by refining mknbi and juggling the segments around I
gave Etherboot 48kB-- from 0x94000 upwards, obviating the need for
USE_LOWMEM_BUFFER which I thought was ugly.

It would probably be better to rework the means by which drivers get
buffers, possibly by providing a library which returns pointers to a
common buffer area. Then the decision where to put the buffer area is
concentrated in the library, not scattered throughout drivers.

[Etherboot-developers] Q: USE_LOWMEM_BUFFER?

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

I'm a little curious about the history of USE_LOWMEM_BUFFER, and
the reasons for it.  The primary reason is that when I start
compiling I can easily get a huge .bss section, because all of the
drivers have a seperate transmit buffer.

I'm not advocating reviving USE_LOWMEM_BUFFER but instead looking
at what it would take to use the old USE_LOWMEM_BUFFER infrastructure
to have a common transmit buffer.

Eric

Re: [Etherboot-developers] Relocation & friends....

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

Hello Eric,

Saturday, July 20, 2002, 3:44:33 AM, you wrote:
EWB> [...]
EWB> But things should definitely be on the move.  One of the things I want to
EWB> check out is to see if atftp-0.6 works with the existing tftpm implementation.

I would like to know too. As my desktop yesterday decided to blow its
80gig disk (thank whoever my data was backuped onto the other disk) I
have to re-install quite everything first before development goes on.
Testing atftp was on my schedule, too, but there are other things with
higher priority (hunting for food, writing exams, you know). Let me
know in any case. If you need, I can post a very-simple
coded-in-one-hour-or-three tftp-server that supports multicast and
works with my code (I implemented it along the RFC, and tested the
code against it).

Sorry the announced menuing code isn't out yet, but I've been really
busy last two weeks. After my last exam, next friday, there will be
plenty of time for me.

[...]
EWB> And of course watch out for Adam Agnew, as he has some work on signed boot
EWB> images that he was threatening to submit earlier today.

I didn't get anything of this, but let me guess he wants something
like authenticity checking !?

-- 
Best regards,
 Anselm                            mailto:an...@ho...

[Etherboot-developers] Relocation & friends....

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

I have enough code working with LinuxBIOS, that I am back on etherboot
getting hard driver booting, and multicast booting working.

So I don't have to go back and do a lot of rethinking later, I have
implemented the little bit of infrastructure needed for relocation.
That is an xstart32 function so I have a hook before we leave etherboot,
and virt_to_bus, virt_to_phys, and ioremap + readb and company.
It will take a while before all of the drivers are updated so that
it all works, but that isn't a huge challenge, just tedious.  The final task
is to get special handling for the 16bit BIOS interface code.

I couldn't access cvs at sourceforge this evening, so syncing up will
have to wait until next week.

But things should definitely be on the move.  One of the things I want to
check out is to see if atftp-0.6 works with the existing tftpm implementation.

Portability issues so etherboot can be ported to another hardware platform
are something I care about now too, so it will be interesting to see
where all of this can go.

And of course watch out for Adam Agnew, as he has some work on signed boot
images that he was threatening to submit earlier today.

Eric

Re: [Etherboot-developers] Seperating out the x86 BIOS calls...

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

Markus Gutschke <ma...@gu...> writes:

> Eric W Biederman wrote:
> > Gak.  I've been doing this to long.  I converted the code to 32bit assembly
> > and it worked on my very first try.
> 
> I guess, it is time for you to take some vacation ;-) How about coming for
> LinuxExpo...

Unfortunately I believe I have a scheduling conflict something about
testing etherboot on 1000 nodes simultaneously.

But other than that it would be fun.

Eric

Re: [Etherboot-developers] Seperating out the x86 BIOS calls...

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

Eric W Biederman wrote:
> Gak.  I've been doing this to long.  I converted the code to 32bit assembly
> and it worked on my very first try.

I guess, it is time for you to take some vacation ;-) How about coming 
for LinuxExpo...


Markus

Re: [Etherboot-developers] Seperating out the x86 BIOS calls...

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

Gak.  I've been doing this to long.  I converted the code to 32bit assembly
and it worked on my very first try.

Eric

RE: [Etherboot-developers] sundance (D-Link DFE-550) status

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

Hi

Currently, the document on the sundance chip is all over my desk.  I started
working on it a number of months ago, but all told, I have done about five
hours work on it.  It currently recognizes the card, and I am now working on
the transmit and poll logic.

As it is summer, and I am working without air conditioning ;-(, I don't know
when I will finish it.  I hope to work on it some more over the next couple
of nights.  However, on Friday I go on vacation for two weeks.  During that
time, I will either finish it, or get nothing done (probably the latter).

Sorry I can't give you any more hope than that.

Regards

Tim

> -----Original Message-----
> From: eth...@li...
> [mailto:eth...@li...]On Behalf Of
> Ralph Aichinger
> Sent: Wednesday, July 17, 2002 7:27 AM
> To: eth...@li...
> Subject: [Etherboot-developers] sundance (D-Link DFE-550) status
>
>
> I am considering buying several D-Link DFE-550 (Sundance Alta 201)
> cards. Having EtherBoot support them is not the most important
> feature for the application I am intending to use them for, but
> it could be handy in certain situations.
>
> What is the current status of this chip? I found an old
> archive posting about it, but nothing else.
>
> General (non-EB-related) opinions on these cards are also
> appreciated. These cards are the only non-Realtek cards
> i can get cheap.
>
> Thanks in advance!
>
> EtherBoot saved me hours when installing a network of old, recycled
> Pentiums as X-Terms last months. I thank you very much for your
> wonderful work!
>
> /ralph
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>

[Etherboot-developers] sundance (D-Link DFE-550) status

[Ralph A. <ra...@pa...>]

I am considering buying several D-Link DFE-550 (Sundance Alta 201)
cards. Having EtherBoot support them is not the most important 
feature for the application I am intending to use them for, but
it could be handy in certain situations.

What is the current status of this chip? I found an old 
archive posting about it, but nothing else.

General (non-EB-related) opinions on these cards are also 
appreciated. These cards are the only non-Realtek cards
i can get cheap.

Thanks in advance!

EtherBoot saved me hours when installing a network of old, recycled
Pentiums as X-Terms last months. I thank you very much for your 
wonderful work!

/ralph

Re: [Etherboot-developers] Seperating out the x86 BIOS calls...

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

Markus Gutschke <ma...@gu...> writes:

> Ken Yap wrote:
> > There are some limits of the de/compression code, Markus can explain
> > those.
> 
> The decompressor is based on the code in contrib/compressor/lzhuf.c,
> but has been aggressively optimized for size. If you want to make any
> changes to the assembly code, you should probably first read the C
> source and try to understand it.

That is where I started.  Though I was after more of a feel of the code
than actual understanding.

> The decompressor currently runs in real mode only. As such, it uses
> segment registers and cannot extract more than at most 64kB (there
> probably is a limit even before 64kB is reached, but I don't remember
> all the details). As we know that we are never going to deal with more
> than 64kB of data, we can also tell that the pattern frequency can
> never get bigger than 2^16 (in fact, it'll stay considerably smaller
> than that). Thus, I stripped out the reconst() function which would
> never get called. If you want to deal with larger images, you probably
> have to implement it, though.

When I start dealing with larger images I will look.  At the present
my initial goal is to get it working for the same set of images as
the existing code just running in protected mode.  Since the addresses
are flat I don't need the segment registers.   
 
> Also, I managed to shrink the code size, by compressing all the
> preinitialized tables (using some kind of run length encoding); and I
> stripped off a few more bytes by ordering these tables in a way so
> that once I have initialized one table my registers already have the
> right values that I will need for initializing the next one.
> 
> Due to the small register file, there always is considerable register
> pressure when writing code for the x86. I managed to keep almost all
> data in registers, but this required me to split some of the registers
> into 4bit nybbles. You might need to keep this in mind if you have to
> make changes to the code.

I will.  At a first pass the only changes needed where to ensure the
upper halves of the 32bit registers were 0 in the appropriate
locations.  Because in protected mode you can't index by (%si) or
(%bx)...

As for the register pressure on x86.  I am very familiar with it
having written several thousand lines of assembly with the purpose of
enabling RAM, on various chipsets.  And there I don't have memory so
life is much more interesting.

Thanks for the pointers, they ring true with my reading of the code
so I can't be to far off.  The challenging part is I have to redo how
the BSS section is allocated.  Addresses simply starting at 0, aren't
very useful.

It is refreshing to know that some of the more gratuituous changes
from the C code were size optimizations.  Both because that has been
done, and because there was a reason for them :) 

Eric

Re: [Etherboot-developers] Seperating out the x86 BIOS calls...

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

Ken Yap wrote:
> There are some limits of the de/compression code, Markus can explain
> those.

The decompressor is based on the code in contrib/compressor/lzhuf.c, but has 
been aggressively optimized for size. If you want to make any changes to the 
assembly code, you should probably first read the C source and try to understand it.

The decompressor currently runs in real mode only. As such, it uses segment 
registers and cannot extract more than at most 64kB (there probably is a limit 
even before 64kB is reached, but I don't remember all the details). As we know 
that we are never going to deal with more than 64kB of data, we can also tell 
that the pattern frequency can never get bigger than 2^16 (in fact, it'll stay 
considerably smaller than that). Thus, I stripped out the reconst() function 
which would never get called. If you want to deal with larger images, you 
probably have to implement it, though.

Also, I managed to shrink the code size, by compressing all the preinitialized 
tables (using some kind of run length encoding); and I stripped off a few more 
bytes by ordering these tables in a way so that once I have initialized one 
table my registers already have the right values that I will need for 
initializing the next one.

Due to the small register file, there always is considerable register pressure 
when writing code for the x86. I managed to keep almost all data in registers, 
but this required me to split some of the registers into 4bit nybbles. You might 
need to keep this in mind if you have to make changes to the code.


Markus

-- 
Markus Gutschke
3637 Fillmore Street #106
San Francisco, CA 94123-1600
+1-415-567-8449
ma...@gu...

Re: [Etherboot-developers] Seperating out the x86 BIOS calls...

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

>Regarding the loader, I am starting to seperate out the decompressor
>from the rest of the code, so I can use the decompressor when booted
>under LinuxBIOS.  Saving 6 out of 17k is pretty significant in my
>book.  What I am aiming at is an inplace (or at least in bss)
>decompressor that runs in 32bit mode.

There are some limits of the de/compression code, Markus can explain
those.

>If that works we can permanently move the decompressor out of loader.S
>and possibly make that file readable, instead of #ifdef spagetti.

Bearing in mind that the decompressor isn't really part of the running
Etherboot image. It's the first part of the ROM image and the Etherboot
image is appended onto that. When the ROM gains control, it does a
"self-extract" so to speak.

[Etherboot-developers] Seperating out the x86 BIOS calls...

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

O.k. I just took a moment to skim the code to see what it would really
take to seperate out the x86 bios calls.  And all it requires
is to have a seperate stack for 16bit calls.  There may be some loader
issues as well, I have not looked at that in detail.

I would probably add a table of function pointers, as well so that 
the address of the 16bit code does not need to be known at compile
time.  For the PXE case that is a significant consideration.

Regarding the loader, I am starting to seperate out the decompressor
from the rest of the code, so I can use the decompressor when booted
under LinuxBIOS.  Saving 6 out of 17k is pretty significant in my
book.  What I am aiming at is an inplace (or at least in bss)
decompressor that runs in 32bit mode.

If that works we can permanently move the decompressor out of loader.S
and possibly make that file readable, instead of #ifdef spagetti.

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] Etherboot 5.0.7rc2 at rom-o-matic

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

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

> >DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  -o bin32/linuxbios.o -c linuxbios.c
> >In file included from linuxbios_tables.h:4,
> >                 from linuxbios.c:2:
> >/usr/include/stdint.h:37: warning: redefinition of `int8_t'
> >stdint.h:9: warning: `int8_t' previously declared here
> 
> I think this is my fault. I included stdint.h in osdep.h and osdep.h is
> included by etherboot.h so linuxbios.c includes it twice, the other
> place from linuxbios_tables.h. Just remove the include of stdint.h from
> linuxbios_tables.h.

Backporting my small changes from 5.1.x looks like.  
Actually just include "stdint.h" instead of <stdint.h> in
linuxbios_tables.h

However we work it the fewer external headers we include by accident
or on purpose the more reproducible the build of etherboot will be.

Eric

Re: [Etherboot-developers] Re: [Etherboot-users] Etherboot 5.0.7rc2 at rom-o-matic

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

>DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  -o bin32/linuxbios.o -c linuxbios.c
>In file included from linuxbios_tables.h:4,
>                 from linuxbios.c:2:
>/usr/include/stdint.h:37: warning: redefinition of `int8_t'
>stdint.h:9: warning: `int8_t' previously declared here

I think this is my fault. I included stdint.h in osdep.h and osdep.h is
included by etherboot.h so linuxbios.c includes it twice, the other
place from linuxbios_tables.h. Just remove the include of stdint.h from
linuxbios_tables.h.

Thanks for the heads up.

Re: [Etherboot-developers] Re: [Etherboot-users] Etherboot 5.0.7rc2 at rom-o-matic

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

On Mon, 15 Jul 2002 12:38:58 -0600 Eric W Biederman <ebi...@ln...>
wrote:
>Marty Connor <ma...@et...> writes:
>> I'm wondering if anyone is successfully making LinuxBIOS ROM images at
>> rom-o-matic.net.
>There is a commented line in Config that has a recommended set of options
>for a LinuxBIOS build.  You can start there.

Hmm, I seem not to be able to compile a .ebi file.  Can you give a Config
and a "make" line that work?  I also am not sure of whether .elf or .ebi
is the target I really want. 

Marty


make: Entering directory `/tmp/ROMYl87Lc'
kgcc -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -
DELF_IMAGE -DCONSOLE_SERIAL -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -
DCOMPARM=0x03 -DCONFIG_PCI_DIRECT -DCONFIG_TSC_CURRTICKS -DCOMPRESERVE -
DLINUXBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -
mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -
Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -
DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  -DINCLUDE_3C90X -o bin32/3c90x.o -
c 3c90x.c
kgcc -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -
DELF_IMAGE -DCONSOLE_SERIAL -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -
DCOMPARM=0x03 -DCONFIG_PCI_DIRECT -DCONFIG_TSC_CURRTICKS -DCOMPRESERVE -
DLINUXBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -
mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -
Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -
DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  -DINCLUDE_3C90X  -o bin32/config-
3c90x.o -c config.c
kgcc -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -
DELF_IMAGE -DCONSOLE_SERIAL -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -
DCOMPARM=0x03 -DCONFIG_PCI_DIRECT -DCONFIG_TSC_CURRTICKS -DCOMPRESERVE -
DLINUXBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -
mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -
Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -
DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  -o bin32/pci.o -c pci.c
gcc -E -Wp,-Wall -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -
DTRY_FLOPPY_FIRST=0 -DELF_IMAGE -DCONSOLE_SERIAL -DCOMCONSOLE=0x3F8 -
DCONSPEED=9600 -DCOMPARM=0x03 -DCONFIG_PCI_DIRECT -DCONFIG_TSC_CURRTICKS
-DCOMPRESERVE -DLINUXBIOS -Os -ffreestanding -fstrength-reduce -fomit-
frame-pointer -mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-
functions=1 -Wall -W -Wno-format -Wno-unused -DVERSION_MAJOR=5 -
DVERSION_MINOR=0 -DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  start32.S | as 
-o bin32/start32.o
{standard input}: Assembler messages:
{standard input}:81: Warning: indirect ljmp without `*'
kgcc -DANS_DEFAULT=ANS_NETWORK -DBACKOFF_LIMIT=7 -DTRY_FLOPPY_FIRST=0 -
DELF_IMAGE -DCONSOLE_SERIAL -DCOMCONSOLE=0x3F8 -DCONSPEED=9600 -
DCOMPARM=0x03 -DCONFIG_PCI_DIRECT -DCONFIG_TSC_CURRTICKS -DCOMPRESERVE -
DLINUXBIOS -Os -ffreestanding -fstrength-reduce -fomit-frame-pointer -
mcpu=i386 -malign-jumps=1 -malign-loops=1 -malign-functions=1 -Wall -W -
Wno-format -Wno-unused -DVERSION_MAJOR=5 -DVERSION_MINOR=0 -
DVERSION=\"5.0.7rc2\" -DRELOC=0x94000  -o bin32/linuxbios.o -c linuxbios.c
In file included from linuxbios_tables.h:4,
                 from linuxbios.c:2:
/usr/include/stdint.h:37: warning: redefinition of `int8_t'
stdint.h:9: warning: `int8_t' previously declared here
/usr/include/stdint.h:38: warning: redefinition of `int16_t'
stdint.h:10: warning: `int16_t' previously declared here
/usr/include/stdint.h:39: conflicting types for `int32_t'
stdint.h:11: previous declaration of `int32_t'
/usr/include/stdint.h:44: warning: redefinition of `int64_t'
stdint.h:12: warning: `int64_t' previously declared here
/usr/include/stdint.h:49: warning: redefinition of `uint8_t'
stdint.h:4: warning: `uint8_t' previously declared here
/usr/include/stdint.h:50: warning: redefinition of `uint16_t'
stdint.h:5: warning: `uint16_t' previously declared here
/usr/include/stdint.h:52: conflicting types for `uint32_t'
stdint.h:6: previous declaration of `uint32_t'
/usr/include/stdint.h:59: warning: redefinition of `uint64_t'
stdint.h:7: warning: `uint64_t' previously declared here
make: *** [bin32/linuxbios.o] Error 1
make: Leaving directory `/tmp/ROMYl87Lc'

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

Re: [Etherboot-developers] Etherboot 5.0.7 release planning

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

On Tue, 16 Jul 2002 ke...@us... 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.

Michael

[Etherboot-developers] Etherboot 5.0.7 release planning

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

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.