From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7358404835704569856 X-Received: by 2002:a2e:9254:0:b0:2d6:c23f:7dff with SMTP id v20-20020a2e9254000000b002d6c23f7dffmr9269420ljg.44.1713342326649; Wed, 17 Apr 2024 01:25:26 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:10a1:b0:2d8:ca41:cffb with SMTP id k1-20020a05651c10a100b002d8ca41cffbls75175ljn.1.-pod-prod-07-eu; Wed, 17 Apr 2024 01:25:24 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG48MsN6VcEZ/vD006pmxMjFUepJfs24UfxwnpKwNw2IqJnJAqNOhyDy0hb/HWJCcmpMmdd X-Received: by 2002:a2e:9b04:0:b0:2da:d2b8:ffb0 with SMTP id u4-20020a2e9b04000000b002dad2b8ffb0mr3057955lji.41.1713342324427; Wed, 17 Apr 2024 01:25:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1713342324; cv=none; d=google.com; s=arc-20160816; b=SkA6wd1s8fCNZ2tcb5p8vJHoHzWSYJ8+R9QLwBKdPnz71iHsbq48C0m+tjh9b4nAxd qAV4IKLyV21TkbA9qCZOswIA/mOg1vP481vKuPBTmEcSkzWd5xYSVy54MTRxA37dbnOW Ixl0EZcyD35Jiw94CzGrLNnDge72hHZspDLM+F6QVRAQxWAyDLn7V7zYixeMq7eHJbQe BDZ9DyBr4psVCSmjCNuEgkH+Qra5HU6GU+TnAwvK5DZTuGWdFD3srxYIkq88PFjqLA2O 5V8Y26OALguQXROOPVpU/8gw2GIUI7XBKdIu+Ijl+b6GZSP6PzieNLOg3XXy1c3RUa1J 4+YQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=yU34lVtaWRVYId2X4rSARblI1XmeCXOtWLN8metaxtQ=; fh=7tclEdh7YbwSQowgJ6LNq720O7H5HTEaqj22NJWRE2E=; b=xH5AFv9vdfqXMemkc8GbU7/SngmA7wRKmsZ0gzkNfRnUtLCyq0WJagLiKIbCIk3kVl xeZ7WqM7xKf+PPfa4TuC6XNDaqSJdvIeFA6pyTkmvOB8IK0kgMIHmtY1uItw5tdGrx5S FXLLPaVHgqKwC/68flOClm6W0kMaVsDGXsiQvPtPl3+aB8OCr9rieEUgIExMDsf0BzEc hGE5Cz3eL8f04tWHa3lhZ/my3xhrpowIImRaxkeNI5u5VAVihVqIUlFLN+TLQ0pLqvuh uQUBvBFfW2G08T3dl5alR8s+TD7dYV1r38my9pfiGlIZa6T6ogVOUh4sfq8n9JX2doqZ qILA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ibr@radix50.net designates 85.214.156.166 as permitted sender) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id ka11-20020a05600c584b00b0041816b2a39bsi33912wmb.0.2024.04.17.01.25.24 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2024 01:25:24 -0700 (PDT) Received-SPF: pass (google.com: domain of ibr@radix50.net designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ibr@radix50.net designates 85.214.156.166 as permitted sender) smtp.mailfrom=ibr@radix50.net Received: from ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 43H8PMDu027448 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Apr 2024 10:25:23 +0200 Date: Wed, 17 Apr 2024 10:25:21 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: [PATCH v2 1/1] copy dtbs into a subdirectory based on image name Message-ID: Mail-Followup-To: isar-users@googlegroups.com References: <20240416100746.5681-1-nicusor_huhulea@mentor.com> <3ca17e6f-d449-4a8c-b97e-026f31ae6e5b@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ca17e6f-d449-4a8c-b97e-026f31ae6e5b@siemens.com> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: TZ/bJpHrRI1g On 2024-04-16 17:36, 'Gylstorff Quirin' via isar-users wrote: > On 4/16/24 12:07 PM, Nicusor Liviu Huhulea wrote: > > There are cases when multiple images are build and because the same dtbs > > are copied in deploydir we have a build failure. The build error is related > > to files that are installed into a shared area where those files already exists. > > > > To solve this situation we will copy each dtb in a subdirectory based on > > image name thus avoiding the conflicts. Therefore the other areas needs to be > > updated on the dtbs paths. > > This is a special use case, which breaks all downstream layers which > currently use devicetrees. Coping to the directory dtbs should be disabled > by default as for most uses it is unnecessary. The origin of the problem is bitbake QA with multiple images. The kernel recipe builds the dtb which is deployed by the image. In case of multiple images, the dtbs are considered as different from bitbake PoV and it complains about it -- this is the problem we are trying to address. In our experience, multiple images are common -- and we would still need a solution for a supported feature even if they weren't. >>From the user PoV, multiple directories with the same dtbs are not necessary at all. So, I'm not a fan of the per-image dtb approach although we also have a similar patch to address the immediate failures that we are experiencing. If we go with this approach, I wouldn't welcome switching per-image dtb on and off -- we already have many variables and are missing coverage for untested combinations; maybe some configurable deployment path at most. That said, I think we should really try to bringe the bitbake model closer to the reality and look at moving this to the kernel recipe as Uladzimir has suggested. Maybe there are cases that need to be verified (like different kernels building the same dtbs) and might still need further adjustments. With kind regards, Baurzhan