On 08/28/14 16:52, Peter Maydell wrote: > On 28 August 2014 15:30, Laszlo Ersek <[email protected]> wrote: >> So we got, in the NOR-mapped FD file: >> >> address 0: jump instruction to 4K, otherwise a bunch of emptiness >> (according to erase polarity!) > > Ideally this should be a proper complete vector table with > handlers for all the exception vectors. In particular it is a > nice touch if exceptions for things like invalid accesses > and undefined instructions end up in some sort of panic-abort > function that dumps a diagnostic message to the UART. > This isn't necessary for proper operation but it's handy if > you're trying to debug either UEFI itself or early kernel startup. > As a minimum you want to have them go somewhere sensible > (like a jump-to-self instruction) so that we definitely don't just > try to reenter UEFI at its start point (an effect that is more > likely in 32-bit ARM where the all-zeroes instruction is a NOP). > > Does UEFI install a proper vector table at some point in > bootup by writing to the vector base address register?
Yes, it does that on x86_64 / OVMF. (The feature comes from UefiCpuPkg.) The exception type & details (registers etc) are dumped, and even the offending binary file and RIP are identified in a way that allows one to correlate the exception with the source code. However: - I have no clue if anything similar exists in / for ARM builds. - Even if someone wants to implement such, where should (where *can*, actually) the exception handler table exist at all? The addresses that I listed above are backed by the (read-only) flash chip. The exception handler table should be built somewhere in DRAM, no? > If > not then providing a sensible initial set of vectors is even > more important. Hmmm, wait a second, now grepping for CpuExceptionHandlerLib, I'm actually getting results from ARM packages as well. Ard's series resolves this library class to: CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf Ugh, that's a null library instance; it does nothing. :( If it's any consolation, "ArmVExpress.dsc.inc" seems to use the same, for the physical platforms. ... Hm, maybe I'm looking in the wrong place. ARM likely doesn't actually use CpuExceptionHandlerLib for handling CPU expcetions. There's this code though: ArmPkg/Drivers/CpuDxe/AArch64/Exception.c I think it covers exactly what you say (or at least participates in it). People have even submitted patches against it (see git commit 6a343fac for example.) I'm quite sure the feature you named is covered, but Olivier should be able to state authoritatively. 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
