From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 7692081EFB for ; Tue, 24 Jan 2017 03:05:48 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id v186so108783846lfa.1 for ; Tue, 24 Jan 2017 03:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wckrX0TNgftPIBRCJQhgIEU4zenAaKJBxkwdrwGMmQg=; b=cBcDxo5TQ4h8NpHhE+wUL0bU18DFd84Y61FewbhRlYUDMwTDAHSdM1YS7jpgqQwXVN f/yvRXvtWg3bzBfZtEHMck/2XSzLXpM6cUspS9ENG/4hcwgzADDO2Ve2lKaA3T7ROTxt mjVy8nRQu6JgsPQ4HP50fLh0N2RpNo1/9l/s4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wckrX0TNgftPIBRCJQhgIEU4zenAaKJBxkwdrwGMmQg=; b=hB8vgIFAnj+LCnPDQZHyaRzrNCusF/G0rwyHFFKXtshliWZ1uPTASZES8Z/HkYcwwt hzN3Q5zwctb8fBa6M2YiPjTUiUGUdzXu2HpqhJg838jO65nbRJrW4UFSqg6xa02rdKHY /4ourYBMaCWQQKoylg5Mqwj/m1/06jI7eBODOcQc5G7iQ8SnFcNRLZSpzDwZvmEGV3mI GTCbMcEMzq9V9iRrwn8Ii3eJqhykFHWNBARNt7ZAG5js+c15vUOEM1kwGi2C4Rm+NYp8 qoXehln4p4hi4FseuEf+Gk/fVSBGUznMirET8yeeXFh+jySEcpZ+3oPp/UgrgawjzQfn r/+g== X-Gm-Message-State: AIkVDXKtee/vjRVIZQC43fN0/eNj9C3X9/KRjnv9PW5rB9Ud6qNvRgSHAIEgSCYpemGBXAo9caVmxpSHRmvNFg+5 X-Received: by 10.25.208.20 with SMTP id h20mr11441415lfg.150.1485255945941; Tue, 24 Jan 2017 03:05:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.207.72 with HTTP; Tue, 24 Jan 2017 03:05:44 -0800 (PST) In-Reply-To: <63991be9-816a-98b2-c3f8-e3cb3e86419c@arm.com> References: <1484782032-82342-1-git-send-email-daniil.egranov@arm.com> <20170119151307.GZ25883@bivouac.eciton.net> <6f842667-253f-57ce-cf76-a47ad464aa97@arm.com> <63991be9-816a-98b2-c3f8-e3cb3e86419c@arm.com> From: Ryan Harkin Date: Tue, 24 Jan 2017 11:05:44 +0000 Message-ID: To: Daniil Egranov Cc: "edk2-devel@lists.01.org" , Leif Lindholm Subject: Re: [PATCH] ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: Fixed crash on Juno R0 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 11:05:49 -0000 Content-Type: text/plain; charset=UTF-8 On 24 January 2017 at 02:19, Daniil Egranov wrote: > Hi Ryan, > > > > On 01/23/2017 06:56 AM, Ryan Harkin wrote: >> >> On 20 January 2017 at 20:57, Daniil Egranov >> wrote: >>> >>> Hi Ryan, >>> >>> >>> On 01/20/2017 04:30 AM, Ryan Harkin wrote: >>> >>> On 20 January 2017 at 01:34, Daniil Egranov >>> wrote: >>> >>> Hi Leif, Ryan >>> >>> >>> On 01/19/2017 09:13 AM, Leif Lindholm wrote: >>> >>> On Thu, Jan 19, 2017 at 01:49:04PM +0000, Ryan Harkin wrote: >>> >>> On 18 January 2017 at 23:27, Daniil Egranov >>> wrote: >>> >>> The Marvell Yukon MAC address load supported only on Juno R1 and R2. >>> It disabled for Juno R0 due to PCI issues on this board. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.0 >>> Signed-off-by: Daniil Egranov >>> >>> Tested-by: Ryan Harkin >>> >>> --- >>> ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 9 +++++++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c >>> b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c >>> index 47ff587..e9e6990 100644 >>> --- a/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c >>> +++ b/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c >>> @@ -378,6 +378,7 @@ OnEndOfDxe ( >>> EFI_DEVICE_PATH_PROTOCOL* PciRootComplexDevicePath; >>> EFI_HANDLE Handle; >>> EFI_STATUS Status; >>> + UINT32 JunoRevision; >>> >>> // >>> // PCI Root Complex initialization >>> @@ -393,8 +394,12 @@ OnEndOfDxe ( >>> Status = gBS->ConnectController (Handle, NULL, >>> PciRootComplexDevicePath, >>> FALSE); >>> ASSERT_EFI_ERROR (Status); >>> >>> - Status = ArmJunoSetNicMacAddress (); >>> - ASSERT_EFI_ERROR (Status); >>> + GetJunoRevision (JunoRevision); >>> + >>> + if (JunoRevision != JUNO_REVISION_R0) { >>> + Status = ArmJunoSetNicMacAddress (); >>> + ASSERT_EFI_ERROR (Status); >>> >>> This is just an FYI, but I stacked your patch on top of mainline, like >>> this: >>> >>> 5f81f61 2017-01-18 ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe: >>> Fixed crash on Juno R0 [Daniil Egranov] >>> 19ca06b 2017-01-19 OvmfPkg: Remove superfluous return statements. >>> [Thomas Huth] >>> >>> The first time I ran this, Juno R0 worked fine, but on R1 and R2, the >>> assert triggered: >>> >>> UEFI firmware (version 5f81f61 built at 11:56:52 on Jan 19 2017) >>> [snip] >>> ASSERT_EFI_ERROR (Status = Not Found) >>> ASSERT [ArmJunoDxe] >>> >>> /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(401): >>> !EFI_ERROR (Status) >>> >>> I worked out what is happening. And it's not to do with this patch. >>> It's another fall-out from the re-work you did to the previous patch. >>> It's also ultimately due to a bug the firmware. >>> >>> With the initial version of your "Set Marvell Yukon MAC address" >>> patch, this hang didn't happen. I suspect that was because your error >>> checking was weaker and certain PCIe failures didn't trigger the >>> assert. >>> >>> To reproduce the error with this commit: >>> 1) power on and boot R1 or R2 into Shell >>> I do this by interrupting the boot by pressing ESCAPE and using the >>> boot >>> menu >>> 2) At the Shell prompt, run "reset -s" to shutdown >>> 3) At the ARM Boot Loader "Cmd>" prompt, run "reboot" >>> 4) the board will hang while booting UEFI, assuming the board firmware >>> doesn't die with constant messages like this: >>> >>> ERROR: PCIe CSR read failed to respond >>> ERROR: SMBus transaction not claimed >>> >>> Assuming the problem is firmware, not EDK2, what should we do about it? >>> >>> OK, so instinctively, my reaction was that "the reset -s bug is a >>> system controller firmware bug and we shouldn't work around >>> it". However, since it is actually disrupting Ryan's workflow, which >>> frequently doesn't touch PCI at all, I think downgrading the ASSERT to >>> an error message is a good idea short-term. >>> >>> Daniil - could you make that change please? >>> >>> / >>> Leif >>> >>> >>> I've been able to reproduce "PCIe CSR read failed to respond" and "SMBus >>> transaction not claimed" errors on my Juno R2. I disabled Marvell Yukon >>> driver (.dsc/.fdf) and removed ArmJunoDxe patch but still see the same >>> error >>> messages during the initial boot. >>> >>> Testing motherboard interfaces (FPGA build 118)... >>> SRAM 32MB test: PASSED >>> LAN9118 test: PASSED >>> KMI1/2 test: PASSED >>> MMC test: PASSED >>> PB/LEDs test: PASSED >>> FPGA UART test: PASSED >>> ERROR: PCIe CSR read failed to respond >>> ERROR: SMBus transaction not claimed >>> ERROR: PCIe CSR read failed to respond >>> ... >>> >>> Once it went through reporting these errors, the UEFI starts loading but >>> still fails in OnEndOfDxe(): >>> ASSERT_EFI_ERROR (Status = Not Found) >>> ASSERT [ArmJunoDxe] >>> >>> /home/user/workspace/juno/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(110): >>> !EFI_ERROR (Status) >>> >>> This is the original ArmJunoDxe code: >>> Status = gBS->ConnectController (Handle, NULL, >>> PciRootComplexDevicePath, >>> FALSE); >>> ASSERT_EFI_ERROR (Status); <---- line 110 >>> >>> I'm confused at which point in the commit history this is line 110. >>> >>> Just before your MAC commit, it's line 108. After your commit, and in >>> the current mainline, it's line 394. >>> >>> Then, I have to go back to Jeremy's commit >>> 58a4bff071832e587d18f97597b5d571dcebc9d7 on 27 July 2016 before I see >>> another change to ArmJunoDxe.c. Before that commit, the assert appears >>> on line 116. >>> >>> On my tree, 17.01, 16.12 and 16.11 has the assert on line 246, 16.10 >>> on line 125. >>> >>> So I'm unsure what code you are running. >>> >>> >>> This shows the code where it fails for me after MAC address code was >>> removed >>> from ArmJunoDxe.c. It's part of my development branch and lines may not >>> matching any public commits >> >> You should consider switching branch to mainline when trying to >> compare and report problems with other people, then we have a common >> baseline to work with. >> >> >>> ... but i pulled 16.06 release for a test and >> >> 16.06? Why so old? What's wrong with 16.12? You are missing firmware >> updates and fixes by using such an old release. > > > I wanted to check how long this problem existed. Just picked up one of the > old builds. > > >> >>> see the ASSERT on the same code in case of "PCIe .." and "SMBus .." >>> errors. >>> The line number should be corresponding to >>> 032082bf9906f82b77c161c1c2efbddfd4bb3751 commit: >>> >>> ASSERT_EFI_ERROR (Status = Not Found) >>> ASSERT [ArmJunoDxe] >>> >>> /home/user/workspace/juno_16.06_orig/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(124): >>> !EFI_ERROR (Status) >>> >>> >>> but it actually fails here first: >>> Status = gBS->LocateDevicePath (&gEfiPciRootBridgeIoProtocolGuid, >>> &PciRootComplexDevicePath, >>> &Handle); >>> >>> Ryan - could you try to remove Marvell patches and check if you also >>> catching "PCIe .." and "SMBus .." errors without them and your build >>> still >>> fails with other ASSERTs related to PCI. >>> >>> Leif - in my tests, if it fails with "PCIe .." and "SMBus ..", the UEFI >>> PCI >>> enumeration is completely corrupted. >>> >>> These errors do not appear if board was reset with the nPBRESET button. >>> It >>> never fails with "reset -w" and "reset -c". I also loaded Debian and used >>> the shutdown command from there and got the same "PCIe .." and "SMBus .." >>> errors after "reboot" command from the "Cmd>" prompt. Possibly, the >>> "reboot" command from the board shell prompt does not reset the board >>> correctly so it looks like a firmware issue. >>> >>> Yes, that's pretty much what I've been saying. There appears to be a >>> firmware bug that causes PCIe to be in an unstable state after >>> software shutdown of the AP by the motherboard, followed by reset. >>> >>> The "PCIe CSR read failed to respond" error is nothing to do with EDK2 >>> and happens before EDK2 runs. >>> >>> However, unlike you, if I don't get the "PCIe CSR read failed to >>> respond" error, upstream EDK2 before your MAC address commit will boot >>> without ASSERTing on R0/1/2. >>> >>> >>> Do you mean, when you do have the "PCIe .." error ? As i understand, if >>> you >>> power-cycle the board (no "PCIe .." errors) you do not see ASSERT at the >>> MAC >>> address code during the first boot and can start UEFI Shell? >>> >> Correct. >> >> >>> So I've never seen the assert at line 110 as you pointed out above. >>> That's curious. I can see why that would/should assert, but it doesn't >>> for me. Perhaps it's something to do with the tree you are building >>> from? Or the devices you have connected? I have no additional SATA or >>> PCIe devices connected to my board. >>> >>> Cheers, >>> Ryan. >>> >>> >>> I am using R2 for the tests. The tests were done without SATA or PCI >>> devices >>> connected to the board. Unfortunately, I do not have R1 board at this >>> moment >>> to check it. >>> >> That's fine, R2 is good enough. >> >> >>> This is my R2 firmware versions: >>> >>> ARM V2M-Juno Boot loader v1.0.0 >>> HBI0262 build 1844 >>> >>> ARM V2M_Juno r2 Firmware v1.4.3 >> >> v1.4.4 is the latest Juno firmware. You should update. Although it >> won't fix these problems as it wasn't intended to. And as you used >> 16.06 for your baseline testing, I assume you probably also have old >> SCP firmware in your environment too. >> >> >>> Build Date: Apr 12 2016 >>> >>> MIC RAM configuration (pms_v105.bin)... >>> >>> Configuring motherboard (rev D, var A)... >>> IOFPGA image \MB\HBI0262D\io_b118.bit >>> >>> As Leif suggested, i will replace the ASSERT with an error message and >>> send >>> another patch. >>> >> Thanks, that's all we need to do, I think. >> > > Done. > >>> Could you please check one thing for me on your boards? Use a build which >>> worked for you (no ASSERT) and your steps: UEFI shell -> reset -s -> >>> reboot >>> -> see "PCIe .." and "SMBus .." errors -> boot UEFI. >> >> After I get the "PCIe .." and "SMBus .." errors, the board will never >> boot into UEFI. It hangs forever and I have to power-cycle the board. >> This rarely happens for me on R2. >> >> Sometimes, I do UEFI shell -> reset -s -> reboot and the board will >> give the "PCIe .." and "SMBus .." error, but most of the time, it does >> not and UEFI continues to boot. > > > Interesting, if i do reset -s, i am getting "PCIe ..." error and stop with > ASSERT error in UEFI all the time. > Funny, but while testing mainline [1] before testing your v2 patch, R1 and R2 both crashed after software shutdown with: ASSERT [ArmJunoDxe] /linaro/platforms/uefi/edk2/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c(397): !EFI_ERROR (Status) But even worse than that, at one point, R2 did this: Installation of the FDT using the device path completed. PCI: The size 0x7F000000 of the region 0x80000000 has been increased to be a power of two for the AXI translation table. PCI: The size 0x180000000 of the region 0x880000000 has been increased to be a power of two for the AXI translation table. Synchronous Exception at 0x00000000FDEC712C PC 0x0000FDEC712C (0x0000FDEC5000+0x0000212C) [ 0] CpuIo2Dxe.dll PC 0x0000FDEC6570 (0x0000FDEC5000+0x00001570) [ 0] CpuIo2Dxe.dll PC 0x0000FDE449CC (0x0000FDE41000+0x000039CC) [ 1] PciHostBridge.dll PC 0x0000F886A6B4 (0x0000F8864000+0x000066B4) [ 2] PciBusDxe.dll PC 0x0000F8867C54 (0x0000F8864000+0x00003C54) [ 2] PciBusDxe.dll PC 0x0000F8867C24 (0x0000F8864000+0x00003C24) [ 2] PciBusDxe.dll PC 0x0000F886CA08 (0x0000F8864000+0x00008A08) [ 2] PciBusDxe.dll PC 0x0000F88677A8 (0x0000F8864000+0x000037A8) [ 2] PciBusDxe.dll PC 0x0000F8865920 (0x0000F8864000+0x00001920) [ 2] PciBusDxe.dll PC 0x0000FE005F8C (0x0000FDFFA000+0x0000BF8C) [ 3] DxeCore.dll PC 0x0000FE005358 (0x0000FDFFA000+0x0000B358) [ 3] DxeCore.dll PC 0x0000F8A29D6C (0x0000F8A28000+0x00001D6C) [ 4] ArmJunoDxe.dll PC 0x0000FE0177B8 (0x0000FDFFA000+0x0001D7B8) [ 5] DxeCore.dll PC 0x0000FE016F38 (0x0000FDFFA000+0x0001CF38) [ 5] DxeCore.dll PC 0x0000FE005134 (0x0000FDFFA000+0x0000B134) [ 5] DxeCore.dll PC 0x0000FE0175C4 (0x0000FDFFA000+0x0001D5C4) [ 5] DxeCore.dll PC 0x0000FE0179C0 (0x0000FDFFA000+0x0001D9C0) [ 5] DxeCore.dll PC 0x0000FE017E68 (0x0000FDFFA000+0x0001DE68) [ 5] DxeCore.dll PC 0x0000FDDEDA34 (0x0000FDDE1000+0x0000CA34) [ 6] BdsDxe.dll PC 0x0000FDDFD534 (0x0000FDDE1000+0x0001C534) [ 6] BdsDxe.dll PC 0x0000FDDE3E70 (0x0000FDDE1000+0x00002E70) [ 6] BdsDxe.dll PC 0x0000FDFFC3DC (0x0000FDFFA000+0x000023DC) [ 7] DxeCore.dll PC 0x0000FDFFB4A0 (0x0000FDFFA000+0x000014A0) [ 7] DxeCore.dll PC 0x0000FDFFB024 (0x0000FDFFA000+0x00001024) [ 7] DxeCore.dll [ 0] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe/DEBUG/CpuIo2Dxe.dll [ 1] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe/PciHostBridgeDxe/DEBUG/PciHostBridge.dll [ 2] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe/DEBUG/PciBusDxe.dll [ 3] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll [ 4] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/ArmPlatformPkg/ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe/DEBUG/ArmJunoDxe.dll [ 5] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll [ 6] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll [ 7] /linaro/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll X0 0x0000000057F00000 X1 0x00000000FDECC030 X2 0x0000000057F00000 X3 0x000000000000001A X4 0x00000000FD434E98 X5 0x00000000FDEC64D0 X6 0x00000000F887A080 X7 0x00000000FDE4A4B8 X8 0x00000000FE02D690 X9 0x0000004100000000 X10 0x0000000057EFFFFF X11 0xC000000000000000 X12 0x0000000000000000 X13 0x0000000000000003 X14 0x0000000000000000 X15 0x0000000000000003 X16 0x00000000FEFFFBF0 X17 0x0000000000000000 X18 0x0000000000000000 X19 0x0000000000000013 X20 0x0000000000000000 X21 0x0000000000000000 X22 0x0000000000000000 X23 0x0000000000000000 X24 0x0000000000000000 X25 0x0000000000000000 X26 0x0000000000000000 X27 0x0000000000000000 X28 0x0000000000000000 FP 0x00000000FEFFF2F0 LR 0x00000000FDEC6570 V0 0x0000000000000000 0000000000000000 V1 0xAB1C5ED5923F82A4 59F111F13956C25B V2 0x550C7DC3243185BE 12835B01D807AA98 V3 0xC19BF1749BDC06A7 80DEB1FE72BE5D74 V4 0x240CA1CC0FC19DC6 EFBE4786E49B69C1 V5 0x76F988DA5CB0A9DC 4A7484AA2DE92C6F V6 0xBF597FC7B00327C8 A831C66D983E5152 V7 0x1429296706CA6351 D5A79147C6E00BF3 V8 0x0000000000000000 2E1B213827B70A85 V9 0x0000000000000000 766A0ABB650A7354 V10 0x0000000000000000 A81A664BA2BFE8A1 V11 0x0000000000000000 D6990624D192E819 V12 0x0000000000000000 1E376C0819A4C116 V13 0x0000000000000000 4ED8AA4A391C0CB3 V14 0x0000000000000000 78A5636F748F82EE V15 0x0000000000000000 A4506CEB90BEFFFA V16 0x3C83709547545153 BC990E9F897D4FA8 V17 0xBEBEF297C5EC0578 E1D99AE8C2B92607 V18 0x13242833C5F05BAB 101C24C521387481 V19 0x0A50ABCAD0BDDA12 996865483E880969 V20 0x6C4ABAA53A9BE1CB 4416D9F479B08221 V21 0x60952147C3A68574 55B8AE51435C1A1A V22 0x9FEB2A3B4AB8D3BF 88C1883495C7F76F V23 0xD0C224BC8FB77E09 3DB8D233CF470963 V24 0x0E72963E02D21C93 C95B757DA62B3A12 V25 0x2A77DBA1E4EE5D5C E08479A1B557DFA8 V26 0xB593F86668CA8129 927A0019CDEC1A76 V27 0xD000200000E00002 A6201000E0008C04 V28 0x8020000081000200 892080400880A022 V29 0x2085000000000136 801489A520002304 V30 0x0801200082040060 0384E05702949200 V31 0x4064084112940202 1000458804200800 SP 0x00000000FEFFF2D0 ELR 0x00000000FDEC712C SPSR 0x60000209 FPSR 0x00000000 ESR 0x96000210 FAR 0x0000000057F00000 ESR : EC 0x25 IL 0x1 ISS 0x00000210 Data abort: Synchronous external abort Stack dump: 00000FEFFF1D0: 996865483E880969 0A50ABCAD0BDDA12 4416D9F479B08221 6C4ABAA53A9BE1CB 00000FEFFF1F0: 55B8AE51435C1A1A 60952147C3A68574 88C1883495C7F76F 9FEB2A3B4AB8D3BF 00000FEFFF210: 3DB8D233CF470963 D0C224BC8FB77E09 C95B757DA62B3A12 0E72963E02D21C93 00000FEFFF230: E08479A1B557DFA8 2A77DBA1E4EE5D5C 927A0019CDEC1A76 B593F86668CA8129 00000FEFFF250: A6201000E0008C04 D000200000E00002 892080400880A022 8020000081000200 00000FEFFF270: 801489A520002304 2085000000000136 0384E05702949200 0801200082040060 00000FEFFF290: 1000458804200800 4064084112940202 00000000FDEC712C 0000000060000209 00000FEFFF2B0: 0000000000000000 0000000096000210 0000000057F00000 000000000000001A > 00000FEFFF2D0: 0000000057F00000 0000000057F00000 FFFFFFFFFFFFFFFF FFFFFFFFFFFFFFFF 00000FEFFF2F0: 00000000FEFFF350 00000000FDE449CC A831C66D983E5152 00000000FD434E98 00000FEFFF310: 000000000000001A 0000000057F00000 0000000057F00000 00000000FDECC000 00000FEFFF330: 00000000FD434E98 0101000000000000 0000000000000000 00000000FD434E98 00000FEFFF350: 00000000FEFFF3A0 00000000F886A6B4 00000000FEFFF3A0 00000000FD434E98 00000FEFFF370: 000000000000001A 0000000057F00000 00000000FEFFF3A0 00000000FD46C860 00000FEFFF390: 00000000FDECC000 00000000FD46C798 00000000FEFFF420 00000000F8867C54 00000FEFFF3B0: 0000000057F00000 00000000FDDB8018 00000000FEFFF400 57F00000F8879090 ASSERT [ArmCpuDxe] /linaro/platforms/uefi/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(265): ((BOOLEAN)(0==1)) Anyway, these problems are all due to dodgy lower level firmware, which should be fixed eventually. And your v2 patch removing the assert is out best way forward. Cheers, Ryan. > >> >> >>> As i understand, you do >>> not have the ASSERT with your old builds so you can start the UEFI shell. >>> Use the "pci" shell command to list all PCI devices. Do you see them >>> correctly enumerated? I'd like to make sure that by ignoring the ASSERT >>> errors we will not face any further problems with PCI. >>> >> In the case where my board continues to boot after software shutdown, >> the pci shell command shows this: >> >> Shell> pci >> Seg Bus Dev Func >> --- --- --- ---- >> 00 00 00 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 1556 Device 1100 Prog Interface 0 >> 00 01 00 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 01 00 ==> Pre 2.0 device - All devices other than VGA >> Vendor 0000 Device 0000 Prog Interface 0 >> 00 02 02 00 ==> Pre 2.0 device - All devices other than VGA >> Vendor 0000 Device 0000 Prog Interface 0 >> 00 02 03 00 ==> Pre 2.0 device - All devices other than VGA >> Vendor 0000 Device 0000 Prog Interface 0 >> 00 02 0C 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 10 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 1F 00 ==> Pre 2.0 device - All devices other than VGA >> Vendor 0000 Device 0000 Prog Interface 0 >> >> Which is not the same as when the board is power cycled. On power >> cycle, I see this: >> >> Seg Bus Dev Func >> --- --- --- ---- >> 00 00 00 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 1556 Device 1100 Prog Interface 0 >> 00 01 00 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 01 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 02 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 03 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 0C 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 10 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 02 1F 00 ==> Bridge Device - PCI/PCI bridge >> Vendor 111D Device 8090 Prog Interface 0 >> 00 03 00 00 ==> Mass Storage Controller - Other mass storage >> controll >> er >> Vendor 1095 Device 3132 Prog Interface 0 >> 00 08 00 00 ==> Network Controller - Ethernet controller >> Vendor 11AB Device 4380 Prog Interface 0 >> >> Cheers, >> Ryan. >> >> > > If I let UEFI boot to the shell after "PCIe ..." error, the pci shell > command shows me a long list of unrecognized PCI devices with all > combinations of BDFs. > > Thanks, > Daniil > > >>> Thanks, >>> Daniil >>> >>> >>> Thanks, >>> Daniil >>> >>> >>> Prior to your "Set Marvell Yukon MAC address" patch, or with the >>> earlier version, the board would boot anyway, but the Yukon device >>> would be missing. >>> >>> Now it dies. >>> >>> I don't know which is worse, but I think hanging is worse than an >>> ethernet port dropping out. Although hanging is a bit more obvious >>> that there's a problem... >>> >>> >>> + } >>> } >>> >>> STATIC >>> -- >>> 2.7.4 >>> >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >>> >>> _______________________________________________ >>> edk2-devel mailing list >>> edk2-devel@lists.01.org >>> https://lists.01.org/mailman/listinfo/edk2-devel >>> >>> >> _______________________________________________ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > > [1] mainline is this commit at the moment: 5734d48 2017-01-22 ShellPkg SmbiosView: Add decoding of SMBIOS spec 3.1.1 [Star Zeng]