[U-Boot] [PATCH V2 2/2] ARM: tegra: Add p2371-0000 board

[Thierry Reding]

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 at nvidia.com>
> >>
> >>Signed-off-by: Stephen Warren <swarren at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150820/f3823631/attachment.sig>