Detect the GC2145 camera sensor connected to the stm32mp135f-dk
board in order to enable instead the OV5640 if the GC2145 isn't
detected via I2C. For that purpose, necessary dependencies
(regulator / gpio) are enabled and GC2145 ID registers are checked
to determine if the GC2145 is attached or not. If it isn't found,
then the device-tree is updated (camera nodes status & stmipid02
CSI bridge remote node phandle) to enable the OV5640 sensor
and the remote-endpoint property setting in the ov5640 to
make it point to the stmipi endpoint node.
This remote-endpoint property is not setted within the DT by
default in order to avoid a non birectionnal graph connection
warning during DT build.
Change-Id: If56f670e530158d21926148eadb9ec004797ac20
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/242645
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/245022
Set the environment variable "console", used in extlinux.conf file when it
is generated by YOCTO in OpenSTLinux distribution:
UBOOT_EXTLINUX_CONSOLE ??= "console=${console},${baudrate}"
With these 2 variables, U-Boot give dynamically the used console and
baudrate in the Linux kernel bootargs.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I23ed8b36e294031f1f614d2304ea17085f075612
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/241463
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Update the stm32prog command to allow the reception of U-Boot script in
the FlashLayout alternate during the first USB enumeration.
This patch is aligned with the last TF-A behavior: the Flashlayout
is now loaded by U-Boot; it is no more present at STM32_DDR_BASE when
the stm32prog is launched after a serial boot, on UART or on USB.
The received script must be a U-Boot legacy image, no more need to add
a stm32image header.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I08598ebf2b427ac25eaf56e05799ac8d2dc42947
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/240544
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
When a interruption is received during the first USB enumeration
used to received the FlashLayout, with handle ctrl-c, the second
enumeration is not needed and the result for stm32prog_usb_loop
is false (reset is not needed).
This patch avoid the need of a second ctrl to interrupt the command
stm32prog.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Ie76b6efe731c9d721b794d9ad6b394b38492a4df
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/240543
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
As the fip partition is duplicated in eMCC/SDCard for the firmware
update support in TF-A: "fip-a" and "fip-b", the U-Boot use a dedicated
partition named "u-boot-env" to avoid issue when the FIP is updated by
the update agent.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I1fa341f578929363fb0f0194600009f6c6c9e8a8
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/238557
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Add in MTD partitions the new partitions needed by TF-A firmware update:
- metadata to save the TF-A information: 2 copy
- fip-a / fip-b: two FIP slots, used for system A/B (seamless) update
- the previous "fsbl" partition with 2 copy of TFA is replaced
by 2 partitions (only one copy in each MTD partition) to simplify
the update: no need to managed this copy on update, need to update the
two partition (skip bad block for NAND)
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Ie51edf3fe13dabb66fde99eaf781fdd7b1990e3c
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/238556
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Nicolas TOROMANOFF <nicolas.toromanoff@st.com>
Tested-by: Nicolas TOROMANOFF <nicolas.toromanoff@st.com>
Add support of UUID for FIP parttion, required by Firmware update
support in TF-A:
- UUID TYPE for FIP partition: 19d5df83-11b0-457b-be2c-7559c13142a5
- "fip-a" partition UUID: 4fd84c93-54ef-463f-a7ef-ae25ff887087
- "fip-b" partition UUID: 09c54952-d5bf-45af-acee-335303766fb3
This check is done with a new partition type "FIP" associated
at the FIP UUID.
The A/B partition UUID is detected by the partition name:
"fip-a", "fip-b".
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I94e74b521fd55dcc68ab8d000cb93ef48fc12f14
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/238555
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
On eMMC, the erase_grp_size > 1 so the address and size for the erase
block command can be unaligned on erase group size and some strange
trace occurs and the result is not guarantee by MMC devices.
The SD-Card behavior don't change as erase_grp_size = 1 for SD-Card.
For example, on eMMC present on STM32MP15C-EV1, before the patch:
STM32MP> env erase
Erasing Environment on MMC...
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x27ff
16 blocks erased: OK
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x23ff
16 blocks erased: OK
OK
After this patch:
STM32MP> env erase
Erasing Environment on MMC...
1024 blocks erased at 0x2000: OK
1024 blocks erased at 0x2000: OK
OK
Here the 2 copies of U-Boot environment are in the same devices Erase
group: it is erased twice.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I26fa615c6898db0d17024664b17b20412638bfd7
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/238836
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Fix the end address in the message for unaligned erase request in
mmc_berase() when start + blkcnt is aligned to erase_grp_size.
for example:
- start = 0x2000 - 26
- count = 26
- erase_grp_size = 0x400
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x27ff
But no issue when the end address is not aligned, for example
- start = 0x2000 - 2 * 26
- count = 26
- erase_grp_size = 0x400
Caution! Your devices Erase group is 0x400
The erase range would be change to 0x2000~0x23ff
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I5f92544259c3d1dad2df30c9d7762ec7860f07cf
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/238835
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Christophe KERELLO <christophe.kerello@st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
On STMicroelectronics boards, the UART can reliably go up to
- 2000000 bauds when connected to the on-board ST-LINK-V2 for STM32MP15
- 12000000 bauds when connected to the external ST-LINKV3 for STM32MP13
Unfortunately U-Boot will fall back to 115200 unless higher rates are
declared via CONFIG_SYS_BAUDRATE_TABLE.
This patch add the support of higher baudrates on STMicroelectronics
boards with ST-LINK.
Cc: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Change-Id: Ie4aa91b7f1b08b59b02853e7f28c2b48445ba0f6
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/241313
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/239497
On some STM32 SoC's package, GPIO bank may have hole in their GPIO bank
Example:
If GPIO bank have 16 GPIO pins [0-15].
In particular SoC's package case, some GPIO bank can have less GPIO pins:
- [0-10] => 11 pins;
- [2-7] => 6 pins.
Commit dbf928dd26 ("gpio: stm32f7: Add gpio bank holes management")
proposed a first implementation by not counting GPIO "inside" hole. GPIO
are not displaying correctly using gpio or pinmux command when GPIO holes
are located at the beginning of GPIO bank.
To simplify, consider that all GPIO have 16 GPIO and use the gpio_ranges
struct to indicate if a GPIO is mapped or not. GPIO uclass offers several
GPIO functions ("input", "output", "unused", "unknown" and "func"), use
"unknown" GPIO function to indicate that a GPIO is not mapped.
stm32_offset_to_index() is no more needed and removed.
This must be reflected using the "gpio" command to indicate to user
that a particular GPIO is not mapped (marked as "unknown") as shown below:
Example for a 16 pins GPIO bank with the [2-7] mapping (only 6 pins
mapped):
GPIOI0 : unknown
GPIOI1 : unknown
GPIOI2 : analog
GPIOI3 : analog
GPIOI4 : alt function 0 push-pull pull-down
GPIOI5 : alt function 0 push-pull pull-down
GPIOI6 : alt function 0 push-pull pull-down
GPIOI7 : analog
GPIOI8 : unknown
GPIOI9 : unknown
GPIOI10 : unknown
GPIOI11 : unknown
GPIOI12 : unknown
GPIOI13 : unknown
GPIOI14 : unknown
GPIOI15 : unknown
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I55c39a2707fa8dae108d90c4a72590f1a4520ca9
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/239065
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Fabien DESSENNE <fabien.dessenne@foss.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Increase HUB_DEBOUNCE_TIMEOUT to 2000 because some usb device
needs around 1.5 or more to make the hub port status to be
connected steadily after being powered off and powered on.
These value is aligned with Linux driver and avoids to configure
"usb_pgood_delay" as a workaround for connection timeout on
some USB device; normally the env variable "usb_pgood_delay" is used
to delay the first query after power ON and thus the device answer,
not to increase the connection timeout delay.
Commit-notes:
Hi,
I think this patch solves a general issue because a 1s timeout for
USB connection is too short on problematic USB keys.
The issue was introduced by the commit c998da0d67 ("usb: Change
power-on / scanning timeout handling")
Patch in usb_hub allow to avoid patch in each board/driver.
for example, commit 0417169054 ("imx: ventana: add usb_pgood_delay
2sec default") => use pgood_delay = 2s !?
("ARM: stm32: Increase USB power-good delay on DHSOM")
https://patchwork.ozlabs.org/project/uboot/patch/20211113022444.231801-1-marex@denx.de/
or commit 2bf352f0c1 ("usb: dwc2: Add delay to fix the USB
detection problem on SoCFPGA") => patch in USB DWC2 driver to add
a timeout in driver
the commit 319418c01c ("usb: hub: allow pgood_delay to be
specified via env") => introduce env variable for warm-up times
Patrick
END
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I5eabf3f9fdbbaf763cd44e9c018cb5b74a0c65ac
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/236836
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Remove the U-Boot specific add-on for SDMMCv2 IP used in the STM32MP15
as this compatible "st,stm32-sdmmc2" is present in kernel device
tree v5.15-stm32mp-r1.
This patch reduces the device tree difference with kernel device tree.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I1c465a221cb3da2c7b54cbf8467a0f97ba6f397e
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/195269
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Solve a issue with AXI_WIDTH_32 on a the 64 bytes cache line platform;
in this case the requested descriptor padding length should be 12 but the
associated parameter EQOS_DMA_CH0_CONTROL.DSL is limited at 3bits = 7.
As the DMA descriptor can't be correctly aligned with the cache line,
the maintenance of each descriptor can't be guarantee by a simple cache
line operation: flush or invalid.
To avoid all the maintenance issues, these descripto need to be allocated
in a NOT CACHEABLE memory, allocated by noncached_alloc() when
CONFIG_SYS_NONCACHED_MEMORY is enable.
This patch don't change the current behavior when the descriptor
can be cache-aligned with the filed "Descriptor Skip Length" of
the DMA channel control register, when eqos->desc_pad = true.
Change-Id: Iada23492743e3af977e07c1f1b8c2f32550436f7
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/236650
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Christophe ROULLIER <christophe.roullier@st.com>
In clk_clean_rate_cache, clk->rate should update the private clock
struct when CCF is activated to save the cached rate value.
When clk_get_parent_rate is called, the cached information
is read from pclk->rate, with pclk = clk_get_parent(clk)
which use dev_get_clk_ptr() to access to private data.
As the cached is read from private clk data, the update should
be done also on it.
Series-cc: Tero Kristo <t-kristo@ti.com>
Series-cc: Tero Kristo <kristo@kernel.org>
Fixes: 6b7fd3128f ("clk: fix set_rate to clean up cached rates for the hierarchy")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Ifa06360115ffa3f3307372e6cdd98ec16759d6ba
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/236864
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Some I/Os are connected to ADC input channels, when the corresponding bit
in PCSEL register are set on STM32H7 and STM32MP15.
PCSEL shouldn't be let enabled when VDDA supply is disabled, to avoid
current leakage. This may occur if the kernel disable the VDDA supply
of the ADC, while the PCSEL remains set, after leaving U-boot.
Clear PCSEL bits after each end of conversion, when relevant, to
prevent this case.
Change-Id: I147f128cd67392220a8924cf407bcdae0e1eb555
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/233126
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Add smart calibration support for STM32MP1.
- STM32MP15x: both linear & offset calibration are supported
- STM32MP13x: Only offset calibration is supported
Linear calibration:
Linear calibration is SoC dependent and does not change over
time. As it is time consuming, do it only once.
Restore calibration data from environment variable to save time.
If no calibration data are found in u-boot environment variables
run a new calibration.
Offset calibration:
This calibration is fast and may vary over time.
Run offset single-ended and differential calibration on each boot.
Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com>
Change-Id: If8739d96e019d42341901c5da6a83925cc78333a
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/231628
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Before relying on u-boot,force-b-session-valid property presence to set
force_b_session_valid field, use typec_get_driver_from_usb() which check
if a Type-C connector is present. In this case invoke typec_get_data_role()
which indicates if current data role is DEVICE or HOST.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I3dc5da0c332c5b557a855564985317345d25458f
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/232354
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
The typec_get_driver_from_usb() allows to retrieve a Type-C device from
an USB device.
typec_get_driver_from_usb() checks in USB device node for port and endpoint
sub-node, if exist, retrieve the connector node, probe the associated
Type-C device and return it.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: If564cdf463f3915bec26f17a4717c9ab9d42f692
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/232353
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Implement a minimal UCSI uclass which allows to send request
to UCSI compatible chip. It provides the read() and write() ops.
It offers 3 services:
- ucsi_is_attached() which informs if Type-C connector is attached
or not.
- ucsi_get_data_role() which informs if the Type-C controller acts
as Device or host.
- usci_get_nb_connector() which indicates how many connector are
managed.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I319cf1f49b0980d33e2b47f1b14a513eb4466da5
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/232349
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Remove TYPEC_STUSB160X config from board/st/common/Kconfig
before introduction of real stusb160x Type-C driver.
This will avoid the following Kconfig warning:
drivers/usb/typec/Kconfig:15:warning: ignoring type redefinition of 'TYPEC_STUSB160X' from 'tristate' to 'bool'
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: Ia464dcc7e1b5e3c6e8c8ccd8c3ac84d858ae8588
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/232344
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Update the Linux kernel device tree to support boot with TF-A SP-MIN and
without OP-TEE on STM32MP15 platform.
By default the Linux kernel have OP-TEE nodes, including the SCMI agent,
to support the boot with OP-TEE, the default supported boot mode.
For the TF-A SP-MIN support, the OP-TEE nodes need to be dynamically
updated, including the reserved memory and the SCMI agent nodes.
This patch allows to support this legacy mode, boot with TF-A SP-MIN as
secure monitor and without OP-TEE, with the latest device tree.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: I6ba5eb92850869ab08d5c09bf119089fb283a4a8
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/228518
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/236082
Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Change the mask of OTP0 used to close the device on STM32MP
- STM32MP15x: bit 6 of OPT0
- STM32MP13x: 0b111111 = 0x3F for OTP_SECURED closed device
And support the 2 keys for STM32MP13x
- PKHTH : Hash of the 8 ECC Public Keys Hashes Table
(ECDSA is the authentication algorithm)
- EDMK : Encryption/Decryption Master Key
Change-Id: I1431827b62d294343069ff0aa7e59abaacb8bdd5
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/230109
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/242599
