Re: [PATCH v2 1/4] tools: mkeficapsule: Add support for parsing capsule params from config file
On 19.04.24 08:55, Sughosh Ganu wrote:
Add support for specifying the parameters needed for capsule
generation through a config file, instead of passing them through
command-line. Parameters for more than a single capsule file can be
specified, resulting in generation of multiple capsules through a
single invocation of the command.
The config file can be passed to the mkeficapsule tool in such manner
$ ./tools/mkeficapsule -f
Please, mention the long option.
Signed-off-by: Sughosh Ganu
---
tools/Kconfig | 15 ++
tools/Makefile | 1 +
tools/eficapsule.h | 114
tools/mkeficapsule.c | 87 +
tools/mkeficapsule_parse.c | 352 +
5 files changed, 538 insertions(+), 31 deletions(-)
create mode 100644 tools/mkeficapsule_parse.c
diff --git a/tools/Kconfig b/tools/Kconfig
index 667807b331..0362ca8e45 100644
--- a/tools/Kconfig
+++ b/tools/Kconfig
@@ -104,6 +104,21 @@ config TOOLS_MKEFICAPSULE
optionally sign that file. If you want to enable UEFI capsule
update feature on your target, you certainly need this.
+config EFI_CAPSULE_CFG_FILE
+ string "Path to the EFI Capsule Config File"
+ help
+ Path to the EFI capsule config file which provides the
+ parameters needed to build capsule(s). Parameters can be
+ provided for multiple payloads resulting in corresponding
+ capsule images being generated.
This help test does not explain if this is a parameter for binman or
something built into mkeficapsule.
We should not hard code any path inside mkeficapsule.
I can't see the new CONFIG parameters used within the code changes of
this patch. Please, add them into the patches where they are needed.
+
+config EFI_USE_CAPSULE_CFG_FILE
+ bool "Use the config file for generating capsules"
+ help
+ Boolean option used to specify if the EFI capsules are to
+ be generated through parameters specified via the config
+ file or through command line.
Given this help text I would not know if this option changes how
mkeficapsule is built or how binman invokes it.
I would expect that mkeficapsule is always built in a way that a
configuration file can be passed.
Furthermore I would expect binman to invoke mkeficapsule with the
appropriate command line parameters if you have enabled building capsules.
Why do we need this configuration parameter? Just always build
mkeficapsule with support for the -f parameter.
Best regards
Heinrich
+
menuconfig FSPI_CONF_HEADER
bool "FlexSPI Header Configuration"
help
diff --git a/tools/Makefile b/tools/Makefile
index 6a4280e366..4311f5914f 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -253,6 +253,7 @@ HOSTLDLIBS_mkeficapsule += \
HOSTLDLIBS_mkeficapsule += \
$(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
+mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
mkfwumdata-objs := mkfwumdata.o generated/lib/crc32.o
HOSTLDLIBS_mkfwumdata += -luuid
diff --git a/tools/eficapsule.h b/tools/eficapsule.h
index 6efd07d2eb..71a08b62e6 100644
--- a/tools/eficapsule.h
+++ b/tools/eficapsule.h
@@ -54,6 +54,12 @@ typedef struct {
/* flags */
#define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
+enum capsule_type {
+ CAPSULE_NORMAL_BLOB = 0,
+ CAPSULE_ACCEPT,
+ CAPSULE_REVERT,
+};
+
struct efi_capsule_header {
efi_guid_t capsule_guid;
uint32_t header_size;
@@ -145,4 +151,112 @@ struct fmp_payload_header_params {
uint32_t fw_version;
};
+/**
+ * struct efi_capsule_params - Capsule parameters
+ * @image_guid: Guid value of the payload input image
+ * @image_index: Image index value
+ * @hardware_instance: Hardware instance to be used for the image
+ * @fmp: FMP payload header used for storing firmware version
+ * @monotonic_count: Monotonic count value to be used for signed capsule
+ * @privkey_file: Path to private key used in capsule signing
+ * @cert_file: Path to public key certificate used in capsule signing
+ * @input_file: Path to payload input image
+ * @capsule_file: Path to the output capsule file
+ * @oemflags: Oemflags to be populated in the capsule header
+ * @capsule: Capsule Type, normal or accept or revert
+ */
+struct efi_capsule_params {
+ efi_guid_t *image_guid;
+ unsigned long image_index;
+ unsigned long hardware_instance;
+ struct fmp_payload_header_params fmp;
+ uint64_t monotonic_count;
+ char *privkey_file;
+ char *cert_file;
+ char *input_file;
+ char *capsule_file;
+ unsigned long oemflags;
+ enum capsule_type capsule;
+};
+
+/**
+ * capsule_with_cfg_file() - Generate capsule from config file
+ * @cfg_file: Path to the config file
+ *
+ * Parse the capsule parameters from the config file and use the
+ * parameters for generating one o
Re: [PATCH v2 2/4] doc: Document capsule generation through a config file
On 19.04.24 08:55, Sughosh Ganu wrote:
The UEFI capsule can now be generated by specifying the capsule
parameters through a config file. Highlight these changes in the
documentation.
Signed-off-by: Sughosh Ganu
---
doc/develop/uefi/uefi.rst | 70 +++
1 file changed, 70 insertions(+)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index 0389b269c0..8586127a83 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -318,6 +318,76 @@ Run the following command
--guid \
The users deserve a man-page mkeficapsule.1 that can be installed by
distros as /usr/share/doc/man/man1/mkeficapsule.1.
Do not expect the user to look up the information online.
+Alternatively, the capsules can be generated through a config
+file. When generating the capsules through a config file, the Kconfig
+symbol CONFIG_EFI_CAPSULE_CFG_FILE is to be used for specifying the
+path to the config file.
Why do we need CONFIG_EFI_CAPSULE_CFG_FILE? You could use a fixed path
or an environment parameter.
+
+The config file describes the parameters that are used for generating
+one or more capsules. The parameters for a given capsule file are
+specified within curly braces, in the form of "key:value" pairs. All
+the parameters that are currently supported by the mkeficapsule tool
+can be specified through the config file.
+
+The following are some example payload parameters specified through
+the config file.
+
+.. code-block:: none
+
+ {
+ image-guid: 02f4d760-cfd5-43bd-8e2d-a42acb33c660
+ hardware-instance: 0
+ monotonic-count: 1
+ payload: u-boot.bin
+ image-index: 1
+ fw-version: 2
+ private-key: /path/to/priv/key
+ pub-key-cert: /path/to/pub/key
+ capsule: u-boot.capsule
+ }
+ {
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ hardware-instance: 0
+ payload: u-boot.itb
+ image-index: 2
+ fw-version: 7
+ oemflags: 0x8000
+ capsule: fit.capsule
+ }
+ {
+ capsule-type: accept
+ image-guid: 4ce292da-1dd8-428d-a1c2-77743ef8b96e
+ capsule: accept.capsule
+ }
+ {
+ capsule-type: revert
+ capsule: revert.capsule
+ }
Is this one file? Are these multiple files? If these are multiple files,
please, put them in different code blocks.
What are the curly braces good for? Please, use an established file
format like YAML or JSON.
+
+The following are the keys that specify the capsule parameters
+
+..code-block:: none
+
+image-guid: Image GUID
Please use the following formatting:
image-guid
Image GUID
fw-version
Image version
+image-index: Image index value
+fw-version: Image version
+private-key: Path to the private key file used for capsule signing
+pub-key-cert: Path to the public key crt file used for capsule signing
+payload: Path to the capsule payload file
+capsule: Path to the output capsule file that is generated
+hardware-instance: Hardware Instance value
Please, explain what a hardware instance is.
+monotonic-count: Monotonic count value
Please, explain what it is used for.
+capsule-type: Specifies capsule type. normal(default), accept or revert
ditto
+oemflags: 16bit Oemflags value to be used(populated in capsule header)
ditto
+
+When generating capsules through a config file, the command would look
+like
+
+.. code-block:: console
+
+$ mkeficapsule --cfg-file
All available command line parameters of mkeficapsule should be
described in one place.
Best regards
Heinrich
+
+
Capsule with firmware version
*
[PATCH] efi_loader: change the error message when storing EFI variables
When we try to store EFI variables on a file, we need to use an ESP.
if an ESP is not found, variables will change in memory, but U-Boot
won't be able to restore them across reboots.
Adjust the error message so users can understand what's going on
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_var_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index 413e1794e88c..5276740ffe7a 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -82,7 +82,7 @@ efi_status_t efi_var_to_file(void)
error:
if (ret != EFI_SUCCESS)
- log_err("Failed to persist EFI variables\n");
+ log_err("ESP not found. UEFI variables won't persist
reboots\n");
free(buf);
return ret;
#else
--
2.43.0
Re: [PATCH] stm32mp: Reserve OPTEE area in EFI memory map
On 4/17/24 09:45, Heinrich Schuchardt wrote:
> On 17.04.24 09:25, Patrick DELAUNAY wrote:
>> Hi,
>>
>> On 3/8/24 11:12, Patrice Chotard wrote:
>>> Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory")
>>> memory region above ram_top is tagged in EFI memory map as
>>> EFI_BOOT_SERVICES_DATA.
>>> In case of STM32MP1 platform, above ram_top, there is one reserved-memory
>>> region tagged "no-map" dedicated to OP-TEE (addr=de00 size=200).
>>>
>>> Before booting kernel, EFI memory map is first built, the OPTEE region is
>>> tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE
>>> is used.
>>>
>>> Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions()
>>> which try to add again the same OPTEE region (addr=de00 size=200)
>>> but now with LMB_NOMAP tag which produces the following error message :
>>>
>>> "ERROR: reserving fdt memory region failed (addr=de00 size=200
>>> flags=4)"
>>>
>>> To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark
>>> it as reserved.
>>>
>>> Signed-off-by: Patrice Chotard
>>> ---
>>>
>>> arch/arm/mach-stm32mp/dram_init.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-stm32mp/dram_init.c
>>> b/arch/arm/mach-stm32mp/dram_init.c
>>> index fb1208fc5d5..f67f54f2ae0 100644
>>> --- a/arch/arm/mach-stm32mp/dram_init.c
>>> +++ b/arch/arm/mach-stm32mp/dram_init.c
>>> @@ -7,6 +7,7 @@
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -75,3 +76,14 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
>>> total_size)
>>> return reg + size;
>>> }
>>> +
>>> +void efi_add_known_memory(void)
>>> +{
>>> + if (IS_ENABLED(CONFIG_EFI_LOADER))
>>> + /*
>>> + * Memory over ram_top is reserved to OPTEE.
>>> + * Declare to EFI only memory area below ram_top
>>> + */
>>> + efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
>>> + EFI_CONVENTIONAL_MEMORY);
>
> With this change the EFI memory map passed to the operating system will
> not contain any memory above gd->ram_top. Is this really your intent?
> Don't you have any memory above 0xe000?
Hi Heinrich
On stm32mp157x-dk and stm32mp135x-dk boards, there is no memory above
0xe000.
But, on stm32mp157x-ed1 or stm32mp157x-ev1, you are right, we got memory above
0xe000.
I will rework this patch to take into account memory that could be present
above OPTEE area.
Thanks for pointing this
Patrice
>
> Best regards
>
> Heinrich
>
>>> +}
>>
>>
>>
>> Reviewed-by: Patrick Delaunay
>>
>> Thanks
>> Patrick
>>
>
Re: [PATCH] efi_loader: change the error message when storing EFI variables
On 19.04.24 09:42, Ilias Apalodimas wrote:
When we try to store EFI variables on a file, we need to use an ESP.
if an ESP is not found, variables will change in memory, but U-Boot
won't be able to restore them across reboots.
Adjust the error message so users can understand what's going on
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_var_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index 413e1794e88c..5276740ffe7a 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -82,7 +82,7 @@ efi_status_t efi_var_to_file(void)
error:
if (ret != EFI_SUCCESS)
- log_err("Failed to persist EFI variables\n");
+ log_err("ESP not found. UEFI variables won't persist
reboots\n");
%s/reboots/reboot/ We can't look further into the future.
A missing ESP is not the only possible failure cause. How about
* no space on disk
* already 512 entries in FAT12 root directory
Best regards
Heinrich
free(buf);
return ret;
#else
Re: [PATCH] efi_loader: change the error message when storing EFI variables
Hi Heinrich
On Fri, 19 Apr 2024 at 10:51, Heinrich Schuchardt
wrote:
>
> On 19.04.24 09:42, Ilias Apalodimas wrote:
> > When we try to store EFI variables on a file, we need to use an ESP.
> > if an ESP is not found, variables will change in memory, but U-Boot
> > won't be able to restore them across reboots.
> >
> > Adjust the error message so users can understand what's going on
> >
> > Signed-off-by: Ilias Apalodimas
> > ---
> > lib/efi_loader/efi_var_file.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
> > index 413e1794e88c..5276740ffe7a 100644
> > --- a/lib/efi_loader/efi_var_file.c
> > +++ b/lib/efi_loader/efi_var_file.c
> > @@ -82,7 +82,7 @@ efi_status_t efi_var_to_file(void)
> >
> > error:
> > if (ret != EFI_SUCCESS)
> > - log_err("Failed to persist EFI variables\n");
> > + log_err("ESP not found. UEFI variables won't persist
> > reboots\n");
>
> %s/reboots/reboot/ We can't look further into the future.
>
> A missing ESP is not the only possible failure cause. How about
>
> * no space on disk
> * already 512 entries in FAT12 root directory
>
How about creating 2 error messages?
One stating the ESP is missing and another for write errors?
Thanks
/Ilias
> Best regards
>
> Heinrich
>
> > free(buf);
> > return ret;
> > #else
>
Re: [PATCH v2 4/5] arm: apple: Switch to standard boot
> From: Janne Grunau via B4 Relay > Date: Thu, 18 Apr 2024 21:00:28 +0200 > > From: Janne Grunau > > Use standard boot instead of the distro boot scripts. Use > BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use. > > Signed-off-by: Janne Grunau Reviewed-by: Mark Kettenis > --- > arch/arm/Kconfig| 2 +- > include/configs/apple.h | 20 ++-- > 2 files changed, 3 insertions(+), 19 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 01d6556c42..9b83b2e6f8 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1034,7 +1034,7 @@ config ARCH_APPLE > select USB > imply CMD_DM > imply CMD_GPT > - imply DISTRO_DEFAULTS > + imply BOOTSTD_FULL > imply OF_HAS_PRIOR_STAGE > > config ARCH_OWL > diff --git a/include/configs/apple.h b/include/configs/apple.h > index a70440b3ad..1e08b11448 100644 > --- a/include/configs/apple.h > +++ b/include/configs/apple.h > @@ -9,26 +9,10 @@ > "stdout=vidconsole,serial\0" \ > "stderr=vidconsole,serial\0" > > -#if IS_ENABLED(CONFIG_CMD_NVME) > - #define BOOT_TARGET_NVME(func) func(NVME, nvme, 0) > -#else > - #define BOOT_TARGET_NVME(func) > -#endif > - > -#if IS_ENABLED(CONFIG_CMD_USB) > - #define BOOT_TARGET_USB(func) func(USB, usb, 0) > -#else > - #define BOOT_TARGET_USB(func) > -#endif > - > -#define BOOT_TARGET_DEVICES(func) \ > - BOOT_TARGET_NVME(func) \ > - BOOT_TARGET_USB(func) > - > -#include > +#define BOOT_TARGETS "nvme usb" > > #define CFG_EXTRA_ENV_SETTINGS \ > ENV_DEVICE_SETTINGS \ > - BOOTENV > + "boot_targets=" BOOT_TARGETS "\0" > > #endif > > -- > 2.44.0 > > > >
Re: [PATCH v2 5/5] arm: apple: Do not list bootflows on boot
> From: Janne Grunau via B4 Relay > Date: Thu, 18 Apr 2024 21:00:29 +0200 > > From: Janne Grunau > > The bootflow list is only seen briefly and is probably more confusing > than helpful. To be honest, I think that applies to all boards using BOOTSSTD_FILL. Which probably means the -l should be dropped from the default BOOTCOMMAND for BOOTSTD_FULL. But until that happens: Reviewed-by: Mark Kettenis > > Signed-off-by: Janne Grunau > --- > configs/apple_m1_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig > index c30aec7c55..4eac1a9e2d 100644 > --- a/configs/apple_m1_defconfig > +++ b/configs/apple_m1_defconfig > @@ -8,6 +8,7 @@ CONFIG_SYS_CBSIZE=256 > CONFIG_SYS_PBSIZE=276 > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_DISPLAY_BOARDINFO_LATE=y > +CONFIG_BOOTCOMMAND="bootflow scan -b" > CONFIG_BOARD_LATE_INIT=y > CONFIG_CMD_SELECT_FONT=y > # CONFIG_NET is not set > > -- > 2.44.0 > > > >
Re: [PATCH v3] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
On 4/19/24 05:59, Marek Vasut wrote: > 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 > Signed-off-by: Marek Vasut > --- > Cc: Igor Opaniuk > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Simon Glass Cc: Simon Glass > Cc: Tom Rini > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > V2: Fix up the BKPRWD/BKPWD mask typo > V3: - Update the allocation to 0x20/0x20 > - Update commit message > - Add RB from Patrick > --- > arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 > 1 file changed, 16 insertions(+) > > diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > index dd99150fbc2..d75ec99d6a1 100644 > --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c > @@ -14,6 +14,7 @@ > #include > #include > #include > +#include > > /* RCC register */ > #define RCC_TZCR (STM32_RCC_BASE + 0x00) > @@ -41,6 +42,9 @@ > #define TZC_REGION_ID_ACCESS0(STM32_TZC_BASE + 0x114) > > #define TAMP_CR1 (STM32_TAMP_BASE + 0x00) > +#define TAMP_SMCR(STM32_TAMP_BASE + 0x20) > +#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0) > +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16) > > #define PWR_CR1 (STM32_PWR_BASE + 0x00) > #define PWR_MCUCR(STM32_PWR_BASE + 0x14) > @@ -136,6 +140,18 @@ static void security_init(void) >*/ > writel(0x0, TAMP_CR1); > > + /* > + * TAMP: Configure non-zero secure protection settings. This is > + * checked by BootROM function 35ac on OTP-CLOSED device during > + * CPU core 1 release from endless loop. If secure protection > + * fields are zero, the core 1 is not released from endless > + * loop on second SGI0. > + */ > + clrsetbits_le32(TAMP_SMCR, > + TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT, > + FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) | > + FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20)); > + > /* GPIOZ: deactivate the security */ > writel(BIT(0), RCC_MP_AHB5ENSETR); > writel(0x0, GPIOZ_SECCFGR); Hi Marek Reviewed-by: Patrice Chotard Thanks Patrice
[PATCH v2] efi_loader: change the error message when storing EFI variables
When we try to store EFI variables on a file, we need to use an ESP.
if an ESP is not found, variables will change in memory, but U-Boot
won't be able to restore them across reboots.
Adjust the error message so users can understand what's going on
Signed-off-by: Ilias Apalodimas
---
Changes since v1:
- print different messages if ESP is missing or write to file failed
lib/efi_loader/efi_var_file.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
index 413e1794e88c..d5d347d50f8d 100644
--- a/lib/efi_loader/efi_var_file.c
+++ b/lib/efi_loader/efi_var_file.c
@@ -73,16 +73,20 @@ efi_status_t efi_var_to_file(void)
goto error;
ret = efi_set_blk_dev_to_system_partition();
- if (ret != EFI_SUCCESS)
+ if (ret != EFI_SUCCESS) {
+ log_err("ESP not found.");
goto error;
+ }
r = fs_write(EFI_VAR_FILE_NAME, map_to_sysmem(buf), 0, len, &actlen);
- if (r || len != actlen)
+ if (r || len != actlen) {
+ log_err("Failed to store variables.");
ret = EFI_DEVICE_ERROR;
+ }
error:
if (ret != EFI_SUCCESS)
- log_err("Failed to persist EFI variables\n");
+ log_err(" UEFI variables won't persist reboot\n");
free(buf);
return ret;
#else
--
2.43.0
[GIT PULL] Please pull u-boot-dfu-20240419
Hi Tom, Here is a new development for master: - new "fastboot oem board" command This CI job is at https://source.denx.de/u-boot/custodians/u-boot-dfu/-/pipelines/20427 Thanks, Mattijs The following changes since commit 2c3fa4b8add3cb6a440184ab67debc6867d383c0: sandbox: don't call os_close with invalid file descriptor (2024-04-17 17:06:16 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-dfu.git tags/u-boot-dfu-20240419 for you to fetch changes up to b2acf59baf917c3b4002c1b2094ddb46c03ab02e: fastboot: introduce 'oem board' subcommand (2024-04-18 14:54:38 +0200) ---- u-boot-dfu-20240419 - new "fastboot oem board" command Alexey Romanov (1): fastboot: introduce 'oem board' subcommand doc/android/fastboot.rst | 18 ++ drivers/fastboot/Kconfig | 7 +++ drivers/fastboot/fb_command.c | 30 ++ include/fastboot.h| 1 + 4 files changed, 56 insertions(+)
Re: [PATCH v2] efi_loader: change the error message when storing EFI variables
Heinrich
Please ignore this, I missed that we already report that in
efi_set_blk_dev_to_system_partition()
Apologies for the noise
/Ilias
On Fri, Apr 19, 2024 at 12:45:45PM +0300, Ilias Apalodimas wrote:
> When we try to store EFI variables on a file, we need to use an ESP.
> if an ESP is not found, variables will change in memory, but U-Boot
> won't be able to restore them across reboots.
>
> Adjust the error message so users can understand what's going on
>
> Signed-off-by: Ilias Apalodimas
> ---
> Changes since v1:
> - print different messages if ESP is missing or write to file failed
>
> lib/efi_loader/efi_var_file.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c
> index 413e1794e88c..d5d347d50f8d 100644
> --- a/lib/efi_loader/efi_var_file.c
> +++ b/lib/efi_loader/efi_var_file.c
> @@ -73,16 +73,20 @@ efi_status_t efi_var_to_file(void)
> goto error;
>
> ret = efi_set_blk_dev_to_system_partition();
> - if (ret != EFI_SUCCESS)
> + if (ret != EFI_SUCCESS) {
> + log_err("ESP not found.");
> goto error;
> + }
>
> r = fs_write(EFI_VAR_FILE_NAME, map_to_sysmem(buf), 0, len, &actlen);
> - if (r || len != actlen)
> + if (r || len != actlen) {
> + log_err("Failed to store variables.");
> ret = EFI_DEVICE_ERROR;
> + }
>
> error:
> if (ret != EFI_SUCCESS)
> - log_err("Failed to persist EFI variables\n");
> + log_err(" UEFI variables won't persist reboot\n");
> free(buf);
> return ret;
> #else
> --
> 2.43.0
>
[PATCH 1/1] efi_loader: superfluous efi_restore_gd after EFI_CALL
EFI_CALL() invokes __efi_entry_check() which executes set_gd(efi_gd). There is no need to execute set_gd(efi_gd) again via efi_restore_gd(). Signed-off-by: Heinrich Schuchardt --- cmd/bootefi.c | 1 - cmd/efidebug.c | 2 -- lib/efi_loader/efi_helper.c | 2 -- 3 files changed, 5 deletions(-) diff --git a/cmd/bootefi.c b/cmd/bootefi.c index 578dbb19a7e..c1454ffb948 100644 --- a/cmd/bootefi.c +++ b/cmd/bootefi.c @@ -107,7 +107,6 @@ static int do_efi_selftest(void) /* Execute the test */ ret = EFI_CALL(efi_selftest(&image_obj->header, &systab)); - efi_restore_gd(); free(loaded_image_info->load_options); efi_free_pool(test_device_path); efi_free_pool(test_image_path); diff --git a/cmd/efidebug.c b/cmd/efidebug.c index 32c64711b6c..30def6b6831 100644 --- a/cmd/efidebug.c +++ b/cmd/efidebug.c @@ -1466,8 +1466,6 @@ static __maybe_unused int do_efi_test_bootmgr(struct cmd_tbl *cmdtp, int flag, if (ret && exit_data) efi_free_pool(exit_data); - efi_restore_gd(); - free(load_options); return CMD_RET_SUCCESS; } diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c index 58761fae784..88c3586787e 100644 --- a/lib/efi_loader/efi_helper.c +++ b/lib/efi_loader/efi_helper.c @@ -544,8 +544,6 @@ efi_status_t do_bootefi_exec(efi_handle_t handle, void *load_options) } } - efi_restore_gd(); - out: free(load_options); -- 2.43.0
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On 18/04/24 17:30, Sughosh Ganu wrote: On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote: On 17/04/24 21:34, Tom Rini wrote: On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote: hi Chintan, On Wed, 17 Apr 2024 at 13:21, Chintan Vankar wrote: On 16/04/24 22:30, Tom Rini wrote: On Tue, Apr 16, 2024 at 05:52:58PM +0530, Chintan Vankar wrote: On 12/04/24 03:37, Tom Rini wrote: On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote: On 22/01/24 10:11, Siddharth Vadapalli wrote: On 20/01/24 22:11, Tom Rini wrote: On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli wrote: Hello Tom, On 12/01/24 18:56, Tom Rini wrote: ... The list of conditionals in common/spl/spl.c::board_init_r() should be updated and probably use SPL_NET as the option to check for. Thank you for reviewing the patch and pointing this out. I wasn't aware of it. I assume that you are referring to the following change: if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) || - IS_ENABLED(CONFIG_SPL_ATF)) + IS_ENABLED(CONFIG_SPL_ATF) || IS_ENABLED(CONFIG_SPL_NET)) dram_init_banksize(); I shall replace the current patch with the above change in the v2 series. Since this is in the common section, is there a generic reason I could provide in the commit message rather than the existing commit message which seems to be board specific? Also, I hope that the above change will not cause regressions for other non-TI devices. Please let me know. Yes, that's the area, and just note that networking also requires the DDR to be initialized. Thank you for confirming and providing your suggestion for the contents of the commit message. Following Tom's Suggestion of adding CONFIG_SPL_NET in common/spl/spl.c "dram_init_banksize()", the issue of fetching a file at SPL stage seemed to be fixed. However the commit "ba20b2443c29", which sets gd->ram_top for the very first time in "spl_enable_cache()" results in "arch_lmb_reserve()" function reserving memory region from Stack pointer at "0x81FFB820" to gd->ram_top pointing to "0x1". Previously when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now using TFTP to fetch U-Boot image at SPL stage results in "tftp_init_load_addr()" function call that invokes "arch_lmb_reserve()" function, which reserves entire memory starting from Stack Pointer to gd->ram_top leaving no space to load U-Boot image via TFTP since TFTP loads files at pre configured memory address at "0x8200". As a workaround for this issue, one solution we can propose is to disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. For that we can define a new config option for LMB reserve checks as "SPL_LMB". This config will be enable by default for the backword compatibility and disable for our use case at SPL and U-Boot stage. The problem here is that we need LMB for booting an OS, which is something we'll want in SPL in non-cortex-R cases too, which means this platform, so that's a no-go. I think you need to dig harder and see if you can correct the logic somewhere so that we don't over reserve? Since this issue is due to function call "lmb_init_and_reserve()" function invoked from "tftp_init_load_addr()" function. This function is defined by Simon in commit "a156c47e39ad", which fixes "CVE-2018-18439" to prevent overwriting reserved memory. Simon, can you explain why do we need to call "lmb_init_and_reserve()" function here ? This is indeed a tricky area which is why Sughosh is looking in to trying to re-work the LMB mechanic and we've had a few long threads about it as well. I've honestly forgotten the use case you have here, can you please remind us? We are trying to boot AM62x using Ethernet for which we need to load binary files at SPL and U-Boot stage using TFTP. To store the file we need a free memory in RAM, specifically we are storing these files at 0x8200. But we are facing an issue while loading the file since the memory area having an address 0x8200 is reserved due to "lmb_init_and_reserve()" function call. This function is called in "tftp_init_load_addr()" function which is getting called exactly before we are trying to get the free memory area by calling "lmb_get_free_size()". I have no idea about your platform but I was wondering if there is any particular importance of the load address of 0x8200? It looks as though the current location of the SP when arch_lmb_reserve() gets called means that the load address is getting reserved for the U-Boot image. Do you not have the option of loading the image at a lower address instead? Sughosh, I think my explanation was not clear at: "We are trying to boot AM62x using Ethernet for which we need to load binary files at SPL and U-Boot stage using TFTP." - In Ethernet Booting we are fetching U-Boot image at SPL stage via TFTP at specified address 0x8200. While loading U-Boot image we are getting TFTP error, sinc
Re: [PATCH] efi_loader: use event callback for initrd deregistration
Kojima-san
Apologies but for some reason we failed to pull this patch
In meantime some parts of the bootefi.c code -- specifically theinitrd
cleanup, have been moved to efi_helper.c
Any chance you can rebase this? If not I'll try to find some time to do it
/Ilias
On Mon, Dec 04, 2023 at 01:38:17PM +0200, Ilias Apalodimas wrote:
> Thanks for cleaning this up!
>
> On Mon, 4 Dec 2023 at 06:31, Masahisa Kojima
> wrote:
> >
> > Currently efi_initrd_deregister() is called in bootefi.c
> > when the image started from bootefi command returns.
> > Since efi_guid_event_group_return_to_efibootmgr event is
> > implemented, so let's use this event for invoking
> > initrd deregistration.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > Note that this patch can be applied to u-boot/next.
> > This patch requires the patch e0d1a1ea68("efi_loader: add return to
> > efibootmgr event group")
> >
> > cmd/bootefi.c| 5 --
> > lib/efi_loader/efi_load_initrd.c | 82 +---
> > 2 files changed, 55 insertions(+), 32 deletions(-)
>
> Reviewed-by: Ilias Apalodimas
> Tested-by: Ilias Apalodimas
>
> >
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 4d74969ad6..e52bd3f743 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -390,11 +390,6 @@ static efi_status_t do_bootefi_exec(efi_handle_t
> > handle, void *load_options)
> > out:
> > free(load_options);
> >
> > - if (IS_ENABLED(CONFIG_EFI_LOAD_FILE2_INITRD)) {
> > - if (efi_initrd_deregister() != EFI_SUCCESS)
> > - log_err("Failed to remove loadfile2 for initrd\n");
> > - }
> > -
> > /* Notify EFI_EVENT_GROUP_RETURN_TO_EFIBOOTMGR event group. */
> > list_for_each_entry(evt, &efi_events, link) {
> > if (evt->group &&
> > diff --git a/lib/efi_loader/efi_load_initrd.c
> > b/lib/efi_loader/efi_load_initrd.c
> > index 193433782c..7ca7785c04 100644
> > --- a/lib/efi_loader/efi_load_initrd.c
> > +++ b/lib/efi_loader/efi_load_initrd.c
> > @@ -184,6 +184,50 @@ out:
> > return ret;
> > }
> >
> > +/**
> > + * efi_initrd_deregister() - delete the handle for loading initial RAM disk
> > + *
> > + * This will delete the handle containing the Linux specific vendor device
> > + * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
> > + *
> > + * Return: status code
> > + */
> > +efi_status_t efi_initrd_deregister(void)
> > +{
> > + efi_status_t ret;
> > +
> > + if (!efi_initrd_handle)
> > + return EFI_SUCCESS;
> > +
> > + ret = efi_uninstall_multiple_protocol_interfaces(efi_initrd_handle,
> > +/* initramfs */
> > +
> > &efi_guid_device_path,
> > +&dp_lf2_handle,
> > +/* LOAD_FILE2 */
> > +
> > &efi_guid_load_file2_protocol,
> > +&efi_lf2_protocol,
> > +NULL);
> > + efi_initrd_handle = NULL;
> > +
> > + return ret;
> > +}
> > +
> > +/**
> > + * efi_initrd_return_notify() - return to efibootmgr callback
> > + *
> > + * @event: the event for which this notification function is registered
> > + * @context: event context
> > + */
> > +static void EFIAPI efi_initrd_return_notify(struct efi_event *event,
> > + void *context)
> > +{
> > + efi_status_t ret;
> > +
> > + EFI_ENTRY("%p, %p", event, context);
> > + ret = efi_initrd_deregister();
> > + EFI_EXIT(ret);
> > +}
> > +
> > /**
> > * efi_initrd_register() - create handle for loading initial RAM disk
> > *
> > @@ -197,6 +241,7 @@ out:
> > efi_status_t efi_initrd_register(void)
> > {
> > efi_status_t ret;
> > + struct efi_event *event;
> >
> > /*
> > * Allow the user to continue if Boot file path is not set for
> > @@ -215,34 +260,17 @@ efi_status_t efi_initrd_register(void)
> >
> > &efi_guid_load_file2_protocol,
> >&efi_lf2_protocol,
> >NULL);
> > + if (ret != EFI_SUCCESS) {
> > + log_err("installing EFI_LOAD_FILE2_PROTOCOL failed\n");
> > + return ret;
> > + }
> >
> > - return ret;
> > -}
> > -
> > -/**
> > - * efi_initrd_deregister() - delete the handle for loading initial RAM disk
> > - *
> > - * This will delete the handle containing the Linux specific vendor device
> > - * path and EFI_LOAD_FILE2_PROTOCOL for loading an initrd
> > - *
> > - * Return: status code
> > - */
> > -efi_status_t efi_initrd_deregist
Re: [PATCH v2 0/7] Tegra panel improvements
Hello Tom! This patch set is hanging in patchwork for 3 month without any comments. If no one has anything to say, may you pick it into master? Best regards, Svyatoslav R. ср, 31 січ. 2024 р. о 08:57 Svyatoslav Ryhel пише: > > The current patch set improves the logic of existing panels and > bridge used by Tegra 3 devices and brings support for additional > DSI panels used by Tegra 4 devices. > > New and existing drivers are fully reusable, contain no device > specific parts, and are written according to existing datasheets. > > --- > Changes from v1: > - improved ssd2825 code style > - added TC358768 RGB to DSI bridge bringup commit (used by TF700T) > - added Parade DP501 transmitter bringup (used by Lenovo Ideapad Yoga 11) > --- > > Anton Bambura (1): > video: panel: add Samsung LTL106HL02 MIPI DSI panel driver > > Jonas Schwöbel (1): > video: bridge: add basic support for the Parade DP501 transmitter > > Svyatoslav Ryhel (5): > video: panel: add LG LG070WX3 MIPI DSI panel driver > video: bridge: add Toshiba TC358768 RGB to DSI bridge support > video: endeavoru-panel: shift the init sequence by one step earlier > video: bridge: ssd2825: shift the init sequence by one step earlier > video: renesas: shift the init sequence by one step earlier > > drivers/video/Kconfig | 17 + > drivers/video/Makefile | 2 + > drivers/video/bridge/Kconfig | 19 + > drivers/video/bridge/Makefile | 2 + > drivers/video/bridge/dp501.c | 579 + > drivers/video/bridge/ssd2825.c | 86 +-- > drivers/video/bridge/tc358768.c| 985 + > drivers/video/endeavoru-panel.c| 128 ++-- > drivers/video/lg-ld070wx3.c| 186 ++ > drivers/video/renesas-r61307.c | 93 +-- > drivers/video/renesas-r69328.c | 81 +-- > drivers/video/samsung-ltl106hl02.c | 157 + > 12 files changed, 2155 insertions(+), 180 deletions(-) > create mode 100644 drivers/video/bridge/dp501.c > create mode 100644 drivers/video/bridge/tc358768.c > create mode 100644 drivers/video/lg-ld070wx3.c > create mode 100644 drivers/video/samsung-ltl106hl02.c > > -- > 2.40.1 >
Re: [PATCH v6 00/18] Add T114 video support
Hello Tom! This patch set is hanging in patchwork for 3 month without any comments. If no one has anything to say, may you pick it into master? Best regards, Svyatoslav R. вт, 23 січ. 2024 р. о 19:17 Svyatoslav Ryhel пише: > > T114 is not that different from T30 and all T30 drivers will work > on T114 as well with some adjustments. > > Patches propose general improvements for existing Tegra DC and DSI > drivers as well Tegra 114 video support (experimentl). > > Commits pass buildman for tegra. > > --- > Changes from v5: > - backlight enable moved to the last step of setup for DSI > - parameterized V- and H-sync polarities > - added framebuffer clearing on probe to avoid glitches > - backlight enable moved after DC is fully configured > - fixed printing framebuffer pointer instead of address > - moved scdiv calculation to tegra DSI if it is used > > Changes from v4: > - fixed typo in max rate to be divided (400KHz > 400MHz) > > Changes from v3: > - fixed the clock divider calculation if PLLD/D2 is used > - removed unnecessary pre-configuration > - set correct video FIFO depth for DSI > > Changes from v2: > - fixed image distortion on devices with 180deg rotation > > Changes from v1: > - reworked patchset entirely > - diverged DC configuration per-SOC > - consolidated dc headers from different SOC gen > - initial support of DC detection (tegra has 2 DC) > - added PLLD2 support, resets and powergating > - added T114+ MIPI calibration > - added DSI detection (tegra has 2 DSI) and resets > --- > > Jonas Schwöbel (6): > video: tegra20: dc: fix printing of framebuffer address > video: tegra20: dc: enable backlight after DC is configured > video: tegra20: dc: clean framebuffer memory block > video: tegra20: dsi: remove pre-configuration > video: tegra20: dsi: set correct fifo depth > video: tegra20: dsi: use set_backlight for backlight only > > Svyatoslav Ryhel (12): > video: tegra20: dc: diverge DC per-SOC > video: tegra20: dc: fix image shift on rotated panels > video: tegra20: consolidate DC header > video: tegra20: dc: pass DC id to internal devices > video: tegra20: dc: add PLLD2 parent support > video: tegra20: dc: add reset support > video: tegra20: dc: add powergate > video: tegra20: dc: configure behavior if PLLD/D2 is used > video: tegra20: dc: parameterize V- and H-sync polarities > video: tegra20: add MIPI calibration driver > video: tegra20: dsi: add T114 support > video: tegra20: dsi: add reset support > > arch/arm/dts/tegra114-u-boot.dtsi | 13 + > arch/arm/dts/tegra114.dtsi| 4 +- > arch/arm/dts/tegra30-u-boot.dtsi | 4 + > arch/arm/dts/tegra30.dtsi | 2 +- > arch/arm/include/asm/arch-tegra/dc.h | 13 +- > arch/arm/include/asm/arch-tegra114/pwm.h | 13 + > arch/arm/include/asm/arch-tegra20/display.h | 28 -- > arch/arm/include/asm/arch-tegra30/display.h | 28 -- > drivers/video/tegra20/Makefile| 2 +- > drivers/video/tegra20/tegra-dc.c | 239 +- > drivers/video/tegra20/tegra-dc.h | 45 > drivers/video/tegra20/tegra-dsi.c | 122 - > .../video/tegra20/tegra-dsi.h | 24 +- > drivers/video/tegra20/tegra-mipi.c| 188 ++ > drivers/video/tegra20/tegra-pwm-backlight.c | 3 +- > 15 files changed, 583 insertions(+), 145 deletions(-) > create mode 100644 arch/arm/include/asm/arch-tegra114/pwm.h > delete mode 100644 arch/arm/include/asm/arch-tegra20/display.h > delete mode 100644 arch/arm/include/asm/arch-tegra30/display.h > create mode 100644 drivers/video/tegra20/tegra-dc.h > rename arch/arm/include/asm/arch-tegra30/dsi.h => > drivers/video/tegra20/tegra-dsi.h (90%) > create mode 100644 drivers/video/tegra20/tegra-mipi.c > > -- > 2.40.1 >
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On Fri, 19 Apr 2024 at 16:04, Chintan Vankar wrote: > > > > On 18/04/24 17:30, Sughosh Ganu wrote: > > On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote: > >> > >> > >> > >> On 17/04/24 21:34, Tom Rini wrote: > >>> On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote: > hi Chintan, > > On Wed, 17 Apr 2024 at 13:21, Chintan Vankar wrote: > > > > > > > > On 16/04/24 22:30, Tom Rini wrote: > >> On Tue, Apr 16, 2024 at 05:52:58PM +0530, Chintan Vankar wrote: > >>> > >>> > >>> On 12/04/24 03:37, Tom Rini wrote: > On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote: > > > > > > On 22/01/24 10:11, Siddharth Vadapalli wrote: > >> > >> > >> On 20/01/24 22:11, Tom Rini wrote: > >>> On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli > >>> wrote: > Hello Tom, > > On 12/01/24 18:56, Tom Rini wrote: > >> > >> ... > >> > > The list of conditionals in common/spl/spl.c::board_init_r() > > should be > > updated and probably use SPL_NET as the option to check for. > > Thank you for reviewing the patch and pointing this out. I > wasn't aware of it. I > assume that you are referring to the following change: > > if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || > CONFIG_IS_ENABLED(HANDOFF) || > - IS_ENABLED(CONFIG_SPL_ATF)) > + IS_ENABLED(CONFIG_SPL_ATF) || > IS_ENABLED(CONFIG_SPL_NET)) > dram_init_banksize(); > > I shall replace the current patch with the above change in the > v2 series. Since > this is in the common section, is there a generic reason I could > provide in the > commit message rather than the existing commit message which > seems to be board > specific? Also, I hope that the above change will not cause > regressions for > other non-TI devices. Please let me know. > >>> > >>> Yes, that's the area, and just note that networking also requires > >>> the > >>> DDR to be initialized. > >>> > >> > >> Thank you for confirming and providing your suggestion for the > >> contents of the > >> commit message. > >> > > Following Tom's Suggestion of adding CONFIG_SPL_NET in > > common/spl/spl.c > > "dram_init_banksize()", the issue of fetching a file at SPL stage > > seemed > > to be fixed. However the commit "ba20b2443c29", which sets > > gd->ram_top > > for the very first time in "spl_enable_cache()" results in > > "arch_lmb_reserve()" function reserving memory region from Stack > > pointer > > at "0x81FFB820" to gd->ram_top pointing to "0x1". Previously > > when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now using > > TFTP > > to fetch U-Boot image at SPL stage results in > > "tftp_init_load_addr()" > > function call that invokes "arch_lmb_reserve()" function, which > > reserves > > entire memory starting from Stack Pointer to gd->ram_top leaving no > > space to load U-Boot image via TFTP since TFTP loads files at pre > > configured memory address at "0x8200". > > > > As a workaround for this issue, one solution we can propose is to > > disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. > > For > > that we can define a new config option for LMB reserve checks as > > "SPL_LMB". This config will be enable by default for the backword > > compatibility and disable for our use case at SPL and U-Boot stage. > > The problem here is that we need LMB for booting an OS, which is > something we'll want in SPL in non-cortex-R cases too, which means > this > platform, so that's a no-go. I think you need to dig harder and see > if > you can correct the logic somewhere so that we don't over reserve? > > >>> Since this issue is due to function call "lmb_init_and_reserve()" > >>> function invoked from "tftp_init_load_addr()" function. This function > >>> is defined by Simon in commit "a156c47e39ad", which fixes > >>> "CVE-2018-18439" to prevent overwriting reserved memory. Simon, can > >>> you > >>> explain why do we need to call "lmb_init_and_reserve()" function here > >>> ? > >> > >> This is indeed a tricky area which is why Sughosh is looking in to > >> trying to re-work the LMB mechanic and we've had a few long threads > >>
[PATCH 2/2] tools: type arguemnts
%s/arguemnts/arguemnts/ Signed-off-by: Heinrich Schuchardt --- tools/buildman/test.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/buildman/test.py b/tools/buildman/test.py index bdd3d84158a..f92add7a7c5 100644 --- a/tools/buildman/test.py +++ b/tools/buildman/test.py @@ -195,7 +195,7 @@ class TestBuild(unittest.TestCase): Args: echo_lines: True to echo lines to the terminal to aid test development -kwdisplay_args: Dict of arguemnts to pass to +kwdisplay_args: Dict of arguments to pass to Builder.SetDisplayOptions() Returns: -- 2.43.0
[PATCH 1/2] event: typo arguemnts
%s/arguemnts/arguments/ Signed-off-by: Heinrich Schuchardt --- include/event.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/event.h b/include/event.h index a8f046da3c3..fb353ad623e 100644 --- a/include/event.h +++ b/include/event.h @@ -316,7 +316,7 @@ static inline const char *event_spy_id(struct evspy_info *spy) __used ll_entry_declare(struct evspy_info, _type ## _3_ ## _func, \ evspy_info) = _ESPY_REC(_type, _func) -/* Simple spy with no function arguemnts */ +/* Simple spy with no function arguments */ #define EVENT_SPY_SIMPLE(_type, _func) \ __used ll_entry_declare(struct evspy_info_simple, \ _type ## _3_ ## _func, \ -- 2.43.0
Re: [PATCH 1/2] i2c: Add support for Qualcomm Generic Interface (GENI) I2C controller
Hi Neil,
On 18/04/2024 23:47, Neil Armstrong wrote:
> Add Support for the Qualcomm Generic Interface (GENI) I2C interface
> found on newer Qualcomm SoCs.
\o/
>
> The Generic Interface (GENI) is a firmware based Qualcomm Universal
> Peripherals (QUP) Serial Engine (SE) Wrapper which can support multiple
> bus protocols depending on the firmware type loaded at early boot time
> based on system configuration.
>
> It also supports the "I2C Master Hub" which is a single function Wrapper
> that only FIFO mode I2C.
>
> It replaces the fixed-function QUP Wrapper found on older SoCs.
>
> The geni-se.h containing the generic GENI Serial Engine registers defines
> is imported from Linux.
>
> Only FIFO mode is implemented, nor SE DMA nor GPI DMA is implemented.
nit: "neither SE DMA nor GPI DMA are implemented"
A few minor things below, but otherwise LGTM!
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/i2c/Kconfig| 10 +
> drivers/i2c/Makefile | 1 +
> drivers/i2c/geni_i2c.c | 576
> +
> include/soc/qcom/geni-se.h | 265 +
> 4 files changed, 852 insertions(+)
>
[...]
> diff --git a/drivers/i2c/geni_i2c.c b/drivers/i2c/geni_i2c.c
> new file mode 100644
> index 000..8c3ed3bef89
> --- /dev/null
> +++ b/drivers/i2c/geni_i2c.c
> @@ -0,0 +1,576 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2024, Linaro Limited
> + * Author: Neil Armstrong
> + *
> + * Based on Linux driver: drivers/i2c/busses/i2c-qcom-geni.c
> + */
> +
[...]
> +static int geni_i2c_fifo_tx_fill(struct geni_i2c_priv *geni, struct i2c_msg
> *msg)
> +{
> + ulong start = get_timer(0);
> + ulong cur_xfer = 0;
> + int i;
> +
> + while (get_timer(start) < I2C_TIMEOUT_MS) {
> + u32 status = readl(geni->base + SE_GENI_M_IRQ_STATUS);
> +
> + if (status & (M_CMD_ABORT_EN |
> + M_CMD_OVERRUN_EN |
> + M_ILLEGAL_CMD_EN |
> + M_CMD_FAILURE_EN |
> + M_GP_IRQ_1_EN |
> + M_GP_IRQ_3_EN |
> + M_GP_IRQ_4_EN)) {
> + debug("%s:%d cmd err\n", __func__, __LINE__);
How likely are we to hit this? Would it make sense to promote it to a
pr_warn()?
Please drop the __LINE__ and (if it makes sense to?) print the value of
status.
> + writel(status, geni->base + SE_GENI_M_IRQ_CLEAR);
> + writel(0, geni->base + SE_GENI_TX_WATERMARK_REG);
> + return -EREMOTEIO;
> + }
> +
> + if ((status & M_TX_FIFO_WATERMARK_EN) == 0) {
> + udelay(1);
> + goto skip_fill;
> + }
> +
> + for (i = 0; i < geni->tx_wm; i++) {
> + u32 temp, tx = 0;
> + unsigned int p = 0;
> +
> + while (cur_xfer < msg->len && p < sizeof(tx)) {
> + temp = msg->buf[cur_xfer++];
> + tx |= temp << (p * 8);
> + p++;
> + }
> +
> + writel(tx, geni->base + SE_GENI_TX_FIFOn);
> +
> + if (cur_xfer == msg->len) {
> + writel(0, geni->base +
> SE_GENI_TX_WATERMARK_REG);
> + break;
> + }
> + }
> +
> +skip_fill:
> + writel(status, geni->base + SE_GENI_M_IRQ_CLEAR);
> +
> + if (status & M_CMD_DONE_EN)
> + return 0;
> + }
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int geni_i2c_fifo_rx_drain(struct geni_i2c_priv *geni, struct i2c_msg
> *msg)
> +{
> + ulong start = get_timer(0);
> + ulong cur_xfer = 0;
> + int i;
> +
> + while (get_timer(start) < I2C_TIMEOUT_MS) {
> + u32 status = readl(geni->base + SE_GENI_M_IRQ_STATUS);
> + u32 rxstatus = readl(geni->base + SE_GENI_RX_FIFO_STATUS);
> + u32 rxcnt = rxstatus & RX_FIFO_WC_MSK;
> +
> + if (status & (M_CMD_ABORT_EN |
> + M_CMD_FAILURE_EN |
> + M_CMD_OVERRUN_EN |
> + M_ILLEGAL_CMD_EN |
> + M_GP_IRQ_1_EN |
> + M_GP_IRQ_3_EN |
> + M_GP_IRQ_4_EN)) {
> + debug("%s:%d cmd err\n", __func__, __LINE__);
Ditto
> + writel(status, geni->base + SE_GENI_M_IRQ_CLEAR);
> + return -EIO;
> + }
> +
> + if ((status & (M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN)) ==
> 0) {
> + udelay(1);
> + goto skip_drain;
> + }
> +
> + for (i = 0; cur_xfer < msg->len && i <
Re: [PATCH 2/2] configs: qcom_defconfig: enable GENI I2C Driver
Hi Neil, On 18/04/2024 23:47, Neil Armstrong wrote: > Enable the GENI I2C driver in the default Qualcomm defconfig. > > Signed-off-by: Neil Armstrong Reviewed-by: Caleb Connolly > --- > configs/qcom_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig > index 1abb57345ff..8d440b23625 100644 > --- a/configs/qcom_defconfig > +++ b/configs/qcom_defconfig > @@ -41,6 +41,7 @@ CONFIG_MSM_GPIO=y > CONFIG_QCOM_PMIC_GPIO=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_QUP=y > +CONFIG_SYS_I2C_GENI=y > CONFIG_I2C_MUX=y > CONFIG_DM_KEYBOARD=y > CONFIG_BUTTON_KEYBOARD=y > -- // Caleb (they/them)
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On 19/04/24 17:04, Sughosh Ganu wrote: On Fri, 19 Apr 2024 at 16:04, Chintan Vankar wrote: On 18/04/24 17:30, Sughosh Ganu wrote: On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote: On 17/04/24 21:34, Tom Rini wrote: On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote: hi Chintan, On Wed, 17 Apr 2024 at 13:21, Chintan Vankar wrote: On 16/04/24 22:30, Tom Rini wrote: On Tue, Apr 16, 2024 at 05:52:58PM +0530, Chintan Vankar wrote: On 12/04/24 03:37, Tom Rini wrote: On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote: On 22/01/24 10:11, Siddharth Vadapalli wrote: On 20/01/24 22:11, Tom Rini wrote: On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli wrote: Hello Tom, On 12/01/24 18:56, Tom Rini wrote: ... The list of conditionals in common/spl/spl.c::board_init_r() should be updated and probably use SPL_NET as the option to check for. Thank you for reviewing the patch and pointing this out. I wasn't aware of it. I assume that you are referring to the following change: if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || CONFIG_IS_ENABLED(HANDOFF) || - IS_ENABLED(CONFIG_SPL_ATF)) + IS_ENABLED(CONFIG_SPL_ATF) || IS_ENABLED(CONFIG_SPL_NET)) dram_init_banksize(); I shall replace the current patch with the above change in the v2 series. Since this is in the common section, is there a generic reason I could provide in the commit message rather than the existing commit message which seems to be board specific? Also, I hope that the above change will not cause regressions for other non-TI devices. Please let me know. Yes, that's the area, and just note that networking also requires the DDR to be initialized. Thank you for confirming and providing your suggestion for the contents of the commit message. Following Tom's Suggestion of adding CONFIG_SPL_NET in common/spl/spl.c "dram_init_banksize()", the issue of fetching a file at SPL stage seemed to be fixed. However the commit "ba20b2443c29", which sets gd->ram_top for the very first time in "spl_enable_cache()" results in "arch_lmb_reserve()" function reserving memory region from Stack pointer at "0x81FFB820" to gd->ram_top pointing to "0x1". Previously when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now using TFTP to fetch U-Boot image at SPL stage results in "tftp_init_load_addr()" function call that invokes "arch_lmb_reserve()" function, which reserves entire memory starting from Stack Pointer to gd->ram_top leaving no space to load U-Boot image via TFTP since TFTP loads files at pre configured memory address at "0x8200". As a workaround for this issue, one solution we can propose is to disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. For that we can define a new config option for LMB reserve checks as "SPL_LMB". This config will be enable by default for the backword compatibility and disable for our use case at SPL and U-Boot stage. The problem here is that we need LMB for booting an OS, which is something we'll want in SPL in non-cortex-R cases too, which means this platform, so that's a no-go. I think you need to dig harder and see if you can correct the logic somewhere so that we don't over reserve? Since this issue is due to function call "lmb_init_and_reserve()" function invoked from "tftp_init_load_addr()" function. This function is defined by Simon in commit "a156c47e39ad", which fixes "CVE-2018-18439" to prevent overwriting reserved memory. Simon, can you explain why do we need to call "lmb_init_and_reserve()" function here ? This is indeed a tricky area which is why Sughosh is looking in to trying to re-work the LMB mechanic and we've had a few long threads about it as well. I've honestly forgotten the use case you have here, can you please remind us? We are trying to boot AM62x using Ethernet for which we need to load binary files at SPL and U-Boot stage using TFTP. To store the file we need a free memory in RAM, specifically we are storing these files at 0x8200. But we are facing an issue while loading the file since the memory area having an address 0x8200 is reserved due to "lmb_init_and_reserve()" function call. This function is called in "tftp_init_load_addr()" function which is getting called exactly before we are trying to get the free memory area by calling "lmb_get_free_size()". I have no idea about your platform but I was wondering if there is any particular importance of the load address of 0x8200? It looks as though the current location of the SP when arch_lmb_reserve() gets called means that the load address is getting reserved for the U-Boot image. Do you not have the option of loading the image at a lower address instead? Sughosh, I think my explanation was not clear at: "We are trying to boot AM62x using Ethernet for which we need to load binary files at SPL and U-Boot stage using TFTP." - In Ethernet Booting we are fetching U-Boot image at SPL stage
Re: [PATCH 01/10] board: ti: am62x: Init DRAM size in R5/A53 SPL
On Fri, 19 Apr 2024 at 17:23, Chintan Vankar wrote: > > > > On 19/04/24 17:04, Sughosh Ganu wrote: > > On Fri, 19 Apr 2024 at 16:04, Chintan Vankar wrote: > >> > >> > >> > >> On 18/04/24 17:30, Sughosh Ganu wrote: > >>> On Thu, 18 Apr 2024 at 16:08, Chintan Vankar wrote: > > > > On 17/04/24 21:34, Tom Rini wrote: > > On Wed, Apr 17, 2024 at 05:48:31PM +0530, Sughosh Ganu wrote: > >> hi Chintan, > >> > >> On Wed, 17 Apr 2024 at 13:21, Chintan Vankar wrote: > >>> > >>> > >>> > >>> On 16/04/24 22:30, Tom Rini wrote: > On Tue, Apr 16, 2024 at 05:52:58PM +0530, Chintan Vankar wrote: > > > > > > On 12/04/24 03:37, Tom Rini wrote: > >> On Wed, Apr 03, 2024 at 06:18:01PM +0530, Chintan Vankar wrote: > >>> > >>> > >>> On 22/01/24 10:11, Siddharth Vadapalli wrote: > > > On 20/01/24 22:11, Tom Rini wrote: > > On Mon, Jan 15, 2024 at 01:42:51PM +0530, Siddharth Vadapalli > > wrote: > >> Hello Tom, > >> > >> On 12/01/24 18:56, Tom Rini wrote: > > ... > > >>> The list of conditionals in common/spl/spl.c::board_init_r() > >>> should be > >>> updated and probably use SPL_NET as the option to check for. > >> > >> Thank you for reviewing the patch and pointing this out. I > >> wasn't aware of it. I > >> assume that you are referring to the following change: > >> > >> if (IS_ENABLED(CONFIG_SPL_OS_BOOT) || > >> CONFIG_IS_ENABLED(HANDOFF) || > >> - IS_ENABLED(CONFIG_SPL_ATF)) > >> + IS_ENABLED(CONFIG_SPL_ATF) || > >> IS_ENABLED(CONFIG_SPL_NET)) > >> dram_init_banksize(); > >> > >> I shall replace the current patch with the above change in the > >> v2 series. Since > >> this is in the common section, is there a generic reason I > >> could provide in the > >> commit message rather than the existing commit message which > >> seems to be board > >> specific? Also, I hope that the above change will not cause > >> regressions for > >> other non-TI devices. Please let me know. > > > > Yes, that's the area, and just note that networking also > > requires the > > DDR to be initialized. > > > > Thank you for confirming and providing your suggestion for the > contents of the > commit message. > > >>> Following Tom's Suggestion of adding CONFIG_SPL_NET in > >>> common/spl/spl.c > >>> "dram_init_banksize()", the issue of fetching a file at SPL stage > >>> seemed > >>> to be fixed. However the commit "ba20b2443c29", which sets > >>> gd->ram_top > >>> for the very first time in "spl_enable_cache()" results in > >>> "arch_lmb_reserve()" function reserving memory region from Stack > >>> pointer > >>> at "0x81FFB820" to gd->ram_top pointing to "0x1". > >>> Previously > >>> when gd->ram_top was zero "arch_lmb_reserve()" was noop. Now > >>> using TFTP > >>> to fetch U-Boot image at SPL stage results in > >>> "tftp_init_load_addr()" > >>> function call that invokes "arch_lmb_reserve()" function, which > >>> reserves > >>> entire memory starting from Stack Pointer to gd->ram_top leaving > >>> no > >>> space to load U-Boot image via TFTP since TFTP loads files at pre > >>> configured memory address at "0x8200". > >>> > >>> As a workaround for this issue, one solution we can propose is to > >>> disable the checks "lmb_get_free_size()" at SPL and U-Boot stage. > >>> For > >>> that we can define a new config option for LMB reserve checks as > >>> "SPL_LMB". This config will be enable by default for the backword > >>> compatibility and disable for our use case at SPL and U-Boot > >>> stage. > >> > >> The problem here is that we need LMB for booting an OS, which is > >> something we'll want in SPL in non-cortex-R cases too, which means > >> this > >> platform, so that's a no-go. I think you need to dig harder and > >> see if > >> you can correct the logic somewhere so that we don't over reserve? > >> > > Since this issue is due to function call "lmb_init_and_reserve()" > > function invoked from "tftp_init_load_addr()" function. This > > function > > is defined by Simon in commit "a1
[PULL] Pull request for u-boot master / v2024.07 = u-boot-stm32-20240419
Hi Tom Please pull the STM32 related patches for u-boot/master, v2024.07: u-boot-stm32-20240419 CI status: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/20430 The following changes since commit 97b34f6ace539c9c16eb8565f8b58730848ba97a: env: mmc: print MMC device being read (2024-04-18 16:37:25 -0600) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20240419 for you to fetch changes up to b0283b5e3d37daff48b45c3f98d298844603def4: ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot (2024-04-19 12:05:10 +0200) 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 Christophe Kerello (3): memory: stm32-fmc2-ebi: add MP25 support memory: stm32-fmc2-ebi: add MP25 RIF support mtd: rawnand: stm32_fmc2: add MP25 support Christophe Roullier (2): net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform net: dwc_eth_qos: Add support of STM32MP13xx platform Marek Vasut (14): arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM net: dwc_eth_qos: Split STM32 glue into separate file net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code net: dwc_eth_qos: Scrub ifdeffery net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield net: dwc_eth_qos: Move log_debug statements on top of case block net: dwc_eth_qos: Use consistent logging prints net: dwc_eth_qos: Constify st, eth-* values parsed out of DT net: dwc_eth_qos: Add support for st, ext-phyclk property ARM: stm32: Jump to ep on successful resume in PSCI suspend code ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx Patrice Chotard (29): ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-boot ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings configs: stm32mp13: Enable FASTBOOT configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check() ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot ARM: dts: stm32: Update u-boot, boot-led for stm32mp157a-dk1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot Patrick Delaunay (2): stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 19 +- arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 32 ++--- arch/arm/dts/stm32mp157c-ed1-scmi-u-b
Re: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate file
On 4/8/24 09:24, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate
>> file
>>
>> Move STM32 glue code into separate file to contain the STM32 specific code
>> outside of the DWMAC core code. No functional change.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/Makefile | 1 +
>> drivers/net/dwc_eth_qos.c | 165 ---
>> drivers/net/dwc_eth_qos.h | 1 +
>> drivers/net/dwc_eth_qos_stm32.c | 196
>> 4 files changed, 198 insertions(+), 165 deletions(-) create mode 100644
>> drivers/net/dwc_eth_qos_stm32.c
>>
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile index
>> 6677366ebd6..dc3404519d6 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
>> obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
>> obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
>> obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
>> +obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
>> obj-$(CONFIG_E1000) += e1000.o
>> obj-$(CONFIG_E1000_SPI) += e1000_spi.o
>> obj-$(CONFIG_EEPRO100) += eepro100.o
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 9b3bce1dc87..533c2bf070b 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -295,58 +295,6 @@ err:
>> #endif
>> }
>>
>> -static int eqos_start_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> - int ret;
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - ret = clk_enable(&eqos->clk_master_bus);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_master_bus) failed: %d", ret);
>> - goto err;
>> - }
>> -
>> - ret = clk_enable(&eqos->clk_rx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_rx) failed: %d", ret);
>> - goto err_disable_clk_master_bus;
>> - }
>> -
>> - ret = clk_enable(&eqos->clk_tx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_tx) failed: %d", ret);
>> - goto err_disable_clk_rx;
>> - }
>> -
>> - if (clk_valid(&eqos->clk_ck) && !eqos->clk_ck_enabled) {
>> - ret = clk_enable(&eqos->clk_ck);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_ck) failed: %d", ret);
>> - goto err_disable_clk_tx;
>> - }
>> - eqos->clk_ck_enabled = true;
>> - }
>> -#endif
>> -
>> - debug("%s: OK\n", __func__);
>> - return 0;
>> -
>> -#ifdef CONFIG_CLK
>> -err_disable_clk_tx:
>> - clk_disable(&eqos->clk_tx);
>> -err_disable_clk_rx:
>> - clk_disable(&eqos->clk_rx);
>> -err_disable_clk_master_bus:
>> - clk_disable(&eqos->clk_master_bus);
>> -err:
>> - debug("%s: FAILED: %d\n", __func__, ret);
>> - return ret;
>> -#endif
>> -}
>> -
>> static int eqos_stop_clks_tegra186(struct udevice *dev) { #ifdef
>> CONFIG_CLK @@ -365,22 +313,6 @@ static int eqos_stop_clks_tegra186(struct
>> udevice *dev)
>> return 0;
>> }
>>
>> -static int eqos_stop_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - clk_disable(&eqos->clk_tx);
>> - clk_disable(&eqos->clk_rx);
>> - clk_disable(&eqos->clk_master_bus);
>> -#endif
>> -
>> - debug("%s: OK\n", __func__);
>> - return 0;
>> -}
>> -
>> static int eqos_start_resets_tegra186(struct udevice *dev) {
>> struct eqos_priv *eqos = dev_get_priv(dev); @@ -493,17 +425,6 @@
>> static ulong eqos_get_tick_clk_rate_tegra186(struct udevice *dev) #endif }
>>
>> -static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev) -{ -#ifdef
>> CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> -
>> - return clk_get_rate(&eqos->clk_master_bus);
>> -#else
>> - return 0;
>> -#endif
>> -}
>> -
>> static int eqos_set_full_duplex(struct udevice *dev) {
>> struct eqos_priv *eqos = dev_get_priv(dev); @@ -1415,57 +1336,6 @@
>> err_free_reset_eqos:
>> return ret;
>> }
>>
>> -static int
Re: [Uboot-stm32] [PATCH v3] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
On 4/19/24 11:36, Patrice CHOTARD wrote: > > > On 4/19/24 05:59, Marek Vasut wrote: >> 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 >> Signed-off-by: Marek Vasut >> --- >> Cc: Igor Opaniuk >> Cc: Patrice Chotard >> Cc: Patrick Delaunay >> Cc: Simon Glass > Cc: Simon Glass >> Cc: Tom Rini >> Cc: u-b...@dh-electronics.com >> Cc: uboot-st...@st-md-mailman.stormreply.com >> --- >> V2: Fix up the BKPRWD/BKPWD mask typo >> V3: - Update the allocation to 0x20/0x20 >> - Update commit message >> - Add RB from Patrick >> --- >> arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 >> 1 file changed, 16 insertions(+) >> >> diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> index dd99150fbc2..d75ec99d6a1 100644 >> --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c >> @@ -14,6 +14,7 @@ >> #include >> #include >> #include >> +#include >> >> /* RCC register */ >> #define RCC_TZCR(STM32_RCC_BASE + 0x00) >> @@ -41,6 +42,9 @@ >> #define TZC_REGION_ID_ACCESS0 (STM32_TZC_BASE + 0x114) >> >> #define TAMP_CR1(STM32_TAMP_BASE + 0x00) >> +#define TAMP_SMCR (STM32_TAMP_BASE + 0x20) >> +#define TAMP_SMCR_BKPRWDPROTGENMASK(7, 0) >> +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16) >> >> #define PWR_CR1 (STM32_PWR_BASE + 0x00) >> #define PWR_MCUCR (STM32_PWR_BASE + 0x14) >> @@ -136,6 +140,18 @@ static void security_init(void) >> */ >> writel(0x0, TAMP_CR1); >> >> +/* >> + * TAMP: Configure non-zero secure protection settings. This is >> + * checked by BootROM function 35ac on OTP-CLOSED device during >> + * CPU core 1 release from endless loop. If secure protection >> + * fields are zero, the core 1 is not released from endless >> + * loop on second SGI0. >> + */ >> +clrsetbits_le32(TAMP_SMCR, >> +TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPWDPROT, >> +FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x20) | >> +FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x20)); >> + >> /* GPIOZ: deactivate the security */ >> writel(BIT(0), RCC_MP_AHB5ENSETR); >> writel(0x0, GPIOZ_SECCFGR); > Hi Marek > > Reviewed-by: Patrice Chotard Applied on u-boot-stm32/master > > Thanks > Patrice > ___ > Uboot-stm32 mailing list > uboot-st...@st-md-mailman.stormreply.com > https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32
Re: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate file
On 4/8/24 09:24, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 01/11] net: dwc_eth_qos: Split STM32 glue into separate
>> file
>>
>> Move STM32 glue code into separate file to contain the STM32 specific code
>> outside of the DWMAC core code. No functional change.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/Makefile | 1 +
>> drivers/net/dwc_eth_qos.c | 165 ---
>> drivers/net/dwc_eth_qos.h | 1 +
>> drivers/net/dwc_eth_qos_stm32.c | 196
>> 4 files changed, 198 insertions(+), 165 deletions(-) create mode 100644
>> drivers/net/dwc_eth_qos_stm32.c
>>
>> diff --git a/drivers/net/Makefile b/drivers/net/Makefile index
>> 6677366ebd6..dc3404519d6 100644
>> --- a/drivers/net/Makefile
>> +++ b/drivers/net/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_DWC_ETH_QOS_IMX) += dwc_eth_qos_imx.o
>> obj-$(CONFIG_DWC_ETH_QOS_ROCKCHIP) += dwc_eth_qos_rockchip.o
>> obj-$(CONFIG_DWC_ETH_QOS_QCOM) += dwc_eth_qos_qcom.o
>> obj-$(CONFIG_DWC_ETH_QOS_STARFIVE) += dwc_eth_qos_starfive.o
>> +obj-$(CONFIG_DWC_ETH_QOS_STM32) += dwc_eth_qos_stm32.o
>> obj-$(CONFIG_E1000) += e1000.o
>> obj-$(CONFIG_E1000_SPI) += e1000_spi.o
>> obj-$(CONFIG_EEPRO100) += eepro100.o
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 9b3bce1dc87..533c2bf070b 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -295,58 +295,6 @@ err:
>> #endif
>> }
>>
>> -static int eqos_start_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> - int ret;
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - ret = clk_enable(&eqos->clk_master_bus);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_master_bus) failed: %d", ret);
>> - goto err;
>> - }
>> -
>> - ret = clk_enable(&eqos->clk_rx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_rx) failed: %d", ret);
>> - goto err_disable_clk_master_bus;
>> - }
>> -
>> - ret = clk_enable(&eqos->clk_tx);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_tx) failed: %d", ret);
>> - goto err_disable_clk_rx;
>> - }
>> -
>> - if (clk_valid(&eqos->clk_ck) && !eqos->clk_ck_enabled) {
>> - ret = clk_enable(&eqos->clk_ck);
>> - if (ret < 0) {
>> - pr_err("clk_enable(clk_ck) failed: %d", ret);
>> - goto err_disable_clk_tx;
>> - }
>> - eqos->clk_ck_enabled = true;
>> - }
>> -#endif
>> -
>> - debug("%s: OK\n", __func__);
>> - return 0;
>> -
>> -#ifdef CONFIG_CLK
>> -err_disable_clk_tx:
>> - clk_disable(&eqos->clk_tx);
>> -err_disable_clk_rx:
>> - clk_disable(&eqos->clk_rx);
>> -err_disable_clk_master_bus:
>> - clk_disable(&eqos->clk_master_bus);
>> -err:
>> - debug("%s: FAILED: %d\n", __func__, ret);
>> - return ret;
>> -#endif
>> -}
>> -
>> static int eqos_stop_clks_tegra186(struct udevice *dev) { #ifdef
>> CONFIG_CLK @@ -365,22 +313,6 @@ static int eqos_stop_clks_tegra186(struct
>> udevice *dev)
>> return 0;
>> }
>>
>> -static int eqos_stop_clks_stm32(struct udevice *dev) -{ -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> -
>> - debug("%s(dev=%p):\n", __func__, dev);
>> -
>> - clk_disable(&eqos->clk_tx);
>> - clk_disable(&eqos->clk_rx);
>> - clk_disable(&eqos->clk_master_bus);
>> -#endif
>> -
>> - debug("%s: OK\n", __func__);
>> - return 0;
>> -}
>> -
>> static int eqos_start_resets_tegra186(struct udevice *dev) {
>> struct eqos_priv *eqos = dev_get_priv(dev); @@ -493,17 +425,6 @@
>> static ulong eqos_get_tick_clk_rate_tegra186(struct udevice *dev) #endif }
>>
>> -static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev) -{ -#ifdef
>> CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> -
>> - return clk_get_rate(&eqos->clk_master_bus);
>> -#else
>> - return 0;
>> -#endif
>> -}
>> -
>> static int eqos_set_full_duplex(struct udevice *dev) {
>> struct eqos_priv *eqos = dev_get_priv(dev); @@ -1415,57 +1336,6 @@
>> err_free_reset_eqos:
>> return ret;
>> }
>>
>> -static int
Re: [PATCH v2 02/11] net: dwc_eth_qos: Rename eqos_stm32_config to eqos_stm32mp15_config
On 4/8/24 09:26, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To:u-boot@lists.denx.de
>> Cc: Marek Vasut; Patrice CHOTARD -
>> foss; Christophe
>> ROULLIER; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 02/11] 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.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/dwc_eth_qos.c | 2 +-
>> drivers/net/dwc_eth_qos.h | 2 +-
>> drivers/net/dwc_eth_qos_stm32.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 533c2bf070b..203bfc0848c 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -1507,7 +1507,7 @@ static const struct udevice_id eqos_ids[] = { #if
>> IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
>> {
>> .compatible = "st,stm32mp1-dwmac",
>> - .data = (ulong)&eqos_stm32_config
>> + .data = (ulong)&eqos_stm32mp15_config
>> },
>> #endif
>> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_IMX)
>> diff --git a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h index
>> a6087f191ab..bafd0d339fb 100644
>> --- a/drivers/net/dwc_eth_qos.h
>> +++ b/drivers/net/dwc_eth_qos.h
>> @@ -290,5 +290,5 @@ int eqos_null_ops(struct udevice *dev); extern struct
>> eqos_config eqos_imx_config; extern struct eqos_config
>> eqos_rockchip_config; extern struct eqos_config eqos_qcom_config; -extern
>> struct eqos_config eqos_stm32_config;
>> +extern struct eqos_config eqos_stm32mp15_config;
>> extern struct eqos_config eqos_jh7110_config; diff --git
>> a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c index
>> cfda757133e..fd29a604987 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -184,7 +184,7 @@ static struct eqos_ops eqos_stm32_ops = {
>> .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32 };
>>
>> -struct eqos_config __maybe_unused eqos_stm32_config = {
>> +struct eqos_config __maybe_unused eqos_stm32mp15_config = {
>> .reg_access_always_ok = false,
>> .mdio_wait = 1,
>> .swr_wait = 50,
>> --
>> 2.43.0
>>
> Reviewed-by: Christophe ROULLIER
Applied on u-boot-stm32/master
Re: [PATCH v2 03/11] net: dwc_eth_qos: Fold board_interface_eth_init into STM32 glue code
On 3/26/24 13:07, Marek Vasut wrote:
> 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
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> board/dhelectronics/dh_stm32mp1/board.c | 82 ---
> board/st/stm32mp1/stm32mp1.c| 82 ---
> drivers/net/dwc_eth_qos_stm32.c | 86 -
> 3 files changed, 84 insertions(+), 166 deletions(-)
>
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c
> b/board/dhelectronics/dh_stm32mp1/board.c
> index d1f662d9701..f179c857116 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -48,12 +48,10 @@
>
> /* SYSCFG registers */
> #define SYSCFG_BOOTR 0x00
> -#define SYSCFG_PMCSETR 0x04
> #define SYSCFG_IOCTRLSETR0x18
> #define SYSCFG_ICNR 0x1C
> #define SYSCFG_CMPCR 0x20
> #define SYSCFG_CMPENSETR 0x24
> -#define SYSCFG_PMCCLRR 0x44
>
> #define SYSCFG_BOOTR_BOOT_MASK GENMASK(2, 0)
> #define SYSCFG_BOOTR_BOOTPD_SHIFT4
> @@ -69,16 +67,6 @@
>
> #define SYSCFG_CMPENSETR_MPU_EN BIT(0)
>
> -#define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
> -#define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
> -
> -#define SYSCFG_PMCSETR_ETH_SELMIIBIT(20)
> -
> -#define SYSCFG_PMCSETR_ETH_SEL_MASK GENMASK(23, 21)
> -#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII 0
> -#define SYSCFG_PMCSETR_ETH_SEL_RGMII BIT(21)
> -#define SYSCFG_PMCSETR_ETH_SEL_RMII BIT(23)
> -
> #define KS_CCR 0x08
> #define KS_CCR_EEPROMBIT(9)
> #define KS_BE0 BIT(12)
> @@ -679,76 +667,6 @@ void board_quiesce_devices(void)
> #endif
> }
>
> -/* eth init function : weak called in eqos driver */
> -int board_interface_eth_init(struct udevice *dev,
> - phy_interface_t interface_type)
> -{
> - u8 *syscfg;
> - u32 value;
> - bool eth_clk_sel_reg = false;
> - bool eth_ref_clk_sel_reg = false;
> -
> - /* Gigabit Ethernet 125MHz clock selection. */
> - eth_clk_sel_reg = dev_read_bool(dev, "st,eth-clk-sel");
> -
> - /* Ethernet 50Mhz RMII clock selection */
> - eth_ref_clk_sel_reg =
> - dev_read_bool(dev, "st,eth-ref-clk-sel");
> -
> - syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
> -
> - if (!syscfg)
> - return -ENODEV;
> -
> - switch (interface_type) {
> - case PHY_INTERFACE_MODE_MII:
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - debug("%s: PHY_INTERFACE_MODE_MII\n", __func__);
> - break;
> - case PHY_INTERFACE_MODE_GMII:
> - if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII;
> - debug("%s: PHY_INTERFACE_MODE_GMII\n", __func__);
> - break;
> - case PHY_INTERFACE_MODE_RMII:
> - if (eth_ref_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII;
> - debug("%s: PHY_INTERFACE_MODE_RMII\n", __func__);
> - break;
> - case PHY_INTERFACE_MODE_RGMII:
> - case PHY_INTERFACE_MODE_RGMII_ID:
> - case PHY_INTERFACE_MODE_RGMII_RXID:
> - case PHY_INTERFACE_MODE_RGMII_TXID:
> - if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII;
> - debug("%s: PHY_INTERFACE_MODE_RGMII\n", __func__);
> - break;
> - default:
> - debug("%s: Do not manage %d interface\n",
> - __func__, interface_type);
> - /* Do not manage others interfaces */
> - return -EINVAL;
> - }
> -
> - /* clear and set ETH configuration bits */
> - writel(SYSCFG_PMCSETR_ETH_SEL_MASK | SYSCFG_PMCSETR_ETH_SELMII |
> -SYSCFG_PMCSETR_ETH_REF_CLK_SEL | SYSCFG_PMCSETR_ETH_CLK_SEL,
> -syscfg + SYSCFG_PMCCLRR);
> -
Re: [PATCH v2 04/11] net: dwc_eth_qos: Scrub ifdeffery
On 4/8/24 09:27, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:07 PM
>> To: u-boot@lists.denx.de
>> Cc: Marek Vasut ; Patrice CHOTARD - foss
>> ; Christophe ROULLIER
>> ; Joe Hershberger ;
>> Patrick DELAUNAY - foss ; Ramon Fried
>> ; u-b...@dh-electronics.com;
>> uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 04/11] 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.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Marek Vasut
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc: u-b...@dh-electronics.com
>> Cc: uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/dwc_eth_qos_stm32.c | 25 -
>> 1 file changed, 12 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/dwc_eth_qos_stm32.c
>> b/drivers/net/dwc_eth_qos_stm32.c index 7520a136ed0..d7ec0c9be36 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -46,21 +46,22 @@
>>
>> static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev) { -#ifdef
>> CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> + struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
>> +
>> + if (!CONFIG_IS_ENABLED(CLK))
>> + return 0;
>>
>> return clk_get_rate(&eqos->clk_master_bus);
>> -#else
>> - return 0;
>> -#endif
>> }
>>
>> static int eqos_start_clks_stm32(struct udevice *dev) { -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> + struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
>> int ret;
>>
>> + if (!CONFIG_IS_ENABLED(CLK))
>> + return 0;
>> +
>> debug("%s(dev=%p):\n", __func__, dev);
>>
>> ret = clk_enable(&eqos->clk_master_bus);
>> @@ -89,12 +90,10 @@ static int eqos_start_clks_stm32(struct udevice *dev)
>> }
>> eqos->clk_ck_enabled = true;
>> }
>> -#endif
>>
>> debug("%s: OK\n", __func__);
>> return 0;
>>
>> -#ifdef CONFIG_CLK
>> err_disable_clk_tx:
>> clk_disable(&eqos->clk_tx);
>> err_disable_clk_rx:
>> @@ -104,20 +103,20 @@ err_disable_clk_master_bus:
>> err:
>> debug("%s: FAILED: %d\n", __func__, ret);
>> return ret;
>> -#endif
>> }
>>
>> static int eqos_stop_clks_stm32(struct udevice *dev) { -#ifdef CONFIG_CLK
>> - struct eqos_priv *eqos = dev_get_priv(dev);
>> + struct eqos_priv __maybe_unused *eqos = dev_get_priv(dev);
>> +
>> + if (!CONFIG_IS_ENABLED(CLK))
>> + return 0;
>>
>> debug("%s(dev=%p):\n", __func__, dev);
>>
>> clk_disable(&eqos->clk_tx);
>> clk_disable(&eqos->clk_rx);
>> clk_disable(&eqos->clk_master_bus);
>> -#endif
>>
>> debug("%s: OK\n", __func__);
>> return 0;
>> --
>> 2.43.0
>>
> Reviewed-by: Christophe ROULLIER
Applied on u-boot-stm32/master
Re: [PATCH v2 05/11] net: dwc_eth_qos: Use FIELD_PREP for ETH_SEL bitfield
On 3/26/24 13:07, Marek Vasut wrote:
> Use FIELD_PREP to configure content of ETH_SEL bitfield in SYSCFG_PMCSETR
> register. No functional change.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> drivers/net/dwc_eth_qos_stm32.c | 33 -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index d7ec0c9be36..7545026b158 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "dwc_eth_qos.h"
> @@ -40,9 +41,9 @@
> #define SYSCFG_PMCSETR_ETH_SELMIIBIT(20)
>
> #define SYSCFG_PMCSETR_ETH_SEL_MASK GENMASK(23, 21)
> -#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII 0
> -#define SYSCFG_PMCSETR_ETH_SEL_RGMII BIT(21)
> -#define SYSCFG_PMCSETR_ETH_SEL_RMII BIT(23)
> +#define SYSCFG_PMCSETR_ETH_SEL_GMII_MII 0x0
> +#define SYSCFG_PMCSETR_ETH_SEL_RGMII 0x1
> +#define SYSCFG_PMCSETR_ETH_SEL_RMII 0x4
>
> static ulong eqos_get_tick_clk_rate_stm32(struct udevice *dev)
> {
> @@ -142,35 +143,33 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>
> switch (interface_type) {
> case PHY_INTERFACE_MODE_MII:
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> + value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_MII\n");
> break;
> case PHY_INTERFACE_MODE_GMII:
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_GMII_MII;
> + value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_GMII\n");
> break;
> case PHY_INTERFACE_MODE_RMII:
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_RMII);
> if (eth_ref_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII |
> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RMII;
> + value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_RMII\n");
> break;
> case PHY_INTERFACE_MODE_RGMII:
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> + value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> +SYSCFG_PMCSETR_ETH_SEL_RGMII);
> if (eth_clk_sel_reg)
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII |
> - SYSCFG_PMCSETR_ETH_CLK_SEL;
> - else
> - value = SYSCFG_PMCSETR_ETH_SEL_RGMII;
> + value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> log_debug("PHY_INTERFACE_MODE_RGMII\n");
> break;
> default:
Applied on u-boot-stm32/master
Re: [PATCH v2 06/11] net: dwc_eth_qos: Move log_debug statements on top of case block
On 3/26/24 13:07, Marek Vasut wrote:
> Move the log_debug() calls on top of the bit manipulation code.
> No functional change.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> drivers/net/dwc_eth_qos_stm32.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index 7545026b158..38037c47954 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -143,34 +143,34 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>
> switch (interface_type) {
> case PHY_INTERFACE_MODE_MII:
> + log_debug("PHY_INTERFACE_MODE_MII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_MII\n");
> break;
> case PHY_INTERFACE_MODE_GMII:
> + log_debug("PHY_INTERFACE_MODE_GMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_GMII\n");
> break;
> case PHY_INTERFACE_MODE_RMII:
> + log_debug("PHY_INTERFACE_MODE_RMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RMII);
> if (eth_ref_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_RMII\n");
> break;
> case PHY_INTERFACE_MODE_RGMII:
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> + log_debug("PHY_INTERFACE_MODE_RGMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RGMII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> - log_debug("PHY_INTERFACE_MODE_RGMII\n");
> break;
> default:
> log_debug("Do not manage %d interface\n",
Applied on u-boot-stm32/master
Re: [PATCH v2 07/11] net: dwc_eth_qos: Use consistent logging prints
On 3/26/24 13:07, Marek Vasut wrote:
> Use dev_*() only to print all the logs from this glue code,
> instead of mixing dev_*(), log_*(), pr_*() all in one code.
>
> Reviewed-by: Patrice Chotard
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Add RB from Patrice
> ---
> drivers/net/dwc_eth_qos_stm32.c | 52 ++---
> 1 file changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index 38037c47954..72f65f80540 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -63,36 +63,36 @@ static int eqos_start_clks_stm32(struct udevice *dev)
> if (!CONFIG_IS_ENABLED(CLK))
> return 0;
>
> - debug("%s(dev=%p):\n", __func__, dev);
> + dev_dbg(dev, "%s:\n", __func__);
>
> ret = clk_enable(&eqos->clk_master_bus);
> if (ret < 0) {
> - pr_err("clk_enable(clk_master_bus) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_master_bus) failed: %d\n", ret);
> goto err;
> }
>
> ret = clk_enable(&eqos->clk_rx);
> if (ret < 0) {
> - pr_err("clk_enable(clk_rx) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_rx) failed: %d\n", ret);
> goto err_disable_clk_master_bus;
> }
>
> ret = clk_enable(&eqos->clk_tx);
> if (ret < 0) {
> - pr_err("clk_enable(clk_tx) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_tx) failed: %d\n", ret);
> goto err_disable_clk_rx;
> }
>
> if (clk_valid(&eqos->clk_ck) && !eqos->clk_ck_enabled) {
> ret = clk_enable(&eqos->clk_ck);
> if (ret < 0) {
> - pr_err("clk_enable(clk_ck) failed: %d", ret);
> + dev_err(dev, "clk_enable(clk_ck) failed: %d\n", ret);
> goto err_disable_clk_tx;
> }
> eqos->clk_ck_enabled = true;
> }
>
> - debug("%s: OK\n", __func__);
> + dev_dbg(dev, "%s: OK\n", __func__);
> return 0;
>
> err_disable_clk_tx:
> @@ -102,7 +102,8 @@ err_disable_clk_rx:
> err_disable_clk_master_bus:
> clk_disable(&eqos->clk_master_bus);
> err:
> - debug("%s: FAILED: %d\n", __func__, ret);
> + dev_dbg(dev, "%s: FAILED: %d\n", __func__, ret);
> +
> return ret;
> }
>
> @@ -113,13 +114,14 @@ static int eqos_stop_clks_stm32(struct udevice *dev)
> if (!CONFIG_IS_ENABLED(CLK))
> return 0;
>
> - debug("%s(dev=%p):\n", __func__, dev);
> + dev_dbg(dev, "%s:\n", __func__);
>
> clk_disable(&eqos->clk_tx);
> clk_disable(&eqos->clk_rx);
> clk_disable(&eqos->clk_master_bus);
>
> - debug("%s: OK\n", __func__);
> + dev_dbg(dev, "%s: OK\n", __func__);
> +
> return 0;
> }
>
> @@ -143,20 +145,20 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>
> switch (interface_type) {
> case PHY_INTERFACE_MODE_MII:
> - log_debug("PHY_INTERFACE_MODE_MII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_GMII:
> - log_debug("PHY_INTERFACE_MODE_GMII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_RMII:
> - log_debug("PHY_INTERFACE_MODE_RMII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RMII);
> if (eth_ref_clk_sel_reg)
> @@ -166,15 +168,15 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> - log_debug("PHY_INTERFACE_MODE_RGMII\n");
> + dev_dbg(dev, "PHY_INTERFACE_MODE_RGMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RGMII);
> if (eth_clk_sel_reg)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> default:
> - log_debug("Do not manage %d interface\n",
> - interface_type);
> +
Re: [PATCH v2 10/11] net: dwc_eth_qos: Add support of STM32MP13xx platform
On 4/8/24 17:51, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Christophe ROULLIER; Patrice CHOTARD -
>> foss; Marek Vasut; Joe
>> Hershberger; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 10/11] net: dwc_eth_qos: Add support of STM32MP13xx
>> platform
>>
>> From: Christophe Roullier
>>
>> Add compatible "st,stm32mp13-dwmac" to manage STM32MP13 boards.
>>
>> Reviewed-by: Patrice Chotard
>> Signed-off-by: Christophe Roullier
>> Signed-off-by: Marek Vasut # Rebase, reshuffle, squash code
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: Add RB from Patrice
>> ---
>> drivers/net/dwc_eth_qos.c | 4
>> drivers/net/dwc_eth_qos.h | 1 +
>> drivers/net/dwc_eth_qos_stm32.c | 11 +++
>> 3 files changed, 16 insertions(+)
>>
>> diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index
>> 203bfc0848c..e02317905e5 100644
>> --- a/drivers/net/dwc_eth_qos.c
>> +++ b/drivers/net/dwc_eth_qos.c
>> @@ -1505,6 +1505,10 @@ static const struct udevice_id eqos_ids[] = {
>> },
>> #endif
>> #if IS_ENABLED(CONFIG_DWC_ETH_QOS_STM32)
>> + {
>> + .compatible = "st,stm32mp13-dwmac",
>> + .data = (ulong)&eqos_stm32mp13_config
>> + },
>> {
>> .compatible = "st,stm32mp1-dwmac",
>> .data = (ulong)&eqos_stm32mp15_config diff --git
>> a/drivers/net/dwc_eth_qos.h b/drivers/net/dwc_eth_qos.h index
>> bafd0d339fb..8b3d0d464d3 100644
>> --- a/drivers/net/dwc_eth_qos.h
>> +++ b/drivers/net/dwc_eth_qos.h
>> @@ -290,5 +290,6 @@ int eqos_null_ops(struct udevice *dev); extern struct
>> eqos_config eqos_imx_config; extern struct eqos_config
>> eqos_rockchip_config; extern struct eqos_config eqos_qcom_config;
>> +extern struct eqos_config eqos_stm32mp13_config;
>> extern struct eqos_config eqos_stm32mp15_config; extern struct
>> eqos_config eqos_jh7110_config; diff --git a/drivers/net/dwc_eth_qos_stm32.c
>> b/drivers/net/dwc_eth_qos_stm32.c index 5a20fe5bea2..435473f99a6 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -279,6 +279,17 @@ static struct eqos_ops eqos_stm32_ops = {
>> .eqos_get_tick_clk_rate = eqos_get_tick_clk_rate_stm32 };
>>
>> +struct eqos_config __maybe_unused eqos_stm32mp13_config = {
>> + .reg_access_always_ok = false,
>> + .mdio_wait = 1,
>> + .swr_wait = 50,
>> + .config_mac = EQOS_MAC_RXQ_CTRL0_RXQ0EN_ENABLED_DCB,
>> + .config_mac_mdio = EQOS_MAC_MDIO_ADDRESS_CR_250_300,
>> + .axi_bus_width = EQOS_AXI_WIDTH_32,
>> + .interface = dev_read_phy_mode,
>> + .ops = &eqos_stm32_ops
>> +};
>> +
>> struct eqos_config __maybe_unused eqos_stm32mp15_config = {
>> .reg_access_always_ok = false,
>> .mdio_wait = 1,
>> --
>> 2.43.0
>>
> Reviewed-by: Christophe ROULLIER
Applied on u-boot-stm32/master
Re: [PATCH v2 08/11] net: dwc_eth_qos: Constify st,eth-* values parsed out of DT
On 3/26/24 13:07, Marek Vasut wrote:
> 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
> Signed-off-by: Marek Vasut
> ---
> Cc: Christophe Roullier
> Cc: Joe Hershberger
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Ramon Fried
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: - Add RB from Patrice
> - Add trailing fullstop at the end of code comment
> ---
> drivers/net/dwc_eth_qos_stm32.c | 18 +++---
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/dwc_eth_qos_stm32.c b/drivers/net/dwc_eth_qos_stm32.c
> index 72f65f80540..0b13d01346b 100644
> --- a/drivers/net/dwc_eth_qos_stm32.c
> +++ b/drivers/net/dwc_eth_qos_stm32.c
> @@ -128,17 +128,13 @@ static int eqos_stop_clks_stm32(struct udevice *dev)
> static int eqos_probe_syscfg_stm32(struct udevice *dev,
> phy_interface_t interface_type)
> {
> - bool eth_ref_clk_sel_reg = false;
> - bool eth_clk_sel_reg = false;
> + /* Ethernet 50MHz RMII clock selection. */
> + const bool eth_ref_clk_sel = dev_read_bool(dev, "st,eth-ref-clk-sel");
> + /* Gigabit Ethernet 125MHz clock selection. */
> + const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel");
> u8 *syscfg;
> u32 value;
>
> - /* Gigabit Ethernet 125MHz clock selection. */
> - eth_clk_sel_reg = dev_read_bool(dev, "st,eth-clk-sel");
> -
> - /* Ethernet 50Mhz RMII clock selection */
> - eth_ref_clk_sel_reg = dev_read_bool(dev, "st,eth-ref-clk-sel");
> -
> syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
> if (!syscfg)
> return -ENODEV;
> @@ -154,14 +150,14 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
> dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
> - if (eth_clk_sel_reg)
> + if (eth_clk_sel)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_RMII:
> dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RMII);
> - if (eth_ref_clk_sel_reg)
> + if (eth_ref_clk_sel)
> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
> break;
> case PHY_INTERFACE_MODE_RGMII:
> @@ -171,7 +167,7 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
> dev_dbg(dev, "PHY_INTERFACE_MODE_RGMII\n");
> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
> SYSCFG_PMCSETR_ETH_SEL_RGMII);
> - if (eth_clk_sel_reg)
> + if (eth_clk_sel)
> value |= SYSCFG_PMCSETR_ETH_CLK_SEL;
> break;
> default:
Applied on u-boot-stm32/master
Re: [PATCH v2 09/11] net: dwc_eth_qos: Add DT parsing for STM32MP13xx platform
On 4/8/24 17:50, Christophe ROULLIER wrote:
>> -Original Message-
>> From: Marek Vasut
>> Sent: Tuesday, March 26, 2024 1:08 PM
>> To:u-boot@lists.denx.de
>> Cc: Christophe ROULLIER; Marek
>> Vasut; Joe Hershberger; Patrice
>> CHOTARD - foss; Patrick DELAUNAY -
>> foss; Ramon
>> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com
>> Subject: [PATCH v2 09/11] net: dwc_eth_qos: Add DT parsing for STM32MP13xx
>> platform
>>
>> From: Christophe Roullier
>>
>> Manage 2 ethernet instances, select which instance to configure with mask If
>> mask is not present in DT, it is stm32mp15 platform.
>>
>> Signed-off-by: Christophe Roullier
>> Signed-off-by: Marek Vasut # Rework the code
>> ---
>> Cc: Christophe Roullier
>> Cc: Joe Hershberger
>> Cc: Patrice Chotard
>> Cc: Patrick Delaunay
>> Cc: Ramon Fried
>> Cc:u-b...@dh-electronics.com
>> Cc:uboot-st...@st-md-mailman.stormreply.com
>> ---
>> V2: - Drop unrelated clock frequency validation
>> - Move "st,ext-phyclk" property support into separate patch
>> - This leaves only the regmap parts here
>> ---
>> drivers/net/dwc_eth_qos_stm32.c | 41 ++---
>> 1 file changed, 28 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/dwc_eth_qos_stm32.c
>> b/drivers/net/dwc_eth_qos_stm32.c index 0b13d01346b..5a20fe5bea2 100644
>> --- a/drivers/net/dwc_eth_qos_stm32.c
>> +++ b/drivers/net/dwc_eth_qos_stm32.c
>> @@ -23,6 +23,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -33,11 +34,16 @@
>>
>> /* SYSCFG registers */
>> #define SYSCFG_PMCSETR 0x04
>> -#define SYSCFG_PMCCLRR 0x44
>> +#define SYSCFG_PMCCLRR_MP13 0x08
>> +#define SYSCFG_PMCCLRR_MP15 0x44
>> +
>> +#define SYSCFG_PMCSETR_ETH1_MASK GENMASK(23, 16)
>> +#define SYSCFG_PMCSETR_ETH2_MASK GENMASK(31, 24)
>>
>> #define SYSCFG_PMCSETR_ETH_CLK_SEL BIT(16)
>> #define SYSCFG_PMCSETR_ETH_REF_CLK_SEL BIT(17)
>>
>> +/* STM32MP15xx specific bit */
>> #define SYSCFG_PMCSETR_ETH_SELMII BIT(20)
>>
>> #define SYSCFG_PMCSETR_ETH_SEL_MASK GENMASK(23, 21)
>> @@ -130,23 +136,30 @@ static int eqos_probe_syscfg_stm32(struct udevice
>> *dev, {
>> /* Ethernet 50MHz RMII clock selection. */
>> const bool eth_ref_clk_sel = dev_read_bool(dev,
>> "st,eth-ref-clk-sel");
>> + /* SoC is STM32MP13xx with two ethernet MACs */
>> + const bool is_mp13 = device_is_compatible(dev, "st,stm32mp13-dwmac");
>> /* Gigabit Ethernet 125MHz clock selection. */
>> const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel");
>> - u8 *syscfg;
>> + struct regmap *regmap;
>> + u32 regmap_mask;
>> u32 value;
>>
>> - syscfg = (u8 *)syscon_get_first_range(STM32MP_SYSCON_SYSCFG);
>> - if (!syscfg)
>> - return -ENODEV;
>> + regmap = syscon_regmap_lookup_by_phandle(dev, "st,syscon");
>> + if (IS_ERR(regmap))
>> + return PTR_ERR(regmap);
>> +
>> + regmap_mask = dev_read_u32_index_default(dev, "st,syscon", 2,
>> + SYSCFG_PMCSETR_ETH1_MASK);
>>
>> switch (interface_type) {
>> case PHY_INTERFACE_MODE_MII:
>> dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n");
>> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
>> SYSCFG_PMCSETR_ETH_SEL_GMII_MII);
>> - value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL;
>> + if (!is_mp13) /* Select MII mode on STM32MP15xx */
>> + value |= SYSCFG_PMCSETR_ETH_SELMII;
>> break;
>> - case PHY_INTERFACE_MODE_GMII:
>> + case PHY_INTERFACE_MODE_GMII: /* STM32MP15xx only */
>> dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n");
>> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK,
>> SYSCFG_PMCSETR_ETH_SEL_GMII_MII); @@
>> -177,13 +190,15 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev,
>> return -EINVAL;
>> }
>>
>> - /* clear and set ETH configuration bits */
>> - writel(SYSCFG_PMCSETR_ETH_SEL_MASK | SYSCFG_PMCSETR_ETH_SELMII |
>> - SYSCFG_PMCSETR_ETH_REF_CLK_SEL | SYSCFG_PMCSETR_ETH_CLK_SEL,
>> - syscfg + SYSCFG_PMCCLRR);
>> - writel(value, syscfg + SYSCFG_PMCSETR);
>> + /* Shift value at correct ethernet MAC offset in SYSCFG_PMCSETR */
>> + value <<= ffs(regmap_mask) - ffs(SYSCFG_PMCSETR_ETH1_MASK);
>>
>> - return 0;
>> + /* Update PMCCLRR (clear register) */
>> + regmap_write(regmap, is_mp13 ?
>> + SYSCFG_PMCCLRR_MP13 : SYSCFG_PMCCLRR_MP15,
>> + regmap_mask);
>> +
>> + return regmap_update_bits(regmap, SYSCFG_PMCSETR, regmap_mask,
>> value);
>> }
>>
>> static int eqos_probe_resources_st
Re: [PATCH v2 11/11] net: dwc_eth_qos: Add support for st, ext-phyclk property
On 4/8/24 17:52, Christophe ROULLIER wrote: >> -Original Message- >> From: Marek Vasut >> Sent: Tuesday, March 26, 2024 1:08 PM >> To:u-boot@lists.denx.de >> Cc: Marek Vasut; Christophe >> ROULLIER; Joe >> Hershberger; Patrice CHOTARD - >> foss; Patrick DELAUNAY - >> foss; Ramon >> Fried;u-b...@dh-electronics.com;uboot-st...@st-md-mailman.stormreply.com >> Subject: [PATCH v2 11/11] 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 >> --- >> Cc: Christophe Roullier >> Cc: Joe Hershberger >> Cc: Patrice Chotard >> Cc: Patrick Delaunay >> Cc: Ramon Fried >> Cc:u-b...@dh-electronics.com >> Cc:uboot-st...@st-md-mailman.stormreply.com >> --- >> V2: New patch >> --- >> drivers/net/dwc_eth_qos_stm32.c | 30 +++--- >> 1 file changed, 27 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/net/dwc_eth_qos_stm32.c >> b/drivers/net/dwc_eth_qos_stm32.c index 435473f99a6..9ee82b54c62 100644 >> --- a/drivers/net/dwc_eth_qos_stm32.c >> +++ b/drivers/net/dwc_eth_qos_stm32.c >> @@ -140,6 +140,8 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> const bool is_mp13 = device_is_compatible(dev, >> "st,stm32mp13-dwmac"); >> /* Gigabit Ethernet 125MHz clock selection. */ >> const bool eth_clk_sel = dev_read_bool(dev, "st,eth-clk-sel"); >> + /* Ethernet clock source is RCC. */ >> + const bool ext_phyclk = dev_read_bool(dev, "st,ext-phyclk"); >> struct regmap *regmap; >> u32 regmap_mask; >> u32 value; >> @@ -156,6 +158,12 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> dev_dbg(dev, "PHY_INTERFACE_MODE_MII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_GMII_MII); >> + /* >> + * STM32MP15xx supports both MII and GMII, STM32MP13xx MII >> only. >> + * SYSCFG_PMCSETR ETH_SELMII is present only on STM32MP15xx >> and >> + * acts as a selector between 0:GMII and 1:MII. As >> STM32MP13xx >> + * supports only MII, ETH_SELMII is not present. >> + */ >> if (!is_mp13) /* Select MII mode on STM32MP15xx */ >> value |= SYSCFG_PMCSETR_ETH_SELMII; >> break; >> @@ -163,14 +171,25 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> dev_dbg(dev, "PHY_INTERFACE_MODE_GMII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_GMII_MII); >> - if (eth_clk_sel) >> + /* >> + * If eth_clk_sel is set, use internal ETH_CLKx clock from >> RCC, >> + * otherwise use external clock from IO pin (requires >> matching >> + * GPIO block AF setting of that pin). >> + */ >> + if (eth_clk_sel || ext_phyclk) >> value |= SYSCFG_PMCSETR_ETH_CLK_SEL; >> break; >> case PHY_INTERFACE_MODE_RMII: >> dev_dbg(dev, "PHY_INTERFACE_MODE_RMII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_RMII); >> - if (eth_ref_clk_sel) >> + /* >> + * If eth_ref_clk_sel is set, use internal clock from RCC, >> + * otherwise use external clock from ETHn_RX_CLK/ETHn_REF_CLK >> + * IO pin (requires matching GPIO block AF setting of that >> + * pin). >> + */ >> + if (eth_ref_clk_sel || ext_phyclk) >> value |= SYSCFG_PMCSETR_ETH_REF_CLK_SEL; >> break; >> case PHY_INTERFACE_MODE_RGMII: >> @@ -180,7 +199,12 @@ static int eqos_probe_syscfg_stm32(struct udevice *dev, >> dev_dbg(dev, "PHY_INTERFACE_MODE_RGMII\n"); >> value = FIELD_PREP(SYSCFG_PMCSETR_ETH_SEL_MASK, >> SYSCFG_PMCSETR_ETH_SEL_RGMII); >> - if (eth_clk_sel) >> + /* >> + * If eth_clk_sel is set, use internal ETH_CLKx clock from >> RCC, >> + * otherwise use external clock from ETHx_CLK125 pin >> (requires >> + * matching GPIO block AF setting of that pin). >> + */ >> + if (eth_clk_sel || ex
Re: [PATCH] ARM: stm32: Report OTP-CLOSED instead of rev.? on closed STM32MP15xx
On 4/14/24 20:39, Marek Vasut wrote:
> 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
> ---
> Cc: Igor Opaniuk
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Simon Glass Cc: Simon Glass
> Cc: Tom Rini
> Cc: u-b...@dh-electronics.com
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 19 +--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> index afc56b02eea..dd99150fbc2 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c
> @@ -322,8 +322,23 @@ void get_soc_name(char name[SOC_NAME_SIZE])
>
> get_cpu_string_offsets(&type, &pkg, &rev);
>
> - snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> - soc_type[type], soc_pkg[pkg], soc_rev[rev]);
> + if (bsec_dbgswenable()) {
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s Rev.%s",
> + soc_type[type], soc_pkg[pkg], soc_rev[rev]);
> + } else {
> + /*
> + * 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.
> + */
> + snprintf(name, SOC_NAME_SIZE, "STM32MP%s%s SEC/C",
> + soc_type[type], soc_pkg[pkg]);
> + }
> }
>
> static void setup_soc_type_pkg_rev(void)
Applied on u-boot-stm32/master
Re: [PATCH] ARM: stm32: Drop superfluous Makefile entry for ecdsa_romapi.o
On 4/14/24 20:38, Marek Vasut wrote: > 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 > --- > Cc: Igor Opaniuk > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: Simon Glass Cc: Simon Glass > Cc: Tom Rini > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > arch/arm/mach-stm32mp/stm32mp1/Makefile | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/mach-stm32mp/stm32mp1/Makefile > b/arch/arm/mach-stm32mp/stm32mp1/Makefile > index 857148747ef..ebae50f66c9 100644 > --- a/arch/arm/mach-stm32mp/stm32mp1/Makefile > +++ b/arch/arm/mach-stm32mp/stm32mp1/Makefile > @@ -8,7 +8,6 @@ obj-y += cpu.o > obj-$(CONFIG_STM32MP13X) += stm32mp13x.o > obj-$(CONFIG_STM32MP15X) += stm32mp15x.o > > -obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o > ifdef CONFIG_SPL_BUILD > obj-y += spl.o > obj-y += tzc400.o Applied on u-boot-stm32/master
Re: [PATCH v2] ARM: stm32: Jump to ep on successful resume in PSCI suspend code
On 4/7/24 22:21, Marek Vasut wrote:
> 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
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: u-b...@dh-electronics.com
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---
> V2: Rebase on u-boot/master
> ---
> arch/arm/mach-stm32mp/stm32mp1/psci.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> index 8cdeb0ab3f2..4f2379df45f 100644
> --- a/arch/arm/mach-stm32mp/stm32mp1/psci.c
> +++ b/arch/arm/mach-stm32mp/stm32mp1/psci.c
> @@ -703,6 +703,8 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
> {
> u32 saved_mcudivr, saved_pll3cr, saved_pll4cr, saved_mssckselr;
> u32 gicd_addr = stm32mp_get_gicd_base_address();
> + u32 cpu = psci_get_cpu_id();
> + u32 sp = (u32)__secure_stack_end - (cpu << ARM_PSCI_STACK_SHIFT);
> bool iwdg1_wake = false;
> bool iwdg2_wake = false;
> bool other_wake = false;
> @@ -805,4 +807,16 @@ void __secure psci_system_suspend(u32 __always_unused
> function_id,
>
> writel(SYSCFG_CMPENR_MPUEN, STM32_SYSCFG_BASE + SYSCFG_CMPENSETR);
> clrbits_le32(STM32_SYSCFG_BASE + SYSCFG_CMPCR, SYSCFG_CMPCR_SW_CTRL);
> +
> + /*
> + * The system has resumed successfully. Rewrite LR register stored
> + * on stack with 'ep' value, so that on return from this PSCI call,
> + * the code would jump to that 'ep' resume entry point code path
> + * instead of the previous 'lr' register content which (e.g. with
> + * Linux) points to resume failure code path.
> + *
> + * See arch/arm/cpu/armv7/psci.S _smc_psci: for the stack layout
> + * used here, SP-4 is PC, SP-8 is LR, SP-12 is R7, and so on.
> + */
> + writel(ep, sp - 8);
> }
Applied on u-boot-stm32/master
Re: [PATCH v1 1/2] memory: stm32-fmc2-ebi: add MP25 support
On 3/6/24 10:50, Christophe Kerello wrote:
> 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.
>
> Signed-off-by: Christophe Kerello
>
> ---
>
> drivers/memory/stm32-fmc2-ebi.c | 313 ++--
> 1 file changed, 301 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index a722a3836f7..c7db16463e8 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -22,6 +22,7 @@
> #define FMC2_BCR(x) ((x) * 0x8 + FMC2_BCR1)
> #define FMC2_BTR(x) ((x) * 0x8 + FMC2_BTR1)
> #define FMC2_PCSCNTR 0x20
> +#define FMC2_CFGR0x20
> #define FMC2_BWTR1 0x104
> #define FMC2_BWTR(x) ((x) * 0x8 + FMC2_BWTR1)
>
> @@ -44,6 +45,7 @@
> #define FMC2_BCR_ASYNCWAIT BIT(15)
> #define FMC2_BCR_CPSIZE GENMASK(18, 16)
> #define FMC2_BCR_CBURSTRWBIT(19)
> +#define FMC2_BCR_CSCOUNT GENMASK(21, 20)
> #define FMC2_BCR_NBLSET GENMASK(23, 22)
>
> /* Register: FMC2_BTRx/FMC2_BWTRx */
> @@ -60,6 +62,11 @@
> #define FMC2_PCSCNTR_CSCOUNT GENMASK(15, 0)
> #define FMC2_PCSCNTR_CNTBEN(x) BIT((x) + 16)
>
> +/* Register: FMC2_CFGR */
> +#define FMC2_CFGR_CLKDIV GENMASK(19, 16)
> +#define FMC2_CFGR_CCLKEN BIT(20)
> +#define FMC2_CFGR_FMC2EN BIT(31)
> +
> #define FMC2_MAX_EBI_CE 4
> #define FMC2_MAX_BANKS 5
>
> @@ -76,6 +83,11 @@
> #define FMC2_BCR_MTYP_PSRAM 0x1
> #define FMC2_BCR_MTYP_NOR0x2
>
> +#define FMC2_BCR_CSCOUNT_0 0x0
> +#define FMC2_BCR_CSCOUNT_1 0x1
> +#define FMC2_BCR_CSCOUNT_64 0x2
> +#define FMC2_BCR_CSCOUNT_256 0x3
> +
> #define FMC2_BXTR_EXTMOD_A 0x0
> #define FMC2_BXTR_EXTMOD_B 0x1
> #define FMC2_BXTR_EXTMOD_C 0x2
> @@ -90,6 +102,7 @@
> #define FMC2_BTR_CLKDIV_MAX 0xf
> #define FMC2_BTR_DATLAT_MAX 0xf
> #define FMC2_PCSCNTR_CSCOUNT_MAX 0xff
> +#define FMC2_CFGR_CLKDIV_MAX 0xf
>
> enum stm32_fmc2_ebi_bank {
> FMC2_EBI1 = 0,
> @@ -103,7 +116,8 @@ enum stm32_fmc2_ebi_register_type {
> FMC2_REG_BCR = 1,
> FMC2_REG_BTR,
> FMC2_REG_BWTR,
> - FMC2_REG_PCSCNTR
> + FMC2_REG_PCSCNTR,
> + FMC2_REG_CFGR
> };
>
> enum stm32_fmc2_ebi_transaction_type {
> @@ -134,9 +148,27 @@ enum stm32_fmc2_ebi_cpsize {
> FMC2_CPSIZE_1024 = 1024
> };
>
> +enum stm32_fmc2_ebi_cscount {
> + FMC2_CSCOUNT_0 = 0,
> + FMC2_CSCOUNT_1 = 1,
> + FMC2_CSCOUNT_64 = 64,
> + FMC2_CSCOUNT_256 = 256
> +};
> +
> +struct stm32_fmc2_ebi;
> +
> +struct stm32_fmc2_ebi_data {
> + const struct stm32_fmc2_prop *child_props;
> + unsigned int nb_child_props;
> + u32 fmc2_enable_reg;
> + u32 fmc2_enable_bit;
> + int (*nwait_used_by_ctrls)(struct stm32_fmc2_ebi *ebi);
> +};
> +
> struct stm32_fmc2_ebi {
> struct clk clk;
> fdt_addr_t io_base;
> + const struct stm32_fmc2_ebi_data *data;
> u8 bank_assigned;
> };
>
> @@ -296,6 +328,24 @@ static u32 stm32_fmc2_ebi_ns_to_clk_period(struct
> stm32_fmc2_ebi *ebi,
> return DIV_ROUND_UP(nb_clk_cycles, clk_period);
> }
>
> +static u32 stm32_fmc2_ebi_mp25_ns_to_clk_period(struct stm32_fmc2_ebi *ebi,
> + int cs, u32 setup)
> +{
> + u32 nb_clk_cycles = stm32_fmc2_ebi_ns_to_clock_cycles(ebi, cs, setup);
> + u32 cfgr = readl(ebi->io_base + FMC2_CFGR);
> + u32 clk_period;
> +
> + if (cfgr & FMC2_CFGR_CCLKEN) {
> + clk_period = FIELD_GET(FMC2_CFGR_CLKDIV, cfgr) + 1;
> + } else {
> + u32 btr = readl(ebi->io_base + FMC2_BTR(cs));
> +
> + clk_period = FIELD_GET(FMC2_BTR_CLKDIV, btr) + 1;
> + }
> +
> + return DIV_ROUND_UP(nb_clk_cycles, clk_period);
> +}
> +
> static int stm32_fmc2_ebi_get_reg(int reg_type, int cs, u32 *reg)
> {
> switch (reg_type) {
> @@ -311,6 +361,9 @@ static int stm32_fmc2_ebi_get_reg(int reg_type, int cs,
> u32 *reg)
> case FMC2_REG_PCSCNTR:
> *reg = FMC2_PCSCNTR;
> break;
> + case FMC2_REG_CFGR:
> +
Re: [PATCH v1 2/2] memory: stm32-fmc2-ebi: add MP25 RIF support
On 3/6/24 10:50, Christophe Kerello wrote:
> 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.
>
> Signed-off-by: Christophe Kerello
> ---
>
> drivers/memory/stm32-fmc2-ebi.c | 140 +++-
> 1 file changed, 138 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memory/stm32-fmc2-ebi.c b/drivers/memory/stm32-fmc2-ebi.c
> index c7db16463e8..1ce96077858 100644
> --- a/drivers/memory/stm32-fmc2-ebi.c
> +++ b/drivers/memory/stm32-fmc2-ebi.c
> @@ -23,8 +23,14 @@
> #define FMC2_BTR(x) ((x) * 0x8 + FMC2_BTR1)
> #define FMC2_PCSCNTR 0x20
> #define FMC2_CFGR0x20
> +#define FMC2_SR 0x84
> #define FMC2_BWTR1 0x104
> #define FMC2_BWTR(x) ((x) * 0x8 + FMC2_BWTR1)
> +#define FMC2_SECCFGR 0x300
> +#define FMC2_CIDCFGR00x30c
> +#define FMC2_CIDCFGR(x) ((x) * 0x8 + FMC2_CIDCFGR0)
> +#define FMC2_SEMCR0 0x310
> +#define FMC2_SEMCR(x)((x) * 0x8 + FMC2_SEMCR0)
>
> /* Register: FMC2_BCR1 */
> #define FMC2_BCR1_CCLKEN BIT(20)
> @@ -67,8 +73,23 @@
> #define FMC2_CFGR_CCLKEN BIT(20)
> #define FMC2_CFGR_FMC2EN BIT(31)
>
> +/* Register: FMC2_SR */
> +#define FMC2_SR_ISOSTGENMASK(1, 0)
> +
> +/* Register: FMC2_CIDCFGR */
> +#define FMC2_CIDCFGR_CFENBIT(0)
> +#define FMC2_CIDCFGR_SEMEN BIT(1)
> +#define FMC2_CIDCFGR_SCIDGENMASK(6, 4)
> +#define FMC2_CIDCFGR_SEMWLC1 BIT(17)
> +
> +/* Register: FMC2_SEMCR */
> +#define FMC2_SEMCR_SEM_MUTEX BIT(0)
> +#define FMC2_SEMCR_SEMCIDGENMASK(6, 4)
> +
> #define FMC2_MAX_EBI_CE 4
> #define FMC2_MAX_BANKS 5
> +#define FMC2_MAX_RESOURCES 6
> +#define FMC2_CID11
>
> #define FMC2_BCR_CPSIZE_00x0
> #define FMC2_BCR_CPSIZE_128 0x1
> @@ -163,6 +184,7 @@ struct stm32_fmc2_ebi_data {
> u32 fmc2_enable_reg;
> u32 fmc2_enable_bit;
> int (*nwait_used_by_ctrls)(struct stm32_fmc2_ebi *ebi);
> + int (*check_rif)(struct stm32_fmc2_ebi *ebi, u32 resource);
> };
>
> struct stm32_fmc2_ebi {
> @@ -170,6 +192,7 @@ struct stm32_fmc2_ebi {
> fdt_addr_t io_base;
> const struct stm32_fmc2_ebi_data *data;
> u8 bank_assigned;
> + bool access_granted;
> };
>
> /*
> @@ -241,6 +264,28 @@ static int stm32_fmc2_ebi_check_sync_trans(struct
> stm32_fmc2_ebi *ebi,
> return -EINVAL;
> }
>
> +static int stm32_fmc2_ebi_mp25_check_cclk(struct stm32_fmc2_ebi *ebi,
> + const struct stm32_fmc2_prop *prop,
> + int cs)
> +{
> + if (!ebi->access_granted)
> + return -EACCES;
> +
> + return stm32_fmc2_ebi_check_sync_trans(ebi, prop, cs);
> +}
> +
> +static int stm32_fmc2_ebi_mp25_check_clk_period(struct stm32_fmc2_ebi *ebi,
> + const struct stm32_fmc2_prop
> *prop,
> + int cs)
> +{
> + u32 cfgr = readl(ebi->io_base + FMC2_CFGR);
> +
> + if (cfgr & FMC2_CFGR_CCLKEN && !ebi->access_granted)
> + return -EACCES;
> +
> + return stm32_fmc2_ebi_check_sync_trans(ebi, prop, cs);
> +}
> +
> static int stm32_fmc2_ebi_check_async_trans(struct stm32_fmc2_ebi *ebi,
> const struct stm32_fmc2_prop *prop,
> int cs)
> @@ -960,7 +1005,7 @@ static const struct stm32_fmc2_prop
> stm32_fmc2_mp25_child_props[] = {
> .bprop = true,
> .reg_type = FMC2_REG_CFGR,
> .reg_mask = FMC2_CFGR_CCLKEN,
> - .check = stm32_fmc2_ebi_check_sync_trans,
> + .check = stm32_fmc2_ebi_mp25_check_cclk,
> .set = stm32_fmc2_ebi_set_bit_field,
> },
> {
> @@ -1058,7 +1103,7 @@ static const struct stm32_fmc2_prop
> stm32_fmc2_mp25_child_props[] = {
> {
> .name = "st,fmc2-ebi-cs-clk-period-ns",
> .reset_val = FMC2_CFGR_CLKDIV_MAX + 1,
> - .check = stm32_fmc2_ebi_check_sync_trans,
> + .check = stm32_fmc2_ebi_mp25_check_clk_period,
> .calculate = stm32_fmc2_ebi_ns_to_clock_cycles,
> .set = stm32_fmc2_ebi_mp25_set_clk_period,
> },
> @@ -1113
Re: [PATCH] mtd: rawnand: stm32_fmc2: add MP25 support
On 3/6/24 10:54, Christophe Kerello wrote:
> FMC2 IP supports up to 4 chip select. On MP1 SoC, only 2 of them are
> available when on MP25 SoC, the 4 chip select are available.
>
> Let's use a platform data structure for parameters that will differ.
>
> Signed-off-by: Christophe Kerello
> ---
>
> drivers/mtd/nand/raw/stm32_fmc2_nand.c | 47 ++
> 1 file changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> index 3528824575b..d284b8cbb12 100644
> --- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> +++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
> @@ -34,7 +34,7 @@
> #define FMC2_RB_DELAY_US 30
>
> /* Max chip enable */
> -#define FMC2_MAX_CE 2
> +#define FMC2_MAX_CE 4
>
> /* Timings */
> #define FMC2_THIZ1
> @@ -160,6 +160,11 @@ static inline struct stm32_fmc2_nand
> *to_fmc2_nand(struct nand_chip *chip)
> return container_of(chip, struct stm32_fmc2_nand, chip);
> }
>
> +struct stm32_fmc2_nfc_data {
> + int max_ncs;
> + struct udevice *(*get_cdev)(struct udevice *dev);
> +};
> +
> struct stm32_fmc2_nfc {
> struct nand_hw_control base;
> struct stm32_fmc2_nand nand;
> @@ -169,6 +174,7 @@ struct stm32_fmc2_nfc {
> fdt_addr_t cmd_base[FMC2_MAX_CE];
> fdt_addr_t addr_base[FMC2_MAX_CE];
> struct clk clk;
> + const struct stm32_fmc2_nfc_data *data;
>
> u8 cs_assigned;
> int cs_sel;
> @@ -815,7 +821,7 @@ static int stm32_fmc2_nfc_parse_child(struct
> stm32_fmc2_nfc *nfc, ofnode node)
> }
>
> for (i = 0; i < nand->ncs; i++) {
> - if (cs[i] >= FMC2_MAX_CE) {
> + if (cs[i] >= nfc->data->max_ncs) {
> log_err("Invalid reg value: %d\n", nand->cs_used[i]);
> return -EINVAL;
> }
> @@ -906,10 +912,18 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
> spin_lock_init(&nfc->controller.lock);
> init_waitqueue_head(&nfc->controller.wq);
>
> - cdev = stm32_fmc2_nfc_get_cdev(dev);
> - if (!cdev)
> + nfc->data = (void *)dev_get_driver_data(dev);
> + if (!nfc->data)
> return -EINVAL;
>
> + if (nfc->data->get_cdev) {
> + cdev = nfc->data->get_cdev(dev);
> + if (!cdev)
> + return -EINVAL;
> + } else {
> + cdev = dev->parent;
> + }
> +
> ret = stm32_fmc2_nfc_parse_dt(dev, nfc);
> if (ret)
> return ret;
> @@ -921,7 +935,7 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
> if (dev == cdev)
> start_region = 1;
>
> - for (chip_cs = 0, mem_region = start_region; chip_cs < FMC2_MAX_CE;
> + for (chip_cs = 0, mem_region = start_region; chip_cs <
> nfc->data->max_ncs;
>chip_cs++, mem_region += 3) {
> if (!(nfc->cs_assigned & BIT(chip_cs)))
> continue;
> @@ -1033,9 +1047,28 @@ static int stm32_fmc2_nfc_probe(struct udevice *dev)
> return nand_register(0, mtd);
> }
>
> +static const struct stm32_fmc2_nfc_data stm32_fmc2_nfc_mp1_data = {
> + .max_ncs = 2,
> + .get_cdev = stm32_fmc2_nfc_get_cdev,
> +};
> +
> +static const struct stm32_fmc2_nfc_data stm32_fmc2_nfc_mp25_data = {
> + .max_ncs = 4,
> +};
> +
> static const struct udevice_id stm32_fmc2_nfc_match[] = {
> - { .compatible = "st,stm32mp15-fmc2" },
> - { .compatible = "st,stm32mp1-fmc2-nfc" },
> + {
> + .compatible = "st,stm32mp15-fmc2",
> + .data = (ulong)&stm32_fmc2_nfc_mp1_data,
> + },
> + {
> + .compatible = "st,stm32mp1-fmc2-nfc",
> + .data = (ulong)&stm32_fmc2_nfc_mp1_data,
> + },
> + {
> + .compatible = "st,stm32mp25-fmc2-nfc",
> + .data = (ulong)&stm32_fmc2_nfc_mp25_data,
> + },
> { /* Sentinel */ }
> };
>
Applied on u-boot-stm32/master
Re: [PATCH] arm: stm32: Enable OHCI HCD support on STM32MP15xx DHSOM
On 3/4/24 19:25, Marek Vasut wrote: > 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 > --- > Cc: Patrice Chotard > Cc: Patrick Delaunay > Cc: u-b...@dh-electronics.com > Cc: uboot-st...@st-md-mailman.stormreply.com > --- > configs/stm32mp15_dhcom_basic_defconfig | 2 ++ > configs/stm32mp15_dhcor_basic_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/stm32mp15_dhcom_basic_defconfig > b/configs/stm32mp15_dhcom_basic_defconfig > index 1d241529be7..0bfd3b76d6a 100644 > --- a/configs/stm32mp15_dhcom_basic_defconfig > +++ b/configs/stm32mp15_dhcom_basic_defconfig > @@ -164,6 +164,8 @@ CONFIG_DM_USB_GADGET=y > CONFIG_SPL_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_GENERIC=y > CONFIG_USB_DWC2=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y > diff --git a/configs/stm32mp15_dhcor_basic_defconfig > b/configs/stm32mp15_dhcor_basic_defconfig > index 6e0c4a8cf9f..1c1fbc5c7db 100644 > --- a/configs/stm32mp15_dhcor_basic_defconfig > +++ b/configs/stm32mp15_dhcor_basic_defconfig > @@ -164,6 +164,8 @@ CONFIG_DM_USB_GADGET=y > CONFIG_SPL_DM_USB_GADGET=y > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_GENERIC=y > +CONFIG_USB_OHCI_HCD=y > +CONFIG_USB_OHCI_GENERIC=y > CONFIG_USB_DWC2=y > CONFIG_USB_HOST_ETHER=y > CONFIG_USB_ETHER_ASIX=y Applied on u-boot-stm32/master
Re: [PATCH] stm32mp: cmd_stm32prog: add dependencies with USB_GADGET_DOWNLOAD
On 2/7/24 16:59, Igor Opaniuk wrote: > On Wed, Feb 7, 2024 at 2:12 PM Patrick Delaunay > wrote: >> >> 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 >> --- >> >> arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> index 8f91db4b46b9..589276282e44 100644 >> --- a/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> +++ b/arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig >> @@ -17,6 +17,7 @@ config CMD_STM32PROG >> config CMD_STM32PROG_USB >> bool "support stm32prog over USB" >> depends on CMD_STM32PROG >> + depends on USB_GADGET_DOWNLOAD >> default y >> help >> activate the command "stm32prog usb" for STM32MP soc family >> -- >> 2.25.1 >> > > Reviewed-by: Igor Opaniuk Applied on u-boot-stm32/master
Re: [PATCH v1 01/25] configs: stm32mp13: Enable FASTBOOT
On 4/18/24 13:48, Igor Opaniuk wrote: > On Tue, Apr 9, 2024 at 5:19 PM Patrice Chotard > wrote: >> >> Enable FASTBOOT relative flags for stm32mp13_defconfig. >> >> Signed-off-by: Patrice Chotard >> >> --- >> >> configs/stm32mp13_defconfig | 9 - >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig >> index c893e272db9..db09e63100e 100644 >> --- a/configs/stm32mp13_defconfig >> +++ b/configs/stm32mp13_defconfig >> @@ -15,6 +15,7 @@ CONFIG_CMD_STM32PROG=y >> CONFIG_SYS_LOAD_ADDR=0xc200 >> CONFIG_SYS_MEMTEST_START=0xc000 >> CONFIG_SYS_MEMTEST_END=0xc400 >> +# CONFIG_ANDROID_BOOT_IMAGE is not set >> CONFIG_FIT=y >> CONFIG_SYS_BOOTM_LEN=0x200 >> CONFIG_DISTRO_DEFAULTS=y >> @@ -53,6 +54,13 @@ CONFIG_SYS_MMC_ENV_DEV=-1 >> CONFIG_ENV_MMC_USE_DT=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> +CONFIG_USB_FUNCTION_FASTBOOT=y >> +CONFIG_FASTBOOT_BUF_ADDR=0xc000 >> +CONFIG_FASTBOOT_BUF_SIZE=0x0200 >> +CONFIG_FASTBOOT_FLASH=y >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 >> +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y >> +CONFIG_FASTBOOT_CMD_OEM_PARTCONF=y >> CONFIG_GPIO_HOG=y >> CONFIG_DM_I2C=y >> CONFIG_SYS_I2C_STM32F7=y >> @@ -92,7 +100,6 @@ CONFIG_USB_GADGET_MANUFACTURER="STMicroelectronics" >> CONFIG_USB_GADGET_VENDOR_NUM=0x0483 >> CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 >> CONFIG_USB_GADGET_DWC2_OTG=y >> -CONFIG_USB_GADGET_DOWNLOAD=y >> CONFIG_ERRNO_STR=y >> # CONFIG_LMB_USE_MAX_REGIONS is not set >> CONFIG_LMB_MEMORY_REGIONS=2 >> -- >> 2.25.1 >> > Reviewed-by: Igor Opaniuk > Applied on u-boot-stm32/master
Re: [PATCH v1 02/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_defconfig
On 4/17/24 11:03, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp15_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp15_defconfig b/configs/stm32mp15_defconfig >> index 3302b306996..ffe7512650e 100644 >> --- a/configs/stm32mp15_defconfig >> +++ b/configs/stm32mp15_defconfig >> @@ -69,6 +69,8 @@ CONFIG_TFTP_TSIZE=y >> CONFIG_USE_SERVERIP=y >> CONFIG_SERVERIP="192.168.1.1" >> CONFIG_STM32_ADC=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y > > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 04/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_trusted_defconfig
On 4/17/24 11:04, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp15_trusted_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp15_trusted_defconfig >> b/configs/stm32mp15_trusted_defconfig >> index 84b0854b557..74deaaba2e4 100644 >> --- a/configs/stm32mp15_trusted_defconfig >> +++ b/configs/stm32mp15_trusted_defconfig >> @@ -70,6 +70,8 @@ CONFIG_TFTP_TSIZE=y >> CONFIG_USE_SERVERIP=y >> CONFIG_SERVERIP="192.168.1.1" >> CONFIG_STM32_ADC=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 03/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp15_basic_defconfig
On 4/17/24 11:04, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp15_basic_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp15_basic_defconfig >> b/configs/stm32mp15_basic_defconfig >> index 005f1d55f80..2e22bf86000 100644 >> --- a/configs/stm32mp15_basic_defconfig >> +++ b/configs/stm32mp15_basic_defconfig >> @@ -97,6 +97,8 @@ CONFIG_TFTP_TSIZE=y >> CONFIG_USE_SERVERIP=y >> CONFIG_SERVERIP="192.168.1.1" >> CONFIG_STM32_ADC=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y >> CONFIG_FASTBOOT_BUF_ADDR=0xC000 > > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 05/25] configs: stm32mp1: Enable BUTTON_GPIO flag for stm32mp13_defconfig
On 4/18/24 13:48, Igor Opaniuk wrote: > On Tue, Apr 9, 2024 at 5:05 PM Patrice Chotard > wrote: >> >> Enable BUTTON_GPIO flag for STM32MP15. >> >> Signed-off-by: Patrice Chotard >> --- >> >> configs/stm32mp13_defconfig | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/configs/stm32mp13_defconfig b/configs/stm32mp13_defconfig >> index db09e63100e..caaabf39ef3 100644 >> --- a/configs/stm32mp13_defconfig >> +++ b/configs/stm32mp13_defconfig >> @@ -52,6 +52,8 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y >> CONFIG_SYS_RELOC_GD_ENV_ADDR=y >> CONFIG_SYS_MMC_ENV_DEV=-1 >> CONFIG_ENV_MMC_USE_DT=y >> +CONFIG_BUTTON=y >> +CONFIG_BUTTON_GPIO=y >> CONFIG_CLK_SCMI=y >> CONFIG_SET_DFU_ALT_INFO=y >> CONFIG_USB_FUNCTION_FASTBOOT=y >> -- >> 2.25.1 >> > > Reviewed-by: Igor Opaniuk Applied on u-boot-stm32/master
Re: [PATCH v1 07/25] ARM: dts: stm32: Add gpio-keys for stm32mp135f-dk-u-boot
On 4/17/24 11:06, Patrick DELAUNAY wrote: > Hi > > On 4/9/24 17:01, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 13 + >> 1 file changed, 13 insertions(+) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 06/25] board: st: stmp32mp1: Use BUTTON UCLASS in board_key_check()
On 4/17/24 11:05, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> Instead of using gpio directly to detect key pressed on button >> dedicated for fastboot and stm32mprog, make usage of BUTTON UCLASS. >> >> Signed-off-by: Patrice Chotard >> --- >> >> board/st/stm32mp1/stm32mp1.c | 68 +--- >> 1 file changed, 40 insertions(+), 28 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 08/25] ARM: dts: stm32: Don't probe led-red/led-blue at boot for stm32mp135f-dk-u-boot
On 4/17/24 11:06, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:01, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 09/25] ARM: dts: stm32: Clean led-red node for stm32mp135f-dk-u-boot
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:01, Patrice Chotard wrote:
>> Remove "color" property from led-red node which is not supported
>> by U-Boot.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp135f-dk-u-boot.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> index 8f42735609a..f004e9840a2 100644
>> --- a/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp135f-dk-u-boot.dtsi
>> @@ -35,7 +35,6 @@
>> };
>> led-red {
>> - color = ;
>> gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 10/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare
>> 2 gpio-keys.
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 19 +--
>> 1 file changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index 20728f27ee1..5d49b09c35d 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -3,6 +3,7 @@
>> * Copyright : STMicroelectronics 2022
>> */
>> +#include
>> #include "stm32mp15-scmi-u-boot.dtsi"
>> / {
>> @@ -16,8 +17,22 @@
>> u-boot,error-led = "error";
>> u-boot,mmc-env-partition = "u-boot-env";
>> st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
>> - st,fastboot-gpios = <&gpioa 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> - st,stm32prog-gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> + };
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> +
>> + button-user-1 {
>> + label = "User-1";
>> + linux,code = ;
>> + gpios = <&gpioa 14 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> + };
>> +
>> + button-user-2 {
>> + label = "User-2";
>> + linux,code = ;
>> + gpios = <&gpioa 13 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>;
>> + };
>> };
>> led {
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 11/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:07, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> 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
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index 5d49b09c35d..8760d6c7d93 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -39,7 +39,6 @@
>> red {
>> label = "error";
>> gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>> - default-state = "off";
>> status = "okay";
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 12/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:08, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> 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
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index 8760d6c7d93..e61814fd66e 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -14,7 +14,7 @@
>> config {
>> u-boot,boot-led = "heartbeat";
>> - u-boot,error-led = "error";
>> + u-boot,error-led = "led-red";
>> u-boot,mmc-env-partition = "u-boot-env";
>> st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
>> };
>> @@ -36,10 +36,8 @@
>> };
>> led {
>> - red {
>> - label = "error";
>> + led-red {
>> gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>> - status = "okay";
>> };
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 13/25] ARM: dts: stm32: Add led-blue for stm32mp157a-dk1-scmi-u-boot
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> 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
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> index e61814fd66e..a5158fec7ef 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-scmi-u-boot.dtsi
>> @@ -13,7 +13,7 @@
>> };
>> config {
>> - u-boot,boot-led = "heartbeat";
>> + u-boot,boot-led = "led-blue";
>> u-boot,error-led = "led-red";
>> u-boot,mmc-env-partition = "u-boot-env";
>> st,adc_usb_pd = <&adc1 18>, <&adc1 19>;
>> @@ -36,6 +36,10 @@
>> };
>> led {
>> + led-blue {
>> + /delete-property/label;
>> + };
>> +
>> led-red {
>> gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 14/25] ARM: dts: stm32: Add gpio-keys for stm32mp157a-dk1-u-boot
On 4/17/24 11:09, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> Instead of using "st,fastboot-gpios" and "st,stm32prog-gpios", declare >> 2 gpio-keys. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 19 +-- >> 1 file changed, 17 insertions(+), 2 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 15/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157a-dk1-u-boot
On 4/17/24 11:09, Patrick DELAUNAY wrote:
> Hi,
>
> On 4/9/24 17:02, Patrice Chotard wrote:
>> 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
>> ---
>>
>> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> index 6bf6136c5fd..ee9b51d42b7 100644
>> --- a/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi
>> @@ -67,7 +67,6 @@
>> red {
>> label = "error";
>> gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
>> - default-state = "off";
>> status = "okay";
>> };
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH v1 16/25] ARM: dts: stm32: Update red led node for stm32mp157a-dk1-u-boot
On 4/17/24 11:10, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 ++ >> 1 file changed, 2 insertions(+), 4 deletions(-) > > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 17/25] ARM: dts: stm32: Update u-boot,boot-led for stm32mp157a-dk1-u-boot
On 4/17/24 11:10, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp157a-dk1-u-boot.dtsi | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 18/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> Add 2 gpio-keys : >> _ button-user-1 for stm32prog mode activation. >> _ button-user-2 for fastboot mode activation. >> >> Remove proprietary st,fastboot-gpios and st,stm32prog-gpios. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 19 +-- >> 1 file changed, 17 insertions(+), 2 deletions(-) >> > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 19/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 1 - >> 1 file changed, 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 20/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 21/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-u-boot
On 4/17/24 11:11, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> The blue led is used to indicate U-Boot entering / exit indication >> then Linux heartbeat. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 22/25] ARM: dts: stm32: Add gpio-keys for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:12, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> Add 2 gpio-keys : >> _ button-user-1 for stm32prog mode activation. >> _ button-user-2 for fastboot mode activation. >> >> Remove proprietary st,fastboot-gpios and st,stm32prog-gpios. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 19 +-- >> 1 file changed, 17 insertions(+), 2 deletions(-) >> > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 23/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
On 4/9/24 17:02, Patrice Chotard wrote:
> 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
> ---
>
> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> index 84920f53496..2abd512e297 100644
> --- a/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi
> @@ -37,7 +37,6 @@
> red {
> label = "error";
> gpios = <&gpioa 13 GPIO_ACTIVE_LOW>;
> - default-state = "off";
> status = "okay";
> };
> };
Applied on u-boot-stm32/master
Re: [PATCH v1 23/25] ARM: dts: stm32: Don't probe red led at boot for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:13, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 1 - >> 1 file changed, 1 deletion(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 24/25] ARM: dts: stm32: Update red led node for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:13, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> 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 >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) >> > > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH v1 25/25] ARM: dts: stm32: Add led-blue for stm32mp157c-ed1-scmi-u-boot
On 4/17/24 11:28, Patrick DELAUNAY wrote: > Hi, > > On 4/9/24 17:02, Patrice Chotard wrote: >> The blue led is used to indicate U-Boot entering / exit indication >> then Linux heartbeat. >> >> Signed-off-by: Patrice Chotard >> --- >> >> arch/arm/dts/stm32mp157c-ed1-scmi-u-boot.dtsi | 6 +- >> 1 file changed, 5 insertions(+), 1 deletion(-) >> > > Reviewed-by: Patrick Delaunay > > Thanks > Patrick > Applied on u-boot-stm32/master
Re: [PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings
On 4/17/24 13:11, Jaehoon Chung wrote:
>
>
>> -Original Message-
>> From: Patrick DELAUNAY
>> Sent: Wednesday, April 17, 2024 6:02 PM
>> To: Patrice Chotard ; u-boot@lists.denx.de
>> Cc: U-Boot STM32 ; Jaehoon Chung
>> ;
>> Peng Fan ; Sean Anderson ; Simon Glass
>> ; Tom
>> Rini
>> Subject: Re: [PATCH 2/2] mmc: stm32_sdmmc2: Fix AARCH64 compilation warnings
>>
>> Hi,
>>
>> On 3/8/24 15:26, Patrice Chotard wrote:
>>> When building with AARCH64 defconfig, we got warnings, fix them.
>>>
>>> Signed-off-by: Patrice Chotard
>>> ---
>>>
>>> drivers/mmc/stm32_sdmmc2.c | 8
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
>>> index d4982a14281..39ae79ba129 100644
>>> --- a/drivers/mmc/stm32_sdmmc2.c
>>> +++ b/drivers/mmc/stm32_sdmmc2.c
>>> @@ -220,9 +220,9 @@ static void stm32_sdmmc2_start_data(struct udevice *dev,
>>>
>>> if (data->flags & MMC_DATA_READ) {
>>> data_ctrl |= SDMMC_DCTRL_DTDIR;
>>> - idmabase0 = (u32)data->dest;
>>> + idmabase0 = (u32)(long)data->dest;
>>> } else {
>>> - idmabase0 = (u32)data->src;
>>> + idmabase0 = (u32)(long)data->src;
>>> }
>>>
>>> /* Set the SDMMC DataLength value */
>>> @@ -463,8 +463,8 @@ retry_cmd:
>>>
>>> stm32_sdmmc2_start_cmd(dev, cmd, cmdat, &ctx);
>>>
>>> - dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%x\n",
>>> - cmd->cmdidx, data ? ctx.data_length : 0, (unsigned int)data);
>>> + dev_dbg(dev, "send cmd %d data: 0x%x @ 0x%p\n",
>>> + cmd->cmdidx, data ? ctx.data_length : 0, data);
>>>
>>> ret = stm32_sdmmc2_end_cmd(dev, cmd, &ctx);
>>>
>>
>>
>>
>> Reviewed-by: Patrick Delaunay
>
> Reviewed-by: Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Thanks
>> Patrick
>
>
Applied on u-boot-stm32/master
Re: [PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2" compatible
On 4/17/24 13:10, Jaehoon Chung wrote:
> Hi
>
>> -Original Message-
>> From: Patrick DELAUNAY
>> Sent: Wednesday, April 17, 2024 6:02 PM
>> To: Patrice Chotard ; u-boot@lists.denx.de
>> Cc: U-Boot STM32 ; Jaehoon Chung
>> ;
>> Peng Fan ; Sean Anderson ; Simon Glass
>> ; Tom
>> Rini
>> Subject: Re: [PATCH 1/2] mmc: stm32_sdmmc2: Add "st,stm32mp25-sdmmc2"
>> compatible
>>
>> Hi,
>>
>> On 3/8/24 15:26, Patrice Chotard wrote:
>>> From: Patrick Delaunay
>>>
>>> Add compatible used for STM32MP25 family.
>>>
>>> Signed-off-by: Patrick Delaunay
>>> Signed-off-by: Patrice Chotard
>>> ---
>>>
>>> drivers/mmc/stm32_sdmmc2.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/mmc/stm32_sdmmc2.c b/drivers/mmc/stm32_sdmmc2.c
>>> index a2b111a8435..d4982a14281 100644
>>> --- a/drivers/mmc/stm32_sdmmc2.c
>>> +++ b/drivers/mmc/stm32_sdmmc2.c
>>> @@ -789,6 +789,7 @@ static int stm32_sdmmc2_bind(struct udevice *dev)
>>>
>>> static const struct udevice_id stm32_sdmmc2_ids[] = {
>>> { .compatible = "st,stm32-sdmmc2" },
>>> + { .compatible = "st,stm32mp25-sdmmc2" },
>>> { }
>>> };
>>>
>>
>>
>> Reviewed-by: Patrick Delaunay
>
> Reviewed-by: Jaehoon Chung
>
> Best Regards,
> Jaehoon Chung
>
>>
>> Thanks
>> Patrick
>>
>
>
Applied on u-boot-stm32/master
Re: [PATCH 2/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcor-u-boot
On 4/17/24 11:00, Patrick DELAUNAY wrote:
> Hi
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 partition node name with correct offset.
>>
>> Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for
>> stm32mp15xx-dhcom/dhcor")
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> index 552b35db3c7..ba84db679e1 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
>> @@ -42,15 +42,15 @@
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@50 {
>> + partition@8 {
>> label = "uboot";
>> reg = <0x0008 0x0016>;
>> };
>> - partition@90 {
>> + partition@1e {
>> label = "env1";
>> reg = <0x001E 0x0001>;
>> };
>> - partition@98 {
>> + partition@1f {
>> label = "env2";
>> reg = <0x001F 0x0001>;
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH 1/3] ARM: dts: stm32: Fix partition node name for stm32mp157c-ev1-u-boot
On 4/17/24 10:59, Patrick DELAUNAY wrote:
> Hi,
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 and nand@0 partition node name with correct offset.
>>
>> Fixes: e91d3c61767b ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for stm32mp15xx-ev1")
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> index 139940bd5d4..3515347e91d 100644
>> --- a/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi
>> @@ -33,11 +33,11 @@
>> label = "fsbl1";
>> reg = <0x 0x0004>;
>> };
>> - partition@8 {
>> + partition@4 {
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@10 {
>> + partition@8 {
>> label = "ssbl";
>> reg = <0x0008 0x0020>;
>> };
>> @@ -58,7 +58,7 @@
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@10 {
>> + partition@8 {
>> label = "fip";
>> reg = <0x0008 0x0040>;
>> };
>> @@ -112,7 +112,7 @@
>> label = "fip2";
>> reg = <0x0060 0x0040>;
>> };
>> - partition@120 {
>> + partition@a0 {
>> label = "UBI";
>> reg = <0x00a0 0x3f60>;
>> };
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
>
Applied on u-boot-stm32/master
Re: [PATCH 3/3] ARM: dts: stm32: Fix partition node name for stm32mp15xx-dhcom-u-boot
On 4/17/24 11:00, Patrick DELAUNAY wrote:
> Hi,
>
> On 3/8/24 14:50, Patrice Chotard wrote:
>> Fix flash@0 partition node name with correct offset.
>>
>> Fixes: 90f992e6a58c ("arm: dts: stm32: Add partitions in flash0 and nand
>> node for stm32mp15xx-dhcom/dhcor")
>>
>> Signed-off-by: Patrice Chotard
>> ---
>>
>> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> index 2f70b0690d2..1b445619325 100644
>> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
>> @@ -106,15 +106,15 @@
>> label = "fsbl2";
>> reg = <0x0004 0x0004>;
>> };
>> - partition@50 {
>> + partition@8 {
>> label = "uboot";
>> reg = <0x0008 0x0016>;
>> };
>> - partition@90 {
>> + partition@1e {
>> label = "env1";
>> reg = <0x001E 0x0001>;
>> };
>> - partition@98 {
>> + partition@1f {
>> label = "env2";
>> reg = <0x001F 0x0001>;
>> };
>
>
>
> Reviewed-by: Patrick Delaunay
>
> Thanks
> Patrick
>
Applied on u-boot-stm32/master
Re: [PATCH 2/3] mach-ipq40xx: import GPIO header from mach-snapgradon
On Thu, Apr 18, 2024 at 1:02 PM Caleb Connolly
wrote:
>
> Hi Robert,
>
> On 18/04/2024 10:14, Robert Marko wrote:
> > Pinctrl driver was refactored and moved, but the required header that
> > it depends on was not included.
>
> Thanks for these patches!
>
> I'm a bit worried about duplicating this header file, we could probably
> move it to the main include directory instead?
Hi Caleb,
That works for me as its a straight copy from mach-snapdragon.
>
> Alternatively, do you think it would be sensible to combine
> mach-snapdragon with mach-ipq40xx ?
>
> I received some patches a while ago from some Qualcomm engineers trying
> to introduce support for newer IPQ SoCs, where they also seem to want to
> build U-Boot as 32-bit (something I guess ipq40xx may also do?).
If it's possible, I would prefer to keep mach-ipq40xx separate and
probably convert it
to mach-ipq later since I would also love to see some newer SoC-s as well.
While Snapdragon and IPQ40xx are similar currently they will diverge for sure.
I dont understand why Qualcomm still insists on building the stock
U-Boot in ARMv7 32-bit
compatibility mode for all of the Cortex-A53 based IPQ807x/60xx/50xx and so on.
Regards,
Robert
>
> I'm easy either way, just want to get a better understanding of this.
>
> Kind regards,
> >
> > Fixes: 24d2908e987a ("pinctrl: qcom: move ipq4019 driver from mach-ipq40xx")
> > Signed-off-by: Robert Marko
> > ---
> > arch/arm/mach-ipq40xx/include/mach/gpio.h | 37 +++
> > 1 file changed, 31 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-ipq40xx/include/mach/gpio.h
> > b/arch/arm/mach-ipq40xx/include/mach/gpio.h
> > index a45747c0fe..53c6ae0649 100644
> > --- a/arch/arm/mach-ipq40xx/include/mach/gpio.h
> > +++ b/arch/arm/mach-ipq40xx/include/mach/gpio.h
> > @@ -1,10 +1,35 @@
> > /* SPDX-License-Identifier: GPL-2.0+ */
> > /*
> > - * Empty gpio.h
> > + * Qualcomm common pin control data.
> > *
> > - * This file must stay as arch/arm/include/asm/gpio.h requires it.
> > - *
> > - * Copyright (c) 2019 Sartura Ltd.
> > - *
> > - * Author: Robert Marko
> > + * Copyright (C) 2023 Linaro Ltd.
> > */
> > +#ifndef _QCOM_GPIO_H_
> > +#define _QCOM_GPIO_H_
> > +
> > +#include
> > +#include
> > +
> > +struct msm_pin_data {
> > + int pin_count;
> > + const unsigned int *pin_offsets;
> > + /* Index of first special pin, these are ignored for now */
> > + unsigned int special_pins_start;
> > +};
> > +
> > +static inline u32 qcom_pin_offset(const unsigned int *offs, unsigned int
> > selector)
> > +{
> > + u32 out = (selector * 0x1000);
> > +
> > + if (offs)
> > + return out + offs[selector];
> > +
> > + return out;
> > +}
> > +
> > +static inline bool qcom_is_special_pin(const struct msm_pin_data *pindata,
> > unsigned int pin)
> > +{
> > + return pindata->special_pins_start && pin >=
> > pindata->special_pins_start;
> > +}
> > +
> > +#endif /* _QCOM_GPIO_H_ */
>
> --
> // Caleb (they/them)
--
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
1 Zagreb, Croatia
Email: robert.ma...@sartura.hr
Web: www.sartura.hr
Re: [PATCH 1/1] efi_loader: superfluous efi_restore_gd after EFI_CALL
On Fri, 19 Apr 2024 at 12:59, Heinrich Schuchardt wrote: > > EFI_CALL() invokes __efi_entry_check() which executes set_gd(efi_gd). > There is no need to execute set_gd(efi_gd) again via efi_restore_gd(). > > Signed-off-by: Heinrich Schuchardt > --- > cmd/bootefi.c | 1 - > cmd/efidebug.c | 2 -- > lib/efi_loader/efi_helper.c | 2 -- > 3 files changed, 5 deletions(-) > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > index 578dbb19a7e..c1454ffb948 100644 > --- a/cmd/bootefi.c > +++ b/cmd/bootefi.c > @@ -107,7 +107,6 @@ static int do_efi_selftest(void) > > /* Execute the test */ > ret = EFI_CALL(efi_selftest(&image_obj->header, &systab)); > - efi_restore_gd(); > free(loaded_image_info->load_options); > efi_free_pool(test_device_path); > efi_free_pool(test_image_path); > diff --git a/cmd/efidebug.c b/cmd/efidebug.c > index 32c64711b6c..30def6b6831 100644 > --- a/cmd/efidebug.c > +++ b/cmd/efidebug.c > @@ -1466,8 +1466,6 @@ static __maybe_unused int do_efi_test_bootmgr(struct > cmd_tbl *cmdtp, int flag, > if (ret && exit_data) > efi_free_pool(exit_data); > > - efi_restore_gd(); > - > free(load_options); > return CMD_RET_SUCCESS; > } > diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c > index 58761fae784..88c3586787e 100644 > --- a/lib/efi_loader/efi_helper.c > +++ b/lib/efi_loader/efi_helper.c > @@ -544,8 +544,6 @@ efi_status_t do_bootefi_exec(efi_handle_t handle, void > *load_options) > } > } > > - efi_restore_gd(); > - > out: > free(load_options); > > -- > 2.43.0 > Reviewed-by: Ilias Apalodimas
Re: [PATCH v2 0/7] Tegra panel improvements
On Fri, Apr 19, 2024 at 02:29:20PM +0300, Svyatoslav Ryhel wrote: > Hello Tom! This patch set is hanging in patchwork for 3 month > without any comments. If no one has anything to say, may you > pick it into master? There's a number of video related patches outstanding currently, Anatolij will you be able to put together a PR soon? Thanks. > > Best regards, > Svyatoslav R. > > ср, 31 січ. 2024 р. о 08:57 Svyatoslav Ryhel пише: > > > > The current patch set improves the logic of existing panels and > > bridge used by Tegra 3 devices and brings support for additional > > DSI panels used by Tegra 4 devices. > > > > New and existing drivers are fully reusable, contain no device > > specific parts, and are written according to existing datasheets. > > > > --- > > Changes from v1: > > - improved ssd2825 code style > > - added TC358768 RGB to DSI bridge bringup commit (used by TF700T) > > - added Parade DP501 transmitter bringup (used by Lenovo Ideapad Yoga 11) > > --- > > > > Anton Bambura (1): > > video: panel: add Samsung LTL106HL02 MIPI DSI panel driver > > > > Jonas Schwöbel (1): > > video: bridge: add basic support for the Parade DP501 transmitter > > > > Svyatoslav Ryhel (5): > > video: panel: add LG LG070WX3 MIPI DSI panel driver > > video: bridge: add Toshiba TC358768 RGB to DSI bridge support > > video: endeavoru-panel: shift the init sequence by one step earlier > > video: bridge: ssd2825: shift the init sequence by one step earlier > > video: renesas: shift the init sequence by one step earlier > > > > drivers/video/Kconfig | 17 + > > drivers/video/Makefile | 2 + > > drivers/video/bridge/Kconfig | 19 + > > drivers/video/bridge/Makefile | 2 + > > drivers/video/bridge/dp501.c | 579 + > > drivers/video/bridge/ssd2825.c | 86 +-- > > drivers/video/bridge/tc358768.c| 985 + > > drivers/video/endeavoru-panel.c| 128 ++-- > > drivers/video/lg-ld070wx3.c| 186 ++ > > drivers/video/renesas-r61307.c | 93 +-- > > drivers/video/renesas-r69328.c | 81 +-- > > drivers/video/samsung-ltl106hl02.c | 157 + > > 12 files changed, 2155 insertions(+), 180 deletions(-) > > create mode 100644 drivers/video/bridge/dp501.c > > create mode 100644 drivers/video/bridge/tc358768.c > > create mode 100644 drivers/video/lg-ld070wx3.c > > create mode 100644 drivers/video/samsung-ltl106hl02.c > > > > -- > > 2.40.1 > > -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] mach-snapdragon: use OF_UPSTREAM
On 18/04/2024 19:24, Caleb Connolly wrote: Switch to using upstream DT from dts/upstream. Signed-off-by: Caleb Connolly --- MAINTAINERS | 4 arch/arm/Kconfig | 1 + configs/dragonboard410c_defconfig | 2 +- configs/dragonboard820c_defconfig | 2 +- configs/qcom_defconfig| 2 +- 5 files changed, 4 insertions(+), 7 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index c0d2b5138fca..d0a4a28b401d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -605,12 +605,8 @@ M: Neil Armstrong R:Sumit Garg L:u-boot-q...@groups.io S:Maintained T:git https://source.denx.de/u-boot/custodians/u-boot-snapdragon.git -F: arch/arm/dts/msm8*.dtsi -F: arch/arm/dts/pm8???.dtsi -F: arch/arm/dts/pms405.dtsi -F: arch/arm/dts/sdm845.dtsi F:drivers/*/*/pm8???-* F:drivers/gpio/msm_gpio.c F:drivers/mmc/msm_sdhci.c F:drivers/phy/msm8916-usbh-phy.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 23ee25269a24..2931c82eb11f 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1088,8 +1088,9 @@ config ARCH_SNAPDRAGON select BOARD_LATE_INIT select OF_BOARD select SAVE_PREV_BL_FDT_ADDR select LINUX_KERNEL_IMAGE_HEADER + imply OF_UPSTREAM imply CMD_DM config ARCH_SOCFPGA bool "Altera SOCFPGA family" diff --git a/configs/dragonboard410c_defconfig b/configs/dragonboard410c_defconfig index 260a8349d3b2..9ef04fd45546 100644 --- a/configs/dragonboard410c_defconfig +++ b/configs/dragonboard410c_defconfig @@ -8,9 +8,9 @@ CONFIG_SYS_MALLOC_LEN=0x802000 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8007fff0 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x0 -CONFIG_DEFAULT_DEVICE_TREE="apq8016-sbc" +CONFIG_DEFAULT_DEVICE_TREE="qcom/apq8016-sbc" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 410C" CONFIG_SYS_LOAD_ADDR=0x8008 CONFIG_REMAKE_ELF=y diff --git a/configs/dragonboard820c_defconfig b/configs/dragonboard820c_defconfig index ebc80eb2a464..f6b2cb09ba31 100644 --- a/configs/dragonboard820c_defconfig +++ b/configs/dragonboard820c_defconfig @@ -6,9 +6,9 @@ CONFIG_TEXT_BASE=0x8008 CONFIG_SYS_MALLOC_LEN=0x804000 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8007fff0 CONFIG_ENV_SIZE=0x4000 -CONFIG_DEFAULT_DEVICE_TREE="apq8096-db820c" +CONFIG_DEFAULT_DEVICE_TREE="qcom/apq8096-db820c" CONFIG_IDENT_STRING="\nQualcomm-DragonBoard 820C" CONFIG_SYS_LOAD_ADDR=0x8008 CONFIG_DISTRO_DEFAULTS=y CONFIG_USE_BOOTARGS=y diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index ee3ed89cbc8a..218a9a769682 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -1,9 +1,9 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_POSITION_INDEPENDENT=y CONFIG_ARCH_SNAPDRAGON=y -CONFIG_DEFAULT_DEVICE_TREE="sdm845-db845c" +CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c" CONFIG_SYS_LOAD_ADDR=0x0 CONFIG_BUTTON_CMD=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y Reviewed-by: Neil Armstrong
Re: [PATCH 2/3] arm: dts: drop qcom dts files
On 18/04/2024 19:24, Caleb Connolly wrote: These files are all identical (or older) than those in dts/upstream. Drop them as we now use upstream DTS files with OF_UPSTREAM. Signed-off-by: Caleb Connolly --- arch/arm/dts/apq8016-sbc.dts| 729 arch/arm/dts/apq8096-db820c.dts | 1137 -- arch/arm/dts/msm8916-pm8916.dtsi| 157 - arch/arm/dts/msm8916.dtsi | 2702 - arch/arm/dts/msm8996.dtsi | 3884 -- arch/arm/dts/pm8916.dtsi| 178 - arch/arm/dts/pm8994.dtsi| 152 - arch/arm/dts/pm8998.dtsi| 130 - arch/arm/dts/pmi8994.dtsi | 65 - arch/arm/dts/pmi8998.dtsi | 98 - arch/arm/dts/pms405.dtsi| 149 - arch/arm/dts/qcs404-evb-4000.dts| 96 - arch/arm/dts/qcs404-evb.dtsi| 389 -- arch/arm/dts/qcs404.dtsi| 1829 - arch/arm/dts/sdm845-db845c.dts | 1190 -- arch/arm/dts/sdm845-samsung-starqltechn.dts | 460 --- arch/arm/dts/sdm845-wcd9340.dtsi| 86 - arch/arm/dts/sdm845.dtsi| 5752 --- 18 files changed, 19183 deletions(-) Reviewed-by: Neil Armstrong
Re: [PATCH 3/3] qcom_defconfig: set SYS_INIT_SP_BSS_OFFSET
On 18/04/2024 19:24, Caleb Connolly wrote: Give us lots of room for the appended FDT. Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 218a9a769682..7b589f0bf7a7 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -3,8 +3,9 @@ CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_POSITION_INDEPENDENT=y CONFIG_ARCH_SNAPDRAGON=y CONFIG_DEFAULT_DEVICE_TREE="qcom/sdm845-db845c" CONFIG_SYS_LOAD_ADDR=0x0 +CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864 CONFIG_BUTTON_CMD=y CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_BOOTSTD_FULL=y Reviewed-by: Neil Armstrong
Re: [PATCH v4 2/3] dt-bindings: drop generic headers
On 18/04/2024 20:39, Caleb Connolly wrote: Drop all the subsystem headers that are compatible with the headers in dts/upstream. Signed-off-by: Caleb Connolly --- include/dt-bindings/ata/ahci.h | 20 - include/dt-bindings/gpio/gpio.h| 42 -- include/dt-bindings/input/gpio-keys.h | 13 - include/dt-bindings/input/input.h | 17 - include/dt-bindings/input/linux-event-codes.h | 806 - include/dt-bindings/interrupt-controller/irq.h | 19 - include/dt-bindings/leds/common.h | 106 include/dt-bindings/mux/mux.h | 17 - include/dt-bindings/phy/phy.h | 26 - include/dt-bindings/pwm/pwm.h | 14 - include/dt-bindings/spmi/spmi.h| 10 - include/dt-bindings/thermal/thermal.h | 15 - include/dt-bindings/usb/pd.h | 88 --- 13 files changed, 1193 deletions(-) Reviewed-by: Neil Armstrong
Re: [PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM
On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut wrote:
>
> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> > Hi Tim,
> >
> > On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey wrote:
> >
> >> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> >> following in the SPL?
> >> Couldn't bind rng driver (-96)
> >> SEC0: RNG instantiated
> >>
> >> sec_init failed!
> >
> > Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >
> > U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57 -0300)
> > No pmic
> > Couldn't bind rng driver (-96)
> > SEC0: RNG instantiated
> >
> > sec_init failed!
>
> Interesting. Which TFA blob version do you use ? I used the mainline
> 2.10 for my tests.
Marek,
Were you able to reproduce this as well with the board you enabled
DM_RNG for? If it does work fine what dtb were you using... perhaps
there is something in its u-boot.dtsi that we need?
The error -EPFNOSUPPORT is interesting and helps point to the only
place it can be where the comment says the strange errno is to make
this easier to find:
https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
if (!uc_drv) {
debug("Cannot find uclass for id %d: please add the
UCLASS_DRIVER() declaration for this UCLASS_... id\n",
id);
/*
* Use a strange error to make this case easier to find. When
* a uclass is not available it can prevent driver model from
* starting up and this failure is otherwise hard to debug.
*/
return -EPFNOSUPPORT;
}
I'm not very familiar with the dm driver binding - does the
U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
Honestly I don't know why we need DM_RNG in SPL anyway and we could
just add support for disabling it there to avoid unwanted bloat.
Tim
Re: [PATCH v4 0/7] Add SE HMBSC board support
Hi Caleb, On Fri, 12 Apr 2024 at 02:54, Sumit Garg wrote: > > SE HMIBSC board is based on Qcom APQ8016 SoC. One of the major > difference from db410c is serial port where HMIBSC board uses UART1 as > the debug console with an RS232 port, patch #2 - #5 adds corresponding > driver support. > > Patch #6 adds main HMIBSC board specific bits, features: > - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306) > - 2GiB RAM > - 64GiB eMMC, SD slot > - WiFi and Bluetooth > - 2x Host, 1x Device USB port > - HDMI > - Discrete TPM2 chip over SPI > > Features enabled in U-Boot: > - RAUC updates (refer [2] for more details) > - Environment protection > - USB based ethernet adaptors > > Feedback is very much welcome. > > Changes in v4: > - Rebased on top of qcom-main [4]. > - Split out board DTS patch as #6. > - Convert to text based environment as hmibsc.env. > - MMC regression has been reported for qcom-main branch here [5]. > - Collected further review tag. I haven't seen any further comments on this series. Can you help pick it up? -Sumit > > Changes in v3: > - Rebased on top of qcom-next [1]. > - Collected some review tags. > - Incorporated misc. comments from Caleb and Stephen. > - Split patch#4 as requested. > - Linux HMIBSC board DTS has already been reviewed here [3], I have > incorporated that for U-Boot too. > > Changes in v2: > - Rebased on top on qcom-next [1]. > - Added patch#1 as a fix for generic qcom board support. > - Added patch#4 to enable driving GPIO pins based on pinctrl > configuration. This replaces the custom GPIO configuration. > - Added proper DTS file for HMIBSC board based on Linux DT pattern. > - Merged board support patches into a single patch#5. > > [1] > https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-next?ref_type=heads > [2] https://rauc.readthedocs.io/en/latest/ > [3] > https://lore.kernel.org/linux-kernel/20240403043416.3800259-4-sumit.g...@linaro.org/ > [4] > https://source.denx.de/u-boot/custodians/u-boot-snapdragon/-/commits/qcom-main/?ref_type=heads > [5] > https://lore.kernel.org/all/cafa6wyo+3vroudfuvh390taviqx8pmqroqdtsn0yu6bd5yy...@mail.gmail.com/ > > Sumit Garg (7): > qcom: Don't enable LINUX_KERNEL_IMAGE_HEADER by default > apq8016: Add support for UART1 clocks and pinmux > serial_msm: Enable RS232 flow control > pinctrl: qcom: Add support for driving GPIO pins output > pinctrl: qcom: apq8016: Add GPIO pinctrl function > arm: dts: qcom: Add Schneider HMIBSC board dts > board: add support for Schneider HMIBSC board > > arch/arm/Kconfig | 2 +- > arch/arm/dts/apq8016-schneider-hmibsc.dts | 491 ++ > board/schneider/hmibsc/MAINTAINERS| 6 + > board/schneider/hmibsc/hmibsc.env | 40 ++ > configs/hmibsc_defconfig | 87 > doc/board/index.rst | 1 + > doc/board/schneider/hmibsc.rst| 45 ++ > doc/board/schneider/index.rst | 9 + > drivers/clk/qcom/clock-apq8016.c | 38 +- > drivers/pinctrl/qcom/pinctrl-apq8016.c| 2 + > drivers/pinctrl/qcom/pinctrl-qcom.c | 25 +- > drivers/serial/serial_msm.c | 24 +- > include/configs/hmibsc.h | 16 + > 13 files changed, 760 insertions(+), 26 deletions(-) > create mode 100644 arch/arm/dts/apq8016-schneider-hmibsc.dts > create mode 100644 board/schneider/hmibsc/MAINTAINERS > create mode 100644 board/schneider/hmibsc/hmibsc.env > create mode 100644 configs/hmibsc_defconfig > create mode 100644 doc/board/schneider/hmibsc.rst > create mode 100644 doc/board/schneider/index.rst > create mode 100644 include/configs/hmibsc.h > > -- > 2.34.1 >
[PATCH v3 1/3] clk: imx8mm: Add support for PCIe clocks
Add support for PCIe clocks required to enable PCIe support on
iMX8MM SoC.
Signed-off-by: Tim Harvey
---
v3: wrap pcie clk config around IS_ENABLED to avoid SPL growth as
suggested by Marek
---
drivers/clk/imx/clk-imx8mm.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
index b5c253e49663..1a00dd1d287b 100644
--- a/drivers/clk/imx/clk-imx8mm.c
+++ b/drivers/clk/imx/clk-imx8mm.c
@@ -66,6 +66,17 @@ static const char *imx8mm_i2c3_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
static const char *imx8mm_i2c4_sels[] = {"clock-osc-24m", "sys_pll1_160m",
"sys_pll2_50m", "sys_pll3_out", "audio_pll1_out",
"video_pll1_out", "audio_pll2_out",
"sys_pll1_133m", };
+#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
+static const char *imx8mm_pcie1_ctrl_sels[] = {"clock-osc-24m",
"sys_pll2_250m", "sys_pll2_200m", "sys_pll1_266m",
+ "sys_pll1_800m",
"sys_pll2_500m", "sys_pll2_333m", "sys_pll3_out", };
+
+static const char *imx8mm_pcie1_phy_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "sys_pll2_500m", "clk_ext1", "clk_ext2",
+ "clk_ext3", "clk_ext4",
"sys_pll1_400m", };
+
+static const char *imx8mm_pcie1_aux_sels[] = {"clock-osc-24m",
"sys_pll2_200m", "sys_pll2_50m", "sys_pll3_out",
+ "sys_pll2_100m", "sys_pll1_80m",
"sys_pll1_160m", "sys_pll1_200m", };
+#endif
+
#ifndef CONFIG_SPL_BUILD
static const char *imx8mm_pwm1_sels[] = {"clock-osc-24m", "sys_pll2_100m",
"sys_pll1_160m", "sys_pll1_40m",
"sys_pll3_out", "clk_ext1",
"sys_pll1_80m", "video_pll1_out", };
@@ -256,6 +267,17 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx8m_clk_composite("usb_bus", imx8mm_usb_bus_sels, base +
0x8b80));
/* IP */
+#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
+ clk_dm(IMX8MM_CLK_PCIE1_CTRL,
+ imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels,
+ base + 0xa300));
+ clk_dm(IMX8MM_CLK_PCIE1_PHY,
+ imx8m_clk_composite("pcie1_phy", imx8mm_pcie1_phy_sels,
+ base + 0xa380));
+ clk_dm(IMX8MM_CLK_PCIE1_AUX,
+ imx8m_clk_composite("pcie1_aux", imx8mm_pcie1_aux_sels,
+ base + 0xa400));
+#endif
clk_dm(IMX8MM_CLK_USDHC1,
imx8m_clk_composite("usdhc1", imx8mm_usdhc1_sels,
base + 0xac00));
@@ -339,6 +361,11 @@ static int imx8mm_clk_probe(struct udevice *dev)
imx_clk_gate4("pwm4_root_clk", "pwm4", base + 0x42b0, 0));
#endif
+#if CONFIG_IS_ENABLED(PCIE_DW_IMX)
+ clk_dm(IMX8MM_CLK_PCIE1_ROOT,
+ imx_clk_gate4("pcie1_root_clk", "pcie1_ctrl", base + 0x4250, 0));
+#endif
+
#if CONFIG_IS_ENABLED(DM_SPI)
clk_dm(IMX8MM_CLK_ECSPI1,
imx8m_clk_composite("ecspi1", imx8mm_ecspi1_sels, base +
0xb280));
--
2.25.1
[PATCH v3 2/3] pci: dw_imx: add support for IMX8MM
Add support for the IMX8MM SoC by adding driver data with the compatible
string of the GPR controller.
Reviewed-by: Marek Vasut
Signed-off-by: Tim Harvey
---
v3: collected tags
v2: do not cache chip info in priv per Marek's suggestion
---
drivers/pci/pcie_dw_imx.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie_dw_imx.c b/drivers/pci/pcie_dw_imx.c
index a2ee228224b5..fdb463710ba1 100644
--- a/drivers/pci/pcie_dw_imx.c
+++ b/drivers/pci/pcie_dw_imx.c
@@ -56,6 +56,18 @@ struct pcie_dw_imx {
struct udevice *vpcie;
};
+struct pcie_chip_info {
+ const char *gpr;
+};
+
+static const struct pcie_chip_info imx8mm_chip_info = {
+ .gpr = "fsl,imx8mm-iomuxc-gpr",
+};
+
+static const struct pcie_chip_info imx8mp_chip_info = {
+ .gpr = "fsl,imx8mp-iomuxc-gpr",
+};
+
static void pcie_dw_configure(struct pcie_dw_imx *priv, u32 cap_speed)
{
dw_pcie_dbi_write_enable(&priv->dw, true);
@@ -242,6 +254,7 @@ static int pcie_dw_imx_remove(struct udevice *dev)
static int pcie_dw_imx_of_to_plat(struct udevice *dev)
{
+ struct pcie_chip_info *info = (void *)dev_get_driver_data(dev);
struct pcie_dw_imx *priv = dev_get_priv(dev);
ofnode gpr;
int ret;
@@ -287,7 +300,7 @@ static int pcie_dw_imx_of_to_plat(struct udevice *dev)
goto err_phy;
}
- gpr = ofnode_by_compatible(ofnode_null(), "fsl,imx8mp-iomuxc-gpr");
+ gpr = ofnode_by_compatible(ofnode_null(), info->gpr);
if (ofnode_equal(gpr, ofnode_null())) {
dev_err(dev, "unable to find GPR node\n");
ret = -ENODEV;
@@ -322,7 +335,8 @@ static const struct dm_pci_ops pcie_dw_imx_ops = {
};
static const struct udevice_id pcie_dw_imx_ids[] = {
- { .compatible = "fsl,imx8mp-pcie" },
+ { .compatible = "fsl,imx8mm-pcie", .data = (ulong)&imx8mm_chip_info, },
+ { .compatible = "fsl,imx8mp-pcie", .data = (ulong)&imx8mp_chip_info, },
{ }
};
--
2.25.1
[PATCH v3 3/3] imx8mm_venice_defconfig: Enable PCIe/NVMe support
Enable PCIe/NVMe support. Also, enable the reset driver which is a prerequisite for PCIe support. Signed-off-by: Tim Harvey --- v3: no changes v2: no changes --- configs/imx8mm_venice_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index 517b70b69477..0f97b4b84243 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -12,6 +12,7 @@ CONFIG_DEFAULT_DEVICE_TREE="freescale/imx8mm-venice-gw71xx-0x" CONFIG_SPL_TEXT_BASE=0x7E1000 CONFIG_TARGET_IMX8MM_VENICE=y CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_DM_RESET=y CONFIG_SYS_MONITOR_LEN=524288 CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y @@ -20,6 +21,7 @@ CONFIG_SPL_STACK=0x92 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x3f8000 CONFIG_SYS_LOAD_ADDR=0x4820 +CONFIG_PCI=y CONFIG_SYS_MEMTEST_START=0x4000 CONFIG_SYS_MEMTEST_END=0x8000 CONFIG_FIT=y @@ -60,6 +62,7 @@ CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_USB=y CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_DHCP6=y @@ -120,6 +123,9 @@ CONFIG_PHY_GIGE=y CONFIG_FEC_MXC=y CONFIG_KSZ9477=y CONFIG_MII=y +CONFIG_NVME_PCI=y +CONFIG_PCIE_DW_IMX=y +CONFIG_PHY_IMX8M_PCIE=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y CONFIG_PINCTRL_IMX8M=y -- 2.25.1
Re: [PATCH v6 03/18] video: tegra20: consolidate DC header
On Tue Jan 23, 2024 at 6:16 PM CET, Svyatoslav Ryhel wrote: > Consolidate HD headers and place the result into video/tegra20 Was this supposed to be "DC" headers like in the subject? Other than that this makes sense, so: Reviewed-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v6 18/18] video: tegra20: dsi: use set_backlight for backlight only
On Tue Jan 23, 2024 at 6:16 PM CET, Svyatoslav Ryhel wrote: > From: Jonas Schwöbel > > Shift the backlight set further to prevent visual glitches on > panel init. > > Signed-off-by: Jonas Schwöbel > Signed-off-by: Svyatoslav Ryhel > --- > drivers/video/tegra20/tegra-dsi.c | 10 -- > 1 file changed, 4 insertions(+), 6 deletions(-) I vaguely recall that some devices may have had the panel and the backlight hooked up to the same regulator or enable GPIO, so calling panel_set_backlight() too late may cause the DSI panel to malfunction. That said, I'm not familiar with panel_set_backlight(), so perhaps it always only sets the brightness and the power may already be on earlier? Ah... nevermind... I see that panel_enable_backlight() is called prior to panel_set_backlight(), so this looks like it should be fine. Reviewed-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v6 06/18] video: tegra20: dc: add reset support
On Tue Jan 23, 2024 at 6:16 PM CET, Svyatoslav Ryhel wrote:
> Implement reset use to discard any changes which could have been
> applied to DC before and can interfere with current configuration.
>
> Tested-by: Agneli # Toshiba AC100 T20
> Tested-by: Robert Eckelmann # ASUS TF101
> Tested-by: Andreas Westman Dorcsak # ASUS Grouper E1565
> Tested-by: Ion Agorria # HTC One X
> Tested-by: Svyatoslav Ryhel # Nvidia Tegratab T114
> Signed-off-by: Svyatoslav Ryhel
> ---
> drivers/video/tegra20/tegra-dc.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/video/tegra20/tegra-dc.c
> b/drivers/video/tegra20/tegra-dc.c
> index 56a23b3c97..35abb6fe46 100644
> --- a/drivers/video/tegra20/tegra-dc.c
> +++ b/drivers/video/tegra20/tegra-dc.c
> @@ -10,7 +10,9 @@
> #include
> #include
> #include
> +#include
> #include
> +#include
> #include
> #include
> #include
> @@ -342,6 +344,7 @@ static int tegra_lcd_probe(struct udevice *dev)
> struct video_uc_plat *plat = dev_get_uclass_plat(dev);
> struct video_priv *uc_priv = dev_get_uclass_priv(dev);
> struct tegra_lcd_priv *priv = dev_get_priv(dev);
> + struct reset_ctl reset_ctl;
> int ret;
>
> /* Initialize the Tegra display controller */
> @@ -349,6 +352,20 @@ static int tegra_lcd_probe(struct udevice *dev)
> funcmux_select(PERIPH_ID_DISP1, FUNCMUX_DEFAULT);
> #endif
>
> + ret = reset_get_by_name(dev, "dc", &reset_ctl);
> + if (ret) {
> + log_err("reset_get_by_name() failed: %d\n", ret);
> + return ret;
> + }
> +
> + clock_disable(priv->dc_clk[0]);
> +
> + /* Reset everything set before */
> + reset_assert(&reset_ctl);
> + mdelay(4);
> + reset_deassert(&reset_ctl);
> + mdelay(4);
Are you sure this works as intended? It's been a long time since I
worked on this, but I seem to recall that most of these resets are
actually synchronous, so in order for them to do what they're supposed
to the clock needs to be kept running.
The Linux driver certainly does this differently.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH v6 13/18] video: tegra20: add MIPI calibration driver
On Tue Jan 23, 2024 at 6:16 PM CET, Svyatoslav Ryhel wrote: > Dedicated MIPI calibration driver is used on T114 and newer. Before > T114 MIPI calibration registers were part of VI and CSI. > > Tested-by: Svyatoslav Ryhel # Nvidia Tegratab T114 > Signed-off-by: Svyatoslav Ryhel > --- > drivers/video/tegra20/Makefile | 2 +- > drivers/video/tegra20/tegra-mipi.c | 188 + > 2 files changed, 189 insertions(+), 1 deletion(-) > create mode 100644 drivers/video/tegra20/tegra-mipi.c This looks like an adequate copy of what we have in the Linux kernel. It's slightly suboptimal because most of the register values are hard- coded for Tegra114, but I guess that can always be improved later on. Reviewed-by: Thierry Reding signature.asc Description: PGP signature
[PATCH 0/5] Update PHYTEC SOM Detection
This patch series extends PHYTEC's SOM detection by minor fixes, a generic helper function and a new valid flag. Moreover, it adds a module to provide access to the SOM detection for our TI AM6 products. Daniel Schultz (3): board: phytec: common: Generic "add extension" function board: phytec: common: Fix eepom is empty check board: phytec: Add SOM detection for AM6x Yannic Moog (2): board: phytec: introduce eeprom struct member 'valid' board: phytec: check eeprom_data validity board/phytec/common/Kconfig| 18 +++ board/phytec/common/Makefile | 1 + board/phytec/common/am6_som_detection.c| 159 + board/phytec/common/am6_som_detection.h| 36 + board/phytec/common/imx8m_som_detection.c | 13 +- board/phytec/common/phytec_som_detection.c | 97 + board/phytec/common/phytec_som_detection.h | 16 ++- board/phytec/phycore_am62x/Kconfig | 4 + board/phytec/phycore_am64x/Kconfig | 4 + 9 files changed, 314 insertions(+), 34 deletions(-) create mode 100644 board/phytec/common/am6_som_detection.c create mode 100644 board/phytec/common/am6_som_detection.h -- 2.25.1
[PATCH 1/5] board: phytec: common: Generic "add extension" function
Add a generic function to apply overlays in our board code to not
implement the same logic in different PHYTEC products.
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 33 ++
board/phytec/common/phytec_som_detection.h | 5
2 files changed, 38 insertions(+)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index a56e0f60d62..d167a77c25b 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include "phytec_som_detection.h"
@@ -213,6 +215,28 @@ u8 __maybe_unused phytec_get_som_type(struct
phytec_eeprom_data *data)
return data->data.data_api2.som_type;
}
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+struct extension *phytec_add_extension(const char *name, const char *overlay,
+ const char *other)
+{
+ struct extension *extension;
+
+ if (strlen(overlay) > sizeof(extension->overlay)) {
+ pr_err("Overlay name %s is longer than %lu.\n", overlay,
+ sizeof(extension->overlay));
+ return NULL;
+ }
+
+ extension = calloc(1, sizeof(struct extension));
+ snprintf(extension->name, sizeof(extension->name), name);
+ snprintf(extension->overlay, sizeof(extension->overlay), overlay);
+ snprintf(extension->other, sizeof(extension->other), other);
+ snprintf(extension->owner, sizeof(extension->owner), "PHYTEC");
+
+ return extension;
+}
+#endif /* IS_ENABLED(CONFIG_CMD_EXTENSION) */
+
#else
inline int phytec_eeprom_data_setup(struct phytec_eeprom_data *data,
@@ -253,4 +277,13 @@ u8 __maybe_unused phytec_get_som_type(struct
phytec_eeprom_data *data)
return PHYTEC_EEPROM_INVAL;
}
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+inline struct extension *phytec_add_extension(const char *name,
+ const char *overlay,
+ const char *other)
+{
+ return NULL;
+}
+#endif /* IS_ENABLED(CONFIG_CMD_EXTENSION) */
+
#endif /* IS_ENABLED(CONFIG_PHYTEC_SOM_DETECTION) */
diff --git a/board/phytec/common/phytec_som_detection.h
b/board/phytec/common/phytec_som_detection.h
index 7edbfa3ca5c..ea99a687fee 100644
--- a/board/phytec/common/phytec_som_detection.h
+++ b/board/phytec/common/phytec_som_detection.h
@@ -76,4 +76,9 @@ char * __maybe_unused phytec_get_opt(struct
phytec_eeprom_data *data);
u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data *data);
u8 __maybe_unused phytec_get_som_type(struct phytec_eeprom_data *data);
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+struct extension *phytec_add_extension(const char *name, const char *overlay,
+ const char *other);
+#endif /* IS_ENABLED(CONFIG_CMD_EXTENSION) */
+
#endif /* _PHYTEC_SOM_DETECTION_H */
--
2.25.1
[PATCH 2/5] board: phytec: introduce eeprom struct member 'valid'
From: Yannic Moog
Add a new nember to the eeprom_data that indicates whether the
associated data is valid or not. Make use of this new member in the
phytec_eeprom_data_init function by setting the valid value
appropriately.
Move the eeprom data to a new struct payload that holds
the payload of the eeprom.
Signed-off-by: Yannic Moog
Signed-off-by: Daniel Schultz
---
board/phytec/common/imx8m_som_detection.c | 10 ++--
board/phytec/common/phytec_som_detection.c | 56 --
board/phytec/common/phytec_som_detection.h | 11 +++--
3 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/board/phytec/common/imx8m_som_detection.c
b/board/phytec/common/imx8m_som_detection.c
index 214b75db3b0..7571076a09e 100644
--- a/board/phytec/common/imx8m_som_detection.c
+++ b/board/phytec/common/imx8m_som_detection.c
@@ -34,10 +34,10 @@ int __maybe_unused phytec_imx8m_detect(struct
phytec_eeprom_data *data)
data = &eeprom_data;
/* We can not do the check for early API revisions */
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return -1;
- som = data->data.data_api2.som_no;
+ som = data->payload.data.data_api2.som_no;
debug("%s: som id: %u\n", __func__, som);
opt = phytec_get_opt(data);
@@ -99,7 +99,7 @@ u8 __maybe_unused phytec_get_imx8m_spi(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -126,7 +126,7 @@ u8 __maybe_unused phytec_get_imx8m_eth(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -154,7 +154,7 @@ u8 __maybe_unused phytec_get_imx8mp_rtc(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index d167a77c25b..7913764be0a 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -54,6 +54,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
int ret, i;
unsigned int crc;
int *ptr;
+ const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
if (!data)
data = &eeprom_data;
@@ -64,14 +65,13 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
ret = i2c_get_chip_for_busnum(bus_num, addr, 2, &dev);
if (ret) {
pr_err("%s: i2c EEPROM not found: %i.\n", __func__, ret);
- return ret;
+ goto err;
}
- ret = dm_i2c_read(dev, 0, (uint8_t *)data,
- sizeof(struct phytec_eeprom_data));
+ ret = dm_i2c_read(dev, 0, (uint8_t *)data, payload_size);
if (ret) {
- pr_err("%s: Unable to read EEPROM data\n", __func__);
- return ret;
+ pr_err("%s: Unable to read EEPROM data: %i\n", __func__, ret);
+ goto err;
}
#else
i2c_set_bus_num(bus_num);
@@ -79,36 +79,44 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
sizeof(struct phytec_eeprom_data));
#endif
- if (data->api_rev == 0xff) {
+ if (data->payload.api_rev == 0xff) {
pr_err("%s: EEPROM is not flashed. Prototype?\n", __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
ptr = (int *)data;
- for (i = 0; i < sizeof(struct phytec_eeprom_data); i++)
+ for (i = 0; i < payload_size; ++i)
if (ptr[i] != 0x0)
break;
- if (i == sizeof(struct phytec_eeprom_data)) {
+ if (i == payload_size) {
pr_err("%s: EEPROM data is all zero. Erased?\n", __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
/* We are done here for early revisions */
- if (data->api_rev <= PHYTEC_API_REV1)
+ if (data->payload.api_rev <= PHYTEC_API_REV1) {
+ data->valid = true;
return 0;
+ }
- crc = crc8(0, (const unsigned char *)data,
- sizeof(struct phytec_eeprom_data));
+ crc = crc8(0, (const unsigned char *)&data->payload, payload_size);
debug("%s: crc: %x\n", __func__, crc);
if (crc) {
- pr_err("%s: CRC mism
[PATCH 3/5] board: phytec: check eeprom_data validity
From: Yannic Moog
For all of the functions that access the eeprom_data, make sure these
data are valid. Use the valid member of the phytec_eeprom_data struct.
This fixes a bug where only the API revision check guarded against
accessing rubbish. But if API revision was e.g. 6, eeprom setup failed
before, but phytec_get_imx8m_eth would still happily access the data.
Fixes: dc22188cdc8 ("board: phytec: Add common PHYTEC SoM detection")
Signed-off-by: Yannic Moog
Signed-off-by: Daniel Schultz
---
board/phytec/common/imx8m_som_detection.c | 11 +++
board/phytec/common/phytec_som_detection.c | 10 +++---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/phytec/common/imx8m_som_detection.c
b/board/phytec/common/imx8m_som_detection.c
index 7571076a09e..ee34a5b9579 100644
--- a/board/phytec/common/imx8m_som_detection.c
+++ b/board/phytec/common/imx8m_som_detection.c
@@ -34,7 +34,7 @@ int __maybe_unused phytec_imx8m_detect(struct
phytec_eeprom_data *data)
data = &eeprom_data;
/* We can not do the check for early API revisions */
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return -1;
som = data->payload.data.data_api2.som_no;
@@ -75,6 +75,9 @@ u8 __maybe_unused phytec_get_imx8m_ddr_size(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
+ return PHYTEC_EEPROM_INVAL;
+
opt = phytec_get_opt(data);
if (opt)
ddr_id = PHYTEC_GET_OPTION(opt[2]);
@@ -99,7 +102,7 @@ u8 __maybe_unused phytec_get_imx8m_spi(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -126,7 +129,7 @@ u8 __maybe_unused phytec_get_imx8m_eth(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -154,7 +157,7 @@ u8 __maybe_unused phytec_get_imx8mp_rtc(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index 7913764be0a..5a4cc9e8b02 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -128,7 +128,7 @@ void __maybe_unused phytec_print_som_info(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return;
api2 = &data->payload.data.data_api2;
@@ -190,6 +190,9 @@ char * __maybe_unused phytec_get_opt(struct
phytec_eeprom_data *data)
if (!data)
data = &eeprom_data;
+ if (!data->valid)
+ return NULL;
+
if (data->payload.api_rev < PHYTEC_API_REV2)
opt = data->payload.data.data_api0.opt;
else
@@ -205,7 +208,7 @@ u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data
*data)
if (!data)
data = &eeprom_data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
api2 = &data->payload.data.data_api2;
@@ -217,7 +220,8 @@ u8 __maybe_unused phytec_get_som_type(struct
phytec_eeprom_data *data)
{
if (!data)
data = &eeprom_data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
return data->payload.data.data_api2.som_type;
--
2.25.1
[PATCH 4/5] board: phytec: common: Fix eepom is empty check
The ptr variable is currently defined as int and sizeof
returns the size of the eeprom data struct as Byte (32 in total).
In case the eeprom is empty, the check, if the eeprom is empty,
will most likely stop after 8 iterations because it will continue
with the stack which should contain some data. Therefore, the
init function will detect an empty EEPROM as API0 and return with
the valid flag set to True.
Fixes: dc22188cdc8 ("board: phytec: Add common PHYTEC SoM detection")
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index 5a4cc9e8b02..78c173df20d 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -53,7 +53,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
{
int ret, i;
unsigned int crc;
- int *ptr;
+ u8 *ptr;
const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
if (!data)
@@ -85,7 +85,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
goto err;
}
- ptr = (int *)data;
+ ptr = (u8 *)data;
for (i = 0; i < payload_size; ++i)
if (ptr[i] != 0x0)
break;
--
2.25.1
[PATCH 5/5] board: phytec: Add SOM detection for AM6x
Add all functions to read each SOM option from the EEPROM
image and detect whether it's the correct product for this
image.
Signed-off-by: Daniel Schultz
---
board/phytec/common/Kconfig | 18 +++
board/phytec/common/Makefile| 1 +
board/phytec/common/am6_som_detection.c | 159
board/phytec/common/am6_som_detection.h | 36 ++
board/phytec/phycore_am62x/Kconfig | 4 +
board/phytec/phycore_am64x/Kconfig | 4 +
6 files changed, 222 insertions(+)
create mode 100644 board/phytec/common/am6_som_detection.c
create mode 100644 board/phytec/common/am6_som_detection.h
diff --git a/board/phytec/common/Kconfig b/board/phytec/common/Kconfig
index 3b1c5aa0d02..1077f0f4b61 100644
--- a/board/phytec/common/Kconfig
+++ b/board/phytec/common/Kconfig
@@ -11,3 +11,21 @@ config PHYTEC_IMX8M_SOM_DETECTION
help
Support of I2C EEPROM based SoM detection. Supported
for PHYTEC i.MX8MM/i.MX8MP boards
+
+config PHYTEC_AM62_SOM_DETECTION
+ bool "Support SoM detection for AM62x PHYTEC platforms"
+ depends on (TARGET_PHYCORE_AM62X_A53 || TARGET_PHYCORE_AM62X_R5) && \
+ PHYTEC_SOM_DETECTION
+ default y
+ help
+ Support of I2C EEPROM based SoM detection. Supported
+ for PHYTEC AM62x boards.
+
+config PHYTEC_AM64_SOM_DETECTION
+ bool "Support SoM detection for AM64x PHYTEC platforms"
+ depends on (TARGET_PHYCORE_AM64X_A53 || TARGET_PHYCORE_AM64X_R5) && \
+ PHYTEC_SOM_DETECTION
+ default y
+ help
+ Support of I2C EEPROM based SoM detection. Supported
+ for PHYTEC AM64x boards.
diff --git a/board/phytec/common/Makefile b/board/phytec/common/Makefile
index 35c81741306..3feb00fd1ec 100644
--- a/board/phytec/common/Makefile
+++ b/board/phytec/common/Makefile
@@ -8,4 +8,5 @@ obj- := __dummy__.o
endif
obj-y += phytec_som_detection.o
+obj-$(CONFIG_ARCH_K3) += am6_som_detection.o
obj-$(CONFIG_ARCH_IMX8M) += imx8m_som_detection.o
diff --git a/board/phytec/common/am6_som_detection.c
b/board/phytec/common/am6_som_detection.c
new file mode 100644
index 000..2e9884dab44
--- /dev/null
+++ b/board/phytec/common/am6_som_detection.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2024 PHYTEC Messtechnik GmbH
+ * Author: Daniel Schultz
+ */
+
+#include
+
+#include "am6_som_detection.h"
+
+extern struct phytec_eeprom_data eeprom_data;
+
+#if IS_ENABLED(CONFIG_PHYTEC_AM62_SOM_DETECTION) || \
+ IS_ENABLED(CONFIG_PHYTEC_AM64_SOM_DETECTION)
+
+/* Check if the SoM is actually one of the following products:
+ * - phyCORE-AM62x
+ * - phyCORE-AM64x
+ *
+ * Returns 0 in case it's a known SoM. Otherwise, returns -1.
+ */
+int phytec_am6_detect(struct phytec_eeprom_data *data)
+{
+ char *opt;
+ u8 som;
+
+ if (!data)
+ data = &eeprom_data;
+
+ /* We cannot do the check for early API revisions */
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
+ return -1;
+
+ som = data->payload.data.data_api2.som_no;
+ debug("%s: som id: %u\n", __func__, som);
+
+ opt = phytec_get_opt(data);
+ if (!opt)
+ return -1;
+
+ if (som == PHYTEC_AM62X_SOM && soc_is_am62x())
+ return 0;
+
+ if (som == PHYTEC_AM64X_SOM && soc_is_am64x())
+ return 0;
+
+ return -1;
+}
+
+static u8 phytec_check_opt(struct phytec_eeprom_data *data, u8 option)
+{
+ char *opt;
+
+ if (!data)
+ data = &eeprom_data;
+
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
+ return PHYTEC_EEPROM_INVAL;
+
+ if (option > 8)
+ return PHYTEC_EEPROM_INVAL;
+
+ opt = phytec_get_opt(data);
+ if (opt)
+ return PHYTEC_GET_OPTION(opt[option]);
+ return PHYTEC_EEPROM_INVAL;
+}
+
+/*
+ * Reads LPDDR4 ram size from EEPROM.
+ *
+ * returns:
+ * - The size
+ * - PHYTEC_EEPROM_INVAL when the data is invalid.
+ */
+u8 __maybe_unused phytec_get_am62_ddr_size(struct phytec_eeprom_data *data)
+{
+ u8 ddr_id = phytec_check_opt(data, 3);
+
+ pr_debug("%s: ddr id: %u\n", __func__, ddr_id);
+ return ddr_id;
+}
+
+/*
+ * Reads SPI-NOR flash size and type from EEPROM.
+ *
+ * returns:
+ * - PHYTEC_EEPROM_VALUE_X if no SPI is poulated.
+ * - Otherwise a board depended code for the size.
+ * - PHYTEC_EEPROM_INVAL when the data is invalid.
+ */
+u8 __maybe_unused phytec_get_am62_spi(struct phytec_eeprom_data *data)
+{
+ u8 spi = phytec_check_opt(data, 5);
+
+ pr_debug("%s: spi: %u\n", __func__, spi);
+ return spi;
+}
+
+/*
+ * Reads Ethernet phy information from EEPROM.
+ *
+ * returns:
+ * - 0x0 no ethernet phy is populated.
+ * - 0x1 if 10/100/1000 MBit Phy is populated.
+ * - PHYTEC_EEPROM_INVAL when the data is invalid.
+ */
+u8 __maybe_unused phytec_get_am62_eth(struct phyt
Re: [PATCH v6 01/18] video: tegra20: dc: diverge DC per-SOC
On Tue Jan 23, 2024 at 6:16 PM CET, Svyatoslav Ryhel wrote:
[...]
> diff --git a/arch/arm/include/asm/arch-tegra114/display.h
> b/arch/arm/include/asm/arch-tegra114/display.h
> new file mode 100644
> index 00..9411525799
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-tegra114/display.h
> @@ -0,0 +1,28 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) Copyright 2010
> + * NVIDIA Corporation
> + */
> +
> +#ifndef __ASM_ARCH_TEGRA_DISPLAY_H
> +#define __ASM_ARCH_TEGRA_DISPLAY_H
> +
> +#include
> +
> +/* This holds information about a window which can be displayed */
> +struct disp_ctl_win {
> + enum win_color_depth_id fmt;/* Color depth/format */
> + unsigned intbpp;/* Bits per pixel */
> + phys_addr_t phys_addr; /* Physical address in memory */
> + unsigned intx; /* Horizontal address offset (bytes) */
> + unsigned inty; /* Veritical address offset (bytes) */
> + unsigned intw; /* Width of source window */
> + unsigned inth; /* Height of source window */
> + unsigned intstride; /* Number of bytes per line */
> + unsigned intout_x; /* Left edge of output window (col) */
> + unsigned intout_y; /* Top edge of output window (row) */
> + unsigned intout_w; /* Width of output window in pixels */
> + unsigned intout_h; /* Height of output window in pixels */
> +};
> +
> +#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/
One of the earlier patches in the series gets rid of this per-SoC header
file in favor of a common one. Did this end up here by mistake? It
doesn't seem to be used.
> diff --git a/drivers/video/tegra20/tegra-dc.c
> b/drivers/video/tegra20/tegra-dc.c
> index f53ad46397..7605e77bc1 100644
> --- a/drivers/video/tegra20/tegra-dc.c
> +++ b/drivers/video/tegra20/tegra-dc.c
> @@ -3,7 +3,6 @@
> * Copyright (c) 2011 The Chromium OS Authors.
> */
>
> -#include
> #include
> #include
> #include
> @@ -23,10 +22,15 @@
> #include
> #include
> #include
> -#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +/* Holder of Tegra per-SOC DC differences */
> +struct tegra_dc_soc_info {
> + bool has_timer;
> + bool has_rgb;
> +};
> +
> /* Information about the display controller */
> struct tegra_lcd_priv {
> int width; /* width in pixels */
> @@ -35,6 +39,7 @@ struct tegra_lcd_priv {
> struct display_timing timing;
> struct udevice *panel;
> struct dc_ctlr *dc; /* Display controller regmap */
> + const struct tegra_dc_soc_info *soc;
> fdt_addr_t frame_buffer;/* Address of frame buffer */
> unsigned pixel_clock; /* Pixel clock in Hz */
> int dc_clk[2]; /* Contains clk and its parent */
> @@ -43,8 +48,8 @@ struct tegra_lcd_priv {
>
> enum {
> /* Maximum LCD size we support */
> - LCD_MAX_WIDTH = 1920,
> - LCD_MAX_HEIGHT = 1200,
> + LCD_MAX_WIDTH = 2560,
> + LCD_MAX_HEIGHT = 1600,
> LCD_MAX_LOG2_BPP= VIDEO_BPP16,
> };
>
> @@ -110,9 +115,9 @@ static void update_window(struct tegra_lcd_priv *priv,
> writel(val, &dc->cmd.state_ctrl);
> }
>
> -static int update_display_mode(struct dc_disp_reg *disp,
> -struct tegra_lcd_priv *priv)
> +static int update_display_mode(struct tegra_lcd_priv *priv)
> {
> + struct dc_disp_reg *disp = &priv->dc->disp;
> struct display_timing *dt = &priv->timing;
> unsigned long val;
> unsigned long rate;
> @@ -128,14 +133,16 @@ static int update_display_mode(struct dc_disp_reg *disp,
> &disp->front_porch);
> writel(dt->hactive.typ | (dt->vactive.typ << 16), &disp->disp_active);
>
> - val = DE_SELECT_ACTIVE << DE_SELECT_SHIFT;
> - val |= DE_CONTROL_NORMAL << DE_CONTROL_SHIFT;
> - writel(val, &disp->data_enable_opt);
> + if (priv->soc->has_rgb) {
> + val = DE_SELECT_ACTIVE << DE_SELECT_SHIFT;
> + val |= DE_CONTROL_NORMAL << DE_CONTROL_SHIFT;
> + writel(val, &disp->data_enable_opt);
>
> - val = DATA_FORMAT_DF1P1C << DATA_FORMAT_SHIFT;
> - val |= DATA_ALIGNMENT_MSB << DATA_ALIGNMENT_SHIFT;
> - val |= DATA_ORDER_RED_BLUE << DATA_ORDER_SHIFT;
> - writel(val, &disp->disp_interface_ctrl);
> + val = DATA_FORMAT_DF1P1C << DATA_FORMAT_SHIFT;
> + val |= DATA_ALIGNMENT_MSB << DATA_ALIGNMENT_SHIFT;
> + val |= DATA_ORDER_RED_BLUE << DATA_ORDER_SHIFT;
> + writel(val, &disp->disp_interface_ctrl);
> + }
>
> /*
>* The pixel clock divider is in 7.1 format (where the bottom bit
> @@ -147,7 +154,8 @@ static int update_display_mode(struct dc_disp_reg *disp,
> div = ((rate * 2 + priv->pixel_clock / 2) / priv->pixel_clock) - 2;
> debug("Display clock %lu, divid
