That did the trick, thanks. Haven't tested to see if it works yet, but at
least I got a branch instruction at the start of the FD.
I think we're still in a position that we can change AArch64's layout if
loading at 0x0 is really a bad idea; as defined, there are two seperate NOR
devices in the early boot space, and we could make an argument to place
Tiano in the other one which would get it out of 0x0, but I'm not sure I
understand the logic on why this is necessarily bad; nothing says 0x0 has
to be NULL, especially when dealing with bare-metal programming. At least
on AArch32, the ISR table is at 0x0, which is always a series of branch
instructions.
On 16 June 2014 08:03, Harry Liebel <harry.lie...@arm.com> wrote:
> 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
>
------------------------------------------------------------------------------
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
