Re: [edk2-devel] Alignment fault in __memcpy when SbsaQemu is built uncompressed

["Ard Biesheuvel" <ardb@kernel.org>]

On Sat, 22 Jun 2024 at 20:04, Rebecca Cran <rebecca@bsdio.com> wrote:
>
> I decided to do some testing around the cost of copying vs decompressing
> and moved all the drivers in SbsaQemu into the uncompressed section (as
> described in
> https://github.com/tianocore/tianocore.github.io/wiki/ArmPkg-Compression),
> but firmware built with CLANGDWARF causes an alignment fault when
> writing the last 64 bytes in __memcpy via FvReadFile -> AllocateCopyPool
> -> InternalAllocateCopyPool -> InternalMemCopyMem -> __memcpy
> (AArch64/CopyMem.S in BaseMemoryLibOptDxe).
>
>
> InternalAllocateCopyPool calls CopyMem with Memory=0x1000694d018,
> Buffer=0x10a71300, AllocationSize=274476.
>
> The instruction that causes the fault is:
>
> ldp x14, x15, [x4, #-64]
>
> Where x4=0x10ab432c
>

It looks like the FvReadFile() call is doing a memory copy from the
firmware volume (FV), which seems to be mapped with device attributes
rather than normal memory. With a compressed image, the FV will be
decompressed to normal RAM, so this can never happen at this stage in
the boot (BDS phase)

Looking at Platform/Qemu/SbsaQemu/SbsaQemu.fdf and
Silicon/Qemu/SbsaQemu/Library/SbsaQemuLib/SbsaQemuMem.c, the entire
flash device (FD) which should cover the uncompressed FV is mapped
with cacheable attributes, but the address in question ^^^ is outside
of the predefined window of

BaseAddress   = 0x10000000|gArmTokenSpaceGuid.PcdFdBaseAddress
Size          = 0x003C0000|gArmTokenSpaceGuid.PcdFdSize

Did you update PcdFdSize to account for the larger footprint of the FV?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119728): https://edk2.groups.io/g/devel/message/119728
Mute This Topic: https://groups.io/mt/106820121/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-