Svyatoslav Ryhel [Tue, 23 Jan 2024 17:16:29 +0000 (19:16 +0200)]
video: tegra20: dsi: add T114 support
Existing Tegra DSI driver mostly fits T114 apart MIPI calibration
which on T114 has dedicated driver. To resolve this MIPI calibration
logic was split for pre-T114 and T114+ devices.
Tested-by: Ion Agorria <ion@agorria.com> # HTC One X Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab T114 Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com>
Svyatoslav Ryhel [Tue, 23 Jan 2024 17:16:23 +0000 (19:16 +0200)]
video: tegra20: dc: configure behavior if PLLD/D2 is used
If DISP1 is a PLLD/D2 child, it cannot go over 370MHz. The cause
of this is not quite clear. This can be overcomed by further
halving the PLLD/D2 if the target parent rate is over 800MHz.
This way DISP1 and DSI clocks will have the same frequency. The
shift divider in this case has to be calculated from the
original PLLD/D2 frequency and is passed from the DSI driver.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS Grouper E1565 Tested-by: Ion Agorria <ion@agorria.com> # HTC One X Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab T114 Tested-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> # Microsoft Surface 2 Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com>
Svyatoslav Ryhel [Tue, 23 Jan 2024 17:16:19 +0000 (19:16 +0200)]
video: tegra20: dc: pass DC id to internal devices
Tegra SoC has 2 independent display controllers called DC_A and
DC_B, they are handled differently by internal video devices like
DSI and HDMI controllers so it is important for last to know
which display controller is used to properly set up registers.
To achieve this, a pipe field was added to pdata to pass display
controller id to internal Tegra SoC devices.
Tested-by: Agneli <poczt@protonmail.ch> # Toshiba AC100 T20 Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS Grouper E1565 Tested-by: Ion Agorria <ion@agorria.com> # HTC One X Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # Nvidia Tegratab T114 Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Tom Rini [Fri, 19 Apr 2024 13:28:43 +0000 (07:28 -0600)]
Merge tag 'u-boot-stm32-20240419' of https://source.denx.de/u-boot/custodians/u-boot-stm
MP1:
_ Add OHCI HCD support for STM32MP15xx DHSOM
_ Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
_ Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
_ Jump to ep on successful resume in PSCI suspend code
_ Add FASTBOOT support for STM32MP13
_ Fix/Rework key and leds management for STM32MP13/15
_ net: dwc_eth_qos: Clean up STM32 glue code and add STM32MP13xx support
MP2:
_ Add stm32-fmc-ebi support
_ Add: sdmmc2 support and fix AARCH64 compilation
ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds"; which is not present in kernel DT.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use led node's name instead for
u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Add compatible = "gpio-leds" which is not present in kernel DT.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename red led node's name to led-red.
Remove status property which is useless.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use blue led node's name instead
for u-boot,boot-led property.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot
As indicated in kernel led dt-bindings, label is a deprecated
property, so remove it and use red led node's name instead
for u-boot,error-led property.
Rename "red" led node's name to "led-red".
Remove status property which is useless.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot
red led and button dedicated to fastboot share the same gpio GPIOA13.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from red led node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot
led-red and button dedicated to fastboot share the same gpio GPIOA13.
led-blue and button dedicated to stm32prog share the same gpio GPIOA14.
Led driver is probed early so the corresponding gpio is taken and
configured in output which forbid fastboot and stm32prog button usage.
To avoid this, remove the "default-state" property from led-red and
led-blue led's node.
This will avoid to trigger the led driver probe() to configure the led
default state during startup.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot
Add 2 gpio-keys :
_ button-user-1 for stm32prog mode activation.
_ update button-user's label (defined in kernel DT) to match label
requested in board_key_check() for fastboot mode activation.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Marek Vasut [Fri, 19 Apr 2024 03:59:05 +0000 (05:59 +0200)]
ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be
released from endless loop in BootROM only by populating TAMP BKPxR 4
and 5 with magic and branch address and sending SGI0 interrupt from
core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized
as well to release the core 1 from endless loop during the second SGI0
handling on core 1. Initialize TAMP_SMCR to protect the first 32 backup
registers, the ones which contain the core 1 magic, branch address and
boot information.
This requirement seems to be undocumented, therefore it was necessary
to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump.
Ultimately, it turns out that a certain BootROM function reads out the
TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero.
If they are zero, the BootROM code again waits for SGI0 using WFI, else
the execution moves forward until it reaches handoff to the TAMP BKPxR 5
branch address.
This fixes CPU core 1 release using U-Boot PSCI implementation on an
OTP-CLOSED system, i.e. system with fuse 0 bit 6 set.
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Sun, 14 Apr 2024 18:39:29 +0000 (20:39 +0200)]
ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
SoC revision is only accessible via DBUMCU IDC register,
which requires BSEC.DENABLE DBGSWENABLE bit to be set to
make the register accessible, otherwise an access to the
register triggers bus fault. As BSEC.DBGSWENABLE is zero
in case of an OTP-CLOSED system, do NOT set DBGSWENABLE
bit as this might open a brief window for timing attacks.
Instead, report that this system is OTP-CLOSED and do not
report any SoC revision to avoid confusing users. Use an
SEC/C abbreviation to avoid growing SOC_NAME_SIZE .
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Sun, 14 Apr 2024 18:38:31 +0000 (20:38 +0200)]
ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o
The source file is in arch/arm/mach-stm32mp/ecdsa_romapi.c and not
in arch/arm/mach-stm32mp/stm32mp1/ecdsa_romapi.c . There are two
Makefile entries in each subdirectory. Drop the bogus one and keep
only the correct one, the one in arch/arm/mach-stm32mp/Makefile .
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Sun, 7 Apr 2024 20:21:07 +0000 (22:21 +0200)]
ARM: stm32: Jump to ep on successful resume in PSCI suspend code
In case the system has resumed successfully, the PSCI suspend resume
code has to jump to the 'ep' successful resume entry point code path,
otherwise the code has to jump to content of the LR register, which
points to failed resume code path.
To implement this distinction, rewrite LR register stored on stack
with 'ep' value in case of a successful resume, which is really in
every case unless some catastrophic failure occurred during suspend.
Without this change, Linux counts every resume as failed in
/sys/power/suspend_stats/fail
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Marek Vasut [Tue, 26 Mar 2024 12:07:32 +0000 (13:07 +0100)]
net: dwc_eth_qos: Add support for st, ext-phyclk property
The "st,ext-phyclk" property is a unification of "st,eth-clk-sel"
and "st,eth-ref-clk-sel" properties. All three properties define
ETH CK clock direction, however:
- "st,eth-clk-sel" selects clock direction for GMII/RGMII mode
- "st,eth-ref-clk-sel" selects clock direction for RMII mode
- "st,ext-phyclk" selects clock direction for all RMII/GMII/RGMII modes
The "st,ext-phyclk" is the preferrable property to use.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Christophe ROULLIER <christophe.roullier@foss.st.com>
Marek Vasut [Tue, 26 Mar 2024 12:07:29 +0000 (13:07 +0100)]
net: dwc_eth_qos: Constify st, eth-* values parsed out of DT
Use const bool for the values parsed out of DT. Drop the duplicate
assignment of false into those bool variables, assign them directly
with the content parsed out of DT. Abbreviate the variable name too.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Tue, 26 Mar 2024 12:07:25 +0000 (13:07 +0100)]
net: dwc_eth_qos: Scrub ifdeffery
Replace ifdef CONFIG_CLK with if (CONFIG_IS_ENABLED(CLK)) to improve code
build coverage. Some of the functions printed debug("%s: OK\n", __func__);
on exit with and without CLK enabled, some did not, make it consistent and
print nothing if CLK is disabled.
Marek Vasut [Tue, 26 Mar 2024 12:07:24 +0000 (13:07 +0100)]
net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code
Move board_interface_eth_init() into eqos_probe_syscfg_stm32() in STM32
driver glue code. The eqos_probe_syscfg_stm32() parses STM32 specific DT
properties of this MAC and configures SYSCFG registers accordingly, there
is nothing board specific happening in this function, move it into generic
driver code instead. Drop the now unused duplicates from board files.
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Marek Vasut <marex@denx.de>
Marek Vasut [Tue, 26 Mar 2024 12:07:23 +0000 (13:07 +0100)]
net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config
The current glue code is specific to STM32MP15xx, the upcoming STM32MP13xx
will introduce another entry specific to the STM32MP13xx. Rename the current
entry to eqos_stm32mp15_config in preparation for STM32MP13xx addition. No
functional change.
The FMC2 revision 2 supports security and isolation compliant with
the Resource Isolation Framework (RIF). From RIF point of view,
the FMC2 is composed of several independent resources, listed below,
which can be assigned to different security and compartment domains:
- 0: Common FMC_CFGR register.
- 1: EBI controller for Chip Select 1.
- 2: EBI controller for Chip Select 2.
- 3: EBI controller for Chip Select 3.
- 4: EBI controller for Chip Select 4.
- 5: NAND controller.
Add the support of the revision 2 of FMC2 IP.
- PCSCNTR register has been removed,
- CFGR register has been added,
- the bit used to enable the IP has moved from BCR1 to CFGR,
- the timeout for CEx deassertion has moved from PCSCNTR to BCRx,
- the continuous clock enable has moved from BCR1 to CFGR,
- the clk divide ratio has moved from BCR1 to CFGR.
The MP1 SoCs have only one signal to manage all the controllers (NWAIT).
The MP25 SOC has one RNB signal for the NAND controller and one NWAIT
signal for the memory controller.
Let's use a platform data structure for parameters that will differ
between MP1 and MP25.
Marek Vasut [Mon, 4 Mar 2024 18:25:43 +0000 (19:25 +0100)]
arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM
The OHCI HCD is mandatory for USB 1.1 FS/LS device support, enable it.
This used to be enabled implicitly before, now that implicit dependency
disappeared and this got disabled. Enable it manually.
Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD
This patch avoids compilation issue when CONFIG_USB_GADGET is deactivated
in defconfig, with undefined reference to run_usb_dnl_gadget and to
g_dnl_set_product.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@foundries.io> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
This prints the MMC device being read similar to how we print the MMC
device we write to when e.g. calling saveenv.
One of the side effects is that the boot log now shows from which MMC
device the env was loaded:
Loading Environment from MMC... Reading from MMC(1)... OK
This is useful to identify which MMC device the environment was loaded
from for boards where there are more than one (e.g. eMMC and SD card)
without adding some debug messages manually.
Sadly, there's no way to know which of the default or redundant
environment is being read from env_mmc_load before env_import_redund is
called so it is printing a bit later (and possibly after error/warning
messages).
Michal Simek [Mon, 15 Apr 2024 08:20:05 +0000 (10:20 +0200)]
Kconfig: Remove all default n options
default n doesn't need to be specified. It is default option anyway.
Similar changes have been done by commit 18370f14975c ("Kconfig: Remove all
default n/no options").
Marek Vasut [Sun, 14 Apr 2024 18:37:20 +0000 (20:37 +0200)]
boot: fdt: Turn all addresses and sizes into u64
In case of systems where DRAM bank ends at the edge of 32bit boundary,
start + size calculations would overflow. This happens on STM32MP15xx
with 1 DRAM bank starting at 0xc0000000 and 1 GiB of DRAM. This is a
usual 32bit system DRAM size overflow, fix it by doing all DRAM size
and offset calculations using u64 types. This also covers a case where
a 32bit PAE system might be able to address up to 36bits of DRAM.
Fixes: a4df06e41fa2 ("boot: fdt: Change type of env_get_bootm_low() to phys_addr_t") Signed-off-by: Marek Vasut <marex@denx.de>
This patch adds DEFLATE compression algorithm support. It's a good choice
to trade off between compression ratios and performance compared to LZ4.
Alternatively, DEFLATE could be used for some specific files since EROFS
supports multiple compression algorithms in one image.
Charles Hardin [Fri, 12 Apr 2024 20:45:33 +0000 (13:45 -0700)]
net: add support to parse the NIS domain for the dhcp options
There is code in the bootp parsing for NIS domain and add the
same support for the dhcp options as well. This allows the same
usage of the data when the dhcp command is used in the boot
command.
Signed-off-by: Charles Hardin <ckhardin@gmail.com>
input: button_kbd: gracefully handle buttons that fail probe
If a button device fails to probe, it will still be added to the uclass
device list, and therefore will still be iterated over in
button_read_keys() resulting in a UAF on the buttons private data.
Resolve this by unbinding button devices that aren't active after
probing, and print a warning so it's clear that the button is broken.
Tom Rini [Thu, 18 Apr 2024 18:13:40 +0000 (12:13 -0600)]
Merge tag 'tpm-master-18042024' of https://source.denx.de/u-boot/custodians/u-boot-tpm
Igor says:
"The problem initially was in the TEE sandbox driver implementation
(drivers/tee/sandbox.c) and it's limitations, which doesn't
permit to have multiple simultaneous sessions with different TAs.
This is what actually happened in this CI run [1], firstly "optee_rpmb"
cmd was executed (and after execution we had one session open), and
then "scp03", which also makes calls to OP-TEE, however it fails
in sandbox_tee_open_session() because of this check:
if (state->ta) {
printf("A session is already open\n");
return -EBUSY;
}
I had two ways in mind to address that:
1. Close a session on each optee_rpmb cmd invocation.
I don't see any reason to keep this session open, as obviously
there is no other mechanism (tbh, I don't know if DM calls ".remove" for active
devices) to close it automatically before handing over control to
Linux kernel. As a result we might end up with some orphaned sessions
registered in OP-TEE OS core (obvious resource leak).
2. Extend TEE sandbox driver, add support for multiple
simultaneous sessions just to handle the case.
I've chosen the first approach, as IMO it was "kill two birds with one stone",
I could address resource leak in OP-TEE and bypass limitations of
TEE sandbox driver."
Tom Rini [Thu, 18 Apr 2024 14:29:35 +0000 (08:29 -0600)]
Revert "Merge patch series "pxe: Allow extlinux booting without CMDLINE enabled""
As reported by Jonas Karlman this series breaks booting on some AArch64
platforms with common use cases. For now the best path forward is to
revert the series.
projects / u-boot.git / log
