-----Original Message----- From: Stephen Warren [mailto:swarren@wwwdotorg.org] Sent: Tuesday, July 28, 2015 12:27 PM To: Tom Warren Cc: u-boot@lists.denx.de; Thierry Reding; Stephen Warren; tomcwarren3959@gmail.com Subject: Re: [U-Boot] [PATCH V3 6/6] T210: Add support for 64-bit T210-based P2571 board
On 07/24/2015 04:01 PM, Tom Warren wrote:
Based on Venice2, incorporates Stephen Warren's latest P2571 pinmux table.
With Thierry Reding's 64-bit build fixes, this will build and and boot in 64-bit on my P2571 (when used with a 32-bit AVP loader).
diff --git a/board/nvidia/p2571/max77620_init.c b/board/nvidia/p2571/max77620_init.c
+void pmic_enable_cpu_vdd(void)
This function is never called, or even linked into the binary. For previous Tegra SoCs, it was called from the SPL before booting the CCPLEX. Since there is no SPL for Tegra210, nothing calls this.
- debug("%s: Set LDO2 for VDDIO_SDMMC_AP power to 3.3V\n",
__func__);
- /* 0xF2 for 3.3v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage */
- reg = 0xF200 | MAX77620_CNFG1_L2_REG;
- tegra_i2c_ll_write_addr(MAX77620_I2C_ADDR, 2);
- tegra_i2c_ll_write_data(reg, I2C_SEND_2_BYTES);
- udelay(10 * 1000);
This explains why the SD card isn't working for me on p2371-2180; I guess the PMIC OTP on that board has this regulator disabled, and since this code never runs, it never gets turned on. If I manually turn it on using the i2c command, then "mmc dev 1" works.
Makes sense. My initial development was on a 32-bit build (32-bit AVP SPL + 32-bit U-Boot CPU), so this was called from the AVP code. I still use this 32-bit AVP SPL 'portion' to load my 64-bit CPU binary, so LDO2 does get inited. Your flow is with a different AVP 32-bit 'loader', so some PMIC rails aren't set.
For p2571, I think we should either delete this file entirely. Or, at least strip it down so that it's not touching global PMIC configuration but rather just enabling any non-CCPLEX rails that U-Boot might need such as SD card and USB, then rename the function and arrange for it to be called from somewhere. I'm not sure what a good name and call-site would be yet.
Sounds reasonable. I'll look into rewriting this and calling it in the CPU binary, unless you get to it first.
Tom
-- nvpublic