Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Stephen Warren 
On 09/12/2012 04:10 PM, Tom Warren wrote:

 diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
 b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c

This whole file is definitely common with Tegra20.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Tom Warren 
Stephen,

On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 09/12/2012 04:10 PM, Tom Warren wrote:

 diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
 b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c

 This whole file is definitely common with Tegra20.

I'm going through your previous comments, but I'll just reply quickly
to this one since it needs clearing up.

The intent of this first series of patches for Tegra30 was just to get
to the command prompt on T30 in the quickest way, while impacting
Tegra20 code as little as possible. Hence, I used Tegra20 files to
create a Tegra30 build, and as I ported it to T30 HW, I tried to
eliminate what I could that I knew for sure was T20-specific and not
useful. But I've made no effort to combine common files/code in this
initial pass. I think it's much easier to understand and review these
files as a separate SoC build, rather than having to parse
common/combined files and code. I intend to do the
combination/common-izing of the TegraXX builds once I have a
reasonable T30 build in u-boot-tegra, perhaps even before I start
porting the drivers.  But this is the initial approach I took.
Hopefully it'll be an acceptable course - I'd hate to have to
back-track.

Thanks for the thorough review,

Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Stephen Warren 
On 09/13/2012 02:16 PM, Tom Warren wrote:
 Stephen,
 
 On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org wrote:
 On 09/12/2012 04:10 PM, Tom Warren wrote:

 diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
 b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c

 This whole file is definitely common with Tegra20.
 
 I'm going through your previous comments, but I'll just reply quickly
 to this one since it needs clearing up.
 
 The intent of this first series of patches for Tegra30 was just to get
 to the command prompt on T30 in the quickest way, while impacting
 Tegra20 code as little as possible. Hence, I used Tegra20 files to
 create a Tegra30 build, and as I ported it to T30 HW, I tried to
 eliminate what I could that I knew for sure was T20-specific and not
 useful. But I've made no effort to combine common files/code in this
 initial pass. I think it's much easier to understand and review these
 files as a separate SoC build, rather than having to parse
 common/combined files and code. I intend to do the
 combination/common-izing of the TegraXX builds once I have a
 reasonable T30 build in u-boot-tegra, perhaps even before I start
 porting the drivers.  But this is the initial approach I took.
 Hopefully it'll be an acceptable course - I'd hate to have to
 back-track.

To be honest, it seems like the patch to add the Tegra30 deltas to the
existing Tegra20 code would be massively smaller than duplicating all of
Tegra20 as Tegra30 and applying those same changes. In the kernel, we
have both Tegra20 and Tegra30 support with run-time differentiation, and
the number of places where we have to do something different is not that
large at all. With the current patch series, there's a huge amount of
code to wade through, so spotting any places that haven't been updated
for Tegra30, or weren't intended to be updated yet, is somewhat painful.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Tom Rini 
On 09/13/2012 01:30 PM, Stephen Warren wrote:
 On 09/13/2012 02:16 PM, Tom Warren wrote:
 Stephen,

 On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 09/12/2012 04:10 PM, Tom Warren wrote:

 diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
 b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c

 This whole file is definitely common with Tegra20.

 I'm going through your previous comments, but I'll just reply quickly
 to this one since it needs clearing up.

 The intent of this first series of patches for Tegra30 was just to get
 to the command prompt on T30 in the quickest way, while impacting
 Tegra20 code as little as possible. Hence, I used Tegra20 files to
 create a Tegra30 build, and as I ported it to T30 HW, I tried to
 eliminate what I could that I knew for sure was T20-specific and not
 useful. But I've made no effort to combine common files/code in this
 initial pass. I think it's much easier to understand and review these
 files as a separate SoC build, rather than having to parse
 common/combined files and code. I intend to do the
 combination/common-izing of the TegraXX builds once I have a
 reasonable T30 build in u-boot-tegra, perhaps even before I start
 porting the drivers.  But this is the initial approach I took.
 Hopefully it'll be an acceptable course - I'd hate to have to
 back-track.
 
 To be honest, it seems like the patch to add the Tegra30 deltas to the
 existing Tegra20 code would be massively smaller than duplicating all of
 Tegra20 as Tegra30 and applying those same changes. In the kernel, we
 have both Tegra20 and Tegra30 support with run-time differentiation, and
 the number of places where we have to do something different is not that
 large at all. With the current patch series, there's a huge amount of
 code to wade through, so spotting any places that haven't been updated
 for Tegra30, or weren't intended to be updated yet, is somewhat painful.

