From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 1CBC081C73 for ; Thu, 19 Jan 2017 13:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v/vNvxw4dJedQsuO1zbFWcujRlGORbeetsGZ+3ZzBDM=; b=YT8auxDzGd1x1Ah79BCeo+ZTolRj2YuN8ijSEPi3u2S9gkZHQtRv8QOeg7lxIXX3CuopXQ+SEvXmVGB2NpOoNCjWAB/V8SwKd9u0LyagUhOVtMsqaRtKC2yxZLD/uQwF6pj5ezgRlnkJW+zsi83VVPeyu1XuFsuwRC5TpC+6apw= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Achin.Gupta@arm.com; Received: from e104320-lin (217.140.96.140) by HE1PR08MB1193.eurprd08.prod.outlook.com (10.166.96.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 19 Jan 2017 21:57:15 +0000 Date: Thu, 19 Jan 2017 21:57:32 +0000 From: Achin Gupta To: Ard Biesheuvel CC: Leif Lindholm , "edk2-devel@lists.01.org" , , Supreeth Venkatesh Message-ID: <20170119215731.GE4132@e104320-lin> References: <1484771046-21296-1-git-send-email-achin.gupta@arm.com> <20170118220500.GW25883@bivouac.eciton.net> <20170119123135.GB24076@e102648.cambridge.arm.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: AM4P190CA0010.EURP190.PROD.OUTLOOK.COM (10.172.213.148) To HE1PR08MB1193.eurprd08.prod.outlook.com (10.166.96.17) X-MS-Office365-Filtering-Correlation-Id: 01fd26cb-8849-4c6a-e788-08d440b621ba X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR08MB1193; X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1193; 3:LMM0jBsos3G3KH8P/+7NeesbO3L7y/PXVjSs9KvifAQwSB7yREQnWiZ5hWEBuwl6HUDZa0BelhcwOIBXedynDm43xVcPXtuhMsejEA0LBWdRancGTdV5AoIR1ejUv6WUELlSE0KkGmHw18oGQk6WfQafg8pNsQY9VoqEcrKNqCffoyW4qHOaX/UvOza9WgYeu+LOVKa4D3NwPle7QwmP3uV/DEkPccgZx7+7N9qJWt3mn1S1/vA/VEbeKmurmdWFuKzOyyFC0jzvmIeYp2g2XA== X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1193; 25:dA8sS44whgzie7WAmVUFgIDGIe4PvTn+sbbAtFP9xV0LoXvoGFTChnRUgDnA8NUJOGkOpA4T9g3i48tNQy3cDQmBWQkFgHqB0hdtvxnMt7xDfEPuOn80YGBERgj6LHRFWiupDXGkg4rdHFBBrVB/NPc6KILPrjcFdNhoSfpiilYQPWJ8vzykkzTWaPNEubVmCEElNZWW23hDU/62vCVqQEjLuS3Mg6ADMedze562FmlvPuwcMhhjApcYprv7zDv4z08dYY5HracznOQzBDArathfhIkAJ+MdJpsv8HIOi+Ot50wJiK1OPXkM9nfWmvIwnAyG+HEgE8t58HW3P50wvdHbLYO1kJoqi+qbpEYAlZvxElxwoBVN9JrQ007fiYJ/5FI0gm9HsdekR1m2iR7Hcf1TR/B7Q+hvNeNFU+g46k7jmVCmorDhmZR3zmAxa/fNkviumAcW87b9VC02l5cgXhC2FYRJpN7gJHRtJCaa1L87eeleDN7jR7NvWlkCWzI8LXGnTRJOAJiBsojlTZvPNJmmTgVypLbbNTZdTRGbM48AWGYiG49YeOgr29teWNbYOw5QDGkV2mhCYDFPUUz3D9VC49SDDOupsyNOjPKguDpCCGnXRf5AvspoVM8cGMt57+OusLj5LEjFQNUT1gXP6LrQFdCh7iinXqOoHt+CBu3Rxig2OtXinOVuSNKcd1ixQKETuaiWaB5UEc+qT4ZJo/3vvJc5mSCf/Cy6UUlSsTFJIs2PvjEiJbEb6AL8gKyaxopuIrN7SMZ6o2/aw5Q6VXasoMrfjrw5FHFlOMZvpkpfZQbSgfS+yVu9e+HOIPC16h92uwuWQpApUvNQoU8i5gzVdeGtgoCx+eoZJQFH82UOt1fnM/9DTYwuhtqf4Eh3RGwkCAytek2Vr7CRjH4ZHg== X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1193; 31:/JXn99SbruTkymJDlW7WZ4ScKy5yPksUVy/cF52mn5WKAqqp4H4KQRGnxW+AVS2n74RASR8Tr5KjaomsgWG+Z51UOmCenXq+IiVO5PawEM45AqA50XTXmcNQDZRNlm6s3bAIexDdE2p1UjXQ74PR1GqDwWzwI1O8ckjQDGgIcWMTuohL393vNRrEKvSskF9bWfmieLhrR0BBadXePrcO7XzKbhlK4cbauRpJRsEYeL4nT8gv2gUfqMuV6LyR1lWzzMFeWfcsqqRZBOjS1nM6MA==; 20:0UcLMYaqtyWK6V3XPxoj5VAN43f9GAZ/HYgbJWgRfUb/HI41jT6KKy7S7peVHG/ZYHGYX40aMIKK4Ca2zCIMniivfCF1RHnwA772CXBaGIak8Kg9J3n17gWStxWBMdsO6JtbPo8cJ3M0HTj5MV3EHk50rl+CWrKmj2fMSujWGio= NoDisclaimer: True X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6042181); SRVR:HE1PR08MB1193; BCL:0; PCL:0; RULEID:; SRVR:HE1PR08MB1193; X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1193; 4:Wm3OuOTAy2JuicxhsO7ULMBk12g99/q7rDjLub7t3kNig+ZKoVowDdRwFfxsCjy0BRkG0ODCMKgtps4uN2+TwSaRTpYJ/9mpAruXiQDEYsbJ0YtjWWpMCCbnSTSgBnU2FqTX7LrLk+sYbbKN853VaE8IKYXqynbyFqUL9DAC3vWU+MPjVEifTjWrOTqzWBTA0TA014oVaX66N+aejB1seSuTPjavKUnAqKq/6TfL708O2Oy1DUzqESaHjw8YBn8078wSlmkO/e6VhWfGV5ywZHHqwPSa3ELj3Jw7QFRUJhNZnroUNn7yiR8g/lYOW3LZbDIMnQB3tYMbHU5eAEbDqdlpIfHP9cZUTBCVE4zL5+1zJH6q/dtFXh6BENSlQxpE9vPcOPdo4NInnaT2NQyxWWcqavwT8N1lpj7Tz16qpY+g884QOX8NdsJdC0E1TfdRJdcSWGXHvcC2K9FyzrAi/Yr83kkwbgI6Wl4ktm3ICWTzaLboF63dfbBB7ZP/FeNAlmFsoUwTTVJ0TAJ1+cDAt+KJ2wGSROtLWCaCmef0OiRBjglPQexdMn4+hxwG2k65ryLTtOe4g471sSpV+43z/EoCkDZOYcv8sTUeFGZ4uuqttjultxauJMNYZxfp5ODxyr2yDfun2eKWc2V+vdrA9RqfvEt3mX9sYXihWebIP6EP0scDZH6G0JaLKWZaNziI X-Forefront-PRVS: 0192E812EC X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(6009001)(7916002)(51914003)(24454002)(189002)(199003)(2906002)(42186005)(25786008)(68736007)(189998001)(305945005)(106356001)(105586002)(81166006)(4326007)(50466002)(53936002)(81156014)(93886004)(3846002)(1076002)(5660300001)(83506001)(6116002)(86362001)(575784001)(23726003)(97756001)(8676002)(101416001)(229853002)(54356999)(50986999)(76176999)(2950100002)(38730400001)(9686003)(47776003)(33716001)(92566002)(55016002)(110136003)(33656002)(66066001)(6496003)(97736004)(6666003)(4001350100001)(7736002)(6306002)(46406003)(6916009)(54906002)(18370500001)(107986001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR08MB1193; H:e104320-lin; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR08MB1193; 23:sSKHThPs+YpHCasa1sBxcxw29dQSppGzCKRAG1mIQ?= =?us-ascii?Q?hFzqK8AWc3w3wPTGJKpN+kmUuBnn1Q/Mc7nhYZ+p0jG94c5jV0Nv0G/KQtGp?= =?us-ascii?Q?Lp+NyBEHaVHyqnk2R0SOJVDKxEjEDZyy2CIpJB3CSAc5i6kvq8CninQ357X2?= =?us-ascii?Q?PvzSzdO3+o4WbC5g2o9L0z5mD735zlOW7LhCKTtkH+vkhDbun12QXy9/yCTd?= =?us-ascii?Q?0//Ygdv+hadzMuS7vEVhjTr/c2XB+nSbfzmTmd/xCoyc2etaZRzqvOFfbUon?= =?us-ascii?Q?aVqQUlW/ZADeDqxo3KgnsYDN+mnpctkK83GzXkXobG81P1A17ZBjVG+l/6it?= =?us-ascii?Q?NksOgbGmfQusB5rQtcnWf0VjD7+EMrEsCQob6puNQLajM1YrPnkVpSj0rcEp?= =?us-ascii?Q?eX3vw/Tm/UKKtwNaSBmF9JAe10oRBviqLQ82Znp79nCZPq4V2HeQnVJoSPuv?= =?us-ascii?Q?9AzE9bOjg3clBKnrodD0dejGy3HOQRtF4mSnqSPJILbRleAjaMNWdOGsBanD?= =?us-ascii?Q?bV4bLsVMbvNTqoYW2aF9mxTB6LqLg2nUwdv/Ipi0xveeHN8dI7I0U/TIdo3j?= =?us-ascii?Q?pPLUEI1txmCJGZW4xFr96pw7xsLVwEhxAdsceFUtMUHeUp9MXdFiGLT4trIj?= =?us-ascii?Q?FkJm/96dIFsjpg7Jtkc86IM02BFsSNPTZgLNHx5CHCfF5ri03qXx4kpJtCEr?= =?us-ascii?Q?emoxZTy3CZUMc/MOWZ8EaKAwoF6y7Ts8Mg1OB4hBMq1Ap0BLrkrsdywOOs+f?= =?us-ascii?Q?08O5pLS6hFdlf2PCBQvA496maYN84aAMT6lZvUa2PBNW2HgLpKQseGW86uMz?= =?us-ascii?Q?Oy0Laa38kgslbxDL0XxQn4cG5l6xvj0750HaLhO5aVFIf85ybND0yOQFAAiF?= =?us-ascii?Q?xYjJ23mAKABHHpjQhUNJnKuYrCEwcpfLQ+IuOW/0NTLX+/JezPRoe1ltAp4D?= =?us-ascii?Q?s5iD9MihTwbwbJhglPGqiFyagPnhEA2T85TuZ56o6ZFY/eKJLWXHLx71FqsJ?= =?us-ascii?Q?a49BFjrWBQcqwIsJkV0Et7vwuVpu/Knip8l0or96voXOKDvv+x4quo+VE7kL?= =?us-ascii?Q?MQlLVZqkL9wmCmhzDgWfedxh1s1tGHgwg6hg8mH7ZEFK4X4cqIahba/loiKA?= =?us-ascii?Q?FpXSab/9I059Duv9OqlParkPAz/pX5qbSNoFfy0oA5X6GIvvJVKUT6vIPj9D?= =?us-ascii?Q?qSE1n2MUgkBY5AC5GyHp2chpoC2FBaUHNXW1NIhTN+mh6BrY3oLFfqIoUrVT?= =?us-ascii?Q?xe1utcYCQOWSybAlsfR8SpCp4S+y2E2PSP7rkvc/HTKf42LnAaPBPnbNQp8s?= =?us-ascii?Q?y5Ho0JmM4ArDAZQBYPlco17QGPB31NQ8XcO26R3Oe5caT2rVjgVzpyx/hpKX?= =?us-ascii?Q?DCokEHuSYafYofzMB7l6Kht50E=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1193; 6:lPVEmmI2425PLK6hDwPVJAUU7hN/Hp2rnFJGLV9xEmh3/0IBZ1eb+5I4iXZmONp3d7p5y1n2ym3TNMB20pS/6su4suwykoSirlxfdJMpVKiO9ZKyuL04oKh7gkYSkR1IBWPIm51ZTRxTefjCUyC/1qPKZq50WOJopZPudbRT/WxdKOcxZsao0lRlIXF9PLe4gbBxB7sp34MMyaEAfLO+poQTbxbMvPE2Zsy/PhwiBDE2aGMi5JaXTFOoh6x8ZAA2DIkxPXg4WgGI9kjr+vrj+nprX7hoo9+EuHSZvlamQJNUaaSU57+6t/WwOM93OZPb7yvI1iC5yL5YfSdUowyTc+mM75+lKKMi15zxsdfaxupU8dRFpeU52Fz9XJ9FlfsRW7SMHpboGmdmVeP4zLSjOMkcuee7oMlkpnE0w0eoISidS02y9SX5bWJ3dJX29nQ8B0CQyqC6wdLMj/QtU/lbeg==; 5:mZKTyNj+b/Q2yPtPKYQxDLpIpc30HgGsTD6baP99gZ4eU6SsBznvZ6UYyRp/eIVCHBWbbJ+uF2DLZqTvl45D4sLYB4XhGD6q7R7KSAyh3eRv+cMZNUR5EVvef5qfCU/lwZzyd6Qm4Z9q9xdz3kLQcw==; 24:ja0VMYRZfba/gN9ZMCYpxXakSREpS4+m01zSuqJWlFxammwc9eMyyN+Y4/lRjtMlt1gHZzqDqAD2Nnbg9jJA0tEE0RJgDqYJHzQXdKwwXaM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR08MB1193; 7:s78FCZbAsighuoBqSiUvairMhdb4yNWAV4N3WcMKT3IXw09e/L3NSbERQe+Z9fvkZcIuJin99sIXYOD16NxIwgUg8r/wGYdMAfeBxwzxiqikdtmJEL8F+xP0oQBB/mlPuJLdGDOwvPCpO8T9XAwjfYmTjkFCpp0RN4vx5DkQa0kX41Yab01Yiz6C3zKRREn+64s86zD/F3ma4zdzVGEOnCtOKxDzTBwlLznzBxaDRUHYm+AOAMh/8hAjqQ//zRs9BL8UHPGIkEP2jOQsfbKekSgFOv91i/EDP4jN9ofEwzNJDCm1oVlSMQ71iGQWVZDzF6BplZW85a1YT3dt3VI/6dHUasxZfXbvkUMh/Ck87vVNdR9tVCTKT6bBwRmD0dUUQuzgJQy8d5tczQyBiO0cR79C8I5IU5B/xLe1KCZRrhyCQ/cqDirQR8Ipj8alXGkgEihVwHzgYqzv7u0VZUHrnw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2017 21:57:15.6602 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB1193 Subject: Re: [PATCH] ArmPlatformPkg/ArmVExpressPkg: Fix memory attributes for NOR Flash 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: Thu, 19 Jan 2017 21:57:21 -0000 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Hi Ard, On Thu, Jan 19, 2017 at 06:16:00PM +0000, Ard Biesheuvel wrote: > On 19 January 2017 at 12:31, Achin Gupta wrote: > > Hi Leif/Ard, > > > > On Wed, Jan 18, 2017 at 10:05:00PM +0000, Leif Lindholm wrote: > >> Hi Achin, > >> > >> On Wed, Jan 18, 2017 at 08:24:06PM +0000, achin.gupta@arm.com wrote: > >> > From: Achin Gupta > >> > > >> > The NOR flash banks were being mapped in the translation tables with the same > >> > memory attributes as RAM in the system. These attributes mark the region as > >> > Normal Memory and could additionally be cacheable or non-cacheable. > >> > > >> > Either type of attributes are unsuitable for NOR Flash since write operations > >> > could be performed on it. Normal Memory does not guarantee ordering of > >> > transactions that Device memory does. So the commands sent to the Flash device > >> > may not arrive in the right order unless barriers are used. Commands might not > >> > get past the CPU caches in case the region has been mapped with cacheable > >> > attributes. > >> > > >> > This patch fixes the problem by mapping the NOR Flash memory region with Device > >> > memory attributes. > >> > >> To add some background to Ard's comment - this was not unintentionally > >> done: > >> https://github.com/tianocore/edk2/commit/19bb46c411279dcd30d540c56e5993c5f771c319 > > > > Thanks! I missed this commit. There is some background to the problem I am > > facing below. > > > >> > >> Was the reasoning behind this commit incorrect - do you have a > >> (pre-DXE?) use-case that creates a problem? > > > > AFAIU, The current memory attributes for NOR Flash work only for reads. They > > should additionally be RO to flag any unexpected writes. > > > > Mine is a DXE use case! In NorFlashDxe.c, commands are send to the Flash (erase > > block etc.). They might never reach the device if there is a write-back cache in > > between. So either device or Normal memory with non-cacheable/write-through > > attributes and barriers should work. > > > > If I turn on cache state modelling in the Base FVP, the code gets stuck in > > NorFlashReadStatusRegister() in the below loop in NorFlashEraseSingleBlock(): > > > > // Wait until the status register gives us the all clear > > do { > > StatusRegister = NorFlashReadStatusRegister (Instance, BlockAddress); > > } while ((StatusRegister & P30_SR_BIT_WRITE) != P30_SR_BIT_WRITE); > > > > I think the SEND_NOR_COMMANDs at the beginning of the function get stuck in the > > cache. Changing the flash memory attributes as per this patch solves the > > problem. > > > > The original patch from Ard mentions that the NOR Flash DXE driver should change > > the attributes of the region it wants to write to. Is this what is missing? > > > > NorFlashFvbInitialize() in > ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashFvbDxe.c contains the > following calls: > > Status = gDS->AddMemorySpace ( > EfiGcdMemoryTypeMemoryMappedIo, > Instance->DeviceBaseAddress, RuntimeMmioRegionSize, > EFI_MEMORY_UC | EFI_MEMORY_RUNTIME > ); > ASSERT_EFI_ERROR (Status); > > Status = gDS->SetMemorySpaceAttributes ( > Instance->DeviceBaseAddress, RuntimeMmioRegionSize, > EFI_MEMORY_UC | EFI_MEMORY_RUNTIME); > ASSERT_EFI_ERROR (Status); > > which is supposed to set device attributes on the NOR region that is > actually exposed to the upper layers as read-write capable. > > Perhaps you can enable GCD debugging to trace these calls, to ensure > that the address you are stalled on is actually covered? Thanks for the pointer. Somehow NorFlashFvbInitialize() gets called and a valid firmware volume header is not found. This irrespective of the state of cache modelling. The function proceeds to install a header for which it first tries to erase the Flash blocks reserved for variable storage. I am not sure why a FV header is not found. However the flash erase in response happens with the pre-DXE memory attributes for the flash region. The GCD services to change the attributes are called later. So this seems like a logical error in the code. Does this make sense to you? Here is the trace for reference. The last print was added by me. >>>> add-symbol-file /home/achgup01/work/genfw/uefi/edk2/Build/ArmVExpress-FVP-AArch64/DEBUG_GCC49/AARCH64/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe/DEBUG/ArmVeNorFlashDxe.dll 0xEAEA0000 Loading driver at 0x000EAE90000 EntryPoint=0x000EAEA0044 ArmVeNorFlashDxe.efi NorFlashWriteBlocks: informational - Had to enable HSYS_FLASH flag. FvbRead(Parameters: Lba=0, Offset=0x0, *NumBytes=0x40, Buffer @ 0xF3FFF8A8) NorFlashFvbInitialize ValidateFvHeader: No Firmware Volume header present NorFlashFvbInitialize: The FVB Header is not valid. NorFlashFvbInitialize: Installing a correct one for this volume. FvbEraseBlocks() FvbEraseBlocks: Check if: ( StartingLba=0 + NumOfLba=3 - 1 ) > LastBlock=2. FvbEraseBlocks: Erasing Lba=0 @ 0x0FFC0000. NorFlashEraseSingleBlock: BlockAddress=0x0FFC0000 >>>> Any pointers on the absent FV header and how NorFlashFvbInitialize() gets called would be helpful. cheers, Achin