On Aug 28, 2014, at 8:46 AM, Laszlo Ersek <[email protected]> wrote:
> On 08/28/14 17:17, Peter Maydell wrote: >> On 28 August 2014 16:16, Laszlo Ersek <[email protected]> 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. > It is the ARM architecture that places the reset vector at exception/vector zero. In x86 it is at the magic address, 0xFFFFFFF0, and not associated with exceptions/interrupts. The PI spec reserves the 1st 16 bytes of the FV, the ZeroVector[], for use by the build system if needed for the ARM reset vector. The edk2 system will patch a branch to the entry point of the SEC module into the ZeroVector of the FV header if the FV contains a SEC module. When you have memory, or temporary PEI memory. Having memory is also known as you are able to run C code. At this point you can relocate the vectors and handle exceptions. You can always offset the FV into the FD, and make the beginning of the FD a vector table. As long as the reset vector branches to the start of the FV (which will branch to the start of SEC) it will work just fine. > 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 FDF.inc file (which is also committed to the tree). > > The "main" FDF file can then !include this generated FDF.inc. > > In these cases the development process goes like: > - if you need to update your custom code, update the assembly file, > - regenerate the FDF.inc by manually re-running the python script, > - commit the changes together (changed assembly src + FDF.inc), > - the next build will pick up the new FDF.inc. > I don’t really understand what all this is for? If some one could explain the requirements we could probably add a feature to the edk2 build system to fix this. To see what the build system does today look at: https://svn.code.sf.net/p/edk2/code/trunk/edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c EFI_STATUS UpdateArmResetVectorIfNeeded ( IN MEMORY_FILE *FvImage, IN FV_INFO *FvInfo ) /*++ Routine Description: This parses the FV looking for SEC and patches that address into the beginning of the FV header. For ARM32 the reset vector is at 0x00000000 or 0xFFFF0000. For AArch64 the reset vector is at 0x00000000. This would commonly map to the first entry in the ROM. ARM32 Exceptions: Reset +0 Undefined +4 SWI +8 Prefetch Abort +12 Data Abort +16 IRQ +20 FIQ +24 We support two schemes on ARM. 1) Beginning of the FV is the reset vector 2) Reset vector is data bytes FDF file and that code branches to reset vector in the beginning of the FV (fixed size offset). Need to have the jump for the reset vector at location zero. We also need to store the address or PEI (if it exists). We stub out a return from interrupt in case the debugger is using SWI (not done for AArch64, not enough space in struct). The optional entry to the common exception handler is to support full featured exception handling from ROM and is currently not support by this tool. Thanks, Andrew Fish > 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. > > Thanks > Laszlo > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/edk2-devel
