Re: [PATCH v2 0/2] Add FRDM-IMX91 initial support

[Francesco Valla <francesco@valla.it>]

Hello Joseph,

thank you for the patch set.

On Tue, Dec 02, 2025 at 07:05:01PM +0900, Joseph Guo wrote:
> This series add initial support for the FRDM i.MX91 11x11 development
> board in U-Boot:
> https://www.nxp.com/design/design-center/development-boards-and-designs/FRDM-IMX91
> 
> Include:
> - Device tree for the board.
> - Defconfig and Kconfig for the board.
> - Header file defining memory layout and hadware addresses.
> 
> The board devicetree already attempted to upstream, but not been accepted yet:
> https://lore.kernel.org/all/20251114-imx91_frdm-v1-0-e5763bdf9336@nxp.com/
> 
> Signed-off-by: Joseph Guo <qijian.guo@nxp.com>
> ---
> Changes in v2:
> - add upstream link
> - rename 'vrpi' to 'vexp' to keep align with upstream dts
> - move bootph- property from u-boot.dtsi to dts   
> - correct commit message 'EVK' to 'FRDM'
> - use #include in ecc config file to avoid duplication
> - add ecc description in README
> - drop extraneous includes
> - rename 'imx91_frdm.rst' to 'imx91_11x11_frdm.rst'
> - drop IMX91_FRDM_LPDDR4 symbol
> - Link to v1: https://lore.kernel.org/r/20251127-imx91_frdm-v1-0-8f42646d89ad@nxp.com
> 
> ---
> Joseph Guo (2):
>       arm64: dts: add NXP FRDM-IMX91 device tree
>       imx: Support i.MX91 11x11 FRDM board
> 
>  arch/arm/dts/imx91-11x11-frdm-u-boot.dtsi          |   51 +
>  arch/arm/dts/imx91-11x11-frdm.dts                  |  767 ++++++++
>  arch/arm/mach-imx/imx9/Kconfig                     |    9 +
>  board/freescale/imx91_frdm/Kconfig                 |   12 +
>  board/freescale/imx91_frdm/MAINTAINERS             |    7 +
>  board/freescale/imx91_frdm/Makefile                |   16 +
>  board/freescale/imx91_frdm/imx91_frdm.c            |   25 +
>  board/freescale/imx91_frdm/imx91_frdm.env          |   88 +
>  .../imx91_frdm/lpddr4_2400mts_1gb_timing.c         | 1996 ++++++++++++++++++++
>  .../imx91_frdm/lpddr4_2400mts_2gb_timing.c         | 1996 ++++++++++++++++++++
>  .../imx91_frdm/lpddr4_2400mts_ecc_1gb_timing.c     | 1996 ++++++++++++++++++++
>  .../imx91_frdm/lpddr4_2400mts_ecc_2gb_timing.c     | 1996 ++++++++++++++++++++
>  board/freescale/imx91_frdm/lpddr4_timing.h         |   12 +
>  board/freescale/imx91_frdm/spl.c                   |  193 ++
>  configs/imx91_11x11_frdm_defconfig                 |  143 ++
>  configs/imx91_11x11_frdm_inline_ecc_defconfig      |    3 +
>  doc/board/nxp/imx91_11x11_frdm.rst                 |  100 +
>  doc/board/nxp/index.rst                            |    1 +
>  include/configs/imx91_frdm.h                       |   25 +
>  19 files changed, 9436 insertions(+)
> ---
> base-commit: e199db57c00ba2c2aba81069800126b6543a644c
> change-id: 20251117-imx91_frdm-7a2db95f279d
> 
> Best regards,
> -- 
> Joseph Guo <qijian.guo@nxp.com>
> 

I tested the series on the actual hardware with [0] on top of the
mainline Linux kernel and encountered a unmanaged interrupt warning
during boot, which wasn't there using the downstream NXP u-boot
version:

