etherboot-developers — Discussion of developer issues

[Etherboot-developers] About multicast

[zhiguo d. <dz...@ho...>]

But I can not see any code that about multicast in NIC driver code?

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

[Etherboot-developers] About multicast

[zhiguo d. <dz...@ho...>]

   Are there any NIC can support multicast now?

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

[Etherboot-developers] Fancy menu system

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

Good morning etherboot community,

I spent some half nights on this sub-project and now want to release
the first demo menu featuring graphics at 320x200 (256 colours).
It's in its development, that's why I won't release the source code
for building it right now: I first want the worst bugs fixed before
any other people dig inside.

The menu image is about 255k, which seems rather much. One of the
reasons is that I found no time for even the cheapest graphics
compression, and having a total of > 220,000 graphics pixels has its
costs. The pure code (which must be loaded anyway) is about 19k, plus
the "ressource map" with 6k, which in my opinion is small a footprint.

The menu - in this form - offers the choice between three boot options
(/dev/hda, tftp:/lts/vmlinuz.ltsp and /dev/fd0) as well as the option
to get the computer halted (no acpi funstuff, just the display that
the user may turn off the box); a timeout defaults to booting Linux
after some seconds, with timeoutbar. I borrowed design as well as some
additional graphics inside, you will see and recognize. Requirements:
Etherboot with chained-loader-support (5.0.6 definitively works, but
even 5.0.1 should do... I only have a .6 here) and some kind of
vga-graphics-board. Should later a 640x400 mode be implemented, some
vesa stuff on your board would be required too, but that's out of
reach today.

Please understand this as a feature demonstration, just a step on my
way to go. When the worst bugs are out and at least the basic set of
features is in (e.g. there is not an arithmetic multiplication yet, just
add and sub working) it will go open-source no doubt. Just sit down
and *whow it can do this* :-)

The script code that generated this menu (sorry, not yet the bitmaps I
created/copied) is available for http download along with the menu.nbi
file, get it from http://www.feldhausnetz.de/ebm/menu.zip

Please give your opinion. Any features you really *really* need?
Anything you would have done completely different (except design,
which is cheap-o, quarter-an-hour, late-night job)? Like it (I hope)?

Best regards,
 Anselm Martin Hoffmeister <eth...@ho...>
 Stockholm Projekt Computer-Service

[Etherboot-developers] mknbi mkelf -1.9 stack problem.

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

Problem: 
mknbi && mkelf assume they will be given a stack pointer that can be
accessed with RELOC as their %ss segment base address.  mknbi
handles this better as it calls _real_to_prot before calling _prot_to_real.
With the _real_to_prot call first the stack pointer is mangled into
something that works when etherboot runs at an unexpected address.  

The 32bit entry code does much less mangling of the stack pointer and
breaks more visibly.  When 5.1.2+ runs at unexpected address, both
code bases break to some degree.

I believe this is the primary reason why mkelf fails under 5.1.2+.

Ken does this sound correct?

If so when I have a moment I will add the code to switch to a private
internal stack, so this issue will go away, unless someone beats
me to it :)

If I have a couple of more seconds I will merge in the mkelfImage
support for working in even more arbitrary conditions.

Eric


/**************************************************************************
_PROT_TO_REAL - Go from Protected Mode to REAL Mode
**************************************************************************/
	.globl	_prot_to_real
_prot_to_real:
	.code32
	popl	%eax
	subl	$RELOC,%eax		/* Adjust return address */
	pushl	%eax
	subl	$RELOC,%esp		/* Adjust stack pointer */
#ifdef	GAS291
	ljmp	$REAL_CODE_SEG,$1f-RELOC	/* jump to a 16 bit segment */
#else
	ljmp	$REAL_CODE_SEG,$1f-_start	/* jump to a 16 bit segment */
#endif	/* GAS291 */
1:
	.code16
	movw	$REAL_DATA_SEG,%ax
	movw	%ax,%ds
	movw	%ax,%ss
	movw	%ax,%es
	movw	%ax,%fs
	movw	%ax,%gs

	/* clear the PE bit of CR0 */
	movl	%cr0,%eax
	andl	$0!CR0_PE,%eax
	movl	%eax,%cr0

	/* make intersegment jmp to flush the processor pipeline
	 * and reload %cs:%eip (to clear upper 16 bits of %eip).
	 */
	DATA32 ljmp	$(RELOC)>>4,$2f-_start
