Michael: FV also supports BlockSize and NumBlocks. You can specify them to other value, for example BlockSize = 0x8000. If NumBlocks is not specified, GenFv will calculate the required FV size and divide BlockSize to get NumBlocks.
If your purpose is to generate FV image only, you can remove FD section. The required Flash PCD can be set to its value in [Defines] section of FDF file. For example: [Defines] SET gArmTokenSpaceGuid.FvMainCompactBaseAddress = 0xFFF00000 [FV.FvMainCompact] BlockSize = 0x8000 NumBlocks = 0x80 FvBaseAddress = 0xFFC00000 ... Thanks Liming From: edk2-devel [mailto:[email protected]] On Behalf Of Michael Zimmermann Sent: Tuesday, July 19, 2016 2:20 PM To: Andrew Fish <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [edk2] Generated *.FV is bigger than it's contents ok this is what's happening (in comparison to keeping FVMAIN_COMPACT in the FD): - the generated FVMAIN_COMPACT doesn't have the options EFI_BASE_ADDRESS and EFI_NUM_BLOCKS, EFI_BLOCK_SIZE is 0x1 - this missing base causes FfsRebase to just return(I can actually see that in the binary, because there are WAY more differences than just the reset vector) - since FfsRebase returned without doing anything, mArm is still false. This line didn't get executed: https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3380 - since mArm is false, UpdateArmResetVectorIfNeeded is not getting called as you can see there are two problems: - no rebase - caused by that, all the ARM specific handling like the reset vector doesn't happen Now, FV's support the 'FvBaseAddress' flag, after setting that I indeed get a relocated binary, with a correct reset vector. so, what I did, apart from setting the base address in the Fv section is removing this line to not include the Fv in the FD: 'FV = FVMAIN_COMPACT' Is this the correct way or is there more to it? I guess I have to keep all the surrounding lines for generating the FD because it produces Pcd's like PcdFdBaseAddress which are needed right? Thanks for your help, Michael On Mon, Jul 18, 2016 at 11:54 PM, Andrew Fish wrote: > > On Jul 18, 2016, at 2:25 PM, Michael Zimmermann > wrote: > > If I do that the file is as small as possible(yay), but not bootable > anymore, i.e. the first 4 bytes are 0 instead of the instruction which > jumps past the DOS header. > > > The 1st 16-bytes of the FV header are defined to be a zero vector. This > allows space for code that resets low, and is patched by the build tools. > > > https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L2050 > > It looks like GenFv will patch the start of the FV with a jmp to the > _ModuleEntryPoint (The entry point in the PE/COFF header) of the SEC or > PeiCore if they exist in the FV? > > You can poke around in that area to figure out why the patch did not > happen. > > Thanks, > > Andrew Fish > > Thanks > Michael > > On Mon, Jul 18, 2016 at 11:00 PM, Andrew Fish wrote: > >> >> > On Jul 18, 2016, at 1:42 PM, Michael Zimmermann < >> [email protected]<mailto:[email protected]>> wrote: >> > >> > > For example This statement in the [FD.MEMFD] section will cause this >> region of the FLASH to get padded out if the FV is smaller than 0xA00000 >> > >> > that seems to be the problem because the Size in the FV header is set >> to that value and the file FVMAIN_COMPACT.Fv always has that size. >> > >> > of course I could just make it smaller, but in this case I'd have to >> adjust it to the current size and increase it every time I need more space >> to fix the build error. >> > It would be easier to just be able to remove the 0xFF padding for the >> FV, or at least have a clean way to remove it afterwards by external tools. >> > >> > to make things easier I'll link my source here: >> > >> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf >> < >> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf >> > >> > >> >> What is the size of the FVMAIN_COMPACT if you don't place it in the FD? >> >> Thanks, >> >> Andrew Fish >> >> > Thanks >> > Michael >> > >> > >> > On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish <mailto: <mailto:%0b>>> [email protected]<mailto:[email protected]>>> wrote: >> > >> > > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann < >> [email protected]<mailto:[email protected]> > wrote: >> > > >> > > >> > > I don't need/use XIP or relocation(would the latter make a difference >> > > anyway?). >> > > >> > > Also the difference between FD and FV seems to be terminology only, >> because >> > > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv. >> > > >> > > What I successfully tested as a workaround is reading >> > > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to >> that >> > > size. >> > > That seems to work, but I'm not sure if it's exact, because there are >> still >> > > a few 0xff bytes left and I'm not sure if these really are for >> aligning the >> > > size only. >> > > >> > >> > Michael, >> > >> > The FD is a collection of FVs and Data regions output by the build >> system. If all you have is an FV you should just use that. You can reduce >> the padding by setting the BlockSize smaller. The FvAlignment value >> (commonly 16) would be a good value to try. Any padding after that is >> coming from the FD creation: >> > >> https://github.com/tianocore/edk2/blob/master/OvmfPkg/OvmfPkgX64.fdf#L91 >> >> > >> > >> > 0x100000|0xA00000 >> > >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize >> > FV = DXEFV >> > >> > For example This statement in the [FD.MEMFD] section will cause this >> region of the FLASH to get padded out if the FV is smaller than 0xA00000 >> > >> > The FV will start with an EFI_FIRMWARE_VOLUME_HEADER, >> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105 >> < >> https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Pi/PiFirmwareVolume.h#L105> >> , so you can programmatically figure out how big it is if you need to copy >> it. >> > >> > Thanks, >> > >> > Andrew Fish >> > >> > > Thanks >> > > Michael >> > > >> > > On Mon, Jul 18, 2016 at 5:28 PM, Andrew Fish <[email protected] <mailto:[email protected]%0b>>> > wrote: >> > > >> > >> >> > >>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann < >> > >> [email protected]<mailto:[email protected]> > wrote: >> > >>> >> > >>> >> > >>> Hi, >> > >>> >> > >>> I noticed that the size of YOURPLATFORM.fd always equals the size >> > >> specified >> > >>> in your fdf >> > >>> i.e. 4MB for 'Size = 0x00400000|gArmTokenSpaceGuid.PcdFdSize'. >> > >>> >> > >>> I don't know much about the case where this gets flashed to a nand >> and >> > >>> executed in place, but when using edk2 on a ARM PrePi device with >> edk2 >> > >>> loaded into RAM, this looks like a huge waste of storage memory and >> > >> loading >> > >>> time to me. >> > >>> >> > >>> So, is it really important to have multiple MB(depending of you fv >> size >> > >>> ofc) of 0xff appended to the firmware or is there a fdf option or >> > >>> post-compilation tool to remove this? >> > >>> >> > >> >> > >> The YOURPLATFORM.fd is a Flash Device (.fd) and thus there is an >> > >> assumption it is a fixed size. If you want a flexible size you can >> use an >> > >> FV. Are you dependent on relocating the code so it can XIP? Is that >> what if >> > >> forcing the use of an FD? >> > >> >> > >> Just trying to figure out if what you are really asking for is the >> ability >> > >> to relocate an FV that is only as big as required? Maybe that is an >> FD, >> > >> maybe not? >> > >> >> > >> Short term if your FD is just a single FV you can use a PCD to know >> the >> > >> size and only copy that much data to the RAM. You would have to >> manually >> > >> pick an FD size that did not waist too much storage. >> > >> >> > >> Thanks, >> > >> >> > >> Andrew Fish >> > >> >> > >>> Thanks >> > >>> Michael >> > >>> _______________________________________________ >> > >>> edk2-devel mailing list >> > >>> [email protected]<mailto:[email protected]> >> > >>> >> > >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7wYg-xu4aJ-6YGBqB4GTUNMVu1W9h8mqqf864YQ&e= >> < >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=Kr0PunsxtwGLmV7IsSEodsro5Wwu2oRxRh1L7fFpt3w&s=FXzJ7wYg-xu4aJ-6YGBqB4GTUNMVu1W9h8mqqf864YQ&e= >> > >> > >> >> > >> >> > > _______________________________________________ >> > > edk2-devel mailing list >> > > [email protected]<mailto:[email protected]> >> > > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=GBYUQYXoyDqknWeJcI64xlIkHnhnVmabgBV1ABmDeZs&s=QSUxiPKjBWf7bkI3IIL0E8JliL4vuwEWURFyB2oQQ0E&e= >> < >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_mailman_listinfo_edk2-2Ddevel&d=CwICAg&c=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8u84&r=4sdzHKz0eU1vXqaUySVmyA&m=GBYUQYXoyDqknWeJcI64xlIkHnhnVmabgBV1ABmDeZs&s=QSUxiPKjBWf7bkI3IIL0E8JliL4vuwEWURFyB2oQQ0E&e= >> > >> > >> > >> >> _______________________________________________ >> edk2-devel mailing list >> [email protected]<mailto:[email protected]> >> https://lists.01.org/mailman/listinfo/edk2-devel >> > > > _______________________________________________ edk2-devel mailing list [email protected]<mailto:[email protected]> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
