From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4AED7C433EF for ; Sun, 31 Oct 2021 22:48:44 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 48DDA60C49 for ; Sun, 31 Oct 2021 22:48:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 48DDA60C49 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 702D182982; Sun, 31 Oct 2021 23:48:40 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; secure) header.d=walle.cc header.i=@walle.cc header.b="YZub1u7D"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 96F2482D85; Sun, 31 Oct 2021 23:48:38 +0100 (CET) Received: from ssl.serverraum.org (ssl.serverraum.org [176.9.125.105]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 1CA048119C for ; Sun, 31 Oct 2021 23:48:35 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=walle.cc Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=michael@walle.cc Received: from ssl.serverraum.org (web.serverraum.org [172.16.0.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.serverraum.org (Postfix) with ESMTPSA id 7CC0D22236; Sun, 31 Oct 2021 23:48:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1635720514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=23HN/bQIlViLLnuiDyvpW2AH4M5PyEyoM9wia5i114Q=; b=YZub1u7DqT+WRtm38M0BXY4ZFbaK2q3IZVTGBAbtAJoSvA+HYRY0KLq2TCch0hOX15WlVB N5N9bVYIyE/s60xMVwMHl8W2twzUX/AKtUdUIc8xSV50tiRUmcVRUdOhpOu/+3o95GDdNu 6HkW/Xbc/ODuOgIha2TtMvtSRzkuJVM= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 31 Oct 2021 23:48:34 +0100 From: Michael Walle To: Mark Kettenis Cc: u-boot@lists.denx.de Subject: Re: (overlapping) lmb allocations during boot In-Reply-To: References: <63a9d684653e3d19e621a8d978f44113@walle.cc> <1f9f258db11b21bfd7db4fe1eef785eb@walle.cc> <8fe295d14b6d2db9604f8ec72bdfde4b@walle.cc> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <5ac4e40923091023c96f6536790ba67a@walle.cc> X-Sender: michael@walle.cc X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Am 2021-10-31 18:36, schrieb Mark Kettenis: >> Date: Sun, 31 Oct 2021 16:19:56 +0100 >> From: Michael Walle .. >> >> > Unless CONFIG_EFI_LOADER is defined. Then it relocates the spin table >> >> > to memory allocated using efi_allocate_pages(). But that function >> >> > only looks at the EFI memory map to figure out what memory is >> >> > available. So I suspect that it might hand out the same memory as >> >> > lmb_alloc(). It all looks a bit broken to me... >> >> >> >> Yes, that is actually my code ;) The kontron_sl28 is the only >> >> board which uses spin tables as far as I know. It doesn't support >> >> PSCI; at least if you don't load a bl31 TF-A. Therefore, for SMP >> >> it uses spin tables. The relocation code work arounds a problem >> >> with the reserved EFI code, see [1]. >> >> >> >> And yes, it actually is broken. But so might be every code which >> >> is using the efi_allocate_pages(), no? LMB isn't global, but is >> >> just initialized at different places. Like before a linux kernel >> >> is booted or when you load a file (?). And everytime the whole >> >> memory is added, and then different regions are carved out (see >> >> above). >> > >> > Right. So it mostly works because U-Boot either ends up using a code >> > path where it uses LMB or a path where it ends up using the EFI memory >> > map, but never both. Except if it hits your layerscape code. >> > >> > I think the right way to solve this is to allocate the memory for the >> > spin table through some other means and use efi_add_memory_map() to >> > reserve that memory like what is done in board/raspberrypi/rpi/rpi.c. >> >> Mh. I don't think this will work, just because lmb is quite stupid >> and has just the three steps to carve out memory: >> (1) arch_lmb_reserve() >> (2) board_lmb_reserve() >> (3) boot_fdt_add_mem_rsv_regions() >> >> (1) will carve out u-boot code and data (2) is usually not used and >> (3) doesn't really work IMHO, because the reserved regions are added >> much later in the bootm flow. >> >> So what would "other means" be? I could allocate the memory somehow, >> but how can I communicate that to lmb, so it would be excluded there. > > It could be a simple: > > memalign(PAGE_SIZE, PAGE_SIZE); > > This would allocate memory from the heap which should be excluded from > what lmb hands out. Thanks, that was easy ;) Turns out the heap is between the stack and the uboot code which is reserved by lmb (arch_lmb_reserve()). -michael