2:
	/* we are in real mode now
	 * set up the real mode segment registers : %ds, $ss, %es
	 */
	movw	%cs,%ax
	movw	%ax,%ds
	movw	%ax,%es
	movw	%ax,%ss
	sti
	DATA32 ret	/* There is a 32 bit return address on the stack */
	.code32

Re: [Etherboot-developers] more on the eepro100 problem

[Christoph P. <chr...@gm...>]

Hello,

one of my jobs is also to maintain an eepro100 driver
ported from linux in our company OS. I ported from
2.2.18 kernel.

We saw the "RX out of resource" and "out of resource"
error, but here definitly the pools are available,
but the driver may not fill them up, as if the 
interrupts will not come.

Perhaps this delay in handling chip I/O solved this,
I will have a look !

Christoph


Vasil Vasilev wrote:
> 
> Is this a particular version of eepro100, e.g. 82559er or 82559 or whatever,
> or is this valid for all of them.
> 
> We were using linux 2.2.19 with eepro100 for a while and all was fine. This
> was on PCs with Intel or Transmeta processors both about 800MHz. I see an
> extra delay introduced from 2.2.18 to 2.2.19. Could this the problem?
> 
> I was maintaining a proprietary eepro100 driver and never seen this problem on
> the same machines. I've seen others but not this.
> 
> On Fri, 6 Sep 2002, Christoph Plattner wrote:
> 
> > One question:
> >
> > What type of PC is the card (eepro100) plugged in ?
> > Is this a very fast PC ? More than 500MHz (700, 1GHz...)
> >
> > I have found problems with a 2.2.18 Linux driver. Up to a
> > 500MHz machine it works, on 700MHz sporadic problems
> > were seen, on 1GHz machine and higher, the card will not
> > work.
> >
> > The EEPRO100 community of D. Becker never wants to
> > discuss the problem and the apropriate changes in
> > newer versions. Those knowledge has helped us to
> > understand better problems handling the eepro100
> > card, also in etherboot and GRUB.
> >
> > I hope, I will have time to play around one day
> > concerning this problem.
> >
> > Christoph P.
> >
> >
> > Ronald G Minnich wrote:
> > >
> > > A look at the assembly code shows "everything's fine".
> > >
> > > This is really curious. I can make the device do things, packets flow,
> > > etc. but .... all inw operations return 0!
> > >
> > > Did the registers on the 82559er suddenly become wider or different
> > > somehow?
> > >
> > > ron
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: OSDN - Tired of that same old
> > > cell phone?  Get a new here for FREE!
> > > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > > _______________________________________________
> > > Etherboot-developers mailing list
> > > Eth...@li...
> > > https://lists.sourceforge.net/lists/listinfo/etherboot-developers
> >
> >
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

Re: [Etherboot-developers] more on the eepro100 problem

[Vasil V. <vas...@sy...>]

Is this a particular version of eepro100, e.g. 82559er or 82559 or whatever,
or is this valid for all of them.

We were using linux 2.2.19 with eepro100 for a while and all was fine. This
was on PCs with Intel or Transmeta processors both about 800MHz. I see an
extra delay introduced from 2.2.18 to 2.2.19. Could this the problem?

I was maintaining a proprietary eepro100 driver and never seen this problem on
the same machines. I've seen others but not this.

On Fri, 6 Sep 2002, Christoph Plattner wrote:

> One question:
>
> What type of PC is the card (eepro100) plugged in ?
> Is this a very fast PC ? More than 500MHz (700, 1GHz...)
>
> I have found problems with a 2.2.18 Linux driver. Up to a
> 500MHz machine it works, on 700MHz sporadic problems
> were seen, on 1GHz machine and higher, the card will not
> work.
>
> The EEPRO100 community of D. Becker never wants to
> discuss the problem and the apropriate changes in
> newer versions. Those knowledge has helped us to
> understand better problems handling the eepro100
> card, also in etherboot and GRUB.
>
> I hope, I will have time to play around one day
> concerning this problem.
>
> Christoph P.
>
>
> Ronald G Minnich wrote:
> >
> > A look at the assembly code shows "everything's fine".
> >
> > This is really curious. I can make the device do things, packets flow,
> > etc. but .... all inw operations return 0!
> >
> > Did the registers on the 82559er suddenly become wider or different
> > somehow?
> >
> > ron
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Etherboot-developers mailing list
> > Eth...@li...
> > https://lists.sourceforge.net/lists/listinfo/etherboot-developers
>
>

