etherboot-developers — Discussion of developer issues

[Etherboot-developers] Compiling liloprefix.s failed (EB 5.1.7 from CVS) - relocate?

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

Hello ,

etherboot 5.1.7 (as taken from CVS this evening) does NOT compile
for me (reference: download from CVS at 20:45 GMT). That's what my
linux tells me (gcc version 2.95.3, kernel SuSE 2.4.18 [sorry])

anselm-31:/home/anselm/etherboot/etherboot-5.1/src # make bin32/rtl8139.lilo
as  -o bin/liloprefix.o bin/liloprefix.s
ld -Ttext 0x10000 --oformat binary       -o bin/liloprefix.bin bin/liloprefix.o
ld: warning: cannot find entry symbol _start; defaulting to 00010000
bin/liloprefix.o: In function `bootsector':
bin/liloprefix.o(.text+0x1): relocation truncated to fit: R_386_16 text
bin/liloprefix.o: In function `go':
bin/liloprefix.o(.text+0x19): relocation truncated to fit: R_386_16 text
make: *** [bin/liloprefix.bin] Error 1
rm bin/liloprefix.o
anselm-31:/home/anselm/etherboot/etherboot-5.1/src #
  
Does that mean "relocation =^= work in progress"?

BTW Found this while entering changes into rtl8139.c, for multicast
support with that nic (Hi Deng Zhiguo :-) but wanted to test-run
before commiting to CVS...

-- 
Best regards,
 Anselm 

[Etherboot-developers] 5.1.2rc5 -DRELOCATE test

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

Ok, decided to bite the bullet and try -DRELOCATE with the 3c509.

Created a 5.1.2 3c509.lzrom and turned it into a NBI with mknbi-rom.

5.0.7 loaded the menu. I selected the 5.1.2 ROM NBI and it loaded,
executed (displayed the relocation info) and loaded the menu again. This
time I chose to load itself again. It loaded but flew off nowhere after
...done. Ok, try to load a FreeDOS image. Again loaded fine but went
nowhere after ...done. Try to load a Linux NBI. Loaded fine and after
printing ...done, ran first32. Got as far as printing the banner and the
ramdisk addresses, then nothing.

I think what's happening is that the relocation works fine but the
address of 0x20000 is clobbering the body of Linux and FreeDOS. Menu and
first32 live at 0x10000 and 0x92??? respectively and don't get
clobbered.

-DCONFIG_PCI doesn't work as you have explained.

How do I make a ROM image with the nrv2b images? I'd like to test that
next.

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

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

> > For absolute references I just prefer pointer arithematic.  Segment
> > loads are expensive.  But you very rarely if ever need absolute references.
> 
> Segment loads are expensive, references are cheap.  If you leave them
> loaded then your only penalty is the segment prefix.  And since the
> occurrence of absolute memory references is low, there is little
> reason not to use segments except that most people aren't comfortable
> with them.  %^)

Two other reasons.
It is awkward to do from C.
And you cannot use segments when talking to devices virt_to_bus/bus_to_virt...

My goal when I changed etherboot was to use a C api that is portable.
So I did not even consider special purpose things like a copy_from_absolute.

Eric

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

> For absolute references I just prefer pointer arithematic.  Segment
> loads are expensive.  But you very rarely if ever need absolute references.

Segment loads are expensive, references are cheap.  If you leave them
loaded then your only penalty is the segment prefix.  And since the
occurrence of absolute memory references is low, there is little
reason not to use segments except that most people aren't comfortable
with them.  %^)

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

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

> On Sat, Sep 21, 2002 at 01:01:40PM -0600, Eric W Biederman wrote:
> > There are two ways to do PIC on x86.  And I have played with and implemented
> > both of them.
> > 
> > 1) Use -fPIC when you compile and actually change all of the absolute
> references
> 
> >    in your code to know about the current load address.  See memtest86-3.0
> >    for an implemenation.  The more relocations the linker can resolve
> >    at link time the better.
> > 
> 
> I was daunted by the need to do the fixups.  I'm familiar with the
> MIPS and 68K where PIC code is much simpler.

