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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id AE126C433F5 for ; Mon, 27 Dec 2021 16:31:19 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AF97383838; Mon, 27 Dec 2021 17:31:16 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="W2CDrt1K"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id B80C78382D; Mon, 27 Dec 2021 12:11:02 +0100 (CET) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 5FB3583829 for ; Mon, 27 Dec 2021 12:10:59 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=tiger20081015@gmail.com Received: by mail-pj1-x1034.google.com with SMTP id mj19so13163104pjb.3 for ; Mon, 27 Dec 2021 03:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=Bt5JV4EwCUku04KEqpRfeMG1nXefK7WVJQvprvSvHxo=; b=W2CDrt1KeJ9C6XfRXEkEHd9108AibZ01erD7hDd7qZqbuw0QdOTOrqEP5c39MtLt8X 9Sk9zJXCToLtYFTGhFr3uEoYOMDF1xVX+DZg0x4KmaBWtyipnzqruvlOwnPXSn+NCN5H 3xcMWe1Qo5ZKAvN3kVUBRyMKCD/68EMSKQ/lAHn6oothHRhVk41E5TUjUU5yyIS8PGke mO4k2UWQeOYtO4Bq7T6zJLwvxSYQi4yovJTsoXUOfa3AoDdMk/taaKD6uES37va0DdTx Cw9PEhloxHab4gx2pz4vK0hMCjB/CBphItP6FeAYvC50Ll2ShbKdISLsSZYYnhqXTC/H DyCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Bt5JV4EwCUku04KEqpRfeMG1nXefK7WVJQvprvSvHxo=; b=qKAR0tmnolAiV7x0K/atAmr+lg/v8S/5bQkEhOyg/YKxltMX305AFVKeVQdDunn97z uNtiYTLCyEH/JReWHRPy0yNsR7nDPQGgwUHCVkESUH68EEd25Ca3ymiUERx2JKFVsjJE ++IBj+zLdfgjoq0BMrONTKyA1WYJobc80FjHB4Y9dT89uZYOEVpUtcGod6wXU5sSk65z GxtJAWfIKDm5aLRfEyMyvKcyPjyjgWwfxKNwOFx3EkEEGPyJSO+gZy/oImbSHJvERhei Vg8ZpIwZykXtjy0xN4I6lOhjBbDEb6A4s75AkeaYLodKNLshFuqygCH2Bad/P3xNFZ6y Lmzw== X-Gm-Message-State: AOAM532s/IdyPa4RecFwbVNS3bsDWC618d247UrXfuePDJMs2+ZlEG6B J9Qbit9HP69fhnN8BAreEt3z1kQ5diBoXiVIwX9k9At6 X-Google-Smtp-Source: ABdhPJw0D+Z4yrVYsVJh087Uj/S43d0W6oJVg78WMQaCvJutissDwOzM+dD4tL4m0Y4ajf/IdYl7pe6A9fK5+jJ5ras= X-Received: by 2002:a17:90a:4fc1:: with SMTP id q59mr17153429pjh.85.1640603457613; Mon, 27 Dec 2021 03:10:57 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:7301:3787:b0:4b:e821:dbc3 with HTTP; Mon, 27 Dec 2021 03:10:56 -0800 (PST) From: Fangsuo Wu Date: Mon, 27 Dec 2021 19:10:56 +0800 Message-ID: Subject: Possiable memory conflict with fdt memory region To: u-boot@lists.denx.de Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Mon, 27 Dec 2021 17:31:15 +0100 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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, in image_setup_linux(), stage 1: Boot_fdt_add_mem_rsv_regions() is called first to add the mem reserve regions which prevents u-boot from using them to store the initrd or the fdt blob; stage 2: Then boot_relocate_fdt() is called to reserve or alloc fdt blob from the avaiable lmb region. But it seems at stage 1 it doesn't cover up all mem reserve regions. For example, if CMD_PSTORE is configured, fdt_fixup_pstore(blob) will add pstore to reserved-memory node in fdt in image_setup_libfdt() after stage 2 , which may conflict with fdt memory region and can't be detected since fdt_fixup_pstore doesn't call lmb_reserve(lmb, pstrore addr, pstore len). In image_setup_libfdt, there are also other functions like ft_board_setup which may change existing reserved memory node's size and lead to the same issue. Do you think a common function is needed before boot_fdt_add_mem_rsv_regions() in stage 1? The function can be used to fix-up or add new reserved memory nodes. Thanks.