Re: [Etherboot-developers] more on the eepro100 problem

[Ronald G M. <rmi...@la...>]

On Fri, 6 Sep 2002, Christoph Plattner wrote:

> What type of PC is the card (eepro100) plugged in ?
> Is this a very fast PC ? More than 500MHz (700, 1GHz...)

This is a small PC/104 card with a PIII/750. It is highly integrated.

I'm seeing all sorts of trouble with reads on polled I/O, it is quite
mysterious.

> I have found problems with a 2.2.18 Linux driver. Up to a
> 500MHz machine it works, on 700MHz sporadic problems
> were seen, on 1GHz machine and higher, the card will not
> work.

but I expect inw to work? Does it all return zero's in your case.

ron

Re: [Etherboot-developers] more on the eepro100 problem

[Christoph P. <chr...@gm...>]

One question:

What type of PC is the card (eepro100) plugged in ?
Is this a very fast PC ? More than 500MHz (700, 1GHz...)

I have found problems with a 2.2.18 Linux driver. Up to a
500MHz machine it works, on 700MHz sporadic problems
were seen, on 1GHz machine and higher, the card will not
work.

The EEPRO100 community of D. Becker never wants to 
discuss the problem and the apropriate changes in 
newer versions. Those knowledge has helped us to
understand better problems handling the eepro100
card, also in etherboot and GRUB.

I hope, I will have time to play around one day
concerning this problem.

Christoph P.


Ronald G Minnich wrote:
> 
> A look at the assembly code shows "everything's fine".
> 
> This is really curious. I can make the device do things, packets flow,
> etc. but .... all inw operations return 0!
> 
> Did the registers on the 82559er suddenly become wider or different
> somehow?
> 
> ron
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Etherboot-developers mailing list
> Eth...@li...
> https://lists.sourceforge.net/lists/listinfo/etherboot-developers

-- 
-------------------------------------------------------
private:	chr...@gm...
company:	chr...@al...

[Etherboot-developers] more on the eepro100 problem

[Ronald G M. <rmi...@la...>]

A look at the assembly code shows "everything's fine".

This is really curious. I can make the device do things, packets flow,
etc. but .... all inw operations return 0!

Did the registers on the 82559er suddenly become wider or different
somehow?

ron

[Etherboot-developers] HMMM .... could inw be broken?

[Ronald G M. <rmi...@la...>]

This is etherboot 5.0.7. I am using an eepro100. The symptom is that
packets get sent out but etherboot never sees a control register status
indicating the packet was sent, and not bits ever show that one is
received.

Further looking around shows that EVERY inw returns 0!

I don't see how this is possible, but consider: all the outw's in the
code work, and all inw's return 0. Is there any way in which inw could be
busted?

ron

[Etherboot-developers] CONTACT ME

[DR.PETER A. <p_a...@ma...>]

Dear Sir or Madam,

While conducting an audit into the accounts of NIGERIA ELECTRIC POWER 
AUTHORITY ( N. E . P . A) account, prior to its privatization which is an
on going Governmental exercise, aimed at privatizing all Government owned
companies and parastatals. The BEREAU FOR PUBLIC ENTERPRISES (B. P. E) 
headed by Alhaji EL  Rufai and the PRESIDENTIAL TASK- FORCE ON 
PRIVATISATION,headed by His Excellency Alhaji Atiku Abubakar, The Vice 
President of the Federal Republic Nigeria .Directed us, members of the 
accounts department to carry out a thorough investigation into the 
activities of the above mentioned parastatals. It was while discharging our 
legal duty that we stumbled on an account that has been suspence for twelve
years, but that was assumed to have been accounted for as been utilized.
We discovered the total sum of Seventy- four million and thirty-five thousand
five hundred US dollars ($74,035,500.00).Initially stolen and hide by some
top officials of the parastatals,who from our investigation could not out
of fear transfer the said sum of money with its accruing interest to a safe
haven. After much consultation among ourselves i.e members of the 
Accounting Department, we decided to keep the money to ourselves. Its based
on this development that we decided to contact you to act as our foreign
partner. For you to act as the rightful owner of the money, that has been
owed you about twelve years ago, for the supply of Electrical Transformers.