Since we know that the delta can be small, yes, let's just do this right
the first time (or so).  incremental moves, additions and we can work
out run-vs-build time a little further down the road.

-- 
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Tom Warren 
Tom,

On Thu, Sep 13, 2012 at 1:33 PM, Tom Rini tr...@ti.com wrote:
 On 09/13/2012 01:30 PM, Stephen Warren wrote:
 On 09/13/2012 02:16 PM, Tom Warren wrote:
 Stephen,

 On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org 
 wrote:
 On 09/12/2012 04:10 PM, Tom Warren wrote:

 diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
 b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c

 This whole file is definitely common with Tegra20.

 I'm going through your previous comments, but I'll just reply quickly
 to this one since it needs clearing up.

 The intent of this first series of patches for Tegra30 was just to get
 to the command prompt on T30 in the quickest way, while impacting
 Tegra20 code as little as possible. Hence, I used Tegra20 files to
 create a Tegra30 build, and as I ported it to T30 HW, I tried to
 eliminate what I could that I knew for sure was T20-specific and not
 useful. But I've made no effort to combine common files/code in this
 initial pass. I think it's much easier to understand and review these
 files as a separate SoC build, rather than having to parse
 common/combined files and code. I intend to do the
 combination/common-izing of the TegraXX builds once I have a
 reasonable T30 build in u-boot-tegra, perhaps even before I start
 porting the drivers.  But this is the initial approach I took.
 Hopefully it'll be an acceptable course - I'd hate to have to
 back-track.

 To be honest, it seems like the patch to add the Tegra30 deltas to the
 existing Tegra20 code would be massively smaller than duplicating all of
 Tegra20 as Tegra30 and applying those same changes. In the kernel, we
 have both Tegra20 and Tegra30 support with run-time differentiation, and
 the number of places where we have to do something different is not that
 large at all. With the current patch series, there's a huge amount of
 code to wade through, so spotting any places that haven't been updated
 for Tegra30, or weren't intended to be updated yet, is somewhat painful.

 Since we know that the delta can be small, yes, let's just do this right
 the first time (or so).  incremental moves, additions and we can work
 out run-vs-build time a little further down the road.

Sorry, Tom. I'm not clear on exactly which way you'd like to see this go.

Are you advising that I re-cast this patchset as a set of common Tegra
files/code, with deltas/diffs for the Tegra30 changes? That implies, I
think, that I first have to do a patchset that re-orgs Tegra20 code
into common code, and then submit a smaller version of this patchset
that is just deltas for Tegra30.  That means that I'll be touching
everyone's Tegra20 code, and will need Ack's from all the T20 vendors
before I can move forward w/T30 code.

The other approach, which is still a 2-(or more)-patchset process, is
to continue with this patchset for T30, with corrections as per
review, and then immediately work on a 'merge-to-common-code' set of
patches to common-ize Tegra20/30.  That way Tegra20 is unaffected, I
can keep moving forward, and I think the end result will be the same
as the approach above.

I can see value in both approaches, and it shouldn't surprise you that
I'd favor the 2nd approach, since it's less chaotic for me. Let me
know what you think,

Tom

 --
 Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Tom Rini 
