[PATCH 0/5] Misc fixes for Tegra
From: Tom Warren twarren@nvidia.com
These fixes originated on our downstream L4T U-Boot, and include fdt, pinmux, pll and code relocation changes.
JC Kuo (1): t210: do not enable PLLE and UPHY PLL HW PWRSEQ
Stephen Warren (1): ARM: tegra: rework fdt_serial_tag_setup_one
Tom Warren (2): fdt: Fix 'system' command ARM: Tegra: Use calculated env var feature on all T186/T210 boards
Vishruth (1): ARM: tegra: p2771-0000: enable PIE relocation
arch/arm/cpu/armv8/cpu.c | 5 ++ arch/arm/include/asm/arch-tegra/xusb-padctl.h | 1 + arch/arm/mach-tegra/board2.c | 6 +++ arch/arm/mach-tegra/ft_board_info.c | 77 +++++++++++++++++++++++++++ arch/arm/mach-tegra/ft_board_info.h | 23 ++++++++ arch/arm/mach-tegra/tegra210/clock.c | 19 ------- arch/arm/mach-tegra/tegra210/xusb-padctl.c | 68 ++++++++++++++--------- arch/arm/mach-tegra/xusb-padctl-dummy.c | 4 ++ cmd/fdt.c | 2 +- configs/p2771-0000-000_defconfig | 1 + configs/p2771-0000-500_defconfig | 1 + include/configs/p2771-0000.h | 23 +------- include/configs/tegra186-common.h | 22 +++++++- include/configs/tegra210-common.h | 23 ++++++-- 14 files changed, 204 insertions(+), 71 deletions(-) create mode 100644 arch/arm/mach-tegra/ft_board_info.c create mode 100644 arch/arm/mach-tegra/ft_board_info.h
From: Stephen Warren swarren@nvidia.com
Reword fdt_serial_tag_setup_one() so that the types it uses aren't tied to CONFIG_SERIAL_TAG, and rename the function to better indicate its purpose. This will allow it to be re-used by future board info related code.
Signed-off-by: Stephen Warren swarren@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com --- arch/arm/mach-tegra/ft_board_info.c | 77 +++++++++++++++++++++++++++++++++++++ arch/arm/mach-tegra/ft_board_info.h | 23 +++++++++++ 2 files changed, 100 insertions(+) create mode 100644 arch/arm/mach-tegra/ft_board_info.c create mode 100644 arch/arm/mach-tegra/ft_board_info.h
diff --git a/arch/arm/mach-tegra/ft_board_info.c b/arch/arm/mach-tegra/ft_board_info.c new file mode 100644 index 0000000..7dd3a40 --- /dev/null +++ b/arch/arm/mach-tegra/ft_board_info.c @@ -0,0 +1,77 @@ +/* + * (C) Copyright 2010-2016 + * NVIDIA Corporation <www.nvidia.com> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <fdt_support.h> +#include <fdtdec.h> +#include "ft_board_info.h" + +int ft_board_info_set(void *blob, const struct ft_board_info *bi, + const char *chosen_subnode_name) +{ + int chosen, offset, ret; + u32 val; + + chosen = fdt_path_offset(blob, "/chosen"); + if (!chosen) { + chosen = fdt_add_subnode(blob, 0, "chosen"); + if (chosen < 0) { + error("fdt_add_subnode(/, chosen) failed: %s.\n", + fdt_strerror(chosen)); + return chosen; + } + } + + offset = fdt_add_subnode(blob, chosen, chosen_subnode_name); + if (offset < 0) { + error("fdt_add_subnode(/chosen, %s): %s.\n", + chosen_subnode_name, fdt_strerror(offset)); + return offset; + } + + val = cpu_to_fdt32(bi->id); + ret = fdt_setprop(blob, offset, "id", &val, sizeof(val)); + if (ret < 0) { + error("could not update id property %s.\n", + fdt_strerror(ret)); + return ret; + } + + val = cpu_to_fdt32(bi->sku); + ret = fdt_setprop(blob, offset, "sku", &val, sizeof(val)); + if (ret < 0) { + error("could not update sku property %s.\n", + fdt_strerror(ret)); + return ret; + } + + val = cpu_to_fdt32(bi->fab); + ret = fdt_setprop(blob, offset, "fab", &val, sizeof(val)); + if (ret < 0) { + error("could not update fab property %s.\n", + fdt_strerror(ret)); + return ret; + } + + val = cpu_to_fdt32(bi->major); + ret = fdt_setprop(blob, offset, "major_revision", &val, sizeof(val)); + if (ret < 0) { + error("could not update major_revision property %s.\n", + fdt_strerror(ret)); + return ret; + } + + val = cpu_to_fdt32(bi->minor); + ret = fdt_setprop(blob, offset, "minor_revision", &val, sizeof(val)); + if (ret < 0) { + error("could not update minor_revision property %s.\n", + fdt_strerror(ret)); + return ret; + } + + return 0; +} diff --git a/arch/arm/mach-tegra/ft_board_info.h b/arch/arm/mach-tegra/ft_board_info.h new file mode 100644 index 0000000..c320aee --- /dev/null +++ b/arch/arm/mach-tegra/ft_board_info.h @@ -0,0 +1,23 @@ +/* + * Board info related definitions + * + * (C) Copyright 2015 NVIDIA Corporation <www.nvidia.com> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#ifndef _BOARD_INFO_H_ +#define _BOARD_INFO_H_ + +struct ft_board_info { + u32 id; + u32 sku; + u32 fab; + u32 major; + u32 minor; +}; + +int ft_board_info_set(void *blob, const struct ft_board_info *bi, + const char *chosen_subnode_name); + +#endif
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Stephen Warren swarren@nvidia.com
Reword fdt_serial_tag_setup_one() so that the types it uses aren't tied to CONFIG_SERIAL_TAG, and rename the function to better indicate its purpose. This will allow it to be re-used by future board info related code.
arch/arm/mach-tegra/ft_board_info.c | 77 +++++++++++++++++++++++++++++++++++++ arch/arm/mach-tegra/ft_board_info.h | 23 +++++++++++
I don't think this series was based on upstream, or there are missing patches in between upstream and this series; those files don't exist upstream.
On 3/17/20 11:16 AM, Stephen Warren wrote:
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Stephen Warren swarren@nvidia.com
Reword fdt_serial_tag_setup_one() so that the types it uses aren't tied to CONFIG_SERIAL_TAG, and rename the function to better indicate its purpose. This will allow it to be re-used by future board info related code.
arch/arm/mach-tegra/ft_board_info.c | 77 +++++++++++++++++++++++++++++++++++++ arch/arm/mach-tegra/ft_board_info.h | 23 +++++++++++
I don't think this series was based on upstream, or there are missing patches in between upstream and this series; those files don't exist upstream.
Oh. This patch adds those files. But the commit description says it's reworking some existing logic. I guess the description is from some squashed patch, and doesn't describe what the patch actually does? Also, the new file isn't added to any Makefile, and no edits are made to any other file in order to call the newly added functionality.
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:18 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: Re: [PATCH 1/5] ARM: tegra: rework fdt_serial_tag_setup_one
External email: Use caution opening links or attachments
On 3/17/20 11:16 AM, Stephen Warren wrote:
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Stephen Warren swarren@nvidia.com
Reword fdt_serial_tag_setup_one() so that the types it uses aren't tied to CONFIG_SERIAL_TAG, and rename the function to better indicate its purpose. This will allow it to be re-used by future board info related code.
arch/arm/mach-tegra/ft_board_info.c | 77 +++++++++++++++++++++++++++++++++++++ arch/arm/mach-tegra/ft_board_info.h | 23 +++++++++++
I don't think this series was based on upstream, or there are missing patches in between upstream and this series; those files don't exist upstream.
Oh. This patch adds those files. But the commit description says it's reworking some existing logic. I guess the description is from some squashed patch, and doesn't describe what the patch actually does? Also, the new file isn't added to any Makefile, and no edits are made to any other file in order to call the newly added functionality. [Tom] Yeah, this got messed up when I squashed/edited the transition from nvtboot to cboot support files in arch/arm/mach-tegra. I'll have to revisit this, as the code isn't called anywhere currently in my upstream work, nor build by a Makefile.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
-----Original Message----- From: Tom Warren Sent: Tuesday, March 17, 2020 10:43 AM To: Stephen Warren swarren@wwwdotorg.org Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com; tomcwarren3959@gmail.com Subject: RE: [PATCH 1/5] ARM: tegra: rework fdt_serial_tag_setup_one
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:18 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Stephen Warren swarren@nvidia.com Subject: Re: [PATCH 1/5] ARM: tegra: rework fdt_serial_tag_setup_one
External email: Use caution opening links or attachments
On 3/17/20 11:16 AM, Stephen Warren wrote:
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Stephen Warren swarren@nvidia.com
Reword fdt_serial_tag_setup_one() so that the types it uses aren't tied to CONFIG_SERIAL_TAG, and rename the function to better indicate its purpose. This will allow it to be re-used by future board info related code.
arch/arm/mach-tegra/ft_board_info.c | 77 +++++++++++++++++++++++++++++++++++++ arch/arm/mach-tegra/ft_board_info.h | 23 +++++++++++
I don't think this series was based on upstream, or there are missing patches in between upstream and this series; those files don't exist upstream.
Oh. This patch adds those files. But the commit description says it's reworking some existing logic. I guess the description is from some squashed patch, and doesn't describe what the patch actually does? Also, the new file isn't added to any Makefile, and no edits are made to any other file in order to call the newly added functionality. [Tom] Yeah, this got messed up when I squashed/edited the transition from nvtboot to cboot support files in arch/arm/mach-tegra. I'll have to revisit this, as the code isn't called anywhere currently in my upstream work, nor build by a Makefile. [Tom] OK, so this work (adding board info (proc/pmu/display) is already done by CBoot on T210 before we get to U-Boot, so it's not needed. Mea culpa - lots of churn w/these patches, trying to get them squashed/optimized for upstreaming, and I mistakenly kept this one around from the nvtboot->U-Boot days. I'll drop it.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
From: JC Kuo jckuo@nvidia.com
This commit removes the programming sequence that enables PLLE and UPHY PLL hardware power sequencers. Per TRM, boot software should enable PLLE and UPHY PLLs in software controlled power-on state and should power down PLL before jumping into kernel or the next stage boot software.
Adds call to board_cleanup_before_linux to facilitate this.
Signed-off-by: JC Kuo jckuo@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com --- arch/arm/cpu/armv8/cpu.c | 5 ++ arch/arm/include/asm/arch-tegra/xusb-padctl.h | 1 + arch/arm/mach-tegra/board2.c | 6 +++ arch/arm/mach-tegra/tegra210/clock.c | 19 -------- arch/arm/mach-tegra/tegra210/xusb-padctl.c | 68 +++++++++++++++++---------- arch/arm/mach-tegra/xusb-padctl-dummy.c | 4 ++ 6 files changed, 59 insertions(+), 44 deletions(-)
diff --git a/arch/arm/cpu/armv8/cpu.c b/arch/arm/cpu/armv8/cpu.c index 2467e0b..3575203 100644 --- a/arch/arm/cpu/armv8/cpu.c +++ b/arch/arm/cpu/armv8/cpu.c @@ -32,6 +32,8 @@ void sdelay(unsigned long loops) "b.ne 1b" : "=r" (loops) : "0"(loops) : "cc"); }
+void __weak board_cleanup_before_linux(void){} + int cleanup_before_linux(void) { /* @@ -40,6 +42,9 @@ int cleanup_before_linux(void) * * disable interrupt and turn off caches etc ... */ + + board_cleanup_before_linux(); + disable_interrupts();
/* diff --git a/arch/arm/include/asm/arch-tegra/xusb-padctl.h b/arch/arm/include/asm/arch-tegra/xusb-padctl.h index deccdf4..7e14d81 100644 --- a/arch/arm/include/asm/arch-tegra/xusb-padctl.h +++ b/arch/arm/include/asm/arch-tegra/xusb-padctl.h @@ -16,6 +16,7 @@ struct tegra_xusb_phy; struct tegra_xusb_phy *tegra_xusb_phy_get(unsigned int type);
void tegra_xusb_padctl_init(void); +void tegra_xusb_padctl_exit(void); int tegra_xusb_phy_prepare(struct tegra_xusb_phy *phy); int tegra_xusb_phy_enable(struct tegra_xusb_phy *phy); int tegra_xusb_phy_disable(struct tegra_xusb_phy *phy); diff --git a/arch/arm/mach-tegra/board2.c b/arch/arm/mach-tegra/board2.c index d3497a2..787ff97 100644 --- a/arch/arm/mach-tegra/board2.c +++ b/arch/arm/mach-tegra/board2.c @@ -181,6 +181,12 @@ int board_init(void) return nvidia_board_init(); }
+void board_cleanup_before_linux(void) +{ + /* power down UPHY PLL */ + tegra_xusb_padctl_exit(); +} + #ifdef CONFIG_BOARD_EARLY_INIT_F static void __gpio_early_init(void) { diff --git a/arch/arm/mach-tegra/tegra210/clock.c b/arch/arm/mach-tegra/tegra210/clock.c index b240860..f1b25e2 100644 --- a/arch/arm/mach-tegra/tegra210/clock.c +++ b/arch/arm/mach-tegra/tegra210/clock.c @@ -1235,25 +1235,6 @@ int tegra_plle_enable(void) value &= ~PLLE_SS_CNTL_INTERP_RESET; writel(value, NV_PA_CLK_RST_BASE + PLLE_SS_CNTL);
- /* 7. Enable HW power sequencer for PLLE */ - - value = readl(NV_PA_CLK_RST_BASE + PLLE_MISC); - value &= ~PLLE_MISC_IDDQ_SWCTL; - writel(value, NV_PA_CLK_RST_BASE + PLLE_MISC); - - value = readl(NV_PA_CLK_RST_BASE + PLLE_AUX); - value &= ~PLLE_AUX_SS_SWCTL; - value &= ~PLLE_AUX_ENABLE_SWCTL; - value |= PLLE_AUX_SS_SEQ_INCLUDE; - value |= PLLE_AUX_USE_LOCKDET; - writel(value, NV_PA_CLK_RST_BASE + PLLE_AUX); - - /* 8. Wait 1 us */ - - udelay(1); - value |= PLLE_AUX_SEQ_ENABLE; - writel(value, NV_PA_CLK_RST_BASE + PLLE_AUX); - return 0; }
diff --git a/arch/arm/mach-tegra/tegra210/xusb-padctl.c b/arch/arm/mach-tegra/tegra210/xusb-padctl.c index ab6684f..64dc297 100644 --- a/arch/arm/mach-tegra/tegra210/xusb-padctl.c +++ b/arch/arm/mach-tegra/tegra210/xusb-padctl.c @@ -170,6 +170,17 @@ static int phy_unprepare(struct tegra_xusb_phy *phy) return tegra_xusb_padctl_disable(phy->padctl); }
+#define XUSB_PADCTL_USB3_PAD_MUX 0x28 +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE (1 << 0) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK0 (1 << 1) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK1 (1 << 2) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK2 (1 << 3) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK3 (1 << 4) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK4 (1 << 5) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK5 (1 << 6) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK6 (1 << 7) +#define XUSB_PADCTL_USB3_PAD_MUX_FORCE_SATA_PAD_IDDQ_DISABLE_MASK0 (1 << 8) + #define XUSB_PADCTL_UPHY_PLL_P0_CTL1 0x360 #define XUSB_PADCTL_UPHY_PLL_P0_CTL1_FREQ_NDIV_MASK (0xff << 20) #define XUSB_PADCTL_UPHY_PLL_P0_CTL1_FREQ_NDIV(x) (((x) & 0xff) << 20) @@ -366,31 +377,6 @@ static int pcie_phy_enable(struct tegra_xusb_phy *phy) value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL8_RCAL_CLK_EN; padctl_writel(padctl, value, XUSB_PADCTL_UPHY_PLL_P0_CTL8);
- value = readl(NV_PA_CLK_RST_BASE + CLK_RST_XUSBIO_PLL_CFG0); - value &= ~CLK_RST_XUSBIO_PLL_CFG0_PADPLL_RESET_SWCTL; - value &= ~CLK_RST_XUSBIO_PLL_CFG0_CLK_ENABLE_SWCTL; - value |= CLK_RST_XUSBIO_PLL_CFG0_PADPLL_USE_LOCKDET; - value |= CLK_RST_XUSBIO_PLL_CFG0_PADPLL_SLEEP_IDDQ; - writel(value, NV_PA_CLK_RST_BASE + CLK_RST_XUSBIO_PLL_CFG0); - - value = padctl_readl(padctl, XUSB_PADCTL_UPHY_PLL_P0_CTL1); - value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL1_PWR_OVRD; - padctl_writel(padctl, value, XUSB_PADCTL_UPHY_PLL_P0_CTL1); - - value = padctl_readl(padctl, XUSB_PADCTL_UPHY_PLL_P0_CTL2); - value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL2_CAL_OVRD; - padctl_writel(padctl, value, XUSB_PADCTL_UPHY_PLL_P0_CTL2); - - value = padctl_readl(padctl, XUSB_PADCTL_UPHY_PLL_P0_CTL8); - value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL8_RCAL_OVRD; - padctl_writel(padctl, value, XUSB_PADCTL_UPHY_PLL_P0_CTL8); - - udelay(1); - - value = readl(NV_PA_CLK_RST_BASE + CLK_RST_XUSBIO_PLL_CFG0); - value |= CLK_RST_XUSBIO_PLL_CFG0_SEQ_ENABLE; - writel(value, NV_PA_CLK_RST_BASE + CLK_RST_XUSBIO_PLL_CFG0); - debug("< %s()\n", __func__); return 0; } @@ -454,3 +440,35 @@ void tegra_xusb_padctl_init(void) ret = tegra_xusb_process_nodes(nodes, count, &tegra210_socdata); debug("%s: done, ret=%d\n", __func__, ret); } + +void tegra_xusb_padctl_exit(void) +{ + u32 value; + + debug("> %s\n", __func__); + + value = padctl_readl(&padctl, XUSB_PADCTL_USB3_PAD_MUX); + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK0; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK1; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK2; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK3; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK4; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK5; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_PCIE_PAD_IDDQ_DISABLE_MASK6; + value &= ~XUSB_PADCTL_USB3_PAD_MUX_FORCE_SATA_PAD_IDDQ_DISABLE_MASK0; + padctl_writel(&padctl, value, XUSB_PADCTL_USB3_PAD_MUX); + + value = padctl_readl(&padctl, XUSB_PADCTL_UPHY_PLL_P0_CTL1); + value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL1_IDDQ; + value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL1_SLEEP_MASK; + value |= XUSB_PADCTL_UPHY_PLL_P0_CTL1_SLEEP(3); + value &= ~XUSB_PADCTL_UPHY_PLL_P0_CTL1_ENABLE; + padctl_writel(&padctl, value, XUSB_PADCTL_UPHY_PLL_P0_CTL1); + + reset_set_enable(PERIPH_ID_PEX_USB_UPHY, 1); + while (padctl.enable) + tegra_xusb_padctl_disable(&padctl); + + debug("< %s()\n", __func__); +} diff --git a/arch/arm/mach-tegra/xusb-padctl-dummy.c b/arch/arm/mach-tegra/xusb-padctl-dummy.c index 3ec27a2..f2d9030 100644 --- a/arch/arm/mach-tegra/xusb-padctl-dummy.c +++ b/arch/arm/mach-tegra/xusb-padctl-dummy.c @@ -36,3 +36,7 @@ int __weak tegra_xusb_phy_unprepare(struct tegra_xusb_phy *phy) void __weak tegra_xusb_padctl_init(void) { } + +void __weak tegra_xusb_padctl_exit(void) +{ +}
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: JC Kuo jckuo@nvidia.com
This commit removes the programming sequence that enables PLLE and UPHY PLL hardware power sequencers. Per TRM, boot software should enable PLLE and UPHY PLLs in software controlled power-on state and should power down PLL before jumping into kernel or the next stage boot software.
Adds call to board_cleanup_before_linux to facilitate this.
This directly contradicts what's in Tegra_X1_TRM_DP07225001_v1.3p.pdf, pages 1340/1341, which is what the code currently implements. Was a newer internal-only TRM published that changed the recommended programming flow?
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:30 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Jui Chang Kuo jckuo@nvidia.com Subject: Re: [PATCH 2/5] t210: do not enable PLLE and UPHY PLL HW PWRSEQ
External email: Use caution opening links or attachments
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: JC Kuo jckuo@nvidia.com
This commit removes the programming sequence that enables PLLE and UPHY PLL hardware power sequencers. Per TRM, boot software should enable PLLE and UPHY PLLs in software controlled power-on state and should power down PLL before jumping into kernel or the next stage boot software.
Adds call to board_cleanup_before_linux to facilitate this.
This directly contradicts what's in Tegra_X1_TRM_DP07225001_v1.3p.pdf, pages 1340/1341, which is what the code currently implements. Was a newer internal-only TRM published that changed the recommended programming flow? [Tom] JC wrote this, I'll let him answer, but I'll check my TRM to see what the most recent version is. This code is exactly what we have in downstream T210 U-Boot.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
Please refer to "Notes" section in p1337 of Tegra_X1_TRM_DP07225001_v1.3p.pdf. There are some implementation considerations for boot software.
Thanks, JC
On 3/18/20 1:44 AM, Tom Warren wrote:
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:30 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Jui Chang Kuo jckuo@nvidia.com Subject: Re: [PATCH 2/5] t210: do not enable PLLE and UPHY PLL HW PWRSEQ
External email: Use caution opening links or attachments
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: JC Kuo jckuo@nvidia.com
This commit removes the programming sequence that enables PLLE and UPHY PLL hardware power sequencers. Per TRM, boot software should enable PLLE and UPHY PLLs in software controlled power-on state and should power down PLL before jumping into kernel or the next stage boot software.
Adds call to board_cleanup_before_linux to facilitate this.
This directly contradicts what's in Tegra_X1_TRM_DP07225001_v1.3p.pdf, pages 1340/1341, which is what the code currently implements. Was a newer internal-only TRM published that changed the recommended programming flow? [Tom] JC wrote this, I'll let him answer, but I'll check my TRM to see what the most recent version is. This code is exactly what we have in downstream T210 U-Boot.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
On 3/17/20 7:44 PM, JC Kuo wrote:
Please refer to "Notes" section in p1337 of Tegra_X1_TRM_DP07225001_v1.3p.pdf. There are some implementation considerations for boot software.
OK, I assume you mean this note:
Boot loader should not enable hardware power sequencer. Boot loader should enable the required PLLs in software controlled state.
That's interesting, since I explicitly added the code to program PLLE in HW controlled mode after discussing with the relevant HW engineers the need to clean up the programming sequence in the following pages, and it was clearly communicated that this was in the context of a bootloader, and they pointed out that the bootloader needed to enable HW control but didn't. Sigh. I guess I should have read the sections prior to the programming sequence too.
So I guess this change is OK, and since we have it downstream it seems to operate OK in practice too.
Acked-by: Stephen Warren swarren@nvidia.com
Thanks, JC
On 3/18/20 1:44 AM, Tom Warren wrote:
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:30 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de; Jui Chang Kuo jckuo@nvidia.com Subject: Re: [PATCH 2/5] t210: do not enable PLLE and UPHY PLL HW PWRSEQ
External email: Use caution opening links or attachments
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: JC Kuo jckuo@nvidia.com
This commit removes the programming sequence that enables PLLE and UPHY PLL hardware power sequencers. Per TRM, boot software should enable PLLE and UPHY PLLs in software controlled power-on state and should power down PLL before jumping into kernel or the next stage boot software.
Adds call to board_cleanup_before_linux to facilitate this.
This directly contradicts what's in Tegra_X1_TRM_DP07225001_v1.3p.pdf, pages 1340/1341, which is what the code currently implements. Was a newer internal-only TRM published that changed the recommended programming flow? [Tom] JC wrote this, I'll let him answer, but I'll check my TRM to see what the most recent version is. This code is exactly what we have in downstream T210 U-Boot.
This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
From: Vishruth vishruthj@nvidia.com
U-Boot is configured to build as position independent executable. Enable relocation of RELA section required to work with different load addresses.
Signed-off-by: Vishruth vishruthj@nvidia.com Signed-off-by: Tom Warren twarren@nvidia.com --- configs/p2771-0000-000_defconfig | 1 + configs/p2771-0000-500_defconfig | 1 + 2 files changed, 2 insertions(+)
diff --git a/configs/p2771-0000-000_defconfig b/configs/p2771-0000-000_defconfig index 06f12e2..e347a77 100644 --- a/configs/p2771-0000-000_defconfig +++ b/configs/p2771-0000-000_defconfig @@ -36,3 +36,4 @@ CONFIG_TEGRA186_POWER_DOMAIN=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y +CONFIG_POSITION_INDEPENDENT=y diff --git a/configs/p2771-0000-500_defconfig b/configs/p2771-0000-500_defconfig index 1a14a92..0803b26 100644 --- a/configs/p2771-0000-500_defconfig +++ b/configs/p2771-0000-500_defconfig @@ -36,3 +36,4 @@ CONFIG_TEGRA186_POWER_DOMAIN=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y +CONFIG_POSITION_INDEPENDENT=y
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Vishruth vishruthj@nvidia.com
U-Boot is configured to build as position independent executable. Enable relocation of RELA section required to work with different load addresses.
Reviewed-by: Stephen Warren swarren@nvidia.com
From: Tom Warren twarren@nvidia.com
'fdt systemsetup' wasn't working, due to the fact that the 'set' command was being parsed in do_fdt() by only testing for the leading 's' instead of "se", which kept the "sys" test further down from executing. Changed to test for "se" instead, now 'fdt systemsetup' works (to test the ft_system_setup proc w/o having to boot a kernel).
Signed-off-by: Tom Warren twarren@nvidia.com --- cmd/fdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c index 25a6ed4..36cc726 100644 --- a/cmd/fdt.c +++ b/cmd/fdt.c @@ -286,7 +286,7 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) /* * Set the value of a property in the working_fdt. */ - } else if (argv[1][0] == 's') { + } else if (strncmp(argv[1], "se", 2) == 0) { char *pathp; /* path */ char *prop; /* property */ int nodeoffset; /* node offset from libfdt */
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
'fdt systemsetup' wasn't working, due to the fact that the 'set' command was being parsed in do_fdt() by only testing for the leading 's' instead of "se", which kept the "sys" test further down from executing. Changed to test for "se" instead, now 'fdt systemsetup' works (to test the ft_system_setup proc w/o having to boot a kernel).
Reviewed-by: Stephen Warren swarren@nvidia.com
(Although I wonder if this shouldn't just test the entire string to avoid any possible future ambiguity if more sub-commands are added later. Or doesn't U-Boot already have some sub-command table infra-structure this could use?)
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:33 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de Subject: Re: [PATCH 4/5] fdt: Fix 'system' command
External email: Use caution opening links or attachments
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
'fdt systemsetup' wasn't working, due to the fact that the 'set' command was being parsed in do_fdt() by only testing for the leading 's' instead of "se", which kept the "sys" test further down from executing. Changed to test for "se" instead, now 'fdt systemsetup' works (to test the ft_system_setup proc w/o having to boot a kernel).
Reviewed-by: Stephen Warren swarren@nvidia.com
(Although I wonder if this shouldn't just test the entire string to avoid any possible future ambiguity if more sub-commands are added later. Or doesn't U-Boot already have some sub-command table infra-structure this could use?) [Tom] I usually take the path of least rework approach, so I just fixed the systemsetup command, which is what I was interested in. Let's see if any other Denxians chime in w/their opinion, and I can rework it if needed.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
From: Tom Warren twarren@nvidia.com
Large kernels (>32MB) can fail to boot because they overwrite the FDT address, corrupting the DTB. Stephen Warren had created a fix to dynamically adjust the fdt/ramdisk/pxefile/kernel addr vars at boot time for T186, which allows a large kernel to load and boot.
This is based on his commit, but applied to the tegraXXX-common.h headers so it's used on all T186 and T210 Jetson boards. Note that I've put the kernel 'size' param at 0x03000000, or 48MB, to leave room for kernel growth. Current L4T kernels are running at about 32MB.
Signed-off-by: Tom Warren twarren@nvidia.com --- include/configs/p2771-0000.h | 23 ++--------------------- include/configs/tegra186-common.h | 22 ++++++++++++++++++++-- include/configs/tegra210-common.h | 23 ++++++++++++++++++++--- 3 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/include/configs/p2771-0000.h b/include/configs/p2771-0000.h index 7c6d68a..90d764f 100644 --- a/include/configs/p2771-0000.h +++ b/include/configs/p2771-0000.h @@ -1,6 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* - * Copyright (c) 2013-2016, NVIDIA CORPORATION. + * Copyright (c) 2013-2020, NVIDIA CORPORATION. + * */
#ifndef _P2771_0000_H @@ -17,26 +18,6 @@ #define CONFIG_SYS_MMC_ENV_DEV 0 #define CONFIG_SYS_MMC_ENV_PART 2
-#define BOARD_EXTRA_ENV_SETTINGS \ - "calculated_vars=kernel_addr_r fdt_addr_r scriptaddr pxefile_addr_r " \ - "ramdisk_addr_r\0" \ - "kernel_addr_r_align=00200000\0" \ - "kernel_addr_r_offset=00080000\0" \ - "kernel_addr_r_size=02000000\0" \ - "kernel_addr_r_aliases=loadaddr\0" \ - "fdt_addr_r_align=00200000\0" \ - "fdt_addr_r_offset=00000000\0" \ - "fdt_addr_r_size=00200000\0" \ - "scriptaddr_align=00200000\0" \ - "scriptaddr_offset=00000000\0" \ - "scriptaddr_size=00200000\0" \ - "pxefile_addr_r_align=00200000\0" \ - "pxefile_addr_r_offset=00000000\0" \ - "pxefile_addr_r_size=00200000\0" \ - "ramdisk_addr_r_align=00200000\0" \ - "ramdisk_addr_r_offset=00000000\0" \ - "ramdisk_addr_r_size=02000000\0" - #include "tegra-common-post.h"
/* Crystal is 38.4MHz. clk_m runs at half that rate */ diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h index b4936cc..e88e68d 100644 --- a/include/configs/tegra186-common.h +++ b/include/configs/tegra186-common.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* - * Copyright 2013-2016, NVIDIA CORPORATION. + * Copyright (c) 2013-2020, NVIDIA CORPORATION. */
#ifndef _TEGRA186_COMMON_H_ @@ -50,6 +50,24 @@ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "fdt_addr_r=0x82000000\0" \ - "ramdisk_addr_r=0x82100000\0" + "ramdisk_addr_r=0x82100000\0" \ + "calculated_vars=kernel_addr_r fdt_addr_r scriptaddr pxefile_addr_r " \ + "ramdisk_addr_r\0" \ + "kernel_addr_r_align=00200000\0" \ + "kernel_addr_r_offset=00080000\0" \ + "kernel_addr_r_size=03000000\0" \ + "kernel_addr_r_aliases=loadaddr\0" \ + "fdt_addr_r_align=00200000\0" \ + "fdt_addr_r_offset=00000000\0" \ + "fdt_addr_r_size=00200000\0" \ + "scriptaddr_align=00200000\0" \ + "scriptaddr_offset=00000000\0" \ + "scriptaddr_size=00200000\0" \ + "pxefile_addr_r_align=00200000\0" \ + "pxefile_addr_r_offset=00000000\0" \ + "pxefile_addr_r_size=00200000\0" \ + "ramdisk_addr_r_align=00200000\0" \ + "ramdisk_addr_r_offset=00000000\0" \ + "ramdisk_addr_r_size=02000000\0"
#endif diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index 1c53311..0d15b30 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -1,7 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * (C) Copyright 2013-2015 - * NVIDIA Corporation <www.nvidia.com> + * Copyright (c) 2013-2020, NVIDIA CORPORATION. */
#ifndef _TEGRA210_COMMON_H_ @@ -47,7 +46,25 @@ "pxefile_addr_r=0x90100000\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ "fdt_addr_r=0x82000000\0" \ - "ramdisk_addr_r=0x82100000\0" + "ramdisk_addr_r=0x82100000\0" \ + "calculated_vars=kernel_addr_r fdt_addr_r scriptaddr pxefile_addr_r " \ + "ramdisk_addr_r\0" \ + "kernel_addr_r_align=00200000\0" \ + "kernel_addr_r_offset=00080000\0" \ + "kernel_addr_r_size=03000000\0" \ + "kernel_addr_r_aliases=loadaddr\0" \ + "fdt_addr_r_align=00200000\0" \ + "fdt_addr_r_offset=00000000\0" \ + "fdt_addr_r_size=00200000\0" \ + "scriptaddr_align=00200000\0" \ + "scriptaddr_offset=00000000\0" \ + "scriptaddr_size=00200000\0" \ + "pxefile_addr_r_align=00200000\0" \ + "pxefile_addr_r_offset=00000000\0" \ + "pxefile_addr_r_size=00200000\0" \ + "ramdisk_addr_r_align=00200000\0" \ + "ramdisk_addr_r_offset=00000000\0" \ + "ramdisk_addr_r_size=02000000\0"
/* For USB EHCI controller */ #define CONFIG_EHCI_IS_TDI
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
Large kernels (>32MB) can fail to boot because they overwrite the FDT address, corrupting the DTB. Stephen Warren had created a fix to dynamically adjust the fdt/ramdisk/pxefile/kernel addr vars at boot time for T186, which allows a large kernel to load and boot.
That was actually done to support holes in the RAM map; it's not actually required in order to support large kernels at all. We could just as easily directly modify the existing hard-coded load addresses.
This is based on his commit, but applied to the tegraXXX-common.h headers so it's used on all T186 and T210 Jetson boards. Note that I've put the kernel 'size' param at 0x03000000, or 48MB, to leave room for kernel growth. Current L4T kernels are running at about 32MB.
I had completely forgotten that we had the calculated env vars feature upstream already!
I thought we went with 96 or 128MB space for the kernel downstream, to make sure there'd "never" any future problem as the kernel grows?
But this patch seems OK for now I guess.
-----Original Message----- From: Stephen Warren swarren@wwwdotorg.org Sent: Tuesday, March 17, 2020 10:38 AM To: Tom Warren TWarren@nvidia.com Cc: u-boot@lists.denx.de Subject: Re: [PATCH 5/5] ARM: Tegra: Use calc env var feature on all boards
External email: Use caution opening links or attachments
On 3/16/20 1:40 PM, twarren@nvidia.com wrote:
From: Tom Warren twarren@nvidia.com
Large kernels (>32MB) can fail to boot because they overwrite the FDT address, corrupting the DTB. Stephen Warren had created a fix to dynamically adjust the fdt/ramdisk/pxefile/kernel addr vars at boot time for T186, which allows a large kernel to load and boot.
That was actually done to support holes in the RAM map; it's not actually required in order to support large kernels at all. We could just as easily directly modify the existing hard-coded load addresses.
This is based on his commit, but applied to the tegraXXX-common.h headers so it's used on all T186 and T210 Jetson boards. Note that I've put the kernel 'size' param at 0x03000000, or 48MB, to leave room for kernel growth. Current L4T kernels are running at about 32MB.
I had completely forgotten that we had the calculated env vars feature upstream already!
I thought we went with 96 or 128MB space for the kernel downstream, to make sure there'd "never" any future problem as the kernel grows?
But this patch seems OK for now I guess. [Tom] Yes, we have a large (128MB) kernel size in downstream L4T U-Boot, but only because of the need to test GCOV kernels - I didn't think that excessive allocation was required upstream, so I backed it off to 48MB. As to your point about just fixing the hard-coding of the kernel/ramdisk/fdt_addr_r in T210, I can do that, but it seemed more elegant and future-proof to use the calc env vars code you'd added for T186, plus it brings the two builds in sync, using the same allocation strategy for these 'load' vars.
----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------
participants (4)
-
JC Kuo -
Stephen Warren -
Tom Warren -
twarren＠nvidia.com