Andrew Goodbody [Tue, 2 Jul 2024 17:00:09 +0000 (18:00 +0100)]
sandbox: Fix LTO to work with STACKPROTECTOR
Add the STACKPROTECTOR symbols to the script that generates the
symbols that should not be removed by the use of LTO when linking
a shared object. This prevents a fail to build due to link errors.
https://source.denx.de/u-boot/u-boot/-/issues/35
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Installing patman with `cd ./tools/patman && pip install -e .` fails
with the error below.
As described in the error output below, the license line is not allowed
to be only defined in the setup.py. We remove the 'license' field
entirely, as the Python Packaging User Guide recommends using projects
classifiers instead[1] and we already set the GPL-2.0+ classifier.
> $ cd ./tools/patman && pip install -e .
> Obtaining file:///.../u-boot/tools/patman
> Installing build dependencies ... done
> Checking if build backend supports build_editable ... done
> Getting requirements to build editable ... error
> error: subprocess-exited-with-error
>
> × Getting requirements to build editable did not run successfully.
> │ exit code: 1
> ╰─> [61 lines of output]
> /tmp/pip-build-env-mqjvnmz8/overlay/lib/python3.12/site-packages/setuptools/config/_apply_pyprojecttoml.py:76:
> _MissingDynamic: `license` defined outside of `pyproject.toml` is ignored.
> !!
>
> ********************************************************************************
> The following seems to be defined outside of `pyproject.toml`:
>
> `license = 'GPL-2.0+'`
>
> According to the spec (see the link below), however, setuptools CANNOT
> consider this value unless `license` is listed as `dynamic`.
>
> https://packaging.python.org/en/latest/specifications/pyproject-toml/#declaring-project-metadata-the-project-table
>
> To prevent this problem, you can list `license` under `dynamic` or alternatively
> remove the `[project]` table from your file and rely entirely on other means of
> configuration.
> ********************************************************************************
>
> !!
Tom Rini [Fri, 26 Jul 2024 00:04:16 +0000 (18:04 -0600)]
Merge branch 'qcom-main' of https://gitlab.denx.de/u-boot/custodians/u-boot-snapdragon
* Qualcomm platforms >~2016 gain support for the RPMh (Resource Power Manager)
peripheral which is used to control most regulators. The RB5 is now able to
power up its USB VBUS regulator via the rpmh regulator driver. Git history
from the original Linux driver is preserved for ease of maintenance.
* IPQ40xx SoCs gain ethernet networking support via the new ESS EDMA driver.
Robert Marko [Mon, 3 Jun 2024 12:06:13 +0000 (14:06 +0200)]
dt-bindings: clock: qcom: ipq4019: drop downstream file
IPQ4019 clock dt-bindings are available in Linux upstream, and we can just
use those instead of carrying a downstream file that matches the upstream one
anyway.
Signed-off-by: Robert Marko <robert.marko@sartura.hr> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
power: regulator: qcom-rpmh-regulator: port ops to U-Boot
Port over the regulator ops to U-Boot's regulator API. Add back the
pmic5 mode map using U-Boot dm_regulator_mode API and adjust the
pmic5_pldo and pmic5_pldo_lv definitions. No functional changes.
A lot of the features in here are only relevant when running
multi-threaded with interrupts. Drop everything except what we need to
run single-threaded with a single TCS (which is all the rpmh-rsc
framework in U-Boot supports).
Keep rpmh_write_async() for simplicity and make it wrap the regular
rpmh_write().
Minor adjustments to fix building with U-Boot and work correctly as a
synchronous driver without interrupts. RPMh is fast enough that we can
get away with just firing off requests and assuming they complete.
U-Boot behaviour changes are annotated with a "U-Boot:" comment.
soc: qcom: rpmh-rsc: drop unused multi-threading and non-active TCS support
Since U-Boot is single threaded, we can avoid most of the complexity
that comes with handling more than one in-flight TCS. Drop all the rpmh
code associated with multi-threading as we'll instead wait for a
response on each TCS.
Keep the header pointer in the .data section so we don't initialize it
again after relocation, adjust cmd_db_get_header() to work with the
U-Boot API, and skip validating the header since all cmd-db users are
children of the rpmh-rsc and those children will only probe if cmd-db
initializes successfully.
Qualcomm platforms may have drivers that bind to reserved memory nodes
(cmd-db [1] and smem [2]) which are relevant to U-Boot. Include
/reserved-memory in dm_extended_scan() so that these will be handled
correctly.
Sam Protsenko [Tue, 23 Jul 2024 18:14:39 +0000 (13:14 -0500)]
arm: exynos: Enable TRNG on E850-96 board
Enable True Random Number Generator (TRNG) on E850-96 board. To do so:
1. Enable DM_RNG and RNG_EXYNOS for TARGET_E850_96
2. Add TRNG node to E850-96 device tree
3. Enable 'rng' command support for easy TRNG testing
TRNG node is already applied in Linux kernel device tree, but it hasn't
appeared in upstream dts yet. Add it in U-Boot override dtsi file
temporarily; it can be removed once it appears in upstream dts.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 23 Jul 2024 18:14:38 +0000 (13:14 -0500)]
rng: Add Exynos TRNG driver
Add True Random Number Generator (TRNG) driver for Exynos chips. This
implementation is heavily based on Linux kernel's counterpart [1]. It
also follows upstream dt-bindings [2].
TRNG block is usually a part of SSS (Security Sub System) IP-core on
Exynos chips. Because SSS access on Exynos850 is protected by TZPC
(TrustZone Protection Control), it's not possible to read/write TRNG
registers from U-Boot, as it's running in EL1 mode. Instead, the
corresponding SMC calls should be used to make the secure software
running in EL3 mode access it for us. Those SMC calls are handled by
LDFW (Loadable Firmware), which has to be loaded first. For example, for
E850-96 board it's done in its board_init(), so by the time RNG
capabilities are needed the LDFW should be already loaded and TRNG
should be functional.
Sam Protsenko [Tue, 23 Jul 2024 18:14:36 +0000 (13:14 -0500)]
board: samsung: e850-96: Load LDFW firmware on board init
LDFW is a Loadable Firmware which provides additional security
capabilities in EL3 monitor. For example, True Random Number Generator
(TRNG) block registers can't be accessed from EL1 (where U-Boot and
Linux kernel are running), but it's possible to access TRNG capabilities
via corresponding SMC calls, which in turn are handled by LDFW. To do
so, LDFW firmware has to be loaded first. It's stored on a raw eMMC
partition, so it has to be read into NWD (Normal World) RAM buffer, and
then loaded to SWD (Secure World) memory using the special SMC call to
EL3 monitor program. EL3_MON will load LDFW to SWD memory, more
specifically to the area starting at 0xbf700000 (with size of 7.5 MiB).
That memory area is reserved in device tree, so there shouldn't be any
collisions. After that LDFW becomes functional.
Implement LDFW firmware loading on board init. While at it, fix the
copyright date in header comments, as this board support was actually
added in 2024, not in 2020: it was probably a copy-paste mistake.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Sam Protsenko [Tue, 23 Jul 2024 18:14:35 +0000 (13:14 -0500)]
board: samsung: e850-96: Add default partitions
Add an environment file for E850-96 board with default eMMC partition
list. It follows the Samsung's partition list used for Android-Q on
Exynos850 devices. It was verified on E850-96 board with:
- Conversions to DM_I2C and DM_SERIAL.
- Support for I2C3 and PWM1 for the imx6q clock driver.
- Improvements for udoo-neo
- Describe the i.MX93 CPU clocks in the devicetree to fix CPU clock printing
- Fix for SPI and NANC clk-imx8mn clock driver
Instead of using the local imx6sx-udoo-neo devicetree copies from U-Boot,
convert the imx6sx-udoo-neo boards to OF_UPSTREAM so that the upstream
kernel devicetrees can be used instead.
The udoo_neo_defconfig target supports several board variants.
All of these variants use the imx6sx-udoo-neo-basic devicetree in U-Boot.
Currently, the devicetree model as well as the board variant name
are shown:
...
Model: UDOO Neo Basic
Board: UDOO Neo FULL
...
Printing the devicetree model that is used internally by U-Boot
may confuse users.
Unselect the CONFIG_DISPLAY_BOARDINFO option and move the board printing
inside board_init() so that only the real board name that is detected
in run-time is printed.
Emil Kronborg [Fri, 12 Jul 2024 14:19:10 +0000 (14:19 +0000)]
clk: imx6q: Add definition for IMX6QDL_CLK_I2C3
Commit 727fa4539ca2 ("clk: Add support for I2C clocks on NXP's imx6q SoC
which use CCF") added I2C clocks for I2C1 and I2C2, but not I2C3.
Consequently, devices using I2C3 fail after enabling CONFIG_CLK_IMX6Q
and thus CONFIG_CLK. Therefore, this commit adds the last I2C clock.
Signed-off-by: Emil Kronborg <emil.kronborg@protonmail.com>
clk: imx: clk-imx8mn Fix nand and spi clock parent
The osc_24m is the clock-output-name and not the one that
is used as internal name reference from the strcmp. The clock
that use osc_24m, will not be able to reparent it as they should.
We need anyway register the osc_24m clock fixed factor in the clock
tree.
Fixes: 710c4ffb890 ("clk: imx: clk-imx8mn add gpmi nand clocks") Fixes: 85b1c11989c ("clk: imx: Add ECSPI to iMX8MN") Cc: Marek Vasut <marex@denx.de> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Tom Rini [Mon, 22 Jul 2024 19:48:24 +0000 (13:48 -0600)]
Merge patch series "Generalize PHYTEC Overlay Handling"
Daniel Schultz <d.schultz@phytec.de> says:
The overlays are specified in the bootenv.txt file that is loaded into
the environment. Then these overlays get loaded and applied via a script.
These scripts for loading and applying devicetree overlays are identical
for many phytec boards.
Create a common overlays.env that can be included.
Add support for devicetree overlays to phycore-imx8mp and include the
overlays.env for phycore-imx93.
Rename existing environment variables according to bootstd doc.
Move MMC boot logic into a common k3_mmc.env file and include the new
overlays.env file as well.
Benjamin Hahn [Wed, 17 Jul 2024 05:11:28 +0000 (22:11 -0700)]
phycore_imx93: include common overlays.env
Include the common overlays env file for phycore_imx93.
The common overlays env file supports disabling loading overlays by
setting the no_overlays variable.
Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de> Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Benjamin Hahn [Wed, 17 Jul 2024 05:11:27 +0000 (22:11 -0700)]
phycore-imx8mp: Add overlay and bootenv.txt support
Add support for loading bootenv.txt as well as loading and applying
overlays during boot from mmc and net.
${no_bootenv}: Prevent loading external bootenv.txt environment. Use
${overlays} variable directly from u-boot environment.
${no_overlay}: Do not load overlays defined in ${overlays} variable.
Overlays loaded over the extension command are still
being applied.
Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de> Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Benjamin Hahn [Wed, 17 Jul 2024 05:11:26 +0000 (22:11 -0700)]
include: env: phytec: Create env file for loading and applying overlays
The env scripts for loading and applying overlays are identical for many
PHYTEC Boards. Create a common env that can be included.
The env variables bootenv_addr and fdto_addr are board specific and need
to be set in the board specific file. The env variable get_cmd also
needs to be set in board specific files and can be set to tftp or dhcp.
Signed-off-by: Benjamin Hahn <B.Hahn@phytec.de> Signed-off-by: Daniel Schultz <d.schultz@phytec.de> Reviewed-by: Teresa Remmet <t.remmet@phytec.de> Reviewed-by: Wadim Egorov <w.egorov@phytec.de>