Re: [PATCH v4 2/2] arm64: dts: freescale: add MR-NAVQ95 basic board support

[Laurentiu Mihalcea]

Hi Ahmad,

On 9/9/2026 9:20 AM, Ahmad Fatoum wrote:
> Hi,
> 
> On 9/9/26 5:39 PM, Laurentiu Mihalcea wrote:
>> From: Laurentiu Mihalcea <laurentiu.mihalcea@xxxxxxx>
>>
>> Add basic support for NXP's MR-NAVQ95 board. This board is designed for
>> robotics applications (e.g. drones, rovers, humanoids, etc..) and has the
>> following hardware feats (list is not exhaustive):
>>
>> * based on i.MX95 19x19 SoC
>> * 64GB eMMC
>> * up to 16GB of LPDDR5 memory
>> * 1 x USB 2.0 TypeC
>> * 1 x USB 3.0 TypeC
>> * 1 x RJ45 port with RTL8211 PHY
>>
>> The support targets revision B of the board.
>>
>> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@xxxxxxx>
>> ---
> 
>> +	chosen {
>> +		stdout-path = &lpuart1;
> 
> I would recommend instead "serial0:115200n8" here. This introduces no
> change for Linux, but for other consumers of the device tree, they will
> be able to agree on a common baudrate.

ACK, seems fine. If there's no other objections to this I'll make the switch
in V5.

> 
>> +	memory@80000000 {
>> +		device_type = "memory";
>> +		/* actual size filled in by the bootloader */
>> +		reg = <0x0 0x80000000 0 0x80000000>;
> 
> If the board has at least 2G always, this is fine.

the board only ships with 16GB LPDDR5 so yes, it'll always have at least 2GB.
While the current size is fine, maybe it would be better to change it to 16GB?
Will have to update the commit message as well since "up to 16GB of LPDDR5 memory"
might be a bit misleading.

my other option was to leave the size set to 0x0 like some QCOM DTSIs seem to do.
Not sure what the preferred way of handling this is?

> 
>> +&usdhc2 {
>> +	bootph-pre-ram;
>> +	bus-width = <4>;
>> +	cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
>> +	pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +	pinctrl-1 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +	pinctrl-2 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +	pinctrl-3 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
>> +	pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
> 
> Looks unexpected to have same pinctrl groups for the higher speeds.
> Are higher speed modes even possible on this board?
> 
> If not, I would suggest dropping the extra states.

The pin configuration is chosen to meet the timing requirements of the 200MHz
state. Because of this, I would expect the configuration to be appropriate for
lower frequencies as well.

The intention is to use the same configuration as MX95-19x19-EVK since, from what
I've been told, the trace lengths are similar to those of the EVK.

Thanks for taking the time to review this! :)