From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH V2 2/2] ARM: tegra: Add p2371-0000 board
Date: Wed, 19 Aug 2015 11:41:09 -0600 [thread overview]
Message-ID: <55D4BFB5.20106@wwwdotorg.org> (raw)
In-Reply-To: <20150819135651.GE15607@ulmo.nvidia.com>
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:-)
next prev parent reply other threads:[~2015-08-19 17:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 20:16 [U-Boot] [PATCH V2 1/2] ARM: tegra: Add e2220-1170 board Stephen Warren
2015-07-29 20:16 ` [U-Boot] [PATCH V2 2/2] ARM: tegra: Add p2371-0000 board Stephen Warren
2015-08-19 13:56 ` Thierry Reding
2015-08-19 17:41 ` Stephen Warren [this message]
2015-08-19 21:01 ` Stephen Warren
2015-08-19 23:07 ` Stephen Warren
2015-08-20 8:40 ` Thierry Reding
2015-07-29 23:00 ` [U-Boot] [PATCH V2 1/2] ARM: tegra: Add e2220-1170 board Tom Warren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55D4BFB5.20106@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox