From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.85.221.66; helo=mail-wr1-f66.google.com; envelope-from=philmd@redhat.com; receiver=edk2-devel@lists.01.org Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) (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 E2368211963F0 for ; Fri, 14 Dec 2018 08:14:08 -0800 (PST) Received: by mail-wr1-f66.google.com with SMTP id 96so5972183wrb.2 for ; Fri, 14 Dec 2018 08:14:08 -0800 (PST) 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:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OmRZJxqvlVyBUABn338MjuBvO+8jM3+cXoFxuVlP5pw=; b=XdMSmbVRIwdrdGm/jrooEQJZLr/NCa5FgR6pUKtW1Iug9W/WqvMROHzm4xW7GqPAsB o81ANuvGeujyWwWCChCfu1mnI+YHoGv1gZ5lJk1KuABxiyjXxsZA7YXV4xl80u+Kr7ye HMrqZe16Efi6q1L2iIeEP4orA7RBy52ygpK1XbnglELnUT7HmVkTSTF374hhKs7zsdyr m1+gYAUToQDoU6NmtHhPu3BUtYzZdnKXfyI4SShPnsk9/kj3j2njhIZjHsceS4LRb3/d 5HYAiKOt1FX7EPlqWD4xgyfVCGpuzuNU8GRDGBKeKoEm3yrgcGd8flWJU+9dcS/4p4+G nrcg== X-Gm-Message-State: AA+aEWZsaOchuuWlo1xl9M1junt/z77KPDLMwWmkYj2CzxMB+C98p3wa hoZ+sJwyycBZ1WKOTNWyuLMTQQ== X-Google-Smtp-Source: AFSGD/Wqb+zFKF8qgKo/fGRtg320EED9GPtRNICn6Oa2KB0PtQfh5ZzvFY21wgYkfCjNEUJpzO1M0A== X-Received: by 2002:adf:9484:: with SMTP id 4mr2882679wrr.98.1544804047306; Fri, 14 Dec 2018 08:14:07 -0800 (PST) Received: from [192.168.1.34] (172.red-88-21-202.staticip.rima-tde.net. [88.21.202.172]) by smtp.gmail.com with ESMTPSA id k128sm6770202wmd.37.2018.12.14.08.14.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Dec 2018 08:14:06 -0800 (PST) To: Leif Lindholm , Pete Batard 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> From: =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= Openpgp: id=89C1E78F601EE86C867495CBA2A3FD6EDEADC0DE; url=http://pgp.mit.edu/pks/lookup?op=get&search=0xA2A3FD6EDEADC0DE Message-ID: <979c097f-62a6-1b37-049f-bbb751bf986e@redhat.com> Date: Fri, 14 Dec 2018 17:14:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20181212200154.xprpwxlhsmaur744@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 16:14:10 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Hi Pete, Leif. On 12/12/18 9:01 PM, Leif Lindholm wrote: > 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. 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? [1] available here: https://gitlab.com/philmd/edk2-platforms/blob/raspi3-atf/Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile $ cat Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile -- >8 -- # # Docker image to build Trusted Firmware-A for the Raspberry Pi 3 board # # Copyright (c) 2018 Red Hat, Inc. All rights reserved. # # SPDX-License-Identifier: BSD 2-Clause "Simplified" License # # --------------------------------------------------------------------- # Steps to reproduce an image: # # 1/ build the Docker image: # $ docker build -t atf-raspi3-builder . # # 2/ build the firmware: # The image will store the built files into the /build directory (within Docker). # You can mount a host directory using the '-v :/build' option. # For example, using the 'build' directory in your current directory: # $ docker run --rm -v $PWD/build:/build atf-raspi3-builder # [...] # AS lib/xlat_tables_v2/aarch64/enable_mmu.S # PP bl1/bl1.ld.S # LD /build/rpi3/release/bl1/bl1.elf # BIN /build/rpi3/release/bl1.bin # Built /build/rpi3/release/bl1.bin successfully # [...] # OD /build/rpi3/release/bl2/bl2.dump # OD /build/rpi3/release/bl31/bl31.dump # # You can now access the binaries: # $ ls --numeric-uid-gid -l $PWD/build/rpi3/release/fip.bin $PWD/build/rpi3/release/bl1.bin # -rwxr-xr-x. 1 0 0 18785 Dec 14 16:31 build/rpi3/release/bl1.bin # -rw-r--r--. 1 0 0 41714 Dec 14 16:31 build/rpi3/release/fip.bin # # 3/ Run other commands # Simply add the command after the image name: # $ docker run --rm -v $PWD/build:/build atf-raspi3-builder fiptool info build/rpi3/release/fip.bin # Trusted Boot Firmware BL2: offset=0x88, size=0x41F1, cmdline="--tb-fw" # EL3 Runtime Firmware BL31: offset=0x4279, size=0x6079, cmdline="--soc-fw" # # 4/ Enter the Docker image # Use 'bash' as the command name. # $ docker run --rm -it -v $PWD/build:/build atf-raspi3-builder bash # # 5/ Use another ATF repository # Mount the repository under /source: # $ docker run --rm -v $PWD/build:/build -v ~/source/arm-trusted-firmware:/source atf-raspi3-builder # --------------------------------------------------------------------- # Linaro GCC 5.5-2017.10 Final Release is based on Ubuntu FROM ubuntu:17.10 MAINTAINER Philippe Mathieu-Daudé # Install the required packages to build TF-A # https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.rst#tools RUN apt update && \ DEBIAN_FRONTEND=noninteractive apt-get install -yy eatmydata && \ DEBIAN_FRONTEND=noninteractive eatmydata \ apt-get install -y --no-install-recommends \ build-essential \ ca-certificates \ curl \ device-tree-compiler \ gcc \ git \ libssl-dev \ make && \ rm -rf /var/lib/apt/lists/* # Install Linaro GCC 5.5-2017.10 Final Release RUN curl -sSL http://releases.linaro.org/components/toolchain/binaries/5.5-2017.10/aarch64-elf/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-elf.tar.xz \ | tar -xJC /opt ENV CROSS_COMPILE=/opt/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-elf/bin/aarch64-elf- # Clone the latest stable release (v2.0) of TF-A RUN git clone \ --quiet \ --depth 1 \ --branch v2.0 \ https://github.com/ARM-software/arm-trusted-firmware.git /source # Build the FIP tool # https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.rst#building-and-using-the-fip-tool RUN make -C /source fiptool ENV PATH=${PATH}:/source/tools/fiptool # The default command to run when calling this image without argument: CMD make -C /source BUILD_BASE=/build \ PLAT=rpi3 \ PRELOADED_BL33_BASE=0x30000 \ RPI3_PRELOADED_DTB_BASE=0x10000 \ SUPPORT_VFP=1 \ RPI3_USE_UEFI_MAP=1 \ fip all --- If you have docker installed, you can test using: # build image $ docker build \ -t atf-raspi3-builder \ https://gitlab.com/philmd/edk2-platforms/raw/raspi3-atf/Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile # build firmware $ docker run --rm -v $PWD/test-raspi3-build:/build atf-raspi3-builder # check built binaries $ ls -1 test-raspi3-build/rpi3/release/*.bin test-raspi3-build/rpi3/release/armstub8.bin test-raspi3-build/rpi3/release/bl1.bin test-raspi3-build/rpi3/release/bl1_pad.bin test-raspi3-build/rpi3/release/bl2.bin test-raspi3-build/rpi3/release/bl31.bin test-raspi3-build/rpi3/release/fip.bin Regards, Phil.