From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 23E1F1A1E06 for ; Mon, 26 Sep 2016 05:44:28 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id w84so150028950wmg.1 for ; Mon, 26 Sep 2016 05:44:28 -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=y08APeetuYYtDrXsA1PMMDHVgsd5F1BkDT6DpCxCPcw=; b=mCPrnLBYRn0ux/A/NYdMlGUq+cKONpBoJyhoE3D5C3bUDBO4JtOIpl8PO1RJNk+mKy nSgQswm9b4sM5IZqC9WhLSRF3oYY7PAAide374Ampd0i9YcUb7FRrkaAFQUqBB/VbG4V sW/ALSUUXFsr1eIsjLv0B8c3+jVoJhuQ+ZxgucExAQtAt2oJxPx8lBd72dCKQr0C6mok wfjxoXZNdFhm1X72EqQRD0BguwUeS0a+a2fOj1oVj3Tq3n6LUt0ts78rcMNt/XwqU6bd zPW3k6PvIspPU6rYSDB1CCAKrxHO0SY8fknV+LFHLbnW4FUHAp4+zduEy2QdtCFFX9Th W74A== 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=y08APeetuYYtDrXsA1PMMDHVgsd5F1BkDT6DpCxCPcw=; b=m3OkHshp2b5t9gAicQn53bsyeZz++guqt4/FisFNQoAlPUFZTH7ZKbvS9GfJxx6nSH 0Twyv+zKqbTVWhnPEa6CB1BBKbnRcugOTSj9y7ERnYJp8EYGaEOCf3czJAycuXlZkhf2 1sFa8n3KrQHb8EO+rbNiVN2UeQ3aNWjDps5chqpiqer1JWMacJnzao/e3CKUTOzgdj7t GT8YBgh/ZKpOm78A2xiRvC8awAaroA2i/yBsOqAJBQQnG9MzyMWgYCF1jT5igiDW8gGZ f3VYVa54RclvDKpFCQWy2ig+uxsS4CrAbrjmIO4uLNSS3xtJFT1vx7Qv7qw17df/4uSM vmpw== X-Gm-Message-State: AA6/9Rlw0u+fWUQA5W5RmQ5MP+0/r3VCxDhEyvggH6beE019xmaUZfGyaQbrgmBb/BItwDUC9npDyVnnmNpYtg== X-Received: by 10.28.212.129 with SMTP id l123mr15856900wmg.22.1474893866601; Mon, 26 Sep 2016 05:44:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.36.212 with HTTP; Mon, 26 Sep 2016 05:44:26 -0700 (PDT) In-Reply-To: References: From: Michael Zimmermann Date: Mon, 26 Sep 2016 14:44:26 +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 12:44:28 -0000 Content-Type: text/plain; charset=UTF-8 I'm thankful for the hint about _WC because it drastically improves the speed on my other devices. Unfortunately, it doesn't fix the device I have problems with. I tested all possible attributes and only EFI_MEMORY_WB seems to be working(even EFI_MEMORY_WT is broken). The weird thing is that even if I disable accesses to the framebuffer by disabling all code in the Blt function, it hangs during boot. I really can't explain this behavior. On Mon, Sep 26, 2016 at 12:23 PM, Ard Biesheuvel wrote: > On 26 September 2016 at 00:44, Michael Zimmermann > wrote: > > oh and in case it makes a difference: it's a 64bit ARM device running > 32bit > > code. > > > > That shouldn't matter. > > > On Mon, Sep 26, 2016 at 9:13 AM, Michael Zimmermann > > wrote: > >> > >> 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. > >> > > _WC means write-combining, and so these accesses are not cacheable, > but they do allow unaligned accesses, unlike _UC >