Tom Rini [Mon, 1 Jul 2024 01:03:14 +0000 (19:03 -0600)]
Revert "Merge patch series "zlib: Address CVE-2016-9841""
This series brings our zlib code more up to date. However, it drops an
important performance improvement that is required on some of our
supported platforms in order to boot Linux before the watchdog resets
the system. Furthermore, the "post increment" version of this
performance loop was not tested, so while we can fix it, it would then
require re-testing all platforms. At this point in time, we will revert
updating zlib (which has had a potential security issue since 2016) and
fix this in the v2024.10 release.
Tom Rini [Fri, 28 Jun 2024 19:55:10 +0000 (13:55 -0600)]
Merge patch series "Bug-fixes for a few boards (reduced series)"
Simon Glass <sjg@chromium.org> says:
This series includes fixes to get some rockchip and nvidia boards
working again. It also drops the broken Beaglebone Black config and
provides a devicetree fix for coral (x86).
Simon Glass [Thu, 27 Jun 2024 08:29:48 +0000 (09:29 +0100)]
rockchip: bob: kevin: Disable dcache in SPL
This causes a hang, so disable it. Unfortunately the RAM-size fix does
not resolve the problem and I am unsure what is wrong. As soon as the
cache is enabled the board appears to hang.
Fixes: 6d8cdfd1536 ("rockchip: spl: Enable caches to speed up checksum validation") Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 27 Jun 2024 08:29:46 +0000 (09:29 +0100)]
power: regulator: Handle autoset in regulators_enable_boot_on()
With a recent change, regulators_enable_boot_on() returns an error if a
regulator is already set. Check for and handle this situation.
Fixes: d99fb64a98a power: regulator: Only run autoset once for each regulator Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Simon Glass [Thu, 27 Jun 2024 08:29:44 +0000 (09:29 +0100)]
x86: Set a board-size limit for chromebook_link
Set a size limit for this board so that we get a build error if it grows
too much.
Note that the limit is approximately, since it does not include the FDT,
microcode and fdtmap, which can change in size. However this board is
fairly stable, so overflowing this limit will likely result in the image
not fitting in the ROM space available for U-Boot.
Simon Glass [Thu, 27 Jun 2024 08:29:43 +0000 (09:29 +0100)]
tpm: Avoid code bloat when not using EFI_TCG2_PROTOCOL
It does not make sense to enable all SHA algorithms unless they are
needed. It bloats the code and in this case, causes chromebook_link to
fail to build. That board does use the TPM, but not with measured boot,
nor EFI.
Since EFI_TCG2_PROTOCOL already selects these options, we just need to
add them to MEASURED_BOOT as well.
Note that the original commit combines refactoring and new features,
which makes it hard to see what is going on.
Fixes: 97707f12fda tpm: Support boot measurements Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Thu, 27 Jun 2024 08:29:42 +0000 (09:29 +0100)]
nvidia: nyan-big: Disable debug UART
This cannot be enabled early in boot since some other init is needed.
At this point it is unclear exactly what init is needed, so disable
the debug UART to avoid a hang.
Bryan Brattlof [Wed, 19 Jun 2024 19:12:30 +0000 (14:12 -0500)]
board: beagle: beagleplay: enable OF_SYSTEM_SETUP
Unfortunately when enabling FDT fixups for the AM62x family of SoCs and
moving TF-A to the bottom of RAM we missed the BeaglePlay. This is
causing Linux's memory allocator to clobber TF-A and break its boot.
Enable OF_SYSTEM_SETUP to fixup the kernel's FDT to inform it of the
actual location of the firmware
CC: Andrew Davis <afd@ti.com> CC: Nishanth Menon <nm@ti.com> CC: Robert Nelson <robertcnelson@gmail.com> Reported-by: Dhruva Gole <d-gole@ti.com> Signed-off-by: Bryan Brattlof <bb@ti.com> Acked-by: Andrew Davis <afd@ti.com> Tested-by: Robert Nelson <robertcnelson@gmail.com> Reviewed-by: Nishanth Menon <nm@ti.com> Acked-by: Chirag Shilwant <c-shilwant@ti.com> Tested-by: Dhruva Gole <d-gole@ti.com>
Tom Rini [Mon, 24 Jun 2024 15:49:37 +0000 (09:49 -0600)]
Merge tag 'tpm-master-24062024' of https://source.denx.de/u-boot/custodians/u-boot-tpm
When the EFI TCG measurement code moved from EFI to the TPM subsystem for
general use some prototypes changed from returning efi_status_t to int,
which is more appropriate for the non-EFI APIs. However, some of the
EFI callsites never changed and we ended up assigning the int value to
efi_status_t.
This is unlikely to cause any problems, apart from returning invalid
values on failures and violating the EFI spec.
Ilias Apalodimas [Sat, 22 Jun 2024 14:35:38 +0000 (17:35 +0300)]
efi_loader: fix the return values on efi_tcg
A while back we moved the core functions of the EFI TCG protocol to the
TPM APIs in order for them to be used with bootm, booti etc.
Some prototypes changed from returning efi_status_t to int, which is more
appropriate for the non-EFI APIs. However, some of the EFI callsites never
changed and we ended up assigning the int value to efi_status_t.
This is unlikely to cause any problems, apart from returning invalid
values on failures and violating the EFI spec. Let's fix them
by looking at the new return code and map it to the proper EFI return
code on failures.
Fixes: commit 97707f12fdab ("tpm: Support boot measurements") Fixes: commit d6b55a420cfc ("efi_loader: startup the tpm device when installing the protocol") Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Ilias Apalodimas [Sat, 22 Jun 2024 14:35:37 +0000 (17:35 +0300)]
tpm: fix the return code, if the eventlog buffer is full
We currently return 'No space left on device' if the eventlong buffer
we allocated is not enough. On a similar check later on that function
during the call to tcg2_log_init() we return 'No buffer space
available'. So switch both error codes to -ENOBUFS since we are always
checking a buffer and not a device.
Fixes: commit 97707f12fdab ("tpm: Support boot measurements") Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
doc: board: ti: Add capsule documentation for TI K3 devices
Added introductory documentation about capsule support for TI devices,
including links to more detailed information.
Also added a note in the build secction that points to the host package
dependency docs.
This patch is followup from a request in the series introducing capsule
update for TI boards.
https://lore.kernel.org/r/20240618145058.552eapp5iiz772ej@hardcore
Signed-off-by: Jonathan Humphreys <j-humphreys@ti.com>
Alexander Dahl [Fri, 21 Jun 2024 07:47:20 +0000 (09:47 +0200)]
doc: develop: testing: Fix reference to test writing section
Add missing colon in :doc: link.
Fixes: fc3283314539 ("doc: Explain briefly how to write new tests") Signed-off-by: Alexander Dahl <ada@thorsis.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Alexander Dahl [Fri, 21 Jun 2024 07:47:19 +0000 (09:47 +0200)]
doc: develop: testing: Fix broken reference to pytest suite help
This should have been adapted directly with or after v2021.01-693-gca6583d4e08 ("doc: move test/README to HTML
documentation") or v2021.01-694-g0157619d5c8 ("doc: move
test/py/README.md to HTML documentation") already.
Signed-off-by: Alexander Dahl <ada@thorsis.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Marek Vasut [Fri, 19 Apr 2024 22:03:09 +0000 (00:03 +0200)]
ARM: dts: stm32: Ping IWDG on exit from PSCI suspend code
Make sure the OS would not get any spurious IWDG pretimeout IRQ
right after the system wakes up. This may happen in case the SoC
got woken up by another source than the IWDG pretimeout and the
pretimeout IRQ arrived immediately afterward, but too late to be
handled by the suspend main loop. In case either of the IWDG is
enabled, ping it first and then return to the OS.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io>
Ravi Minnikanti [Sat, 27 Apr 2024 16:15:28 +0000 (09:15 -0700)]
mtd: nand: pxa3xx: Incorrect bitflip return on page read
Once a page is read with higher bitflips all subsequent reads
are returning the same bitflip value even though they have none.
max_bitflip variable is not being reset to 0 across page reads.
This is causing problems like incorrectly
marking erase blocks bad by UBI and causing read failures.
Verified the change with both MTD reads and UBI.
This change is inline with other NFC drivers.
Sample error log where a block is marked bad incorrectly:
ubi0: fixable bit-flip detected at PEB 125
ubi0: run torture test for PEB 125
ubi0: fixable bit-flip detected at PEB 125
ubi0 error: torture_peb: read problems on freshly erased PEB 125,
must be bad
ubi0 error: erase_worker: failed to erase PEB 125, error -5
ubi0: mark PEB 125 as bad
Link: https://lore.kernel.org/all/ea0422cd-a8e6-3c36-f551-a0142893301b@marvell.com Signed-off-by: rminnikanti <rminnikanti@marvell.com> Reviewed-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: rminnikanti <rminnikanti@marvell.com> Acked-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Tom Rini [Sun, 16 Jun 2024 15:10:53 +0000 (09:10 -0600)]
Merge tag 'efi-2024-07-rc5-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2024-07-rc5-2
Documentation:
* Correct links and board names in PHYTEC board descriptions.
* Describe UEFI measured boot.
* Fix typos in include/bootmeth.h.
* Fix link reference to general verified boot docs.
Ilias Apalodimas [Fri, 14 Jun 2024 12:09:50 +0000 (15:09 +0300)]
tpm: measure DTB in PCR1 instead of PCR0
The PC client spec [0], doesn't describe measurements for DTBs. It does
describe what do to for ACPI tables though.
There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS,
and Embedded Drivers and they explicitly mention ACPI in there. There's
no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform Configuration.
However, in Figure 6 -- PCR Mapping of UEFI Components ACPI is shown
in PCR1. The general description also mentions PCR0 is for code and PCR1
is for data such as ACPI and SMBIOS.
So let's switch over the DTB measurements to PCR1 which seems a better
fit.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Eddie James <eajames@linux.ibm.com>
Daniel Schultz [Wed, 12 Jun 2024 16:16:38 +0000 (09:16 -0700)]
doc: board: phytec: phycore-am64x: Fix Link to Documentation
We moved our documentation to another hoster and therefore the URL
changed. Point to the latest documentation instead of release versions
to not link out-dated documentation.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
Daniel Schultz [Wed, 12 Jun 2024 16:16:37 +0000 (09:16 -0700)]
doc: board: phytec: phycore-am62x: Fix Link to Documentation
We moved our documentation to another hoster and therefore the URL
changed. Point to the latest documentation instead of release versions
to not link out-dated documentation.
Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
board: imx8mn_s2: Update timing with production one
The timing upstream was wrong corresponding to the production.
This come evident after commit b614ddb5d33
(ddr: imx: Save the FW loading if it hasn't changed). This
change fix booting from usb
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Marek Vasut [Thu, 6 Jun 2024 13:02:46 +0000 (15:02 +0200)]
ARM: stm32: Fix livetree conversion on STM32MP15xx DHSOM
Unlike fdt_node_check_compatible() which returns 0 if node is compatible,
ofnode_device_is_compatible() return true which is non-zero if node is
compatible. The intention of the code is to exit from the function in
case the node is not compatible with "micrel,ks8851-mll". Add the missing
invert into the conditional to reinstate original behavior.
This exposes a follow up problem caused by conversion to DM based FMC2 EBI
driver, where the FMC2 EBI is not configured when accessed by this code.
Probe the KS8851 MAC, which also configures the FMC2 EBI as a dependency,
so that the KS8851 MAC CCR register can be accessed over the FMC2 EBI bus
and checked for EEPROM present bit.
Fixes: 5a605b7c8615 ("board: dhelectronics: stm32mp1: convert to livetree") Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Quentin Schulz [Thu, 6 Jun 2024 11:44:04 +0000 (13:44 +0200)]
rockchip: mkimage: fix mkimage -l for header v1
There are two paths to reach this function, either through mkimage -l or
through dumpimage -l. The latter passes a NULL imagename while the
former passes an empty string. Therefore, let's make both tools behave
the same by handling the empty string the same way as for NULL.
Without this, the only way to get some information out of mkimage -l is
to provide "-n rk3399" for example, which isn't documented in the usage
of the tool.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 12 May 2024 12:16:15 +0000 (12:16 +0000)]
pinctrl: rockchip: rv1126: Fix support for IOMUX_L_SOURCE_PMU flag
GPIO0_C0-C4 iomux is set using PMUGRF_GPIO0C_IOMUX_L reg on RV1126. This
is indicated using the IOMUX_L_SOURCE_PMU flag. Fix reading current mux
by fully adopting the IOMUX_L_SOURCE_PMU related code in Linux kernel.
Based on Linux commit fd4ea48688c6 ("pinctrl: rockchip: Add RV1126
pinctrl support").
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jonas Karlman [Sun, 12 May 2024 12:16:14 +0000 (12:16 +0000)]
pinctrl: rockchip: rk3188: Fix support for IOMUX_GPIO_ONLY flag
GPIO0_A0-A7 on RK3188 is IOMUX_GPIO_ONLY, however, trying to set gpio
mux return an -ENOTSUPP error code. Fix this by validating using the mux
function type and not the iomux flag.
Based on Linux commit c4a532dee6b6 ("pinctrl: rockchip: handle first
half of rk3188-bank0 correctly").
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Quentin Schulz [Wed, 5 Jun 2024 09:33:21 +0000 (11:33 +0200)]
regulator: rk8xx: fix incorrect device used for _ldo_[sg]et_suspend_value
_ldo_get_suspend_value and _ldo_set_suspend_value get passed the parent
of the regulator (so the pmic) as first argument, therefore this udevice
should be used for pmic_* callbacks instead of using the parent of the
pmic.
To avoid further confusion, let's rename the argument to pmic instead of
dev, highlighting which kind of device we expect as argument.
Fixes: f047e4ab9762 ("regulator: rk8xx: add indirection level for some ldo callbacks") Reported-by: Simon Glass <sjg@chromium.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> # chromebook-bob
Chris Morgan [Tue, 21 May 2024 15:45:49 +0000 (10:45 -0500)]
board: rockchip: rgxx3: Use sdmmc0 as first device
Some of the rgxx3 devices do not have a way to recover from a poor
flash of a bootloader to eMMC. Set the device to always attempt to boot
from sdmmc0 first which ensures that we can override the boot from
emmc if we have a card present with a valid fit signature. The
expectation is that this will protect from the very unlikely chance
we have a valid FIT signature on the eMMC but the U-Boot stage fails
for some other reason.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
On some of the supported devices the adc detect code always returns
that the button has been pushed, and as a result the device will
not boot normally.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Quentin Schulz [Mon, 10 Jun 2024 16:11:44 +0000 (18:11 +0200)]
cmd: sound: fix help text
There's never been a -q or -s argument handled in the command, so let's
remove it. This was highlighted during review[1] but somehow still got
through.
While at it, slightly "reword" in the help text how the len + freq
arguments are defined. Indeed, len and freq work in pair, it is possible
to define none of either, n of both, or n - 1 of freq if there are n
len, in which case the freq that goes with the last len would be the n -
1 (and not the default of 400Hz if neither len nor freq is passed). I
assume this isn't what's expected but leaving it for another patch if
need be to fix what happens in that very odd scenario.
Tom Rini [Thu, 6 Jun 2024 16:44:25 +0000 (10:44 -0600)]
doc/sphinx, test/py: Update requests module to 2.32.2
The issue described in https://github.com/psf/requests/pull/6655 has
been assigned as a security issue. While unlikely to be exploited in our
usage, update to the current release to fix it. Furthermore, upstream
has now moved on to v2.23.2 as the release to use which has all of the
issues resolved.
Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini@konsulko.com>
According to UEFI v2.10 spec section 8.2.6, if a caller invokes the
SetVariables() service, it will produce a digest from hash(VariableName,
VendorGuid, Attributes, TimeStamp, DataNew_variable_content), then the
firmware that implements the SetVariable() service will compare the
digest with the result of applying the signer’s public key to the
signature. For EFI variable append write, efitools sign-efi-sig-list has
an option "-a" to add EFI_VARIABLE_APPEND_WRITE attr, and u-boot will
drop this attribute in efi_set_variable_int(). So if a caller uses
"sign-efi-sig-list -a" to create the authenticated variable, this append
write will fail in the u-boot due to "hash check failed".
This patch resumes writing the EFI_VARIABLE_APPEND_WRITE attr to ensure
that the hash check is correct. And also update the "test_efi_secboot"
test case to compliance with the change.
Fiona Klute [Sat, 18 May 2024 10:47:05 +0000 (12:47 +0200)]
doc: Detailed example for netconsole setup
This adds details that I would have liked to have readily available,
in particular how to activate the network interface before enabling
netconsole, and how to integrate netconsole so you can use the U-Boot
prompt.
Signed-off-by: Fiona Klute <fiona.klute@gmx.de> Reviewed-by: Tony Dinh <mibodhi@gmail.com>
Neil Armstrong [Tue, 28 May 2024 08:35:03 +0000 (10:35 +0200)]
usb: dwc3: gadget: fix crash in dwc3_gadget_giveback()
If the ep0 stalls or request are dequeued when gagdet is stopped,
the request dma may not be mapped yet and dwc3_flush_cache() may be
called with a NULL pointer.
Check req->request.dma before calling dwc3_flush_cache() and later
the usb_gadget_unmap_request() functions since it means that
usb_gadget_map_request() hasn't been called yet.
Adam Ford [Sat, 1 Jun 2024 14:55:20 +0000 (09:55 -0500)]
configs: rzg2_beacon: Realign ENV location and offset
The ENV size and offset were changed to different
values in Beacon's downstream release. Change them to the
same values as the downstream for consistent behavior.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Adam Ford [Sat, 1 Jun 2024 14:55:19 +0000 (09:55 -0500)]
renesas: beacon-rzg2m: Add Marek to MAINTAINER file
Since any changes to the RZ/G2 family go through Marek's tree,
update the MAINTAINER file to automatically show his name
when running get_maintainer.pl. Without this, he is not
copied.
Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Marek Vasut [Sun, 19 May 2024 20:40:07 +0000 (22:40 +0200)]
ARM: dts: renesas: Reserve space in 64bit R-Car DTs
Reserve 4 kiB of space in 64bit R-Car DTs when those DTs are compiled
to permit patching in OpTee-OS /firmware node, /reserved-memory node,
possibly also additional /memory@ nodes and RPC node by TFA.
This duplicates behavior in arch/arm/dts/Makefile with OF_UPSTREAM.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Tom Rini [Thu, 30 May 2024 13:07:51 +0000 (07:07 -0600)]
Merge patch series "omap3: igep0x00: Fix boot failure and modernize the boards support"
Javier Martinez Canillas <javier@dowhile0.org> says:
Hello,
I noticed that the IGEPv2 board did not boot anymore with mainline U-Boot.
This was caused by a driver change to allocate its platform data before
relocation and U-Boot not having enough pre-relocation heap size for this.
This series fixes this issue and also makes the board support more modern,
by enabling DM for SPL and migrating the IGEP boards to use upstream DTBs.
The IGEPv2 board boot started to fail since the commit afd4f15a39de ("spi:
omap3_spi: Read platform data in ofdata_to_platdata()"). Because this made
the OMAP3 SPI controller driver to allocate its platform data before doing
a relocation, but the igep0x00 config sets this pool size to just 1 KiB.
Increase the pre-relocation malloc heap size to 16 KiB, as is set by other
OMAP3 boards. This not only restores booting but also makes it consistent.
Leave the SPL pool size to the previous 1 KiB size since 16 KiB may not be
a possible size in that constrained environment and is also the value that
is set by other OMAP3 boards.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Enric Balletbo i Serra <eballetbo@gmail.com>
H Bell [Wed, 22 May 2024 19:12:51 +0000 (19:12 +0000)]
board: starfive: support Pine64 Star64 board
Add documentation files
Signed-off-by: Henry Bell <dmoo_dv@protonmail.com> Cc: ycliang@andestech.com Cc: heinrich.schuchardt@canonical.com Reviewed-by: E Shattow <lucent@gmail.com>
H Bell [Wed, 22 May 2024 19:12:48 +0000 (19:12 +0000)]
board: starfive: support Pine64 Star64 board
Similar to the Milk-V Mars, The Star64 board contains few differences to the
VisionFive 2 boards, so can be part of the same U-boot build.
Signed-off-by: Henry Bell <dmoo_dv@protonmail.com> Cc: ycliang@andestech.com Cc: heinrich.schuchardt@canonical.com Reviewed-by: E Shattow <lucent@gmail.com>
Conor Dooley [Wed, 15 May 2024 15:04:31 +0000 (16:04 +0100)]
board: microchip: icicle: make both ethernets optional
A given AMP configuration for a board may make either one, or neither
of, the ethernet ports available to U-Boot. The Icicle's init code will
fail if mac1 is not present, so move it to the optional approach taken
for mac0.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
projects / u-boot.git / log