This patch adds a limited pulse-width modulator to sandbox's Chromium OS
Embedded Controller emulation. The emulated PWM device supports multiple
channels but can only set a duty cycle for each, as the actual EC
doesn't expose any functionality or information other than that. Though
the EC supports specifying the PWM channel by its type (e.g. display
backlight, keyboard backlight), this is not implemented in the emulation
as nothing in U-Boot uses this type specification.

This emulated PWM device is then used to test the Chromium OS PWM driver
in sandbox. Adding the required device node to the sandbox test
device-tree unfortunately makes it the first PWM device, so this also
touches some other tests to make sure they still use the sandbox PWM.
Signed-off-by: NAlper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Each _device_ belonging to a given uclass of course has its own ->ops,
of a type determined by and known to the uclass.

However, no instance of a uclass_driver seems to populate ->ops, and
the only reference to it in code is this relocation.

Moreover, it's not really clear what could sensibly be assigned; it
would have to be some "struct uclass_ops *" providing a set of methods
for the core to call on that particular uclass, but should the need
for that ever arise, it would be better to have a member of that
particular type instead of void*.
Signed-off-by: NRasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: NSimon Glass <sjg@chromium.org>

GCC provides a symbol _init in crti.o on x86_64 and aarch64 but not on
RISC-V. The following lines leads to a build error for sandbox_defconfig on
RISC-V due to the missing symbol:

    common/board_f.c:269:
    #elif defined(CONFIG_SANDBOX) || defined(CONFIG_EFI_APP)
            gd->mon_len = (ulong)&_end - (ulong)_init;

The sandbox code is not copied into the memory allocated using mmap().
Hence we can safely use gd->mon_len = 0 to avoid the reference to _init.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NRick Chen <rick@andestech.com>

state_uninit() and dm_uninit() are mutually exclusive:

state_uninit() prints via drivers. So it cannot be executed after
dm_uninit().

dm_uninit() requires memory. So it cannot be executed after state_uninit()
which releases all memory.

Just skip dm_uninit() when resetting the sandbox. We will wake up in a new
process and allocate new memory. So this cleanup is not required. We don't
do it in sandbox_exit() either.

This avoids a segmentation error when efi_reset_system_boottime() is
invoked by a UEFI application.
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Addresses in state->ram_buf must be in the low 4 GiB of the address space.
Otherwise we cannot correctly fill SMBIOS tables. This shows up in warnings
like:

    WARNING: SMBIOS table_address overflow 7f752735e020

Ensure that state->ram_buf is initialized by the first invocation of
os_malloc().
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Define LOG_CATEGORY for all uclass to allow filtering with
log command.
Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

At present if sandbox crashes it prints a message and tries to exit. But
with the recently introduced signal handler, it often seems to get stuck
in a loop until the stack overflows:

Segmentation violation

Segmentation violation

Segmentation violation

Segmentation violation

Segmentation violation

Segmentation violation

Segmentation violation
...

The signal handler is only useful for a few tests, as I understand it.
Make it optional.
Signed-off-by: NSimon Glass <sjg@chromium.org>

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Signed-off-by: NTom Rini <trini@konsulko.com>

- configs: libretech: set SPI mode to 0 to fix SPI NOR Flash probe

Kconfig defaults to mode 3 if CONFIG_SF_DEFAULT_MODE is not set.
It becomes an issue since meson_spifc does not support SPI_CPHA.
Needed after commit e2e95e5e ("spi: Update speed/mode on change").

Fixes: e2e95e5e ("spi: Update speed/mode on change")
Signed-off-by: NDa Xue <da@libre.computer>
[narmstrong: reformated commit reference & added Fixes tag]
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

Pull request for efi-2021-07-rc6

Bug fixes:

* improve specification compliance of UEFI capsule updates
* allow capsule update on-disk without checking OsIndications
* provide parameter checks for QueryVariableInfo()

replace CONFIG_AUTOBOOT_USE_MENUKEY with CONFIG_AUTOBOOT_MENUKEY
Signed-off-by: NDa Xue <da@libre.computer>

Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.

In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable.  The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by the submitter to trigger processing of the
capsule on the next reboot.

Let's add a config option which ignores the bit and just relies on the
capsule being present. Since U-Boot deletes the capsule while processing
it, we won't end up applying it multiple times.

Note that this is allowed for all capsules. In the future, once
authenticated capsules are fully supported, we can limit the functionality
to those only.
Signed-off-by: Napalos <ilias.apalodimas@linaro.org>

Reword Kconfig description.
Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>

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>

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>

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>

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>

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>

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>

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

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>

[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>

Merge tag 'xilinx-for-v2021.10' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next

Xilinx changes for v2021.10

clk:
- Add driver for Xilinx Clocking Wizard IP

fdt:
- Also record architecture in /fit-images

net:
- Fix plat/priv data handling in axi emac
- Add support for 10G/25G speeds

pca953x:
- Add missing dependency on i2c

serial:
- Fix dependencies for DEBUG uart for pl010/pl011
- Add setconfig option for cadence serial driver

watchdog:
- Add cadence wdt expire now function

zynq:
- Update DT bindings to reflect the latest state and descriptions

zynqmp:
- Update DT bindings to reflect the latest state and descriptions
- SPL: Add support for ECC DRAM initialization
- Fix R5 core 1 handling logic
- Enable firmware driver for mini configurations
- Enable secure boot, regulators, wdt
- Add support xck devices and 67dr
- Add psu init for sm/smk-k26 SOMs
- Add handling for MMC seq number via mmc_get_env_dev()
- Handle reserved memory locations
- Add support for u-boot.itb generation for secure OS
- Handle BL32 handoffs for secure OS
- Add support for 64bit addresses for u-boot.its generation
- Change eeprom handling via nvmem aliases

Add zynqmp 67dr silicon to zynqmp device id table.
Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com>
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

It is working in a way that only minimal timeout is setup to reach
expiration just right after it is setup.
Please make sure that PMUFW is compiled with ENABLE_EM flag.

On U-Boot prompt you can test it like:
ZynqMP> wdt dev watchdog@fd4d0000
ZynqMP> wdt list
watchdog@fd4d0000 (cdns_wdt)
ZynqMP> wdt dev
dev: watchdog@fd4d0000
ZynqMP> wdt expire
(And reset should happen here)
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

Enable watchdog command to be able to work with watchdogs.
Signed-off-by: NMichal Simek <michal.simek@xilinx.com>

- Cypress s25hl-t/s25hs-t support (Takahiro Kuwano)

This reverts commit 4e1903a6.

This local commit was not intended to be pushed out.
Signed-off-by: NTom Rini <trini@konsulko.com>