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::444; helo=mail-wr1-x444.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 A59432119307C for ; Wed, 12 Dec 2018 12:01:57 -0800 (PST) Received: by mail-wr1-x444.google.com with SMTP id v13so18959411wrw.5 for ; Wed, 12 Dec 2018 12:01:57 -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:in-reply-to:user-agent; bh=IWf+BDkY6gJxw0lN2sKBKey5t08SE9O/y6c6nVJ0J0A=; b=aUWvBePCQAg9Ba4s0mmgH1OgsyKqeISa3l/LTNXeV7ceypzh2rsnapHgy4uI/kThZP yKYQCCPneaA1fdH7zJqtwzaijJU7rK316yi1zqeOgU1kaSJYhtyVp7NmK8TElpPNlLBq 8VtNCsINM22Fye+9w9XNUGeT6E13BcOJ0PVF0= 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:in-reply-to:user-agent; bh=IWf+BDkY6gJxw0lN2sKBKey5t08SE9O/y6c6nVJ0J0A=; b=HZiCJyMp7jqMVBC+lh1PaJjLkRjzspfBHczAVr27Mnk+NrBa3Vgj4o3+qtaeUa4oWQ 1ZFLxRrBHxNWJ6952oIf1OfhmsxNMGvCTDG7krsZrFXUL3ArMltqzaQcsGnlolqZzSa+ ipOMBn8YquP86o/Ecv6PMwJQT32lb0FNexiPB2WRGoT3zuOq9lXLrW/w9uFg+6wAWsO+ m08hlsME8yM+ZDGrRhtzf3LOXoRYwMUiBAljJx4x+4riSULZUax2QWWwa00XjRPM6VRe crrXQOHKpyqq3Tp3lvL5oSYcwfqLJqfCIgmvKZ6RWN5nKMQ5Ze1hZvPOAI7LUMUICrWi tBKQ== X-Gm-Message-State: AA+aEWYLegRvBBB59ikFj18e05vTp7eACgMvY4Vki3l7HAL3m9PZC7pD hltRF1KnX0bMsD916VCbOLlWyYBRdPs= X-Google-Smtp-Source: AFSGD/XBbm4PCeTNZZzy79821yYRBnNL4iDlt3caVJAe1prlmZ1iRtGOS1deak/b7wyo7eLklxONgg== X-Received: by 2002:adf:94e4:: with SMTP id 91mr19583164wrr.322.1544644916417; Wed, 12 Dec 2018 12:01:56 -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 m4sm20387678wmi.3.2018.12.12.12.01.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 12 Dec 2018 12:01:55 -0800 (PST) Date: Wed, 12 Dec 2018 20:01:54 +0000 From: Leif Lindholm To: Pete Batard Cc: edk2-devel@lists.01.org, Ard Biesheuvel Message-ID: <20181212200154.xprpwxlhsmaur744@bivouac.eciton.net> References: <20181210123853.4864-1-pete@akeo.ie> <20181211181040.7i6dfxrl4kfcxspz@bivouac.eciton.net> <20181212183244.sn3h6sgsmz6s4hti@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: Wed, 12 Dec 2018 20:01:59 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Dec 12, 2018 at 07:53:04PM +0000, Pete Batard wrote: > 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. Understood - thank you for this background. > > 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. Yeah, this certainly works for me. Regards, Leif