From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::442; helo=mail-wr1-x442.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CAFBE211A4586 for ; Fri, 14 Dec 2018 10:41:14 -0800 (PST) Received: by mail-wr1-x442.google.com with SMTP id p4so6381979wrt.7 for ; Fri, 14 Dec 2018 10:41:14 -0800 (PST) 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:content-transfer-encoding:in-reply-to :user-agent; bh=ot8m51M/lk+qysC1Tpz8RnTFofe5QU5p40RT/S0VL5M=; b=aCGyduP+jdkY5F3cFB18xXg1oftwLMgGs+zuV8b61b+pU+OL7wkL753r2rehOOvG9t F/2gBzNnqxxFOAb+dUlcPKLgwJjSMwr0GmTegSjFZ1Tw+fbPEuU/IxIwgMlEVyeKprsi 3oAQA2U3d1WIAum45rJcvgB6v4HHPjlFHuHUg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=ot8m51M/lk+qysC1Tpz8RnTFofe5QU5p40RT/S0VL5M=; b=m4pbN2YIY8ZPAB45MRgVZ7GFESLjZH4Jbgb7VuuBlERKEIjdNPlsAqK/KsmFIoUlQd V2qXjxuNPgkHAzI9VmUhV0rQjGf/x1jjCscZVqtYfETLl8jMDser/W/Qmf0VG2DhRI2O ER8948YzggDz5ZLDqMOvwJj/PLDED8ynAVm11AwEgJHnDKamIchrTgbh6COupkFtnif+ a3w+9dOh3+mHeMc/pdZgQp1R+KXllWDHuVTkN4GnIkW9cOzm0JXc7GXC08zn4feSInjf 9XufDIg+7r4xvrDQtYGl/yqyboR4qS+r6okwIXk6w+41FJug9UL1d4xpvAcAm9CbcnzG zWdg== X-Gm-Message-State: AA+aEWa3lFIo0RS+BdhtsKAuru1U60ss7Q2dMKaV8StmEcO/7AEcExDY AtOPfctcyOah6vFpnNf5wt/N6g== X-Google-Smtp-Source: AFSGD/WvZ1YgWxrv0orTqy/lGNDtJgS/JaMJTz3Wxzvlh6QzgUcbvSjbvOkvCh9HgJnGjnemsLAaiw== X-Received: by 2002:a05:6000:110f:: with SMTP id z15mr3405852wrw.136.1544812873067; Fri, 14 Dec 2018 10:41:13 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id x12sm5003564wrt.20.2018.12.14.10.41.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 14 Dec 2018 10:41:12 -0800 (PST) Date: Fri, 14 Dec 2018 18:41:10 +0000 From: Leif Lindholm To: Pete Batard Cc: Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , edk2-devel@lists.01.org, Laszlo Ersek , Ard Biesheuvel Message-ID: <20181214184110.hxk4bbflrs6zmnne@bivouac.eciton.net> References: <20181210123853.4864-1-pete@akeo.ie> <20181211181040.7i6dfxrl4kfcxspz@bivouac.eciton.net> <20181212183244.sn3h6sgsmz6s4hti@bivouac.eciton.net> <20181212200154.xprpwxlhsmaur744@bivouac.eciton.net> <979c097f-62a6-1b37-049f-bbb751bf986e@redhat.com> <20181214163646.oji43hgeqxlp3vzq@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH v2 edk2-platforms 00/20] Platform/Broadcom: Add Raspberry Pi 3 support X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 18:41:15 -0000 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Fri, Dec 14, 2018 at 05:08:05PM +0000, Pete Batard wrote: > Hi Philippe, Hi Leif, > > On 2018.12.14 16:36, Leif Lindholm wrote: > > On Fri, Dec 14, 2018 at 05:14:05PM +0100, Philippe Mathieu-Daudé wrote: > > > > > I can certainly upload binary releases for the required ATF files in my > > > > > github clone of ATF, and then add links to that in the readme with the > > > > > instructions on how to rebuild ATF. > > > > > > > > > > However, I'd rather wait to do that until there has been an official tagged > > > > > new release for ATF (which would be 2.1 at this stage, since our changes > > > > > have been applied after 2.0), as it'll look better for Pi users to see an > > > > > initial ATF serial output that says "BL<#>: v2.1(release)" instead of the > > > > > current "BL<#>: v2.0(release):v2.0-278-gc3859557" > > > > > > > > > > How about this then: If ATF produces a formal release before this proposal > > > > > is integrated, I'll amend it to remove the ATF binary blobs and apply the > > > > > suggestion above, with the Atf/ build/link data moved out of non-osi. But if > > > > > they don't, I'll keep the proposal for ATF as is, and then submit a patch to > > > > > remove the non-osi data and apply the above at a later date, once there has > > > > > been a new ATF release. > > > > > > > > Yeah, this certainly works for me. > > > > > > I setup this Dockerfile [1] to have reproducible builds and avoid to > > > store those binaries in the non-osi repository, what do you think about > > > this approach? > > > > Get off my lawn? :) > > > > > [1] available here: > > > https://gitlab.com/philmd/edk2-platforms/blob/raspi3-atf/Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile > > > > I think it's a good thing to have, especially for something like the > > Pi. I guess if that exists, we can trust people who prefer not to use > > containers to be happy to follow the Readme, or grab binaries from > > Pete's github? > > That's one way to do it. As I indicated, as soon as ATF creates a 2.1 tagged > release, I will look into removing the binary blobs from non-osi. > > However I am not planning to do that sooner. As a matter of fact, given that > this is not a blocking issue and given the scope of what still needs to be > addressed for RPi3 integration, I am kind of hoping we won't see an ATF > release for another month or two, so that we can get through the current > integration process, with the current binary blobs in non-osi, and then sort > out their removal post integration. > > Personally, I also expect that anybody who wants to build the binaries > locally, can simply be directed to follow the official ATF build notes on > how to set up their tool chain, and then refer to the build parameters from > our readme. But then again, if we have a nice Docker solution to provide, I > don't see why we shouldn't also point to it. > > On the other hand, when it comes to providing trustworthy links, and since > there exists a MinGW32 version of the Linaro GCC compilers, I'd much rather > use AppVeyor for automated build of ATF binaries. The nice thing is that > AppVeyor can keep and serve its build artefacts, so we'd be able to directly > link to those, which should give some level of trust that the binaries > haven't been tampered with by the owner of the repo (or at least that, if > they have, the source would reflect it). And you can also easily configure > AppVeyor to only build on tagged commits, which I think is what we want. > > At any rate, I think there exists more than one solution to address the ATF > binary provision problem for RPi3, while also not having to ask users to > blindly trust any binaries we might link to. Maybe Docker or AppVeyor are > what we want to use. Maybe there is yet another option on the table that we > haven't talked about yet. > > If we believe this is necessary, I can look into adding AppVeyor builds of > the official ATF ASAP. But for the time being, I would prefer if we start > discussing this in earnest once ATF 2.1 has been tagged for release, and I > send a formal proposal to address the removal of the non-osi ATF binaries. Sure, that works for me. / Leif