Re: [edk2-devel] [PATCH v1] OvmfPkg: Add build options for 8MB and 16MB X64 OVMF images

["Laszlo Ersek" <lersek@redhat.com>]

On 05/28/21 15:33, Brian J. Johnson wrote:
> On 5/27/21 5:12 AM, Laszlo Ersek wrote:
>> On 05/26/21 19:08, Devon Bautista wrote:
>>> Currently, the largest volume size for building OVMF images is 4MB. With
>>> the growth of the Linuxboot project, maintainers have had to maintain a
>>> fork containing this patch which allows larger image sizes in order for
>>> Linuxboot developers/users to have enough space to experiment with
>>> and test including their own Linux kernel in the DXE section of OVMF
>>> firmware. Testing using OVMF is valuable since it allows testing in QEMU
>>> and thus does not require any hardware to do so.
>>>
>>> This patch allows specifying '-D FD_SIZE_8MB' or '-D FD_SIZE_16MB' to
>>> the OVMF build script in order to add the ability to build 8MB or 16MB
>>> x86_64 (X64) OVMF images, respectively.
>>>
>>> Signed-off-by: Devon Bautista <dbautista@newmexicoconsortium.org>
>>> ---
>>>   OvmfPkg/OvmfPkgDefines.fdf.inc | 34 ++++++++++++++++++++++++++++++++++
>>>   OvmfPkg/OvmfPkgX64.dsc         | 10 +++++++++-
>>>   OvmfPkg/VarStore.fdf.inc       | 16 ++++++++--------
>>>   3 files changed, 51 insertions(+), 9 deletions(-)

>> (4) Dumping a bunch of magic numbers on reviewers is unhelpful. I'll
>> need to sit down with a calculator and go through the patch with a
>> magnifying glass. Please support that work by creating a commit message
>> (summary table) similar to the one in commit b24fca05751f ("OvmfPkg:
>> introduce 4MB flash image (mainly) for Windows HCK", 2017-05-05).
>>
> 
> I've found it very helpful to create a spreadsheet to calculate the
> offsets based on the region sizes, and add it to the tree.  It can also
> calculate the related PCDs, if any.  That makes it a lot easier to
> verify the numbers, and to make changes in the future.

This sounds really nice -- I'd appreciate such a spreadsheet in the
OvmfPkg directory tree somewhere. My concern is that most (all?)
spreadsheet formats are compressed archives one way or another (ZIP
archives of multiple files, or gzipped XML files, or some such), and
such formats are not nice to track in git. I'd like a (structured)
plaintext representation of the spreadsheet to live in edk2 git. Same as
we prefer plaintext SVG files for graphics / diagrams in edk2, to my
knowledge.

Thanks!
Laszlo