On Oct 2, 2013, at 2:03 AM, Wei Liu <[email protected]> wrote: > On Tue, Oct 01, 2013 at 10:33:49AM -0700, Andrew Fish wrote: >> >> On Oct 1, 2013, at 10:10 AM, Wei Liu <[email protected]> wrote: >> >>> Hi OVMF experts >>> >>> I'm trying to make OVMF work with Xen HVM and discover a possible bug in >>> EDK2 OVMF. The root cause is that EmuVariableFvbRuntimeDxe sets FTW >>> spare space base address to a not-aligned address. FTW refuses to >>> initializes in that situation. >>> >>> My quick hack seems to fix that, Xen HVM is not able to boot to internal >>> EFI shell. But I'm sure whether that makes sense -- by far I only play >>> with OVMF for 3 days and there's certainly a lot more for me to learn. >>> >>> I'm wondering how other platform works. >> >> The general case for the edk2 is the FDF files define the FLASH layout via >> setting PCDs. >> >> The FD (Flash Device) has a bass address, and then things are specified as >> offsets. If the offsets are followed by PCD tokens, then the build sets >> these PCD values. >> >> https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/EmulatorPkg.fdf >> ... >> [FD.Fv_Recovery] >> # >> # In OS X PEIMs are really XIP, so we need to make this address match the >> malloced >> # buffer for the FD (0x41000000). If this address does not match the FV will >> get >> # relocated in place (works, but not a great idea). >> # >> BaseAddress = 0x102000000|gEmulatorPkgTokenSpaceGuid.PcdEmuFdBaseAddress >> #The base address of the FLASH Device. >> Size = 0x005a0000|gEmulatorPkgTokenSpaceGuid.PcdEmuFirmwareFdSize >> #The size in bytes of the FLASH Device >> ErasePolarity = 1 >> BlockSize = 0x10000 >> NumBlocks = 0x5a >> ... >> 0x0058e000|0x00002000 >> gEmulatorPkgTokenSpaceGuid.PcdEmuFlashNvStorageFtwWorkingBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize >> #NV_FTW_WORKING >> DATA = { >> # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = >> gEdkiiWorkingBlockSignatureGuid = >> # { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, >> 0x1b, 0x95 }} >> 0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49, >> 0xa0, 0xce, 0x65, 0x0, 0xfd, 0x9f, 0x1b, 0x95, >> # Crc:UINT32 #WorkingBlockValid:1, WorkingBlockInvalid:1, >> Reserved >> 0xE2, 0x33, 0xF2, 0x03, 0xFE, 0xFF, 0xFF, 0xFF, >> # WriteQueueSize: UINT64 >> 0xE0, 0x1F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 >> } >> >> 0x00590000|0x00010000 >> #NV_FTW_SPARE >> gEmulatorPkgTokenSpaceGuid.PcdEmuFlashNvStorageFtwSpareBase|gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize >> ... > > Thanks for the pointer. > > In EmulatorPkg/FlashMapPei/FlashMapPei.c there is actually a fixup for > that base address, not sure if that's what makes EmulatorPkg work. > > PcdSet64 (PcdFlashNvStorageFtwSpareBase64, PcdGet64 > (PcdEmuFlashNvStorageFtwSpareBase) + FdFixUp); >
This is emulator specific I think. Might have to do with not being able to allocate the virtual address set in the FDF file in the Application that is the emulator. >> >> I'm not sure what OVMF is doing? > > OVMF has following content in OvmfPkgX64.dsc: > > [PcdsDynamicDefault] > > gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0 > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0 > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0 > gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase|0 > > Per the DSC document, the above line sets PcdFlashNvStorageFtwSpareBase > to 0 as initial value. > > Then EmuVariableFvbRuntimeDxe which is loaded right before FTWDxe sets > that value to > SubPtr = (VOID*) ((UINT8*) Ptr + EMU_FVB_BLOCK_SIZE); > PcdSet32 (PcdFlashNvStorageFtwSpareBase, (UINT32)(UINTN) SubPtr); > > Ptr is the value in PcdEmuVariableNvStoreReserved, which is pre-set > to 0 and initialized in PlatformPei. The reserved address is dynamically > allocated. The allocation doesn't guarantee to be EMU_FV_BLOCK_SIZE > aligned. So I'm suspecting there's a bug in EmuVariableFvbRuntimeDxe. > Maybe the original allocation should be aligned? > Thanks > Wei. > >> >> Thanks, >> >> Andrew Fish >> >> >> >> ------------------------------------------------------------------------------ >> October Webinars: Code for Performance >> Free Intel webinars can help you accelerate application performance. >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most >> from >> the latest Intel processors and coprocessors. See abstracts and register > >> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk >> _______________________________________________ >> edk2-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
