From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 D000A1A1E1D for ; Mon, 26 Sep 2016 00:13:33 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id l132so134711330wmf.0 for ; Mon, 26 Sep 2016 00:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BcsvK8NDxo8FIVgwomzkdmAgaoGigmjThqKVv4bS0lo=; b=MxFVS70xbI5tkyVGluc76eD9RHYCTZCTFVdoRJehAtTONXLLiArYILRe9EdyS4zhI9 6ktJ4i5UIX25hLx/HlI3B4t2ofLyPgMxZCsPVexhzS6myLDiA6OmyJO7DNAsbiuTiCMH GGQe5w/4fLA5VU+TmRv9fG+n8ERkcFN+KpBUVlk78xf4KeE3MBOV2d7wSI84gqpkW19V ckNFD41RGos5AAOrD6lQJZHRLPDEOTE/cl2tq1cEUMLbJYZ5Pi307vWKYuZgC9EVLuXA IF8RmNJrl5Td5pQFwaUYh9f4PZ+nonyi1xyfSahbRqeMSA2oA/VyUjF+iYawYoNUrK61 gpSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BcsvK8NDxo8FIVgwomzkdmAgaoGigmjThqKVv4bS0lo=; b=mZPgXbmKcxejV8K5BrqUvID7OeKKT47UtoivgjzXnjeJjN8EER+9pVrxtUp4BPfw3W a/qKF4oG99DDVbuW4rNfaKL7N2pPUQTobUzcUXys1aggVJ2ODMwFvzYj3fZb8i3I0xjp ON1nRybNM3hTDRbnEULGvCGpQdFe4+SAAhTgcHr9KeIBX69GbIHpoV+qWqdfSKsVDLo2 oAMO+18YBrkR6Z8+P6y7DKqWvQoNnUM5M+u9JwzyLKrtKRvFZwI80Iuz/PvOmoch1ZAo F5ETWbKh+lrY6SJUf6IWkJLOwsdRunBAhBYz2B1lzaFcCjewfANEBtMNTohXdZroXngs 7lOw== X-Gm-Message-State: AA6/9RlYP1Iz5Y/RwzCgFI3Dj1LNbFF27gARjZEyfLyxTUB8znZa1tRRohUS6ClI+Yf7pD1ambDxz58iK1KEyw== X-Received: by 10.28.207.129 with SMTP id f123mr2893509wmg.1.1474874012387; Mon, 26 Sep 2016 00:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.36.212 with HTTP; Mon, 26 Sep 2016 00:13:31 -0700 (PDT) In-Reply-To: References: From: Michael Zimmermann Date: Mon, 26 Sep 2016 09:13:31 +0200 Message-ID: To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Leif Lindholm X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: System hang when using SetMemoryAttributes 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: Mon, 26 Sep 2016 07:13:34 -0000 Content-Type: text/plain; charset=UTF-8 Ard, I have to mark the framebuffer as uncached, because if writes to it are cached, they don't instantly reach the underlying hardware. I'd have to manually flush the cache for that region every time otherwise. Isn't that the normal way? I don't think that any device would work with a write-cache framebuffer - I actually copied the code from the ArmVirt LCD drivers which do the same. Thanks Michael On Mon, Sep 26, 2016 at 8:35 AM, Ard Biesheuvel wrote: > On 25 September 2016 at 20:01, Michael Zimmermann > wrote: > > Hi, > > > > which side effects can SetMemoryAttributes have? > > I have a device where setting the framebuffer(which is part of DRAM) to > > EFI_MEMORY_UC makes UEFI hang later on(when already outside the lcd > driver). > > > > If I do the same on a memory range allocated with AllocateAnyPages > instead > > of AllocateAddress UEFI boots just fine(but ofc, the screen doesn't > work). > > > > Unfortunately I don't have UART on that device but I'm sure there's no > > assert because I configured DebugLib to reboot the device in that case - > > which never happens, it's just stuck when the console drivers(TerminalDxe > > etc) initialize later on. > > > > Hello Michael, > > EFI_MEMORY_WC is more suitable for a framebuffer than EFI_MEMORY_UC, > since the latter does not allow unaligned accesses, so any unaligned > store will crash the system. > > Since the framebuffer is in DRAM, I assume the reason for setting the > memory attributes is that the device is not DMA coherent? Could you > perhaps describe the hardware in more detail? > > -- > Ard. >