etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] Adding real-mode stack for prot_to_real

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

>We also need to load the GDT, and segment registers with the values
>mknbi assumes are in use.  A protected mode entry point can only
>sanely assume a flat 32bit address space with a base address of 0.
>I have played with the former and checked it into the developer etherboot
>CVS tree.  But I had not identified the remaing stack issue.

I have some time this weekend and will get a round tuit. It's fairly
easy to fix, just do what menustart.S does, that is, switch GDTs, get a
private stack, in this case at the top of the 6kB allocated to
first32.c, then copy the 3 arguments over and jump to the entry point of
first32.c.

Re: [Etherboot-developers] Adding real-mode stack for prot_to_real

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

Marc Singer <el...@bu...> writes:

> On Fri, Sep 20, 2002 at 05:12:04PM -0600, Eric W Biederman wrote:
> > I have a confirmation for you.   mknbi fails to setup it's own stack
> > and then behaves badly if etherboot doesn't give it a stack.
> > 
> > I have triggered this bug in the development version by relocating
> > etherboot.
> > 
> > If you have the time to change mknbi to setup it's own stack 1K should
> > be sufficient, it would be appreciated.
> > 
> > The problem triggers in prot_to_real && real_to_prot.
> > 
> 
> If I understand it correctly, the problem is that the stack etherboot
> uses is greater than 64KiB away from the base address of mknbi.  So,
> when prot_to_real substracts $RELOC from the %esp and installs the
> real-mode %ss, the stack has moved and is probably trouncing something
> interesting.  

We also need to load the GDT, and segment registers with the values
mknbi assumes are in use.  A protected mode entry point can only
sanely assume a flat 32bit address space with a base address of 0.
I have played with the former and checked it into the developer etherboot
CVS tree.  But I had not identified the remaing stack issue.

The stack moving and trouncing something interesting is less of a problem.

> Now we could make real-mode %ss behave and leave the
> stack where it is, or we could setup a real-mode stack for the benefit
> of BIOS calls.

I would suggest making the protected mode stack behave.  We don't
need to touch it unless we return to etherboot.
 
> I've made a patch that I expect would work, but it doesn't.  This is
> against mknbi-1.2-7.  The behavior is a hard crash before I see
> anything from first32.c.  I've put the real_stack in .code32 and in
> .data with no change in behavior.  The odd thing is that if I only
> change the stack pointer to 0x00090000 before calling first() then
> I'll see the logon messages.  It must be something simple that I'm not
> noticing.  
> 
> Ideas?

I am not totally familiar with the usages in mknbi, but in etherboot
I seem to recall some of the callers passing values on the stack through
real_to_prot, and prot_to_real.  So switching stack may not work.

> BTW, I am aware that this won't work when we start in real-mode and
> first to protected mode first.  I think all we need to do is push an
> initial 32 bit stack pointer before the first call to real_to_prot and
> all should be good.

Starting in real mode actually appears to behave better, some better
in the existing cases.  A real mode stack at a semi random location is less
deadly than getting your segment registers wrong.

Eric

[Etherboot-developers] Adding real-mode stack for prot_to_real

[Marc S. <el...@bu...>]

On Fri, Sep 20, 2002 at 05:12:04PM -0600, Eric W Biederman wrote:
> I have a confirmation for you.   mknbi fails to setup it's own stack
> and then behaves badly if etherboot doesn't give it a stack.
> 
> I have triggered this bug in the development version by relocating
> etherboot.
> 
> If you have the time to change mknbi to setup it's own stack 1K should
> be sufficient, it would be appreciated.
> 
> The problem triggers in prot_to_real && real_to_prot.
> 

If I understand it correctly, the problem is that the stack etherboot
uses is greater than 64KiB away from the base address of mknbi.  So,
when prot_to_real substracts $RELOC from the %esp and installs the
real-mode %ss, the stack has moved and is probably trouncing something
interesting.  Now we could make real-mode %ss behave and leave the
stack where it is, or we could setup a real-mode stack for the benefit
of BIOS calls.

