Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

Subject: Re: [edk2] [PATCH v3 09/10] ArmPlatformPkg: add support for a QEMU/mach-virt target

From: Laszlo Ersek <>

To: Peter Maydell <>

Date: 2014-08-29 01:46:01

On 08/28/14 17:17, Peter Maydell wrote:
> On 28 August 2014 16:16, Laszlo Ersek  wrote:
>> On 08/28/14 16:59, Ard Biesheuvel wrote:
>>> However, putting a vector table in that particular place is
>>> troublesome, as the whole point of having the region is to avoid
>>> putting a Firmware Volume (FV) there. And having to code the whole
>>> vector table in hex inside the DATA = { } is not a great prospect
>>> either.
> This just seems like a flaw in UEFI to me. You really need to
> be able to write bits of custom assembly and data to low memory.

I think I can agree that this may be a limitation of the edk2 build
system (not "UEFI" in general). I have read complaints before that DATA
= { } regions in FDF files are a pain to format, especially in an
automated way.

As a workaround, sometimes people write Python scripts (which they
commit to the tree) that process custom source files (which they also
commit to the tree). These source files can be assembly language files
that are not covered by the normal edk2 build process. The python
script(s) can invoke custom assemblers, binutils, hexdump as well, and
the output can be some file (which is also committed to the tree).

The "main" FDF file can then !include this generated

In these cases the development process goes like:
- if you need to update your custom code, update the assembly file,
- regenerate the by manually re-running the python script,
- commit the changes together (changed assembly src +,
- the next build will pick up the new

This is not "ideal" (as in, "fully automated"), but it works; there have
been examples.

>From time to time BaseTools are extended to cover such "extras"
natively. Specifically, this use case seems new to me.

But, certainly doable, as long as one were to write a suitable generator
in Python, and of course the assembly code in question.

>> I think that the exception vector table simply doesn't *belong* in the
>> flash.
> I don't understand that. In the flash seems entirely reasonable
> to me...

I was simply wrong, probably.


Slashdot TV.  
Video for Nerds.  Stuff that matters.
edk2-devel mailing list