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

[Stephen Warren <swarren@wwwdotorg.org>]

On 08/19/2015 11:41 AM, 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.
...
>>> 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:-)

So, COUNTER_FREQUENCY is only used if U-Boot is started in EL3, to 
program the cntfrq_el0 register. Since I'm booting a secure monitor 
first, U-Boot is starting in EL2 for me, and COUNTER_FREQUENCY isn't 
actually used. I've confirmed in the TRM that clk_m does run at half the 
crystal rate, and that the secure monitor is indeed setting cntfrq_el0 
is 19.2MHz rather than 38.4MHz. I'll send a patch to correct this.