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::541; helo=mail-ed1-x541.google.com; envelope-from=pete@akeo.ie; receiver=edk2-devel@lists.01.org Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 2941D2119A84A for ; Tue, 11 Dec 2018 12:16:11 -0800 (PST) Received: by mail-ed1-x541.google.com with SMTP id f23so13651390edb.3 for ; Tue, 11 Dec 2018 12:16:11 -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=NIo4ZcIfsTQnCMkQAOIbxznzy52e34kwbnbfnHsYJSo=; b=K4g1Qx8uoVExXui6mRrWbt3hAdp/HtIOzkVo1i78aX0Ixf+3Emlpxl/1t8pg8Yij/6 PW8dd/qrVhzqUZA9WzsGGIrRuuWrM5b3fSA634Hci6PtO44waq5Ka8wQ6Ir5lmrQ+66w 3/NLF7lAGk4KKuCG2z3t6KQA/5OolpE3XmKIG0Th53H24XPwQZFxG2PvmmtjidoekPDe cmxTtsaOY3zAcpDeP8trvj4T+ttm3q/iLC7UWLWZhB5cknhufwyUt9SC83aukKY5Q7UO 86MnKdiFqImIKpFNUgdffZd3qaUpJR+50AJFoanscMPhAcNL22XAMNavCxErELSKccJF oILQ== 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=NIo4ZcIfsTQnCMkQAOIbxznzy52e34kwbnbfnHsYJSo=; b=oWr0Gk/h/98X6/OrX6neKtjOQeSzw2Rnv9M1AtXv61hwReyp0Et1WgTpGMbZCkDA2A 39p2ERbe6Z4hSB9mhjNG9rHy2za9ZVt7FbWRsmNopcwqtBuhVq2wDinp+TW3QFhXv0P4 W7Yb7zAFrZw2AaKDFnlMjpbMAaRwC89vsQ1icPDHJ0HsRUtKXGE4wRbcnqsm9l4V+iiq Fe8xJ6mdti0j/eL53EQ6K/VrGUS2sK1cNMzJs3biNcqAApJSUU+g4nxh1qOYgpUoZQTl nvIjpbmuhCkKG2FjYHcb9YzrUeZmB5YUta7kj5QJdmY3jKGwqBSrePFu+sU4zoVdJ4/6 5xvw== X-Gm-Message-State: AA+aEWaRSAY0VrM3ZIDQA79ZtWgYBwOuPhh2IujBfhaQvGeskZDmGcmy sn+alAOYfeU+tTPZh185c1uLzA== X-Google-Smtp-Source: AFSGD/UwG9taYNC/y8jTeM/2sPyvbgdn6A/BPUepn0exzthfoMsH2+JJSZz8oPn7YgxvO+6ZniS6OA== X-Received: by 2002:a17:906:7692:: with SMTP id o18-v6mr13364601ejm.63.1544559370134; Tue, 11 Dec 2018 12:16:10 -0800 (PST) Received: from [10.0.0.101] ([84.203.68.105]) by smtp.googlemail.com with ESMTPSA id b9sm4018407ede.12.2018.12.11.12.16.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Dec 2018 12:16:08 -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> From: Pete Batard Message-ID: Date: Tue, 11 Dec 2018 20:16:07 +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: <20181211181040.7i6dfxrl4kfcxspz@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: Tue, 11 Dec 2018 20:16:12 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Leif, On 2018.12.11 18:10, Leif Lindholm wrote: > Hi Pete, > > Many thanks for this. > I expect Ard will give more detailed review, since he has some > familiarity with the port. But I wanted to make a few comments. > > Could you cc me as well on any future revisions? Will do. > On Mon, Dec 10, 2018 at 12:38:33PM +0000, Pete Batard wrote: >> Version History: >> >> * v2: Break down the content into logical entities of more manageable size. >> Please pay attention to the *NON-OSI* tagged patches, that should be >> applied to edk2-non-osi instead of edk2-platforms. >> >> Preamble: >> >> Because of its price point, ease of use and availability, the Raspberry Pi is >> undeniably one of the most successful ARM platform in existence today. Its >> widespread adoption therefore makes it a perfect fit as an EDK2 platform. >> >> However, up until now, the Raspberry Pi hasn't been supported as a bona fide >> platform in our repository. This series of patches remedies that by introducing >> the Raspberry Pi 3 Model B and Model B+ as a viable EDK2 platforms. >> >> With regards to the latter: >> * Even though the ARM Trusted Firmware binary blobs are subject to a >> BSD-3-Clause licence, which may be compatible with the EDK2 one, we chose >> to follow the lead of other platforms that provide ATF binaries in non OSI. > > 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. For the record, there's a readme located in the directory where the ATF binaries are provided, that has the full build command we used, as well as the description of the memory mapping. > (If it isn't upstream, non-osi is the way to go for now.) > ((This isn't a "do what I say", this is a "you don't have to".)) I guess that means we'll keep the binaries in non-osi for now then. However, I have been thinking about renaming the directory that contains the ATF blobs from "Binary/" to "Atf/" to make it more explicit. I'll probably do for the v3, unless someone has a different idea. >> * The Device Tree binaries (and source descriptors) are subject to a GPLv2 >> license, as per the ones published by the Raspberry Pi Foundation. > > This feels somewhat suboptimal. Is there someone you could ask whether > they'd be willing to dual license? As per the official Raspberry Pi firmware repo at https://github.com/raspberrypi/firmware: The dtbs, overlays and associated README are built from Linux kernel sources, released under the GPL (see boot/COPYING.linux) The part about it being built from kernel sources makes me think that, unless we get all the Linux developers who touched on the relevant parts of the Device Tree to agree on dual licensing, which would be a tremendous effort, it's going to have to remain GPLv2. As a result, even if it wanted to, I doubt the Raspberry Pi foundation would have the authority to dual license the .dtb's/.dts's. But if you see it differently, I can try to get in touch with the Foundation. By the way, since I have just seen from Ard's recent OverdriveBoard patches that we do have the ability to compile a Device Tree from source (which I wasn't aware of), I'm going to point out that we probably don't want to do that for this platform. The reason is: we need to make it easy for users of the Pi3 Model B+ to override the default Model B Device Tree, which is what we embed in the firmware (since it's the most compatible one), and of course it'll be a lot more annoying for people to do that all they have is the .dts. And we can't refer users to the official Pi Foundation .dtb's, as they produce USB keyboard issues and are missing some of the features we want. Moreover, even if we were to decide that we'd like to have at least the Model B Device Tree built from source, we'd still also need to provide the .dtb for that one as, if you want to use one of the many DT overlays provided by the Pi Foundation (see https://github.com/raspberrypi/firmware/tree/master/boot/overlays) then you have no choice but to also provide the base .dtb at the same time, which means that Rpi3 users will want to have easy access to a precompiled custom bcm2710-rpi-3-b.dtb as well. > If not, this is certainly yet another argument for an edk2-non-bsd > repository or suchlike. > >> * The DwUsbHostDxe driver is subject to a GPLv2 license > > And this. I can look into this. I'll just point out that out of the 4 developers that officially appear to have had a hand with crafting this code, one is listed as... Linaro. ;) >> * The Logo source code is under an EDK2 license, but the logo itself, which >> we obtained authorisation to use from the Raspberry Pi Foundation itself, >> after detailing our planned usage, is subject to the trademark licensing >> terms put forward by the Raspberry Pi Foundation, and therefore we chose >> to move the whole Logo driver under non OSI. > > Yes, that's definitely the right thing to do. > >> Additional Notes: >> >> * We chose to introduce the platform under Broadcom/Bcm283x/ as we consider >> first, that additional Broadcom platforms may be introduced, and second that >> even though only Bcm2837 (i.e. Pi 3) platforms are supported from the current >> RaspberryPiPkg, support may be added for Bcm2836 (Pi 2) in the future, hence >> our decision to use a generic Bcm283x/ subdirectory. > > I fully agree with this, but... > > Now for the bikeshedding: Bcm2837 is the SoC used in Pi 3. It is not > an alternative name for the Pi 3. And since the board design is open, > it is plausible that there may be derivative boards. > So ideally, I would like to see something like: > > Platform/RaspberryPi/Pi3 > Silicon/Broadcom/Bcm283x > > With (if practically possible) a split between SoC and board modules > and configuration files. Okay. I was half expecting such a request, so I'll see what I can do. I'll be waiting to see if Ard has additional feedback before I start working on this as part of a v3. > I would expect the Pi3.dsc/.fdf to be fairly minimal and including > .dsc.inc/.fdf.inc files from Bcm283x. > >> * The ARM Trusted Firmware being used is a vanilla version built from the >> latest tree, as we worked with that project to get necessary patches >> integrated. > > Sweet! > >> * Detailed instructions on how to build and test the platform firmware are >> included in the Readme.md found at the root of the platform. > > Splendid! > >> * As detailed in the Readme, the resulting platform firmware has been >> successfully used to install and run Linux OSes, such as Ubuntu 18.10, as >> well as Windows 10 1809 (*full* UI version, not IoT). > > Very nice! > > Could you also add an entry to the top-level Readme.md with a link to > the rpi3 Readme.md? (But hold off until I push some updates from > Nariman.) Will do. Regards, /Pete