On Sat, 22 Jun 2024 at 20:04, Rebecca Cran <rebe...@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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
