On 03/10/21 09:04, Jon Nettleton wrote: > I am debugging a failure that I am seeing while using the HoneyComb's > spi-nor flash for runtime variable storage. I am hoping someone on > the list can give me some insight as what may be the problem. > > The problem showed up when we switched the MMIO region for the fspi > flash device to be marked as non executable. reading variables is > fine, however writes began throwing an error. > > [ 556.709828] Unable to handle kernel execute from non-executable > memory at virtual address 00000000206a3968 > > I have patched the kernel and removed the X86 requirement and enabled > the sysfs runtime mappings kernel config so I can get an easy view of > the mappings the kernel carries for runtime services. I then track > that virtual address to the MMIO region of nor flash, which makes > sense that region is marked as non executable. The question is why is > code being executed from this address range > > attribute > :::::::::::::: > 0x8000000000000001 > :::::::::::::: > num_pages > :::::::::::::: > 0x40 > :::::::::::::: > phys_addr > :::::::::::::: > 0x20500000 > :::::::::::::: > type > :::::::::::::: > 0xb > :::::::::::::: > virt_addr > :::::::::::::: > 0x20680000 > > So then I patched the PL011 serial driver to be able to log to the > console in runtime and I track down the access to Status = > Fvb->GetPhysicalAddress(Fvb, &FvVolHdr); in UpdateVariableStore(). > What I don't understand is why EfiConvertPointer is mapping that > pointer into the Virtual address space occupied by the runtime mmio of > the flash. The pointer is being properly remapped. Here are the > pointer addresses in EFI and Kernel Runtime > > EFI: > UpdateVariableStore:156 ECE33968 > FvbGetPhysicalAddress(BaseAddress=0x20000000) > > KERNEL: > UpdateVariableStore:156 206A3968 > [ 556.709828] Unable to handle kernel execute from non-executable > memory at virtual address 00000000206a3968 > > Any insight that anyone could provide would be much appreciated.
Your platform appears misconfigured -- the flash MMIO range appears to overlap runtime services code even before SetVirtualAddressMap. The virtual address conflict is likely the result of the original physical address conflict. After the virtual address updates, the EfiMemoryMappedIO (0xb) type range is mapped at virtual address range [0x20680000, 0x206C0000). The GetPhysicalAddress function seems to be located at offset 0x23968 in that range (with 0x1C698 bytes to go in the range). That's inexplicable. What is the physical base address of the flash? What are the PCDs used in "ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvb.c"? Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#72629): https://edk2.groups.io/g/devel/message/72629 Mute This Topic: https://groups.io/mt/81222488/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
