[PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support

[Tom Warren]

-----Original Message-----
From: Stephen Warren <swarren at wwwdotorg.org> 
Sent: Wednesday, March 25, 2020 12:31 PM
To: Tom Warren <TWarren at nvidia.com>
Cc: u-boot at lists.denx.de; Stephen Warren <swarren at nvidia.com>; Thierry Reding <treding at nvidia.com>; Jonathan Hunter <jonathanh at nvidia.com>; tomcwarren3959 at gmail.com
Subject: Re: [PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support

External email: Use caution opening links or attachments


On 3/24/20 1:03 PM, twarren at nvidia.com wrote:
> From: Tom Warren <twarren at nvidia.com>
>
> The Jetson Nano Developer Kit is a Tegra X1-based development board. 
> It is similar to Jetson TX1 but it is not pin compatible. It features 
> 4GB of LPDDR4, a SPI NOR flash for early boot firmware and an SD card 
> slot used for storage.
>
> HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 
> 2.0 and 1 USB 3.0) can be used to attach a variety of peripherals and 
> a PCI Ethernet controller provides onboard network connectivity. NVMe 
> support has also been added. Env save is at the end of QSPI (4MB-8K).
>
> A 40-pin header on the board can be used to extend the capabilities 
> and exposed interfaces of the Jetson Nano.

>  arch/arm/dts/tegra210-p3450-0000.dts | 147 
> +++++++++++++++++++++++++++++

This filename is consistent with other DT filenames in U-Boot, but there's been a movement downstream to name DT after baseboard plus module rather than combination, so tegra210-p3449-0000+p3448-0000.dts.
Either is probably fine for now since this board was released before the push towards the more descriptive naming.
[Tom] I'll stick with this naming, someone can float a change to move all Tegra boards to module+baseboard naming later if we so choose. This fits in the current U-Boot naming scheme.

> diff --git a/arch/arm/mach-tegra/board2.c 
> b/arch/arm/mach-tegra/board2.c

> +#if defined(CONFIG_DISABLE_SDMMC1_EARLY)
> +     /*
> +      * Turn off (reset/disable) SDMMC1 on Nano here, before GPIO INIT.
> +      * We do this because earlier bootloaders have enabled power to
> +      * SDMMC1 on Nano, and toggling power-gpio (PZ3) in pinmux_init()
> +      * results in power being back-driven into the SD-card and SDMMC1
> +      * HW, which is 'bad' as per the HW team.
> +      *
> +      * From the HW team: "LDO2 from the PMIC has already been set to 3.3v in
> +      * nvtboot/CBoot on Nano (for SD-card boot). So when U-Boot's GPIO_INIT
> +      * table sets PZ3 to OUT0 as per the pinmux spreadsheet, it turns off
> +      * the loadswitch. When PZ3 is 0 and not driving, essentially the SDCard
> +      * voltage turns off. Since the SDCard voltage is no longer there, the
> +      * SDMMC CLK/DAT lines are backdriving into what essentially is a
> +      * powered-off SDCard, that's why the voltage drops from 3.3V to ~1.6V"
> +      *
> +      * Note that this can probably be removed when we change over to storing
> +      * all BL components on QSPI on Nano, and U-Boot then becomes the first
> +      * one to turn on SDMMC1 power. Another fix would be to have CBoot
> +      * disable power/gate SDMMC1 off before handing off to U-Boot/kernel.
> +      */
> +     reset_set_enable(PERIPH_ID_SDMMC1, 1);
> +     clock_set_enable(PERIPH_ID_SDMMC1, 0);
> +#endif       /* CONFIG_DISABLE_SDMMC1_EARLY */

I imagine we can remove this completely now that cboot does 100% of the pinmux init, so the referenced pinmux_init() function in U-Boot no longer causes a problem?
[Tom] That's a good point, but I'll have to engage w/the HW team to see if they can set up to measure the SD-card signals again w/o this change to see if the back-driving is gone.
I'd like to leave it in, though, as a precaution so we don't damage anyone's SD-cards. If/when we can re-measure it, I can float a new patch to remove the SDMMC1_EARLY switch and/or just remove this code entirely.

> diff --git a/board/nvidia/p3450-0000/p3450-0000.c 
> b/board/nvidia/p3450-0000/p3450-0000.c

> +static void ft_carveout_setup(void *fdt)

If/when we upstream the DT node/property copying feature, can this code be replaced by simply adding extra nodes/properties to the copy list?
[Tom] Good question, I'll look into it. I still need to finesse the FDT copy feature a bit, I'll look at it then.

> diff --git a/configs/p3450-0000_defconfig 
> b/configs/p3450-0000_defconfig

> +CONFIG_DISABLE_SDMMC1_EARLY=y

We can drop this assuming the code chunk I commented on above gets dropped.
[Tom] When I can get the HW team to re-measure SD card voltages w/o this I'll float a patch to remove it, assuming it looks good.

> +CONFIG_NVME=y

Does this work already? I thought it was still under development for Tegra.
[Tom] Yep, I bought a M.2 E key -> M.2 NVMe adapter for Nano & put a WD Black NVMe stick in it, and I can see/read/write the NVMe device in U-Boot using the 'nvme' commands. And it visible in the kernel.  So for T210, it works (in U-Boot). Supporting NVMe in other bootloaders/SoCs that don’t use U-Boot is still a WIP.

--nvpublic