Alain Kalker [mailto:a.c.kal...@gmail.com] wrote:
]I'm trying to build DuetPkg for X64 on Arch Linux x86_64, using GCC46
]toolchain, but struggling to keep the size down because of the dreaded
]GenPage error, which currently reads:
]
]/home/miki/vcs/git/tianocore/edk2/Build/DuetPkgX64/DEBUG_GCC46/FV/
]EfildrPure: ERROR 16386: Invalid parameter option
] Input file size (0x7a54c) exceeds the Page Table Offset (0x70000)
The Duet project hits the MS-DOS 640KB barrier pretty easily.
]Things which I have tried (but which haven't helped enough yet):
]
]- Use the latest GCC compiler available for my OS (GCC 4.9.0) with the
]GCC48 toolchain tag
]
]This fails with another error (which is a known issue):
]
]"GenFw" -e DXE_DRIVER -o /home/miki/vcs/git/tianocore/edk2/Build/
]DuetPkgX64/DEBUG_GCC48/X64/DuetPkg/DxeIpl/DxeIpl/DEBUG/DxeIpl.efi /home/
]miki/vcs/git/tianocore/edk2/Build/DuetPkgX64/DEBUG_GCC48/X64/DuetPkg/
]DxeIpl/DxeIpl/DEBUG/DxeIpl.dll
]GenFw: ERROR 3000: Invalid
] Unsupported section alignment.
]
]- Disable as many things as possible in DuetPkg/DuetPkg.fdf:
]
]Scouring the net for information, and using my own imagination, I've
]disabled the following:
]
]#INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
]#INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
]#INF IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
]#INF IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe/IsaFloppyDxe.inf
]+#FILE FREEFORM = PCD
](gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile) {
]+# SECTION RAW = MdeModulePkg/Logo/Logo.bmp
]+# }
]
]Yet, apparently, this is still not enough, the GenPage error keeps
]popping up no matter how hard I try. Are there any other ways of keeping
]the size down?
]>From what I've read, people seem to be having success building with
]Visual Studio. Is this toolchain really that much better than GCC?
It would be hard to call Visual Studio a better compiler
than gcc given that it doesn't support the C99 (or later)
language standard. The strength of Visual Studio in this
case is mature support for link time code generation, which
allows it to reduce image size by discarding unused code and
data. Gcc now has link time optimization that eliminates
unused code and data (-flto). But it is newer and not quite
as easy to use. EDK2 does not currently use the gcc link
time optimization feature.
]I know there are projects out there like Clover Boot Loader and such, but
]I'd rather stick to vanilla Duet from edk2.
]
]Any suggestions on how to solve this?
Duet starts in real mode and uses legacy BIOS INT 13h calls
to read the FV into memory. INT 13h can only target the lower
640KB memory. Duet also uses a chunk of low memory for page
tables. The legacy BIOS needs some low memory for its own use
too. The result is a severe limitation on FV size. One
solution is to copy the FV data into memory above 1MB
as it is read from disk a cluster at a time. With that
change, the entire FV no longer needs to fit into low memory.
Here is an example:
http://notabs.org/coreboot/duet-payload/index.htm
Though this project builds a coreboot payload, it also
produces a bootable Duet FAT image that is not subject
to the 640KB low memory restriction.
Thanks,
Scott
]Kind regards,
]
]Alain Kalker
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