[    1.840096] mmc1: host does not support reading read-only switch, assuming write-enable
[    1.850352] mmc1: new high speed SDHC card at address 1234
[    1.857170] mmcblk1: mmc1:1234 SA08G 7.21 GiB
[    1.864850]  mmcblk1: p1 p2
[    2.279012] random: crng init done
[   11.720182] platform pwrseq-usdhc3: deferred probe pending: pwrseq_simple: reset control not ready
[   11.734562] platform 42890000.ethernet: deferred probe pending: platform: wait for supplier /soc@0/efuse@47510000/mac-address@4ec
[   17.947574] irq 99: nobody cared (try booting with the "irqpoll" option)
[   17.954292] CPU: 0 UID: 0 PID: 55 Comm: irq/99-1-0022 Not tainted 6.18.0-01544-g0817234e6cf9-dirty #1 PREEMPT 
[   17.954302] Hardware name: NXP FRDM-IMX91 Development Board (DT)
[   17.954306] Call trace:
[   17.954310]  show_stack+0x18/0x30 (C)
[   17.954326]  dump_stack_lvl+0x60/0x80
[   17.954335]  dump_stack+0x18/0x24
[   17.954341]  __report_bad_irq+0x4c/0xec
[   17.954351]  note_interrupt+0x33c/0x390
[   17.954361]  handle_irq_event+0x94/0xbc
[   17.954368]  handle_level_irq+0xd8/0x170
[   17.954375]  handle_irq_desc+0x34/0x58
[   17.954380]  generic_handle_domain_irq+0x1c/0x28
[   17.954386]  vf610_gpio_irq_handler+0x70/0x110
[   17.954395]  handle_irq_desc+0x34/0x58
[   17.954401]  generic_handle_domain_irq+0x1c/0x28
[   17.954407]  gic_handle_irq+0x4c/0x140
[   17.954412]  call_on_irq_stack+0x30/0x48
[   17.954419]  do_interrupt_handler+0x80/0x84
[   17.954426]  el1_interrupt+0x38/0x60
[   17.954436]  el1h_64_irq_handler+0x18/0x24
[   17.954443]  el1h_64_irq+0x6c/0x70
[   17.954448]  _raw_spin_unlock_irqrestore+0x8/0x44 (P)
[   17.954457]  wake_threads_waitq+0x60/0x70
[   17.954463]  irq_thread+0x194/0x32c
[   17.954469]  kthread+0x12c/0x204
[   17.954478]  ret_from_fork+0x10/0x20
[   17.954485] handlers:
[   18.064352] [<00000000ec900a2b>] irq_default_primary_handler threaded [<00000000a61af792>] pca953x_irq_handler
[   18.074353] Disabling IRQ #99
[   18.080294] nxp-pca9450 1-0025: pca9451a probed.

Further analysis led me to think that this is caused by the fact that
the PCAL6524 GPIO expander (1-0022) shares its interrupt line with the
USB Type C port controller (PTN5110). As soon as the first interrupt
line from the PCAL is enabled (i.e., when the PCA9451A PMIC requests
its interrupt line, which is provided by the aforementioned PCAL6524),
the corresponding parent interrupt - which is shared - is also enabled
and this causes an interrupt storm, at least until the PTN5110 driver
is probed.

The interrupt storm causes a noticeable delay during the boot sequence,
as well as the disabling of the shared IRQ #99, making the device not
really usable.

In the downstream version of u-boot, this is taken care by the support
for the TypeC port controller logic [1], which is however not available
in upstream u-boot. Until that support is added, I'd suggest to add a
workaround in here (maybe in SPL code?) that simply disables the
interrupts for the PTN5110 and clears the interrupt latch as well.
The IRQ can then be enabled in a proper way by the kernel driver.


[0] https://lore.kernel.org/all/20251114-imx91_frdm-v1-0-e5763bdf9336@nxp.com/
[1] https://github.com/nxp-imx/uboot-imx/blob/lf_v2025.04/board/freescale/common/tcpc.c#L1058


Thank you


Regards,

Francesco