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 X-Spam-Level: X-Spam-Status: No, score=-8.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31886C433EF for ; Mon, 13 Sep 2021 16:08:32 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 643CE604D1 for ; Mon, 13 Sep 2021 16:08:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 643CE604D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C1EBD833DE; Mon, 13 Sep 2021 18:08:28 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="wb+YV39m"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 88487833E8; Mon, 13 Sep 2021 18:08:26 +0200 (CEST) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6281B833CB for ; Mon, 13 Sep 2021 18:08:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ed1-x532.google.com with SMTP id z94so8960341ede.8 for ; Mon, 13 Sep 2021 09:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WjMEiLTC1brXAwcECiX1lt6XeBjg3wO+PJMMwYht9fI=; b=wb+YV39m0vf0S6hBOsUpbXzqq+aLOAFqNi4RMuDege6UFtg8upqxMAuAbnYLENTX7n LKMw82E/S2zFnOcdIDZGyq0BhIsotiK5fKtzc/px8ZnLf7Qy8WRPuNh/yVs+8QMfkF04 uD7Swm0TI0J7MH1Yj0WzCXM5x0v8MV3WnuZmoK+nh9U5dBeYCGM1CFCbOXYHUuLtQ0+F vqGAZfG0067PdHlVgAYgxupBmYqQWYB4sYB4FJyWBZ7K4fbRYMYaSuOR2/JoQ5zNngv3 Suzz1767L8XFPLkCeelUQxkQl/rrNqaJsThc871TG3rzcFvEvfZzoPo4mYq3+AkrDzQY j1gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WjMEiLTC1brXAwcECiX1lt6XeBjg3wO+PJMMwYht9fI=; b=aZB6zyICeIA4S5SL2xaAj0h+p7z7ySr3s6Htd5YVaBWuWs4mBqt92aGcIC9rC7avbe lRXMfqIYThe5mRgpDnospAh8CeH1L9mEm/usdsTUjykx22szKaV/fpauPb/gn4fBSM1i pu7ok/8EdBo1+qWa5o733cE32P5tL6upUldVL1PJ20+HpRm5yTIXLQlTDP/7zISANrTH +AwqT6F1SsQ9FMFmwojkppHw7fJLsw7e/U6iB+FBFK9uJ2qqHvIeEVUPljMQoDwryTnM 9G/s9iBm2EL800V1RoZzjH92l7x4zA1t/F8W7WB/p9Xs3MB+gUzRTIWIAg91BiGrDjCY HF5w== X-Gm-Message-State: AOAM532quOE02sxNKNrB5Rvp332Dx8qHlfJZoJuTAXmWRReUTfSLuVbD FetLGQCm28RnFi2AvscXrVMmnKAthMb3UjXvXWlQow== X-Google-Smtp-Source: ABdhPJyQlPACajP5aDh22gj28WtwwcC+2zPc7s/B2AZQjdNmAyJpEX3Z56Vje3f6Ds/BILX7j1jzeg5dNAhsApOzJ2M= X-Received: by 2002:a05:6402:34c:: with SMTP id r12mr13921023edw.390.1631549301852; Mon, 13 Sep 2021 09:08:21 -0700 (PDT) MIME-Version: 1.0 References: <44b858e8826f4617439aec11ad850431e4bc1a21.1628000645.git.jan.kiszka@siemens.com> <20210911001003.GA2638@bill-the-cat> <0fd4c0d4-c42f-bb15-b68b-3ccf9a9037e0@siemens.com> <20210913123445.GB12964@bill-the-cat> <5d515165-6f39-285d-7bd1-a412ed468cf4@siemens.com> <20210913145609.GO12964@bill-the-cat> <54d40bce-3baf-e485-3467-863eca5bf296@siemens.com> <20210913153621.GP12964@bill-the-cat> In-Reply-To: <20210913153621.GP12964@bill-the-cat> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Mon, 13 Sep 2021 18:08:10 +0200 Message-ID: Subject: Re: [PATCH v7 5/5] iot2050: Enable watchdog support, but do not auto-start it To: Tom Rini Cc: Jan Kiszka , Simon Glass , U-Boot Mailing List , Le Jin , Bao Cheng Su , Nian Gao , Chao Zeng , Lokesh Vutla Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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 On Mon, 13 Sept 2021 at 17:36, Tom Rini wrote: > On Mon, Sep 13, 2021 at 04:59:35PM +0200, Jan Kiszka wrote: > > On 13.09.21 16:56, Tom Rini wrote: > > > On Mon, Sep 13, 2021 at 04:31:37PM +0200, Jan Kiszka wrote: > > >> On 13.09.21 14:34, Tom Rini wrote: > > >>> On Mon, Sep 13, 2021 at 09:57:45AM +0200, Jan Kiszka wrote: > > >>>> On 11.09.21 02:10, Tom Rini wrote: > > >>>>> On Tue, Aug 03, 2021 at 04:24:05PM +0200, Jan Kiszka wrote: > > >>>>> > > >>>>>> From: Jan Kiszka > > >>>>>> > > >>>>>> This allows to use the watchdog in custom scripts but does not > enforce > > >>>>>> that the OS has to support it as well. > > >>>>>> > > >>>>>> Signed-off-by: Jan Kiszka > > >>>>> > > >>>>> Sorry for the late reply. This causes CI to fail: > > >>>>> Building current source for 1 boards (1 thread, 16 jobs per threa= d) > > >>>>> aarch64: + iot2050 > > >>>>> +(iot2050) WARNING ATF file bl31.bin NOT found, resulting binary > is non-functional > > >>>>> +(iot2050) WARNING OPTEE file bl32.bin NOT found, resulting might > be non-functional > > >>>>> +(iot2050) binman: Filename 'k3-rti-wdt.fw' not found in input > path (.,/home/trini/work/u-boot/u-boot,board/siemens/iot2050,arch/arm/dts= ) > (cwd=3D'/tmp/iot2050/.bm-work/iot2050') > > >>>>> +(iot2050) make[1]: *** [all] Error 1 > > >>>>> +(iot2050) make: *** [sub-make] Error 2 > > >>>>> 0 0 1 /1 iot2050 > > >>>>> > > >>>>> And needs to be handled like ATF/OPTEE/etc where CI can build but > throw > > >>>>> a "THIS WILL NOT RUN CORRECTLY" type warning to the user. > > >>>>> > > >>>> > > >>>> I was about to sent an update anyway - time passed, and now we eve= n > have > > >>>> support for the next generation integrated from the beginning. But > > >>>> related upstream DT changes are not yet merged. > > >>> > > >>> OK. > > >>> > > >>>> But back to this issue: How can CI be fed with all those required > > >>>> binaries? The build makes no sense in their absence. > > >>> > > >>> To be clearer, CI isn't fed all of the binaries, we just use > /dev/null > > >>> in that case and try and make it clear it won't boot. K3 isn't a > good > > >>> example here, but I think sunxi uses binman and handles this same > class > > >>> of problem? > > >>> > > >> > > >> I'm seeing it additionally carrying a "missing-msg" property, but th= at > > >> alone (even with missing-blob-help updated) does not make the build > > >> pass. It rather seems I'm missing some "allow_missing" property for > that > > >> image, but even reading the code gives no clue yet how to achieve > that. > > >> Yet another binman mystery. > > > > > > You might also need a new file in tools/binman/etype/ ? Also, it wil= l > > > have a non-zero exit status still, but with a value of 101 which we > > > check for and know that's "binary blob missing" and so OK to allow CI > to > > > pass on. > > > > > > > Err, that doesn't sound like binman is making my life easier. Why can't > > a I simple do something like > > > > k3-rti-wdt-firmware { > > type =3D "blob"; > > load =3D <0x82000000>; > > blob { > > filename =3D CONFIG_WDT_K3_RTI_FW_FILE; > > missing-msg =3D "k3-rti-wdt-firmware"; > > allow_missing; > > }; > > }; > > > > and be done? > > Sounds like a good idea, and I'm not quite sure what's missing to go > from where we are today to there. I might be missing something myself. > If that entry is located in a DT for U-Boot consumption why not, but in the DT that is associated to a platform that is passed to the OS, that sounds like a practice to avoid as this does not describe hardware. Thinking compatibility, is the filename/filepath really OS independent ? > > -- > Tom > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog