On 08/19/2015 07:56 AM, Thierry Reding wrote:
On Wed, Jul 29, 2015 at 02:16:33PM -0600, Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
Signed-off-by: Stephen Warren swarren@nvidia.com
v2: Use named constants for PMIC I2C and register addresses.
arch/arm/dts/Makefile | 1 + arch/arm/dts/tegra210-p2371-0000.dts | 59 +++++ arch/arm/mach-tegra/tegra210/Kconfig | 6 + board/nvidia/p2371-0000/Kconfig | 12 + board/nvidia/p2371-0000/MAINTAINERS | 6 + board/nvidia/p2371-0000/Makefile | 8 + board/nvidia/p2371-0000/p2371-0000.c | 51 ++++ board/nvidia/p2371-0000/pinmux-config-p2371-0000.h | 260 +++++++++++++++++++++ configs/p2371-0000_defconfig | 16 ++
...
Sorry for being late on this. I just rebased my tree on origin/master and got rid of my preliminary P2371 patches in favour of this only to notice that it doesn't work the way it used to. For example I used to use:
# ums 0 mmc 1
to upload kernel, DTB and such to the external SD card. Unfortunately that no longer works with this version of the patches. I tried to see what the differences are but couldn't spot anything. I see that dmesg shows a bunch of USB device reset messages, and failures to read the superblock on /dev/sdc, which is what the mass storage shows up as. I also tried porting a couple of changes from my earlier tree over to master, but to no avail.
Any ideas what could be the reason here? Does the external SD card work for anybody else?
It certainly did when I tested it. I haven't tested it on this particular board since the patch was actually applied though.
A few questions:
- Do regular filesystem commands such as part list, ls, load work on the SD card?
- Does ums work on the eMMC but not SD, or fail on both?
Perhaps related: I have just noticed that one of my SD cards works just fine in p2371-2180 but the other card doesn't. I swear they both used to work. Unfortunately I can't test those cards on p2371-0000 since it has a uSD slot instead of full-size. I've also noticed some stability issues with "ums" even on the eMMC; basic stuff like the device enumeration and various sized dd operations work fine, but mounting filesystems doesn't always work. I'll see if I can work out what's up. I wonder if the recent T210 clock driver patches had anything to do with this; IIRC they didn't exist when I first did all these board ports.
I also noticed two other things:
diff --git a/configs/p2371-0000_defconfig b/configs/p2371-0000_defconfig
[...]
+CONFIG_USE_PRIVATE_LIBGCC=y
Why do we need this?
I copied the configuration from the p2571 patches that Tom sent, to keep all the T210 boards consistent. Perhaps Tom can shed some light? FWIW, I tested removing that line for p2371-2180 and the build and boot to U-Boot prompt still seemed to work. This option might be a hold-over from previous chips where SPL existed and needed to be built with different CPU options. Perhaps we can remove this.
diff --git a/include/configs/p2371-0000.h b/include/configs/p2371-0000.h
[...]
+#define COUNTER_FREQUENCY 38400000
As far as I know the system counter is actually clocked by clk_m, which on most (all?) Tegra210 platforms will be configured to run at half the oscillator frequency (19.2 MHz). This is corroborated by the fact that running:
# sleep 5
actually takes 10 seconds rather than the expected 5. Changing the above to 19200000 fixes that.
That's odd. I just tested this on p2371-2180 which should have the same basic clock/crystal setup, and "sleep 10" takes 10 seconds. What SW are you using as the primary bootloader? I'm using nvtboot from our internal L4T main branch. Once that's released, I would expect people to use that same thing (and NVIDIAns can use it already:-)