Thread: [Etherboot-discuss] Freeing redundant ROM images.
Brought to you by:
marty_connor,
stefanhajnoczi
Menu
▾
▴
etherboot-discuss
|
From: Glenn B. <gl...@my...> - 2007-08-02 01:31:38
Attachments:
scan.patch
|
Folks, Attached is a self-describing patch to cause redundant Etherboot ROM images to unload themselves during POST, saving memory. Redundant ROMs occur if one installs multiple NICs with identical ROMs in a machine. Please comment if you know how the patch might be improved. Thanks, --Glenn P.S.: Sadly, the machine I cared about does not have space for even 2 copies of the ROM, so continues to complain (since each ROM must be loaded before it unloads itself). This machine (an AMD with nvidia chipset) also wants keyboard interaction after its warning! :-/ |
|
From: Michael B. <mb...@fe...> - 2008-03-08 15:22:31
|
On Wed, 1 Aug 2007, Glenn Brown wrote: > Attached is a self-describing patch to cause redundant Etherboot ROM > images to unload themselves during POST, saving memory. Redundant ROMs > occur if one installs multiple NICs with identical ROMs in a machine. > > Please comment if you know how the patch might be improved. > > Thanks, > --Glenn > > P.S.: Sadly, the machine I cared about does not have space for even 2 > copies of the ROM, so continues to complain (since each ROM must be > loaded before it unloads itself). This machine (an AMD with nvidia > chipset) also wants keyboard interaction after its warning! :-/ There is, I think a solution to this problem. Intel PXE ROMs use PMM to allocate an area of extended memory, copy the body of the ROM to this location and then shrink the option ROM image down to a few kB. This allows multiple ROMs to be loaded simultaneously without running out of option ROM space. The downside to this is that areas of memory allocated with PMM are explicitly *not* available once the system has started booting. The PMM spec goes so far as to state that they will be zeroed before the option ROM's BEV is called. On the other hand, since it seems that every Intel PXE ROM uses this technique, it's probably safe to assume that no BIOS actually implements this detail of the PMM spec. We also need to maintain compatibility with BIOSes that do not provide PMM services, not least because this includes the bochs/qemu BIOS that we use extensively for testing. The simplest modification to add this support would be along the lines of: Expand install() in libprefix.S to allow a manually-specified image source address (rather than assuming %cs:0000) and a manually-specified temporary load buffer address (rather than HIGHMEM_LOADPOINT). Modify the various bits of block-copying code in libprefix.S so that they will cope with a source image in extended memory. (Ideally in a way that will still work under -DKEEP_IT_REAL, though this may be a challenge.) In romprefix.S, during initialisation, attempt to use PMM to allocate a 2MB, 2MB-aligned memory block. (Using a 2MB block is the only way to request 2MB alignment, which is necessary to avoid regions with A20=1). If PMM allocation succeeds, copy the ROM image to the allocated block, store the block address in the ROM itself, and shrink the ROM. In romprefix.S, at execution time, look at the PMM-allocated address. If it is zero, call install() as per usual. If it is non-zero, call install() with the manually-specified source address pointing to the start of the PMM block, and the manually-specified temporary load buffer pointing to the end of the ROM image within the PMM block. In romprefix.S, in the UNDI loader, do a similar test for PMM/non-PMM. Michael |
|
From: Michael B. <mb...@fe...> - 2008-03-11 16:29:07
|
On Sat, 8 Mar 2008, Michael Brown wrote: > > P.S.: Sadly, the machine I cared about does not have space for even 2 > > copies of the ROM, so continues to complain (since each ROM must be > > loaded before it unloads itself). This machine (an AMD with nvidia > > chipset) also wants keyboard interaction after its warning! :-/ > > There is, I think a solution to this problem. Intel PXE ROMs use PMM to > allocate an area of extended memory, copy the body of the ROM to this > location and then shrink the option ROM image down to a few kB. This > allows multiple ROMs to be loaded simultaneously without running out of > option ROM space. gPXE now supports PMM and shrinking its own ROM image via DDIM. On a BIOS that provides PMM services (which should be almost all modern BIOSes), the gPXE ROM will use up only 1.5kB of option ROM space. It should therefore be no problem to have multiple gPXE ROMs present in a system simultaneously. This feature is available as of commit 08b19ab. Bug reports are welcome. Michael |
|
From: Viswanath K. <vis...@gm...> - 2008-03-19 03:01:46
|
I tried using latest PMM gPXE (where the size of the ROM is shunk after loading to PMM memory) It seems to be working fine on a Phoenix bios, but with this option ROM, I cannot enter the BIOS setup. When I press thye <Del> key, it beeps. After removing the card, I can enter BIOS setup. It is a SuperMicro machines with Phoenix Bios. Any data I can collect? -Viswa On Tue, Mar 11, 2008 at 9:28 AM, Michael Brown <mb...@fe...> wrote: > On Sat, 8 Mar 2008, Michael Brown wrote: > > > P.S.: Sadly, the machine I cared about does not have space for even 2 > > > copies of the ROM, so continues to complain (since each ROM must be > > > loaded before it unloads itself). This machine (an AMD with nvidia > > > chipset) also wants keyboard interaction after its warning! :-/ > > > > There is, I think a solution to this problem. Intel PXE ROMs use PMM to > > allocate an area of extended memory, copy the body of the ROM to this > > location and then shrink the option ROM image down to a few kB. This > > allows multiple ROMs to be loaded simultaneously without running out of > > option ROM space. > > > gPXE now supports PMM and shrinking its own ROM image via DDIM. On a BIOS > that provides PMM services (which should be almost all modern BIOSes), the > gPXE ROM will use up only 1.5kB of option ROM space. It should therefore > be no problem to have multiple gPXE ROMs present in a system > simultaneously. > > This feature is available as of commit 08b19ab. Bug reports are welcome. > > Michael > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Etherboot-discuss mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-discuss > |
|
From: Michael B. <mb...@fe...> - 2008-03-26 14:46:30
|
On Tue, 18 Mar 2008, Viswanath Krishnamurthy wrote: > I tried using latest PMM gPXE (where the size of the ROM is shunk after > loading to PMM memory) It seems to be working fine on a Phoenix bios, > but with this option ROM, I cannot enter the BIOS setup. When I press > thye <Del> key, it beeps. After removing the card, I can enter BIOS > setup. > > It is a SuperMicro machines with Phoenix Bios. Any data I can collect? What does the gPXE BIOS-detection line display? This is the first line gPXE prints; it will appear somewhere in the middle of the BIOS POST output and will look something like: gPXE (http://etherboot.org) - PnP BBS PMM Michael |
|
From: Viswanath K. <vis...@gm...> - 2008-03-27 01:21:23
|
It does display gPXE (http://etherboot.org) - PnP BBS PMM -Viswa On Wed, Mar 26, 2008 at 7:46 AM, Michael Brown <mb...@fe...> wrote: > On Tue, 18 Mar 2008, Viswanath Krishnamurthy wrote: > > I tried using latest PMM gPXE (where the size of the ROM is shunk after > > loading to PMM memory) It seems to be working fine on a Phoenix bios, > > but with this option ROM, I cannot enter the BIOS setup. When I press > > thye <Del> key, it beeps. After removing the card, I can enter BIOS > > setup. > > > > It is a SuperMicro machines with Phoenix Bios. Any data I can collect? > > What does the gPXE BIOS-detection line display? This is the first line > gPXE prints; it will appear somewhere in the middle of the BIOS POST > output and will look something like: > > gPXE (http://etherboot.org) - PnP BBS PMM > > Michael > |
|
From: Michael B. <mb...@fe...> - 2008-03-27 05:55:21
Attachments:
pmm1.patch
pmm2.patch
|
On Wed, 26 Mar 2008, Viswanath Krishnamurthy wrote: > > > I tried using latest PMM gPXE (where the size of the ROM is shunk > > > after loading to PMM memory) It seems to be working fine on a > > > Phoenix bios, but with this option ROM, I cannot enter the BIOS > > > setup. When I press thye <Del> key, it beeps. After removing the > > > card, I can enter BIOS setup. > > > > What does the gPXE BIOS-detection line display? This is the first line > > gPXE prints; it will appear somewhere in the middle of the BIOS POST > > output and will look something like: > > It does display > > gPXE (http://etherboot.org) - PnP BBS PMM Thanks. Could you try the two attached debugging patches? Apply each patch to a clean gPXE tree (i.e. don't apply pmm2.patch on top of pmm1.patch; revert the tree to a clean state first). For each of pmm1.patch and pmm2.patch, could you let me know: a) what is displayed on the gPXE BIOS-detection line b) whether or not you are able to enter the BIOS setup with the ROM present (FYI, pmm1.patch disables the PMM allocation, while pmm2.patch will perform the PMM allocation but then behave as though it failed.) Thanks, Michael |
|
From: Itay G. <ita...@gm...> - 2008-06-26 10:34:28
|
Michael, Viswa, Is this issue with the SuperMicro machines, was eventually fixed? Thanks, Itay On Thu, Mar 27, 2008 at 8:55 AM, Michael Brown <mb...@fe...> wrote: > On Wed, 26 Mar 2008, Viswanath Krishnamurthy wrote: > > > > I tried using latest PMM gPXE (where the size of the ROM is shunk > > > > after loading to PMM memory) It seems to be working fine on a > > > > Phoenix bios, but with this option ROM, I cannot enter the BIOS > > > > setup. When I press thye <Del> key, it beeps. After removing the > > > > card, I can enter BIOS setup. > > > > > > What does the gPXE BIOS-detection line display? This is the first line > > > gPXE prints; it will appear somewhere in the middle of the BIOS POST > > > output and will look something like: > > > > It does display > > > > gPXE (http://etherboot.org) - PnP BBS PMM > > Thanks. Could you try the two attached debugging patches? Apply each > patch to a clean gPXE tree (i.e. don't apply pmm2.patch on top of > pmm1.patch; revert the tree to a clean state first). > > For each of pmm1.patch and pmm2.patch, could you let me know: > > a) what is displayed on the gPXE BIOS-detection line > > b) whether or not you are able to enter the BIOS setup with the ROM > present > > (FYI, pmm1.patch disables the PMM allocation, while pmm2.patch will > perform the PMM allocation but then behave as though it failed.) > > Thanks, > > Michael > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Etherboot-discuss mailing list > Eth...@li... > https://lists.sourceforge.net/lists/listinfo/etherboot-discuss > > |
|
From: Michael B. <mb...@fe...> - 2008-06-26 20:33:16
|
On Thu, 26 Jun 2008, Itay Gazit wrote: > On Thu, Mar 27, 2008 at 8:55 AM, Michael Brown <mb...@fe...> > wrote: > > Thanks. Could you try the two attached debugging patches? Apply each > > patch to a clean gPXE tree (i.e. don't apply pmm2.patch on top of > > pmm1.patch; revert the tree to a clean state first). > > > > For each of pmm1.patch and pmm2.patch, could you let me know: > > > > a) what is displayed on the gPXE BIOS-detection line > > > > b) whether or not you are able to enter the BIOS setup with the ROM > > present > > > > (FYI, pmm1.patch disables the PMM allocation, while pmm2.patch will > > perform the PMM allocation but then behave as though it failed.) > > Michael, Viswa, > > Is this issue with the SuperMicro machines, was eventually fixed? I don't think I ever got a reply to my e-mail with the two debugging patches (or, if I did, I don't remember it and have probably lost it). Could you let me know the results of the two tests that I asked for? Thanks, Michael |
|
From: Viswanath K. <vis...@gm...> - 2008-07-05 19:49:26
|
We had the case of bad hardware causing this issue. This had nothing to do with PMM changes. So far the PMM support works on following server types 1. Dell 1950/2950 series 2. HP 380GL series (There was an issue with USB Keyboard which was fixed recently last week) 3. IBM 3550/3650 (Intel series) machines. BTW, IBM BIOS is not BBS/PnP compliant. Go figure, so it hooks int19. One cannot return from int19 to the next boot device. Another issue to figure out later 4. HP Bladecenter (C3000/C7000) 5. IBM Bladecenter (Again IBM bios sucks compared to other standard bios) On IBM 3455 (AMD series), gPXE seems to hang here. Needs further investigation -Viswa On Thu, Jun 26, 2008 at 1:32 PM, Michael Brown <mb...@fe...> wrote: > On Thu, 26 Jun 2008, Itay Gazit wrote: > > On Thu, Mar 27, 2008 at 8:55 AM, Michael Brown <mb...@fe...> > > wrote: > > > Thanks. Could you try the two attached debugging patches? Apply each > > > patch to a clean gPXE tree (i.e. don't apply pmm2.patch on top of > > > pmm1.patch; revert the tree to a clean state first). > > > > > > For each of pmm1.patch and pmm2.patch, could you let me know: > > > > > > a) what is displayed on the gPXE BIOS-detection line > > > > > > b) whether or not you are able to enter the BIOS setup with the ROM > > > present > > > > > > (FYI, pmm1.patch disables the PMM allocation, while pmm2.patch will > > > perform the PMM allocation but then behave as though it failed.) > > > > Michael, Viswa, > > > > Is this issue with the SuperMicro machines, was eventually fixed? > > I don't think I ever got a reply to my e-mail with the two debugging > patches (or, if I did, I don't remember it and have probably lost it). > > Could you let me know the results of the two tests that I asked for? > > Thanks, > > Michael > |
|
From: Itay G. <ita...@gm...> - 2008-09-09 13:51:48
|
Viswa, Regarding the SuperMicro machines, what was the HW problem? Did you solve it? I have just failed to boot gPXE, with the latest code, on two different SuperMicro machines. Thanks, Itay On Sat, Jul 5, 2008 at 10:49 PM, Viswanath Krishnamurthy < vis...@gm...> wrote: > We had the case of bad hardware causing this issue. This had nothing to do > with PMM changes. > > So far the PMM support works on following server types > > 1. Dell 1950/2950 series > 2. HP 380GL series (There was an issue with USB Keyboard which was fixed > recently last week) > 3. IBM 3550/3650 (Intel series) machines. BTW, IBM BIOS is not BBS/PnP > compliant. Go figure, so it hooks int19. One cannot return from int19 to the > next boot device. Another issue to figure out later > > 4. HP Bladecenter (C3000/C7000) > 5. IBM Bladecenter (Again IBM bios sucks compared to other standard bios) > > On IBM 3455 (AMD series), gPXE seems to hang here. Needs further > investigation > > -Viswa > > > > On Thu, Jun 26, 2008 at 1:32 PM, Michael Brown <mb...@fe...> > wrote: > >> On Thu, 26 Jun 2008, Itay Gazit wrote: >> > On Thu, Mar 27, 2008 at 8:55 AM, Michael Brown <mb...@fe... >> > >> > wrote: >> > > Thanks. Could you try the two attached debugging patches? Apply each >> > > patch to a clean gPXE tree (i.e. don't apply pmm2.patch on top of >> > > pmm1.patch; revert the tree to a clean state first). >> > > >> > > For each of pmm1.patch and pmm2.patch, could you let me know: >> > > >> > > a) what is displayed on the gPXE BIOS-detection line >> > > >> > > b) whether or not you are able to enter the BIOS setup with the ROM >> > > present >> > > >> > > (FYI, pmm1.patch disables the PMM allocation, while pmm2.patch will >> > > perform the PMM allocation but then behave as though it failed.) >> > >> > Michael, Viswa, >> > >> > Is this issue with the SuperMicro machines, was eventually fixed? >> >> I don't think I ever got a reply to my e-mail with the two debugging >> patches (or, if I did, I don't remember it and have probably lost it). >> >> Could you let me know the results of the two tests that I asked for? >> >> Thanks, >> >> Michael >> > > |
|
From: Michael B. <mb...@fe...> - 2008-09-09 18:55:03
|
On Tuesday 09 September 2008 14:51:45 Itay Gazit wrote: > Viswa, > Regarding the SuperMicro machines, what was the HW problem? Did you solve > it? > > I have just failed to boot gPXE, with the latest code, on two different > SuperMicro machines. What does the gPXE ROM banner line say? This is the line that should look something like: gPXE (http://etherboot.org) 05:00.0 7000 PCI3.00 PnP BBS PMM0040 CA00 This line contains just about all the diagnostic information about the ROM prefix, and is present even in non-debug builds. If you're having issues with gPXE loading from ROM (i.e. issues that prevent you even reaching the gPXE shell prompt), then that's the most useful diagnostic information you can give. Michael |
|
From: Itay G. <ita...@gm...> - 2008-09-10 14:29:41
|
gPXE ROM banner: gPXE (http://etherboot.org) - 05:00.0 C800 PCI3.00 PnP BBS PMM0020 0500 If I press Ctrl-B it shows: "gPXE (PCI 05:00.0) starting execution" and then get stuck. Itay On Tue, Sep 9, 2008 at 9:54 PM, Michael Brown <mb...@fe...>wrote: > On Tuesday 09 September 2008 14:51:45 Itay Gazit wrote: > > Viswa, > > Regarding the SuperMicro machines, what was the HW problem? Did you solve > > it? > > > > I have just failed to boot gPXE, with the latest code, on two different > > SuperMicro machines. > > What does the gPXE ROM banner line say? This is the line that should look > something like: > > gPXE (http://etherboot.org) 05:00.0 7000 PCI3.00 PnP BBS PMM0040 CA00 > > This line contains just about all the diagnostic information about the ROM > prefix, and is present even in non-debug builds. If you're having issues > with gPXE loading from ROM (i.e. issues that prevent you even reaching the > gPXE shell prompt), then that's the most useful diagnostic information you > can give. > > Michael > |
|
From: Michael B. <mb...@fe...> - 2008-09-10 15:04:25
|
On Wednesday 10 September 2008 15:29:37 Itay Gazit wrote: > gPXE ROM banner: > > gPXE (http://etherboot.org) - 05:00.0 C800 PCI3.00 PnP BBS PMM0020 0500 > > If I press Ctrl-B it shows: "gPXE (PCI 05:00.0) starting execution" and > then get stuck. Thanks. That's a seriously screwed BIOS - it's reporting itself as PCI3.00, but seems to have requested that gPXE copy itself into the option ROM space at 0500:0000. Since 0500:0000 isn't within the option ROM space, this is going to fail. I've created three patches to try. Each patch should be applied against a clean copy of romprefix.S (i.e. do not accumulate the patches). Could you try them, and let me know what happens (including the ROM banner) in each case? Thanks, Michael |
|
From: Itay G. <ita...@gm...> - 2008-09-11 11:07:52
|
dump-gs-early.patch - Banner: "gPXE (http://etherboot.org) - 05:00.0 C800 0500 PCI3.00 PnP BBS PMM0020 0500". By pressing Ctrl-B the machine stucked. force-pci-299.patch - "gPXE (http://etherboot.org) - 05:00.0 C800 PCI2.99 PnP BBS PMM0020 0500". By pressing Ctrl-B I did receive the gPXE command line, but the network driver didn't load ( ifstat returned nothing ). no-pci3-header.patch - "gPXE (http://etherboot.org) - 05:00.0 C800 PCI3.00 PnP BBS PMM0020 0500". By pressing Ctrl-B I did receive the gPXE command line, but the network driver didn't load ( ifstat returned nothing ). Thanks Itay On Wed, Sep 10, 2008 at 6:03 PM, Michael Brown <mb...@fe...>wrote: > On Wednesday 10 September 2008 15:29:37 Itay Gazit wrote: > > gPXE ROM banner: > > > > gPXE (http://etherboot.org) - 05:00.0 C800 PCI3.00 PnP BBS PMM0020 0500 > > > > If I press Ctrl-B it shows: "gPXE (PCI 05:00.0) starting execution" and > > then get stuck. > > Thanks. That's a seriously screwed BIOS - it's reporting itself as > PCI3.00, > but seems to have requested that gPXE copy itself into the option ROM space > at 0500:0000. Since 0500:0000 isn't within the option ROM space, this is > going to fail. > > I've created three patches to try. Each patch should be applied against a > clean copy of romprefix.S (i.e. do not accumulate the patches). Could you > try them, and let me know what happens (including the ROM banner) in each > case? > > Thanks, > > Michael > |
Thanks for helping keep SourceForge clean.
X