From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::344; helo=mail-ot1-x344.google.com; envelope-from=vladimir.olovyannikov@broadcom.com; receiver=edk2-devel@lists.01.org Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C826621144D10 for ; Wed, 19 Sep 2018 16:58:55 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id w17-v6so7631585otk.3 for ; Wed, 19 Sep 2018 16:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=EnfcBNS9ohB4zWqcOXf53fN3Y2e7tHVb3mwSitsExxk=; b=gFrJDFPgZA6ipJKKLQ16XOxu+wAnyuVSKQOqnUMVebwk+ysls7/Mht0V7Kpbk6CQRF 5eFflxFId0E6g3fFfcwbdSKdeVZRnM7JnPwu5AGakURKcoCLzP3c+Bcbf6EFyNcIPolZ D0meurVKK1JMQzR5y0cI7mLr4Q+61ynY8wxqU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=EnfcBNS9ohB4zWqcOXf53fN3Y2e7tHVb3mwSitsExxk=; b=rJdyHuc846SHGeeflt3yKp43axmqdQoQyo3MinPh3b4ArpErPKJ901DRJnU3gvPuzQ KkGH958t2CNOD7kmfq3xRQ1yfMo6clOd9ReqhoNNb6zCT5dhPOgtS8xUA1YQhYb0jHHj 2FKSWdkoGKJd6EXfnAqVVTvDYuSEbUvnkjzVmGn5dRMf4oYdWQnGq0pyU/FmqbPxXJlW WBTN8U6z1qwGcKJEAYlXUNrrOnpiMgy5LgnHomSQYn6iJhqpeDqEmFrWqhfaEEz4Kzxc fJnvXqs4YvfHgiizuriMLAIPcULZUsOrCcLZobVG3PxpB1I9ercuRahYDU93dpTXwgYp j8Jw== X-Gm-Message-State: APzg51BYNcFiNsUsCrrgT/ExAivWPkPIgdRbhFVGM7ZbPveLSeSCvFmY HL3/ij3bOG6crykO55XeP5gFbyqFkVSOQEuCgz1k9A5W8l8= X-Google-Smtp-Source: ANB0VdaHOWl4ifxTwVfQGcBobpoHX482olG2ONoPH6SEzX2joiIEXsNByyw6MKz/3pQsgBZnHlCcA4/GLUTmfJipkiw= X-Received: by 2002:a9d:209:: with SMTP id 9-v6mr21254049otb.228.1537401534177; Wed, 19 Sep 2018 16:58:54 -0700 (PDT) From: Vladimir Olovyannikov References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFMLJ9VLqvHxHUlXRLrPYZmgSToWQHe714LpfmVl0A= Date: Wed, 19 Sep 2018 16:58:52 -0700 Message-ID: <0203a14be46555436db1c8d5e58064ae@mail.gmail.com> To: Ard Biesheuvel Cc: edk2-devel@lists.01.org Subject: Re: Stack issue after warm UEFI reset and MMU enabling on an Armv8 platform X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Sep 2018 23:58:56 -0000 Content-Type: text/plain; charset="UTF-8" >From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >Sent: Wednesday, September 19, 2018 4:38 PM >To: Vladimir Olovyannikov >Cc: edk2-devel@lists.01.org >Subject: Re: Stack issue after warm UEFI reset and MMU enabling on an Armv8 >platform >On 19 September 2018 at 15:55, Vladimir Olovyannikov > wrote: >>Hi All, >>I need UEFI experts help on the problem with Armv8 board on warm UEFI >>reset. >>Cold reset works fine. >>Here is how I set up a warm reset: >>STATIC >>EFI_STATUS >>ShutdownUefiBootServices ( >> VOID >> ) >>{ >> EFI_STATUS Status; >> UINTN MemoryMapSize; >> EFI_MEMORY_DESCRIPTOR *MemoryMap; >> UINTN MapKey; >> UINTN DescriptorSize; >> UINT32 DescriptorVersion; >> UINTN Pages; >> MemoryMap = NULL; >> MemoryMapSize = 0; >> Pages = 0; >> >> do { >> Status = gBS->GetMemoryMap ( >> &MemoryMapSize, >> MemoryMap, >> &MapKey, >> &DescriptorSize, >> &DescriptorVersion >> ); >> if (Status == EFI_BUFFER_TOO_SMALL) { >> >> Pages = EFI_SIZE_TO_PAGES (MemoryMapSize) + 1; >> MemoryMap = AllocatePages (Pages); >> >> // >> // Get System MemoryMap >> // >> Status = gBS->GetMemoryMap ( >> &MemoryMapSize, >> MemoryMap, >> &MapKey, >> &DescriptorSize, >> &DescriptorVersion >> ); >> } >> >> // Don't do anything between the GetMemoryMap() and ExitBootServices() >> if (!EFI_ERROR(Status)) { >> Status = gBS->ExitBootServices (gImageHandle, MapKey); >> if (EFI_ERROR(Status)) { >> FreePages (MemoryMap, Pages); >> MemoryMap = NULL; >> MemoryMapSize = 0; >> } >> } >> } while (EFI_ERROR(Status)); >> >> return Status; >>} >> >>Then perform >>ArmCleanDataCache (); >>ArmInvalidateDataCache (); >>ArmDisableInstructionCache (); >>ArmInvalidateInstructionCache (); >These don't do anything useful on ARM. You can only reliably perform cache >maintenance by virtual address. So, should I just remove them altogether? >>ArmDisableMmu (); >... so after this call returns, all bets are off with regards to whether >what is popped from the stack is actually what we pushed when we entered >the function. OK, thank you for explanation. But this call returns back into ResetLib implementation as it should, and then there is a direct jump to the start of FV. Am I doing anything wrong here? Then, up to the point of enabling of MMU the stack is OK. But right after enabling MMU it points at _ModuleEntryPoint end of function in DxeCoreEntryPoint.c Am I missing anything? Maybe some stack cleanup before jumping to the start of FV? >>Then jump to start of FV: >>typedef >>VOID >> (EFIAPI *START_FV)( >> VOID >>); >>StartOfFv = (START_FV)(UINTN)PcdGet64(PcdFvBaseAddress); >>StartOfFv (); >> >>Now this is what happens on warm reset: >>reset -c warm >>1. Until ArmEnableMmu() gets called, everything works as expected. >> Here is the stack right before ArmEnableMmu() is called: >> ArmConfigureMmu+0x4f8 >> InitMmu+0x24 >> MemoryPeim+0x440 >> PrePiMain+0x114 >> PrimaryMain+0x68 >> CEntryPoint+0xC4 >> EL2:0x00000000800008BC >> ----- End of stack info ----- >> >>2. Here is the stack as soon as Mmu is enabled with ArmEnableMmu() : >> ArmConfigureMmu+0x4fc <-- This one is correct, at line 745 in >> ArmConfigureMmu() in ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c >> (return EFI_SUCCESS) >> _ModuleEntryPoint+0x24 <-- Wrong. This points directly to >> ASSERT(FALSE); and to CpuDeadLoop() in DxeCoreEntryPoint.c, lines 59-60. >> El2:0x000000008E5E8300 <-- Absolutely bogus >> --- End of stack info --- >> >>So, as soon as ArmEnableMmu() exits, execution jumps directly to >>CpuDeadLoop() in DxeCoreEntryPoint of _ModuleEntryPoint(). >> >>Would be grateful for any advice. >> >>Thank you, >>Vladimir