In the general case fixups are needed.  But yes x86 needs fixups more
than some.  The fixup code is fairly trivial (Once you strip it down
to the essentials).  For doing fixups x86 is one of the friendliest
architectures.

 
> > 2) Modify the code to use a protected mode code and data segment with base !=
> 0.
> 
> > This is what I have done with etherboot.  If you need to refer to an absolute
> 
> >    memory location you need a virt_to_phys/phys_to_virt set of calls.  This
> >    technique is still compatible with the existing
> >    real_to_prot/prot_to_real stubs in mknbi.  Except for the expense
> >    of modifying the code this method is not to bad.
> 
> Are you doing this in the version of etherboot you are debugging?

Yes in the development version 5.1.2+

> This occurred to me.  In fact, I thought that it might be simplest to
> use other segment registers to make it something built-in at compile
> time.  No performance penalty except for the extra segment prefix and
> a possible segment register load.  It could be macro-ized for some
> cases, though I suspect it would be necessary to perform a copy in
> many cases.

For absolute references I just prefer pointer arithematic.  Segment
loads are expensive.  But you very rarely if ever need absolute references.

Eric

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

On Sat, Sep 21, 2002 at 01:01:40PM -0600, Eric W Biederman wrote:
> There are two ways to do PIC on x86.  And I have played with and implemented
> both of them.
> 
> 1) Use -fPIC when you compile and actually change all of the absolute references
>    in your code to know about the current load address.  See memtest86-3.0
>    for an implemenation.  The more relocations the linker can resolve
>    at link time the better.
> 

I was daunted by the need to do the fixups.  I'm familiar with the
MIPS and 68K where PIC code is much simpler.

> 2) Modify the code to use a protected mode code and data segment with base != 0.
>    This is what I have done with etherboot.  If you need to refer to an absolute
>    memory location you need a virt_to_phys/phys_to_virt set of calls.  This
>    technique is still compatible with the existing
>    real_to_prot/prot_to_real stubs in mknbi.  Except for the expense
>    of modifying the code this method is not to bad.

Are you doing this in the version of etherboot you are debugging?

This occurred to me.  In fact, I thought that it might be simplest to
use other segment registers to make it something built-in at compile
time.  No performance penalty except for the extra segment prefix and
a possible segment register load.  It could be macro-ized for some
cases, though I suspect it would be necessary to perform a copy in
many cases.

Cheers.

Re: [Etherboot-developers] etherboot-5.1.2rc5 available

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

ke...@us... writes:

> It's at www.etherboot.org/etherboot-5.1.2rc5.tar.bz2
> 
> It's got some fixes by Eric and Michael. You should use mknbi-1.2-10rc1
> (just announced) with it if you are using a PC BIOS.
> 
> Eric, where are we with the debugging? Is it ready for people to try to
> see if it will work with various NICs?

With the new mknbi we have shown that the standard code paths ELF && NBI
are working.  So the remaining problems will be primarily NIC problems.

There are two generic code paths that still needs some work.
-DCAN_BOOT_DISK
-UCONFIG_PCI_DIRECT

For disk access the old functionality is not quite yet provided by the new
code.

The pci code that makes BIOS calls make some assumptions about segment
registers, that I haven't had time to go back and fix.

Eric

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

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

> On Sat, Sep 21, 2002 at 09:36:15AM -0700, Marc Singer wrote:
> > On Sun, Sep 22, 2002 at 02:07:59AM +1000, Ken Yap wrote:
> > > >I was wondering about that.  I was also wondering if there would be
> > > >any utility in changing mknbi to PIC, position independent code.  It
> > > >may be overkill since are likely to know where things are in memory.
> > > 
> > > If you know a way to generate PIC with gcc that doesn't have a large
> > > overhead in code size or relocation tables, or require a bulky runtime
> > > relocating loader, let us know.
> > 
> > Well...it make the mknbi loader at least 6732 bytes long.  I faked one
> > of the symbols, so there may be more data.  Is it possible to give the
> > loader 8K instead of 6K?  I haven't looked at etherboot, but I'd guess
> > it has a similar bloat of about...good grief...a 90% increase.
> > 
> > So we know that it is expensive.  Are we really that tight on memory?
> > 
> 
> Nevermind.  I found something that describes what needs to be done.
> It's way to much work for something of nominal value.

There are two ways to do PIC on x86.  And I have played with and implemented
both of them.

1) Use -fPIC when you compile and actually change all of the absolute references
   in your code to know about the current load address.  See memtest86-3.0
   for an implemenation.  The more relocations the linker can resolve
   at link time the better.

