Thread: [Etherboot-developers] Adding real-mode stack for prot_to_real
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Marc S. <el...@bu...> - 2002-09-21 04:17:37
|
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: |
|
From: <ke...@us...> - 2002-09-21 11:30:50
|
>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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 16:00:38
|
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. |
|
From: <ke...@us...> - 2002-09-21 16:08:04
|
>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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 16:36:17
|
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 |
|
From: Marc S. <el...@bu...> - 2002-09-21 16:45:07
|
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. |
|
From: Eric W B. <ebi...@ln...> - 2002-09-21 19:01:46
|
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 |
|
From: Marc S. <el...@bu...> - 2002-09-21 20:05:42
|
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. |
|
From: Eric W B. <ebi...@ln...> - 2002-09-21 20:13:31
|
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 |
|
From: Marc S. <el...@bu...> - 2002-09-21 22:03:53
|
> 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. %^) |
|
From: Eric W B. <ebi...@ln...> - 2002-09-21 22:15:21
|
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 |
|
From: Claudio G. <cla...@fa...> - 2002-10-01 09:42:54
|
Alle Saturday 21 September 2002 13:30, Ken Yap ha scritto: > 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. Don't know if this can help, but this is my scenario: * Old System (works!) [without DiskOnChip] Etherboot 5.0.6 mknbi 1.2.6 linux kernel 2.4.18 I builded the nbi with: mknbi-linux --ip=rom --append="root=/dev/ram ramdisk=1 ramdisk_size=10240 vga=769 console=ttyS4 sb=0x220,9,1,5 init=/sbin/quickinit" --output linux.nbi bzImage RamDisk When the system boots up on the commandline I'll find the network informations provided from our DHCP server (I use this information extracting form /proc/cmdline) * New System (DOES'NT work) [with DiskOnChip] Etherboot 5.0.6 (the same as above, but builded with RELOCADDR=0x84000) mknbi 1.2.10rc1 linux kernel 2.4.18 (the same) I builded the nbi with: mknbi-linux --ip=rom --append="root=/dev/ram ramdisk=1 ramdisk_size=10240 vga=769 console=ttyS4 sb=0x220,9,1,5 init=/sbin/quickinit" --output linux.nbi --relocseg=0x8000 --first32pm= bzImage RamDisk The system boots up, but on the commandline I find "ip=255.255.255.255:255.255.255.255:::" (that is not the informations my DHCP provide!) I've tried the same nbi image on the old system (the one without DiskOnChip and with Etherboot builded with the default RELOCADDR) and obtained the very same behaviour. Do you have some idea? Thanks! Claudio -- "Only two things are infinite: the universe and human stupidity, and I'm not so sure about the Universe." Albert Einstein ---------------------------------------------------------------- // Claudio Granatiero ICQ 16725435 \\|soft PGP: 74F0 52C0 75A1 4CAA B3E8 13CE DA7A C86E 2EBA 9F75 |
|
From: Eric W B. <ebi...@ln...> - 2002-09-21 04:43:10
|
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 |
|
From: <ke...@us...> - 2002-09-21 05:38:52
|
>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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 05:58:54
|
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. |
|
From: <ke...@us...> - 2002-09-21 06:09:04
|
>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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 15:13:27
|
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?
|
|
From: Marc S. <el...@bu...> - 2002-09-21 06:03:11
|
> 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:
|
|
From: <ke...@us...> - 2002-09-21 06:14:40
|
>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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 15:18:16
|
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. |
|
From: <ke...@us...> - 2002-09-21 15:38:30
|
>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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 15:55:33
|
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? |
|
From: <ke...@us...> - 2002-09-21 16:04:14
|
>> 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. |
|
From: Marc S. <el...@bu...> - 2002-09-21 16:10:59
|
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. |
