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 3EB56C433F5 for ; Sun, 31 Oct 2021 11:44:12 +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 32B0F60F59 for ; Sun, 31 Oct 2021 11:44:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 32B0F60F59 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl 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 D2AFB80601; Sun, 31 Oct 2021 12:44:07 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id D551A815A8; Sun, 31 Oct 2021 12:44:05 +0100 (CET) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (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 CDB5880234 for ; Sun, 31 Oct 2021 12:44:01 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id b3e45e19; Sun, 31 Oct 2021 12:44:00 +0100 (CET) Date: Sun, 31 Oct 2021 12:44:00 +0100 (CET) From: Mark Kettenis To: Michael Walle Cc: u-boot@lists.denx.de In-Reply-To: <63a9d684653e3d19e621a8d978f44113@walle.cc> (message from Michael Walle on Sun, 31 Oct 2021 11:43:38 +0100) Subject: Re: (overlapping) lmb allocations during boot References: <63a9d684653e3d19e621a8d978f44113@walle.cc> Message-ID: 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 > Date: Sun, 31 Oct 2021 11:43:38 +0100 > From: Michael Walle > > 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.. The spin table is embedded in the u-boot binary itself isn't it? But the memory occupied by the u-boot should already be reserved... 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... Does your target end up with CONFIG_EFI_LOADER defined?