1. 07 7月, 2021 6 次提交
    • M
      gpio: Introduce CONFIG_GPIO_EXTRA_HEADER to cleanup #ifdefs · 7a672057
      Masami Hiramatsu 提交于
      Since some SoCs and boards do not hae extra asm/arch/gpio.h,
      introduce CONFIG_GPIO_EXTRA_HEADER instead of adding
      !define(CONFIG_ARCH_XXXX) in asm/gpio.h.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
      7a672057
    • M
      dm: pci: Skip setting VGA bridge bits if parent device is the host bus · 2f7dddc2
      Masami Hiramatsu 提交于
      Commit bbbcb526 ("dm: pci: Enable VGA address forwarding on bridges")
      sets the VGA bridge bits by checking pplat->class, but if the parent
      device is the pci host bus device, it can be skipped. Moreover, it
      shouldn't access the pplat because the parent has different plat data.
      
      Without this fix, "pci enum" command cause a synchronous abort.
      
      pci_auto_config_devices: start
      PCI Autoconfig: Bus Memory region: [78000000-7fffffff],
      		Physical Memory [78000000-7fffffffx]
      PCI Autoconfig: Bus I/O region: [0-ffff],
      		Physical Memory [77f00000-77f0ffffx]
      pci_auto_config_devices: device pci_6:0.0
      PCI Autoconfig: BAR 0, Mem, size=0x1000000, address=0x78000000 bus_lower=0x79000000
      
      PCI Autoconfig: BAR 1, Mem, size=0x8000000, No room in resource, avail start=79000000 / size=8000000, need=8000000
      PCI: Failed autoconfig bar 14
      
      PCI Autoconfig: BAR 2, I/O, size=0x4, address=0x1000 bus_lower=0x1004
      
      PCI Autoconfig: BAR 3, Mem, size=0x2000000, address=0x7a000000 bus_lower=0x7c000000
      
      PCI Autoconfig: BAR 4, I/O, size=0x80, address=0x1080 bus_lower=0x1100
      
      PCI Autoconfig: ROM, size=0x80000, address=0x7c000000 bus_lower=0x7c080000
      
      "Synchronous Abort" handler, esr 0x96000006
      elr: 00000000e002bd28 lr : 00000000e002bce8 (reloc)
      elr: 00000000fff6fd28 lr : 00000000fff6fce8
      x0 : 0000000000001041 x1 : 000000000000003e
      x2 : 00000000ffb0f8c8 x3 : 0000000000000001
      x4 : 0000000000000080 x5 : 0000000000000000
      x6 : 00000000fff718fc x7 : 000000000000000f
      x8 : 00000000ffb0f238 x9 : 0000000000000008
      x10: 0000000000000000 x11: 0000000000000010
      x12: 0000000000000006 x13: 000000000001869f
      x14: 00000000ffb0fcd0 x15: 0000000000000020
      x16: 00000000fff71cc4 x17: 0000000000000000
      x18: 00000000ffb13d90 x19: 00000000ffb14320
      x20: 0000000000000000 x21: 00000000ffb14090
      x22: 00000000ffb0f8c8 x23: 0000000000000001
      x24: 00000000ffb14c10 x25: 0000000000000000
      x26: 0000000000000000 x27: 0000000000000000
      x28: 00000000ffb14c70 x29: 00000000ffb0f830
      
      Code: 52800843 52800061 52800e00 97ffcf65 (b9400280)
      Resetting CPU ...
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      2f7dddc2
    • M
      ata: ahci-pci: Use scsi_ops to initialize ops · ada6894f
      Masami Hiramatsu 提交于
      Without this fix, scsi-scan will cause a synchronous abort
      when accessing ops->scan.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      ada6894f
    • C
      arm: iproc: Add higher speed configurations · 9fe79ca0
      Chris Packham 提交于
      Add support for 1.3GHz, 1.35GHz and 1.4GHz parts. This is based on
      equivalent code in Broadcom's LDK 5.0.6.
      Signed-off-by: NChris Packham <judge.packham@gmail.com>
      9fe79ca0
    • L
      ARM: integrator: Drop PCI support · 7dd42be9
      Linus Walleij 提交于
      We didn't convert the Integrator to use DM for PCI in
      time, and we don't use it either so let's just drop
      PCI support from the Integrator.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: NTom Rini <trini@konsulko.com>
      7dd42be9
    • S
      mpc8379erdb: enable DM_USB DM_PCI DM_ETH · c8be85f3
      Sinan Akman 提交于
      Signed-off-by: NSinan Akman <sinan@writeme.com>
      c8be85f3
  2. 06 7月, 2021 11 次提交
    • T
      Merge branch '2021-07-01-update-CI-containers' · 1311dd37
      Tom Rini 提交于
      - General test.py improvements
      - Rewrite the squashfs tests
      - Update our CI container to Ubuntu 20.04 "focal" base.
      - Make some changes to the Azure yaml so that we can have more tests run
        there.
      1311dd37
    • T
      Docker/CI: Update to "focal" and latest build · b1c2102d
      Tom Rini 提交于
      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: NTom Rini <trini@konsulko.com>
      b1c2102d
    • J
      test/py: rewrite sqfsls command test suite · 9bde9b5e
      Joao Marcos Costa 提交于
      Add more details to test cases by comparing each expected line with the
      command's output. Add new test cases:
      - sqfsls at an empty directory
      - sqfsls at a sub-directory
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      Tested-by: Simon Glass <sjg@chromium.org> [on sandbox]
      Signed-off-by: NJoao Marcos Costa <jmcosta944@gmail.com>
      9bde9b5e
    • J
      test/py: rewrite sqfsload command test suite · 208eb2a4
      Joao Marcos Costa 提交于
      The previous strategy to know if a file was correctly loaded was to
      check for how many bytes were read and compare it against the file's
      original size. Since this is not a good solution, replace it by
      comparing the checksum of the loaded bytes against the original file's
      checksum. Add more test cases: files at a sub-directory and non-existent
      file.
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      Tested-by: Simon Glass <sjg@chromium.org> [on sandbox]
      Signed-off-by: NJoao Marcos Costa <jmcosta944@gmail.com>
      208eb2a4
    • J
      test/py: rewrite common tools for SquashFS tests · 04c9813e
      Joao Marcos Costa 提交于
      Remove the previous OOP approach, which was confusing and incomplete.
      Add more test cases by making SquashFS images with various options,
      concerning file fragmentation and its compression. Add comments to
      properly document the code.
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      Tested-by: Simon Glass <sjg@chromium.org> [on sandbox]
      Signed-off-by: NJoao Marcos Costa <jmcosta944@gmail.com>
      04c9813e
    • A
      Azure: Add loop devices and CAP_SYS_ADMIN for sandbox test.py tests · e22ec9c6
      Alper Nebi Yasak 提交于
      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: NAlper Nebi Yasak <alpernebiyasak@gmail.com>
      e22ec9c6
    • A
      Azure: Add fuse device for test.py tests · 1aaaf60d
      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: NAlper Nebi Yasak <alpernebiyasak@gmail.com>
      1aaaf60d
    • A
      tools: docker: Install a readable kernel for libguestfs-tools · f9abaa53
      Alper Nebi Yasak 提交于
      The filesystem and EFI (capsule and secure boot) test setups try to use
      guestmount and virt-make-fs respectively to prepare disk images to run
      tests on. However, these libguestfs tools need a kernel image and fail
      with the following message (revealed in debug/trace mode) if it can't
      find one:
      
          supermin: failed to find a suitable kernel (host_cpu=x86_64).
      
          I looked for kernels in /boot and modules in /lib/modules.
      
          If this is a Xen guest, and you only have Xen domU kernels
          installed, try installing a fullvirt kernel (only for
          supermin use, you shouldn't boot the Xen guest with it).
      
      This failure then causes these tests to be skipped in CIs. Install a
      kernel package in the Docker containers so the CIs can run these
      tests with libguestfs tools again (assuming the container is run with
      necessary host devices and privileges). As this kernel would be only
      used for virtualization, we can use the kernel package specialized for
      that. On Ubuntu systems kernel images are not readable by non-root
      users, so explicitly add read permissions with chmod as well.
      Signed-off-by: NAlper Nebi Yasak <alpernebiyasak@gmail.com>
      Acked-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      f9abaa53
    • A
      test/py: Wait for guestmount worker to exit after running guestunmount · 99f5303c
      Alper Nebi Yasak 提交于
      Some filesystem tests are failing when their image is prepared with
      guestmount, but succeeding if loop mounts are used instead. The reason
      seems to be a race condition the guestmount(1) manual page explains:
      
          When guestunmount(1)/fusermount(1) exits, guestmount may still be
          running and cleaning up the mountpoint.  The disk image will not be
          fully finalized.
      
          This means that scripts like the following have a nasty race condition:
      
           guestmount -a disk.img -i /mnt
           # copy things into /mnt
           guestunmount /mnt
           # immediately try to use 'disk.img' ** UNSAFE **
      
          The solution is to use the --pid-file option to write the guestmount
          PID to a file, then after guestunmount spin waiting for this PID to
          exit.
      
      The Python standard library has an os.waitpid() function for waiting a
      child to terminate, but it cannot wait on non-child processes. Implement
      a utility function that can do this by polling the process repeatedly
      for a given duration, optionally killing the process if it won't
      terminate on its own. Apply the suggested solution with this utility
      function, which makes the failing tests succeed again.
      Signed-off-by: NAlper Nebi Yasak <alpernebiyasak@gmail.com>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      99f5303c
    • A
      test/py: Use loop mounts if guestmount fails in filesystem tests · 8f5f5d3a
      Alper Nebi Yasak 提交于
      If guestmount isn't available on the system, filesystem test setup falls
      back to using loop mounts to prepare its disk images. If guestmount is
      available but fails to work, the tests are immediately skipped. Instead
      of giving up on a guestmount failure, try using loop mounts as an
      attempt to keep tests running.
      
      Also stop checking if guestmount is in PATH, as trying to run a missing
      guestmount can now follow the same failure codepath and fall back to
      loop mounts anyway.
      Signed-off-by: NAlper Nebi Yasak <alpernebiyasak@gmail.com>
      8f5f5d3a
    • A
      env: efi: fix a wrong address dereference · f1eb346e
      AKASHI Takahiro 提交于
      Probably, a pointer to a variable in an inner block should not
      be exposed to an outer block.
      
      Fixes: c70f4481 ("efi_loader: simplify 'printenv -e'")
      Signed-off-by: NAKASHI Takahiro <takahiro.akashi@linaro.org>
      [trini: Don't make guid const now]
      Signed-off-by: NTom Rini <trini@konsulko.com>
      f1eb346e
  3. 05 7月, 2021 2 次提交
  4. 03 7月, 2021 5 次提交
  5. 02 7月, 2021 9 次提交
    • H
      efi_loader: clear OsIndications · 149108a3
      Heinrich Schuchardt 提交于
      After each reboot we must clear flag
      EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable
      OsIndications.
      Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      149108a3
    • M
      efi_loader: Improve the parameter check for QueryVariableInfo() · 417a3c24
      Masami Hiramatsu 提交于
      Improve efi_query_variable_info() to check the parameter settings and
      return correct error code according to the UEFI Specification 2.9,
      and the Self Certification Test (SCT) II Case Specification, June
      2017, chapter 4.1.4 QueryVariableInfo().
      Reported-by: NKazuhiko Sakamoto <sakamoto.kazuhiko@socionext.com>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
      Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      417a3c24
    • H
      efi_loader: missing parentheses in query_console_size · abd62e4d
      Heinrich Schuchardt 提交于
      After if we should use parentheses to keep the code readable.
      
      Fixes: a95f4c88 ("efi_loader: NULL dereference in EFI console")
      Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      abd62e4d
    • I
      efi_loader: Always install FMPs · 6e0184b8
      Ilias Apalodimas 提交于
      We only install FMPs if a CapsuleUpdate is requested.  Since we now have an
      ESRT table which relies on FMPs to build the required information, it
      makes more sense to unconditionally install them. This will allow userspace
      applications (e.g fwupd) to make use of the ERST and provide us with files
      we can use to run CapsuleUpdate on-disk
      Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      6e0184b8
    • I
      efi_loader: Force a single FMP instance per hardware store · b891ff18
      Ilias Apalodimas 提交于
      Chapter 23 of the EFI spec (rev 2.9) says:
      "A specific updatable hardware firmware store must be represented by
      exactly one FMP instance".
      This is not the case for us, since both of our FMP protocols can be
      installed at the same time because they are controlled by a single
      'dfu_alt_info' env variable.
      So make the config options depend on each other and allow the user to
      install one of them at any given time.  If we fix the meta-data provided
      by the 'dfu_alt_info' in the future,  to hint about the capsule type
      (fit or raw) we can revise this and enable both FMPs to be installed, as
      long as they target different firmware hardware stores
      
      Note that we are not using a Kconfig 'choice' on purpose, since we
      want to allow both of those to be installed and tested in sandbox
      Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      b891ff18
    • M
      efi: Fix to use null handle to create new handle for efi_fmp_raw · 3ef77223
      Masami Hiramatsu 提交于
      When running the efidebug capsule disk-update command, the efi_fmp_raw
      protocol installation fails with 2 (EFI_INVALID_PARAMETER) as below.
      This is because the code passes efi_root instead of the handle local var.
      
      => efidebug capsule disk-update
      EFI: Call: efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
        EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbaf5988)
          EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
            EFI: Entry efi_install_protocol_interface(00000000fbaf5988, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6ee8)
              EFI: new handle 00000000fbb37520
            EFI: Exit: efi_install_protocol_interface: 0
          EFI: 0 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
        EFI: Exit: efi_install_multiple_protocol_interfaces: 0
      EFI: 0 returned by efi_install_multiple_protocol_interfaces( &handle, &efi_guid_firmware_management_protocol, &efi_fmp_fit, NULL)
      EFI: Call: efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
        EFI: Entry efi_install_multiple_protocol_interfaces(00000000fbfec648)
          EFI: Call: efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
            EFI: Entry efi_install_protocol_interface(00000000fbfec648, 86c77a67-0b97-4633-a187-49104d0685c7, 0, 00000000fbfa6f18)
              EFI: handle 00000000fbaf8520
            EFI: Exit: efi_install_protocol_interface: 2
          EFI: 2 returned by efi_install_protocol_interface( handle, protocol, EFI_NATIVE_INTERFACE, protocol_interface)
        EFI: Exit: efi_install_multiple_protocol_interfaces: 2
      EFI: 2 returned by efi_install_multiple_protocol_interfaces( &efi_root, &efi_guid_firmware_management_protocol, &efi_fmp_raw, NULL)
      Command failed, result=1
      
      To fix this issue, pass the handle local var which is set NULL right
      before installing efi_fmp_raw as same as the installing efi_fmp_fit.
      (In both cases, the local reference to the handle will be just discarded)
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@linaro.org>
      Signed-off-by: NIlias Apalodimas <ilias.apalodimas@linaro.org>
      Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
      3ef77223
    • T
      Merge branch '2021-07-01-buildtime-gd-sanity-check' into next · 03b61ffe
      Tom Rini 提交于
      - Merge build-time sanity checks to ensure the size of gd doesn't
        change.  This can happen during cleanups due to not all symbols being
        implemented in Kconfig.
      03b61ffe
    • R
      global-data.h: add build-time sanity check of sizeof(struct global_data) · ee3a46a4
      Rasmus Villemoes 提交于
      The layout and contents of struct global_data depends on a lot of
      CONFIG_* preprocessor macros, not all of which are entirely converted
      to Kconfig - not to mention weird games played here and there. This
      can result in one translation unit using one definition of struct
      global_data while the actual layout is another.
      
      That can be very hard to debug. But we already have a mechanism that
      can help catch such bugs at build time, namely the asm-offsets
      machinery which is necessary anyway to provide assembly code with the
      necessary constants. So make sure that every C translation unit that
      include global_data.h actually sees the same size of struct
      global_data as that which was seen by the asm-offsets.c TU.
      
      It is likely that this patch will break the build of some boards. For
      example, without the patch from Matt Merhar
      (https://lists.denx.de/pipermail/u-boot/2021-May/450135.html) or some
      other fix, this breaks P2041RDB_defconfig:
      
        CC      arch/powerpc/lib/traps.o
        AS      arch/powerpc/cpu/mpc85xx/start.o
      In file included from include/asm-generic/global_data.h:26,
                       from ./arch/powerpc/include/asm/global_data.h:109,
                       from include/init.h:21,
                       from arch/powerpc/lib/traps.c:7:
      include/linux/build_bug.h:99:41: error: static assertion failed: "sizeof(struct global_data) == GD_SIZE"
         99 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
            |                                         ^~~~~~~~~~~~~~
      include/linux/build_bug.h:98:34: note: in expansion of macro ‘__static_assert’
         98 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
            |                                  ^~~~~~~~~~~~~~~
      include/asm-generic/global_data.h:470:1: note: in expansion of macro ‘static_assert’
        470 | static_assert(sizeof(struct global_data) == GD_SIZE);
            | ^~~~~~~~~~~~~
      make[1]: *** [scripts/Makefile.build:266: arch/powerpc/lib/traps.o] Error 1
      make: *** [Makefile:1753: arch/powerpc/lib] Error 2
      make: *** Waiting for unfinished jobs....
      Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      ee3a46a4
    • R
      build_bug.h: add wrapper for _Static_assert · ef0f4e83
      Rasmus Villemoes 提交于
      [Linux commit 6bab69c65013bed5fce9f101a64a84d0385b3946]
      
      BUILD_BUG_ON() is a little annoying, since it cannot be used outside
      function scope.  So one cannot put assertions about the sizeof() a
      struct next to the struct definition, but has to hide that in some more
      or less arbitrary function.
      
      Since gcc 4.6 (which is now also the required minimum), there is support
      for the C11 _Static_assert in all C modes, including gnu89.  So add a
      simple wrapper for that.
      
      _Static_assert() requires a message argument, which is usually quite
      redundant (and I believe that bug got fixed at least in newer C++
      standards), but we can easily work around that with a little macro
      magic, making it optional.
      
      For example, adding
      
        static_assert(sizeof(struct printf_spec) == 8);
      
      in vsprintf.c and modifying that struct to violate it, one gets
      
      ./include/linux/build_bug.h:78:41: error: static assertion failed: "sizeof(struct printf_spec) == 8"
       #define __static_assert(expr, msg, ...) _Static_assert(expr, "" msg "")
      
      godbolt.org suggests that _Static_assert() has been support by clang
      since at least 3.0.0.
      Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      ef0f4e83
  6. 01 7月, 2021 6 次提交
  7. 30 6月, 2021 1 次提交