2) Modify the code to use a protected mode code and data segment with base != 0.
   This is what I have done with etherboot.  If you need to refer to an absolute
   memory location you need a virt_to_phys/phys_to_virt set of calls.  This
   technique is still compatible with the existing
   real_to_prot/prot_to_real stubs in mknbi.  Except for the expense
   of modifying the code this method is not to bad.

Eric

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

On Sat, Sep 21, 2002 at 09:36:15AM -0700, Marc Singer wrote:
> On Sun, Sep 22, 2002 at 02:07:59AM +1000, Ken Yap wrote:
> > >I was wondering about that.  I was also wondering if there would be
> > >any utility in changing mknbi to PIC, position independent code.  It
> > >may be overkill since are likely to know where things are in memory.
> > 
> > If you know a way to generate PIC with gcc that doesn't have a large
> > overhead in code size or relocation tables, or require a bulky runtime
> > relocating loader, let us know.
> 
> Well...it make the mknbi loader at least 6732 bytes long.  I faked one
> of the symbols, so there may be more data.  Is it possible to give the
> loader 8K instead of 6K?  I haven't looked at etherboot, but I'd guess
> it has a similar bloat of about...good grief...a 90% increase.
> 
> So we know that it is expensive.  Are we really that tight on memory?
> 

Nevermind.  I found something that describes what needs to be done.
It's way to much work for something of nominal value.

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

On Sun, Sep 22, 2002 at 02:07:59AM +1000, Ken Yap wrote:
> >I was wondering about that.  I was also wondering if there would be
> >any utility in changing mknbi to PIC, position independent code.  It
> >may be overkill since are likely to know where things are in memory.
> 
> If you know a way to generate PIC with gcc that doesn't have a large
> overhead in code size or relocation tables, or require a bulky runtime
> relocating loader, let us know.

Well...it make the mknbi loader at least 6732 bytes long.  I faked one
of the symbols, so there may be more data.  Is it possible to give the
loader 8K instead of 6K?  I haven't looked at etherboot, but I'd guess
it has a similar bloat of about...good grief...a 90% increase.

So we know that it is expensive.  Are we really that tight on memory?

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

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

>I'm booting an AMD SC520 CPU with an 82559rc ethernet controller.
>There's a DOC on board which is the reason for all of this nonsense
>that I want to rewrite using a simple boot-floppy setup.
>
>Is this an interesting scenario to test?  I'm game.  I've already been
>rebuilding etherboot and mknbi, so there's little challenge there.

That URL again: www.etherboot.org/etherboot-5.1.2rc5.tar.bz2
Documentation? UTSL!

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

On Sun, Sep 22, 2002 at 02:04:10AM +1000, Ken Yap wrote:
> >> Those BIOS stubs with inline mode switching go all the way back to the
> >> roots of Etherboot in BSD Netboot. Evidently it was the easy thing to do
> >> then. But Etherboot has outgrown that straitjacket now, thanks to Eric.
> >
> >Is this new code working?  Or, should I stick with a patched mknbi?
> 
> Which new code? Etherboot 5.1.2rc? It's in the bug hunt stage. We
> welcome testers. Depending on what you are trying to do, and your NIC,
> you may be ecstatic or lose all your hair.

I'm booting an AMD SC520 CPU with an 82559rc ethernet controller.
There's a DOC on board which is the reason for all of this nonsense
that I want to rewrite using a simple boot-floppy setup.

Is this an interesting scenario to test?  I'm game.  I've already been
rebuilding etherboot and mknbi, so there's little challenge there.

BTW, I just tried mknbi-1.2-10rc1.  It's all good. 

Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

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

>I was wondering about that.  I was also wondering if there would be
>any utility in changing mknbi to PIC, position independent code.  It
>may be overkill since are likely to know where things are in memory.

If you know a way to generate PIC with gcc that doesn't have a large
overhead in code size or relocation tables, or require a bulky runtime
relocating loader, let us know.

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

>> Those BIOS stubs with inline mode switching go all the way back to the
>> roots of Etherboot in BSD Netboot. Evidently it was the easy thing to do
>> then. But Etherboot has outgrown that straitjacket now, thanks to Eric.
>
>Is this new code working?  Or, should I stick with a patched mknbi?