I've made a patch that I expect would work, but it doesn't.  This is
against mknbi-1.2-7.  The behavior is a hard crash before I see
anything from first32.c.  I've put the real_stack in .code32 and in
.data with no change in behavior.  The odd thing is that if I only
change the stack pointer to 0x00090000 before calling first() then
I'll see the logon messages.  It must be something simple that I'm not
noticing.  

Ideas?

BTW, I am aware that this won't work when we start in real-mode and
first to protected mode first.  I think all we need to do is push an
initial 32 bit stack pointer before the first call to real_to_prot and
all should be good.

============================================================

diff -u -r ../mknbi-1.2.7-original/start32.S ../mknbi-1.2.7/start32.S
--- ../mknbi-1.2.7-original/start32.S	2002-03-04 04:44:53.000000000 -0800
+++ ../mknbi-1.2.7/start32.S	2002-09-20 21:07:54.000000000 -0700
@@ -350,6 +350,7 @@
 	movl	%eax,%es
 	movl	%eax,%ss
 	addl	$RELOC,%esp		/* Fix up stack pointer */
+	popl	%esp			/* Restore 32 bit stack */
 	xorl	%eax,%eax
 	movl	%eax,%fs
 	movl	%eax,%gs
@@ -367,6 +368,10 @@
 	popl	%eax
 	subl	$RELOC,%eax		/* Adjust return address */
 	pushl	%eax
+	movl	%esp, %edx
+	lea	real_stack, %eax
+	movl	%eax, %esp
+	pushl	%edx			/* Save the 32 bit stack pointer */
 	subl	$RELOC,%esp		/* Adjust stack pointer */
 #ifdef	GAS291
 	ljmp	$REAL_CODE_SEG,$1f-RELOC	/* jump to a 16 bit segment */
@@ -437,9 +442,15 @@
 
 /* Other variables */
 #ifdef	FIRST32PM
+.global initsp
 initsp:	.long	0
 #else
+.global initsp
 initss:	.word	0
 initsp:	.word	0
 days:	.long	0
 #endif
+
+.data
+real_stack_end:	.fill	1024,1,0	/* Real-mode only stack */
+real_stack:

Re: Re[2]: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

Anselm Martin Hoffmeister <eth...@ho...> writes:

