On 06/16/14 08: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.
Looks like a spectacularly bad idea. The C standard guarantees that any
pointer to a function, and any pointer to an object, will compare
unequal to a null pointer. On edk2 platforms, null pointers have
all-bits-zero representation. If you place an object at address zero,
then the above guarantee is breached.
> 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
(In the second line of each of these dumps, you can see
EFI_FIRMWARE_FILE_SYSTEM2_GUID. But this is just a side note, not
particularly important.)
>
> 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.
Please save your build log and upload it somewhere. My guess is the
following -- see "BaseTools/UserManuals/GenFds_Utility_Man_Page.rtf" --
GenFv is likely called with --baseaddr=0 (equivalently, with -r 0),
which leads the code to believe that --baseaddr has not been passed at
all. See:
$ GenFv --help
-r Address, --baseaddr Address
Address is the rebase start address for drivers that
run in Flash. It supports DEC or HEX digital format.
If it is set to zero, no rebase action will be taken
And/or, please see GenVtf ("generate volume top file") too:
$ GenVtf --help
-r BaseAddress, --baseaddr BaseAddress
BaseAddress is the starting address of Firmware Volume
where Boot Strapped Image will reside.
main() in "BaseTools/Source/C/GenVtf/GenVtf.c" parses the value into
"StartAddress1" and "StartAddress2" (which are set to zero initially),
and passes them to GenerateVtfImage(). That function checks for zero
values (at least in case of StartAddress2.)
GenFds (BaseTools/Source/Python/GenFds) seems to be a Python program
that invokes both GenFv and GenVtf, and it appears to pass "-r" to both.
The above are not the exact cause of course, but I think they illustrate
that storing the boot code such that the null pointer points to it is a
Bad Idea (TM). I'm not sure about the alignment requirements (word?
page?) -- can you try at the next "granule" above zero?
Thanks
Laszlo
------------------------------------------------------------------------------
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