Which new code? Etherboot 5.1.2rc? It's in the bug hunt stage. We
welcome testers. Depending on what you are trying to do, and your NIC,
you may be ecstatic or lose all your hair.

[Etherboot-developers] Re: [Etherboot-users] Mknbi is the misbehaving when reloc'd

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

On Sat, Sep 21, 2002 at 09:30:41PM +1000, Ken Yap wrote:
> Let's get our terminology synced. Firstly I am only talking about Linux
> images only, not any of the other images that mknbi builds, and I am
> only talking about modifications to mknbi, not Etherboot.
> 
> FIRST16		Supported by Etherboot 4.x and 5.0. Deprecated as
> 		FIRST32* is a superset.
> FIRST32RM	Supported by Etherboot 4.x and 5.0. What you get by
> 		default by using mknbi-linux. Calls first32 by going
> 		into RM, then first32 goes into PM.
> FIRST32PM	Supported by Etherboot 5.x. What you get by mknbi-linux
> 		--first32pm. No mode switch between Etherboot and mknbi.
> 		Now uses private stack and can be called by Etherboot
> 		from any address.
> ELF		Supported by Etherboot 5.x. What you get by mkelf-linux.
> 		No mode switch. Also fixed as a result of the above.
> 
> For Etherboot 5.2 the last two formats will be preferred.
> 
> What I propose to do in mknbi-1.4 is remove support for FIRST16, and
> make FIRST32PM the default for mknbi-linux. To get FIRST32RM for old
> Etherboot ROMs you would have to explicitly use --first32rm. mkelf-linux
> will work as usual.

I was wondering about that.  I was also wondering if there would be
any utility in changing mknbi to PIC, position independent code.  It
may be overkill since are likely to know where things are in memory.

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

On Sun, Sep 22, 2002 at 01:38:25AM +1000, Ken Yap wrote:
> >I don't think you understand what I was trying to do.  I figured it
> >was better to make a special real-mode stack for calling interrupts
> >than to fuss with the protected-mode stack.  This has nothing to do
> >with the way that the loaders was called--I read ifdef's just fine.
> 
> This would have been the better solution, and is in fact what Eric has
> implemented in 5.1.2+ by rewriting all the BIOS stub routines, which
> frees Etherboot to live anywhere.

Cool.

> Those BIOS stubs with inline mode switching go all the way back to the
> roots of Etherboot in BSD Netboot. Evidently it was the easy thing to do
> then. But Etherboot has outgrown that straitjacket now, thanks to Eric.

Is this new code working?  Or, should I stick with a patched mknbi?

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

>I don't think you understand what I was trying to do.  I figured it
>was better to make a special real-mode stack for calling interrupts
>than to fuss with the protected-mode stack.  This has nothing to do
>with the way that the loaders was called--I read ifdef's just fine.

This would have been the better solution, and is in fact what Eric has
implemented in 5.1.2+ by rewriting all the BIOS stub routines, which
frees Etherboot to live anywhere. However the real-mode stack still has
to be in the bottom 1MB for obvious reasons, which means that somewhere
a RM stack has to be allocated.  Given that start32/first32 is just a
small trampoline segment that has to live under 1MB anyway, it's ok to
use the less elegant approach of putting the text and the stack all
within the same 6kB segment. You maximise the use of the space by
starting the stack right at the top of the 6kB.

>Instead, it had to do with the fact that the loader was crashing when
>transitioning to real-mode to make interrupt calls.  

Which is due to the PM stack, which doubles as the RM stack, starting
off out of range of the RM code. So the solution is either to divorce
the two stacks or to ensure that the PM stack is suitable as a RM stack.

Those BIOS stubs with inline mode switching go all the way back to the
roots of Etherboot in BSD Netboot. Evidently it was the easy thing to do
then. But Etherboot has outgrown that straitjacket now, thanks to Eric.

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

On Sat, Sep 21, 2002 at 04:14:36PM +1000, Ken Yap wrote:
> >What I did was abandon the ill conceived real-mode stack and setup a
> >new protected mode stack in .bss.  It works for me.  
> 
> This shows that you don't understand what is happening. When first32
> gets called in PM, it is handed a PM stack, but it's at an unsuitable
> address. Making first32 get its own PM stack within 64kB of the text
> segment fixes the problem. This is the approach taken by menustart.S.
> 
> The RM stuff is in a different #ifdef branch and should be read
> separately.