> >> I thought of one other possibility to try.  We might be stomping BIOS tables
> >> if etherboot is loading to high.  Setting RELOCADDR lower might be worth
> >> a shot.
> 
> Another idea: There is the possibility for etherboot to load the hda
> MBR as boot block (or hdX-partitions even). Couldn't we establish an
> option LOCALBOOTDEVICE= for this purpose (if set, then instead of
> returning to BIOS for local boot, get the MBR ourselves)?
> 
> I know this is really against reason on working machines, but
> obviously, that machines isn't working as it should. And this way, you
> could hinder users from tampering with the Bios boot device settings,
> as (at least for my setup) no matter that setting, Etherboot ROM to be
> first boot priority. Even if user can crack the BIOS-Password (by
> looking over someone's shoulder, for example) they could NOT
> floppy-boot anyway...
> 
> Just an idea.

To some extent we already support this.  And we even have ide drivers.
Basically someone needs to take a day or two with 5.1.2+ and get
this going if they want it.

Eric

Re[2]: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

>> I thought of one other possibility to try.  We might be stomping BIOS tables
>> if etherboot is loading to high.  Setting RELOCADDR lower might be worth
>> a shot.

Another idea: There is the possibility for etherboot to load the hda
MBR as boot block (or hdX-partitions even). Couldn't we establish an
option LOCALBOOTDEVICE= for this purpose (if set, then instead of
returning to BIOS for local boot, get the MBR ourselves)?

I know this is really against reason on working machines, but
obviously, that machines isn't working as it should. And this way, you
could hinder users from tampering with the Bios boot device settings,
as (at least for my setup) no matter that setting, Etherboot ROM to be
first boot priority. Even if user can crack the BIOS-Password (by
looking over someone's shoulder, for example) they could NOT
floppy-boot anyway...

Just an idea.

Anselm

Re: [Etherboot-developers] ADMTech an983b

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

>I notice this hardware ID also does not exist in the etherboot code, which
>I'm guessing is my problem, so my question is: would it be possible to
>easily add this chip to the etherboot code? If so, which files would I
>modify? I'm guessing NIC, Roms and tulip.c based on simply grepping, but any
>tips would be appreciated...

NIC and config.c, Should be obvious. Please send me the patch when you
get it working.

[Etherboot-developers] ADMTech an983b

[John H. <jh...@gm...>]

Hi All,

I've been trying to get etherboot going with an an983b from ADMTech, but to
no avail, the probe cannot find the device. While searching for a solution,
I found this post:

http://www.uwsg.iu.edu/hypermail/linux/net/0204.3/0002.html

To sum it up - the only real problem is that the nic identifies itself as
[vendor 0x1317, device 0x9511] and this is not listed in tulip_core.c in the
kernel code; simply adding the values to this file fixes the problem and
allows the NIC to be recognized.

I notice this hardware ID also does not exist in the etherboot code, which
I'm guessing is my problem, so my question is: would it be possible to
easily add this chip to the etherboot code? If so, which files would I
modify? I'm guessing NIC, Roms and tulip.c based on simply grepping, but any
tips would be appreciated...

-John

Re: [Etherboot-developers] Prism2 driver update?

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

The latest linux-wlan-ng is 0.1.15pre8, Looking at the changelog
[ftp://ftp.linux-wlan.org/pub/linux-wlan-ng/CHANGES], a few updates have
happened that I noticed since 0.1.13
- Applied pizza's patch to remove the pb_t structure and make all
    802.11<->ether conversions happen in-place.  Noticeably reduces
    cpu load.  Also includes a few misc bugfixes to the conversion code.
- Partial rewrite of the PCI/PLX/USB driver internals
- Fix an alignment bug in the rx path.
- Partial rewrite of copy_to_bap.
- More cleanups/deletions/fixes in wlan_compat.h
- Updates to hfa384x.h to reflect latest documentation

and David Gibson [the author and maintainer of the orinoco linux driver] has
a sept 13 update [http://ozlabs.org/people/dgibson/dldwd/]

Hope this helps out. :)
----- Original Message -----
From: "Michael Brown" <mb...@fe...>
To: "Boris" <bo...@th...>
Cc: <eth...@li...>
Sent: Thursday, September 19, 2002 2:39 AM
Subject: Re: [Etherboot-developers] Prism2 driver update?


> On Wed, 18 Sep 2002, Boris wrote:
> > What was the prism2 driver derrived from? The linux kernel? If so,
> > what version was it extracted from? I read that the linux driver has
> > been updated because it had some allocation problems. Make we should
> > take the latest linux driver and get that one working in etherboot.
> > Just in case the older driver had problems [which even I had with
> > larger then 20mb images].
>
> It was taken from 2.4.18-6mdk (Mandrake 8.2 release), which I think
> corresponds to linux-wlan-ng-0.1.13.  If you can point me towards the
> relevant changelog message and patches for the Linux kernel, I'll try to
> map them into the Etherboot driver.
>
> The Etherboot Prism2 driver comprises three header files (hfa384x.h,
> p80211hdr.h and wlan_compat.h), one main C file (prism2.c) and two wrapper
> C files (prism2_pci.c and prism2_plx.c).  The header files were lifted
> straight from the Linux kernel source without modifications, in order to
> make it easier to upgrade them, so that's a simple job.  In prism2.c,
> there are very few nontrivial routines:
>   hfa384x_docmd_wait
>   hfa384x_prepare_bap
>   hfa384x_copy_from_bap
>   hfa384x_copy_to_bap
>   hfa384x_cmd_access
>   hfa384x_drvr_getconfig
>   hfa384x_drvr_setconfig
>   hfa384x_wait_for_event
>   prism2_poll
>   prism2_transmit
> most of which have direct equivalents in the Linux kernel source, so it
> should be fairly straightforward to see which changes should be applied to
> which routines.
>
> Michael Brown
> http://www.fensystems.co.uk
>
>

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

On 18 Sep 2002, Eric W Biederman wrote:
> > > > Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
> > > > is an E820-related problem that I've fixed once before already, but I just
> > > > don't have time to hack on Etherboot at the moment.  However, if someone
> > > > can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
> > > > start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> > > > regain some spare time. :-)
> > > BIOS Bug.  Almost certainly.  All we do is return to the BIOS.
> > > Unless there is something we don't reset to it's original state?  Some
> > > bits of test code (Returning ealier to the BIOS) could identify if
> > > whatever it is has changed yet, so it should be trackable.
> > Thanks; that's confirmed what I thought would be the best debug strategy.
> > It's certainly a BIOS or hardware-specific problem; it will happen on a
> > batch of machines of the same hardware type.  We tried looking at Windows
> > 98's idea of a diagnostic boot log, but gave up when we found it contained
> > only six (unhelpful) lines.
> I thought of one other possibility to try.  We might be stomping BIOS tables
> if etherboot is loading to high.  Setting RELOCADDR lower might be worth
> a shot.

Will try, thanks.

> Which vesion of etherboot does the crawl show up with?

5.0.7.  I did send a floppy of 5.1 to be tried, but it wouldn't even load
up.  I won't find out any more until one of the problematic machines gets
delivered to me for testing.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Prism2 driver update?

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

On Wed, 18 Sep 2002, Boris wrote:
> What was the prism2 driver derrived from? The linux kernel? If so,
> what version was it extracted from? I read that the linux driver has
> been updated because it had some allocation problems. Make we should
> take the latest linux driver and get that one working in etherboot.
> Just in case the older driver had problems [which even I had with
> larger then 20mb images].

It was taken from 2.4.18-6mdk (Mandrake 8.2 release), which I think
corresponds to linux-wlan-ng-0.1.13.  If you can point me towards the
relevant changelog message and patches for the Linux kernel, I'll try to
map them into the Etherboot driver.

The Etherboot Prism2 driver comprises three header files (hfa384x.h,
p80211hdr.h and wlan_compat.h), one main C file (prism2.c) and two wrapper
C files (prism2_pci.c and prism2_plx.c).  The header files were lifted
straight from the Linux kernel source without modifications, in order to
make it easier to upgrade them, so that's a simple job.  In prism2.c,
there are very few nontrivial routines:
  hfa384x_docmd_wait
  hfa384x_prepare_bap
  hfa384x_copy_from_bap
  hfa384x_copy_to_bap
  hfa384x_cmd_access
  hfa384x_drvr_getconfig
  hfa384x_drvr_setconfig
  hfa384x_wait_for_event
  prism2_poll
  prism2_transmit
most of which have direct equivalents in the Linux kernel source, so it
should be fairly straightforward to see which changes should be applied to
which routines.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

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

> On 18 Sep 2002, Eric W. Biederman wrote:
> > > > I just downloaded and compiled the latest Etherboot 5.1 cvs and tried
> > > > using the prism2 drivers on it. It comes up but it doesnt seem to
> > > > detect the card. Anyone else using the prism2 drivers on 5.1 cvs?
> > > Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
> > > is an E820-related problem that I've fixed once before already, but I just
> > > don't have time to hack on Etherboot at the moment.  However, if someone
> > > can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
> > > start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> > > regain some spare time. :-)
> > BIOS Bug.  Almost certainly.  All we do is return to the BIOS.
> > Unless there is something we don't reset to it's original state?  Some
> > bits of test code (Returning ealier to the BIOS) could identify if
> > whatever it is has changed yet, so it should be trackable.
> 
> Thanks; that's confirmed what I thought would be the best debug strategy.
> It's certainly a BIOS or hardware-specific problem; it will happen on a
> batch of machines of the same hardware type.  We tried looking at Windows
> 98's idea of a diagnostic boot log, but gave up when we found it contained
> only six (unhelpful) lines.

I thought of one other possibility to try.  We might be stomping BIOS tables
if etherboot is loading to high.  Setting RELOCADDR lower might be worth
a shot.

Which vesion of etherboot does the crawl show up with?

Eric

[Etherboot-developers] Prism2 driver update?

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

What was the prism2 driver derrived from? The linux kernel? If so, what version was it extracted from? I read that the linux driver has been updated because it had some allocation problems. Make we should take the latest linux driver and get that one working in etherboot. Just in case the older driver had problems [which even I had with larger then 20mb images].

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

On Wed, 18 Sep 2002, Anselm Martin Hoffmeister wrote:
> BTW: Try setting your BIOS to "PNPOS=No" for that  board-not-found problem.
> That seems to have helped several people with similar problems on other NICs.

Thanks, but this is a hardware setup that was known to work with Etherboot
5.1 a couple of weeks ago, so something in the code has broken since then.
I will get around to tracking it down at some point.

Michael

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

Anselm Martin Hoffmeister <ans...@gm...> writes:

> > Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
> > is an E820-related problem that I've fixed once before already, but I just
> > don't have time to hack on Etherboot at the moment.  However, if someone
> > can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
> > start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> > regain some spare time. :-)
> 
> Could it be that the Etherboot code doesn't safely deactivate your hardware?
> (But it shouldn't have initialized it if asking for "local boot", does it?)
> However, you could have a look into the code.

Only if it times out, and retries the boot process.

> BTW: Try setting your BIOS to "PNPOS=No" for that  board-not-found problem.
> That seems to have helped several people with similar problems on other NICs.

Click.   PNPOS=Yes implies the OS can assign resources to the device.
And we verify that some Resource is assigned to the pci device.

The BIOS should assign all resouces to boot devices but it is quite
possible to overlook a NIC as a boot device.

Eric

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

On 18 Sep 2002, Eric W. Biederman wrote:
> > > I just downloaded and compiled the latest Etherboot 5.1 cvs and tried
> > > using the prism2 drivers on it. It comes up but it doesnt seem to
> > > detect the card. Anyone else using the prism2 drivers on 5.1 cvs?
> > Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
> > is an E820-related problem that I've fixed once before already, but I just
> > don't have time to hack on Etherboot at the moment.  However, if someone
> > can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
> > start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> > regain some spare time. :-)
> BIOS Bug.  Almost certainly.  All we do is return to the BIOS.
> Unless there is something we don't reset to it's original state?  Some
> bits of test code (Returning ealier to the BIOS) could identify if
> whatever it is has changed yet, so it should be trackable.

