I'm sorry, ofc it is supported, it was just some size error.(my fault) Thanks Michael
On Thu, Jul 21, 2016 at 3:51 AM, Gao, Liming <[email protected]> wrote: > 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] > <[email protected]>] On Behalf Of > > Michael Zimmermann > > Sent: Tuesday, July 19, 2016 2:20 PM > > To: Andrew Fish > > Cc: [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]> 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: > <%0b>> >> [email protected]>> wrote: > > >> > > > >> > > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann < > > >> [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] > <[email protected]%0b> > > >> > wrote: > > >> > > > > >> > >> > > >> > >>> On Jul 17, 2016, at 11:02 PM, Michael Zimmermann < > > >> > >> [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] > > >> > >>> > > >> > >> > > >> > > > 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] > > >> > > > > >> > > > 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] > > >> https://lists.01.org/mailman/listinfo/edk2-devel > > >> > > > > > > > > > > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > [email protected] > > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
