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 <LOCAL_DIRECTORY>:/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é <[email protected]> # 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. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
