13 Jan, 2022

2 commits


28 Dec, 2021

1 commit


14 Nov, 2021

1 commit


12 Nov, 2021

1 commit

  • As per https://github.com/actions/virtual-environments/issues/4312 the
    Windows-2016 environments are scheduled for deprecation and removal in
    early 2022. Move to windows-2019 now to avoid this (Visual Studio 2019
    is included here, hence the tag naming scheme change).

    Signed-off-by: Tom Rini
    Reviewed-by: Bin Meng

    Tom Rini
     

22 Oct, 2021

1 commit


15 Oct, 2021

1 commit


30 Sep, 2021

1 commit


25 Sep, 2021

1 commit

  • vexpress_ca9x4 is seemingly the only board except for qemu_arm which
    is able to run U-Boot correctly, using the `-M vexpress-a9` option to
    QEMU. Building for qemu_arm and running qemu-system-arm with the `-M
    virt` argument has a number of downsides, most importantly that it
    only supports virtio storage drivers. This significantly reduces its
    usefulness in testing memory card and Flash solutions, especially when
    the tested images are from a third party source.

    So therefore we reintroduce the vexpress_ca9x4 board in this commit,
    with the explicit goal of using it with QEMU.

    A number of differences to note from the original:

    * Since the board was apparently unmaintained, I have now set myself
    as the maintainer.

    * The board has been converted to use the driver model, which was the
    reason it was removed in the first place.

    * The vexpress_ca15_tc2 and vexpress_ca5x2 boards, which were removed
    in the same commit, are not necessary for the QEMU use case, and
    have been omitted.

    * An `mmc0` alias was introduced in the dts file. The mmc is not
    detected correctly without this, now that it's based on the device
    tree instead of the board's init function.

    * A couple of other nodes were removed because they were problematic
    when trying to run the UEFI bootmgr. Once again, the primary use
    case here is QEMU, and these nodes are not needed for that to work.

    * Unnecessary board init code has been removed, thanks to driver model
    and device tree.

    * `CONFIG_OF_EMBED` has been enabled. I know this goes against
    recommended practice, but there doesn't seem to be any other way to
    pass the dtb to U-Boot in the QEMU scenario. Using the -dtb argument
    does not work, I suppose because U-Boot doesn't use the same
    mechanics as the kernel when it's booting.

    * Load addresses have been changed to fit QEMU use case.

    People wanting to get a more detailed, yet somewhat isolated, diff
    between this and the original, can run this command:

    git diff c6c26a05b89f25a06e7562f8c2071b60fd0c9eac~1 -- \
    $( git diff-tree --diff-filter=A -r --name-only HEAD~1 HEAD)

    (Make sure to either check out this commit first, or replace HEAD with
    the commit ID of this commit)

    Signed-off-by: Kristian Amlie

    Kristian Amlie
     

12 Sep, 2021

1 commit


11 Sep, 2021

1 commit

  • This adds CI tests for SiFive Unleashed board.

    QEMU supports booting exact the same images as used on the real
    hardware out of the box, that U-Boot SPL loads U-Boot proper
    from either an SD card or the SPI NOR flash, hence we can easily
    set up CI to cover these 2 boot flows of SiFive Unleashed board.

    With this, now we can have regression testing of mmc-spi-slot and
    sifive spi drivers, as well as mmc and spi-nor subsystems.

    Signed-off-by: Bin Meng
    Reviewed-by: Tom Rini

    Bin Meng
     

06 Aug, 2021

1 commit


04 Aug, 2021

1 commit

  • The current stable release of LLVM is 12, update to that. While at it,
    fix that we had not correctly upgraded to LLVM 11 previously.

    Signed-off-by: Tom Rini

    Tom Rini
     

28 Jul, 2021

1 commit


08 Jul, 2021

2 commits

  • With the spear family of platforms gone, remove references to them from
    the build jobs.

    Reviewed-by: Bin Meng
    Signed-off-by: Tom Rini

    Tom Rini
     
  • This board has not been converted to CONFIG_DM_PCI by the deadline and is
    also missing conversion to CONFIG_DM. Remove it. This is also the last
    of the ARCH_MPC8641/MPC8610 platforms, so remove that support as well.

    Cc: Paul Gortmaker
    Cc: Priyanka Jain
    Signed-off-by: Tom Rini
    Reviewed-by: Simon Glass

    Tom Rini
     

07 Jul, 2021

1 commit

  • - Move to gcc-11.1.0 builds from kernel.org for supported platforms and
    LLVM-11 for those tests.
    - As Heinrich has noted, the RISC-V platform specification has a profile
    OS-A for running rich operating systems like Linux and BSD. This profile
    requires 64bit and UEFI conforming to the EBBR. Only the 'embedded'
    profile may use 32bit. Given this, drop grub for 32bit RISC-V as it no
    longer compiles with gcc-11.1 and upstream is unlikely to fix it:
    https://www.mail-archive.com/grub-devel@gnu.org/msg30736.html
    - Update to grub-2.06 release to address other issues of building with
    gcc-11.1.
    - Update to newer Xtensa (gcc-9.2.0) and ARC (gcc-10.2) toolchains

    Cc: Heinrich Schuchardt
    Cc: Bin Meng
    Cc: Simon Glass
    Cc: Rick Chen
    Signed-off-by: Tom Rini
    Reviewed-by: Bin Meng

    Tom Rini
     

06 Jul, 2021

