* Re: [GIT PULL] Please pull tegra cleanups for 3.2
From: Olof Johansson @ 2011-10-13 22:27 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stephen Warren,
Colin Cross, Russell King - ARM Linux
In-Reply-To: <201110131716.18358.arnd-r2nGTMty4D4@public.gmane.org>
Hi,
On Thu, Oct 13, 2011 at 8:16 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Thursday 13 October 2011, Olof Johansson wrote:
>> Hi Arnd,
>>
>> Please pull the below branch of cleanups for the 3.2 merge window.
>> They have been included in linux-next for a couple of days already.
>
> I saw Russell had a comment on the macro name should be addressed.
> I've put your series plus an additional commit to fix this up
> into the tegra/cleanup branch. When you ack this patch, I'll include
> this branch into next/cleanup and the for-next branch.
Based on discussion on IRC, I pulled in the edit into the original
commit instead and rebased the branch.
I also added the devices.c fix that I posted yesterday, so here is a
new pull request.
Thanks!
-Olof
The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84:
Linux 3.1-rc9 (2011-10-04 18:11:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git for-3.2/cleanup
Olof Johansson (15):
ARM: tegra: annotate IO_*_VIRT pointers
ARM: tegra: timer: don't cast __iomem pointers
ARM: tegra: tegra2_clocks: don't cast __iomem pointers
ARM: tegra: tegra2_clocks: 0 -> NULL changes
ARM: tegra: pcie: don't cast __iomem pointers
ARM: tegra: pcie: include board.h
ARM: tegra: pcie: 0 -> NULL changes
ARM: tegra: tegra_init_cache should be static
ARM: tegra: tegra_rtc_read_ms should be static
ARM: tegra: tegra_powergate_is_powered should be static
ARM: tegra: tegra2_clocks: don't export some tables
ARM: tegra: dma: staticify some tables and functions
ARM: tegra: cpu-tegra: sparse type fix
ARM: tegra: cpu-tegra: unexport two functions
ARM: tegra: devices.c should include devices.h
arch/arm/mach-tegra/common.c | 2 +-
arch/arm/mach-tegra/cpu-tegra.c | 6 ++--
arch/arm/mach-tegra/devices.c | 2 +
arch/arm/mach-tegra/dma.c | 14 +++++---
arch/arm/mach-tegra/include/mach/io.h | 18 ++++++---
arch/arm/mach-tegra/include/mach/powergate.h | 1 -
arch/arm/mach-tegra/io.c | 8 ++--
arch/arm/mach-tegra/pcie.c | 8 +++--
arch/arm/mach-tegra/powergate.c | 5 +--
arch/arm/mach-tegra/tegra2_clocks.c | 50 +++++++++++++-------------
arch/arm/mach-tegra/timer.c | 6 ++--
11 files changed, 66 insertions(+), 54 deletions(-)
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Olof Johansson @ 2011-10-13 23:38 UTC (permalink / raw)
To: Stephen Warren
Cc: Peter De Schrijver, Russell King,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling, Arnd Bergmann (arnd-r2nGTMty4D4@public.gmane.org)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173955580F-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
Hi,
On Wed, Sep 28, 2011 at 10:50 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Peter De Schrijver wrote at Tuesday, September 27, 2011 7:08 PM:
>> This patch causes the kernel uncompressor to determine the physical address
>> of the SDRAM at runtime. This allows the kernel to boot on both tegra20 and
>> tegra30 even though SDRAM is at different physical addresses on both SoCs.
>>
>> Signed-off-by: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> An alternative would be to simply add that config option to the relevant
> defconfig/.config file. I see both cases in use in the kernel. Still, the
> code change this enables looks fine to just turn on all the time, and will
> be needed for Tegra30 support, so I'm fine just selecting it as you have.
>
> Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 472a7f8..474737b 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -596,6 +596,7 @@ config ARCH_TEGRA
>> select HAVE_CLK
>> select HAVE_SCHED_CLOCK
>> select ARCH_HAS_CPUFREQ
>> + select AUTO_ZRELADDR
>> help
>> This enables support for NVIDIA Tegra based systems (Tegra APX,
>> Tegra 6xx and Tegra 2 series).
>
> P.S. Since this patch relates to Tegra, you should CC the Tegra maintainers
> and list; I've done so on this message. I also added Arnd; he might take
> this through the arm-soc tree.
While it does touch a file outside of arch/arm/mach-tegra, it's for
the tegra options and is not likely to cause conflicts upstream. I'll
apply it with the rest of tegra patches for 3.2 here.
So: Applied, thanks.
-Olof
^ permalink raw reply
* Re: [PATCH v4 3/4] gpio/tegra: Convert to a platform device
From: Olof Johansson @ 2011-10-13 23:42 UTC (permalink / raw)
To: Stephen Warren
Cc: Grant Likely, Colin Cross, Arnd Bergmann, Nicolas Pitre,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Peter De Schrijver
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE1A08D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Thu, Oct 13, 2011 at 9:36 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Olof Johansson wrote at Wednesday, October 12, 2011 5:19 PM:
>> On Wed, Oct 12, 2011 at 05:03:24PM -0600, Grant Likely wrote:
>> > On Wed, Oct 12, 2011 at 4:41 PM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
>> > > On Tue, Oct 11, 2011 at 04:16:14PM -0600, Stephen Warren wrote:
> ...
>> > > Otherwise, patch looks good. Due to dependencies between this, the rest
>> > > of this patch series and the pinmux changes, I'll hold off on it until
>> > > the dependencies land (i.e. target it for 3.3). We're cutting it very close
>> > > to the merge window as it is, I'll start for-3.3 branches shortly.
>> >
>> > Actually, see if you can get it in via the same tree as the pinmux
>> > changes. Dependencies is not a reason to hold off from getting it
>> > into linux-next.
>>
>> Ok, the fixup is minimal, should be trivial to spot at git merge time.
>>
>> Stephen, do you want to respin yourself or should I do the __devinit
>> change when I apply?
>
> I'm happy for you to fix that up when you apply if you're happy doing that.
>
> The same fixup applies to the pinmux patches too.
Thanks, applied (and pinmux patch fixed up). for-3.2/features was
rebased to roll in the pinmux change.
-Olof
^ permalink raw reply
* [GIT PULL] Please pull tegra feature branch for 3.2
From: Olof Johansson @ 2011-10-14 0:21 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stephen Warren,
Colin Cross
Hi Arnd,
The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84:
Linux 3.1-rc9 (2011-10-04 18:11:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git for-3.2/features
Olof Johansson (1):
ARM: tegra: update defconfig
Peter De Schrijver (4):
arm/tegra: prepare Seaboard pinmux code for derived boards
arm/tegra: add support for ventana pinmuxing
arm/tegra: device tree support for ventana board
arm/tegra: select AUTO_ZRELADDR by default
Stephen Warren (6):
arm/tegra: Prep boards for gpio/pinmux conversion to pdevs
arm/dt: Tegra: Add pinmux node to tegra20.dtsi
arm/tegra: Convert pinmux driver to a platform device
gpio/tegra: Convert to a platform device
arm/tegra: pinmux: ioremap registers
arm/tegra: Harmony: Configure PMC for low-level interrupts
.../devicetree/bindings/pinmux/pinmux_nvidia.txt | 5 +
arch/arm/Kconfig | 1 +
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++
arch/arm/boot/dts/tegra20.dtsi | 8 +
arch/arm/configs/tegra_defconfig | 39 ++++-
arch/arm/mach-tegra/Kconfig | 6 +
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 26 +++-
arch/arm/mach-tegra/board-harmony-pinmux.c | 8 +
arch/arm/mach-tegra/board-harmony-power.c | 13 ++-
arch/arm/mach-tegra/board-paz00-pinmux.c | 8 +
arch/arm/mach-tegra/board-seaboard-pinmux.c | 69 ++++++++-
arch/arm/mach-tegra/board-trimslice-pinmux.c | 7 +
arch/arm/mach-tegra/devices.c | 84 ++++++++++
arch/arm/mach-tegra/devices.h | 2 +
arch/arm/mach-tegra/include/mach/pinmux.h | 4 +
arch/arm/mach-tegra/pinmux-t2-tables.c | 76 ++--------
arch/arm/mach-tegra/pinmux.c | 163 ++++++++++++++++----
drivers/gpio/gpio-tegra.c | 143 ++++++++++++------
20 files changed, 536 insertions(+), 160 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
^ permalink raw reply
* Adding board support
From: Thierry Reding @ 2011-10-14 5:49 UTC (permalink / raw)
To: linux-tegra-u79uwXL29TY76Z2rM5mHXA
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
Hi,
I have two Tegra2 based boards that I would like to add mainline support to.
Currently they run on a modified NVIDIA kernel (Vibrante 1.1 for those who
know it), but I would very much like to have them eventually boot from a
mainline kernel. Both boards are rather similar to Harmony.
I have a couple of questions, though. From what I can tell, the only
functionality missing from mainline is nvmap/nvhost. While this is required
for our boards, I was looking for some remote that includes support. The only
source I came across was at git.chromium.org (kernel.git and
kernel-next.git). I suppose those are kernels that are recommended to run on
Tegra2 boards if HW-accelerated video decoding and 3D rendering is required,
right?
I guess for the time being, the best plan would be to work on two branches,
one based on the code from chromium and one based on the mainline code which
doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which
branch or repository should I base such work on? Olof's for-3.2 branches?
Another question concerns testing. So far I've always booted a modified
U-Boot (from Vibrante 1.1) to allow booting with an initial ramdisk (loaded
from SD/MMC) as payload for fastboot/quickboot. What are other people using?
What tools should I be using to update the firmware? Unfortunately nvflash is
not available in source code, and I haven't found any documentation about the
early boot process, so it is kind of hard to figure out how all this is
supposed to work and consequently find ways to automate these things for
production boards.
I realize that some of these questions may be slightly off-topic here. If so,
would someone be so kind as to point me to the correct mailing list?
Thanks,
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Russell King - ARM Linux @ 2011-10-14 7:15 UTC (permalink / raw)
To: Olof Johansson
Cc: Stephen Warren, Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling, Arnd Bergmann (arnd-r2nGTMty4D4@public.gmane.org)
In-Reply-To: <CAOesGMiuzF47kdmaaFny9Fg1ieox6a75tMFfLRAptvDxz_QPMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Oct 13, 2011 at 04:38:46PM -0700, Olof Johansson wrote:
> Hi,
>
> On Wed, Sep 28, 2011 at 10:50 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Peter De Schrijver wrote at Tuesday, September 27, 2011 7:08 PM:
> >> This patch causes the kernel uncompressor to determine the physical address
> >> of the SDRAM at runtime. This allows the kernel to boot on both tegra20 and
> >> tegra30 even though SDRAM is at different physical addresses on both SoCs.
> >>
> >> Signed-off-by: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > An alternative would be to simply add that config option to the relevant
> > defconfig/.config file. I see both cases in use in the kernel. Still, the
> > code change this enables looks fine to just turn on all the time, and will
> > be needed for Tegra30 support, so I'm fine just selecting it as you have.
> >
> > Acked-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> index 472a7f8..474737b 100644
> >> --- a/arch/arm/Kconfig
> >> +++ b/arch/arm/Kconfig
> >> @@ -596,6 +596,7 @@ config ARCH_TEGRA
> >> select HAVE_CLK
> >> select HAVE_SCHED_CLOCK
> >> select ARCH_HAS_CPUFREQ
> >> + select AUTO_ZRELADDR
> >> help
> >> This enables support for NVIDIA Tegra based systems (Tegra APX,
> >> Tegra 6xx and Tegra 2 series).
> >
> > P.S. Since this patch relates to Tegra, you should CC the Tegra maintainers
> > and list; I've done so on this message. I also added Arnd; he might take
> > this through the arm-soc tree.
>
> While it does touch a file outside of arch/arm/mach-tegra, it's for
> the tegra options and is not likely to cause conflicts upstream. I'll
> apply it with the rest of tegra patches for 3.2 here.
>
> So: Applied, thanks.
I'll point out that this makes Tegra incompatible with ZBOOT_ROM, which
can still be enabled. ZBOOT_ROM=y AUTO_ZRELADDR=y is an invalid
configuration at runtime.
^ permalink raw reply
* RE: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Stephen Warren @ 2011-10-14 14:45 UTC (permalink / raw)
To: Russell King - ARM Linux, Olof Johansson
Cc: Peter De Schrijver, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
Colin Cross (ccross@android.com), Erik Gilling,
Arnd Bergmann (arnd@arndb.de)
In-Reply-To: <20111014071500.GP21648@n2100.arm.linux.org.uk>
Russell King wrote at Friday, October 14, 2011 1:15 AM:
> On Thu, Oct 13, 2011 at 04:38:46PM -0700, Olof Johansson wrote:
> > Hi,
> >
> > On Wed, Sep 28, 2011 at 10:50 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > > Peter De Schrijver wrote at Tuesday, September 27, 2011 7:08 PM:
> > >> This patch causes the kernel uncompressor to determine the physical address
> > >> of the SDRAM at runtime. This allows the kernel to boot on both tegra20 and
> > >> tegra30 even though SDRAM is at different physical addresses on both SoCs.
> > >>
> > >> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > >
> > > An alternative would be to simply add that config option to the relevant
> > > defconfig/.config file. I see both cases in use in the kernel. Still, the
> > > code change this enables looks fine to just turn on all the time, and will
> > > be needed for Tegra30 support, so I'm fine just selecting it as you have.
> > >
> > > Acked-by: Stephen Warren <swarren@nvidia.com>
> > >
> > >> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > >> index 472a7f8..474737b 100644
> > >> --- a/arch/arm/Kconfig
> > >> +++ b/arch/arm/Kconfig
> > >> @@ -596,6 +596,7 @@ config ARCH_TEGRA
> > >> select HAVE_CLK
> > >> select HAVE_SCHED_CLOCK
> > >> select ARCH_HAS_CPUFREQ
> > >> + select AUTO_ZRELADDR
> > >> help
> > >> This enables support for NVIDIA Tegra based systems (Tegra APX,
> > >> Tegra 6xx and Tegra 2 series).
> > >
> > > P.S. Since this patch relates to Tegra, you should CC the Tegra maintainers
> > > and list; I've done so on this message. I also added Arnd; he might take
> > > this through the arm-soc tree.
> >
> > While it does touch a file outside of arch/arm/mach-tegra, it's for
> > the tegra options and is not likely to cause conflicts upstream. I'll
> > apply it with the rest of tegra patches for 3.2 here.
> >
> > So: Applied, thanks.
>
> I'll point out that this makes Tegra incompatible with ZBOOT_ROM, which
> can still be enabled. ZBOOT_ROM=y AUTO_ZRELADDR=y is an invalid
> configuration at runtime.
I see that at least one machine solves that by doing:
config ARCH_EP93XX
...
select AUTO_ZRELADDR if !ZBOOT_ROM
That said, given the way Tegra works, ZBOOT_ROM isn't useful; typically,
systems don't use NOR flash for storage of the kernel, so I don't think
ZBOOT_ROM is likely to be used. Perhaps we should just depend on !ZBOOT_ROM?
--
nvpublic
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Arnd Bergmann @ 2011-10-14 15:29 UTC (permalink / raw)
To: Stephen Warren
Cc: Russell King - ARM Linux, Olof Johansson, Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE1A260-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Friday 14 October 2011, Stephen Warren wrote:
> Russell King wrote at Friday, October 14, 2011 1:15 AM:
> > On Thu, Oct 13, 2011 at 04:38:46PM -0700, Olof Johansson wrote:
> >
> > I'll point out that this makes Tegra incompatible with ZBOOT_ROM, which
> > can still be enabled. ZBOOT_ROM=y AUTO_ZRELADDR=y is an invalid
> > configuration at runtime.
>
> I see that at least one machine solves that by doing:
>
> config ARCH_EP93XX
> ...
> select AUTO_ZRELADDR if !ZBOOT_ROM
>
> That said, given the way Tegra works, ZBOOT_ROM isn't useful; typically,
> systems don't use NOR flash for storage of the kernel, so I don't think
> ZBOOT_ROM is likely to be used. Perhaps we should just depend on !ZBOOT_ROM?
That sounds like a correct fix, but also confusing because the top-level
subarchitecture selection should not depend on too many things that are
not obvious to someone configuring the kernel. From the perspective
of least suprise I would think that instead ZBOOTROM should depend on
!ARCH_TEGRA, but there is no precedent for this in the current Kconfig.
You mention that tegra30 will require AUTO_ZRELADDR. Does that mean that
with tegra30 merged you would no longer be able to build any tegra
kernel? If not, the best solution for now would probably be to
put AUTO_ZRELADDR into the defconfig for now (provided that tegra20 can
still boot without it) and make tegra30 depend on AUTO_ZRELADDR within
the tegra Kconfig.
This is only a temporary solution I think, because it is one of the
areas that we will have to revisit once we make it possible to combine
multiple subarchitectures into a single kernel. I have some ideas how
I would express that in Kconfig but I'm sure that we will have a lot
of debate over it before we coem to a solution that works for everyone.
Arnd
^ permalink raw reply
* [PATCH] ARM: mutually exclude ZBOOT_ROM and AUTO_ZRELADDR
From: Olof Johansson @ 2011-10-14 15:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: linux-arm-kernel, linux-tegra, linux-kernel, ccross, arnd,
swarren, pdeschrijver, Olof Johansson
In-Reply-To: <20111014071500.GP21648@n2100.arm.linux.org.uk>
This way platforms that want it can select AUTO_ZRELADDR without issues caused by
someone manually also enabling ZBOOT_ROM.
Signed-off-by: Olof Johansson <olof@lixom.net>
---
arch/arm/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Russell King wrote at Friday, October 14, 2011 1:15 AM:
> I'll point out that this makes Tegra incompatible with ZBOOT_ROM, which
> can still be enabled. ZBOOT_ROM=y AUTO_ZRELADDR=y is an invalid
> configuration at runtime.
Ah, looks like the dependency is only one-way. Since they are mutually
exclusive, how about the below?
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 82973b2..2ad58e8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1814,6 +1814,7 @@ config ZBOOT_ROM_BSS
config ZBOOT_ROM
bool "Compressed boot loader in ROM/flash"
depends on ZBOOT_ROM_TEXT != ZBOOT_ROM_BSS
+ depends on !AUTO_ZRELADDR
help
Say Y here if you intend to execute your compressed kernel image
(zImage) directly from ROM or flash. If unsure, say N.
--
1.7.4.1
^ permalink raw reply related
* RE: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Stephen Warren @ 2011-10-14 16:12 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Russell King - ARM Linux, Olof Johansson, Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <201110141729.41515.arnd-r2nGTMty4D4@public.gmane.org>
Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM:
...
> You mention that tegra30 will require AUTO_ZRELADDR.
Well, just to be clear, here's the situation I think:
Tegra20's SDRAM starts at physical address 0.
Tegra30's SDRAM starts at physical address 2G.
To support that, we could either:
a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually
exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr
etc. based on the new Tegra30 config variable too. Then, there's no need
for AUTO_ZRELADDR anywhere.
b) Have no new config variable, build a unified T20/T30 kernel, leave
Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to
account for the different SDRAM physical addresses.
> Does that mean that with tegra30 merged you would no longer be able
> to build any tegra kernel?
Sorry, I don't quite understand that question.
--
nvpublic
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Arnd Bergmann @ 2011-10-14 16:27 UTC (permalink / raw)
To: Stephen Warren
Cc: Russell King - ARM Linux, Olof Johansson, Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE1A283-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Friday 14 October 2011, Stephen Warren wrote:
> Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM:
> ...
> > You mention that tegra30 will require AUTO_ZRELADDR.
>
> Well, just to be clear, here's the situation I think:
>
> Tegra20's SDRAM starts at physical address 0.
>
> Tegra30's SDRAM starts at physical address 2G.
>
> To support that, we could either:
>
> a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually
> exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr
> etc. based on the new Tegra30 config variable too. Then, there's no need
> for AUTO_ZRELADDR anywhere.
>
> b) Have no new config variable, build a unified T20/T30 kernel, leave
> Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to
> account for the different SDRAM physical addresses.
Ok, thanks for the explanation, that makes it much clearer. For
completeness, you could also do both of the above and make T20/T30 mutually
exclusive unless AUTO_ZRELADDR is set. That might be more complex than
necessary, I don't know.
Arnd
^ permalink raw reply
* Re: [PATCH] ARM: mutually exclude ZBOOT_ROM and AUTO_ZRELADDR
From: Arnd Bergmann @ 2011-10-14 16:29 UTC (permalink / raw)
To: Olof Johansson
Cc: Russell King - ARM Linux,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ccross-z5hGa2qSFaRBDgjK7y7TUQ, swarren-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1318607945-6807-1-git-send-email-olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
On Friday 14 October 2011, Olof Johansson wrote:
> This way platforms that want it can select AUTO_ZRELADDR without issues caused by
> someone manually also enabling ZBOOT_ROM.
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 82973b2..2ad58e8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1814,6 +1814,7 @@ config ZBOOT_ROM_BSS
> config ZBOOT_ROM
> bool "Compressed boot loader in ROM/flash"
> depends on ZBOOT_ROM_TEXT != ZBOOT_ROM_BSS
> + depends on !AUTO_ZRELADDR
> help
> Say Y here if you intend to execute your compressed kernel image
> (zImage) directly from ROM or flash. If unsure, say N.
Unfortunately, you cannot have it both ways:
arnd@ocdc-kvm:~/linux-arm$ make O=obj-tmp CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm -sj20 menuconfig
arch/arm/Kconfig:1761:error: recursive dependency detected!
arch/arm/Kconfig:1761: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
arch/arm/Kconfig:1899: symbol AUTO_ZRELADDR depends on ZBOOT_ROM
Arnd
^ permalink raw reply
* RE: Adding board support
From: Stephen Warren @ 2011-10-14 16:31 UTC (permalink / raw)
To: Thierry Reding,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20111014054945.GA32399-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM:
...
> I have a couple of questions, though. From what I can tell, the only
> functionality missing from mainline is nvmap/nvhost. While this is required
> for our boards, I was looking for some remote that includes support. The only
> source I came across was at git.chromium.org (kernel.git and
> kernel-next.git). I suppose those are kernels that are recommended to run on
> Tegra2 boards if HW-accelerated video decoding and 3D rendering is required,
> right?
There are also some NVIDIA kernel repos that contain this support; see:
http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
I think our current Linux4Tegra releases do use the kernel from ChromeOS, but
future releases may move to our internal kernels.
> I guess for the time being, the best plan would be to work on two branches,
> one based on the code from chromium and one based on the mainline code which
> doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which
> branch or repository should I base such work on? Olof's for-3.2 branches?
Just as an FYI, upstreaming nvmap/nvhost isn't a near-term goal. In the longer
term, we're starting to think about a solution here.
For practical purposes, you'll probably want to base any product kernels off
one of NVIDIA's various downstream branches. Given your Vibrante usage, it'd
probably be best to ask your existing NVIDIA contacts some of these questions.
However, please don't let that stop you upstreaming basic board support; you
should be able to upstream anything that doesn't depend on nvhost/nvmap etc.
You'll probably want to use device-tree exclusively for any new board support
in mainline.
> Another question concerns testing. So far I've always booted a modified
> U-Boot (from Vibrante 1.1) to allow booting with an initial ramdisk (loaded
> from SD/MMC) as payload for fastboot/quickboot. What are other people using?
Personally, I've recently switched to using mainline U-Boot on almost all my
boards (Harmony, Seaboard, Ventana). Maybe I'll add TrimSlice support there
too. Note that this relies on a number of patches that have been posted to
the U-Boot mailing list, but not yet checked into their repos. This completely
bypasses fastboot; Tegra's boot ROM runs U-Boot directly instead of fastboot.
> What tools should I be using to update the firmware? Unfortunately nvflash is
> not available in source code, and I haven't found any documentation about the
> early boot process, so it is kind of hard to figure out how all this is
> supposed to work and consequently find ways to automate these things for
> production boards.
Try grabbing the Linux4Tegra packages from:
http://developer.nvidia.com/content/linux-tegra-release-12-alpha-1-released
at least that has a publically obtainable/usable nvflash for a few boards.
You should be able to adjust the flash.cfg files there for other boards.
It's a little early to say much, but there are some early movements towards
replacing nvflash with something more open for general Linux usage. You may
also want to look at the "cbootimage" tool here:
https://gitorious.org/cbootimage
--
nvpublic
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Olof Johansson @ 2011-10-14 16:44 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Warren, Russell King - ARM Linux, Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <201110141827.53906.arnd-r2nGTMty4D4@public.gmane.org>
On Fri, Oct 14, 2011 at 9:27 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Friday 14 October 2011, Stephen Warren wrote:
>> Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM:
>> ...
>> > You mention that tegra30 will require AUTO_ZRELADDR.
>>
>> Well, just to be clear, here's the situation I think:
>>
>> Tegra20's SDRAM starts at physical address 0.
>>
>> Tegra30's SDRAM starts at physical address 2G.
>>
>> To support that, we could either:
>>
>> a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually
>> exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr
>> etc. based on the new Tegra30 config variable too. Then, there's no need
>> for AUTO_ZRELADDR anywhere.
>>
>> b) Have no new config variable, build a unified T20/T30 kernel, leave
>> Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to
>> account for the different SDRAM physical addresses.
>
> Ok, thanks for the explanation, that makes it much clearer. For
> completeness, you could also do both of the above and make T20/T30 mutually
> exclusive unless AUTO_ZRELADDR is set. That might be more complex than
> necessary, I don't know.
That is likely to get messy.
Seems like there could be some use for a (silent) option for a
platform to indicate that it can do XIP kernel (or zImage), and thus
not able to use AUTO_ZRELADDR (or other options that require rewriting
text segment of zImage or kernel).
Language gets awkard though, since it'd be a negative option (or all
platforms would need to add it). MACH_XIP_UNSUPPORTED perhaps?
-Olof
^ permalink raw reply
* Re: [GIT PULL] Please pull tegra feature branch for 3.2
From: Olof Johansson @ 2011-10-14 16:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Stephen Warren,
Colin Cross
In-Reply-To: <CAOesGMipZUkZG8oHSwK-8xw5Y0u6Ymfjmumq7=ijsztUwdGeDA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dropped the AUTO_ZRELADDR patch due to discussions related to
dependency issues. New pull request:
The following changes since commit ecb7b0e33e048e63d1169e6fee277430c70ddf0b:
ARM: tegra: update defconfig (2011-10-13 15:07:40 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git for-3.2/features
olof@quad:~/work/tegra (for-3.2/features) $ git request-pull v3.1-rc9
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git
The following changes since commit 976d167615b64e14bc1491ca51d424e2ba9a5e84:
Linux 3.1-rc9 (2011-10-04 18:11:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git for-3.2/features
Olof Johansson (1):
ARM: tegra: update defconfig
Peter De Schrijver (3):
arm/tegra: prepare Seaboard pinmux code for derived boards
arm/tegra: add support for ventana pinmuxing
arm/tegra: device tree support for ventana board
Stephen Warren (6):
arm/tegra: Prep boards for gpio/pinmux conversion to pdevs
arm/dt: Tegra: Add pinmux node to tegra20.dtsi
arm/tegra: Convert pinmux driver to a platform device
gpio/tegra: Convert to a platform device
arm/tegra: pinmux: ioremap registers
arm/tegra: Harmony: Configure PMC for low-level interrupts
.../devicetree/bindings/pinmux/pinmux_nvidia.txt | 5 +
arch/arm/boot/dts/tegra-ventana.dts | 32 ++++
arch/arm/boot/dts/tegra20.dtsi | 8 +
arch/arm/configs/tegra_defconfig | 39 ++++-
arch/arm/mach-tegra/Kconfig | 6 +
arch/arm/mach-tegra/Makefile | 1 +
arch/arm/mach-tegra/Makefile.boot | 1 +
arch/arm/mach-tegra/board-dt.c | 26 +++-
arch/arm/mach-tegra/board-harmony-pinmux.c | 8 +
arch/arm/mach-tegra/board-harmony-power.c | 13 ++-
arch/arm/mach-tegra/board-paz00-pinmux.c | 8 +
arch/arm/mach-tegra/board-seaboard-pinmux.c | 69 ++++++++-
arch/arm/mach-tegra/board-trimslice-pinmux.c | 7 +
arch/arm/mach-tegra/devices.c | 84 ++++++++++
arch/arm/mach-tegra/devices.h | 2 +
arch/arm/mach-tegra/include/mach/pinmux.h | 4 +
arch/arm/mach-tegra/pinmux-t2-tables.c | 76 ++--------
arch/arm/mach-tegra/pinmux.c | 163 ++++++++++++++++----
drivers/gpio/gpio-tegra.c | 143 ++++++++++++------
19 files changed, 535 insertions(+), 160 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pinmux/pinmux_nvidia.txt
create mode 100644 arch/arm/boot/dts/tegra-ventana.dts
^ permalink raw reply
* RE: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Nicolas Pitre @ 2011-10-14 17:53 UTC (permalink / raw)
To: Stephen Warren
Cc: Arnd Bergmann, Russell King - ARM Linux, Olof Johansson,
Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE1A283-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
On Fri, 14 Oct 2011, Stephen Warren wrote:
> Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM:
> ...
> > You mention that tegra30 will require AUTO_ZRELADDR.
>
> Well, just to be clear, here's the situation I think:
>
> Tegra20's SDRAM starts at physical address 0.
>
> Tegra30's SDRAM starts at physical address 2G.
>
> To support that, we could either:
>
> a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually
> exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr
> etc. based on the new Tegra30 config variable too. Then, there's no need
> for AUTO_ZRELADDR anywhere.
>
> b) Have no new config variable, build a unified T20/T30 kernel, leave
> Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to
> account for the different SDRAM physical addresses.
As I explained yesterday, I'm working on more cleanups that involve
reworking the dependencies around ZBOOTROM, AUTO_ZRELADDR and friends,
and removing zreladdr for all platforms. So please do not come up with
Tegra specific hacks to fix this up. So for the time being I'd simply
suggest using the minimal fix i.e.:
select AUTO_ZRELADDR if !ZBOOT_ROM
And eventually this will disappear entirely in favor of a single global
config option which is not platform dependent.
Nicolas
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Olof Johansson @ 2011-10-14 17:58 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen Warren, Arnd Bergmann, Russell King - ARM Linux,
Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <alpine.LFD.2.02.1110141348270.17040-QuJgVwGFrdf/9pzu0YdTqQ@public.gmane.org>
Hi,
On Fri, Oct 14, 2011 at 10:53 AM, Nicolas Pitre <nico-vtqb6HGKxmzR7s880joybQ@public.gmane.org> wrote:
> As I explained yesterday, I'm working on more cleanups that involve
> reworking the dependencies around ZBOOTROM, AUTO_ZRELADDR and friends,
> and removing zreladdr for all platforms. So please do not come up with
> Tegra specific hacks to fix this up. So for the time being I'd simply
> suggest using the minimal fix i.e.:
>
> select AUTO_ZRELADDR if !ZBOOT_ROM
>
> And eventually this will disappear entirely in favor of a single global
> config option which is not platform dependent.
Odd, I'm not seeing any mention of the above on the list (especially
not posted yesterday), but that sounds good to me.
We've dropped the patch for now, if t30 needs it we can update the
defconfig when the time comes, and wait for your cleanup for the rest.
-Olof
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Olof Johansson @ 2011-10-14 18:00 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Stephen Warren, Arnd Bergmann, Russell King - ARM Linux,
Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <CAOesGMhm_dD=9dyMWQRfH5AXH4AE42+4ckNwhnMUGaBJEHsumg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Oct 14, 2011 at 10:58 AM, Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org> wrote:
> Odd, I'm not seeing any mention of the above on the list (especially
> not posted yesterday), but that sounds good to me.
Ah, didn't think to search for your linaro address. My bad.
-Olof
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Nicolas Pitre @ 2011-10-14 18:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stephen Warren, Russell King - ARM Linux, Olof Johansson,
Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <201110141827.53906.arnd-r2nGTMty4D4@public.gmane.org>
On Fri, 14 Oct 2011, Arnd Bergmann wrote:
> On Friday 14 October 2011, Stephen Warren wrote:
> > Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM:
> > ...
> > > You mention that tegra30 will require AUTO_ZRELADDR.
> >
> > Well, just to be clear, here's the situation I think:
> >
> > Tegra20's SDRAM starts at physical address 0.
> >
> > Tegra30's SDRAM starts at physical address 2G.
> >
> > To support that, we could either:
> >
> > a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually
> > exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr
> > etc. based on the new Tegra30 config variable too. Then, there's no need
> > for AUTO_ZRELADDR anywhere.
> >
> > b) Have no new config variable, build a unified T20/T30 kernel, leave
> > Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to
> > account for the different SDRAM physical addresses.
>
> Ok, thanks for the explanation, that makes it much clearer. For
> completeness, you could also do both of the above and make T20/T30 mutually
> exclusive unless AUTO_ZRELADDR is set. That might be more complex than
> necessary, I don't know.
The way I'm restructuring things around this is that AUTO_ZRELADDR will
always be active by default, just like ARM_PATCH_PHYS_VIRT now. This
platform specific exclusion thinking is a step backward so I'd prefer if
people would refrain from going there for the moment.
Nicolas
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Nicolas Pitre @ 2011-10-14 18:03 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Stephen Warren, Russell King - ARM Linux,
Peter De Schrijver,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Colin Cross (ccross-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org),
Erik Gilling
In-Reply-To: <CAOesGMgDwMeVmwo1WJ3tU+ZdjCSJ6F8mY42e_KwTmzAkGQsqmg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, 14 Oct 2011, Olof Johansson wrote:
> On Fri, Oct 14, 2011 at 9:27 AM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> > On Friday 14 October 2011, Stephen Warren wrote:
> >> Arnd Bergmann wrote at Friday, October 14, 2011 9:30 AM:
> >> ...
> >> > You mention that tegra30 will require AUTO_ZRELADDR.
> >>
> >> Well, just to be clear, here's the situation I think:
> >>
> >> Tegra20's SDRAM starts at physical address 0.
> >>
> >> Tegra30's SDRAM starts at physical address 2G.
> >>
> >> To support that, we could either:
> >>
> >> a) Introduce a new Kconfig variable for Tegra30, make T20/T30 mutually
> >> exclusive, and update arch/arm/mach-tegra/Makefile.boot to set zreladdr
> >> etc. based on the new Tegra30 config variable too. Then, there's no need
> >> for AUTO_ZRELADDR anywhere.
> >>
> >> b) Have no new config variable, build a unified T20/T30 kernel, leave
> >> Makefile.boot untouched, and rely on using AUTO_ZRELADDR for Tegra30 to
> >> account for the different SDRAM physical addresses.
> >
> > Ok, thanks for the explanation, that makes it much clearer. For
> > completeness, you could also do both of the above and make T20/T30 mutually
> > exclusive unless AUTO_ZRELADDR is set. That might be more complex than
> > necessary, I don't know.
>
> That is likely to get messy.
>
> Seems like there could be some use for a (silent) option for a
> platform to indicate that it can do XIP kernel (or zImage), and thus
> not able to use AUTO_ZRELADDR (or other options that require rewriting
> text segment of zImage or kernel).
>
> Language gets awkard though, since it'd be a negative option (or all
> platforms would need to add it). MACH_XIP_UNSUPPORTED perhaps?
Please hold on -- I'm on it.
Nicolas
^ permalink raw reply
* Re: [PATCH] ARM: mutually exclude ZBOOT_ROM and AUTO_ZRELADDR
From: Nicolas Pitre @ 2011-10-14 18:04 UTC (permalink / raw)
To: Olof Johansson
Cc: Russell King - ARM Linux,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ccross-z5hGa2qSFaRBDgjK7y7TUQ, arnd-r2nGTMty4D4,
swarren-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1318607945-6807-1-git-send-email-olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
On Fri, 14 Oct 2011, Olof Johansson wrote:
> This way platforms that want it can select AUTO_ZRELADDR without issues caused by
> someone manually also enabling ZBOOT_ROM.
>
> Signed-off-by: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Acked-by: Nicolas Pitre <nicolas.pitre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Certainly harmless for the time being.
> ---
> arch/arm/Kconfig | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
>
> Russell King wrote at Friday, October 14, 2011 1:15 AM:
>
> > I'll point out that this makes Tegra incompatible with ZBOOT_ROM, which
> > can still be enabled. ZBOOT_ROM=y AUTO_ZRELADDR=y is an invalid
> > configuration at runtime.
>
> Ah, looks like the dependency is only one-way. Since they are mutually
> exclusive, how about the below?
>
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 82973b2..2ad58e8 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1814,6 +1814,7 @@ config ZBOOT_ROM_BSS
> config ZBOOT_ROM
> bool "Compressed boot loader in ROM/flash"
> depends on ZBOOT_ROM_TEXT != ZBOOT_ROM_BSS
> + depends on !AUTO_ZRELADDR
> help
> Say Y here if you intend to execute your compressed kernel image
> (zImage) directly from ROM or flash. If unsure, say N.
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH] ARM: mutually exclude ZBOOT_ROM and AUTO_ZRELADDR
From: Nicolas Pitre @ 2011-10-14 18:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof Johansson, Russell King - ARM Linux,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ccross-z5hGa2qSFaRBDgjK7y7TUQ, swarren-DDmLM1+adcrQT0dZR+AlfA,
pdeschrijver-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <201110141829.48634.arnd-r2nGTMty4D4@public.gmane.org>
On Fri, 14 Oct 2011, Arnd Bergmann wrote:
> On Friday 14 October 2011, Olof Johansson wrote:
> > This way platforms that want it can select AUTO_ZRELADDR without issues caused by
> > someone manually also enabling ZBOOT_ROM.
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 82973b2..2ad58e8 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -1814,6 +1814,7 @@ config ZBOOT_ROM_BSS
> > config ZBOOT_ROM
> > bool "Compressed boot loader in ROM/flash"
> > depends on ZBOOT_ROM_TEXT != ZBOOT_ROM_BSS
> > + depends on !AUTO_ZRELADDR
> > help
> > Say Y here if you intend to execute your compressed kernel image
> > (zImage) directly from ROM or flash. If unsure, say N.
>
> Unfortunately, you cannot have it both ways:
>
> arnd@ocdc-kvm:~/linux-arm$ make O=obj-tmp CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm -sj20 menuconfig
> arch/arm/Kconfig:1761:error: recursive dependency detected!
> arch/arm/Kconfig:1761: symbol ZBOOT_ROM depends on AUTO_ZRELADDR
Ah, right.
OK, like I said I'm reworking the whole thing, so the cheapest fix for
the time being is "select AUTO_ZRELADDR if !ZBOOT_ROM".
Nicolas
^ permalink raw reply
* Re: Adding board support
From: Thierry Reding @ 2011-10-14 18:58 UTC (permalink / raw)
To: Stephen Warren; +Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF173BE1A290-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5139 bytes --]
Hi,
Thanks for taking the time to reply. This is *exactly* the kind of
information I'm looking for.
* Stephen Warren wrote:
> Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM:
> ...
> > I have a couple of questions, though. From what I can tell, the only
> > functionality missing from mainline is nvmap/nvhost. While this is required
> > for our boards, I was looking for some remote that includes support. The only
> > source I came across was at git.chromium.org (kernel.git and
> > kernel-next.git). I suppose those are kernels that are recommended to run on
> > Tegra2 boards if HW-accelerated video decoding and 3D rendering is required,
> > right?
>
> There are also some NVIDIA kernel repos that contain this support; see:
> http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=summary
>
> I think our current Linux4Tegra releases do use the kernel from ChromeOS, but
> future releases may move to our internal kernels.
The kernel at the NVIDIA website seems to be close to what Vibrante ships
with. I'll have a closer look at it.
> > I guess for the time being, the best plan would be to work on two branches,
> > one based on the code from chromium and one based on the mainline code which
> > doesn't contain nvmap/nvhost and used to prepare patches for mainline. Which
> > branch or repository should I base such work on? Olof's for-3.2 branches?
>
> Just as an FYI, upstreaming nvmap/nvhost isn't a near-term goal. In the longer
> term, we're starting to think about a solution here.
That's good news. :-)
> For practical purposes, you'll probably want to base any product kernels off
> one of NVIDIA's various downstream branches. Given your Vibrante usage, it'd
> probably be best to ask your existing NVIDIA contacts some of these questions.
>
> However, please don't let that stop you upstreaming basic board support; you
> should be able to upstream anything that doesn't depend on nvhost/nvmap etc.
> You'll probably want to use device-tree exclusively for any new board support
> in mainline.
We'll have to stick to the Vibrante kernel while some issues are still being
worked out and I don't want to risk any differences in the kernel to
interfere.
However, in the meantime I would like to prepare some board support patches
for inclusion in the mainline kernel. My intention was indeed to use the
device-tree exclusively. Since both boards are rather similar to Harmony, it
will probably be easy to derive them from Harmony. I've been meaning to read
up on device-trees for a while and this looks to be the perfect opportunity.
> > Another question concerns testing. So far I've always booted a modified
> > U-Boot (from Vibrante 1.1) to allow booting with an initial ramdisk (loaded
> > from SD/MMC) as payload for fastboot/quickboot. What are other people using?
>
> Personally, I've recently switched to using mainline U-Boot on almost all my
> boards (Harmony, Seaboard, Ventana). Maybe I'll add TrimSlice support there
> too. Note that this relies on a number of patches that have been posted to
> the U-Boot mailing list, but not yet checked into their repos. This completely
> bypasses fastboot; Tegra's boot ROM runs U-Boot directly instead of fastboot.
I was hoping that somebody had gotten this to work. Would you mind sharing
the script that you use? All the scripts I've seen so far create some boot
image (using a tool named mkbootimg) that contains U-Boot.
U-Boot mainline support is another point on my TODO list. Getting the latest
mainline code with the patches you mention (I assume you are referring to the
patch series by Simon Glass and Tom Warren) to work would be a good step in
that direction.
Have you done any testing with the NVIDIA binary blobs when booting this way?
The latest information I have from our NVIDIA contacts is that fastboot or
quickboot are required, for some reason, to make HW accelerated video
decoding and 3D rendering work.
> > What tools should I be using to update the firmware? Unfortunately nvflash is
> > not available in source code, and I haven't found any documentation about the
> > early boot process, so it is kind of hard to figure out how all this is
> > supposed to work and consequently find ways to automate these things for
> > production boards.
>
> Try grabbing the Linux4Tegra packages from:
> http://developer.nvidia.com/content/linux-tegra-release-12-alpha-1-released
>
> at least that has a publically obtainable/usable nvflash for a few boards.
> You should be able to adjust the flash.cfg files there for other boards.
>
> It's a little early to say much, but there are some early movements towards
> replacing nvflash with something more open for general Linux usage.
More good news.
> You may also want to look at the "cbootimage" tool here:
>
> https://gitorious.org/cbootimage
That's great. Another missing piece of the puzzle. This seems to be the
open-source equivalent of another tool from Vibrante that allows to create
BCT files from "source" files (I've forgotten the name).
Thanks,
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
From: Russell King - ARM Linux @ 2011-10-14 19:20 UTC (permalink / raw)
To: Olof Johansson
Cc: Arnd Bergmann, Stephen Warren, Peter De Schrijver,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
Colin Cross (ccross@android.com), Erik Gilling
In-Reply-To: <CAOesGMgDwMeVmwo1WJ3tU+ZdjCSJ6F8mY42e_KwTmzAkGQsqmg@mail.gmail.com>
On Fri, Oct 14, 2011 at 09:44:34AM -0700, Olof Johansson wrote:
> That is likely to get messy.
>
> Seems like there could be some use for a (silent) option for a
> platform to indicate that it can do XIP kernel (or zImage), and thus
> not able to use AUTO_ZRELADDR (or other options that require rewriting
> text segment of zImage or kernel).
It's not that.
The options are:
AUTO_ZRELADDR=n ZBOOT_ROM=n => fixed address for decompressed kernel
image to be decompressed to from zreladdr make variable,
decompressor can be loaded to any RAM address.
AUTO_ZRELADDR=y ZBOOT_ROM=n => address for decompressed kernel calculated
from location of zImage in RAM, decompressor must be loaded to
the correct place in RAM and must always copy itself out of
the way prior to decompressing.
AUTO_ZRELADDR=n ZBOOT_ROM=y => fixed address for decompressed kernel
image to be decompressed to from zreladdr make variable,
decompressor can be loaded to any RAM address which doesn't
overlap its BSS segment, or decompressor programmed into
read-only memory at the address to which it was compiled.
AUTO_ZRELADDR=y ZBOOT_ROM=y => invalid (think about it - this results
in a zImage which is built to be run from read-only memory,
and try to write the decompressed image into that read-only
memory.)
This has nothing to do with XIP or not - XIP is a completely separate story,
and if you're building an XIP kernel you're not using the decompressor (so
AUTO_ZRELADDR and ZBOOT_ROM don't even feature.) Neither does the dynamic
code patching stuff like ARM_PATCH_PHYS_VIRT.
ARM_PATCH_PHYS_VIRT has no bearing on AUTO_ZRELADDR or ZBOOT_ROM; that is
a property of the decompressed kernel image itself, and while your
decompressor may restrict where it can decompress the kernel image to,
the decompressed image itself remains free of those dependencies (and
eg, can be turned into a uImage with the appropriate load address
for other platforms.)
As I've said in the past, what I'd _like_ to see is that ARM_PATCH_PHYS_VIRT
be enabled for everything irrespective of any other configuration, and
we're just left with AUTO_ZRELADDR / ZBOOT_ROM to worry about. The
overhead from the P:V patching is soo small that it's not really worth
even having the option in the general case - the only time when P:V
patching doesn't work is with non-linear translations found on some
sparsemem platforms.
But... one thing to note is that it _is_ common to load the decompressor
at a _different_ address to that where the kernel ultimately ends up
residing to avoid the additional copy in the decompressor. My experience
shows that this is quite common on the platforms I had supplied. This
means that if we default to AUTO_ZRELADDR for !ZBOOT_ROM, we end up
having to have developers change their uboot setups to avoid unexpected
results.
^ permalink raw reply
* RE: Adding board support
From: Stephen Warren @ 2011-10-14 19:20 UTC (permalink / raw)
To: Thierry Reding; +Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20111014185847.GA916-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
Thierry Reding wrote at Friday, October 14, 2011 12:59 PM:
> * Stephen Warren wrote:
> > Thierry Reding wrote at Thursday, October 13, 2011 11:50 PM:
...
> > > Another question concerns testing. So far I've always booted a modified
> > > U-Boot (from Vibrante 1.1) to allow booting with an initial ramdisk (loaded
> > > from SD/MMC) as payload for fastboot/quickboot. What are other people using?
> >
> > Personally, I've recently switched to using mainline U-Boot on almost all my
> > boards (Harmony, Seaboard, Ventana). Maybe I'll add TrimSlice support there
> > too. Note that this relies on a number of patches that have been posted to
> > the U-Boot mailing list, but not yet checked into their repos. This completely
> > bypasses fastboot; Tegra's boot ROM runs U-Boot directly instead of fastboot.
>
> I was hoping that somebody had gotten this to work. Would you mind sharing
> the script that you use? All the scripts I've seen so far create some boot
> image (using a tool named mkbootimg) that contains U-Boot.
>
> U-Boot mainline support is another point on my TODO list. Getting the latest
> mainline code with the patches you mention (I assume you are referring to the
> patch series by Simon Glass and Tom Warren) to work would be a good step in
> that direction.
I branched from: git://git.denx.de/u-boot.git master at commit
0841ca90f22d73b0ea4642ef1ce33d879bb2f3ff.
I applied the following:
http://patchwork.ozlabs.org/patch/115862/
http://patchwork.ozlabs.org/patch/115864/
http://patchwork.ozlabs.org/patch/115865/
http://patchwork.ozlabs.org/patch/115860/
http://patchwork.ozlabs.org/patch/115863/
http://patchwork.ozlabs.org/patch/115861/
http://patchwork.ozlabs.org/patch/119321/
http://patchwork.ozlabs.org/patch/119322/
http://patchwork.ozlabs.org/patch/119323/
http://patchwork.ozlabs.org/patch/119324/
http://patchwork.ozlabs.org/patch/119325/
http://patchwork.ozlabs.org/patch/118184/
I applied the following to hack the default environment so I could boot from
SD cards layed out how mine are; you'll probably need to tweak this a bunch:
diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index 07546a4..f30f569 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -104,9 +104,19 @@
/* Environment information */
#define CONFIG_EXTRA_ENV_SETTINGS \
- "console=ttyS0,115200n8\0" \
- "mem=" TEGRA2_SYSMEM "\0" \
- "smpflag=smp\0" \
+ "bootcmd=run usb0_boot ; run usb1_boot ; run mmc1_boot ; run mmc0_boot\0" \
+ "bootdelay=2\0" \
+ "loadaddr=0x00500000\0" \
+ "scriptaddr=0x408000\0" \
+ "script_img=/u-boot/boot.scr.uimg\0" \
+ "mmc0_boot=setenv devnum 0; run mmc_boot;\0" \
+ "mmc1_boot=setenv devnum 1; run mmc_boot;\0" \
+ "usb0_boot=usb start 0; run usb_boot;\0" \
+ "usb1_boot=usb start 1; run usb_boot;\0" \
+ "scr_boot=fatload ${devtype} ${devnum}:c ${scriptaddr} ${script_img};source ${scriptaddr};read ${devtype} ${devnum}:${kernelpart} ${scriptaddr} 0 10;source ${scriptaddr};\0" \
+ "mmc_boot=mmc dev ${devnum};setenv devtype mmc;setenv devname mmcblk${devnum}p;run scr_boot;\0" \
+ "usb_boot=setenv devtype usb;setenv devnum 0;setenv devname sda;run scr_boot;\0" \
+ "platform_extras=lp0_vec=0x2000@0x1C406000 kcrashmem=0x100000@0x02000000 mem=384M@0M nvmem=128M@384M mem=511M@512M\0" \
#define CONFIG_LOADADDR 0x408000 /* def. location for kernel */
#define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */
In order to actually use the resultant u-boot.bin, it's pretty simple if you
already have nvflash working with burn fastboot.
1) Edit flash.cfg (or whatever config file you pass to nvflash to define
The partitions and their content) and replace the filename entry in the
EBT partition with u-boot.bin.
2) I personally remove all the partition entries in flash.cfg except for
BCT, PT, EBT. This will avoid nvflash flashing your Android/... filesystem.
If you want your filesystem in the same flash, don't do this.
Then, run nvflash just like you would normally.
> Have you done any testing with the NVIDIA binary blobs when booting this way?
> The latest information I have from our NVIDIA contacts is that fastboot or
> quickboot are required, for some reason, to make HW accelerated video
> decoding and 3D rendering work.
It's possible the binary drivers accidentally rely on the bootloader
having configured some piece of HW.
However, in general, the bootloader product you use shouldn't affect
whether the binary drivers work.
In particular, the binary drivers certainly work after the ChromeOS
U-Boot boots a board.
Coincidentally, right before seeing your email, I just tried mainline
U-Boot on Seaboard with our Linux4Tegra alpha 1 release, and while X
started, I couldn't see anything on screen. This did previously work
with some old version of ChromeOS's U-Boot. So, there's certainly some
missing HW initialization somewhere.
BTW, you might also want to take a look at NVIDIA's web forums:
http://developer.nvidia.com/beta-forum
While I'm personally happy to answer your questions here, (I work for
a group dedicated to making general Linux support on Tegra) you may find
more people aimed at this kind of support on those forums. I'm not
active on those forums though.
I hope this all helps!
--
nvpublic
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox