diff mbox

[edk2] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

Message ID CAKv+Gu_SX4apoY1VTt6YN20KpAweJi7oVzcsOG6nGJCwSk81gg@mail.gmail.com
State New
Headers show

Commit Message

Ard Biesheuvel Feb. 29, 2016, 5:09 p.m. UTC 
On 17 February 2016 at 14:39, Cohen, Eugene <eugene@hp.com> wrote:
> Instead of only handling SEC Core or PEI Core instances in the outer FV,
> the GenFv tool will now recurse into FV image FFS files to look for instances
> in encapsulated FVs so the vector area can be updated appropriately.
>
> Tested on ARM and AArch64 platforms.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Eugene Cohen <eugene@hp.com>


Hello Eugene,

This patch fails to build:

GenFvInternalLib.c: In function ‘UpdateArmResetVectorIfNeeded’:
GenFvInternalLib.c:2197:25: error:
‘ARMT_UNCONDITIONAL_JUMP_INSTRUCTION’ undeclared (first use in this
function)
       ResetVector[0] |= ARMT_UNCONDITIONAL_JUMP_INSTRUCTION;
                         ^
GenFvInternalLib.c:2197:25: note: each undeclared identifier is
reported only once for each function it appears in
GenFvInternalLib.c:2254:25: error:
‘ARM64_UNCONDITIONAL_JUMP_INSTRUCTION’ undeclared (first use in this
function)
       ResetVector[0] |= ARM64_UNCONDITIONAL_JUMP_INSTRUCTION;

Also, after patching this manually to 0x14000000, I did not end up
with a working image. Perhaps you could share some instructions?

What I tried was the following:

 #

The idea is to wrap my top level FV in a CRC32 wrapper, and still be
able to boot it XIP
Unfortunately, the reset vector and PEI pointer are zero, and with
verbose output enabled, i never see any output related to the entry
vector. Also, in the debugger, it does not seem mArm ever assumes the
TRUE value.

Comments

Ard Biesheuvel March 1, 2016, 7:42 p.m. UTC | #1 
On 1 March 2016 at 20:36, Cohen, Eugene <eugene@hp.com> wrote:
> Ard,

>

> The incorrect DataOffset appears to stem from the "PROCESSING_REQUIRED = FALSE" statement.  Remove this and both the rebase and SEC/PEI core discovery should work.

>

> Perhaps someone with more background on why this flag exists can shed some light when it should be used and when it shouldn't (and why it's possible to break GUIDed section generation in such a subtle way).

>


Thanks for the analysis. It was my understanding that this flag needs
to be set to FALSE to indicate that the volume is readable directly,
i.e., without decompression etc, and this is obviously the case for
signed and/or crc'ed payload.

Anyway, I will give it another spin tomorrow.

-- 
Ard.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
diff mbox

Patch

diff --git a/ArmVirtPkg/ArmVirtQemu.fdf b/ArmVirtPkg/ArmVirtQemu.fdf
index ef456539cc62..9b1ecd5eb65b 100644
--- a/ArmVirtPkg/ArmVirtQemu.fdf
+++ b/ArmVirtPkg/ArmVirtQemu.fdf
@@ -67,7 +67,7 @@  [FD.QEMU_EFI]

 0x00001000|0x001ff000
 gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
-FV = FVMAIN_COMPACT
+FV = FVMAIN_SIGNED


 ################################################################################
@@ -280,6 +280,30 @@  [FV.FVMAIN_COMPACT]
     }
   }

+[FV.FVMAIN_SIGNED]
+FvAlignment        = 16
+ERASE_POLARITY     = 1
+MEMORY_MAPPED      = TRUE
+STICKY_WRITE       = TRUE
+LOCK_CAP           = TRUE
+LOCK_STATUS        = TRUE
+WRITE_DISABLED_CAP = TRUE
+WRITE_ENABLED_CAP  = TRUE
+WRITE_STATUS       = TRUE
+WRITE_LOCK_CAP     = TRUE
+WRITE_LOCK_STATUS  = TRUE
+READ_DISABLED_CAP  = TRUE
+READ_ENABLED_CAP   = TRUE
+READ_STATUS        = TRUE
+READ_LOCK_CAP      = TRUE
+READ_LOCK_STATUS   = TRUE
+
+  FILE FV_IMAGE = 4C4A9ABE-71E1-4D2E-8FF6-AA8801FEB9AA {
+    SECTION GUIDED FC1BCDB0-7D31-49AA-936A-A4600D9DD083
PROCESSING_REQUIRED = FALSE {
+      SECTION FV_IMAGE = FVMAIN_COMPACT
+    }
+  }
+

 ################################################################################