Thanks; that's confirmed what I thought would be the best debug strategy.
It's certainly a BIOS or hardware-specific problem; it will happen on a
batch of machines of the same hardware type.  We tried looking at Windows
98's idea of a diagnostic boot log, but gave up when we found it contained
only six (unhelpful) lines.

I'm *really* looking forward to this debug-via-floppy-boot session :-(

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

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

> On Wed, 18 Sep 2002, Boris wrote:
> > I just downloaded and compiled the latest Etherboot 5.1 cvs and tried
> > using the prism2 drivers on it. It comes up but it doesnt seem to
> > detect the card. Anyone else using the prism2 drivers on 5.1 cvs?
> 
> Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
> is an E820-related problem that I've fixed once before already, but I just
> don't have time to hack on Etherboot at the moment.  However, if someone
> can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
> start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> regain some spare time. :-)

BIOS Bug.  Almost certainly.  All we do is return to the BIOS.
Unless there is something we don't reset to it's original state?  Some
bits of test code (Returning ealier to the BIOS) could identify if 
whatever it is has changed yet, so it should be trackable.

Eric

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

[Anselm M. H. <ans...@gm...>]

> Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
> is an E820-related problem that I've fixed once before already, but I just
> don't have time to hack on Etherboot at the moment.  However, if someone
> can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
> start up if booted via Etherboot's "Boot (L)ocal" option, then I might
> regain some spare time. :-)

