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 9C2D2C433F5 for ; Thu, 6 Jan 2022 07:40:29 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id CBF82830AF; Thu, 6 Jan 2022 08:40:26 +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="ZwMCLawh"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id BF008830C0; Thu, 6 Jan 2022 08:40:25 +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 00F52830A0 for ; Thu, 6 Jan 2022 08:40:23 +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 B0FEE2223E; Thu, 6 Jan 2022 08:40:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2016061301; t=1641454822; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rXqJ5b6kpXjrVhCZzgb3msYQRUWGfrXFmgo/BbW3l24=; b=ZwMCLawh62f5DsJ7LZdrhO0TweOlARaLqAqU/qA86bRjP+tg8qpPS9u5uYU/HZ4mZp140K XUaygMpA+ZyuPA02tPMsNfMA+Ej47Av6o75pek04fdvB/xmVfllwtzwrpuFIl54QYNxRKS R9btLdPJnLRfdwcWKzMorj6QFTfhfs8= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 06 Jan 2022 08:40:21 +0100 From: Michael Walle To: "Sahil Malhotra (OSS)" Cc: ZHIZHIKIN Andrey , =?UTF-8?Q?C?= =?UTF-8?Q?l=C3=A9ment_Faure?= , Gaurav Jain , Pankaj Gupta , Priyanka Jain , u-boot@lists.denx.de, Varun Sethi , Ye Li Subject: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.12 Message-ID: X-Sender: michael@walle.cc 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 Sahil, Am 2022-01-06 07:09, schrieb Sahil Malhotra (OSS): >> I don't know I follow. u-boot and linux should have the same device >> tree; >> regardless if that device is used or not. So applying the overlay just >> for linux isn't >> enough here. > Ok, I don't think that as of now, in all platforms uboot and linux > have same devie > tree. That doesn't mean it is ok to diverge again. I put a lot of effort in syncing uboot's LS1028A device tree with linux. > But I will try to address your concern, but I don’t know how to apply > overlay to > dtb which is embedded in u-boot binary, Can you please point me to one > reference > which is doing this thing, I will take reference from there. Sorry I can't advise you with that. There is board_fix_fdt() maybe that will help. But I'm not conviced this is the correct approach, see below. >> > We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE >> > reserves One Job Ring for its use and that is communicated to Kernel >> > using DTB overlay. >> > >> >> what if the overlay doesn't match the dtb? >> > I didn't get this point, can you please elaborate a little. >> >> You are merging a dtb fragment with an unknown dtb, right? Who says >> they >> match? you might have an old dtb where the supplied dtb fragment >> doesn't >> make any sense. >> >> I might be missing something here. Eg. where is the linux dtb supposed >> to come >> from? This patchset is really missing an example and a description how >> things >> should work. > If supplied DTB does not match with DTB overlay fragment. then overlay > will not get applied. I don't think this is what happens here. fdt_overlay_apply() will mark the fdt as damaged and there will be no fdt at all. > We don't have any control on where user picks the DTB, but we can only > make sure DTB > overlay feature must work with DTBs which are upstreamed > If user makes its own customized DTB, we cannot make sure that things > will work. Again. Is there any documentation on how this should all work together? Where does optee get its device tree from? Shouldn't it be the same device tree as u-boot and linux? Shouldn't optee modify the device tree in place before jumping back to u-boot? Andrey, do you know how this works on imx? -michael