On Thu, Sep 13, 2012 at 02:21:54PM -0700, Tom Warren wrote:
 Tom,
 
 On Thu, Sep 13, 2012 at 1:33 PM, Tom Rini tr...@ti.com wrote:
  On 09/13/2012 01:30 PM, Stephen Warren wrote:
  On 09/13/2012 02:16 PM, Tom Warren wrote:
  Stephen,
 
  On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org 
  wrote:
  On 09/12/2012 04:10 PM, Tom Warren wrote:
 
  diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
  b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
 
  This whole file is definitely common with Tegra20.
 
  I'm going through your previous comments, but I'll just reply quickly
  to this one since it needs clearing up.
 
  The intent of this first series of patches for Tegra30 was just to get
  to the command prompt on T30 in the quickest way, while impacting
  Tegra20 code as little as possible. Hence, I used Tegra20 files to
  create a Tegra30 build, and as I ported it to T30 HW, I tried to
  eliminate what I could that I knew for sure was T20-specific and not
  useful. But I've made no effort to combine common files/code in this
  initial pass. I think it's much easier to understand and review these
  files as a separate SoC build, rather than having to parse
  common/combined files and code. I intend to do the
  combination/common-izing of the TegraXX builds once I have a
  reasonable T30 build in u-boot-tegra, perhaps even before I start
  porting the drivers.  But this is the initial approach I took.
  Hopefully it'll be an acceptable course - I'd hate to have to
  back-track.
 
  To be honest, it seems like the patch to add the Tegra30 deltas to the
  existing Tegra20 code would be massively smaller than duplicating all of
  Tegra20 as Tegra30 and applying those same changes. In the kernel, we
  have both Tegra20 and Tegra30 support with run-time differentiation, and
  the number of places where we have to do something different is not that
  large at all. With the current patch series, there's a huge amount of
  code to wade through, so spotting any places that haven't been updated
  for Tegra30, or weren't intended to be updated yet, is somewhat painful.
 
  Since we know that the delta can be small, yes, let's just do this right
  the first time (or so).  incremental moves, additions and we can work
  out run-vs-build time a little further down the road.
 
 Sorry, Tom. I'm not clear on exactly which way you'd like to see this go.
 
 Are you advising that I re-cast this patchset as a set of common Tegra
 files/code, with deltas/diffs for the Tegra30 changes? That implies, I
 think, that I first have to do a patchset that re-orgs Tegra20 code
 into common code, and then submit a smaller version of this patchset
 that is just deltas for Tegra30.  That means that I'll be touching
 everyone's Tegra20 code, and will need Ack's from all the T20 vendors
 before I can move forward w/T30 code.

As far as I'm conerend to do a:
git mv arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c
arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c (just looking at top of
tree mainline) needs just the overall Tegra maintainer to Ack.  The
Custodians page says that's you, and so long as you MAKEALL -s tegra20
before and after, that's good to go.  By that same token, breaking out a
hypothetical set of common functions from tegra20/usb.c into
tegra-common/usb.c and leaving the T20 specific bits in tegra20/usb.c
and adding tegra30/usb.c later just needs you and MAKEALL happy.

 The other approach, which is still a 2-(or more)-patchset process, is
 to continue with this patchset for T30, with corrections as per
 review, and then immediately work on a 'merge-to-common-code' set of
 patches to common-ize Tegra20/30.  That way Tegra20 is unaffected, I
 can keep moving forward, and I think the end result will be the same
 as the approach above.

As has been noted, when you copy files you get a lot of re-review and
it's hard to tell what's new and what's not.  It IS good to post what
you have posted and say please check areas X/Y/Z, it's new code.  But
reviewing code that will be dropped as soon as you switch to the
'merge-to-common-code' branch being the reviewed one is hard, especially
when folks with less Tegra background try and read the patches for
general issues.

 I can see value in both approaches, and it shouldn't surprise you that
 I'd favor the 2nd approach, since it's less chaotic for me. Let me
 know what you think,

Well, I'd argue that since you're going to need to do the
'merge-to-common-code' path at some point, it's going to save you work
to do that now rather than fixup issues in two places.  And again, if
you don't change the code, just where the code is, MAKEALL will catch
your problems for you.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Tom Warren 
Tom,