Could it be that the Etherboot code doesn't safely deactivate your hardware?
(But it shouldn't have initialized it if asking for "local boot", does it?)
However, you could have a look into the code.

BTW: Try setting your BIOS to "PNPOS=No" for that  board-not-found problem.
That seems to have helped several people with similar problems on other NICs.

HTH Anselm

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

On Wed, 18 Sep 2002, Boris wrote:
> I just downloaded and compiled the latest Etherboot 5.1 cvs and tried
> using the prism2 drivers on it. It comes up but it doesnt seem to
> detect the card. Anyone else using the prism2 drivers on 5.1 cvs?

Last time I tried 5.1, it failed to even detect my BIOS.  I'm think this
is an E820-related problem that I've fixed once before already, but I just
don't have time to hack on Etherboot at the moment.  However, if someone
can tell me why, on some machines, Windows 98 takes forever (45 mins+) to
start up if booted via Etherboot's "Boot (L)ocal" option, then I might
regain some spare time. :-)

Michael

[Etherboot-developers] Prism2 drivers *dont* work in latest Etherboot 5.1 cvs

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

I just downloaded and compiled the latest Etherboot 5.1 cvs and tried using the prism2 drivers on it. It comes up but it doesnt seem to detect the card. Anyone else using the prism2 drivers on 5.1 cvs?

