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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.