dgit.raspbian.org Git - u-boot.git/log

Merge version 2024.01+dfsg-5+rpi1 and 2024.01+dfsg-6 to produce 2024.01+dfsg-6+rpi1

Merge u-boot (2024.01+dfsg-6) import into refs/heads/workingbranch

arm: dts: k3-am625*: Don't try to build the final firmware images

The final firmware images require the inclusion of firmware elements that
are not yet available in linux-firmware. Build the U-Boot elements so that
these can be combined with the other elements at a later date.

Signed-off-by: Martyn Welch <martyn.welch@collabora.com>
Gbp-Pq: Topic am62x
Gbp-Pq: Name 0008-arm-dts-k3-am625-Don-t-try-to-build-the-final-firmwa.patch

[PATCH] riscv: sifive: fu740: reduce DDR speed from 1866MT/s to 1600MT/s

To: u-boot@lists.denx.de
Cc: Thomas Perrot <thomas.perrot@bootlin.com>
Message-ID: <20240222145203.2659671-1-thomas.perrot@bootlin.com>
Origin: https://patchwork.ozlabs.org/project/uboot/patch/20240222145203.2659671-1-thomas.perrot@bootlin.com/

It appears that there is some timing marginality either in the
board layout or the SoC that results in occasional data corruption
on some boards.
We observed this issue on some of the new HiFive Unmatched RevB
boards during volume production as well as some of the original
HiFive Unmatched boards from 2021 in our possession. This means
that there are other boards out there that might have the issue
too.

We have done some limited testing with DDR4 at 1600MT/s and
faulty boards (failing at 1866MT/s) passed.
We plan further testing after we procure a temperature chamber.

Signed-off-by: Thomas Perrot <thomas.perrot@bootlin.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name riscv-sifive-fu740-reduce-DDR-speed-from-1866MT-s-to-1600MT-s.patch

[PATCH 1/1] serial: move sbi_dbcn_available to .data section

To: Tom Rini <trini@konsulko.com>
Cc: Rick Chen <rick@andestech.com>, Leo Yu-Chi Liang <ycliang@andestech.com>,
u-boot@lists.denx.de,
Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Message-ID: <20240226163226.126288-1-heinrich.schuchardt@canonical.com>
Origin: https://patchwork.ozlabs.org/project/uboot/patch/20240226163226.126288-1-heinrich.schuchardt@canonical.com/
Bug-Debian: https://bugs.debian.org/1060682

U-Boot SPL loads the device-tree directly behind main U-Boot overlapping
the .bss section. reserve_fdt() is called in board_init_f() to relocate the
device-tree to a safe location.

Debug UARTs are enabled before board_init_f(). With sbi_dbcn_available in
the .bss section the device-tree is corrupted when _debug_uart_init() is
called in the SBI serial driver. Move the variable to the .data section.

Link: https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2054091
Fixes: dfe08374943c ("risc-v: implement DBCN based debug console")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name serial-move-sbi_dbcn_available-to-.data-section.patch

[PATCH] configs: visionfive2: Disable ENV_IS_NOWHERE

The VisionFive 2 board supports saving the u-boot environment settings
are saved to on-board SPI flash. However the defconfig enables both
ENV_IS_NOWHERE and ENV_IS_IN_SPI_FLASH, preventing the "saveenv" command
to work. Fix that by disabling ENV_IS_NOWHERE.

Fixes: 7d79bed00c9e ("configs: starfive: Enable environment in SPI flash support")
Reported-by: E Shattow <lucent@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name configs-visionfive2-Disable-ENV_IS_NOWHERE.patch

[PATCH] board: starfive: handle compatible property in dynamic DT configuration

The difference between the StarFive VisionFive 2 1.2A and 1.3B boards is
handled dynamically by looking at the PCB version in the EEPROM in order
to have a single u-boot version for both versions of the board. While
the "model" property is correctly handled, the "compatible" one is
always the the one of version 1.3b.

This patch add support for dynamically configuring that property.

Fixes: 9b7060bd15e7 ("riscv: dts: jh7110: Combine the board device tree files of 1.2A and 1.3B")
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name board-starfive-handle-compatible-property-in-dynamic.patch