I don't think you understand what I was trying to do.  I figured it
was better to make a special real-mode stack for calling interrupts
than to fuss with the protected-mode stack.  This has nothing to do
with the way that the loaders was called--I read ifdef's just fine.
Instead, it had to do with the fact that the loader was crashing when
transitioning to real-mode to make interrupt calls.  

As I said, it was ill conceived because I would have had to do a lot
more to make it work properly.  The prot-mode stack fix was easier and
clearly more effective.

[Etherboot-developers] More stack-ness

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

On Sat, Sep 21, 2002 at 04:08:49PM +1000, Ken Yap wrote:
> >I just posted a patch that does this.  I used a 4K stack and I copy
> >more than 3 arguments since it's easy to do so.  I also made an
> >allowance so that we could return to etherboot if necessary.
> 
> Sorry, your method is not good enough. You should not allocate a static
> area for the stack, it wastes space and if any more stuff is added to
> first32.c it will add pressure on space. Rather just point %esp to the
> top of the 6kB area allocated to first32 (RELOC+6144). That way, the
> stack only grows as much as needed. BTW, it's a 1kB stack you were
> allocating. If you had allocated 4kB, you would have run out of space
> already since the text size of first32 is already > 4kB.

First, I hope you noticed that there was an error in the way I handled
the stack if returning to etherboot.  I forgot to account for pop'ing
the return value.

Second, thanks for making a fix.  I tried this almost a year ago and
gave up because I didn't have time to look into it.  I'm glad a
solution has been implemented.

Finally, I'm not sure we are talking about the same thing.  The BSS
section is allocated after all of the code and data.  Here's the end
of the memory may for my version of the loader:

  000835a0 t vsprintf
  000837c8 T sprintf
  000837e8 T printf
  00083944 d seg
  0008395c D top_of_initrd
  00083960 d rdmode
  00083964 d emptytag.42
  00083968 A __bss_start
  00083968 A _edata
  00083980 b prot_stack_top
  00087980 b ip
  00087980 b prot_stack
  00087984 b op
  00087988 b vgamode
  0008798c b bp
  00087990 b vendortags
  00087994 b rdaddr
  000879a0 B meminfo
  00087c2c A _end

I'm not sure what you mean by putting pressure on first32 since all of
that code appears before this in the loader image.

However, when I look at this map (replacing 0x9's with 0x8's):

  Memory layout assumed by mknbi and this program

  0x07C00-0x07FFF   0.5 kB        floppy boot sector if loaded from floppy
  0x0F???-0x0FFFF     ? kB        large Etherboot data buffers (deprecated)
  0x10000-0x8FFFF 512.0 kB        kernel (from tagged image)
  0x90000-0x901FF   0.5 kB        Linux floppy boot sector (from Linux image)
  0x90200-0x921FF   8.0 kB        kernel setup (from Linux image)
  0x92200-0x923FF   0.5 kB        tagged image header ("directory")
  0x92400-0x927FF   1.0 kB        kernel parameters (generated by mknbi)
  0x92800-0x93FFF   6.0 kB        this program (generated by mknbi)
  0x94000-0x9FFFF  48.0 kB        Etherboot (top few kB may be used by BIOS)
                                  Normally Etherboot starts at 0x94000

what I see is that anything longer than 6K trounces etherboot.  Is
this what you mean?

[Etherboot-developers] etherboot-5.1.2rc5 available

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

It's at www.etherboot.org/etherboot-5.1.2rc5.tar.bz2

It's got some fixes by Eric and Michael. You should use mknbi-1.2-10rc1
(just announced) with it if you are using a PC BIOS.

Eric, where are we with the debugging? Is it ready for people to try to
see if it will work with various NICs?

[Etherboot-developers] Re: [Etherboot-users] Mknbi is the misbehaving when reloc'd

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

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

Ok, I think I have fixed start32.S/first32.c to use its own stack and
thus work properly when relocated, whether by --relocseg or 5.1.2rc3.  I
have booted tomsrtbt with 5.0.7 and also 5.1.2rc3 on a 3c509.  This fix
is only for the ELF or --first32pm images. I'm not sure I want to
support FIRST32RM much longer. See below.

The new mknbi can be found at www.etherboot.org/mknbi-1.2-10rc1.tar.bz2
Please give it a whirl.

