Michael: I have no comments on your patch. I am curious what build error when you specify BlockSize.
Thanks Liming From: edk2-devel [mailto:[email protected]] On Behalf Of Michael Zimmermann Sent: Wednesday, July 20, 2016 11:57 PM To: Gao, Liming <[email protected]> Cc: [email protected] <[email protected]>; Andrew Fish <[email protected]> Subject: Re: [edk2] Generated *.FV is bigger than it's contents > 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. It does not, It gives me an build error. I didn't check the FDF spec, but edk2's FDF parser doesn't support it from what I can see in the source code. For me it doesn't matter though because I don't think I have to set the size of the FV > 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: Why didn't I see this solution? too simple :P thx. so, I currently have this (working) patch to generate the small FV and making the FD/FV drivers happy. Any suggestions on that or does it look good to you? Thanks Michael ================================= diff --git a/LittleKernelPkg.fdf b/LittleKernelPkg.fdf index 4de69e1..0ad9756 100644 --- a/LittleKernelPkg.fdf +++ b/LittleKernelPkg.fdf @@ -26,35 +26,10 @@ [Defines] !include $(WORKSPACE)/Build/EFIDROID/LittleKernelPkg.fdf.inc - -[FD.LittleKernelPkg_EFI] -BaseAddress = $(FD_BASE)|gArmTokenSpaceGuid.PcdFdBaseAddress # The base address of the Firmware in NOR Flash. -Size = 0x00200000|gArmTokenSpaceGuid.PcdFdSize # The size in bytes of the FLASH Device -ErasePolarity = 1 - -# This one is tricky, it must be: BlockSize * NumBlocks = Size -BlockSize = 0x00001000 -NumBlocks = 0x200 - -0x00000000|0x00200000 -gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize -FV = FVMAIN_COMPACT +SET gArmTokenSpaceGuid.PcdFdBaseAddress = $(FD_BASE) +SET gArmTokenSpaceGuid.PcdFdSize = 0x00400000 +SET gArmTokenSpaceGuid.PcdFvBaseAddress = $(FD_BASE) +SET gArmTokenSpaceGuid.PcdFvSize = 0x00400000 ################################################################################ @@ -189,6 +164,7 @@ FvNameGuid = 411ffc75-2138-44b9-874c-d2c91fa78e91 } [FV.FVMAIN_COMPACT] +FvBaseAddress = $(FD_BASE) FvAlignment = 8 ERASE_POLARITY = 1 MEMORY_MAPPED = TRUE On Wed, Jul 20, 2016 at 5:27 PM, Gao, Liming wrote: > 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 > Cc: [email protected]<mailto:[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]<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