[PATCH 2/2] efi_loader: create common function to free struct efi_disk_obj

Current error handling of creating raw disk/partition has
following issues.
- duplicate free for EFI handle, EFI handle is already freed
in efi_delete_handle()
- missing free for struct efi_device_path and
struct efi_simple_file_system_protocol in some error paths

To address those issues, this commit creates the common function
to free the struct efi_disk_obj resources and calls it in case
of error.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name efi_loader-create-common-function-to-free-struct-efi.patch

[PATCH 1/2] efi_loader: avoid pointer access after calling efi_delete_handle

efi_delete_handle() calls efi_purge_handle(), then it finally
frees the EFI handle.
Both diskobj and handle variables in efi_disk_remove() have
the same pointer, we can not access diskobj->dp after calling
efi_delete_handle().

This commit saves the struct efi_device_path pointer before
calling efi_delete_handle(). This commit also fixes the
missing free for volume member in struct efi_disk_obj.

This commit also removes the container_of() calls, and
adds the TODO comment of missing efi_close_protocol() call
for the parent EFI_BLOCK_IO_PROTOCOL.

Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Gbp-Pq: Topic riscv64
Gbp-Pq: Name efi_loader-avoid-pointer-access-after-calling-efi_de.patch

[PATCH] Makefile: Use relative paths for debugging symbols.

The KBUILD_CFLAGS and KBUILD_AFLAGS variables are adjusted to use
-ffile-prefix-map and --debug-prefix-map, respectively, to use
relative paths for occurrences of __FILE__ and debug paths.

This enables reproducible builds regardless of the absolute path to
the build directory:

https://reproducible-builds.org/docs/build-path/

Series-to: u-boot
Signed-off-by: Vagrant Cascadian <vagrant@reproducible-builds.org>
Gbp-Pq: Name Makefile-Use-relative-paths-for-debugging-symbols.patch

enable support for secure boot on qemu arm64/amd64

Secure boot is now supported upstream in EFI mode. It is disabled
by default, and can be enabled by loading keys from the console:
https://u-boot.readthedocs.io/en/latest/develop/uefi/uefi.html#configuring-uefi-secure-boot

Gbp-Pq: Topic qemu
Gbp-Pq: Name efi-secure-boot.patch

rockchip-inno-usb

Downloaded from:
https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io

Downloaded from:
https://patchwork.ozlabs.org/project/uboot/patch/20210406151059.1187379-1-icenowy@aosc.io

From: Icenowy Zheng <icenowy@aosc.io>
To: Simon Glass <sjg@chromium.org>, Kever Yang <kever.yang@rock-chips.com>,
Frank Wang <frank.wang@rock-chips.com>,
Jagan Teki <jagan@amarulasolutions.com>
Cc: u-boot@lists.denx.de,
Icenowy Zheng <icenowy@aosc.io>
Subject: [PATCH] phy: rockchip: inno-usb2: fix hang when multiple controllers
exit
Date: Tue, 6 Apr 2021 23:10:59 +0800
Message-Id: <20210406151059.1187379-1-icenowy@aosc.io>

The OHCI and EHCI controllers are both bound to the same PHY. They will
both do init and power_on operations when the controller is brought up
and both do power_off and exit when the controller is stopped. However,
the PHY uclass of U-Boot is not as sane as we thought -- they won't
maintain a status mark for PHYs, and thus the functions of the PHYs
could be called for multiple times. Calling init/power_on for multiple
times have no severe problems, however calling power_off/exit for
multiple times have a problem -- the first exit call will stop the PHY
clock, and power_off/exit calls after it still trying to write to PHY
registers. The write operation to PHY registers will fail because clock
is already stopped.

Adapt the count mechanism from phy-sun4i-usb to both init/exit and
power_on/power_off functions to phy-rockchip-inno-usb2 to fix this
problem. With this stopping USB controllers (manually or before booting
a kernel) will work.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Fixes: ac97a9ece14e ("phy: rockchip: Add Rockchip USB2PHY driver")
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Gbp-Pq: Topic rockchip
Gbp-Pq: Name rockchip-inno-usb.patch

