Hi Michael. I think what you are really looking for is the 'Force rebase' option that goes into the fdf file. It is a workaround in the Basetool as it normally skips some image creation operations if the image Base address is set to 0x0.
So in your fdf file you can try something like this (taken from the ArmVExpress-FVP-AArch64.fdf): --- [FV.FVMAIN_SEC] FvBaseAddress = 0x0 # Secure ROM FvForceRebase = TRUE FvAlignment = 16 ERASE_POLARITY = 1 --- The 'FvForceRebase' option forces the tool to process the image even if the base address is set to 0x0. To answer the other part of the question. The initial jump instruction lives here: BaseTools/Source/C/GenFv/GenFvInternalLib.c : UpdateArmResetVectorIfNeeded() Regards, Harry On 16/06/14 07:14, Michael Casadevall wrote: > Hey all, > > I've been working on porting TianoCore to KVM on AArch64, and I've > recently run into an issue which I'm hoping someone can help me to > debug. Recent proposed changes to KVM place the address space for > BootROMs and persistent storage from 0x0-0x8000000, with the early > boot code for Tiano startng at 0x0. My problem is that when the FDF is > set to generate an image for this load location, it appears to create > a malformed FD file. > > Under normal circumstances, the very first bits of the .fd file are a > branch instruction to the start of the PEI. This generates correctly > when the FDF is set to any BaseAddress that != 0x0. > > For example: > > Here's a known good image > $ hexdump > Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head > 0000000 01e2 1400 0000 0000 0000 0000 0000 0000 > 0000010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d > > The same code, compiled with my updated FDF generates the following: > $ hexdump > Build/AArch64Virtualization-KVM/DEBUG_ARMLINUXGCC/FV/KVM_EFI.fd | head > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > 0000010 e578 8c8c 8a3d 4f1c 3599 6189 c385 d32d > > I've tried and failed to locate the code responsible for writing out > the initial branch statement, so I'm hoping somewhere here can get me > a pointer on where to look. The relevant bit of my FDF is inline below. > > [FD.KVM_EFI] > BaseAddress = 0x0000000|gArmTokenSpaceGuid.PcdFdBaseAddress # KVM > assigns 0 - 0x8000000 for a BootROM > Size = 0x8000000|gArmTokenSpaceGuid.PcdFdSize # The > size in bytes of the FLASH Device > ErasePolarity = 1 > > # This one is tricky, it must be: BlockSize * NumBlocks = Size > BlockSize = 0x00001000 > NumBlocks = 0x8000 > > As best I can tell, GenFds appears to be the relevant utility, but > nothing in the code jumps out as relevent, and I admit I'm completely > unfamiliar with this area of the tree. > > Thanks in advance, > Michael -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
