From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jmPRFsEybmA3ewAAWB0awg (envelope-from ) for ; Wed, 07 Apr 2021 18:31:29 -0400 Received: by simark.ca (Postfix, from userid 112) id 4FD4F1E965; Wed, 7 Apr 2021 18:31:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 884761E789 for ; Wed, 7 Apr 2021 18:31:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 35B5D393A406; Wed, 7 Apr 2021 22:31:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 35B5D393A406 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1617834683; bh=I8puY81NYFIYnlGaTuw8Ny1oakVoVw+/eWwAqUrGOKs=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=qRAtcEyilxE7NkfXPsqcQZAPiNxhAxJOqkKjVM+lGmLNbqNb+QH/ywui2Hz6BDovS Lx/JTebYicw0wDaqy7iibNz2IP/wmcSm7tyFEx5+/iP48+j95LOunRWERg+4y8pczR i0rBmX3w1XHaiaMoVjMipOrUtcabZJW6eYdaeC7U= Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id C9D09385801D for ; Wed, 7 Apr 2021 22:31:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C9D09385801D Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 79496335C77; Wed, 7 Apr 2021 22:31:17 +0000 (UTC) Date: Wed, 7 Apr 2021 18:31:17 -0400 To: Luis Machado Subject: Re: [PATCH] [sim,moxie] Fix DTB generation mechanism and build failure Message-ID: Mail-Followup-To: Luis Machado , gdb-patches@sourceware.org References: <20210407193929.1251903-1-luis.machado@linaro.org> <8c9459b3-ffbe-af35-eeb6-513a66d87e5b@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8c9459b3-ffbe-af35-eeb6-513a66d87e5b@linaro.org> X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 07 Apr 2021 17:39, Luis Machado via Gdb-patches wrote: > On 4/7/21 5:26 PM, Mike Frysinger wrote: > > On 07 Apr 2021 16:39, Luis Machado via Gdb-patches wrote: > >> I ran into a build failure with --enable-targets=all due to the fact that > >> the moxie sim expects to be able to use the dtc tool. If it isn't available, > >> the builds fails. > >> > >> Given the device tree compiler (dtc) is not available everywhere, it seems > >> fair to only generate the DTB file on the spot if we have such a tool. For > >> those who don't have the tool available, we can use a prebuilt version of the > >> DTB available in the repository. > > > > i think i asked about vendoring the tool in, but i think people were > > (understandably) not super keen on the idea since it's not GPL or GNU. > > > >> The DTS file hasn't changed since ~2009, so it seems pretty safe to assume > >> a prebuilt version is suitable to be used. > > > > and because it's quite small. if it were much larger, i don't think we'd > > want to do it this way. > > > >> I also checked that the DTB file generated on an x86_64-Linux machine is the > >> the same as the one generated on an AArch64-Linux machine. > > > > right, by design, it should be stable no matter where it's created. > > > >> Tested by running make/make install with/without the dtc tool. > > > > i think we want to fold this under the existing maintainer logic. check out > > commit 8c379db285f2ab8ad298288e86103548b90674a2 for a bit more detail. we'd > > want to only update+install the version in the source tree rather than switch > > between the one in the srcdir & the builddir one. > > I'll take a look. Are you proposing we only use the prebuilt file from > the source tree instead of generating a new dtb file during the build? > And we should only do those things if maintainer mode is enabled? if we're going to commit the prebuilt file to the tree, then yes, we should only be using that. we have a lot of similar styles: * configure from configure.ac * Makefile.in/aclocal.m4 from Makefile.am * nltvals.def from common/gennltvals.py so if maintainer mode is enabled, and dtc is available, and the dts is newer than the dtb, we'd update the dtb in the source repo. anyone changing the dts would be responsible for this. as you noted, this is pretty rare atm, so shouldn't be a big deal. -mike