Re: [PATCH v2 edk2-platforms 00/20] Platform/Broadcom: Add Raspberry Pi 3 support

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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é <philmd@redhat.com>

# 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.