disable-fit-image-tests

Disable FIT image tests.

FIT images were made more robust in light of CVE-2021-27097 and
CVE-2021-27138, but test-imagetools.sh was not updated to reflect
those changes.

Reported upstream: https://lists.denx.de/pipermail/u-boot/2021-March/443460.html

Gbp-Pq: Name disable-fit-image-tests

[PATCH] arm: config: fix default console only to specify the device

This reverts commit 767edf0f6b3eaa0303f3fd6afdc14ddce0aca70c and restores
commit 232ed3ca534708527a9515c7c41bc3542949525c.

Debian's flash-kernel expect the console variable to just contain the device,
because it will set the bootargs to "console=${console}". So revert adding
"console=" to the console parameter, but also adjust the shipped bootscripts
for exynos boards to cope with it.

Bug-Debian: https://bugs.debian.org/920116
Signed-off-by: Benjamin Drung <bdrung@debian.org>
Gbp-Pq: Topic exynos
Gbp-Pq: Name 0001-arm-config-fix-default-console-only-to-specify-the-d.patch

test-imagetools-test-fixes

This patch allows testing in an alternate directory and also detects
failures to execute commands, treating that as a failure.

Gbp-Pq: Name test-imagetools-test-fixes

Add spl/arndale-spl.bin rule

Gbp-Pq: Topic arndale
Gbp-Pq: Name board-spl-rule.diff

[PATCH] arm: sunxi: Reduce inrush current on Olimex A20-OLinuXino_MICRO configs

This change fix reboot, both configurations
were tested on my Olimex A20 Micro Rev E with debian-12.

This issue was also present and fixed on A20 Lime2 (in 8311e84b18),
quoting Olliver Schinagl:

    The lime2 features a too large capacitor on the LDO3 output, which
    causes the PMIC to shutdown when enabling power. To be able to still
    boot up however, we must gradually enable power on LDO3 for this board.
    We do this by enabling both the inrush quirk and the maximum slope the
    AXP209 supports.

Link: https://bugs.debian.org/1060752
Series-to: u-boot@lists.denx.de
Series-links: 1:187331
Series-version: 2
Cc: Olliver Schinagl <oliver@schinagl.nl>
Cc: Priit Laes <plaes@plaes.org>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Philippe Coval <rzr@users.sf.net>
Series-changes: 2
- Add qirk to eMMC configuration of same machine
Forwarded: http://patchwork.ozlabs.org/project/uboot/list/?series=394499
Bug-Debian: https://bugs.debian.org/1060752
Applied-Upstream: https://source.denx.de/u-boot/u-boot/-/commit/c93a6fc8f5313b2aa7081d53c3061c7c1b94afca#v2024.04-rc3-48-gc93a6fc8f5
Signed-off-by: Philippe Coval <rzr@users.sf.net>
Gbp-Pq: Topic allwinner
Gbp-Pq: Name 0001-arm-sunxi-Reduce-inrush-current-on-Olimex-A20-OLinuX.patch

u-boot (2024.01+dfsg-6) unstable; urgency=medium

  * Use system dtc from device-tree-compiler (Closes: #1091125)
  * debian/control: Move device-tree-compiler from Build-Depends-Arch to
    Build-Depends.
  * debian/control: Mark python3-libfdt, python3-jsonschema, and
    python3-yaml as native to fix cross-building.
  * debian/control: Update to Standards-Version 4.7.0.

[dgit import unpatched u-boot 2024.01+dfsg-6]

Import u-boot_2024.01+dfsg-6.debian.tar.xz

[dgit import tarball u-boot 2024.01+dfsg-6 u-boot_2024.01+dfsg-6.debian.tar.xz]

Commit Debian 3.0 (quilt) metadata

[dgit (11.11) quilt-fixup]

Always pass armv7 flags when building for armv7

don't build mips* targets for qemu.

Manual merge of version 2021.01+dfsg-5+rpi1 and 2024.01+dfsg-5 to produce 2024.01+dfsg-5+rpi1

Merge u-boot (2024.01+dfsg-5) import into refs/heads/workingbranch