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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BDA5C433F5 for ; Tue, 2 Nov 2021 15:39:00 +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 A987C60F5A for ; Tue, 2 Nov 2021 15:38:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A987C60F5A 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 3723082E48; Tue, 2 Nov 2021 16:38:57 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="L0/h8+3S"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1BACD82F03; Tue, 2 Nov 2021 16:38:55 +0100 (CET) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 92171815A8 for ; Tue, 2 Nov 2021 16:38:50 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-ed1-x531.google.com with SMTP id r4so76720490edi.5 for ; Tue, 02 Nov 2021 08:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=2q2qzgIHCExjx/DvqPuYbkRJVSjExZwNC+Y2xI7jimc=; b=L0/h8+3SdaIYIqNl3IfssBlIqn4O1ZEKqHBU3U19/dyNNyUvv7UZg6q8P/kejHTJwa NXXE0+2a9goY5Eene5TZhFupzts1iBwwM9MxD7oYqgs+I9o03CmjoRkb69K+A1q0Ys6R i0Iac209uT9uZHZlnckW1FkK0kDJrBCQmBjwLQhEvOueDKog5G+Uj6ihFq+7EMUXeilq P9/3lOU7GCCIPCInLWkxygyxRPk87S49vM/y/iU1ggIL2l/PVYFmXFYXmmXlDUlG6DdK kYJNEf26dKGX7zAqPbH1lwicqMb8M4oSwnZBvghlq97QBIpx/MvSq0UZpeLtHO4mnxME 4kbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=2q2qzgIHCExjx/DvqPuYbkRJVSjExZwNC+Y2xI7jimc=; b=bevIj8SI7pQTPw6jYeBD62m6Pr1bhKK4yUtr5Gadec7yR12qToGezUvg6mkqotmvXW J+IaIoNJT9PybzBEvrt8x/Wu2/XUP0lnpDDa7kz6dFKZ0coMmVXAgiiKtqDANfD+3Ayw ksSsMHFxuwtaILhJof2WWWBcvg6jvND+bmsuXD3GGBUZYRTmYJ29TClVwFLSPJEGRzkl H3Zc6UDAiX2yxhX9uYgiyd0wfSPqlLUz6kXR9+t4DfbfjkM55x9VMPbKOmAjXJomM7m+ ykCcYhQyt5Fb0gymlYe2UXEu3hfIlaR4WCUQ3HbxrHR/B33ZxmS9nWzxvMiYO/Em7ZiW pcwg== X-Gm-Message-State: AOAM531E63QsJxrm+l8TT77dzf7Z+/Ksr5Fyg5nc0iNgxp+cILBnqP0m VUN8ZOhi3JxOSIf1zy0QowaGmQ== X-Google-Smtp-Source: ABdhPJwH4SMm29JkXItpmEu7HQoUTyQE/IXH+S4hLujfPOJPXYRbnf3rB1iHBaj+z4ratnozabkPKA== X-Received: by 2002:a17:906:e254:: with SMTP id gq20mr40928695ejb.50.1635867529593; Tue, 02 Nov 2021 08:38:49 -0700 (PDT) Received: from apalos.home (ppp-94-66-220-13.home.otenet.gr. [94.66.220.13]) by smtp.gmail.com with ESMTPSA id ho17sm2827146ejc.111.2021.11.02.08.38.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Nov 2021 08:38:48 -0700 (PDT) Date: Tue, 2 Nov 2021 17:38:46 +0200 From: Ilias Apalodimas To: Simon Glass Cc: =?iso-8859-1?Q?Fran=E7ois?= Ozog , U-Boot Mailing List , Mark Kettenis , Heinrich Schuchardt , Tom Rini , Sean Anderson , Marcel Ziswiler Subject: Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Hi Simon, [...] > > > > > > > > > > > > Why me? Perhaps Linaro could take this on instead of working in a > > > > > separate tool and domain? You guys could really pull things together > > > > > and reduce the fragmentation, if you took it on. > > > > > > > > > > Honestly it is hard enough to even get Linaro people to write a test > > > > > for code they have written. What gives? > > > > > > > > That's completely inaccurate. We've added selftests for *every* > > > > single feature we've sent for EFI up to now. Functionality wise the > > > > past 2 years we've added > > > > - EFI variables > > > > - EFI secure boot > > > > - capsule updates > > > > - initrd loading > > > > - efi TCG protocol > > > > - ESRT tables > > > > - RNG protocol > > > > > > > > 5a24239c951e8 efi_loader: selftest: enable APPEND_WRITE tests > > > > 3fc2b16335721 cmd: bootefi: carve out efi_selftest code from do_bootefi() > > > > 1170fee695197 efi_selftest: fix variables test for GetNextVariableName() > > > > ce62b0f8f45f1 test/py: Fix efidebug related tests > > > > 450596f2ac3fd test/py: efi_capsule: test for FIT image capsule > > > > de489d82e3189 test: test the ESRT creation > > > > 57be8cdce35 test/py: efi_secboot: small rework for adding a new test > > > > e1174c566a61c test/py: efi_secboot: add test for intermediate certificates > > > > 479ab6c17eda7 efi_selftest: add selftests for loadfile2 used to load initramfs > > > > > > > > and I am pretty sure I am forgetting more on functionality and selftests. > > > > > > > > So basically we've either contributed new selftests for *everything* > > > > we've or fixed the existing ones. The only thing that's not merged is > > > > the TCG selftests which are on upstream review. > > > > > > Er, I didn't say or mean that no tests were written, just that there > > > is too much push-back on it. Heinrich put a huge amount of effort into > > > > There's no pushback at all, apart from the TPM one. (and for a very good > > reason I've explained over and over again). In fact we add the sefltests > > as part of our patchsets. > > > > > the tests and basically created a strong base for it. Congrats and > > > huge kudos to him. As to Linaro, no offence intended, and it is great > > > that all these tests have been added. Thank you for your efforts and > > > it is very helpful. But I think you miss my point. Or perhaps you > > > don't even agree with it? I sent an email about this on one patch just > > > a day or two ago. > > > > I guess you mean [1]. I've lost count of how many times I responded to > > this. Threads [2], [3] and [4] are just a few examples, so I just got > > tired or replying the same thing over and over. > > > > So bottom line, we are contributing selftests as always, we just don't agree > > with the way *you* want this specific TPM test, trying to force us into sandbox. > > So instead of respecting what we have (which btw is acceptable from u-boot's > > perspective and cleans up a lot of the TPM crud along the way), you went ahead > > making misleading statements on the selftests we contribute, in general. What's > > even more annoying is that, as I showed you, we pretty much add a selftest > > for *every* feature we add. Excellent ... that's certainly ... encouraging ... and > > very productive. > > > > > > > > As to the leadership side (my bigger point), Linaro is leading us all > > > down this fragmented path, with TF-A, FIP, more and more binaries and > > > larger firmware diagrams. Or do you disagree with that too? > > > > > > > Of course I disagree. People decided not to use SPL for their own reasons. > > I am certainly not qualified to answer why Arm choose to do that, but it seems > > to be common nowdays (risc-v/OpenSBI). All Linaro is doing is making sure > > U-Boot is compatible and remains the de-facto choice for embedded boot > > loaders playing nicely with all the new FSBLs come up with. If you > > cosinder SPL and U-Boot the center of the known universe, we certainly view > > things differently. FWIW it's *our* work mostly that made U-Boot SystemReady > > compliant, which is something Arm pushes for [5]. > > > > > I'm sorry if you find this a bit sharp. > > > > Which part? The first one wrt to selftests is not sharp. It's > > manipulative and utterly unacceptable for me, not to mention entirely > > fabricated. > > > > The latter on bootloading fragmentation, I am always happy to discuss. > > My comment was about the push-back I feel I have received when > requesting tests. It was a poor choice of words since it suggests this > is an ongoing problem when in fact many tests have been written. So I > would like to withdraw that and I am sorry for saying that and for > upsetting you. I certainly agree that Linaro has written lots of tests > and this is great. Thank you to you and Linaro for that. The business > of how the tests are written can be handled in other threads. Thanks, I appreciate this. Let's just forget this ever happened. The discussions are usually constructive and I am happy with the general progress, despite of the differences of opinion. > > > > > > But someone needs to be > > > pointing these things out. I don't know who else is doing so. ARM > > > firmware has got noticeably more complicated and fragmented in the > > > last five years, hasn't it? What can Linaro do to address that? I am > > > very happy to help and provide part of the solution, but it needs a > > > shared vision. > > > > There's a TF-A mailing list, we can certainly engage there and try to align > > our ideas/designs. > > > > > > > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > > > becoming a living nightmare. > > > > > > Perhaps the problem here is just the pandemic response and the > > > inability for people to get into a room and brainstorm / collaborate / > > > hack on ideas? I know you have made big efforts to engage, Ilias. We > > > have spoken many times and I'm sure f2f would be easier. > > > > > > > > > > > > > > > It's not even just a Linaro/ARM problem. On the x86 side it is fast > > > becoming a living nightmare. > > > > > > Perhaps the problem here is just the pandemic response and the > > > inability for people to get into a room and brainstorm / collaborate / > > > hack on ideas? I know you have made big efforts to engage, Ilias. We > > > have spoken many times and I'm sure f2f would be easier. > > > > Maybe, hopefully travelling will restart soon. > > I think the whole issue in this thread comes down to a matter of alignment. > > As you can tell, I am frustrated with where things are headed and hope > we can course-correct at some point. This is a matter of perspective to me. I've accepted the fact that firmware gets more complex. Whether I personally like it or not is a different story. One thing that's clear to me though is that we either have to adapt, or slowly become irrelevant. Thanks /Ilias > > Regards, > Simon > > > > > > [1] https://lore.kernel.org/u-boot/CAPnjgZ2mmcUKz0v=ysSvf17c6ab++-hEpO4rc0OeeAEz7pFA2g@mail.gmail.com/ > > [2] https://lore.kernel.org/u-boot/YVdlvpThuqr8jksL@apalos.home/ > > [3] https://lore.kernel.org/u-boot/CAC_iWjLWxPyEwPpG7v=1U1sxLOD4LXF+Vm+cGTHom9Mpz9pAgw@mail.gmail.com/ > > [4] https://lore.kernel.org/u-boot/YVGGRqgVAiHvd1aR@apalos.home/ > > [5] https://www.arm.com/why-arm/architecture/systems/systemready-certification-program/ir?_ga=2.140829686.578781084.1635493248-857780164.1580291819 > > > > Regards > > /Ilias