On Thu, Sep 13, 2012 at 3:04 PM, Tom Rini tr...@ti.com wrote:
 On Thu, Sep 13, 2012 at 02:21:54PM -0700, Tom Warren wrote:
 Tom,

 On Thu, Sep 13, 2012 at 1:33 PM, Tom Rini tr...@ti.com wrote:
  On 09/13/2012 01:30 PM, Stephen Warren wrote:
  On 09/13/2012 02:16 PM, Tom Warren wrote:
  Stephen,
 
  On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren swar...@wwwdotorg.org 
  wrote:
  On 09/12/2012 04:10 PM, Tom Warren wrote:
 
  diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
  b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
 
  This whole file is definitely common with Tegra20.
 
  I'm going through your previous comments, but I'll just reply quickly
  to this one since it needs clearing up.
 
  The intent of this first series of patches for Tegra30 was just to get
  to the command prompt on T30 in the quickest way, while impacting
  Tegra20 code as little as possible. Hence, I used Tegra20 files to
  create a Tegra30 build, and as I ported it to T30 HW, I tried to
  eliminate what I could that I knew for sure was T20-specific and not
  useful. But I've made no effort to combine common files/code in this
  initial pass. I think it's much easier to understand and review these
  files as a separate SoC build, rather than having to parse
  common/combined files and code. I intend to do the
  combination/common-izing of the TegraXX builds once I have a
  reasonable T30 build in u-boot-tegra, perhaps even before I start
  porting the drivers.  But this is the initial approach I took.
  Hopefully it'll be an acceptable course - I'd hate to have to
  back-track.
 
  To be honest, it seems like the patch to add the Tegra30 deltas to the
  existing Tegra20 code would be massively smaller than duplicating all of
  Tegra20 as Tegra30 and applying those same changes. In the kernel, we
  have both Tegra20 and Tegra30 support with run-time differentiation, and
  the number of places where we have to do something different is not that
  large at all. With the current patch series, there's a huge amount of
  code to wade through, so spotting any places that haven't been updated
  for Tegra30, or weren't intended to be updated yet, is somewhat painful.
 
  Since we know that the delta can be small, yes, let's just do this right
  the first time (or so).  incremental moves, additions and we can work
  out run-vs-build time a little further down the road.

 Sorry, Tom. I'm not clear on exactly which way you'd like to see this go.

 Are you advising that I re-cast this patchset as a set of common Tegra
 files/code, with deltas/diffs for the Tegra30 changes? That implies, I
 think, that I first have to do a patchset that re-orgs Tegra20 code
 into common code, and then submit a smaller version of this patchset
 that is just deltas for Tegra30.  That means that I'll be touching
 everyone's Tegra20 code, and will need Ack's from all the T20 vendors
 before I can move forward w/T30 code.

 As far as I'm conerend to do a:
 git mv arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c
 arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c (just looking at top of
 tree mainline) needs just the overall Tegra maintainer to Ack.  The
 Custodians page says that's you, and so long as you MAKEALL -s tegra20
 before and after, that's good to go.  By that same token, breaking out a
 hypothetical set of common functions from tegra20/usb.c into
 tegra-common/usb.c and leaving the T20 specific bits in tegra20/usb.c
 and adding tegra30/usb.c later just needs you and MAKEALL happy.

 The other approach, which is still a 2-(or more)-patchset process, is
 to continue with this patchset for T30, with corrections as per
 review, and then immediately work on a 'merge-to-common-code' set of
 patches to common-ize Tegra20/30.  That way Tegra20 is unaffected, I
 can keep moving forward, and I think the end result will be the same
 as the approach above.

 As has been noted, when you copy files you get a lot of re-review and
 it's hard to tell what's new and what's not.  It IS good to post what
 you have posted and say please check areas X/Y/Z, it's new code.  But
 reviewing code that will be dropped as soon as you switch to the
 'merge-to-common-code' branch being the reviewed one is hard, especially
 when folks with less Tegra background try and read the patches for
 general issues.

 I can see value in both approaches, and it shouldn't surprise you that
 I'd favor the 2nd approach, since it's less chaotic for me. Let me
 know what you think,

 Well, I'd argue that since you're going to need to do the
 'merge-to-common-code' path at some point, it's going to save you work
 to do that now rather than fixup issues in two places.  And again, if
 you don't change the code, just where the code is, MAKEALL will catch
 your problems for you.

