From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Paul Walmsley <pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: Tegra baseline test results for v3.10-rc1
Date: Wed, 05 Jun 2013 09:17:44 -0600 [thread overview]
Message-ID: <51AF5698.5050106@wwwdotorg.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1306050558430.13098-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
On 06/04/2013 11:59 PM, Paul Walmsley wrote:
>
> Here are some basic Tegra test results for Linux v3.10-rc1.
> Logs and other details at:
>
> http://www.pwsan.com/tegra/testlogs/test_v3.10-rc1/20130518212204/
Cool. thanks for running these tests. It's very useful.
That URL is 404, although going up one directory manually lets me find
the logs.
I can access all the log files there, but can't download the zImage; I
get permission denied. I can download the .dtb file. Is this deliberate?
http://www.pwsan.com/tegra/testlogs/test_v3.10-rc1/20130519152115/build_z/tegra_defconfig/zImage
I'm curious what the difference is between the "t33beaver" and
"tegra30-beaver" path entries is, in the following URL:
http://www.pwsan.com/tegra/testlogs/test_v3.10-rc1/20130519152115/boot/t33beaver/tegra30-beaver/
It might be better to call this board just "tegra30-beaver" for
consistency with other upstream tools like cbootimage-configs and the
DTB filename.
In the boot logs, I see:
Tegra30 (Beaver) # setenv bootargs 'console=ttyS0,230400n8
lp0_vec=0x00002000@0x9C406000 video=tegrafb mem=1023M@2048M vmalloc=128M
noinitrd usbcore.old_scheme_first=1 core_edp_mv=1300 panel=lvds
tegraid=30.1.2.0.0 debug_uartport=lsport tegra_fbmem=4104K@0xFF900000
max_cpu_cur_ma=10000 root=/dev/mmcblk0p1 rw rootwait gpt'
Most of those options aren't necessary for the upstream kernel.
Unfortunately, our downstream kernel requires a bunch of crufty options,
but upstream doesn't. It might be worth minimizing the set of options
passed to upstream, so there's no possibility that those options ever do
anything; most won't since they're custom options no supported upstream,
but I wonder if e.g. mem, vmalloc, gpt might have negative effects even now.
next prev parent reply other threads:[~2013-06-05 15:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-05 5:59 Tegra baseline test results for v3.10-rc1 Paul Walmsley
[not found] ` <alpine.DEB.2.02.1306050558430.13098-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2013-06-05 15:17 ` Stephen Warren [this message]
[not found] ` <51AF5698.5050106-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-06 4:34 ` Paul Walmsley
[not found] ` <alpine.DEB.2.02.1306060421250.15042-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2013-06-06 15:58 ` Stephen Warren
[not found] ` <51B0B196.3040400-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-06-11 12:26 ` Paul Walmsley
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=51AF5698.5050106@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pwalmsley-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
/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