Let's get our terminology synced. Firstly I am only talking about Linux
images only, not any of the other images that mknbi builds, and I am
only talking about modifications to mknbi, not Etherboot.

FIRST16		Supported by Etherboot 4.x and 5.0. Deprecated as
		FIRST32* is a superset.
FIRST32RM	Supported by Etherboot 4.x and 5.0. What you get by
		default by using mknbi-linux. Calls first32 by going
		into RM, then first32 goes into PM.
FIRST32PM	Supported by Etherboot 5.x. What you get by mknbi-linux
		--first32pm. No mode switch between Etherboot and mknbi.
		Now uses private stack and can be called by Etherboot
		from any address.
ELF		Supported by Etherboot 5.x. What you get by mkelf-linux.
		No mode switch. Also fixed as a result of the above.

For Etherboot 5.2 the last two formats will be preferred.

What I propose to do in mknbi-1.4 is remove support for FIRST16, and
make FIRST32PM the default for mknbi-linux. To get FIRST32RM for old
Etherboot ROMs you would have to explicitly use --first32rm. mkelf-linux
will work as usual.

Re: [Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

>What I did was abandon the ill conceived real-mode stack and setup a
>new protected mode stack in .bss.  It works for me.  

This shows that you don't understand what is happening. When first32
gets called in PM, it is handed a PM stack, but it's at an unsuitable
address. Making first32 get its own PM stack within 64kB of the text
segment fixes the problem. This is the approach taken by menustart.S.

The RM stuff is in a different #ifdef branch and should be read
separately.

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

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

>I just posted a patch that does this.  I used a 4K stack and I copy
>more than 3 arguments since it's easy to do so.  I also made an
>allowance so that we could return to etherboot if necessary.

Sorry, your method is not good enough. You should not allocate a static
area for the stack, it wastes space and if any more stuff is added to
first32.c it will add pressure on space. Rather just point %esp to the
top of the 6kB area allocated to first32 (RELOC+6144). That way, the
stack only grows as much as needed. BTW, it's a 1kB stack you were
allocating. If you had allocated 4kB, you would have run out of space
already since the text size of first32 is already > 4kB.

[Etherboot-developers] Stack patch that fixes relocseg, DiskOnChip, mkelf-linux

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

> 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 don't know if this is a problem in my scenario because I haven't
changed them from version 1.2-7.  The first thing done when start32
receives control is load a new gdt.

> I would suggest making the protected mode stack behave.  We don't
> need to touch it unless we return to etherboot.

What I did was abandon the ill conceived real-mode stack and setup a
new protected mode stack in .bss.  It works for me.  


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

--- ../mknbi-1.2.7-original/start32.S	2002-03-04 04:44:53.000000000 -0800
+++ ../mknbi-1.2.7/start32.S	2002-09-20 22:48:20.000000000 -0700
@@ -50,10 +50,26 @@
    GDT will have the wrong descriptors for the real code segments */
 	sgdt	gdtsave		/* save old GDT */
 	lgdt	gdtarg		/* load ours */
-	/* save the stack pointer and jump to the routine */
-	movl	%esp,%eax
+
+	movl	%esp,%eax	/* Save stack pointer so we can return */
 	movl	%eax,initsp
-	jmp	first
+
+	movl	$16, %ecx	/* Number of parameters to copy */
+	movl	%esp, %esi
+;	movl	$RELOC, %eax
+;	addl	$0x7ff0, %eax	/* Put stack above this loader */
+	leal	prot_stack, %eax
+	movl	%eax, %esp
+	subl	%ecx, %esp
+	movl	%esp, %edi
+	rep movsl
+	popl	%eax		/* Remove old return address */
+	call	first
+
+	movl	initsp, %eax	/* Return to sender, something's wrong */
+	movl	%eax, %esp
+	ret
+
 #else
 	.code16
 /* We need this stack adjustment because this code runs from a different
@@ -443,3 +459,8 @@
 initsp:	.word	0
 days:	.long	0
 #endif
+
+.bss
+prot_stack_top:
+	.skip	4096
+prot_stack:

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

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

On Sat, Sep 21, 2002 at 03:38:38PM +1000, Ken Yap wrote:
> >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.

I just posted a patch that does this.  I used a 4K stack and I copy
more than 3 arguments since it's easy to do so.  I also made an
allowance so that we could return to etherboot if necessary.