Moving the code via git as you pointed out above is fine, but how do I
hook 'tegra-common' into the boards.cfg/Makefile/MAKEALL process? I'd
need a 'tegra-common'  subdir for arm720t, armv7 and an 'arch-tegra'
subdir for

Re: [U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-13 Thread Tom Rini 
On Thu, Sep 13, 2012 at 03:16:21PM -0700, Tom Warren wrote:
 Tom,
 
 On Thu, Sep 13, 2012 at 3:04 PM, Tom Rini tr...@ti.com wrote:
  On Thu, Sep 13, 2012 at 02:21:54PM -0700, Tom Warren wrote:
  Tom,
 
  On Thu, Sep 13, 2012 at 1:33 PM, Tom Rini tr...@ti.com wrote:
   On 09/13/2012 01:30 PM, Stephen Warren wrote:
   On 09/13/2012 02:16 PM, Tom Warren wrote:
   Stephen,
  
   On Thu, Sep 13, 2012 at 1:03 PM, Stephen Warren 
   swar...@wwwdotorg.org wrote:
   On 09/12/2012 04:10 PM, Tom Warren wrote:
  
   diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
   b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
  
   This whole file is definitely common with Tegra20.
  
   I'm going through your previous comments, but I'll just reply quickly
   to this one since it needs clearing up.
  
   The intent of this first series of patches for Tegra30 was just to get
   to the command prompt on T30 in the quickest way, while impacting
   Tegra20 code as little as possible. Hence, I used Tegra20 files to
   create a Tegra30 build, and as I ported it to T30 HW, I tried to
   eliminate what I could that I knew for sure was T20-specific and not
   useful. But I've made no effort to combine common files/code in this
   initial pass. I think it's much easier to understand and review these
   files as a separate SoC build, rather than having to parse
   common/combined files and code. I intend to do the
   combination/common-izing of the TegraXX builds once I have a
   reasonable T30 build in u-boot-tegra, perhaps even before I start
   porting the drivers.  But this is the initial approach I took.
   Hopefully it'll be an acceptable course - I'd hate to have to
   back-track.
  
   To be honest, it seems like the patch to add the Tegra30 deltas to the
   existing Tegra20 code would be massively smaller than duplicating all of
   Tegra20 as Tegra30 and applying those same changes. In the kernel, we
   have both Tegra20 and Tegra30 support with run-time differentiation, and
   the number of places where we have to do something different is not that
   large at all. With the current patch series, there's a huge amount of
   code to wade through, so spotting any places that haven't been updated
   for Tegra30, or weren't intended to be updated yet, is somewhat painful.
  
   Since we know that the delta can be small, yes, let's just do this right
   the first time (or so).  incremental moves, additions and we can work
   out run-vs-build time a little further down the road.
 
  Sorry, Tom. I'm not clear on exactly which way you'd like to see this go.
 
  Are you advising that I re-cast this patchset as a set of common Tegra
  files/code, with deltas/diffs for the Tegra30 changes? That implies, I
  think, that I first have to do a patchset that re-orgs Tegra20 code
  into common code, and then submit a smaller version of this patchset
  that is just deltas for Tegra30.  That means that I'll be touching
  everyone's Tegra20 code, and will need Ack's from all the T20 vendors
  before I can move forward w/T30 code.
 
  As far as I'm conerend to do a:
  git mv arch/arm/cpu/armv7/tegra20/cmd_enterrcm.c
  arch/arm/cpu/armv7/tegra-common/cmd_enterrcm.c (just looking at top of
  tree mainline) needs just the overall Tegra maintainer to Ack.  The
  Custodians page says that's you, and so long as you MAKEALL -s tegra20
  before and after, that's good to go.  By that same token, breaking out a
  hypothetical set of common functions from tegra20/usb.c into
  tegra-common/usb.c and leaving the T20 specific bits in tegra20/usb.c
  and adding tegra30/usb.c later just needs you and MAKEALL happy.
 
  The other approach, which is still a 2-(or more)-patchset process, is
  to continue with this patchset for T30, with corrections as per
  review, and then immediately work on a 'merge-to-common-code' set of
  patches to common-ize Tegra20/30.  That way Tegra20 is unaffected, I
  can keep moving forward, and I think the end result will be the same
  as the approach above.
 
  As has been noted, when you copy files you get a lot of re-review and
  it's hard to tell what's new and what's not.  It IS good to post what
  you have posted and say please check areas X/Y/Z, it's new code.  But
  reviewing code that will be dropped as soon as you switch to the
  'merge-to-common-code' branch being the reviewed one is hard, especially
  when folks with less Tegra background try and read the patches for
  general issues.
 
  I can see value in both approaches, and it shouldn't surprise you that
  I'd favor the 2nd approach, since it's less chaotic for me. Let me
  know what you think,
 
  Well, I'd argue that since you're going to need to do the
  'merge-to-common-code' path at some point, it's going to save you work
  to do that now rather than fixup issues in two places.  And again, if
  you don't change the code, just where the code is, MAKEALL will catch
  your problems for you.
 
 Moving the code via git as you pointed out above is fine, but how do I
 hook

[U-Boot] [PATCH 3/9] Tegra: T30: Add CPU (armv7) files

2012-09-12 Thread Tom Warren 
Signed-off-by: Tom Warren twar...@nvidia.com
---
 arch/arm/cpu/armv7/tegra30/Makefile   |   48 +
 arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c |   65 +
 arch/arm/cpu/armv7/tegra30/config.mk  |   26 +++
 3 files changed, 139 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/tegra30/Makefile
 create mode 100644 arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
 create mode 100644 arch/arm/cpu/armv7/tegra30/config.mk

diff --git a/arch/arm/cpu/armv7/tegra30/Makefile 
b/arch/arm/cpu/armv7/tegra30/Makefile
new file mode 100644
index 000..3b98e23
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra30/Makefile
@@ -0,0 +1,48 @@
+#
+# (C) Copyright 20102012 Nvidia Corporation.
+#
+# (C) Copyright 2000-2003
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB=  $(obj)lib$(SOC).o
+
+COBJS-$(CONFIG_CMD_ENTERRCM) += cmd_enterrcm.o
+
+COBJS  := $(COBJS-y)
+SRCS   := $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+   $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c 
b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
new file mode 100644
index 000..e146938
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra30/cmd_enterrcm.c
@@ -0,0 +1,65 @@
+/*
+ * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Derived from code (arch/arm/lib/reset.c) that is:
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Marius Groeger mgroe...@sysgo.de
+ *
+ * (C) Copyright 2002
+ * Sysgo Real-Time Solutions, GmbH www.elinos.com
+ * Alex Zuepke a...@sysgo.de
+ *
+ * (C) Copyright 2002
+ * Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+ *
+ * (C) Copyright 2004
+ * DAVE Srl
+ * http://www.dave-tech.it
+ * http://www.wawnet.biz
+ * mailto:i...@wawnet.biz
+ *
+ * (C) Copyright 2004 Texas Insturments
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see http://www.gnu.org/licenses/.
+ */
+
+#include common.h
+#include asm/arch/tegra30.h
+#include asm/arch/pmc.h
+
+static int do_enterrcm(cmd_tbl_t *cmdtp, int flag, int argc,
+  char * const argv[])
+{
+   struct pmc_ctlr *pmc = (struct pmc_ctlr *)NV_PA_PMC_BASE;
+
+   puts(Entering RCM...\n);
+   udelay(5);
+
+   pmc-pmc_scratch0 = 2;
+   disable_interrupts();
+   reset_cpu(0);
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   enterrcm, 1, 0, do_enterrcm,
+   reset Tegra and enter USB Recovery Mode,
+   
+);
diff --git a/arch/arm/cpu/armv7/tegra30/config.mk 
b/arch/arm/cpu/armv7/tegra30/config.mk
new file mode 100644
index 000..fad9efa
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra30/config.mk
@@ -0,0 +1,26 @@
+#
+# (C) Copyright 2010-2012
+# NVIDIA Corporation www.nvidia.com
+#
+# (C) Copyright 2002
+# Gary Jennejohn, DENX Software Engineering, ga...@denx.de
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is