We will want to assure you here that there are no risks involved in this
deal, as all unnecessary bottlenecks has been dismantled by us.We have 
prepared all the documents backing up this transaction.therefore we are
willing to compensate you with twenty percent of the alleged sum after the
money has been successfully transferred into your account. NOTE: That as
civil servants we are not authorized to operate foreign bank accounts. 
There is also no way we can pay the money into our domestic local accounts
here. We therefore formally solicit your assistance in this venture. We are 
hoping that you will find it .noble and wise doing business with us. Pls.

If our proposal interests you. Indicate so by sending us a reply immediately. 
Pls. Feel free to ask questions on issues that you do not  understand. 
Pls. reply message immediately and send us a reliable access
telephone and fax numbers. Urgency and secrecy is required in this 
transaction. We are eagerly looking forward to hearing from you.

Thanking you in anticipation of your kind consideration.

Yours faithfully

Dr.Peter Azu.

Accountant General Bureau for Public Enterprises.

Re: [Etherboot-developers] [COMMIT] contrib/mini-slamd

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

By way of finishing up details I just tested the slam client in
etherboot, and fixed one bug but it is definitely working now.

Previously heap.c could allocate a chunk of memory across as segment
boundary, which caused problems.  I don't see why rolling over
a 4GB boundary should but it did.

Eric

Re: [Etherboot-developers] 5.1.2+ Issues

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

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

> >Ken I'm not certain what your ELF problems are.
> >I will have to test the output of mkelf-linux on a non-LinuxBIOS
> >machine and see what I get.  I cannot reproduce the problem.
> 
> I put the tomsrtbt image I usually netboot at
> 
> 	http://www.etherboot.org/tomsrtbt-2.0.103.nb
> 
> It's an ELF image generated from a bzImage and initrd and requires a
> PCBIOS Etherboot. See if you have any luck with it. diself will show you
> its segments.

O.k. I took a first cursory look.  And the problem occurs here as well.

I have made some small changes to the cvs copy of mknbi, that address
some of the problems.  At first glance it appears the problem is
the assumptions about the state etherboot will leave the system in
are two strong.  It does not appear to be an etherboot problem.

While looking I found one more fix for the e820 code now committed.

You might want to play with:
ftp://ftp.lnxi.com/pub/src/mkelfImage/mkelfImage-1.16.tar.gz

I suspect etherboot 5.2 will require a new version of mknbi/mkelf.  I think
mkelf-linux will even fail if RELOCADDR is changed from 0x90000.

Eric
k

[Etherboot-developers] [COMMIT] contrib/mini-slamd

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

O.k. I took the last part of this holiday weekend and wrote 
a mini multicast server that works with the x-slam multicast
protocol in etherboot. Virtually everything is hard coded,
but it is enough to serve up one file.

This removes the server bottleneck from releasing etherboot-5.1.2.

I suspect atftp-0.6 will also work with the etherboot tftp multicast
client but I haven't tested that one yet.

Just as I was finishing this up I received word that my grandfather
has passed away, so I'm likely to be preoccupied with other things
that etherboot for a while. 

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

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

> >Ok, did more testing. Booted a 5.1.2 (up to CVS) unrelocated compressed
> >image using a 5.0.7 ROM. Menu comes up ok and I can load menus ad
> >infinitum. I can load an ELF bzImage and initrd ok but it stops after
> >loading has finished, probably jumps into hyperspace. I cannot load a
> >tagged FreeDOS image, it complains about the clash in low memory.
> 
> Ok, after the last round of changes, I can now boot a FreeDOS image
> (NBI).  Either Michael's fix or the prezero fix worked. It still can't
> launch an non-multiboot ELF image. I guess the launch code has a bug.

Good. One code path is working.

Do the standard NBI images use a 16bit or a 32bit entry point?

From my testing I am certain xstart32(entry, a, b, c) gets to the
entry point, under LinuxBIOS Multiboot or not.

What I have to narrow down is why ELF images don't work.
I have two possibilities.
A) The stack contents are incorrect.
B) It is an environment issue that doesn't show up under LinuxBIOS.

