Thread: [Etherboot-developers] Memory allocation
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-developers
|
From: Michael B. <mb...@fe...> - 2003-05-23 16:20:12
|
Memory allocation within Etherboot seems to suffer from several problems at the moment. As far as I can tell, we have the following memory ranges being used: 1. Etherboot text. This will be at RELOCADDR (=0x20000) if -DRELOCATE is not defined, otherwise somewhere towards the top of available RAM. (Will always be within an even megabyte, i.e. A20=0). 2. Etherboot protected-mode stack. I think this is within the Etherboot text, somebody please confirm/correct me on this. 3. Etherboot real-mode stack. This is always at the top of free base memory (as defined by 40:13), provided that Etherboot is the only thing allocating base memory. NB. Other code may allocate base memory by changing the counter at 40:13. We should really recalculate the real-mode stack top each time we make a _real_call, based on the current contents of 40:13. Is there any reason why we can't do this? (I'm thinking of LinuxBIOS in particular; does this use the same 40:13 counter?) 4. Etherboot heap. This gets placed in the largest contiguous block in memory. At the moment, nothing uses it. 5. Allocated base memory, from 640K down to [40:13]k. Includes the BIOS EPDA. The interaction of these five areas with prep_segment() has the following problems: a. No checks are made for (3). prep_segment will happily trash the real-mode stack and _real_call will happily walk all over an area that prep_segment has prepared. b. If heap (4) or base memory (5) is allocated after the first call to prep_segment, it's possible that it will allocate memory that prep_segment() has already checked is free and prepared. In addition, there seems to be an assortment of other mechanisms that programs may use to deal with memory allocation: BIOS PMM, Int 15,87, E820-map reading a la Etherboot etc. Currently Etherboot makes no attempt to handle or cooperate with any of these; if anything other than Etherboot is allocating memory then there's a high chance of a collision. MEMDISK contains routines that, AFAICT, allow us to fake the E820 map, so that we could mark as reserved any regions that we have allocated. Questions: 1. Would this be sufficient to prevent other entities treading on Etherboot? (I'm guessing yes). 2. Do we have to do all our memory allocation and E820 map modification *before* we allow any other entity that might allocate memory to execute? (I'm guessing yes). 3. What if another entity is also faking the E820 map? (I'm guessing that this is not a problem as long as the other entity also does (2)). 4. How do we avoid treading on other entities? (In particular: the Intel UNDI driver seems to install something just above the 1MB mark. prep_segment() then obliterates this, because it can't tell that the region is in use). 5. Would it take into account the BIOS PMM, if it exists? 6. How do we tidy up before passing control to the loaded program? We don't always want to free everything; if it's a menu program then we need to keep Etherboot "hidden". Comments, suggestions, ideas welcome. This is currently the only thing stopping the UNDI driver from working. It needs to be sorted out before Etherboot can reliably co-exist with other boot ROMs (e.g. PXE ROMs are likely to install things into extended memory) and it's a prerequisite of PXE-on-Etherboot. Michael |
|
From: <ebi...@ln...> - 2003-05-27 20:43:11
|
Michael Brown <mb...@fe...> writes: > Memory allocation within Etherboot seems to suffer from several problems > at the moment. As far as I can tell, we have the following memory ranges > being used: > > 1. Etherboot text. This will be at RELOCADDR (=0x20000) if -DRELOCATE is > not defined, otherwise somewhere towards the top of available RAM. > (Will always be within an even megabyte, i.e. A20=0). > > 2. Etherboot protected-mode stack. I think this is within the Etherboot > text, somebody please confirm/correct me on this. Actually a better way of looking at Etherboot text and the stack is: Etherboot text+data+bss They are all of a predetermined fixed size, and the protected mode stack is allocated in the bss. The bss is important because it takes no space in the etherboot image but it is allocated statically at build time. static char buf[255]; or any other static variable without an initializer will be allocated in the bss. > 3. Etherboot real-mode stack. This is always at the top of free base > memory (as defined by 40:13), provided that Etherboot is the only thing > allocating base memory. > > NB. Other code may allocate base memory by changing the counter at > 40:13. We should really recalculate the real-mode stack top each time > we make a _real_call, based on the current contents of 40:13. Is there > any reason why we can't do this? (I'm thinking of LinuxBIOS in > particular; does this use the same 40:13 counter?) LinuxBIOS does not use 40:13 at the present time. In fact the only interface to the outside world (Besides the simple LinuxBIOS table) visible when running etherboot is etherboot itself. Care needs to be take because I'm not certain 40:13 is reliable. I know there are several cases that do BIOS calls to get this information. And the linux kernel explicitly does not read it with a comment about it being unreliable. > 4. Etherboot heap. This gets placed in the largest contiguous block in > memory. At the moment, nothing uses it. The multicast protocol drivers use it. For most things static allocation is sufficient and when static allocation works it is safer. Since packets can come in a random order during multicast reception we may not have enough information unless we allocate a static buffer for the file we are downloading. > 5. Allocated base memory, from 640K down to [40:13]k. Includes the BIOS > EPDA. > > The interaction of these five areas with prep_segment() has the following > problems: > > a. No checks are made for (3). prep_segment will happily trash the > real-mode stack and _real_call will happily walk all over an area that > prep_segment has prepared. Correct. That was an after thought. > b. If heap (4) or base memory (5) is allocated after the first call to > prep_segment, it's possible that it will allocate memory that > prep_segment() has already checked is free and prepared. Correct. So far all of the heap allocation is just for the multicast case when we cannot incrementally load the image. So it all happens during processing of the first packet. > In addition, there seems to be an assortment of other mechanisms that > programs may use to deal with memory allocation: BIOS PMM, Int 15,87, > E820-map reading a la Etherboot etc. Currently Etherboot makes no attempt > to handle or cooperate with any of these; if anything other than Etherboot > is allocating memory then there's a high chance of a collision. > > MEMDISK contains routines that, AFAICT, allow us to fake the E820 map, so > that we could mark as reserved any regions that we have allocated. > Questions: > > 1. Would this be sufficient to prevent other entities treading on > Etherboot? (I'm guessing yes). Likely. > 2. Do we have to do all our memory allocation and E820 map modification > *before* we allow any other entity that might allocate memory to > execute? (I'm guessing yes). That would be tricky. The current assumption is that etherboot owns the machine. We may need to rescan the map. Given that in the worst case we don't know where a packet needs to go into memory until we read it. I would say the general etherboot case is that it needs to do most of the allocation first. > 3. What if another entity is also faking the E820 map? (I'm guessing that > this is not a problem as long as the other entity also does (2)). > > 4. How do we avoid treading on other entities? (In particular: the > Intel UNDI driver seems to install something just above the 1MB mark. > prep_segment() then obliterates this, because it can't tell that the > region is in use). Very good question. It looks like we need to rescan things (at least in the UNDI driver case. > 5. Would it take into account the BIOS PMM, if it exists? Possibly. I don't recall what that is... If it is BIOS services for allocating memory above 1MB then that would be a good idea. > 6. How do we tidy up before passing control to the loaded program? We > don't always want to free everything; if it's a menu program then we > need to keep Etherboot "hidden". This is the biggest reason I dislike callbacks, there is a lot of weird cooperation needed to get everything working. > Comments, suggestions, ideas welcome. This is currently the only thing > stopping the UNDI driver from working. It needs to be sorted out before > Etherboot can reliably co-exist with other boot ROMs (e.g. PXE ROMs are > likely to install things into extended memory) and it's a prerequisite of > PXE-on-Etherboot. I hope this helps. Eric |
|
From: Michael B. <mb...@fe...> - 2003-05-28 09:13:59
|
> > 2. Etherboot protected-mode stack. I think this is within the Etherboot > > text, somebody please confirm/correct me on this. > Actually a better way of looking at Etherboot text and the stack is: > Etherboot text+data+bss They are all of a predetermined fixed size, > and the protected mode stack is allocated in the bss. The bss is important > because it takes no space in the etherboot image but it is allocated > statically at build time. > static char buf[255]; or any other static variable without an initializer > will be allocated in the bss. Thanks, that's handy to know. > > 3. Etherboot real-mode stack. This is always at the top of free base > > memory (as defined by 40:13), provided that Etherboot is the only thing > > allocating base memory. > > NB. Other code may allocate base memory by changing the counter at > > 40:13. We should really recalculate the real-mode stack top each time > > we make a _real_call, based on the current contents of 40:13. Is there > > any reason why we can't do this? (I'm thinking of LinuxBIOS in > > particular; does this use the same 40:13 counter?) > LinuxBIOS does not use 40:13 at the present time. In fact the only > interface to the outside world (Besides the simple LinuxBIOS table) > visible when running etherboot is etherboot itself. > Care needs to be take because I'm not certain 40:13 is reliable. I > know there are several cases that do BIOS calls to get this > information. And the linux kernel explicitly does not read it with > a comment about it being unreliable. The PXE spec actually instructs you to use 40:13, so I'm comfortable doing it in the case of the Etherboot UNDI driver; if 40:13 doesn't work then the PXE driver would probably fail anyway. 40:13 is used only by routines in basemem.c. However, I did modify pcbios/memsizes.c to make a call to adjust_real_mode_stack() in basemem.c in order to centralise the management of the real mode stack location. If you think 40:13 might not be reliable then you may want to revert this change. > > 5. Allocated base memory, from 640K down to [40:13]k. Includes the BIOS > > EPDA. > > The interaction of these five areas with prep_segment() has the following > > problems: > > a. No checks are made for (3). prep_segment will happily trash the > > real-mode stack and _real_call will happily walk all over an area that > > prep_segment has prepared. > Correct. That was an after thought. What is the size of the real-mode stack, and shall we add it in as another check in prep_segment? > > 4. How do we avoid treading on other entities? (In particular: the > > Intel UNDI driver seems to install something just above the 1MB mark. > > prep_segment() then obliterates this, because it can't tell that the > > region is in use). > Very good question. It looks like we need to rescan things (at least > in the UNDI driver case. UNDI driver was a false alert; it turned out to be the status of the A20 line. I thought I must be treading on something UNDI-related when I loaded a segment in the [1MB,2MB) range, but actually I was simply vapourising the contents of base memory thanks to A20. Have you ever tried doing memset ( phys_to_virt(0), '!', 1<<20 ); ? :-) > > 5. Would it take into account the BIOS PMM, if it exists? > Possibly. I don't recall what that is... > If it is BIOS services for allocating memory above 1MB then that would > be a good idea. I've looked into PMM a little more and we can, I think, ignore it; it is to do with allocating memory above 1MB but only during POST. As soon as Int 19 happens (i.e. before we get control), any memory allocated via PMM is freed and PMM ceases to be available. Michael |
|
From: <ebi...@ln...> - 2003-05-28 15:24:23
|
Michael Brown <mb...@fe...> writes: > > > 3. Etherboot real-mode stack. This is always at the top of free base > > > memory (as defined by 40:13), provided that Etherboot is the only thing > > > allocating base memory. > > > NB. Other code may allocate base memory by changing the counter at > > > 40:13. We should really recalculate the real-mode stack top each time > > > we make a _real_call, based on the current contents of 40:13. Is there > > > any reason why we can't do this? (I'm thinking of LinuxBIOS in > > > particular; does this use the same 40:13 counter?) > > LinuxBIOS does not use 40:13 at the present time. In fact the only > > interface to the outside world (Besides the simple LinuxBIOS table) > > visible when running etherboot is etherboot itself. > > Care needs to be take because I'm not certain 40:13 is reliable. I > > know there are several cases that do BIOS calls to get this > > information. And the linux kernel explicitly does not read it with > > a comment about it being unreliable. > > The PXE spec actually instructs you to use 40:13, so I'm comfortable doing > it in the case of the Etherboot UNDI driver; if 40:13 doesn't work then > the PXE driver would probably fail anyway. > > 40:13 is used only by routines in basemem.c. However, I did modify > pcbios/memsizes.c to make a call to adjust_real_mode_stack() in basemem.c > in order to centralise the management of the real mode stack location. If > you think 40:13 might not be reliable then you may want to revert this > change. It is quite possible there is a strong difference between what is reliable by the time the OS starts, and what is reliable beforehand. Unless we have reason to suspect I would suggest leaving it in. > > > 5. Allocated base memory, from 640K down to [40:13]k. Includes the BIOS > > > EPDA. > > > The interaction of these five areas with prep_segment() has the following > > > problems: > > > a. No checks are made for (3). prep_segment will happily trash the > > > real-mode stack and _real_call will happily walk all over an area that > > > prep_segment has prepared. > > Correct. That was an after thought. > > What is the size of the real-mode stack, and shall we add it in as another > check in prep_segment? At most 64K. As for a check that is a good question. Ideally we should be able to avoid the areas claimed by prep_segment. But that would require remember things. > > > 4. How do we avoid treading on other entities? (In particular: the > > > Intel UNDI driver seems to install something just above the 1MB mark. > > > prep_segment() then obliterates this, because it can't tell that the > > > region is in use). > > Very good question. It looks like we need to rescan things (at least > > in the UNDI driver case. > > UNDI driver was a false alert; it turned out to be the status of the A20 > line. I thought I must be treading on something UNDI-related when I > loaded a segment in the [1MB,2MB) range, but actually I was simply > vapourising the contents of base memory thanks to A20. Have you ever > tried doing memset ( phys_to_virt(0), '!', 1<<20 ); ? :-) How did you fail to enable the a20 line? > > > 5. Would it take into account the BIOS PMM, if it exists? > > Possibly. I don't recall what that is... > > If it is BIOS services for allocating memory above 1MB then that would > > be a good idea. > > I've looked into PMM a little more and we can, I think, ignore it; it is > to do with allocating memory above 1MB but only during POST. As soon as > Int 19 happens (i.e. before we get control), any memory allocated via PMM > is freed and PMM ceases to be available. O.k. One issue on my wishlist is to have a stub that loads etherboot into high memory (>1MB) from the rom initialization code, and then just leaves a very small stub in real mode. Given that I have seen several BIOS's start acting erratically because of their real mode storage for options roms was used up. This could make etherboot more reliable. Eric |
|
From: Michael B. <mb...@fe...> - 2003-05-28 15:43:03
|
> > > > 4. How do we avoid treading on other entities? (In particular: the > > > > Intel UNDI driver seems to install something just above the 1MB mark. > > > > prep_segment() then obliterates this, because it can't tell that the > > > > region is in use). > > > Very good question. It looks like we need to rescan things (at least > > > in the UNDI driver case. > > UNDI driver was a false alert; it turned out to be the status of the A20 > > line. I thought I must be treading on something UNDI-related when I > > loaded a segment in the [1MB,2MB) range, but actually I was simply > > vapourising the contents of base memory thanks to A20. Have you ever > > tried doing memset ( phys_to_virt(0), '!', 1<<20 ); ? :-) > How did you fail to enable the a20 line? I didn't. The UNDI driver (i.e. the one in the PXE ROM) plays about with it whenever it gets bored and feels like causing some extra debugging work. I have a two-stage solution to this problem: 1. Ensure Etherboot text is always within an even megabyte, so that _real_call returns successfully and we make it all the way back to the C code even if something nasty happens to A20. (Hey, half your memory's just disappeared? No problem! :) 2. Call gateA20_set() immediately after doing any UNDI API call. Thanks to (1), I can do this cleanly in C instead of assembler. > > I've looked into PMM a little more and we can, I think, ignore it; it is > > to do with allocating memory above 1MB but only during POST. As soon as > > Int 19 happens (i.e. before we get control), any memory allocated via PMM > > is freed and PMM ceases to be available. > O.k. One issue on my wishlist is to have a stub that loads etherboot > into high memory (>1MB) from the rom initialization code, and then just > leaves a very small stub in real mode. Given that I have seen several > BIOS's start acting erratically because of their real mode storage for > options roms was used up. This could make etherboot more reliable. Could be interesting; PMM is potentially in charge of high memory at the time the initialisation code is called (assuming the BIOS supports PMM), but anything it allocates is lost before the system starts booting. I'm not sure how you'd work around that problem. [ Some working real mode stub code would, however, come in handy for the case of PXE-on-Etherboot; we would need to provide a real-mode entry point. ] Michael |
|
From: <ebi...@ln...> - 2003-05-28 19:17:57
|
Michael Brown <mb...@fe...> writes:
> > > > > 4. How do we avoid treading on other entities? (In particular: the
> > > > > Intel UNDI driver seems to install something just above the 1MB mark.
>
> > > > > prep_segment() then obliterates this, because it can't tell that the
> > > > > region is in use).
> > > > Very good question. It looks like we need to rescan things (at least
> > > > in the UNDI driver case.
> > > UNDI driver was a false alert; it turned out to be the status of the A20
> > > line. I thought I must be treading on something UNDI-related when I
> > > loaded a segment in the [1MB,2MB) range, but actually I was simply
> > > vapourising the contents of base memory thanks to A20. Have you ever
> > > tried doing memset ( phys_to_virt(0), '!', 1<<20 ); ? :-)
> > How did you fail to enable the a20 line?
>
> I didn't. The UNDI driver (i.e. the one in the PXE ROM) plays about with
> it whenever it gets bored and feels like causing some extra debugging
> work. I have a two-stage solution to this problem:
>
> 1. Ensure Etherboot text is always within an even megabyte, so that
> _real_call returns successfully and we make it all the way back to the
> C code even if something nasty happens to A20. (Hey, half your
> memory's just disappeared? No problem! :)
That is a little limiting (etherboot text && stack must be in 1MB) but
in practice this does not look like a problem. Especially as special
linker sections can force the issue if we exceed 1MB.
> 2. Call gateA20_set() immediately after doing any UNDI API call. Thanks
> to (1), I can do this cleanly in C instead of assembler.
This is definitely a solution I like.
On the same toon there is some outstanding gatea20 work that was don in 5.0.x
that has never made it into 5.1.x. Roughly it was disabling and reenabling
gatea20 around the transitions to/from real mode.
> > > I've looked into PMM a little more and we can, I think, ignore it; it is
> > > to do with allocating memory above 1MB but only during POST. As soon as
> > > Int 19 happens (i.e. before we get control), any memory allocated via PMM
> > > is freed and PMM ceases to be available.
> > O.k. One issue on my wishlist is to have a stub that loads etherboot
> > into high memory (>1MB) from the rom initialization code, and then just
> > leaves a very small stub in real mode. Given that I have seen several
> > BIOS's start acting erratically because of their real mode storage for
> > options roms was used up. This could make etherboot more reliable.
>
> Could be interesting; PMM is potentially in charge of high memory at the
> time the initialisation code is called (assuming the BIOS supports PMM),
> but anything it allocates is lost before the system starts booting. I'm
> not sure how you'd work around that problem.
Me either. The PXE spec seems to require it to some extent. But just
skimming it I don't see how.
> [ Some working real mode stub code would, however, come in handy for the
> case of PXE-on-Etherboot; we would need to provide a real-mode entry
> point. ]
There are 2 cases of real mode stubs.
Callbacks PXE-on-Etherboot.
The initial boot, and transitioning from a compressed image in an
UMB to wherever we will finally land.
I can multiplex them all through the standard entry point in main
easily. But I don't currently see how to reduce the UMB footprint.
And the trend for new NICs (tg3 e1000) is that they require larger
drivers.
Eric
|
|
From: Michael B. <mb...@fe...> - 2003-05-28 20:53:15
|
On Wed, 28 May 2003, Eric W. Biederman wrote: > > I didn't. The UNDI driver (i.e. the one in the PXE ROM) plays about with > > it whenever it gets bored and feels like causing some extra debugging > > work. I have a two-stage solution to this problem: > > 1. Ensure Etherboot text is always within an even megabyte, so that > > _real_call returns successfully and we make it all the way back to the > > C code even if something nasty happens to A20. (Hey, half your > > memory's just disappeared? No problem! :) > That is a little limiting (etherboot text && stack must be in 1MB) but > in practice this does not look like a problem. Especially as special > linker sections can force the issue if we exceed 1MB. Weren't we restricted to 64KB until recently? If we're going to exceed 1MB in 5.2, we've got some serious code bloat! :) > > 2. Call gateA20_set() immediately after doing any UNDI API call. Thanks > > to (1), I can do this cleanly in C instead of assembler. > This is definitely a solution I like. > On the same toon there is some outstanding gatea20 work that was don in 5.0.x > that has never made it into 5.1.x. Roughly it was disabling and reenabling > gatea20 around the transitions to/from real mode. Where is this code? Grepping for a20/A20 in 5.0/src doesn't find it. > > > O.k. One issue on my wishlist is to have a stub that loads etherboot > > > into high memory (>1MB) from the rom initialization code, and then just > > > leaves a very small stub in real mode. Given that I have seen several > > > BIOS's start acting erratically because of their real mode storage for > > > options roms was used up. This could make etherboot more reliable. > > Could be interesting; PMM is potentially in charge of high memory at the > > time the initialisation code is called (assuming the BIOS supports PMM), > > but anything it allocates is lost before the system starts booting. I'm > > not sure how you'd work around that problem. > Me either. The PXE spec seems to require it to some extent. But just > skimming it I don't see how. It's not very clear. PXE spec seems to state that the PXE ROM should move itself into upper memory using PMM, implying that it stays there ready for when the system boots. However, PMM spec states that this is impossible; anything allocated by PMM is for POST-time only and will be destroyed at boot time. To make it even more confusing, a disassembly of an Intel PXE ROM shows debug messages that mention PMM, but AFAICT the code never makes any PMM API calls. (At least, the PMM signature, "$PMM", doesn't appear anywhere within the ROM and this is the only way to locate PMM services within the BIOS.) Michael |
|
From: <ebi...@ln...> - 2003-05-29 03:51:48
|
Michael Brown <mb...@fe...> writes: > Weren't we restricted to 64KB until recently? If we're going to exceed > 1MB in 5.2, we've got some serious code bloat! :) make bin/etherboot.img tends in this direction. That is etherboot with all of the drivers compiled in. We still have a ways to go but we are not far off at the moment. My basic point was that it is not hard to force the important bits below 1MB if we need to. > > > 2. Call gateA20_set() immediately after doing any UNDI API call. Thanks > > > to (1), I can do this cleanly in C instead of assembler. > > This is definitely a solution I like. > > On the same toon there is some outstanding gatea20 work that was don in 5.0.x > > that has never made it into 5.1.x. Roughly it was disabling and reenabling > > gatea20 around the transitions to/from real mode. > > Where is this code? Grepping for a20/A20 in 5.0/src doesn't find it. I know there is something outstanding. All I remember for certain is that there was some a20 bug fixing in 5.0.x right at the start of 5.1.x that did get picked up in 5.1.x. The only piece I am certain is missing are gatea20_unset calls in 5.1.x because of problems with relocation. But it looks like you have found the solution to that. So we should be able to add them back in as appropriate. While we are thinking about it the a20 code needs to move out of misc.c as it is highly arch dependent. > > > > O.k. One issue on my wishlist is to have a stub that loads etherboot > > > > into high memory (>1MB) from the rom initialization code, and then just > > > > leaves a very small stub in real mode. Given that I have seen several > > > > BIOS's start acting erratically because of their real mode storage for > > > > options roms was used up. This could make etherboot more reliable. > > > Could be interesting; PMM is potentially in charge of high memory at the > > > time the initialisation code is called (assuming the BIOS supports PMM), > > > but anything it allocates is lost before the system starts booting. I'm > > > not sure how you'd work around that problem. > > Me either. The PXE spec seems to require it to some extent. But just > > skimming it I don't see how. > > It's not very clear. PXE spec seems to state that the PXE ROM should move > itself into upper memory using PMM, implying that it stays there ready for > when the system boots. However, PMM spec states that this is impossible; > anything allocated by PMM is for POST-time only and will be destroyed at > boot time. > > To make it even more confusing, a disassembly of an Intel PXE ROM shows > debug messages that mention PMM, but AFAICT the code never makes any PMM > API calls. (At least, the PMM signature, "$PMM", doesn't appear anywhere > within the ROM and this is the only way to locate PMM services within the > BIOS.) Interesting... Perhaps the guys who wrote the pxe spec were confused. Eric |
|
From: <ebi...@ln...> - 2003-05-30 23:12:13
|
> > > > > O.k. One issue on my wishlist is to have a stub that loads etherboot > > > > > into high memory (>1MB) from the rom initialization code, and then just > > > > > leaves a very small stub in real mode. Given that I have seen several > > > > > BIOS's start acting erratically because of their real mode storage for > > > > > options roms was used up. This could make etherboot more reliable. > > > > Could be interesting; PMM is potentially in charge of high memory at the > > > > time the initialisation code is called (assuming the BIOS supports PMM), > > > > but anything it allocates is lost before the system starts booting. I'm > > > > not sure how you'd work around that problem. > > > Me either. The PXE spec seems to require it to some extent. But just > > > skimming it I don't see how. > > > > It's not very clear. PXE spec seems to state that the PXE ROM should move > > itself into upper memory using PMM, implying that it stays there ready for > > when the system boots. However, PMM spec states that this is impossible; > > anything allocated by PMM is for POST-time only and will be destroyed at > > boot time. > > > > To make it even more confusing, a disassembly of an Intel PXE ROM shows > > debug messages that mention PMM, but AFAICT the code never makes any PMM > > API calls. (At least, the PMM signature, "$PMM", doesn't appear anywhere > > within the ROM and this is the only way to locate PMM services within the > > BIOS.) > > Interesting... > > Perhaps the guys who wrote the pxe spec were confused. I have just had an interesting conversation and I now have a reasonable explanation why BIOS code has problems with protected mode. The problem is that code run in vm86 mode frequently makes use of BIOS services. And if the BIOS services are implemented in protected mode vm86 mode does not work. Which would explain why there are no BIOS interfaces for handling this problem. For the case of making etherboot UMB friendly I would suggest we look at copying the compressing image to low memory, in loader.S and reserving that memory as appropriate. Eric |
