From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7201062888117633024 X-Forwarded-Encrypted: i=2; AJvYcCWW3eT50xrvV0WQd8xIKFPrrEyWZMcp5zpIgRY/Y5882/qpkne7u2+Doi8do258pCqABpNmbAjV5l+GBwve4AhEpDu3jbAcRXrCEAk= X-Received: by 2002:a05:6402:b2d:b0:563:e047:cb9f with SMTP id bo13-20020a0564020b2d00b00563e047cb9fmr4193299edb.19.1708954349616; Mon, 26 Feb 2024 05:32:29 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6402:2681:b0:565:68dc:3227 with SMTP id w1-20020a056402268100b0056568dc3227ls1242329edd.1.-pod-prod-05-eu; Mon, 26 Feb 2024 05:32:27 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCUCGuH0jgE7m/FOLMfm6X/pzY1OnTnHmpygUOIW9BaNhM7xD7U9kXT0dMYGT4wkMHMRglFnrCf9L7VBPZ0Rpiit7hMvVT2fVPPVSqY= X-Google-Smtp-Source: AGHT+IHJshU5SESTPtOvvXF9ySd/ByFetQy9J0Lkz4uawXoeuC5w+lPGdJ4WmrLesdf8OicUaAMt X-Received: by 2002:a05:6402:1c82:b0:565:a562:9fc3 with SMTP id cy2-20020a0564021c8200b00565a5629fc3mr3507736edb.38.1708954346992; Mon, 26 Feb 2024 05:32:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1708954346; cv=none; d=google.com; s=arc-20160816; b=C/yVTwyJGbH7HWjrB7WeoBvGaswWGi63mfjQdUDhHKLu/gamf9OdjfDRGqv4VESDk8 c8RGFRCD2Op9ZJ2hxlzuNyxN+Iv4MhppKCCLJMpOLgK/LnW7j3UUdq1aGopuWisklBEN UFRLLBQQ8Ct6zxtaqsDti7Op7TIPwUs8AGTB+WB44bNOFtI2OANvsJOkBMS0YfU1k7sa w1WvL3U589zRcswUzZ3roNvH23nUxFI53MFxMHDJIjYe9FRVn6k2cIh+bCn0KyBjjm5B pbGx2nEM9lJ1NNqGSlfZML6sO2NqdiXht/JLOXnAoIwGIW1GIvSam9ivMh5j3BGrjRD8 UE0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id; bh=wMK6Zd8hoENT9iMaC8wGKmHyYd5AGgLGPKqEW6J/0X4=; fh=tG47Ju6uWt1zljik2gIQy5X3dvLVzmdi6aLiuadzxTQ=; b=xjj/l8xdtONESml8Sx7eipaKbMdSLnnf0rZSmmmGH7EgD3bbdP1jCcgDugGL6TY4Kl 69+meYuhXnpy0tvlXaYGFIO3sy5NazBPa5fG9zKuXeKdtfJmzmvOl58VdhQVVmw/U+XR uUynpqxrHnVQg5K1KIHXyNQid+bZVsBQP+6tjr47nAR42obiaPdLzS3etdCtN/hgJvPv QyBw2y6Fguy0xZYn5wqvkZ8xWuKbUUrGIPTH2c+5bXIwZHa9H2cDLDVddUtujEzmlkjQ z2isJz5l2BaLAiCYfscKGWfYSjwDevTTrT/CIMKKDuNS7sYWjDXq3l4wUuNbC3+fC8cr YEuA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id u16-20020a509510000000b00563fcbe92aasi442711eda.0.2024.02.26.05.32.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Feb 2024 05:32:26 -0800 (PST) Received-SPF: pass (google.com: domain of ubely@ilbers.de 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 ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from [127.0.0.1] (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 41QDWNh1026078 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Feb 2024 14:32:24 +0100 Message-ID: Subject: Re: [PATCH v3 2/3] deploy boot files via sstate-cache From: Uladzimir Bely To: Jan Kiszka , Anton Mikanovich , "Moessbauer, Felix (T CED OES-DE)" , "isar-users@googlegroups.com" Cc: "Schmidt, Adriaan (T CED EDC-DE)" Date: Mon, 26 Feb 2024 16:32:23 +0300 In-Reply-To: References: <20230223064359.4171845-1-felix.moessbauer@siemens.com> <20230223064359.4171845-3-felix.moessbauer@siemens.com> <1d0847434c11cf121ef541ff7a47a1158c4ca6a6.camel@siemens.com> <2cddc01d-2a6f-4590-935e-b6ce7912d3ce@siemens.com> <84afbe6c-e561-4c57-9145-270ffa289686@ilbers.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.50.4 (by Flathub.org) MIME-Version: 1.0 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: hBR+1P8GSfbY On Wed, 2024-01-10 at 05:27 +0100, 'Jan Kiszka' via isar-users wrote: > On 09.01.24 15:04, Anton Mikanovich wrote: > > 09/01/2024 15:46, Jan Kiszka wrote: > > > Careful with renaming, I'm not sure of we aren't picking up the > > > DTBs > > > from there and also relying on the names as the firmware will > > > need > > > specific naming as well. This needs at least double-checking. > > >=20 > > > Jan > > >=20 > > It looks like there is no other solution, because different distros > > may > > have > > differencies in their dtb files. > > Downstreams are rely on Isar output paths, so we should at least > > create > > a item > > in RECIPE-API-CHANGELOG.md. > >=20 >=20 > This is about naming for the kernel or the firmware, not for the > layer. > Again: Careful! Also, it would likely be better to enhance > DEPLOY_DIR_IMAGE with the distro, rather than messing with the file > names. >=20 > Jan >=20 > --=20 > Siemens AG, Technology > Linux Expert Center >=20 Currently we have an internal solution that uses a subdirectory named according to the image built (e.g., 'isar-image-base-bootfiles'). This saves original DTB namings, but we just have them in a separate dir. This, of course, also needs mentioning in RECIPE-API-CHANGELOG.md since imagers/CI may use the files for their purpose. Anyway, there is another issue in the whole patchset. We make sstate do things it is not supposed to do. And if the user wants to completely disable sstate, they at least won't find kernel/DTB files in deploy dir. At most, imager can fail if it looks for them here. A simple way to reproduce the issue with disabled sstate: 1. Run 'kas-container menu', configure stm32mp15x-bullseye target 2. Run 'kas-container shell' 3. Disable sstate ``` builder@25df5af8cc0a:/build$ echo 'INHERIT:remove =3D "sstate"' >> conf/local.conf ``` 4. Build the image ``` builder@25df5af8cc0a:/build$ bitbake isar-image-base ``` 5. Check `build/tmp/deploy/images` =3D> there are no any kernel/initrd files, they exist only in `tmp/work/debian-bullseye-armhf/isar-image- base-stm32mp15x/1.0-r0/deploy/` Some other targets (like phyboard-mira) even fail in imager, since it needs the files to be in deploy dir. I guess, later we need to rework the functionality the following way: 1. Don't use sstate for copying files, they should be directly deployed; 2. Split boot files extracted from rootfses with different distro and targets (e.g., `-base`, `-debug`, etc) - but with no sstate help.