Either of which are possible, if I knew some of the NBI images used
a 32bit entry point, and how well they worked.  I could deal
with a number of possibilities.

I am going to first examine the stack possibility as that is
the most likely issue.  And the start checking out the environmental
ones.  But first I hope, a test multicast server...

Eric

Re: [Etherboot-developers] I've just checked and ...

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

Ronald G Minnich <rmi...@la...> writes:

> On 31 Aug 2002, Eric W Biederman wrote:
> 
> > I am getting a reading of about 1.37 to 1.4 microseconds for an outb,
> > on a dual 2.4 Xeon.
> 
> shucks. It was too good to last. I was ok with +- 10%, but 40%?
> 
> Anyway, I'll see if there's something else we can do. But I think you
> might want to leave this in for the "if all else fails" case.
> 
> time for plan b.

I will keep it around but I would definitely like something better.

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

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

> There a bug in assembling .S and .s files due to the C preprocessor.
> The i386 in .arch i386 gets replaced by 1 and as barfs. I fixed it by
> adding -Ui386 to the assemble rules (2 places). Not sure if this is the
> best way to fix it.

Sorry.  I only saw that in start32.S -Ui386 in the assembly rules
is probly good enough.  That is my cheap insurance that all of the
assembly will run on a 386.

Eric

Re: [Etherboot-developers] I've just checked and ...

[Ronald G M. <rmi...@la...>]

On 31 Aug 2002, Eric W Biederman wrote:

> I am getting a reading of about 1.37 to 1.4 microseconds for an outb,
> on a dual 2.4 Xeon.

shucks. It was too good to last. I was ok with +- 10%, but 40%?

Anyway, I'll see if there's something else we can do. But I think you
might want to leave this in for the "if all else fails" case.

time for plan b.

ron

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

>Ok, did more testing. Booted a 5.1.2 (up to CVS) unrelocated compressed
>image using a 5.0.7 ROM. Menu comes up ok and I can load menus ad
>infinitum. I can load an ELF bzImage and initrd ok but it stops after
>loading has finished, probably jumps into hyperspace. I cannot load a
>tagged FreeDOS image, it complains about the clash in low memory.

Ok, after the last round of changes, I can now boot a FreeDOS image
(NBI).  Either Michael's fix or the prezero fix worked. It still can't
launch an non-multiboot ELF image. I guess the launch code has a bug.

Seems like a good time to issue a snapshot:

	http://www.etherboot.org/etherboot-5.1.2rc4.tar.bz2

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

There a bug in assembling .S and .s files due to the C preprocessor.
The i386 in .arch i386 gets replaced by 1 and as barfs. I fixed it by
adding -Ui386 to the assemble rules (2 places). Not sure if this is the
best way to fix it.

Re: [Etherboot-developers] 5.1.2+ Issues

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

>Ken I'm not certain what your ELF problems are.
>I will have to test the output of mkelf-linux on a non-LinuxBIOS
>machine and see what I get.  I cannot reproduce the problem.

I put the tomsrtbt image I usually netboot at

	http://www.etherboot.org/tomsrtbt-2.0.103.nb

It's an ELF image generated from a bzImage and initrd and requires a
PCBIOS Etherboot. See if you have any luck with it. diself will show you
its segments.

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

>This still ensures the image is loaded to memory, though it will not
>check the extra memory length.  

You can look on this as an opportunity to make ELF images more attractive
than NBI images. If you really want to check that an image is correctly
loaded and that the memory is valid there, then checksum the memory area
after loading and compare it with the checksum in the note section.

