In case USB hub regulator is shared, unexpected behavior occurs.
On stm32mp135f-dk, stm32mp157c-ev1 and stm32mp157x-dkx, regulator
v3v3 is shared between several IP/devices (USB, panel, ethernet phy,
camera, ...).
Running command "usb stop", v3v3 regulator is switched off and
the splashscreen content disappear.
v3v3 shouldn't be disabled on usb_onboard_hub_remove() callback.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: If7ed2ccb5a1c1a84637d29d763cc1935d9b8815e
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/299563
ACI: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Fabrice GASNIER <fabrice.gasnier@foss.st.com>
Domain-Review: Fabrice GASNIER <fabrice.gasnier@foss.st.com>
EFI device paths for block devices must be unique. If a non-unique device
path is discovered, probing of the block device fails.
Currently we use UsbClass() device path nodes. As multiple devices may
have the same vendor and product id these are non-unique. Instead we
should use Usb() device path nodes. They include the USB port on the
parent hub. Hence they are unique.
A USB storage device may contain multiple logical units. These can be
modeled as Ctrl() nodes.
[Backport of commit e472ef8a3d ("efi_loader: fix device-path for
USB devices")]
Reported-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Change-Id: Ie4c356c0b597fcd8b461c2e0d219740db4a8473d
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/297489
Tested-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
Reduces the CONFIG_DDR_CACHEABLE_SIZE, the size of DDR mapped cacheable
before relocation, to support DDR with only 256MB because the OP-TEE
reserved memory is located at end of the DDR.
By default the new size of 128MB cacheable memory is enough
in dram_bank_mmu_setup() for early_enable_caches() in arch_cpu_init()
and is correct for DDR size = 256MB.
After relocation the real size of DDR, excluding the no-map reserved
memory, is used after the U-Boot device tree parsing.
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Ib054753be65d3ea7a0b3fd189c0a0422d19b37c2
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/294875
ACI: CITOOLS <MDG-smet-aci-reviews@list.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
Currently, in stm32_qspi_claim_bus(), QSPI_CR and QSPI_DCR registers
are saved in stm32_ospi_flash struct on first flash memory initialization
and restored on each flash accesses.
As the logic of spi-uclass.c changed since commit
741280e9ac ("spi: spi-uclass: Fix spi_claim_bus() speed/mode setup logic"),
set_speed() and set_mode() callbacks are called systematically when bus
speed or bus mode need to be updated, QSPI_CR and QSPI_DCR registers are
set accordingly.
So stm32_qspi_claim_bus() can be updated by removing QSPI_CR and QSPI_DCR
save/restore code and struct stm32_ospi_flash can be removed as well.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: Ib14cd764550191e02a7c587bc4b62d29d1c08765
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/295910
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Domain-Review: Christophe KERELLO <christophe.kerello@st.com>
Change the default base for offset parsing with simple_strtoull(),
so offset in flashlayout is coded in base 10 by default, even if string
start with '0'. The Octal encoding is not supported. The base 16
is still supported when the '0x' header is detected.
This patch solve unexpected parsing result when the address,
provided by decimal value is starting by 0, for example 0x4400 = 00017408
is a invalid with current code.
...
P 0x04 fsbl1 Binary mmc0 00017408 tf-a.stm32
....
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Icec632d485db8fb4f25d878dd3b90253a7b2c706
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/296166
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
ACI: CITOOLS <MDG-smet-aci-reviews@list.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
When mtdparts and mtdids are empty, the parsing of partitions defined in
device-trees via the `partitions` node with `fixed-partitions` compatible
should be executed one time but it not the case now because
old_mtdparts = mtdparts = old_mtdids = mtdids = NULL
so the first test is always true.
The test on mtd_dev_list_updated() resutl should be done unconditionally
to parse again the device tree is the MTD DEV list change after the call of
mtd_probe_uclass_mtd_devs() / mtd_probe_uclass_spi_nor_devs().
Fixes: dc339bf784 ("mtd: add support for parsing partitions defined in OF")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Ib7980b3efd19fd542a4b6e60d47f8136fdfd1454
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/289323
ACI: CITOOLS <MDG-smet-aci-reviews@list.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
Since commit c0364ce1c6 ("doc/README.gpt: define partition type GUID for
U-Boot environment"), a specific type GUID can be used to indicate
the U-Boot environment partition on the device with GPT partition table.
This patch uses this type GUID to found the env partition as fallback
when the partition name property "u-boot,mmc-env-partition" is not present
in config node or if the indicated partition name is not found.
The mmc_offset_try_partition() function is reused, it selects the first
partition with the correct type GUID when the parameter 'str' is NULL.
[Backport of commit 80105d8fd5 ("env: mmc: select GPT env partition by
type guid")]
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I0a9d81be69475c89cac4f007332fc368197d2868
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/284267
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
Activate by default CONFIG_ENV_MMC_USE_DT as "u-boot,mmc-env-partition"
should be always use in STMicroelectronics boards device tree to locate
the environment for mmc backend. The 2 defines:
CONFIG_ENV_OFFSET=0x280000
CONFIG_ENV_OFFSET_REDUND=0x2C0000
are only valid for spi-nor and not for SD-Card or eMMC.
[Backport of commit 0902bcdbb3 ("configs: stm32mp: activate
CONFIG_ENV_MMC_USE_DT")]
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I0bc109d437812cbb99876e1e14a2427a0a78250e
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/284266
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
Add a new config CONFIG_ENV_MMC_USE_DT to force configuration of the
U-Boot environment offset with device tree config node.
This patch avoids issues when several CONFIG_ENV_IS_IN_XXX are activated,
the defconfig file uses the same value for CONFIG_ENV_OFFSET or
CONFIG_ENV_OFFSET_REDUND for the several ENV backends (SPI_FLASH, EEPROM
NAND, SATA, MMC).
After this patch a bad offset value is not possible when the selected
partition in device tree is not found.
[Backport of commit d2103e20a9 ("env: mmc: add CONFIG_ENV_MMC_USE_DT")]
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I18a4322bc0a4cbe82fbc904deea8736ee06906e6
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/284265
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
This file has a lot of conditional code and much of it is unnecessary.
Clean this up to reduce the number of build combinations.
This patch replaces the test on CONFIG_ENV_OFFSET_REDUND for the
more coherent CONFIG_SYS_REDUNDAND_ENVIRONMENT.
This patch also corrects a compilation issue in init_mmc_for_env()
when CONFIG_SYS_MMC_ENV_PART is not activated, env_mmc_orig_hwpart is
not defined.
[Backport of commit 46c9016b7f ("env: mcc: Drop unnecessary #ifdefs")]
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Change-Id: I580f48ee15bb77074eed8d66b85950a133476f17
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/284263
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
The API reset_release_all should only release the reset bulk resources
and not change the reset level with de-assert.
In U-Boot, it is the responsibility of the caller (each driver) to call
reset_assert_all if the reset level need to be handle, as it is done by
the single reset API: reset_request/reset_free.
This patch avoids issue when a reset line is shared by several drivers;
the bulk resets are requested and de-asserted in probe
with reset_get_bulk()/reset_deassert_bulk() and the reset_release_all()
is called in remove to release the associated resource
but the de-assert must not be performed for shared reset.
It is it the case for shared reset for generic EHCI / OHCI, the common
reset linux is managed in Linux kernel by shared reset API
devm_reset_control_get_shared() = performs de-assert only for the last
users.
I think it is the good time to change this behavior as the reset bulk
API is not yet massively used in driver.
Fixes: 3b9d1bdd4e ("reset: add reset_release_all()")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Change-Id: Ia77c62ce3ca45336d9126875d5bbfba74214a7b4
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/293200
ACI: CITOOLS <MDG-smet-aci-reviews@list.st.com>
Reviewed-by: Fabrice GASNIER <fabrice.gasnier@foss.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Domain-Review: Patrice CHOTARD <patrice.chotard@foss.st.com>
EHCI is usually used with companion controller (like OHCI) as companion
controller. This information on the companion is missing currently in
companion drivers.
So, if the usb-uclass isn't aware, it may scan busses in any order: OHCI
first, then EHCI.
This is seen on STM32MP1 where DT probing makes the probe order to occur
by increasing address (OHCI address < EHCI address).
When a low speed or full-speed device is plugged in, it's not detected as
EHCI should first detect it, and give ownership (handover) to OHCI.
Current situation on STM32MP1 (with a low speed device plugged-in)
STM32MP> usb start
starting USB...
Bus usb@5800c000: USB OHCI 1.0
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800c000 for devices... 1 USB Device(s) found
scanning bus usb@5800d000 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
The "companion" property in the device tree allow to retrieve companion
controller information, from the EHCI node. This allow marking the
companion driver as such.
With this patch (same low speed device plugged in):
STM32MP> usb start
starting USB...
Bus usb@5800c000: USB OHCI 1.0
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices... 1 USB Device(s) found
scanning bus usb@5800c000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
STM32MP> usb tree
USB device tree:
1 Hub (12 Mb/s, 0mA)
| U-Boot Root Hub
|
+-2 Human Interface (1.5 Mb/s, 100mA)
HP HP USB 1000dpi Laser Mouse
1 Hub (480 Mb/s, 0mA)
u-boot EHCI Host Controller
This also optimize bus scan when a High speed device is plugged in, as
the usb-uclass skips OHCI in this case:
STM32MP> usb reset
resetting USB...
Bus usb@5800c000: USB OHCI 1.0
Bus usb@5800d000: USB EHCI 1.00
scanning bus usb@5800d000 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
STM32MP> usb tree
USB device tree:
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Mass Storage (480 Mb/s, 200mA)
SanDisk Cruzer Blade 03003432021922011407
Change-Id: I42ee83786bfdd9d715c229eae8f8b5fa50f42b7c
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/u-boot/+/289910
ACI: CITOOLS <MDG-smet-aci-reviews@list.st.com>
ACI: CIBUILD <MDG-smet-aci-builds@list.st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Reviewed-by: Patrice CHOTARD <patrice.chotard@foss.st.com>
Domain-Review: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
