Re: [PATCH v1 2/4] efi_loader: Add OS notifications for SetVariableRT in RAM
Hi Heinrich,
> > +
> >
> > /* Use internal device tree when starting UEFI application */
> > #define EFI_FDT_USE_INTERNAL NULL
> > diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> > index 8ebbea7e5c69..d898ba6c268f 100644
> > --- a/lib/efi_loader/efi_runtime.c
> > +++ b/lib/efi_loader/efi_runtime.c
> > @@ -127,10 +127,6 @@ efi_status_t efi_init_runtime_supported(void)
> > EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
> > EFI_RT_SUPPORTED_CONVERT_POINTER;
> >
> > - if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE))
> > - rt_table->runtime_services_supported |=
> > - EFI_RT_SUPPORTED_SET_VARIABLE;
> > -
>
[...]
> Why do you want to remove this flag?
>
I don't, I messed this up during my rebase before sending the patches.
The code in EBS() was supposed to re-enable it.
It's all fixed in patch #3, but this patch needs a change as well
rt_prop->runtime_services_supported |= ~EFI_RT_SUPPORTED_SET_VARIABLE;
should be
rt_prop->runtime_services_supported |= EFI_RT_SUPPORTED_SET_VARIABLE;
in efi_variables_boot_exit_notify()
Thanks
/Ilias
> Best regards
>
> Heinrich
>
> > /*
> >* This value must be synced with efi_runtime_detach_list
> >* as well as efi_runtime_services.
> > diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> > index f79041e6bedd..f97c8c57f75c 100644
> > --- a/lib/efi_loader/efi_variable.c
> > +++ b/lib/efi_loader/efi_variable.c
> > @@ -554,6 +554,26 @@ if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE)) {
> >*/
> > void efi_variables_boot_exit_notify(void)
> > {
> > + const efi_guid_t efi_guid_efi_rt_var_file =
> > U_BOOT_EFI_RT_VAR_FILE_GUID;
> > + const efi_guid_t rt_prop_guid = EFI_RT_PROPERTIES_TABLE_GUID;
> > + efi_status_t ret;
> > +
> > + if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE)) {
> > + struct efi_rt_properties_table *rt_prop =
> > + efi_get_configuration_table(&rt_prop_guid);
> > +
> > + ret = efi_set_variable_int(u"RTStorageVolatile",
> > +&efi_guid_efi_rt_var_file,
> > +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> > +EFI_VARIABLE_RUNTIME_ACCESS |
> > +EFI_VARIABLE_READ_ONLY,
> > +sizeof(EFI_VAR_FILE_NAME),
> > +EFI_VAR_FILE_NAME, false);
> > + if (ret != EFI_SUCCESS)
> > + rt_prop->runtime_services_supported |=
> > ~EFI_RT_SUPPORTED_SET_VARIABLE;
> > + else
> > + log_err("Can't RTStorage. SetVariableRT won't be
> > available\n");
> > + }
> > /* Switch variable services functions to runtime version */
> > efi_runtime_services.get_variable = efi_get_variable_runtime;
> > efi_runtime_services.get_next_variable_name =
>
Re: [PATCH v1 3/4] efi_loader: add an EFI variable with the variable file contents
On 4/6/24 16:01, Ilias Apalodimas wrote: Previous patches enabled SetVariableRT using a RAM backend. Although EBBR [0] defines a variable format we can teach userspace tools and write the altered variables, it's better if we skip the ABI requirements completely. So let's add a new variable, in its own namespace called "VarToFile" which contains a binary dump of the updated RT, BS and, NV variables. Some adjustments are needed to do that. Currently we discard BS-only variables in EBS(). We need to preserve those on the OS RAM backend that exposes the variables. Since BS-only variables can't appear at RT we need to move the memory masking checks from efi_var_collect() to efi_get_next_variable_name_mem()/efi_get_variable_mem() and do the filtering at runtime. We also need to make efi_var_collect() available at runtime, in order to construct the "VarToFile" buffer with BS, RT & NV variables. All users and applications (for linux) have to do when updating a variable is dd that variable in the file described by "RTStorageVolatile". Linux efivarfs uses a first 4 bytes of the output to represent attributes in little-endian format. So, storing variables works like this: $~ efibootmgr -n 0001 $~ dd if=/sys/firmware/efi/efivars/VarToFile-b2ac5fc9-92b7-4acd-aeac-11e818c3130c of=/boot/efi/ubootefi.var skip=4 bs=1 [0] https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage This change actually doubles the amount of memory needed to store a variable at runtime. How do you reflect this in QueryVariableInfo()? Suggested-by:Ard Biesheuvel # dumping all variables to a variable Signed-off-by: Ilias Apalodimas --- include/efi_variable.h| 15 +++- lib/efi_loader/efi_boottime.c | 2 + lib/efi_loader/efi_var_common.c | 43 +-- lib/efi_loader/efi_var_file.c | 1 - lib/efi_loader/efi_var_mem.c | 90 ++- lib/efi_loader/efi_variable.c | 118 -- lib/efi_loader/efi_variable_tee.c | 1 - 7 files changed, 164 insertions(+), 106 deletions(-) diff --git a/include/efi_variable.h b/include/efi_variable.h index 42a2b7c52bef..8963339b9bb6 100644 --- a/include/efi_variable.h +++ b/include/efi_variable.h @@ -271,13 +271,15 @@ const efi_guid_t *efi_auth_var_get_guid(const u16 *name); * * @variable_name_size: size of variable_name buffer in bytes * @variable_name:name of uefi variable's name in u16 + * @mask: bitmask with required attributes of variables to be collected. + * variables are only collected if all of the required * @vendor: vendor's guid * * Return: status code */ efi_status_t __efi_runtime efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16 *variable_name, - efi_guid_t *vendor); + efi_guid_t *vendor, u32 mask); /** * efi_get_variable_mem() - Runtime common code across efi variable * implementations for GetVariable() from @@ -289,12 +291,14 @@ efi_get_next_variable_name_mem(efi_uintn_t *variable_name_size, u16 *variable_na * @data_size:size of the buffer to which the variable value is copied * @data: buffer to which the variable value is copied * @timep:authentication time (seconds since start of epoch) + * @mask: bitmask with required attributes of variables to be collected. + * variables are only collected if all of the required This line looks incomplete. * Return:status code */ efi_status_t __efi_runtime efi_get_variable_mem(const u16 *variable_name, const efi_guid_t *vendor, u32 *attributes, efi_uintn_t *data_size, void *data, -u64 *timep); +u64 *timep, u32 mask); /** * efi_get_variable_runtime() - runtime implementation of GetVariable() @@ -334,4 +338,11 @@ efi_get_next_variable_name_runtime(efi_uintn_t *variable_name_size, */ void efi_var_buf_update(struct efi_var_file *var_buf); +/** + * efi_prealloced_rt_memory() - Get a pointer to preallocated EFI memory + * available at runtime + * + * Return: pointer to preallocated runtime usable buffer + */ +void __efi_runtime *efi_prealloced_rt_memory(void); #endif diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c index 1951291747cd..39481c89a688 100644 --- a/lib/efi_loader/efi_boottime.c +++ b/lib/efi_loader/efi_boottime.c @@ -97,6 +97,8 @@ const efi_guid_t efi_guid_load_file_protocol = EFI_LOAD_FILE_PROTOCOL_GUID; const efi_guid_t efi_guid_load_file2_protocol = EFI_LOAD_FILE2_PROTOCOL_GUID; /* GUID of the SMBIOS table */ const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID; +/* used by special U-Boot variables during SetVariableRT */ +const efi_guid_t efi_guid_efi_rt_var_file = U_BOOT_EFI_RT_VAR_FILE_GUID; st
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);
> }
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH v1 2/4] efi_loader: Add OS notifications for SetVariableRT in RAM
On 4/6/24 16:01, Ilias Apalodimas wrote:
Previous patches enable SetVariableRT using a volatile storage backend
using EFI_RUNTIME_SERVICES_DATA allocared memory. Since there's no
recommendation from the spec on how to notify the OS, add a volatile
EFI variable that contains the filename relative to the ESP. OS'es
can use that file and update it at runtime
$~ efivar -p -n b2ac5fc9-92b7-4acd-aeac-11e818c3130c-RTStorageVolatile
GUID: b2ac5fc9-92b7-4acd-aeac-11e818c3130c
Name: "RTStorageVolatile"
Attributes:
Boot Service Access
Runtime Service Access
Value:
75 62 6f 6f 74 65 66 69 2e 76 61 72 00 |ubootefi.var. |
Signed-off-by: Ilias Apalodimas
---
include/efi_loader.h | 4
lib/efi_loader/efi_runtime.c | 4
lib/efi_loader/efi_variable.c | 20
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 7daca0afba2b..25551fe18948 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -159,6 +159,10 @@ static inline void efi_set_bootdev(const char *dev, const
char *devnr,
#define EFICONFIG_AUTO_GENERATED_ENTRY_GUID \
EFI_GUID(0x8108ac4e, 0x9f11, 0x4d59, \
0x85, 0x0e, 0xe2, 0x1a, 0x52, 0x2c, 0x59, 0xb2)
+#define U_BOOT_EFI_RT_VAR_FILE_GUID \
+ EFI_GUID(0xb2ac5fc9, 0x92b7, 0x4acd, \
+0xae, 0xac, 0x11, 0xe8, 0x18, 0xc3, 0x13, 0x0c)
+
/* Use internal device tree when starting UEFI application */
#define EFI_FDT_USE_INTERNAL NULL
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 8ebbea7e5c69..d898ba6c268f 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -127,10 +127,6 @@ efi_status_t efi_init_runtime_supported(void)
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
EFI_RT_SUPPORTED_CONVERT_POINTER;
- if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE))
- rt_table->runtime_services_supported |=
- EFI_RT_SUPPORTED_SET_VARIABLE;
-
Why do you want to remove this flag?
Best regards
Heinrich
/*
* This value must be synced with efi_runtime_detach_list
* as well as efi_runtime_services.
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index f79041e6bedd..f97c8c57f75c 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -554,6 +554,26 @@ if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE)) {
*/
void efi_variables_boot_exit_notify(void)
{
+ const efi_guid_t efi_guid_efi_rt_var_file = U_BOOT_EFI_RT_VAR_FILE_GUID;
+ const efi_guid_t rt_prop_guid = EFI_RT_PROPERTIES_TABLE_GUID;
+ efi_status_t ret;
+
+ if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE)) {
+ struct efi_rt_properties_table *rt_prop =
+ efi_get_configuration_table(&rt_prop_guid);
+
+ ret = efi_set_variable_int(u"RTStorageVolatile",
+ &efi_guid_efi_rt_var_file,
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS |
+ EFI_VARIABLE_READ_ONLY,
+ sizeof(EFI_VAR_FILE_NAME),
+ EFI_VAR_FILE_NAME, false);
+ if (ret != EFI_SUCCESS)
+ rt_prop->runtime_services_supported |=
~EFI_RT_SUPPORTED_SET_VARIABLE;
+ else
+ log_err("Can't RTStorage. SetVariableRT won't be
available\n");
+ }
/* Switch variable services functions to runtime version */
efi_runtime_services.get_variable = efi_get_variable_runtime;
efi_runtime_services.get_next_variable_name =
Re: [PATCH v1 1/4] efi_loader: conditionally enable SetvariableRT
On 4/6/24 16:01, Ilias Apalodimas wrote:
When EFI variables are stored on file we don't allow SetVariableRT,
Neither in the UEFI standard nor in U-Boot we have a function SetVariableRT.
%s/SetVariableRT/SetVariable at runtime/
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariableRT we copy runtime variables in RAM and expose them to
%s/GetVariabeRT/GetVariable at runtime/
the OS. Add a Kconfig option and provide SetVariableRT using the same
memory backend. The OS will be responsible for syncing the RAM contents
to the file, otherwise any changes made during runtime won't persist
reboots.
It's worth noting that the variable store format is defined in EBBR [0]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.
- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs
(ro,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system
- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
BootNext: 0001
BootCurrent:
BootOrder: ,0001
Boot* debian
HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
Boot0001* virtio 0
VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
$~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootNext"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
01 00
[0]
https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/Kconfig| 16 +++
lib/efi_loader/efi_runtime.c | 5 +
lib/efi_loader/efi_variable.c | 114 --
.../efi_selftest_variables_runtime.c | 13 +-
4 files changed, 135 insertions(+), 13 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index a7c3e05c13a0..b210ceea6d64 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -63,6 +63,22 @@ config EFI_VARIABLE_FILE_STORE
Select this option if you want non-volatile UEFI variables to be
stored as file /ubootefi.var on the EFI system partition.
+config EFI_RT_VOLATILE_STORE
+ bool "Allow variable runtime services in volatile storage (e.g RAM)"
+ depends on EFI_VARIABLE_FILE_STORE
+ help
+ When EFI variables are stored on file we don't allow SetVariableRT,
+ since the OS doesn't know how to write that file. At he same time
+ we copy runtime variables in DRAM and support GetVariableRT
+
+ Enable this option to allow SetVariableRT on the RAM backend of
+ the EFI variable storage. The OS will be responsible for syncing
+ the RAM contents to the file, otherwise any changes made during
+ runtime won't persist reboots.
+ Authenticated variables are not supported. Note that this will
+ violate the EFI spec since writing auth variables will return
+ EFI_INVALID_PARAMETER
+
config EFI_MM_COMM_TEE
bool "UEFI variables storage service via the trusted world"
depends on OPTEE
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 18da6892e796..8ebbea7e5c69 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -126,6 +127,10 @@ efi_status_t efi_init_runtime_supported(void)
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP |
EFI_RT_SUPPORTED_CONVERT_POINTER;
+ if (IS_ENABLED(CONFIG_EFI_RT_VOLATILE_STORE))
+ rt_table->runtime_services_supported |=
+ EFI_RT_SUPPORTED_SET_VARIABLE;
+
/*
* This value must be synced with efi_runtime_detach_list
* as well as efi_runtime_services.
diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
index 6fe3792a12a5..f79041e6bedd 100644
--- a/lib/efi_loader/efi_variable.c
+++ b/lib/efi_loader/efi_variable.c
@@ -218,17 +218,20 @@ efi_get_next_variable_name_int(efi_uintn_t
*variable_name_size,
return efi_get_next_variable_name_mem(variable_name_size,
variable_name, vendor);
}
-efi_status_t efi_set_variable_int(const u16 *variable_name,
- const efi_guid_t *vendor,
-
[PATCH] configs: am335x_guardian: store boot count in AM3352 RTC block
From: Gireesh Hiremath store bootcount in RTC block scratch register Signed-off-by: Gireesh Hiremath --- configs/am335x_guardian_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am335x_guardian_defconfig b/configs/am335x_guardian_defconfig index 75138542431..a03d33d 100644 --- a/configs/am335x_guardian_defconfig +++ b/configs/am335x_guardian_defconfig @@ -16,6 +16,7 @@ CONFIG_AM335X_USB1=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y CONFIG_BOOTCOUNT_BOOTLIMIT=3 +CONFIG_SYS_BOOTCOUNT_ADDR=0x44E3E000 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x54 CONFIG_SPL_LIBDISK_SUPPORT=y -- 2.30.2
Re: [PATCH v1 0/4] Enable SetvariableRT
On 4/7/24 23:53, Mark Kettenis wrote:
From: Ilias Apalodimas
Hi all,
This is an updated version of [0].
When EFI variables are stored on file we don't allow SetVariableRT,
since the OS doesn't know how to access or write that file. At the same
time keeping the U-Boot drivers alive in runtime sections and performing
writes from the firmware is dangerous -- if at all possible.
For GetVariableRT we copy runtime variables in RAM and expose them to
the OS. Add a Kconfig option and provide SetVariableRT using the same
memory back end. The OS will be responsible for syncing the RAM contents
to the file, otherwise any changes made during runtime won't persist
reboots.
It's worth noting that the variable store format is defined in EBBR [1]
and authenticated variables are explicitly prohibited, since they have
to be stored on a medium that's tamper and rollback protected.
The original RFC was just enabling the memory back end. This is a more
complete version and we should be able, with small adjustments of
userspace tools, fix SetVariableRT. If enabled the firmware will add two
new RO EFI variables after ExitBootServices.
RTStorageVolatile -- contains the filename, relative to the ESP
VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can
be copied to the file defined by RTStorageVolatile.
If any errors occur during the variable init, the firmware will delete them
and adjust the RT_PROP table accordingly, disabling SetvarRT.
- pre-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs
(ro,nosuid,nodev,noexec,relatime)
$~ efibootmgr -n 0001
Could not set BootNext: Read-only file system
- post-patch
$~ mount | grep efiva
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
, disabling SetvarRT.
$~ efibootmgr -n 0001
BootNext: 0001
BootCurrent:
BootOrder: ,0001
Boot* debian
HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
Boot0001* virtio 0
VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
$~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
Name: "BootNext"
Attributes:
Non-Volatile
Boot Service Access
Runtime Service Access
Value:
01 00
[0]
https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodi...@linaro.org/
[1]
https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
Changes since the RFC:
- Return EFI_INVALID_PARAM if attributes are not volatile
- Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables
- Add 2 EFI variables and allow userspace to write the file
- Add selftests
Ilias Apalodimas (4):
efi_loader: conditionally enable SetvariableRT
efi_loader: Add OS notifications for SetVariableRT in RAM
efi_loader: add an EFI variable with the variable file contents
efi_selftest: add tests for setvariableRT
include/efi_loader.h | 4 +
include/efi_variable.h| 15 +-
lib/efi_loader/Kconfig| 16 ++
lib/efi_loader/efi_boottime.c | 2 +
lib/efi_loader/efi_runtime.c | 1 +
lib/efi_loader/efi_var_common.c | 43 ++--
lib/efi_loader/efi_var_file.c | 1 -
lib/efi_loader/efi_var_mem.c | 90 +++-
lib/efi_loader/efi_variable.c | 210 +-
lib/efi_loader/efi_variable_tee.c | 1 -
.../efi_selftest_variables_runtime.c | 116 +-
11 files changed, 401 insertions(+), 98 deletions(-)
I can't get patch 0003 from this series to apply on master or next.
Hello Mark,
there are some prerequisite pending patches:
See
https://source.denx.de/u-boot/custodians/u-boot-tpm/-/commits/setvar_rt1?ref_type=heads
Best regards
Heinrich
Re: [PATCH v1 0/4] Enable SetvariableRT
Hi Mark
On Mon, 8 Apr 2024 at 00:53, Mark Kettenis wrote:
>
> > From: Ilias Apalodimas
> >
> > Hi all,
> >
> > This is an updated version of [0].
> >
> > When EFI variables are stored on file we don't allow SetVariableRT,
> > since the OS doesn't know how to access or write that file. At the same
> > time keeping the U-Boot drivers alive in runtime sections and performing
> > writes from the firmware is dangerous -- if at all possible.
> >
> > For GetVariableRT we copy runtime variables in RAM and expose them to
> > the OS. Add a Kconfig option and provide SetVariableRT using the same
> > memory back end. The OS will be responsible for syncing the RAM contents
> > to the file, otherwise any changes made during runtime won't persist
> > reboots.
> >
> > It's worth noting that the variable store format is defined in EBBR [1]
> > and authenticated variables are explicitly prohibited, since they have
> > to be stored on a medium that's tamper and rollback protected.
> >
> > The original RFC was just enabling the memory back end. This is a more
> > complete version and we should be able, with small adjustments of
> > userspace tools, fix SetVariableRT. If enabled the firmware will add two
> > new RO EFI variables after ExitBootServices.
> >
> > RTStorageVolatile -- contains the filename, relative to the ESP
> > VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can
> > be copied to the file defined by RTStorageVolatile.
> >
> > If any errors occur during the variable init, the firmware will delete them
> > and adjust the RT_PROP table accordingly, disabling SetvarRT.
> >
> > - pre-patch
> > $~ mount | grep efiva
> > efivarfs on /sys/firmware/efi/efivars type efivarfs
> > (ro,nosuid,nodev,noexec,relatime)
> >
> > $~ efibootmgr -n 0001
> > Could not set BootNext: Read-only file system
> >
> > - post-patch
> > $~ mount | grep efiva
> > efivarfs on /sys/firmware/efi/efivars type efivarfs
> > (rw,nosuid,nodev,noexec,relatime)
> > , disabling SetvarRT.
> > $~ efibootmgr -n 0001
> > BootNext: 0001
> > BootCurrent:
> > BootOrder: ,0001
> > Boot* debian
> > HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
> > Boot0001* virtio 0
> > VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
> >
> > $~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
> > GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
> > Name: "BootNext"
> > Attributes:
> > Non-Volatile
> > Boot Service Access
> > Runtime Service Access
> > Value:
> > 01 00
> >
> > [0]
> > https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodi...@linaro.org/
> > [1]
> > https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
> >
> > Changes since the RFC:
> > - Return EFI_INVALID_PARAM if attributes are not volatile
> > - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables
> > - Add 2 EFI variables and allow userspace to write the file
> > - Add selftests
> >
> > Ilias Apalodimas (4):
> > efi_loader: conditionally enable SetvariableRT
> > efi_loader: Add OS notifications for SetVariableRT in RAM
> > efi_loader: add an EFI variable with the variable file contents
> > efi_selftest: add tests for setvariableRT
> >
> > include/efi_loader.h | 4 +
> > include/efi_variable.h| 15 +-
> > lib/efi_loader/Kconfig| 16 ++
> > lib/efi_loader/efi_boottime.c | 2 +
> > lib/efi_loader/efi_runtime.c | 1 +
> > lib/efi_loader/efi_var_common.c | 43 ++--
> > lib/efi_loader/efi_var_file.c | 1 -
> > lib/efi_loader/efi_var_mem.c | 90 +++-
> > lib/efi_loader/efi_variable.c | 210 +-
> > lib/efi_loader/efi_variable_tee.c | 1 -
> > .../efi_selftest_variables_runtime.c | 116 +-
> > 11 files changed, 401 insertions(+), 98 deletions(-)
>
> I can't get patch 0003 from this series to apply on master or next.
Yes, my bad I forgot to mention you also need (before applying this series)
https://lore.kernel.org/u-boot/20240403153335.96971-1-heinrich.schucha...@canonical.com/
https://lore.kernel.org/u-boot/20240402090950.3819705-1-kojima.masah...@socionext.com/
https://lore.kernel.org/u-boot/20240405065058.591452-1-ilias.apalodi...@linaro.org/
Alternatively, you can clone directly
https://source.denx.de/u-boot/custodians/u-boot-tpm/-/tree/setvar_rt1
Thanks
/Ilias
>
Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
On Sun, Apr 7, 2024 at 8:51 PM Peng Fan wrote: > Ok. But these should not be related to this patchset. Yes, that's why my first sentence was: "Here are some comments unrelated to the UART issue." Thanks for taking a look at these issues.
Armada 3720 alike Board - no PHY devices found by mii info, no ping
Hello list,
I work with a variant of Marvell Armada 3720 board.
Recently I upgrade Uboot version from 2017 to 2023.07.
As a result PING command failed
Original version of 2017 reports on mii info command
PCPE>> mii info
PHY 0x01: OUI = 0x5A985, Model = 0x2A, Rev = 0x06, 100baseT, HDX
Whilst my new 2023 can not find PHY devices
I made minimal changes to configuration and Device tree files.
Compilation passed, I loaded Uboot using Uart and it successfully reached PCPE
prompt
So I tried to test network .
Ping correctly reports it uses eth1@neta4 as output interface (exactly as
v2017 does),
but ping failed
I did not touch at all PHY and ethernet related definitions, leaving them
exactly as it was.
Please advise what to look for.
I do not know how to send full DTS file to list, please instruct me.
Meanwhile I do copy-paste.
Here snipped of DTSI file
-
comphy: comphy@18300 {
compatible = "marvell,mvebu-comphy",
"marvell,comphy-armada-3700";
reg = <0x18300 0x28>,
<0x1f300 0x3d000>;
mux-bitcount = <4>;
max-lanes = <3>;
};
Here the relevant part of DTS file:
&comphy {
phy0 {
phy-type = ;
phy-speed = ;
};
phy1 {
phy-type = ;
phy-speed = ;
};
phy2 {
phy-type = ;
phy-speed = ;
};
};
ð0 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&rgmii_pins>, <&smi_pins>;
phy-mode = "rgmii";
phy_addr = <0x2>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
ð1 {
status = "okay";
phy-mode = "sgmii";
phy_addr = <0x1>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
And here snippet of DTSI file :
RE: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
> Subject: Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM > > Hello Peng, > > Some minor nitpicks... s/Conver to/Convert to/ in the patch subject, and a > couple more below. > > > On 2024-03-28 06:05, Peng Fan (OSS) wrote: > > A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg), > > those nodes > > s/soc/SoC/ > > > could be dropped after upstream linux supports them. > > s/linux/Linux/ Will fix all the typos in V5. Thanks, Peng. > > > To support OF_UPSTREAM, a few driver changes are included. > > For TMU, still use U-Boot node, I will prepare a kernel update, then > > back to U-Boot support. > > > > Mathieu: please help test the boards you maintain when you have time. > > > > Thanks, > > Peng. > > > > To: Sébastien Szymanski > > To: Stefano Babic > > To: Fabio Estevam > > To: "NXP i.MX U-Boot Team" > > To: Mathieu Othacehe > > Cc: u-boot@lists.denx.de > > Signed-off-by: Peng Fan > > > > Changes in v4: > > - Convert all i.MX93 boards > > - Link to v3: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fr%2F20240328-imx93-of-v3-0- > 4e7f341ed7ea%40nxp.com&data=0 > > > 5%7C02%7Cpeng.fan%40nxp.com%7Cfb4cf5cd6eb048f7004508dc5724921f > %7C686ea > > > 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638481061784727166%7CU > nknown%7CT > > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI > > > 6Mn0%3D%7C0%7C%7C%7C&sdata=m3eUSDFipFRBJlujTzNovsgusVTRp8lekD > guNKKGlq8 > > %3D&reserved=0 > > > > Changes in v3: > > - Update patch 5, to drop the imx8mp-evk changes which are wrongly > >included > > - Link to v2: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fr%2F20240328-imx93-of-v2-0- > 909f5d37da87%40nxp.com&data=0 > > > 5%7C02%7Cpeng.fan%40nxp.com%7Cfb4cf5cd6eb048f7004508dc5724921f > %7C686ea > > > 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638481061784740481%7CU > nknown%7CT > > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI > > > 6Mn0%3D%7C0%7C%7C%7C&sdata=dOltsehRiqbWFgRABoeC1nUqbU5CTz2 > OOt6Yq7u9sj0 > > %3D&reserved=0 > > > > Changes in v2: > > - Add a new patch to sync clock header to avoid breaking > > - Drop the Makefile change which change including order > > - Link to v1: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore > > .kernel.org%2Fr%2F20240327-imx93-of-v1-0- > afab6b31422a%40nxp.com&data=0 > > > 5%7C02%7Cpeng.fan%40nxp.com%7Cfb4cf5cd6eb048f7004508dc5724921f > %7C686ea > > > 1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638481061784750001%7CU > nknown%7CT > > > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC > JXVCI > > > 6Mn0%3D%7C0%7C%7C%7C&sdata=x4s291DNECLAyKaOdMRse2CLfFwaSx8Z > %2BCdLZZrYV > > mY%3D&reserved=0 > > > > --- > > Peng Fan (5): > > gpio: imx_rgpio2p: support one address > > serial: lpuart: use ipg clk for i.MX7ULP > > cpu: drop imx9_cpu > > clk: imx93: fix anatop base > > imx93: convert to OF_UPSTREAM > > > > arch/arm/dts/Makefile | 5 - > > arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 119 > > arch/arm/dts/imx93-11x11-evk.dts| 322 - > > arch/arm/dts/imx93-phyboard-segin.dts | 117 --- > > arch/arm/dts/imx93-phycore-som.dtsi | 126 > > arch/arm/dts/imx93-pinfunc.h| 623 > > arch/arm/dts/imx93-u-boot.dtsi | 80 +++ > > arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi | 22 + > > arch/arm/dts/imx93-var-som-symphony.dts | 323 - > > arch/arm/dts/imx93-var-som.dtsi | 111 --- > > arch/arm/dts/imx93.dtsi | 906 > > > > arch/arm/mach-imx/imx9/Kconfig | 1 + > > configs/imx93-phyboard-segin_defconfig | 2 +- > > configs/imx93_11x11_evk_defconfig | 2 +- > > configs/imx93_11x11_evk_ld_defconfig| 2 +- > > configs/imx93_var_som_defconfig | 2 +- > > drivers/clk/imx/clk-imx93.c | 2 +- > > drivers/cpu/imx9_cpu.c | 224 -- > > drivers/gpio/imx_rgpio2p.c | 42 +- > > drivers/serial/serial_lpuart.c | 9 +- > > include/dt-bindings/clock/imx93-clock.h | 208 -- > > include/dt-bindings/power/fsl,imx93-power.h | 15 - > > 22 files changed, 273 insertions(+), 2990 deletions(-) > > --- > > base-commit: 280f34ba7d68bb50c0b8eaa040322c1f3b37d46e > > change-id: 20240328-imx93-of-v2-f879efef737d > > > > Best regards,
RE: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
> Subject: Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM > > Hi Peng, > > Here are some comments unrelated to the UART issue. > > On Sun, Apr 7, 2024 at 7:35 AM Peng Fan wrote: > > > SOC: 0xa1009300 > > LC: 0x2040010 > > M33 prepare ok > > Could you remove these three lines? Ok. But these should not be related to this patchset. > > They are not very helpful and add noise to the boot log. > > > Normal Boot > > Trying to boot from BOOTROM > > Boot Stage: Primary boot > > image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from > > 0x49800 by ROM_API > > NOTICE: BL31: v2.8(release):lf-6.6.3-1.0.0-10-gf12d90141 > > NOTICE: BL31: Built : 09:34:44, Mar 27 2024 > > > > > > U-Boot 2024.04-rc5-00388-g351988e2dce (Apr 07 2024 - 19:29:56 +0800) > > > > Reset Status: POR > > > > Could not read CPU frequency: -2 > > CPU: NXP i.MX93(52) Rev1.1 A55 at 0 MHz > > Please fix this. I am sure the CPU is not running at 0 MHz :-) Yes, I will fix . Also not related to this patchset. > > > CPU: Industrial temperature grade (-40C to 105C) at 26C > > > > Model: NXP i.MX93 11X11 EVK board > > DRAM: 2 GiB > > Core: 188 devices, 24 uclasses, devicetree: separate > > WDT: Started watchdog@4249 with servicing every 1000ms (40s > timeout) > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > Loading Environment from MMC... *** Warning - bad CRC, using default > > environment > > > > In:serial@4438 > > Out: serial@4438 > > Err: serial@4438 > > switch to partitions #0, OK > > mmc1 is current device > > Net: > > Warning: ethernet@428a (eth1) using random MAC address - > > 6a:c2:96:d2:68:a6 > > eth0: ethernet@4289 [PRIME], eth1: ethernet@428a > > Aren't the MAC address fuses programmed? Or are they not being read > correctly? I will check, but I think not related to this patchset. Thanks, Peng.
Re: [PATCH v1 0/4] Enable SetvariableRT
> From: Ilias Apalodimas
>
> Hi all,
>
> This is an updated version of [0].
>
> When EFI variables are stored on file we don't allow SetVariableRT,
> since the OS doesn't know how to access or write that file. At the same
> time keeping the U-Boot drivers alive in runtime sections and performing
> writes from the firmware is dangerous -- if at all possible.
>
> For GetVariableRT we copy runtime variables in RAM and expose them to
> the OS. Add a Kconfig option and provide SetVariableRT using the same
> memory back end. The OS will be responsible for syncing the RAM contents
> to the file, otherwise any changes made during runtime won't persist
> reboots.
>
> It's worth noting that the variable store format is defined in EBBR [1]
> and authenticated variables are explicitly prohibited, since they have
> to be stored on a medium that's tamper and rollback protected.
>
> The original RFC was just enabling the memory back end. This is a more
> complete version and we should be able, with small adjustments of
> userspace tools, fix SetVariableRT. If enabled the firmware will add two
> new RO EFI variables after ExitBootServices.
>
> RTStorageVolatile -- contains the filename, relative to the ESP
> VarToFile -- an EFI variable that holds all the BS,RT, NV variables and can
> be copied to the file defined by RTStorageVolatile.
>
> If any errors occur during the variable init, the firmware will delete them
> and adjust the RT_PROP table accordingly, disabling SetvarRT.
>
> - pre-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (ro,nosuid,nodev,noexec,relatime)
>
> $~ efibootmgr -n 0001
> Could not set BootNext: Read-only file system
>
> - post-patch
> $~ mount | grep efiva
> efivarfs on /sys/firmware/efi/efivars type efivarfs
> (rw,nosuid,nodev,noexec,relatime)
> , disabling SetvarRT.
> $~ efibootmgr -n 0001
> BootNext: 0001
> BootCurrent:
> BootOrder: ,0001
> Boot* debian
> HD(1,GPT,bdae5610-3331-4e4d-9466-acb5caf0b4a6,0x800,0x10)/File(EFI\debian\grubaa64.efi)
> Boot0001* virtio 0
> VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,85001f00)/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b,16008500){auto_created_boot_option}
>
> $~ efivar -p -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-BootNext
> GUID: 8be4df61-93ca-11d2-aa0d-00e098032b8c
> Name: "BootNext"
> Attributes:
> Non-Volatile
> Boot Service Access
> Runtime Service Access
> Value:
> 01 00
>
> [0]
> https://lore.kernel.org/u-boot/20240329071929.2461441-1-ilias.apalodi...@linaro.org/
> [1]
> https://arm-software.github.io/ebbr/index.html#document-chapter5-variable-storage
>
> Changes since the RFC:
> - Return EFI_INVALID_PARAM if attributes are not volatile
> - Add EFI_WRITE_PROTECTED checks for BS, RT *only* variables
> - Add 2 EFI variables and allow userspace to write the file
> - Add selftests
>
> Ilias Apalodimas (4):
> efi_loader: conditionally enable SetvariableRT
> efi_loader: Add OS notifications for SetVariableRT in RAM
> efi_loader: add an EFI variable with the variable file contents
> efi_selftest: add tests for setvariableRT
>
> include/efi_loader.h | 4 +
> include/efi_variable.h| 15 +-
> lib/efi_loader/Kconfig| 16 ++
> lib/efi_loader/efi_boottime.c | 2 +
> lib/efi_loader/efi_runtime.c | 1 +
> lib/efi_loader/efi_var_common.c | 43 ++--
> lib/efi_loader/efi_var_file.c | 1 -
> lib/efi_loader/efi_var_mem.c | 90 +++-
> lib/efi_loader/efi_variable.c | 210 +-
> lib/efi_loader/efi_variable_tee.c | 1 -
> .../efi_selftest_variables_runtime.c | 116 +-
> 11 files changed, 401 insertions(+), 98 deletions(-)
I can't get patch 0003 from this series to apply on master or next.
[PATCH v2] ARM: stm32: Jump to ep on successful resume in PSCI suspend code
In case the system has resumed successfully, the PSCI suspend resume
code has to jump to the 'ep' successful resume entry point code path,
otherwise the code has to jump to content of the LR register, which
points to failed resume code path.
To implement this distinction, rewrite LR register stored on stack
with 'ep' value in case of a successful resume, which is really in
every case unless some catastrophic failure occurred during suspend.
Without this change, Linux counts every resume as failed in
/sys/power/suspend_stats/fail
Signed-off-by: Marek Vasut
---
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);
}
--
2.43.0
Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
Hello Peng, Some minor nitpicks... s/Conver to/Convert to/ in the patch subject, and a couple more below. On 2024-03-28 06:05, Peng Fan (OSS) wrote: A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg), those nodes s/soc/SoC/ could be dropped after upstream linux supports them. s/linux/Linux/ To support OF_UPSTREAM, a few driver changes are included. For TMU, still use U-Boot node, I will prepare a kernel update, then back to U-Boot support. Mathieu: please help test the boards you maintain when you have time. Thanks, Peng. To: Sébastien Szymanski To: Stefano Babic To: Fabio Estevam To: "NXP i.MX U-Boot Team" To: Mathieu Othacehe Cc: u-boot@lists.denx.de Signed-off-by: Peng Fan Changes in v4: - Convert all i.MX93 boards - Link to v3: https://lore.kernel.org/r/20240328-imx93-of-v3-0-4e7f341ed...@nxp.com Changes in v3: - Update patch 5, to drop the imx8mp-evk changes which are wrongly included - Link to v2: https://lore.kernel.org/r/20240328-imx93-of-v2-0-909f5d37d...@nxp.com Changes in v2: - Add a new patch to sync clock header to avoid breaking - Drop the Makefile change which change including order - Link to v1: https://lore.kernel.org/r/20240327-imx93-of-v1-0-afab6b314...@nxp.com --- Peng Fan (5): gpio: imx_rgpio2p: support one address serial: lpuart: use ipg clk for i.MX7ULP cpu: drop imx9_cpu clk: imx93: fix anatop base imx93: convert to OF_UPSTREAM arch/arm/dts/Makefile | 5 - arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 119 arch/arm/dts/imx93-11x11-evk.dts| 322 - arch/arm/dts/imx93-phyboard-segin.dts | 117 --- arch/arm/dts/imx93-phycore-som.dtsi | 126 arch/arm/dts/imx93-pinfunc.h| 623 arch/arm/dts/imx93-u-boot.dtsi | 80 +++ arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi | 22 + arch/arm/dts/imx93-var-som-symphony.dts | 323 - arch/arm/dts/imx93-var-som.dtsi | 111 --- arch/arm/dts/imx93.dtsi | 906 arch/arm/mach-imx/imx9/Kconfig | 1 + configs/imx93-phyboard-segin_defconfig | 2 +- configs/imx93_11x11_evk_defconfig | 2 +- configs/imx93_11x11_evk_ld_defconfig| 2 +- configs/imx93_var_som_defconfig | 2 +- drivers/clk/imx/clk-imx93.c | 2 +- drivers/cpu/imx9_cpu.c | 224 -- drivers/gpio/imx_rgpio2p.c | 42 +- drivers/serial/serial_lpuart.c | 9 +- include/dt-bindings/clock/imx93-clock.h | 208 -- include/dt-bindings/power/fsl,imx93-power.h | 15 - 22 files changed, 273 insertions(+), 2990 deletions(-) --- base-commit: 280f34ba7d68bb50c0b8eaa040322c1f3b37d46e change-id: 20240328-imx93-of-v2-f879efef737d Best regards,
Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
Hi Peng, Here are some comments unrelated to the UART issue. On Sun, Apr 7, 2024 at 7:35 AM Peng Fan wrote: > SOC: 0xa1009300 > LC: 0x2040010 > M33 prepare ok Could you remove these three lines? They are not very helpful and add noise to the boot log. > Normal Boot > Trying to boot from BOOTROM > Boot Stage: Primary boot > image offset 0x8000, pagesize 0x200, ivt offset 0x0 > Load image from 0x49800 by ROM_API > NOTICE: BL31: v2.8(release):lf-6.6.3-1.0.0-10-gf12d90141 > NOTICE: BL31: Built : 09:34:44, Mar 27 2024 > > > U-Boot 2024.04-rc5-00388-g351988e2dce (Apr 07 2024 - 19:29:56 +0800) > > Reset Status: POR > > Could not read CPU frequency: -2 > CPU: NXP i.MX93(52) Rev1.1 A55 at 0 MHz Please fix this. I am sure the CPU is not running at 0 MHz :-) > CPU: Industrial temperature grade (-40C to 105C) at 26C > > Model: NXP i.MX93 11X11 EVK board > DRAM: 2 GiB > Core: 188 devices, 24 uclasses, devicetree: separate > WDT: Started watchdog@4249 with servicing every 1000ms (40s timeout) > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > In:serial@4438 > Out: serial@4438 > Err: serial@4438 > switch to partitions #0, OK > mmc1 is current device > Net: > Warning: ethernet@428a (eth1) using random MAC address - 6a:c2:96:d2:68:a6 > eth0: ethernet@4289 [PRIME], eth1: ethernet@428a Aren't the MAC address fuses programmed? Or are they not being read correctly?
Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
> Any comments? Yes, see: https://lists.denx.de/pipermail/u-boot/2024-March/549531.html Thanks, Mathieu
[PATCH v4 3/3] imx93_11x11_evk: Add PCF2131 RTC support
Enable CONFIG_RTC_PCF2127 configs to support pcf2131. Signed-off-by: Joy Zou --- Changes in v3: 1. Change CONFIG_RTC_PCF2131 into CONFIG_RTC_PCF2127 because the pcf2131 driver have been merged into the pcf2127. --- configs/imx93_11x11_evk_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/imx93_11x11_evk_defconfig b/configs/imx93_11x11_evk_defconfig index 63613477c7..55e2673291 100644 --- a/configs/imx93_11x11_evk_defconfig +++ b/configs/imx93_11x11_evk_defconfig @@ -14,6 +14,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx93-11x11-evk" CONFIG_SPL_TEXT_BASE=0x2049A000 CONFIG_TARGET_IMX93_11X11_EVK=y CONFIG_SYS_MONITOR_LEN=524288 +CONFIG_RTC_PCF2127=y CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y CONFIG_SPL_STACK=0x20519dd0 -- 2.37.1
[PATCH v4 2/3] imx: imx93_evk: add rtc PCF2131
support rtc PCF2131 for imx93.
Signed-off-by: Joy Zou
---
Changes in v4:
1. remove arch/arm/dts/imx93_11x11_evk.dts change because it can sync from
kernel dts.
2. add the RTC support to the -u-boot.dtsi.
3. assign the rtc0 to rtc@53 in order to avoid date reset fail.
Changes in v3:
1. remove arch/arm/dts/imx93.dtsi modification because this change have existed.
Changes in v2:
1. use the flag bootph-pre-ram instead of uboot,dm-spl.
---
arch/arm/dts/imx93-11x11-evk-u-boot.dtsi | 34
1 file changed, 34 insertions(+)
diff --git a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
index a99ba99bfb..85aaf0844f 100644
--- a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
@@ -19,6 +19,11 @@
method = "smc";
};
};
+
+ aliases {
+ rtc0 = &pcf2131;
+ };
+
};
&{/soc@0} {
@@ -112,6 +117,25 @@
bootph-some-ram;
};
+&lpi2c3 {
+ bootph-pre-ram;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <40>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-1 = <&pinctrl_lpi2c3>;
+ status = "okay";
+
+ pcf2131: rtc@53 {
+ compatible = "nxp,pcf2131";
+ reg = <0x53>;
+ interrupt-parent = <&pcal6524>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ status = "okay";
+ };
+};
+
&{/soc@0/bus@4400/i2c@4435/pmic@25} {
bootph-pre-ram;
bootph-some-ram;
@@ -127,6 +151,16 @@
bootph-some-ram;
};
+&iomuxc {
+ pinctrl_lpi2c3: lpi2c3grp {
+ bootph-pre-ram;
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA
0x4b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL
0x4b9e
+ >;
+ };
+};
+
&fec {
phy-reset-gpios = <&pcal6524 16 GPIO_ACTIVE_LOW>;
phy-reset-duration = <15>;
--
2.37.1
[PATCH v4 1/3] drivers: rtc: add pcf2131 rtc driver
Adding support for pcf2131 RTC chip.
The pcf2131 is similar to the pcf2127. The driver support rtc register
read/write by using rtc cmd and rtc date set/get by using date cmd.
The pcf2131 is special when write access to time registers. it requires
setting the STOP and CPR bits. STOP bit needs to be cleared after time
registers are updated.
Signed-off-by: Joy Zou
---
Changes in v4:
1. Add static keyword for the is_pcf2131_type function.
2. remove unnecessary ret initialization.
Changes in v3:
1.merge pcf2131 into pcf2127 in order to keep same with kernel.
Changes in v2:
1. delete the unnecessary initialization.
2. retrun directly function insteand of redundancy return ret.
3. delete the unnecessary comment line.
---
drivers/rtc/pcf2127.c | 146 ++
1 file changed, 132 insertions(+), 14 deletions(-)
diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index 2f3fafb496..2b000347f8 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -23,6 +23,38 @@
#define PCF2127_REG_MO 0x08
#define PCF2127_REG_YR 0x09
+#define PCF2131_REG_CTRL1 0x00
+#define PCF2131_BIT_CTRL1_STOP BIT(5)
+#define PCF2131_REG_SR_RESET0x05
+#define PCF2131_SR_VAL_Clr_Pres 0xa4
+#define PCF2131_REG_SC 0x07
+#define PCF2131_REG_MN 0x08
+#define PCF2131_REG_HR 0x09
+#define PCF2131_REG_DM 0x0a
+#define PCF2131_REG_DW 0x0b
+#define PCF2131_REG_MO 0x0c
+#define PCF2131_REG_YR 0x0d
+
+enum {
+ NXP_CHIP_TYPE_PCF2127 = 0,
+ NXP_CHIP_TYPE_PCF2129,
+ NXP_CHIP_TYPE_PCA2129,
+ NXP_CHIP_TYPE_PCF2131,
+ NXP_CHIP_TYPE_AMOUNT
+};
+
+static bool is_pcf2131_type(struct udevice *dev)
+{
+ int type;
+
+ type = dev_get_driver_data(dev);
+
+ if (type == NXP_CHIP_TYPE_PCF2131)
+ return true;
+ else
+ return false;
+}
+
static int pcf2127_rtc_read(struct udevice *dev, uint offset, u8 *buffer, uint
len)
{
struct dm_i2c_chip *chip = dev_get_parent_plat(dev);
@@ -43,10 +75,64 @@ static int pcf2127_rtc_read(struct udevice *dev, uint
offset, u8 *buffer, uint l
return dm_i2c_xfer(dev, &msg, 1);
}
+static int pcf2131_rtc_lock(struct udevice *dev)
+{
+ int ret;
+ uchar buf[6] = { PCF2131_REG_CTRL1 };
+
+ ret = pcf2127_rtc_read(dev, PCF2131_REG_CTRL1, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ buf[PCF2131_REG_CTRL1] |= PCF2131_BIT_CTRL1_STOP;
+ ret = dm_i2c_write(dev, PCF2131_REG_CTRL1, &buf[PCF2131_REG_CTRL1], 1);
+ if (ret < 0)
+ return ret;
+
+ buf[PCF2131_REG_SR_RESET] = PCF2131_SR_VAL_Clr_Pres;
+
+ return dm_i2c_write(dev, PCF2131_REG_SR_RESET,
&buf[PCF2131_REG_SR_RESET], 1);
+}
+
+static int pcf2131_rtc_unlock(struct udevice *dev)
+{
+ int ret;
+ uchar buf[6] = { PCF2131_REG_CTRL1 };
+
+ ret = pcf2127_rtc_read(dev, PCF2131_REG_CTRL1, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ buf[PCF2131_REG_CTRL1] &= ~PCF2131_BIT_CTRL1_STOP;
+ return dm_i2c_write(dev, PCF2131_REG_CTRL1, &buf[PCF2131_REG_CTRL1], 1);
+}
+
static int pcf2127_rtc_write(struct udevice *dev, uint offset,
const u8 *buffer, uint len)
{
- return dm_i2c_write(dev, offset, buffer, len);
+ int ret;
+ bool flag;
+
+ flag = is_pcf2131_type(dev);
+ if (flag) {
+ ret = pcf2131_rtc_lock(dev);
+ if (ret < 0)
+ return ret;
+ }
+
+ ret = dm_i2c_write(dev, offset, buffer, len);
+ if (ret < 0) {
+ if (flag)
+ pcf2131_rtc_unlock(dev);
+ return ret;
+ }
+
+ if (flag) {
+ ret = pcf2131_rtc_unlock(dev);
+ if (ret < 0)
+ return ret;
+ }
+ return ret;
}
static int pcf2127_rtc_set(struct udevice *dev, const struct rtc_time *tm)
@@ -68,15 +154,19 @@ static int pcf2127_rtc_set(struct udevice *dev, const
struct rtc_time *tm)
buf[i++] = bin2bcd(tm->tm_year % 100);
/* write register's data */
- ret = dm_i2c_write(dev, PCF2127_REG_SC, buf, i);
+ if (is_pcf2131_type(dev))
+ ret = pcf2127_rtc_write(dev, PCF2131_REG_SC, buf, i);
+ else
+ ret = pcf2127_rtc_write(dev, PCF2127_REG_SC, buf, i);
return ret;
}
static int pcf2127_rtc_get(struct udevice *dev, struct rtc_time *tm)
{
- int ret = 0;
- uchar buf[10] = { PCF2127_REG_CTRL1 };
+ int ret;
+ bool flag;
+ uchar buf[14] = { PCF2127_REG_CTRL1 };
ret = pcf2127_rtc_read(dev, PCF2127_REG_CTRL1, buf, sizeof(buf));
if (ret < 0)
@@ -85,15 +175,28 @@ static int pcf2127_rtc_get(struct udevice *dev, struct
rtc_time *tm)
[PATCH v4 0/3] Add pcf2131 rtc support
The patchset supports pcf2131 rtc. For the details, please check the patch commit log. Joy Zou (3): drivers: rtc: add pcf2131 rtc driver imx: imx93_evk: add rtc PCF2131 imx93_11x11_evk: Add PCF2131 RTC support arch/arm/dts/imx93-11x11-evk-u-boot.dtsi | 34 ++ configs/imx93_11x11_evk_defconfig| 1 + drivers/rtc/pcf2127.c| 146 --- 3 files changed, 167 insertions(+), 14 deletions(-) -- 2.37.1
RE: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
Hi Mathieu,
> Subject: RE: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
>
> Hi Mathieu,
> > Subject: Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
> >
> >
> > > Any comments?
> >
> > Yes, see:
>
> Sorry, I missed your comment.
Could you please help try this on top of this patchset?
Seems this is the only point I could think of, that would impact uart.
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index 653ff99e67b..891352293f9 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -486,19 +486,22 @@ static int lpuart_serial_pending(struct udevice *dev,
bool input)
static int lpuart_serial_probe(struct udevice *dev)
{
#if CONFIG_IS_ENABLED(CLK)
+ struct lpuart_serial_plat *plat = dev_get_plat(dev);
struct clk per_clk;
struct clk ipg_clk;
int ret;
- ret = clk_get_by_name(dev, "per", &per_clk);
- if (!ret) {
- ret = clk_enable(&per_clk);
- if (ret) {
- dev_err(dev, "Failed to enable per clk: %d\n", ret);
- return ret;
+ if (plat->devtype != DEV_MX7ULP) {
+ ret = clk_get_by_name(dev, "per", &per_clk);
+ if (!ret) {
+ ret = clk_enable(&per_clk);
+ if (ret) {
+ dev_err(dev, "Failed to enable per clk: %d\n",
ret);
+ return ret;
+ }
+ } else {
+ debug("%s: Failed to get per clk: %d\n", __func__, ret);
}
- } else {
- debug("%s: Failed to get per clk: %d\n", __func__, ret);
}
ret = clk_get_by_name(dev, "ipg", &ipg_clk);
Thanks,
Peng.
>
> From my test just now, log below. For your uart not work proper, I think it is
> the uart clk not setup
>
> U-Boot SPL 2024.04-rc5-00388-g351988e2dce (Apr 07 2024 - 19:29:56
> +0800)
> SOC: 0xa1009300
> LC: 0x2040010
> M33 prepare ok
> Normal Boot
> Trying to boot from BOOTROM
> Boot Stage: Primary boot
> image offset 0x8000, pagesize 0x200, ivt offset 0x0 Load image from 0x49800
> by ROM_API
> NOTICE: BL31: v2.8(release):lf-6.6.3-1.0.0-10-gf12d90141
> NOTICE: BL31: Built : 09:34:44, Mar 27 2024
>
>
> U-Boot 2024.04-rc5-00388-g351988e2dce (Apr 07 2024 - 19:29:56 +0800)
>
> Reset Status: POR
>
> Could not read CPU frequency: -2
> CPU: NXP i.MX93(52) Rev1.1 A55 at 0 MHz
> CPU: Industrial temperature grade (-40C to 105C) at 26C
>
> Model: NXP i.MX93 11X11 EVK board
> DRAM: 2 GiB
> Core: 188 devices, 24 uclasses, devicetree: separate
> WDT: Started watchdog@4249 with servicing every 1000ms (40s
> timeout)
> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> In:serial@4438
> Out: serial@4438
> Err: serial@4438
> switch to partitions #0, OK
> mmc1 is current device
> Net:
> Warning: ethernet@428a (eth1) using random MAC address -
> 6a:c2:96:d2:68:a6
> eth0: ethernet@4289 [PRIME], eth1: ethernet@428a Hit any key
> to stop autoboot: 0
>
> I see you have:
> &lpuart1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_uart1>;
> clocks = <&clk IMX93_CLK_LPUART1_GATE>, <&clk
> IMX93_CLK_LPUART1_GATE>;
> clock-names = "ipg", "per";
> status = "okay";
> };
>
> Could you please help give a look on your uart settings which not work with:
> https://lore.kernel.org/all/20240328-imx93-of-v2-v4-2-
> 338d15a65...@nxp.com/
>
> Thanks,
> Peng.
>
> > https://lists.d/
> > enx.de%2Fpipermail%2Fu-boot%2F2024-
> >
> March%2F549531.html&data=05%7C02%7Cpeng.fan%40nxp.com%7C46ad4
> > 24ef2cb4c09f8b908dc56edad0a%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> >
> 7C0%7C0%7C638480826025692986%7CUnknown%7CTWFpbGZsb3d8eyJWI
> >
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> >
> 0%7C%7C%7C&sdata=9oXIZF8Ihp1OfaDx3C%2Bcq9nstWJVhN8u3U7xQAhX2
> > 2o%3D&reserved=0
> >
> > Thanks,
> >
> > Mathieu
Re: [PATCH 1/5] zfs: Fix malloc() success check
Hi Phaedrus,
On Sun, Apr 7, 2024 at 4:00 AM wrote:
> This code was hitting the error code path whenever malloc() succeeded
> rather than when it failed, so presumably this part of the code hasn't
> been tested. I had to apply this fix (and others) to get U-Boot to boot
> from ZFS on an Nvidia Jetson TX2 NX SoM (an aarch64 computer).
>
> Signed-off-by: Phaedrus Leeds
> Tested-by: Phaedrus Leeds
>
It's an abuse of the Tested-by tag. If you are the author of the patch,
that obviously implies that you tested it before sending to ML.
Signed-off-by is enough in this case.
---
> fs/zfs/zfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/zfs/zfs.c b/fs/zfs/zfs.c
> index 1fec96cd5c..14779dee32 100644
> --- a/fs/zfs/zfs.c
> +++ b/fs/zfs/zfs.c
> @@ -648,21 +648,21 @@ dmu_read(dnode_end_t *dn, uint64_t blkid, void **buf,
> if (bp_array != dn->dn.dn_blkptr) {
> free(bp_array);
> bp_array = 0;
> }
>
> if (BP_IS_HOLE(bp)) {
> size_t size = zfs_to_cpu16(dn->dn.dn_datablkszsec,
>
> dn->endian)
> << SPA_MINBLOCKSHIFT;
> *buf = malloc(size);
> - if (*buf) {
> + if (!*buf) {
> err = ZFS_ERR_OUT_OF_MEMORY;
> break;
> }
> memset(*buf, 0, size);
> endian = (zfs_to_cpu64(bp->blk_prop, endian) >>
> 63) & 1;
> break;
> }
> if (level == 0) {
> err = zio_read(bp, endian, buf, 0, data);
> endian = (zfs_to_cpu64(bp->blk_prop, endian) >>
> 63) & 1;
> --
> 2.44.0
>
>
--
Best regards - Atentamente - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
https://www.linkedin.com/in/iopaniuk
RE: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
Hi Mathieu,
> Subject: Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
>
>
> > Any comments?
>
> Yes, see:
Sorry, I missed your comment.
>From my test just now, log below. For your uart not work proper, I think it is
the uart clk not setup
U-Boot SPL 2024.04-rc5-00388-g351988e2dce (Apr 07 2024 - 19:29:56 +0800)
SOC: 0xa1009300
LC: 0x2040010
M33 prepare ok
Normal Boot
Trying to boot from BOOTROM
Boot Stage: Primary boot
image offset 0x8000, pagesize 0x200, ivt offset 0x0
Load image from 0x49800 by ROM_API
NOTICE: BL31: v2.8(release):lf-6.6.3-1.0.0-10-gf12d90141
NOTICE: BL31: Built : 09:34:44, Mar 27 2024
U-Boot 2024.04-rc5-00388-g351988e2dce (Apr 07 2024 - 19:29:56 +0800)
Reset Status: POR
Could not read CPU frequency: -2
CPU: NXP i.MX93(52) Rev1.1 A55 at 0 MHz
CPU: Industrial temperature grade (-40C to 105C) at 26C
Model: NXP i.MX93 11X11 EVK board
DRAM: 2 GiB
Core: 188 devices, 24 uclasses, devicetree: separate
WDT: Started watchdog@4249 with servicing every 1000ms (40s timeout)
MMC: FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In:serial@4438
Out: serial@4438
Err: serial@4438
switch to partitions #0, OK
mmc1 is current device
Net:
Warning: ethernet@428a (eth1) using random MAC address - 6a:c2:96:d2:68:a6
eth0: ethernet@4289 [PRIME], eth1: ethernet@428a
Hit any key to stop autoboot: 0
I see you have:
&lpuart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
clocks = <&clk IMX93_CLK_LPUART1_GATE>, <&clk IMX93_CLK_LPUART1_GATE>;
clock-names = "ipg", "per";
status = "okay";
};
Could you please help give a look on your uart settings which not work with:
https://lore.kernel.org/all/20240328-imx93-of-v2-v4-2-338d15a65...@nxp.com/
Thanks,
Peng.
> https://lists.d/
> enx.de%2Fpipermail%2Fu-boot%2F2024-
> March%2F549531.html&data=05%7C02%7Cpeng.fan%40nxp.com%7C46ad4
> 24ef2cb4c09f8b908dc56edad0a%7C686ea1d3bc2b4c6fa92cd99c5c301635%
> 7C0%7C0%7C638480826025692986%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 0%7C%7C%7C&sdata=9oXIZF8Ihp1OfaDx3C%2Bcq9nstWJVhN8u3U7xQAhX2
> 2o%3D&reserved=0
>
> Thanks,
>
> Mathieu
RE: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
Any comments? Thanks, Peng. > Subject: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM > > A few nodes were added to soc and board u-boot.dtsi(lpi2c, usbotg), those > nodes could be dropped after upstream linux supports them. > > To support OF_UPSTREAM, a few driver changes are included. > For TMU, still use U-Boot node, I will prepare a kernel update, then back to > U- > Boot support. > > Mathieu: please help test the boards you maintain when you have time. > > Thanks, > Peng. > > To: Sébastien Szymanski > To: Stefano Babic > To: Fabio Estevam > To: "NXP i.MX U-Boot Team" > To: Mathieu Othacehe > Cc: u-boot@lists.denx.de > Signed-off-by: Peng Fan > > Changes in v4: > - Convert all i.MX93 boards > - Link to v3: https://lore.kernel.org/r/20240328-imx93-of-v3-0- > 4e7f341ed...@nxp.com > > Changes in v3: > - Update patch 5, to drop the imx8mp-evk changes which are wrongly >included > - Link to v2: https://lore.kernel.org/r/20240328-imx93-of-v2-0- > 909f5d37d...@nxp.com > > Changes in v2: > - Add a new patch to sync clock header to avoid breaking > - Drop the Makefile change which change including order > - Link to v1: https://lore.kernel.org/r/20240327-imx93-of-v1-0- > afab6b314...@nxp.com > > --- > Peng Fan (5): > gpio: imx_rgpio2p: support one address > serial: lpuart: use ipg clk for i.MX7ULP > cpu: drop imx9_cpu > clk: imx93: fix anatop base > imx93: convert to OF_UPSTREAM > > arch/arm/dts/Makefile | 5 - > arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 119 > arch/arm/dts/imx93-11x11-evk.dts| 322 - > arch/arm/dts/imx93-phyboard-segin.dts | 117 --- > arch/arm/dts/imx93-phycore-som.dtsi | 126 > arch/arm/dts/imx93-pinfunc.h| 623 > arch/arm/dts/imx93-u-boot.dtsi | 80 +++ > arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi | 22 + > arch/arm/dts/imx93-var-som-symphony.dts | 323 - > arch/arm/dts/imx93-var-som.dtsi | 111 --- > arch/arm/dts/imx93.dtsi | 906 > > arch/arm/mach-imx/imx9/Kconfig | 1 + > configs/imx93-phyboard-segin_defconfig | 2 +- > configs/imx93_11x11_evk_defconfig | 2 +- > configs/imx93_11x11_evk_ld_defconfig| 2 +- > configs/imx93_var_som_defconfig | 2 +- > drivers/clk/imx/clk-imx93.c | 2 +- > drivers/cpu/imx9_cpu.c | 224 -- > drivers/gpio/imx_rgpio2p.c | 42 +- > drivers/serial/serial_lpuart.c | 9 +- > include/dt-bindings/clock/imx93-clock.h | 208 -- > include/dt-bindings/power/fsl,imx93-power.h | 15 - > 22 files changed, 273 insertions(+), 2990 deletions(-) > --- > base-commit: 280f34ba7d68bb50c0b8eaa040322c1f3b37d46e > change-id: 20240328-imx93-of-v2-f879efef737d > > Best regards, > -- > Peng Fan
