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 A8EF4C433F5 for ; Sun, 31 Oct 2021 10:43:48 +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 8A71160F9E for ; Sun, 31 Oct 2021 10:43:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 8A71160F9E 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 243E78187B; Sun, 31 Oct 2021 11:43:44 +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="h0bI/GzV"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D683583273; Sun, 31 Oct 2021 11:43:41 +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 C67FB815A8 for ; Sun, 31 Oct 2021 11:43:38 +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 5E4BD22247 for ; Sun, 31 Oct 2021 11:43:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1635677018; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=FJc6xwtJlB/ZkmxpS0RK4E4+E26u2nHMxfTJ3P2bOEw=; b=h0bI/GzV4V8WpHZYX+HorP/Y9InOciJ/PPseGMXB0sokuneFKzO/FiC9yFgcB/jBjHOu+0 sGNT79ofdVWvWh6AmuFqbnVd2o6+YQNwmJkLy0EGQxQ2dZ0mkEfXblSSVuJZbw5oi45amJ Weh5gcZgu6/LGaIAq51S5FWUUljDijA= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 31 Oct 2021 11:43:38 +0100 From: Michael Walle To: u-boot@lists.denx.de Subject: (overlapping) lmb allocations during boot User-Agent: Roundcube Webmail/1.4.11 Message-ID: <63a9d684653e3d19e621a8d978f44113@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 Hi, I sometimes see a corrupted initrd during kernel boot on my board (kontron_sl28). Debugging showed that in this case the spin table for the secondary CPUs overlaps with the lmb initrd allocations (initrd_high is set). I had a look at how the fdt and initrd are relocated (if enabled). In summary, they use lmb_alloc() which will first add all available memory and then carve out reserved regions. There are calls for arch (arch_lmb_reserve()) and board (board_lmb_reserve()) callbacks. The interesting thing is that, there is also code to carve out any reserved regions which were added to the fdt earlier (boot_fdt_add_mem_rsv_regions()). The problem here is, that the DT fixups, which might add the reserved regions are called just before jumping to linux. Thus both the allocation for the fdt (if fdt_high is set) and the ramdisk (if initrd_high is set) will ignore any reserved memory regions. Unfortunately, I don't see any good way to fix this. You'd need all the DT fixups before we can initialize the lmb. Also, I don't know if this will affect any other areas; probably I'm the only one, who reserves an area which is outside of the u-boot code and data segment. A hackish way would be to carve out the spin_table code in board_lmb_reserve(). But meh.. -michael