[Etherboot-developers] (no subject)

[deng z. <dz...@ho...>]

Could mknbi-dos to create a hard disk that bigger than 102400k bytes? 

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: 
http://messenger.microsoft.com/cn/

[Etherboot-developers] (no subject)

[deng z. <dz...@ho...>]

How can I create a boot image that create a RAM hard disk bigger than 
10240K?

_________________________________________________________________
免费下载 MSN Explorer: http://explorer.msn.com/lccn/

Re: [Etherboot-developers] RE: [Etherboot-users] Fancy menu system

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

"Donnelly, John" <Joh...@hp...> writes:

> I boot using serial consoles 
> so I like it the way it is ;-) ...

This is the external boot menu, so it doesn't get compiled into the etherboot
romimage.  This allows us to have options.

But note in the development version of etherboot all menus have been removed
from the internals of etherboot so having an external menu that suites  
your needs is important.

Eric

[Etherboot-developers] RE: [Etherboot-users] Fancy menu system

[Donnelly, J. <Joh...@hp...>]

I boot using serial consoles=20
so I like it the way it is ;-) ...

///

-----Original Message-----
From: Anselm Martin Hoffmeister [mailto:eth...@ho...]
Sent: Tuesday, September 10, 2002 2:21 AM
To: eth...@li...
Cc: eth...@li...
Subject: [Etherboot-users] Fancy menu system


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



-------------------------------------------------------
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=3Dsourceforge1&refcode1=3Dvs3390
_______________________________________________
Etherboot-users mailing list
Eth...@li...
https://lists.sourceforge.net/lists/listinfo/etherboot-users

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

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

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

Yes, there is an unfortunate hidden assumption that it's called from
Etherboot running somewhere in 0x9xxxx.

>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 :)

Go for it, I'm swamped this week. It would be good if the internal stack
were somewhere safe for 5.0 as well so that nothing will break.

Re: [Etherboot-developers] About multicast

[Anselm M. H. <ans...@gm...>]

> But I can not see any code that about multicast in NIC driver code?
 
It's not as visible :-)
Usually it is just one byte or so sent to the network device telling it that
it should not only accept unicast packets to its own address and broadcast,
but also multicast packets. There are not many drivers up to now AFAIK, but
it's no great job to implement this single output. The rest is handled inside
etherboot which examines all incoming (and accepted) packets and sees they
are multicast if their address is something like 225.0.0.1 or so.
Really, for the nic specific stuff, there's not much to see.

If you don't get it yourself for your board, tell me which model (etherboot
driver, linux driver will probably do) you have and I can have a look at it.

HTH

Anselm

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net