From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: None (no SPF record) identity=mailfrom; client-ip=2a00:1450:4864:20::542; helo=mail-ed1-x542.google.com; envelope-from=pete@akeo.ie; receiver=edk2-devel@lists.01.org Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (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 AFDEC211A43CE for ; Fri, 14 Dec 2018 09:08:08 -0800 (PST) Received: by mail-ed1-x542.google.com with SMTP id f9so5504792eds.10 for ; Fri, 14 Dec 2018 09:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akeo-ie.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2KJ3Uw/3mu7ViBIsU/d91MS4DPjny7Ah3QYxLYJVLTM=; b=InQtU2Eb0IKrvF8daOMrDOYyoApT/HXPPZ31sHQiHzTg0KQcrijQWmd0JBQU0Zp4Te 3acWY9wKNDOpME/OKTftHuuBaqfFX4RvYoR6i24Qn7j7F7XqsfqDwTphj0w1Gse9QLNO U++Y5B/6fBAEoDA2AUII7fZGb9NHIseMImINRHnfMCp4TO7mFo6NNkJpcJlh+MeCI6xV cHyim+yQvY1OI0d1J6WSyt9kqnjfkRdyilvSFewKQLQeOgwot3b3r7DGW0lVgm2WvG56 ZwgS4ZTGh5tNAkIgaB22q4yD0W3hKu9cJxALFE0ITUGK8ROnUMYU7qHh5SEP/yEe8jKh MUPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2KJ3Uw/3mu7ViBIsU/d91MS4DPjny7Ah3QYxLYJVLTM=; b=gXT2BgKDfQ2f5oBxDeNRo9A44wAswePkWRgMJCekXByfKuu45pZqjxPkVcM8St4iuZ G6TqV98MR8yC3ybv6DCiTbCCM62l3FGG+Ow46w18DEocMmjv7d9HpCpMKpuAgWdcmkzY J4DLf2DVV5G16gYFFGJHR9GPj5s3fjHiuBB25yq60N16Q4lpi65+cOmptSx9M6l9Ff4V RmtgXpxtyRk1baw1AtGjiRFmBEyTBnjZHBG3kaTQB8jl9HJk8mo2fExCmcjMuy+BKcYJ 2jLbfxlDbBSat29MzuFsnGzkBgmOy/4jEOL2jdj0kqc3sCUmR2sSImSw5hQOkdsd9wYJ jbQg== X-Gm-Message-State: AA+aEWbED+Bm/rZYYT+6EGD8eoZu5XXIgzkA/4AfDXfGW5rqumIaqf+U qNrudA/CKrYL077mxROhhNCGhBGMuAk= X-Google-Smtp-Source: AFSGD/Xq3p+1WlTXdoooh6O/taMZIMe6G+IdfbEYmZEFcldTW5bhaXest2OlELFGI5ngWT2R+/v5sg== X-Received: by 2002:a50:aa9b:: with SMTP id q27mr3700641edc.93.1544807287165; Fri, 14 Dec 2018 09:08:07 -0800 (PST) Received: from [10.0.0.101] ([84.203.59.7]) by smtp.googlemail.com with ESMTPSA id f20sm1544756edf.19.2018.12.14.09.08.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Dec 2018 09:08:06 -0800 (PST) To: Leif Lindholm , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Cc: edk2-devel@lists.01.org, Laszlo Ersek , Ard Biesheuvel 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> From: Pete Batard Message-ID: Date: Fri, 14 Dec 2018 17:08:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20181214163646.oji43hgeqxlp3vzq@bivouac.eciton.net> 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 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 X-List-Received-Date: Fri, 14 Dec 2018 17:08:09 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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. Regards, /Pete