I would be happy to see NBI format for Linux images go away but unless
there are telling advantages in favour of ELF, I can't press the suit too
strongly. And I cannot remove tagged image support from the code base
because it provides useful loading of ROM, PXE and DOS images. Things
might have been different if Jamie had used a standard like ELF (I
don't know if ELF was already speced that many years ago) because of
the architecture independence, sane treatment of the byte order issue,
lack of x86isms, support for additional sections, etc. As you can see
from the NBI spec, it was never refined beyond a draft, presumably nobody
had any significant comment to make on it.

This is orthogonal to the issue of zeroing the BSS in ELF segments which
is I agree is a good thing because it's speced that way.

Re: [Etherboot-developers] I've just checked and ...

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

Ronald G Minnich <rmi...@la...> writes:

> The 5.0.5 timer.[ch] is identical it seems with the 5.0.7 version. So my
> 5.0.5 version should be fine with 5.0.7. My version has the "don't use
> timer2" patch. I am attaching it for all of you to take a look see and
> comment. I think this might help with my current problems as Smartcore
> systems don't actually have a TIMER2 -- all timeouts go to 0.
> 
> ron

Ron in playing with this code I wanted to see how accurate it's
estimates were. 

> // this is the "no timer2" version. 
> // to calibrate tsc, we get a TSC reading, then to 1,000,000 outbs to port 0x80
> // then we read TSC again, and divide the difference by 1,000,000
> // we have found on a wide range of machines that this gives us a a good
> microsecond value
> 
> // to +- 10%. On a dual AMD 1.6 Ghz box, it gives us .97 microseconds, and on a
> 
> // 267 Mhz. p5, it gives us 1.1 microseconds. 
> // also, since gcc now supports long long, we use that. 
> // also no unsigned long long / operator, so we play games. 
> // about the only thing you can do with long longs, it seems, is return them and
> assign them.

I am getting a reading of about 1.37 to 1.4 microseconds for an outb,
on a dual 2.4 Xeon.

I guess this isn't too bad as the delays will take longer than expected
with an estimate of 1.0 microsecond per outb.  But the estimate is so
inaccurate at + 40% that I'm not really certain it is useful.

Eric

[Etherboot-developers] 5.1.2+ Issues

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

Ken Yap         -- ELF images hang after loader.
Timothy Legge   -- 486 floppy boot failure.
Ron Minnich     -- No timer2
Eric Biederman  -- No Multicast test code
Eric Biederman  -- Documenation is not updated to match the core changes.
Ron Minnich && 
atul srivastava -- 82559ER problems
Eric Biederman  -- No relocatable drivers.

Thoughts on fixes.

Ken I'm not certain what your ELF problems are.
I will have to test the output of mkelf-linux on a non-LinuxBIOS
machine and see what I get.  I cannot reproduce the problem.

I have a 386 and a 486 at home and if I have a moment this weekend,
I will attempt to reproduce the 486 hang.  The 386 doesn't have a nic
but that doesn't matter.

Having code that works without timer2 seems important because
there have also been some well know chipsets that loose the high
half, and give erradic timings if it is used.  So I am definitely
looking at what it will take to merge Ron's, changes.

I definitely plan on writing a mini-server this long weekend,
so other people can test my multicast code.

The documentation, and driver issues are noted so I don't forget they exist.
There has been a lot of traffic lately.

Hopefully in the next day or two we can get the core debugged well
enough that the major problem will be drivers that don't relocate
properly.


Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

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

> >The final issue is how to handle unitialized areas of an image, the
> >bss parts of a segment.  For ELF it is required that they be zeroed,
> >and the zeroing is cheap and it increases reproducibility of behavior.
> >For tagged images we do all of the zeroing before we load anything to
> >ram so the zeroing it will not cause problems.  If it is felt that the
> >zeroing is a problem or that the unitialized memory length check is
> >a problem we can simply not pass that information to prep_segment.
> 
> As I said what do do with the gap between the image length and the memory
> length wasn't considered in the NBI spec. You are placing an
> interpretation on it that wasn't in its design. I may simply make them
> the same in future versions of mknbi, but Etherboot has to work with
> existing NBI images which are compliant. 

Even zeroing the gap the etherboot cvs tree works with existing NBI images.

> If you feel that strongly about
> zeroing RAM for NBI you can make it a compile option. If a loaded program
> depends on undefined areas being zero, I consider that a bug and zeroing
> it masks the bug.

Which may or may not be a good thing.  Basically the interpretation
is that the memory length in the NBI spec is useless.  I can live with that.

I have made the following change to tagged_probe:

		if (!prep_segment(
			sh->loadaddr,
			sh->loadaddr + sh->imglength,
-			sh->loadaddr + sh->memlength,
+			sh->loadaddr + sh->imglength,
			loc, loc + sh->imglength)) {
			return 0;
		}

This totally ignores the memory length and only worries about the well
defined portion, of the tagged image.

This still ensures the image is loaded to memory, though it will not
check the extra memory length.  

Eric