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 D9CD1C433F5 for ; Thu, 27 Jan 2022 15:07:24 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 8004C837E1; Thu, 27 Jan 2022 16:06:47 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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; unprotected) header.d=chromium.org header.i=@chromium.org header.b="Ae03i/zY"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 001E48365D; Thu, 27 Jan 2022 16:06:20 +0100 (CET) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 801DB80F81 for ; Thu, 27 Jan 2022 16:06:15 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-ot1-x329.google.com with SMTP id o9-20020a9d7189000000b0059ee49b4f0fso2827862otj.2 for ; Thu, 27 Jan 2022 07:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rvGrLpgNYlGe+krT/8CUPRlIOFwhT1psTSmpU83rB0I=; b=Ae03i/zYmLCxBd8K0xCEgl3OqAnshgy5iVcOc+/Nn2AN87TLLpUW1aPcYDudWz8RJ5 QEbD3gBGcwZIgzyuCTQWdFaaHYWKkqFKiBbeC/Ieh8epSy4mlpt0AuSbcC9vGpxMXLLQ UEM8GFhCWAB827GjMzty3FlnRXpcX8eojNxyQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rvGrLpgNYlGe+krT/8CUPRlIOFwhT1psTSmpU83rB0I=; b=QhsjIpYE7l9UxsnYvI7wY9Iz0sV9Uie7PeDdF8KDEyR6b1q4vJQE/HsvGm3SonCRlm /JZtZ0rmCCVaQVbul/nCjwkOrpNQDSoBymXkp8dJmBncAzqJ+3kEFjABKI0Q473bFjGb nJ/VJseOR5S+ZkrlzNufCIWLa+x/T/13O6iRGnR6ecyDc1VVnsVGGd08F3dB2KuPDtZr kJAJOGvv6Mz+9lPEqJIwXiAk2/5n+nOKcHy/hl2950f4zYvVQ3UcSyKJ45S5/3Mrw8Jk Ar9Y8/jdloAR08ZYzf7WWX82OBVF8Pi8IbCfAymyJAUcFxRMjOh3FR9jbm8AKJ/MqDJo zuNQ== X-Gm-Message-State: AOAM53235lOH8PKR3RHbGGVYw1Mm/0NG8MB34I3r2OEjTxUwom4pHEPy WHIVEOZslDxLVQfA+Fhmev2BIBATw/piUvymHGJO+A== X-Google-Smtp-Source: ABdhPJyJ5ucBynok3q+v973bErQ5ztzOrwmQKunEPHBfubz9CqQLSHcJFBzPrtJ4HfEb0GVnZPe3jh3MmfhJzlgQ40M= X-Received: by 2002:a9d:3ab:: with SMTP id f40mr2237079otf.351.1643295973624; Thu, 27 Jan 2022 07:06:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Simon Glass Date: Thu, 27 Jan 2022 08:06:00 -0700 Message-ID: Subject: Re: Possiable memory conflict with fdt memory region To: Fangsuo Wu , Tom Rini Cc: U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.5 at phobos.denx.de X-Virus-Status: Clean Hi Fangsuo, On Mon, 27 Dec 2021 at 09:31, Fangsuo Wu wrote: > > 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. +Tom Rini Possibly. I am not an expert on this, but perhaps send a patch? Regards, Simon