On Wed, Aug 19, 2015 at 11:41:09AM -0600, Stephen Warren wrote:
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?
eMMC seems to work better. I see various partitions detected on the /dev/sdc device and I don't see device reset messages. But I do see other issues that are similar as for the SD card.
I didn't mention that before, but when I run
# ums 0 mmc 1
I have trouble interrupting it using Ctrl+C. This used to work fine but for some reason this isn't working reliably anymore. I have to keep pressing Ctrl+C for half a minute or so before it reacts.
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.
My recollection is that we needed this in order for SPL to be linked against a custom version of libgcc, because the default libgcc provided by the cross-compiler would typically be optimized for ARMv7 and crash on the AVP (ARMv4). I think the string functions were the problematic parts. Given that we don't have the split architecture issue with U-Boot on Tegra210, there's no longer a need to build the private version. I've successfully been booting U-Boot for a long time without it.
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:-)
That's odd. The miniloader that I use was "inspired" by nvtboot, so it uses mostly the same initialization. It then goes and implements the old RCM/nv3p protocol so that it can be used in conjunction with tegrarcm rather than the newer flashing tools that L4T provides.
That said, it seems to me like there might be a difference between how nvtboot and the miniloader that I use set up clocks, resulting in this discrepancy. So hard-coding the frequency may not be a good option because it would be assuming primary bootloader behaviour. I do have a couple of patches in my local tree that I wrote as a result of some review feedback. The goal was to make the hard-coded COUNTER_FREQUENCY optional and instead allow our architected timer setup code to query the clk_m frequency and program that value instead. I'll send those out shortly, perhaps you could try those on your setup to see if it works correctly.
Thierry