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 2B4AFC433EF for ; Fri, 15 Jul 2022 10:24:49 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 20FF583C4B; Fri, 15 Jul 2022 12:24:47 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1657880687; bh=N9t8rTcqLnnHcDhqQNtyZZ6RbDZJV6+8anaseTWC8W4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=c3sGiCg4WdQOwLytWdfT2JNDp/MQ7kevQQUqTi5zu3V39KEJPeGbkpu4e1D66xRpQ sBf9RWBgefIMAPXcll0n8oKfcWZew2bk12DiYI24TF0eghtRGHMRwNnuHKWTsrePYA sb9I1vrTvaf4Ju4CKClpi7Gas7av6D+vnnoJBzr/dX1YT3C6dvvC8yiUJJmGmXsNh9 mpliGfDTiQmTBfdrxv52dr4opcyL03RQE/HzZ8GIqzLOnGEZouePPNIBCSWOrRYRTR LaJghOlubFiXiVrScfqPhrjnwTnEeBI1UuI0igG/oTOC7OcY3JyA3nUeT7LwkI3S+y cifPGdABS1hyw== Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 554B881874; Fri, 15 Jul 2022 12:24:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1657880681; bh=N9t8rTcqLnnHcDhqQNtyZZ6RbDZJV6+8anaseTWC8W4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TQbBjNp1xVFEq2m8gCaAbdgXwJfvsNnngpg6oGQMNQRW8WsszC3JF/0KdwiHURyKH eN0Nvc+mUbZgWBFIfvUMcwc0iiVriBdWOAz2sWNIVIBuxuksnTVos/5SqNI5djIFAN vD4RiruXLHFbILxylpfK3YFzponJu53SeMFmmiAh6lSBFji6ITH7pROmY+4j81ZRnQ 6XjmrFhKevpxLT07ltVuU+H1WiVGmpt6FOnzTw7893+laXu8iP1Aipao/kZamoVIv7 nqd7+KGIGlwRRa9WqmW+G6qQ4swKSBsyQEjUn3d/YlvtCQtY4nTr7CMqAlfoqKrxLl Me+U2SAeY0g5A== Message-ID: <1be66336-1888-864f-86a7-c95ee6b80971@denx.de> Date: Fri, 15 Jul 2022 12:24:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: kontron_pitx_imx8m does not start Content-Language: en-US To: Heiko Thiery Cc: Fabio Estevam , u-boot@lists.denx.de, "Peng Fan (OSS)" , Peng Fan , sbabic@denx.de References: <2c487e38-9795-cd04-52df-75beb3837e9a@denx.de> From: Marek Vasut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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.6 at phobos.denx.de X-Virus-Status: Clean On 7/15/22 12:05, Heiko Thiery wrote: > Hi Marek > > Am Fr., 15. Juli 2022 um 11:29 Uhr schrieb Marek Vasut : >> >> On 7/15/22 10:33, Heiko Thiery wrote: >>> Hi, >> >> Hi, >> >>> I see since the change to CLK_IMX8MQ that the kontron_pitx_imx8m board >>> does not start anymore. I have enabled the DUBUG_UART and see the >>> following outputs >> >> Pick >> [PATCH] board_init: Do not reserve MALLOC_F area on stack if non-zero >> MALLOC_F_ADDR > > this does not solve the issue. >> >> And also, increate SPL_MALLOC_F_LEN in board config if that itself does >> not help. > > As said, I need to increase SYS_MALLOC_F_LEN to 0xc000. Then the board > starts. But Peng said that this is not a valid value due to the > OCRAM_S is limited to 32k and this is the MALLOC base. > On the other hand, why does my board consums that much memory and the > others not. I cannot find any difference in these boards that explains > this to me. Too many clock CCF nodes which each allocate udevice structure (which ... is sub-optimal) ? Try commenting out some of the clock in drivers/clk/*mx8mm*c using #ifdef CONFIG_SPL_BUILD , does that make a difference ?