-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Wednesday, March 25, 2020 12:31 PM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; Thierry Reding treding@nvidia.com; Jonathan Hunter jonathanh@nvidia.com; tomcwarren3959@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@nvidia.com wrote:
From: Tom Warren twarren@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