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::543; helo=mail-ed1-x543.google.com; envelope-from=pete@akeo.ie; receiver=edk2-devel@lists.01.org Received: from mail-ed1-x543.google.com (mail-ed1-x543.google.com [IPv6:2a00:1450:4864:20::543]) (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 793D52119EBF0 for ; Wed, 12 Dec 2018 11:53:09 -0800 (PST) Received: by mail-ed1-x543.google.com with SMTP id d3so50514edx.7 for ; Wed, 12 Dec 2018 11:53:09 -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=6+K+JOg8QhUVPEzTZ4uYYTepiZHP/tk1VabEPdmhZxA=; b=S0I9dQ1PRd2Gheo5OrxbiZEheiAno/ddy4BwrsulbjbdcIiyO13+bFW0lN9uzAFN7M YK3BMIlrDahAuvTCzo0nqur6jxWJ46fDIpVPvRuB8DU2gPOMD7S6gheiZBVVz/TYMf1r k7QOPyzUhMHC1ysXnGOYiIZEZe1ZfZ/PirpridPIg4DHfjCJnS3/16C1L2vbm38egQfY WrWXIp3Lz1BM5sKUD4QaccGKnPtUI0c0dGgNMyGaoU9E//AKKQM5mgSW//uMYwSwkl2E u18uS3KeqLhbqstxDRCswfKnd3EZEsOLazHbroPVhmlJ3VjzDJrowJMtiD8JU7yoibf/ Hvdg== 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=6+K+JOg8QhUVPEzTZ4uYYTepiZHP/tk1VabEPdmhZxA=; b=GLTTgAQj1F+tczS7QIcfLwO+Hx65TKeWp3PU6kbqsZXKZerXWVslnY6L489OyAsiDd 1bd9xgSSyJzSk9DZTdTvCmqcxjYYtyL2gbSokmA4yYkxaaZ4u7bYY9vuN+rNy5VFAggA FeCjxKfN5WgVlA9EN8b9fj9swZMdvewztdlDr8v/qFYc9jeNbdDcjg4T5/e7jwzyU0kx oT9bNZe6Qvw2jpPcvUF95sm6V9zEJAwXOq2w3NB3tYuseXMXOT5QrZDQVzqc8XV5DAuf jBjdOxtXyejc4YCmOaw4MgNZW7/yKKEuD56EhfDs1b8DdiWl5f8GI26X6lhEdCBdQrm/ BUtA== X-Gm-Message-State: AA+aEWZmNvLl5kf866R32ZNkvykL2NA96ANPTDcJI8jDAwtGn2nYyBZr +T/etk1LFFDqQT6uC+pRj5I7CQ== X-Google-Smtp-Source: AFSGD/XC3muHawI4kZviMst/Rx+6hsfg9bItv85F624YKLvewl8X88fx/NqiAR10GpVmf7Q9Gv8n+Q== X-Received: by 2002:a50:b7d6:: with SMTP id i22mr19517495ede.27.1544644387616; Wed, 12 Dec 2018 11:53:07 -0800 (PST) Received: from [10.0.0.101] ([84.203.68.105]) by smtp.googlemail.com with ESMTPSA id v11sm18234edy.49.2018.12.12.11.53.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Dec 2018 11:53:06 -0800 (PST) To: Leif Lindholm Cc: edk2-devel@lists.01.org, Ard Biesheuvel References: <20181210123853.4864-1-pete@akeo.ie> <20181211181040.7i6dfxrl4kfcxspz@bivouac.eciton.net> <20181212183244.sn3h6sgsmz6s4hti@bivouac.eciton.net> From: Pete Batard Message-ID: Date: Wed, 12 Dec 2018 19:53:04 +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: <20181212183244.sn3h6sgsmz6s4hti@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: Wed, 12 Dec 2018 19:53:09 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 2018.12.12 18:32, Leif Lindholm wrote: > On Tue, Dec 11, 2018 at 08:16:07PM +0000, Pete Batard wrote: >>> I _think_ all of the ATF binaries we have in non-osi are >>> non-upstream. If the port for the rpi3 is upstream, I would be just as >>> happy to have simple build instructions of a known good commit (with >>> notes on toolchain version tested) in the Readme.md - and possibly a >>> placeholder directory with a .inf in to drop a prebuilt image into. >> >> Well, while it is upstream, it is built using a custom rpi3 specific option >> which we had ATF to add, so that we could get a memory mapping that works >> with Windows (default one was okay for Linux but not Windows). So I doubt we >> will ever get upstream binaries that we can use as is, if that's what you >> are alluding to. > > I don't really care all that much about that, but if we need > modifications to run Windows (and nothing prevents that from working > with Linux), then should we try to change the upstream defaults? The problem here is U-Boot. The RPi3 ATF has pretty much been designed around U-Boot usage (since it was its only consumer until now), so, to achieve the above, we'll need to validate that we aren't going to break anything for downstream RPi3/U-Boot users, which I don't think we can accomplish in a reasonable timeframe. When I mentioned that the ATF works with Linux and Windows, I meant "when used as part of an UEFI payload". But I have yet to run any comprehensive test of our UEFI-tailored ATF within a U-Boot payload. And even though nobody should be relying on a fixed memory mapping, I do some have concerns that some people might have downstream elements that are tailored around the current U-Boot friendly memory mapping, which we might break. As such, I'd rather first see usage of the UEFI bootloader take off with a few Linux distros, after it has been officialized in edk2-platforms, so that we can have a bit more weight in asking the U-Boot folks whether they'd consider using our memory mapping as default. > But for me, I'd be happy with just the build instructions you have, > and no binaries/license, in > edk2-platforms/Platform/RaspberryPi/RPi3/Arm-Tf/, with the user having > to drop in their own binaries. In that case, I think I'd still like to provide some links to downloadable binaries, for people who don't want to have to rebuild ATF, and who consider that download links provided in an official readme should be trustworthy enough. 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. Regards, /Pete