3 commits

  • Move us up to being based on Ubuntu 20.04 "focal" and the latest tag
    from Ubuntu for this release. For this, we make sure that "python" is
    now python3 but still include python2.7 for the rx51 qemu build as that
    is very old and does not support python3.

    Signed-off-by: Tom Rini

    Tom Rini
     
  • The filesystem test setup needs to prepare disk images for its tests,
    with either guestmount or loop mounts. The former requires access to the
    host fuse device (added in a previous patch), the latter requires access
    to host loop devices. Both mounts also need additional privileges since
    docker's default configuration prevents the containers from mounting
    filesystems (for host security).

    Add any available loop devices to the container and try to add as few
    privileges as possible to run these tests, which narrow down to adding
    SYS_ADMIN capability and disabling apparmor confinement. However, this
    much still seems to be insecure enough to let malicious container
    processes escape as root on the host system [1].

    [1] https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/

    Since the mentioned tests are marked to run only on the sandbox board,
    add these additional devices and privileges only when testing with that.

    An alternative to using mounts is modifying the filesystem tests to use
    virt-make-fs (like some EFI tests do), but it fails to generate a
    partitionless FAT filesystem image on Debian systems. Other more
    feasible alternatives are using guestfish or directly using libguestfs
    Python bindings to create and populate the images, but switching the
    test setups to these is nontrivial and is left as future work.

    Signed-off-by: Alper Nebi Yasak

    Alper Nebi Yasak
     
  • The EFI secure boot and capsule test setups need to prepare disk images
    for their tests using virt-make-fs, which requires access to the host
    fuse device. This is not exposed to the docker container by default and
    has to be added explicitly. Add it.

    Signed-off-by: Alper Nebi Yasak

    Alper Nebi Yasak
     

22 Jun, 2021

1 commit

  • MSYS2 Windows build started to fail since yesterday (Jun 21):

    checking keyring...
    checking package integrity...
    error: gcc-libs: signature from "David Macek " is unknown trust
    :: File /var/cache/pacman/pkg/gcc-libs-10.2.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
    error: gcc: signature from "David Macek " is unknown trust
    :: File /var/cache/pacman/pkg/gcc-10.2.0-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (PGP signature)).
    error: failed to commit transaction (invalid or corrupted package)
    Errors occurred, no packages were upgraded.

    Switching to the latest installer (version 20210604) seems to fix it.

    Signed-off-by: Bin Meng
    Reviewed-by: Tom Rini
    Tested-by: Tom Rini

    Bin Meng
     

25 May, 2021

1 commit

  • Remove qemu_mips boards because DM migration doesn't make sense.
    The board support for qemu_mips is already marked as deprecated
    in Qemu in favour of the Malta board. Also qemu_mips support
    has been removed from Linux a long time ago.

    The official replacement is the Malta board. The same Malta U-Boot
    image can be used with Qemu and on physical hardware.
    All combinations of Big Endian and Little Endian as well as 32 bit
    and 64 bit are supported.

    Signed-off-by: Daniel Schwierzeck

    Daniel Schwierzeck
     

29 Apr, 2021

1 commit


10 Apr, 2021

1 commit


08 Apr, 2021

1 commit


07 Apr, 2021

1 commit

  • Now that there is a single SuperH platform, rework the Azure job
    slightly. Azure build time limits mean that we need to split the world
    build up still. Make a single build job for the single Renesas SuperH
    platform as well as all of the ARM platforms from Renesas.

    Cc: Marek Vasut
    Signed-off-by: Tom Rini

    Tom Rini
     

30 Mar, 2021

1 commit


27 Mar, 2021

1 commit


26 Mar, 2021

1 commit


22 Mar, 2021

1 commit

  • At present there is only one board which uses sandbox SPL. But with
    sandbox_noinst being added, this is no longer true. Add a --board flag
    so that we just build one board on azure, as is done in gitlab.

    Signed-off-by: Simon Glass
    Reviewed-by: Tom Rini

    Simon Glass
     

05 Mar, 2021

1 commit


01 Mar, 2021

1 commit


02 Feb, 2021

1 commit

  • Commit dd5c954e917b ("travis/gitlab/azure: Use -W to avoid warnings check")
    added -W to avoid warnings check, but it mistakenly dropped -E for
    the world build script in the azure pipelines.

    This caused builds on the azure pipelines fail to report warnings. Let's
    add it back.

    Fixes: dd5c954e917b ("travis/gitlab/azure: Use -W to avoid warnings check")
    Signed-off-by: Bin Meng
    Reviewed-by: Simon Glass

    Bin Meng
     

27 Jan, 2021

1 commit


06 Nov, 2020

1 commit


30 Oct, 2020

1 commit


15 Sep, 2020

1 commit


02 Sep, 2020

1 commit


06 Aug, 2020

1 commit


28 Jul, 2020

1 commit

  • Recent CI failures were seen [1] when building MSYS2 Windows host
    tools. The error messages are something like:

    downloading mingw32.db...
    downloading mingw32.db.sig...
    error: mingw32: key "4A6129F4E4B84AE46ED7F635628F528CF3053E04" is unknown
    error: mingw32: signature from "David Macek " is unknown trust
    error: failed to update mingw32 (invalid or corrupted database (PGP signature))

    Per the MSYS2 official news [2], this was caused by a packager
    switch and several solutions were suggested, e.g.: a new package
    of msys2-keyring and a new msys2 installer that includes them are
    released. However right now we have been using the MSYS2 github
    CI base repo [3] for the MSYS2 build in U-Boot, but per the project
    information on the github webpage, it says: "This repository is
    unused/deprecated and will be remove after 2021-01-01". Since it is
    unmaintained it's unlikely the new PGP keys will be included in the
    git repo, and the only choice is to switch to use the MSYS2 official
    installer as the CI base instead.

    [1] https://dev.azure.com/u-boot/u-boot/_build/results?buildId=975
    [2] https://www.msys2.org/news/#2020-06-29-new-packagers
    [3] https://github.com/msys2/msys2-ci-base

    Signed-off-by: Bin Meng

    Bin Meng