- Update the imx_rgpio2p to only access one address as per the
dt-schema.
- Remove unused imx9_cpu.c file.
- Only use the LPUART ipg clk for i.MX7ULP.
- Use the correct anatop base for accessing the PLL clocks on i.MX93.
Tom Rini [Mon, 15 Apr 2024 13:38:18 +0000 (07:38 -0600)]
Merge tag 'u-boot-socfpga-next-20240415' of https://source.denx.de/u-boot/custodians/u-boot-socfpga
- Add option to reprogram FPGA every reboot, enable this as default in
chameleonv3 defconfig.
- Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG,
so the driver can be built when CONFIG_SPL_SOCFPGA_DT_REG is set in
defconfig.
Yang Xiwen [Thu, 1 Feb 2024 14:05:43 +0000 (22:05 +0800)]
mmc: dw_mmc: Don't return error if data busy timeout
As described in [1], some poor hardware or cards would fail to release
the bus and keep driving data lines low. Ignore it and send the next cmd
directly seems okay for most cases.
Marek Vasut [Sun, 17 Mar 2024 03:01:22 +0000 (04:01 +0100)]
mmc: Unconditionally call mmc_deinit()
Place the SDR104/HS200/HS400 checks into the mmc_deinit() and always
call it. This simplifies the code and removes ifdeffery. No functional
change is expected.
Marek Vasut [Sat, 24 Feb 2024 22:32:11 +0000 (23:32 +0100)]
mmc: renesas-sdhi: Do not access SCC during tuning in send_cmd callback
Do not access SCC when sending commands during tuning operation as that
will disrupt the tuning operation. The tuning operation is adjusting the
SCC settings itself in execute_tuning callback.
When renesas_sdhi_execute_tuning() is called by the MMC core code, a loop
which consists of renesas_sdhi_prepare_tuning(), mmc_send_tuning() and
renesas_sdhi_compare_scc_data() iterates over each SCC tuning tap.
The renesas_sdhi_prepare_tuning() configures the SCC tuning tap number into
hardware, mmc_send_tuning() triggers transfer of tuning block which depends
on the bus mode for which the bus is currently being tuned, this information
is supplied by the MMC core code, and finally renesas_sdhi_compare_scc_data()
tests the received tuning block for validity.
Because renesas_sdhi_prepare_tuning() configures the SCC tuning tap into
the hardware to fit the tuning operation, mmc_send_tuning() which triggers
command transfer using renesas_sdhi_send_cmd() must not manipulate with
the SCC in any way. Currently renesas_sdhi_send_cmd() does unconditionally
call renesas_sdhi_check_scc_error(), which may adjust the SCC tuning tap
position by writing RENESAS_SDHI_SCC_TAPSET, which would overwrite the
required tuning configuration set by renesas_sdhi_prepare_tuning() and
disrupt the tuning operation.
Fix this by skipping the renesas_sdhi_check_scc_error() call in case the
MMC subsystem is in tuning state. This way, the SCC settings are left
unmodified by command transfer during tuning operation.
Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Sat, 24 Feb 2024 22:32:10 +0000 (23:32 +0100)]
mmc: Add generic tuning flag
Set generic mmc->tuning flag when performing tuning to indicate
this condition to drivers. Drivers may use this to bypass various
checks during tuning.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Sat, 24 Feb 2024 22:32:09 +0000 (23:32 +0100)]
mmc: Convert hs400_tuning flag from u8 to bool
This hs400_tuning is a flag, make it bool. No functional change.
This will be useful in the following patch, which adds another
more generic flag, where the compiler can better use the space
now reserved for the u8 to store more flags in it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Tue, 20 Feb 2024 08:38:45 +0000 (09:38 +0100)]
mmc: renesas-sdhi: Stop transmission in case tuning block transfer fails
The current code uses the state of tuning block received by SCC to
determine whether or not to send transmission stop command. This is
not correct. Use the state of tuning block transfer to determine
whether or not to send transmission stop command instead, because
the transmission stop command has to be sent in case the tuning
block transfer failed.
This requires two changes, separate variable to store and check the
state of tuning block received by SCC, and another separate variable
to store and check return value from transmission stop command.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Marek Vasut [Tue, 20 Feb 2024 08:38:14 +0000 (09:38 +0100)]
mmc: tmio: Check INFO1 for completion during DMA transfer
In case a CRC error occurs during DMA transfer, the transfer completion
flag is not set in TMIO_SD_DMA_INFO1 and the transfer would eventually
time out. The timeout could be very long in case the transfer consists
of a large amount of blocks, the base timeout is 10 seconds and every
block adds 100 us more.
In case a CRC error does occur, a completion flag is set in a different
register, TMIO_SD_INFO1. Use this other completion flag to detect DMA
transfer ended and stop waiting for TMIO_SD_DMA_INFO1 completion flag.
This reduces the lengthy timeout in case of an error. The unconditional
check of TMIO_SD_DMA_INFO2 register for DMA related errors must not be
skipped in any case to actually recognize the DMA error and report it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Paul Barker <paul.barker.ct@bp.renesas.com> Tested-by: Paul Barker <paul.barker.ct@bp.renesas.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Linus Walleij [Thu, 8 Feb 2024 09:33:43 +0000 (10:33 +0100)]
mmc: arm_pl180_mmci: Rely on DM
The PL180/MMCI driver is implied to use CONFIG_DM and the ARM
defconfigs such as configs/vexpress_ca9x4_defconfig will get it
as well.
With a simple oneline to default to not being the v2 variant,
the original ARM MMCI variant works fine with the driver as well.
The IP version actually needs to be read out from a register on
the ARM versions, but we will simply assume we are running on the
original hardware if arm,primecell-periphid is not explicitly
specified in the device tree.
Jonas Karlman [Sat, 27 Jan 2024 17:12:35 +0000 (17:12 +0000)]
mmc: Add SPL_MMC_PWRSEQ to fix link issue when building SPL
With MMC_PWRSEQ enabled the following link issue may happen when
building SPL and SPL_PWRSEQ is not enabled.
aarch64-linux-gnu-ld.bfd: drivers/mmc/meson_gx_mmc.o: in function `meson_mmc_probe':
drivers/mmc/meson_gx_mmc.c:295: undefined reference to `pwrseq_set_power'
Fix this by adding a SPL_MMC_PWRSEQ Kconfig option used to enable mmc
pwrseq support in SPL.
Also add depends on DM_GPIO to fix following link issue:
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.o: in function `mmc_pwrseq_set_power':
drivers/mmc/mmc-pwrseq.c:26: undefined reference to `gpio_request_by_name'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:29: undefined reference to `dm_gpio_set_value'
aarch64-linux-gnu-ld.bfd: drivers/mmc/mmc-pwrseq.c:31: undefined reference to `dm_gpio_set_value'
Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Acked-by: Ferass El Hafidi <vitali64pmemail@protonmail.com>
If the CSD register contains a reserved value (4 - 7) in bits 0:2 of the
TRAN_SPEED field, a buffer overrun occurs. Resize the mapping table.
According to the original report
https://lore.kernel.org/u-boot/20180826231332.2491-11-erosca@de.adit-jv.com/
reserved values have been observed resulting in a buffer overrun.
Michał Barnaś [Tue, 19 Mar 2024 18:18:13 +0000 (18:18 +0000)]
arm: socfpga: arria10: add option to reprogram the FPGA every reboot
Add Kconfig that enables FPGA reprogramming with warm boot on Arria 10.
This option allows to change the bitstream on the filesystem and apply
changes with warm reboot without the need for a power cycle.
Alexander Dahl [Wed, 20 Mar 2024 09:02:13 +0000 (10:02 +0100)]
mtd: nand: raw: atmel: Fix comment in timings preparation
Introduced with commit 6a8dfd57220d ("nand: atmel: Add DM based NAND
driver") when driver was initially ported from Linux. The context
around this and especially the code itself suggests 'read' is meant
instead of write.
The fix is the same as accepted in Linux already with mainline Linux
kernel commit 1c60e027ffde ("mtd: nand: raw: atmel: Fix comment in
timings preparation").
Alexander Dahl [Wed, 20 Mar 2024 09:02:10 +0000 (10:02 +0100)]
mtd: nand: raw: Port another option flag from Linux
Introduced in upstream Linux with commit 7a08dbaedd365 for release v5.0.
When the new atmel nand driver was backported to U-Boot with commit 6a8dfd57220d ("nand: atmel: Add DM based NAND driver") that definition
was added to the driver instead of the header file. Move it over to the
other definitions with the same help text it has in Linux.
Code actually using this has not been ported over to raw nand base yet.
Alexander Dahl [Wed, 20 Mar 2024 09:02:09 +0000 (10:02 +0100)]
mtd: nand: raw: Use macro nand_to_mtd() where appropriate
In every other place in this file the macro is used, make it consistent.
Link: https://lore.kernel.org/all/20240320090214.40465-2-ada@thorsis.com Fixes: 9d1806fadc24 ("mtd: nand: Get rid of mtd variable in function calls") Signed-off-by: Alexander Dahl <ada@thorsis.com> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Tom Rini [Sat, 13 Apr 2024 16:18:38 +0000 (10:18 -0600)]
Merge tag 'efi-2024-07-rc1-2' of https://source.denx.de/u-boot/custodians/u-boot-efi
Pull request efi-2024-07-rc1-2
Documentation:
* bump build dependency idna to 3.7
* update docker image reference to latest
* fix section levels in gen_compile_commands
* fix references to trace doc
UEFI:
* eliminate duplicate runtime section definitions
* let 'EFI using ACPI tables at' be a debug message
* sanitize efi_tcg2_final_events_table definition
* move efi_var_collect to common functions
* improve error messages in variables unit test by using
EFI_UNSUPPORTED for private authenticated variables
Tom Rini [Fri, 12 Apr 2024 14:23:17 +0000 (08:23 -0600)]
doc/sphinx: Bump idna to 3.7
While we unlikely to have an issue with CVE-2024-3651, it is simple
enough to bump our version of idna to receive the fix, do so.
Reported-by: GitHub dependabot Signed-off-by: Tom Rini <trini@konsulko.com> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Vincent Stehlé [Thu, 11 Apr 2024 16:44:02 +0000 (18:44 +0200)]
Fix references to trace doc
The README.trace has been moved and converted to rst in commit dce26c7d56ed
("doc: move README.trace to HTML documentation"); fix all the remaining
references to this file.
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Tom Rini <trini@konsulko.com> Cc: Simon Glass <sjg@chromium.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
efi_loader: move efi_var_collect to common functions
efi_var_collect() was initially placed in efi_var_file.c, since back
then we only supported efi variables stored in a file. Since then we
support variables stored in an RPMB as well and use that function to
collect variables that should be present at runtime.
So let's move it around in efi_var_common.c which makes more sense
Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <apalos@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The 2 subsections of this page ("Compatible IDEs" and "Usage") are using
the same header level as the title (with "===").
Because of this, they always appear in the HTML rendered ToC.
Drop the subsections one level lower by replacing "=" by "-".
This fixes the HTML rendering.
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Rini [Fri, 12 Apr 2024 22:23:19 +0000 (16:23 -0600)]
Merge patch series "mcheck implementation for U-Boot"
Eugene Uriev <eugeneuriev@gmail.com> says:
There was no "mcheck" for U-Boot before.
Since U-Boot has only 1 thread, and normally makes 4000+ - 6000+
mallocs, it's better to use havier canaries to protect heap-chunks.
My variant uses 2x8 = 16byte-long protector. And
the multiplier could be changed to tune speed/protection tradeoff.
This protects not only against memset()-s, but against "near" wild
pointers too, and makes more probable to catch "distant" ones.
The core file of the set is included into the C-file, not complied
separately in order to enable (potential) coexisting of
mcheck-protectors, e.g. malloc_simple(.) and dlmalloc simultaneously.
My tests were for ARM SoC, 64bit, so the patch is
aware of alignment.
Primary this patch is for using by developers: to verify,
if a change doesn't break the heap integrity.
By default the mcheck is disabled and wouldn't affect the boot.
I used pedantic mode, canary=16byte, registry-size=6608.
For my system the overhead was 230ms.
Eugene Uriev [Sun, 31 Mar 2024 20:03:22 +0000 (23:03 +0300)]
mcheck: integrate mcheck into dlmalloc.c
This changes are probable worth to be generalized in a
separate .h-file so, making it able to cover
libc-mallocs and others, without too much copy-paste.
But the malloc<=>mALLOc substitutions interfere
with an elegant way to do this.
Jim Liu [Mon, 8 Apr 2024 08:49:02 +0000 (16:49 +0800)]
net: designware: Invalidate RX buffer cache before freeing the DMA descriptor
In IPv6 context, the ICMP and UDP checksum byte in the RX packet
is initially set to 0, recaclculated, and then re-inserted.
This process can result in a dirty cache line. To prevent issues,
it is essential to invalidate cache for the RX buffer before freeing
the descriptor for next DMA transfer.
This ensure that the dirty cache line doesn't inadvertently written back
due to cache eviction, there by corrupting the RX buffer
Signed-off-by: Parvathi Bhogaraju <pbhogaraju@microsoft.com> Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
Tom Rini [Fri, 12 Apr 2024 19:54:51 +0000 (13:54 -0600)]
Merge patch series "Introduce ICSSG Ethernet driver"
MD Danish Anwar <danishanwar@ti.com> says:
Introduce ICSSG PRUETH support in uboot. The ICSSG driver is used in TI
AM654 SR2.0.
The ICSSG PRU Sub-system runs on EMAC firmware. This series Introduces
support for ICSSG driver in uboot.
This series has been tested on AM65x SR2.0, and the ICSSG interface is
able to ping / dhcp and boot kernel using tftp in uboot.
To use ICSSG2 ethernet, the ICSSG firmware needs to be loaded to PRU RPROC
cores and RPROC cores need to be booted with the firmware. This step is
done inside driver similar to kernel.
The remoteproc driver uses request_fw_into_buf() API from fs-loader driver
to load and start rproc with the required firmwares.
This series only introduces driver files. The device tree and config
changes to enable ICSSG driver will be introduced later.
net: ti: icssg: Add support sending FDB command to update rx_flow_id
ICSSG firmware supports FDB commands. Add support to send FDB commands
from driver. Once rx_flow_id is obtained from dma, let firmware know that
we are using this rx_flow_id by sending a FDB command.
Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
This is the PRUSS Ethernet driver for TI AM654 SR2.0 and later SoCs with
the ICSSG PRU Sub-system running EMAC firmware. ICSSG Subsystem supports
two slices per instance. This driver caters to both slices / ports of
the icssg subsystem.
Since it is not possible for Ethernet driver to register more than one
port for a given instance, this patch introduces top level PRUETH as
UCLASS_MISC and binds UCLASS_ETH to individual ports in order to support
bringing up more than one Ethernet interface in U-Boot.
Since top level driver is UCLASS_MISC, board files would need to
instantiate the driver explicitly.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
net: ti: icssg: Add Firmware config and classification APIs.
Add icssg_config.h / .c and icssg_classifier.c files. These are firmware
configuration and classification related files. Add MII helper APIs and
MACROs. These APIs and MACROs will be later used by ICSSG Ethernet driver.
Also introduce icssg_prueth.h which has definition of prueth related
structures.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Tom Rini [Fri, 12 Apr 2024 18:57:13 +0000 (12:57 -0600)]
Merge patch series "zlib: Address CVE-2016-9841"
Michal Simek <michal.simek@amd.com> says:
It looks like that only CVE-2016-9841 is not fixed and this series is
trying to address it. The first two patches are just preparation based on
changes which happened in past. The third one is actual fix and the last
one is following what has been done in Linux kernel long time ago and don't
use incorrect zlib version string.
I tested it with and I can't see any issue.
./test/py/test.py --bd sandbox --build -s
Michal Simek [Wed, 27 Mar 2024 14:14:53 +0000 (15:14 +0100)]
zlib: Remove incorrect ZLIB_VERSION
Get rid of zlib version which is not correct because of U-Boot related
changes and various CVE backports.
The change in inspired by Linux kernel commit 4f3865fb57a0 ("[PATCH]
zlib_inflate: Upgrade library code to a recent version") which described
ZLIB_VERSION removal as
"This patch also removes ZLIB_VERSION as it no longer has a correct value.
We don't need version checks anyway as the kernel's module handling will
take care of that for us. This removal is also more in keeping with the
zlib author's wishes (http://www.zlib.net/zlib_faq.html#faq24) and I've
added something to the zlib.h header to note its a modified version."
Author describes wish to follow this guidance at
https://www.zlib.net/zlib_faq.html#faq24:
"The license says that altered source versions must be "plainly marked". So
what exactly do I need to do to meet that requirement?
You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h. In
particular, the final version number needs to be changed to f, and an
identification string should be appended to ZLIB_VERSION. Version numbers
x.x.x.f are reserved for modifications to zlib by others than the zlib
maintainers. For example, if the version of the base zlib you are altering
is 1.2.3.4, then in zlib.h you should change ZLIB_VERNUM to 0x123f, and
ZLIB_VERSION to something like 1.2.3.f-zachary-mods-v3. You can also update
the version strings in deflate.c and inftrees.c."
But U-Boot is not exact version that's why following the same style which
has been used by Linux kernel where ZLIB_VERSION is completely removed.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Wed, 27 Mar 2024 14:14:52 +0000 (15:14 +0100)]
zlib: Port fix for CVE-2016-9841 to U-Boot
The patch corresponds to zlib commit at
https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb
which declares that it is fixing CVE-2016-9841.
Here is c&p description from zlib:
"Use post-increment only in inffast.c.
An old inffast.c optimization turns out to not be optimal anymore
with modern compilers, and furthermore was not compliant with the
C standard, for which decrementing a pointer before its allocated
memory is undefined. Per the recommendation of a security audit of
the zlib code by Trail of Bits and TrustInSoft, in support of the
Mozilla Foundation, this "optimization" was removed, in order to
avoid the possibility of undefined behavior."
Origin patch also updates the code when
INFLATE_ALLOW_INVALID_DISTANCE_TOOFAR_ARRR is present but this code is not
the part of U-Boot hence it is ignored.
Also do not deal with state->sane variable which requires other changes
which are also not the part of zlib.
Commit 92faa8b10918 ("zlib: handle overflow while calculating available
stream input size") is kept in inffast.c too not to break described case.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Wed, 27 Mar 2024 14:14:51 +0000 (15:14 +0100)]
zlib: Rename write variable to wnext (window write index)
There is no particular patch/description which described the reason for
this change but it was done as the part of zlib 1.2.3.5 release done by
zlib commit d004b047838a ("zlib 1.2.3.5"). It is preparation for followup
patch.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Michal Simek [Wed, 27 Mar 2024 14:14:50 +0000 (15:14 +0100)]
zlib: Rename this variable to here (current decoding table entry)
There is no particular patch/description which described the reason for
this change but it was done as the part of zlib 1.2.3.5 release done by
zlib commit 639be997883d ("zlib 1.2.3.3") It is preparation for followup
patch.
Signed-off-by: Michal Simek <michal.simek@amd.com>
ARM: uniphier: Move uniphier_mem_map_init() call into dram_init()
The function uniphier_mem_map_init() is to change global variable
'mem_map', which is referenced to get_page_table_size() to calculate
the size of page table.
However, uniphier_mem_map_init() is called after get_page_table_size(),
so the size of page table and 'mem_map' become inconsist each other.
After all, U-Boot fails to boot on chip with memory map different from
default map,
uniphier_mem_map_init() should be moved to dram_init(), which is
called before get_page_table_size().
Sam Protsenko [Sat, 30 Mar 2024 00:55:53 +0000 (19:55 -0500)]
fdt: Fix fdt_pack_reg() on 64-bit platforms
When "memory" node is being processed in fdt_pack_reg() on ARM64
platforms, an unaligned bus access might happen, which leads to
"synchronous abort" CPU exception. Consider next dts example:
After fdt_pack_reg() reads the first addr/size entry from such memory
node, the "p" pointer becomes 12 bytes shifted from its original value
(8 bytes for two address cells + 4 bytes for one size cell). So now it's
not 64-bit aligned, and an attempt to do 64-bit bus access to that
address will cause an abort like this:
"Synchronous Abort" handler, esr 0x96000021, far 0xba235efc
This issue was originally reported by David Virag [1] who observed it
happening on Samsung Exynos7885 SoC (ARM64), and later the same issue
was observed on Samsung Exynos850 (ARM64).
Fix the issue by using put_unaligned_be64() helper, which takes care of
possible unaligned 64-bit accesses. That solution was proposed by Simon
Glass in the original thread [1].
Fixes: 739a01ed8e02 ("fdt_support: fix an endian bug of fdt_fixup_memory_banks") Suggested-by: Simon Glass <sjg@google.com> Reported-by: David Virag <virag.david003@gmail.com> Closes: https://lists.denx.de/pipermail/u-boot/2023-July/522074.html Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Sam Protsenko [Thu, 28 Mar 2024 22:29:50 +0000 (17:29 -0500)]
part: Check all partitions in part_get_info_by_name()
In part_get_info_by_name() the inability to get some partition info
shouldn't be a reason for dropping out of the loop. That might happen
e.g. if the partition is hidden or unused. An example of such case are
Samsung devices, where they use the "unused" GUID type
(00000000-0000-0000-0000-000000000000) to indicate that the partition
should be hidden from the OS. Such partitions might not be seen in
"part list" output, which creates "gaps" in numbering in between of the
visible partitions:
Part Start LBA End LBA Name
1 0x00000400 0x0000a3ff "efs"
5 0x00026420 0x00026c1f "dtbo"
12 0x0003f390 0x0074738f "super"
In that case, the loop in part_get_info_by_name() would break after
partition #1, so any attempt to obtain "dtbo" or "super" partition will
fail. Fix that by continuing to iterate over the remaining partitions to
make sure none of the visible ones is missed. That makes "part" command
(e.g. "part start", "part size") able to work with such tables.
Fixes: 87b8530fe244 ("disk: part: implement generic function part_get_info_by_name()") Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Hugo Cornelis [Thu, 21 Mar 2024 11:22:22 +0000 (12:22 +0100)]
image-host: Fix error value paths and emit error messages to stderr.
A recent refactoring in image-host.c messed up the return values of
the function that reads the encryptiong keys. This patch fixes this
and also makes sure that error output goes to stderr instead of to
stdout.
Signed-off-by: Hugo Cornelis <hugo.cornelis@essensium.com>
sandbox: missing return value checks in eth-raw-os
We should check the return value of fcntl().
Addresses-Coverity-ID: 131108 ("Unchecked return value from library")
Addresses-Coverity-ID: 131109 ("Unchecked return value from library") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Janne Grunau [Thu, 4 Apr 2024 06:25:54 +0000 (08:25 +0200)]
usb: kbd: Add probe quirk for Apple and Keychron keyboards
Those keyboards do not return the current device state. Polling will
timeout unless there are key presses. This is not a problem during
operation but the initial device state query during probing will fail.
Skip this step in usb_kbd_probe_dev() to make these devices useable.
Not all Apple keyboards behave like this. A keyboard with USB
vendor/product ID 05ac:0221 is reported to work with the current code.
Unfortunately some Keychron keyboards "re-use" Apple's vendor ID and
show the same behavior (Keychron C2, 05ac:024f for example).
Reviewed-by: Marek Vasut <marex@denx.de> Reviewed-by: Neal Gompa <neal@gompa.dev> Signed-off-by: Janne Grunau <j@jannau.net>
Janne Grunau [Thu, 4 Apr 2024 06:25:53 +0000 (08:25 +0200)]
usb: kbd: support Apple Magic Keyboards (2021)
Apple USB keyboards (Magic Keyboard from 2021 (product id 0x029c)) carry
the HID keyboard boot protocol on the second interface descriptor.
Probe via vendor and product IDs since the class/subclass/protocol match
uses the first interface descriptor.
Probe the two first interface descriptors for the HID keyboard boot
protocol.
Janne Grunau [Thu, 4 Apr 2024 06:25:52 +0000 (08:25 +0200)]
usb: Add environment based device ignorelist
Add the environment variable "usb_ignorelist" to prevent USB devices
listed in it from being bound to drivers. This allows to ignore devices
which are undesirable or trigger bugs in u-boot's USB stack.
Devices emulating keyboards are one example of undesirable devices as
u-boot currently supports only a single USB keyboard device. Most
commonly, people run into this with Yubikeys, so let's ignore those in
the default environment.
Based on previous USB keyboard specific patches for the same purpose.
board: phycore-am62x: Extend for better environment handling
Select environment location based on the device we boot from.
Also, introduce a "boot" variable that represents the current boot
device and can be used by scripts.
arm: mach-k3: am625: Provide a way to obtain boot device for non SPLs
Introduce get_boot_device() to obtain the booting device. Make it also
available for non SPL builds so u-boot can also know the device it is
booting from.
Move verdin-am62 to OF_UPSTREAM:
- handle the fact that dtbs now have a 'ti/' prefix
- imply OF_UPSTREAM
- remove redundant files from arch/arm/dts leaving only the
*-u-boot.dtsi files
- update MAINTAINERS file
Andrew Davis [Tue, 2 Apr 2024 16:09:08 +0000 (11:09 -0500)]
arm: dts: k3: Remove unneeded ti, sci-sysreset binding and nodes
This extra binding is non-standard and now unneeded as we bind the
sysreset driver automatically. This matches what is done in Linux
and allows us to more closely match the DTBs. Remove the binding
and all users.
Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com>
Andrew Davis [Tue, 2 Apr 2024 16:09:07 +0000 (11:09 -0500)]
firmware: ti_sci: Bind sysreset driver when enabled
The sysreset TI-SCI API is available with TI-SCI always, there is no need
for a DT node to describe the availability of this. If the sysreset driver
is available then bind it during ti-sci probe.
Remove the unneeded device tree matching.
Signed-off-by: Andrew Davis <afd@ti.com> Tested-by: Jonathan Humphreys <j-humphreys@ti.com> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Vitor Soares [Thu, 28 Mar 2024 10:05:48 +0000 (10:05 +0000)]
arm: mach-k3: common: EFI loader map memory below ram top
During the boot, the EFI loader maps the memory from ram_top to ram_end
as EFI_BOOT_SERVICES_DATA. When LMB does boot_fdt_add_mem_rsv_regions()
to OPTEE, TFA, R5, and M4F DMA/memory "no-map" for the kernel it produces
the following error message:
ERROR: reserving fdt memory region failed (addr=9cb00000 size=100000 flags=4)
ERROR: reserving fdt memory region failed (addr=9cc00000 size=e00000 flags=4)
ERROR: reserving fdt memory region failed (addr=9da00000 size=100000 flags=4)
ERROR: reserving fdt memory region failed (addr=9db00000 size=c00000 flags=4)
ERROR: reserving fdt memory region failed (addr=9e780000 size=80000 flags=4)
ERROR: reserving fdt memory region failed (addr=9e800000 size=1800000 flags=4)
To avoid this, don't flag with EFI_BOOT_SERVICES_DATA the memory from
ram_top to ram_end by the EFI loader.
Martyn Welch [Tue, 26 Mar 2024 14:26:33 +0000 (14:26 +0000)]
am625x_evm_a53: Tweak boot command to set fdt
With the current config for tha SK-AM62, fdtfile isn't set in the U-Boot
environment. When using bootflow to boot from a block device, where the
extlinux.conf file specifies `fdtdir`, a fallback device tree is being
constructed from the `soc` (`k3`) and `board` (`am62x`) environment
variables, resulting in u-Boot trying to retrieve
`/dtbs/6.8.1+/k3-am62x.dtb`. This file doesn't exist.
The environment variables `default_device_tree` and
`default_device_tree_arch` are set in the config, the `findfdt` script
can be called to construct `fdtfile` from the environment variables set
by these config options, however this script currently isn't being run.
Calling this script results in the correct device tree being retrieved:
Retrieving file: /dtbs/6.8.1+/ti/k3-am625-sk.dtb
Many boards are calling this script as part of their boot command. The
am62x currently isn't. Rectify this so that booting works correctly.
Signed-off-by: Martyn Welch <martyn.welch@collabora.com> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>
This isn't very helpful. Improve the message to tell the user that the
number is actually a line number and also tell the user in which file
they have to look.
Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
arm: mach-k3: am625: Fixup a53 cpu frequency by speed grade
The maximum frequency of the A53 CPU on the AM62 depends on the speed
grade of the SoC. However, this value is hardcoded in the DT for all
AM62 variants, potentially causing specifications to be exceeded. Moreover,
setting a common lower frequency for all variants increases boot time.
To prevent these issues, modify the DT at runtime from the R5 core to
adjust the A53 CPU frequency based on its speed grade.
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
arm: mach-k3: am62: Get a53 max cpu frequency by speed grade
AM62 SoC has multiple speed grades. Add function to return max A53 CPU
frequency based on grade. Fastest grade's max frequency also depends on
PMIC voltage, to simplify implementation use the smaller value.
Suggested-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Joao Paulo Goncalves <joao.goncalves@toradex.com>
projects / thirdparty / u-boot.git / log
