[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Thierry Reding]

Move the nand-controller node to the tegra20-tamonten.dtsi so that it
can be shared between all derived boards.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
This depends on Tom's "Tegra: MMC: Add DT support for MMC to T20 boards"
patches.

 board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++++++++++
 board/avionic-design/dts/tegra20-tec.dts       | 11 -----------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi b/board/avionic-design/dts/tegra20-tamonten.dtsi
index 4766aba..0a95ac1 100644
--- a/board/avionic-design/dts/tegra20-tamonten.dtsi
+++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
@@ -279,6 +279,17 @@
 		status = "okay";
 	};
 
+	nand-controller at 70008000 {
+		nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
+		nvidia,width = <8>;
+		nvidia,timing = <26 100 20 80 20 10 12 10 70>;
+
+		nand at 0 {
+			reg = <0>;
+			compatible = "hynix,hy27uf4g2b", "nand-flash";
+		};
+	};
+
 	i2c at 7000c000 {
 		clock-frequency = <400000>;
 		status = "okay";
diff --git a/board/avionic-design/dts/tegra20-tec.dts b/board/avionic-design/dts/tegra20-tec.dts
index 376d279..694682c 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/board/avionic-design/dts/tegra20-tec.dts
@@ -32,17 +32,6 @@
 		clock-frequency = <216000000>;
 	};
 
-	nand-controller at 70008000 {
-		nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
-		nvidia,width = <8>;
-		nvidia,timing = <26 100 20 80 20 10 12 10 70>;
-
-		nand at 0 {
-			reg = <0>;
-			compatible = "hynix,hy27uf4g2b", "nand-flash";
-		};
-	};
-
 	i2c at 7000c000 {
 		status = "disabled";
 	};
-- 
1.8.1.2

[U-Boot] [PATCH 2/4] Tegra: Medcom-Wide: Enable NAND and boot script support

[Thierry Reding]

Boot script support brings Medcom-Wide in line with other Tegra boards.
In order to enable booting a Linux kernel with initial ramdisk, also add
support for the new FIT image type.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 include/configs/medcom-wide.h | 34 ++++++++++++++++++++--------------
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/include/configs/medcom-wide.h b/include/configs/medcom-wide.h
index bae4ba0..ea8e83f 100644
--- a/include/configs/medcom-wide.h
+++ b/include/configs/medcom-wide.h
@@ -44,14 +44,29 @@
 #define CONFIG_BOARD_EARLY_INIT_F
 #define CONFIG_BOARD_LATE_INIT
 
-#define CONFIG_ENV_IS_NOWHERE
-
 /* SD/MMC */
 #define CONFIG_MMC
 #define CONFIG_GENERIC_MMC
 #define CONFIG_TEGRA_MMC
 #define CONFIG_CMD_MMC
 
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+#define CONFIG_FS_EXT4
+#define CONFIG_FS_FAT
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
+
+/* NAND support */
+#define CONFIG_CMD_NAND
+#define CONFIG_TEGRA_NAND
+#define CONFIG_SYS_MAX_NAND_DEVICE	1
+
+/* Environment in NAND, aligned to start of last sector */
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET		(SZ_512M - SZ_128K) /* 128K sectors */
+
 /* USB host support */
 #define CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_TEGRA
@@ -66,18 +81,6 @@
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_DHCP
 
-#define CONFIG_DOS_PARTITION
-#define CONFIG_EFI_PARTITION
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-
-#define CONFIG_FIT
-
-#define CONFIG_BOOTCOMMAND				\
-	"mmc rescan;"					\
-	"ext2load mmc 0 0x17000000 /boot/uImage;"	\
-	"bootm"
-
 /* LCD support */
 #define CONFIG_LCD
 #define CONFIG_PWM_TEGRA
@@ -85,6 +88,9 @@
 #define LCD_BPP LCD_COLOR16
 #define CONFIG_SYS_WHITE_ON_BLACK
 
+/* support the new (FDT-based) image format */
+#define CONFIG_FIT
+
 #include "tegra-common-post.h"
 
 #endif /* __CONFIG_H */
-- 
1.8.1.2

[U-Boot] [PATCH 2/4] Tegra: Medcom-Wide: Enable NAND and boot script support

[Stephen Warren]

On 02/14/2013 12:54 AM, Thierry Reding wrote:
> Boot script support brings Medcom-Wide in line with other Tegra boards.
> In order to enable booting a Linux kernel with initial ramdisk, also add
> support for the new FIT image type.

I don't care if you enable FIT on your boards, but I would like to point
out that there's no requirement to enable FIT just to support ramdisks.
bootz/bootm support separate files/locations/... for ramdisks if you
want, and I'm pretty sure I validated it worked once at least.

[U-Boot] [PATCH 2/4] Tegra: Medcom-Wide: Enable NAND and boot script support

[Thierry Reding]

On Thu, Feb 14, 2013 at 10:19:28AM -0700, Stephen Warren wrote:
> On 02/14/2013 12:54 AM, Thierry Reding wrote:
> > Boot script support brings Medcom-Wide in line with other Tegra boards.
> > In order to enable booting a Linux kernel with initial ramdisk, also add
> > support for the new FIT image type.
> 
> I don't care if you enable FIT on your boards, but I would like to point
> out that there's no requirement to enable FIT just to support ramdisks.
> bootz/bootm support separate files/locations/... for ramdisks if you
> want, and I'm pretty sure I validated it worked once at least.

Yes, I seem to remember using that as well at some point. In most of our
products we ship a single uImage, though, which contains both the zImage
and the initrd.gz (when we can support all features on mainline, a DTB
will also be part of the same uImage). The main reason why we do this is
because it reduces the number of files that need to be distributed.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130214/a7bcc31b/attachment.pgp>

[U-Boot] [PATCH 3/4] Tegra: Plutux: Enable NAND and boot script support

[Thierry Reding]

Boot script support brings Plutux in line with other Tegra boards. In
order to enable booting a Linux kernel with initial ramdisk, also add
support for the new FIT image type.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 include/configs/plutux.h | 31 +++++++++++++++++++------------
 1 file changed, 19 insertions(+), 12 deletions(-)

diff --git a/include/configs/plutux.h b/include/configs/plutux.h
index deee237..3332ea8 100644
--- a/include/configs/plutux.h
+++ b/include/configs/plutux.h
@@ -42,8 +42,7 @@
 #define CONFIG_SYS_NS16550_COM1		NV_PA_APB_UARTD_BASE
 
 #define CONFIG_BOARD_EARLY_INIT_F
-
-#define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_BOARD_LATE_INIT
 
 /* SD/MMC */
 #define CONFIG_MMC
@@ -51,6 +50,23 @@
 #define CONFIG_TEGRA_MMC
 #define CONFIG_CMD_MMC
 
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+#define CONFIG_FS_EXT4
+#define CONFIG_FS_FAT
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
+
+/* NAND support */
+#define CONFIG_CMD_NAND
+#define CONFIG_TEGRA_NAND
+#define CONFIG_SYS_MAX_NAND_DEVICE	1
+
+/* Environment in NAND, aligned to start of last sector */
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET		(SZ_512M - SZ_128K) /* 128K sectors */
+
 /* USB host support */
 #define CONFIG_USB_EHCI
 #define CONFIG_USB_EHCI_TEGRA
@@ -65,18 +81,9 @@
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_DHCP
 
-#define CONFIG_DOS_PARTITION
-#define CONFIG_EFI_PARTITION
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-
+/* support the new (FDT-based) image format */
 #define CONFIG_FIT
 
-#define CONFIG_BOOTCOMMAND				\
-	"mmc rescan;"					\
-	"ext2load mmc 0 0x17000000 /boot/uImage;"	\
-	"bootm"
-
 #include "tegra-common-post.h"
 
 #endif /* __CONFIG_H */
-- 
1.8.1.2

[U-Boot] [PATCH 4/4] Tegra: TEC: Enable boot script support

[Thierry Reding]

Boot script support brings TEC in line with other Tegra boards. To
enable booting a Linux kernel with initial ramdisk, also include support
for the new FIT image type.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 include/configs/tec.h | 23 +++++++++++------------
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/include/configs/tec.h b/include/configs/tec.h
index caeb9cd..64f6c65 100644
--- a/include/configs/tec.h
+++ b/include/configs/tec.h
@@ -50,6 +50,14 @@
 #define CONFIG_TEGRA_MMC
 #define CONFIG_CMD_MMC
 
+#define CONFIG_DOS_PARTITION
+#define CONFIG_EFI_PARTITION
+#define CONFIG_FS_EXT4
+#define CONFIG_FS_FAT
+#define CONFIG_CMD_EXT2
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_FS_GENERIC
+
 /* NAND support */
 #define CONFIG_CMD_NAND
 #define CONFIG_TEGRA_NAND
@@ -73,18 +81,6 @@
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_DHCP
 
-#define CONFIG_DOS_PARTITION
-#define CONFIG_EFI_PARTITION
-#define CONFIG_CMD_EXT2
-#define CONFIG_CMD_FAT
-
-#define CONFIG_FIT
-
-#define CONFIG_BOOTCOMMAND				\
-	"mmc rescan;"					\
-	"ext2load mmc 0 0x17000000 /boot/uImage;"	\
-	"bootm"
-
 /* LCD support */
 #define CONFIG_LCD
 #define CONFIG_PWM_TEGRA
@@ -92,6 +88,9 @@
 #define LCD_BPP LCD_COLOR16
 #define CONFIG_SYS_WHITE_ON_BLACK
 
+/* support the new (FDT-based) image format */
+#define CONFIG_FIT
+
 #include "tegra-common-post.h"
 
 #endif /* __CONFIG_H */
-- 
1.8.1.2

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

Thierry,

On Thu, Feb 14, 2013 at 12:54 AM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> Move the nand-controller node to the tegra20-tamonten.dtsi so that it
> can be shared between all derived boards.
>
> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> ---
> This depends on Tom's "Tegra: MMC: Add DT support for MMC to T20 boards"
> patches.
>
>  board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++++++++++
>  board/avionic-design/dts/tegra20-tec.dts       | 11 -----------
>  2 files changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi b/board/avionic-design/dts/tegra20-tamonten.dtsi
> index 4766aba..0a95ac1 100644
> --- a/board/avionic-design/dts/tegra20-tamonten.dtsi
> +++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
> @@ -279,6 +279,17 @@
>                 status = "okay";
>         };
>
> +       nand-controller at 70008000 {
> +               nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
> +               nvidia,width = <8>;
> +               nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> +
> +               nand at 0 {
> +                       reg = <0>;
> +                       compatible = "hynix,hy27uf4g2b", "nand-flash";
> +               };
> +       };
> +
>         i2c at 7000c000 {
>                 clock-frequency = <400000>;
>                 status = "okay";
> diff --git a/board/avionic-design/dts/tegra20-tec.dts b/board/avionic-design/dts/tegra20-tec.dts
> index 376d279..694682c 100644
> --- a/board/avionic-design/dts/tegra20-tec.dts
> +++ b/board/avionic-design/dts/tegra20-tec.dts
> @@ -32,17 +32,6 @@
>                 clock-frequency = <216000000>;
>         };
>
> -       nand-controller at 70008000 {
> -               nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
> -               nvidia,width = <8>;
> -               nvidia,timing = <26 100 20 80 20 10 12 10 70>;
> -
> -               nand at 0 {
> -                       reg = <0>;
> -                       compatible = "hynix,hy27uf4g2b", "nand-flash";
> -               };
> -       };
> -
>         i2c at 7000c000 {
>                 status = "disabled";
>         };
> --
> 1.8.1.2
>
I kinda lost track of this patchset. I'd like to move it into
u-boot-tegra/next if you think it's ready, but I'm not sure if it
conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
tegra: enable a common set of disk-related commands").

Let me know how you want me to proceed - I'd like to get a PR off to
Albert for ARM/master this week if possible.

Thanks,

Tom

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Thierry Reding]

On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
[...]
> I kinda lost track of this patchset. I'd like to move it into
> u-boot-tegra/next if you think it's ready, but I'm not sure if it
> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
> tegra: enable a common set of disk-related commands").

I can rebase my patches on top of Stephen's work and resend them if it
helps.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130304/eaa935bf/attachment.pgp>

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

Thierry,

On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
> [...]
>> I kinda lost track of this patchset. I'd like to move it into
>> u-boot-tegra/next if you think it's ready, but I'm not sure if it
>> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
>> tegra: enable a common set of disk-related commands").
>
> I can rebase my patches on top of Stephen's work and resend them if it
> helps.
>
> Thierry
The only problem I see is that Stephen's patchset isn't exclusively
Tegra-based, so I'm not sure I want to bring it into the Tegra tree
and cause problems when I do a PR. The other half of the patchset is
assigned to Tom Rini.

Stephen - how would you like me to resolve this?

Thanks,

Tom

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Stephen Warren]

On 03/04/2013 04:26 PM, Tom Warren wrote:
> Thierry,
> 
> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
> <thierry.reding@avionic-design.de> wrote:
>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
>> [...]
>>> I kinda lost track of this patchset. I'd like to move it into
>>> u-boot-tegra/next if you think it's ready, but I'm not sure if it
>>> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
>>> tegra: enable a common set of disk-related commands").
>>
>> I can rebase my patches on top of Stephen's work and resend them if it
>> helps.
>>
>> Thierry
> The only problem I see is that Stephen's patchset isn't exclusively
> Tegra-based, so I'm not sure I want to bring it into the Tegra tree
> and cause problems when I do a PR. The other half of the patchset is
> assigned to Tom Rini.
> 
> Stephen - how would you like me to resolve this?

Hmmm. Thierry's patch series does quite a few things at once.

I'd suggest that Thierry posts a series that /just/ enables NAND
support. It should be possible to apply that on its own without any
conflicts/dependencies on my series.

Enabling FIT could also be a separate series without any
conflicts/dependencies.

A lot of the rest of that series is effectively part of my series, since
I ended up enabling all those new options in the various common Tegra
config files in my series.

The only thing left over is the removal of the custom definition of
CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series.

Re: How to get my series into Tegra's tree. I think it'd be fine to
apply my series to the Tegra tree even though it touches disk/partition
code if you can get the/a maintainer for that code to ack it. Probably
someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes
wouldn't have to wait long I hope.

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 03/04/2013 04:26 PM, Tom Warren wrote:
>> Thierry,
>>
>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
>> <thierry.reding@avionic-design.de> wrote:
>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
>>> [...]
>>>> I kinda lost track of this patchset. I'd like to move it into
>>>> u-boot-tegra/next if you think it's ready, but I'm not sure if it
>>>> conflicts with/works with Stephen's 4th patch of his v2 series ("ARM:
>>>> tegra: enable a common set of disk-related commands").
>>>
>>> I can rebase my patches on top of Stephen's work and resend them if it
>>> helps.
>>>
>>> Thierry
>> The only problem I see is that Stephen's patchset isn't exclusively
>> Tegra-based, so I'm not sure I want to bring it into the Tegra tree
>> and cause problems when I do a PR. The other half of the patchset is
>> assigned to Tom Rini.
>>
>> Stephen - how would you like me to resolve this?
>
> Hmmm. Thierry's patch series does quite a few things at once.
>
> I'd suggest that Thierry posts a series that /just/ enables NAND
> support. It should be possible to apply that on its own without any
> conflicts/dependencies on my series.
>
> Enabling FIT could also be a separate series without any
> conflicts/dependencies.
>
> A lot of the rest of that series is effectively part of my series, since
> I ended up enabling all those new options in the various common Tegra
> config files in my series.
>
> The only thing left over is the removal of the custom definition of
> CONFIG_BOOTCOMMAND in the AD headers. That should happen after my series.
>
> Re: How to get my series into Tegra's tree. I think it'd be fine to
> apply my series to the Tegra tree even though it touches disk/partition
> code if you can get the/a maintainer for that code to ack it. Probably
> someone like Tom Rini. That way, Thierry's CONFIG_BOOTCOMMAND changes
> wouldn't have to wait long I hope.
Sorry, kinda dropped the ball on this while I was working on the padcfg changes.

Tom Rini - do you agree with Stephen's approach for the disk parts of
his patchset? If so, I can apply it to u-boot-tegra/next today & push.

Thierry - assuming the above happens, can you rework/split your
patchset as Stephen outlines above? Then I can apply your patches &
push and we'll be ready for a PR early next week after some
testing/MAKEALL/etc.

Thanks,

Tom

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2013 11:36 AM, Tom Warren wrote:
> On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren
> <swarren@wwwdotorg.org> wrote:
>> On 03/04/2013 04:26 PM, Tom Warren wrote:
>>> Thierry,
>>> 
>>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding 
>>> <thierry.reding@avionic-design.de> wrote:
>>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote: 
>>>> [...]
>>>>> I kinda lost track of this patchset. I'd like to move it
>>>>> into u-boot-tegra/next if you think it's ready, but I'm not
>>>>> sure if it conflicts with/works with Stephen's 4th patch of
>>>>> his v2 series ("ARM: tegra: enable a common set of
>>>>> disk-related commands").
>>>> 
>>>> I can rebase my patches on top of Stephen's work and resend
>>>> them if it helps.
>>>> 
>>>> Thierry
>>> The only problem I see is that Stephen's patchset isn't
>>> exclusively Tegra-based, so I'm not sure I want to bring it
>>> into the Tegra tree and cause problems when I do a PR. The
>>> other half of the patchset is assigned to Tom Rini.
>>> 
>>> Stephen - how would you like me to resolve this?
>> 
>> Hmmm. Thierry's patch series does quite a few things at once.
>> 
>> I'd suggest that Thierry posts a series that /just/ enables NAND 
>> support. It should be possible to apply that on its own without
>> any conflicts/dependencies on my series.
>> 
>> Enabling FIT could also be a separate series without any 
>> conflicts/dependencies.
>> 
>> A lot of the rest of that series is effectively part of my
>> series, since I ended up enabling all those new options in the
>> various common Tegra config files in my series.
>> 
>> The only thing left over is the removal of the custom definition
>> of CONFIG_BOOTCOMMAND in the AD headers. That should happen after
>> my series.
>> 
>> Re: How to get my series into Tegra's tree. I think it'd be fine
>> to apply my series to the Tegra tree even though it touches
>> disk/partition code if you can get the/a maintainer for that code
>> to ack it. Probably someone like Tom Rini. That way, Thierry's
>> CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope.
> Sorry, kinda dropped the ball on this while I was working on the
> padcfg changes.
> 
> Tom Rini - do you agree with Stephen's approach for the disk parts
> of his patchset? If so, I can apply it to u-boot-tegra/next today &
> push.

Can you give me some patchwork links?  I'm getting going on another
round of pulling things into master today.  Thanks!

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJROhV4AAoJENk4IS6UOR1WgboP/iZFuJFTOf9lLyR38dNHk66p
7h/wexQRQr7CIMYUwHsS55IStunXNif4Njm9u6ehNbjz45v0vpIVUlV37NjhFG82
3XwTRLvt1w9Aag6h8jB/We+Z73rArhHfpq3dbB5FuyX4n+J3Dq+7sRp7kZkRu7gS
skSzcAE5b0eMB6OiPwuG0zkVkMaf0ryYZAzjsRvXgT9302YSigHdM0TnZColzcLt
LQREK58EiQiO20DGuTYIyRUzEG9MlSiv9J7GOLbtgdEbXES/P/v40lybvPwtNdre
q3UmPrDRCMJ2eqtyVZbTRLEAxN9vUhd11cfDBb2HOSsFTilJkpu1GBaR80nmca3p
HgyeHvZnABQ/rvAVRPHP54UT+iXF531Z3CRUF5vQcT0N/JHH1LuyHVuij23b5Fxt
LcM51YNijmFkisZVTxgX4mrFNpGmSvP+4jEky+t6Vz26uZ8YYfa26Lwlby6EFrKy
Nz8QduohPsuSi92QQjSb5LJn86QxFNwz+20UjXPLilQRet/W5WosGJqdUKdH1aun
tkZlUZw7mtu9lIEqJJq4JpNKYP7NoMmDygyob0v+VCUPshqKig6Xs3voQMaAC44i
90OBzokS/Vj/AYJQ7eXwpVsdYkrPc5UXBU70/5QMftEVDR6wk0cLHou18F3wYeQd
HpIFPnhpM0/7rMKXchV3
=FTH6
-----END PGP SIGNATURE-----

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

Tom

On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/08/2013 11:36 AM, Tom Warren wrote:
>> On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren
>> <swarren@wwwdotorg.org> wrote:
>>> On 03/04/2013 04:26 PM, Tom Warren wrote:
>>>> Thierry,
>>>>
>>>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
>>>> <thierry.reding@avionic-design.de> wrote:
>>>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren wrote:
>>>>> [...]
>>>>>> I kinda lost track of this patchset. I'd like to move it
>>>>>> into u-boot-tegra/next if you think it's ready, but I'm not
>>>>>> sure if it conflicts with/works with Stephen's 4th patch of
>>>>>> his v2 series ("ARM: tegra: enable a common set of
>>>>>> disk-related commands").
>>>>>
>>>>> I can rebase my patches on top of Stephen's work and resend
>>>>> them if it helps.
>>>>>
>>>>> Thierry
>>>> The only problem I see is that Stephen's patchset isn't
>>>> exclusively Tegra-based, so I'm not sure I want to bring it
>>>> into the Tegra tree and cause problems when I do a PR. The
>>>> other half of the patchset is assigned to Tom Rini.
>>>>
>>>> Stephen - how would you like me to resolve this?
>>>
>>> Hmmm. Thierry's patch series does quite a few things at once.
>>>
>>> I'd suggest that Thierry posts a series that /just/ enables NAND
>>> support. It should be possible to apply that on its own without
>>> any conflicts/dependencies on my series.
>>>
>>> Enabling FIT could also be a separate series without any
>>> conflicts/dependencies.
>>>
>>> A lot of the rest of that series is effectively part of my
>>> series, since I ended up enabling all those new options in the
>>> various common Tegra config files in my series.
>>>
>>> The only thing left over is the removal of the custom definition
>>> of CONFIG_BOOTCOMMAND in the AD headers. That should happen after
>>> my series.
>>>
>>> Re: How to get my series into Tegra's tree. I think it'd be fine
>>> to apply my series to the Tegra tree even though it touches
>>> disk/partition code if you can get the/a maintainer for that code
>>> to ack it. Probably someone like Tom Rini. That way, Thierry's
>>> CONFIG_BOOTCOMMAND changes wouldn't have to wait long I hope.
>> Sorry, kinda dropped the ball on this while I was working on the
>> padcfg changes.
>>
>> Tom Rini - do you agree with Stephen's approach for the disk parts
>> of his patchset? If so, I can apply it to u-boot-tegra/next today &
>> push.
>
> Can you give me some patchwork links?  I'm getting going on another
> round of pulling things into master today.  Thanks!
>
> - --
> Tom

Sure:

http://patchwork.ozlabs.org/patch/224204/
http://patchwork.ozlabs.org/patch/224205/
http://patchwork.ozlabs.org/patch/224206/
http://patchwork.ozlabs.org/patch/224207/

204/205 are assigned to you; 206/207 to me.

Tom

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2013 11:48 AM, Tom Warren wrote:
> On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <trini@ti.com> wrote:
>> On 03/08/2013 11:36 AM, Tom Warren wrote:
>>> On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren 
>>> <swarren@wwwdotorg.org> wrote:
>>>> On 03/04/2013 04:26 PM, Tom Warren wrote:
>>>>> Thierry,
>>>>> 
>>>>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding 
>>>>> <thierry.reding@avionic-design.de> wrote:
>>>>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren
>>>>>> wrote: [...]
>>>>>>> I kinda lost track of this patchset. I'd like to move
>>>>>>> it into u-boot-tegra/next if you think it's ready, but
>>>>>>> I'm not sure if it conflicts with/works with Stephen's
>>>>>>> 4th patch of his v2 series ("ARM: tegra: enable a
>>>>>>> common set of disk-related commands").
>>>>>> 
>>>>>> I can rebase my patches on top of Stephen's work and
>>>>>> resend them if it helps.
>>>>>> 
>>>>>> Thierry
>>>>> The only problem I see is that Stephen's patchset isn't 
>>>>> exclusively Tegra-based, so I'm not sure I want to bring
>>>>> it into the Tegra tree and cause problems when I do a PR.
>>>>> The other half of the patchset is assigned to Tom Rini.
>>>>> 
>>>>> Stephen - how would you like me to resolve this?
>>>> 
>>>> Hmmm. Thierry's patch series does quite a few things at
>>>> once.
>>>> 
>>>> I'd suggest that Thierry posts a series that /just/ enables
>>>> NAND support. It should be possible to apply that on its own
>>>> without any conflicts/dependencies on my series.
>>>> 
>>>> Enabling FIT could also be a separate series without any 
>>>> conflicts/dependencies.
>>>> 
>>>> A lot of the rest of that series is effectively part of my 
>>>> series, since I ended up enabling all those new options in
>>>> the various common Tegra config files in my series.
>>>> 
>>>> The only thing left over is the removal of the custom
>>>> definition of CONFIG_BOOTCOMMAND in the AD headers. That
>>>> should happen after my series.
>>>> 
>>>> Re: How to get my series into Tegra's tree. I think it'd be
>>>> fine to apply my series to the Tegra tree even though it
>>>> touches disk/partition code if you can get the/a maintainer
>>>> for that code to ack it. Probably someone like Tom Rini. That
>>>> way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to
>>>> wait long I hope.
>>> Sorry, kinda dropped the ball on this while I was working on
>>> the padcfg changes.
>>> 
>>> Tom Rini - do you agree with Stephen's approach for the disk
>>> parts of his patchset? If so, I can apply it to
>>> u-boot-tegra/next today & push.
>> 
>> Can you give me some patchwork links?  I'm getting going on
>> another round of pulling things into master today.  Thanks!
> 
> Sure:
> 
> http://patchwork.ozlabs.org/patch/224204/ 
> http://patchwork.ozlabs.org/patch/224205/ 
> http://patchwork.ozlabs.org/patch/224206/ 
> http://patchwork.ozlabs.org/patch/224207/
> 
> 204/205 are assigned to you; 206/207 to me.

OK, ack'd, lets move them along the tegra tree since that's where
they're really used.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJROhiQAAoJENk4IS6UOR1Wr50P/RIsDFVP62XXxKOfcpQtAUYX
7QHGLX1+qS58pAFRwclIxs64VzIm2dT5xDplzilABJH8BTE6MnUyKqkKbeP4M8pR
dtwsVROHK8QdI09bZWN3sBn8B9derkLlsg58lzK8YooeOHJznQhdCxNXEa99/5HJ
WLVx7buxUyMYQINyFQH83pCm9e67R/k7KYmr+D3yyvLLpxSyJI++1BpgRDzNhG74
DHacV6gBqD+bMBS62TTtfxGBOHXZgfrSxxuooFHJa8kJef73xt6LKOWwY6KV/eVj
cbk6utg7kiSr50AknVwatIZ+aig/uBuXmoLs6IRIkrgn9fVj4yYmmiLcdgfbqgdU
mZSE//EW9xQ2mL6qQDEFOOdqrZ2xs9ipf59LqAzKloh41SAWzpxrr2KSp5jpz7rX
mjpMPUMZ7lsWNET8x+1rj22MnFWXtfl3EAHTF3WX1FdvWbm63MRLRYmGEf3LzdXW
NuA5vpbQEgjnabwg6IGWcxGtPFKCChePThZ3lsK9DT/ozn4pmlvQMzFGL7PHZjX7
ZJcSW/mHTR5HxZC5P7+sgVbGPpwnuUT/Hia/j0kkM+cyCVaqRka649+fIM3Ozrgh
yvpqPu2R6JhbwGECmW6AusFGx8Vi/XXC70XfryymGGJB8tDU/6h0HogYYB9PS21e
yxBeqziVVusJSwPqn6E1
=d+6W
-----END PGP SIGNATURE-----

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini <trini@ti.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/08/2013 11:48 AM, Tom Warren wrote:
>> On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <trini@ti.com> wrote:
>>> On 03/08/2013 11:36 AM, Tom Warren wrote:
>>>> On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren
>>>> <swarren@wwwdotorg.org> wrote:
>>>>> On 03/04/2013 04:26 PM, Tom Warren wrote:
>>>>>> Thierry,
>>>>>>
>>>>>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
>>>>>> <thierry.reding@avionic-design.de> wrote:
>>>>>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren
>>>>>>> wrote: [...]
>>>>>>>> I kinda lost track of this patchset. I'd like to move
>>>>>>>> it into u-boot-tegra/next if you think it's ready, but
>>>>>>>> I'm not sure if it conflicts with/works with Stephen's
>>>>>>>> 4th patch of his v2 series ("ARM: tegra: enable a
>>>>>>>> common set of disk-related commands").
>>>>>>>
>>>>>>> I can rebase my patches on top of Stephen's work and
>>>>>>> resend them if it helps.
>>>>>>>
>>>>>>> Thierry
>>>>>> The only problem I see is that Stephen's patchset isn't
>>>>>> exclusively Tegra-based, so I'm not sure I want to bring
>>>>>> it into the Tegra tree and cause problems when I do a PR.
>>>>>> The other half of the patchset is assigned to Tom Rini.
>>>>>>
>>>>>> Stephen - how would you like me to resolve this?
>>>>>
>>>>> Hmmm. Thierry's patch series does quite a few things at
>>>>> once.
>>>>>
>>>>> I'd suggest that Thierry posts a series that /just/ enables
>>>>> NAND support. It should be possible to apply that on its own
>>>>> without any conflicts/dependencies on my series.
>>>>>
>>>>> Enabling FIT could also be a separate series without any
>>>>> conflicts/dependencies.
>>>>>
>>>>> A lot of the rest of that series is effectively part of my
>>>>> series, since I ended up enabling all those new options in
>>>>> the various common Tegra config files in my series.
>>>>>
>>>>> The only thing left over is the removal of the custom
>>>>> definition of CONFIG_BOOTCOMMAND in the AD headers. That
>>>>> should happen after my series.
>>>>>
>>>>> Re: How to get my series into Tegra's tree. I think it'd be
>>>>> fine to apply my series to the Tegra tree even though it
>>>>> touches disk/partition code if you can get the/a maintainer
>>>>> for that code to ack it. Probably someone like Tom Rini. That
>>>>> way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to
>>>>> wait long I hope.
>>>> Sorry, kinda dropped the ball on this while I was working on
>>>> the padcfg changes.
>>>>
>>>> Tom Rini - do you agree with Stephen's approach for the disk
>>>> parts of his patchset? If so, I can apply it to
>>>> u-boot-tegra/next today & push.
>>>
>>> Can you give me some patchwork links?  I'm getting going on
>>> another round of pulling things into master today.  Thanks!
>>
>> Sure:
>>
>> http://patchwork.ozlabs.org/patch/224204/
>> http://patchwork.ozlabs.org/patch/224205/
>> http://patchwork.ozlabs.org/patch/224206/
>> http://patchwork.ozlabs.org/patch/224207/
>>
>> 204/205 are assigned to you; 206/207 to me.
>
> OK, ack'd, lets move them along the tegra tree since that's where
> they're really used.
>
> - --
> Tom
Will do - thanks.

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Tom Warren]

Thierry,

On Fri, Mar 8, 2013 at 9:58 AM, Tom Warren <twarren.nvidia@gmail.com> wrote:
> On Fri, Mar 8, 2013 at 9:57 AM, Tom Rini <trini@ti.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 03/08/2013 11:48 AM, Tom Warren wrote:
>>> On Fri, Mar 8, 2013 at 9:44 AM, Tom Rini <trini@ti.com> wrote:
>>>> On 03/08/2013 11:36 AM, Tom Warren wrote:
>>>>> On Mon, Mar 4, 2013 at 4:39 PM, Stephen Warren
>>>>> <swarren@wwwdotorg.org> wrote:
>>>>>> On 03/04/2013 04:26 PM, Tom Warren wrote:
>>>>>>> Thierry,
>>>>>>>
>>>>>>> On Mon, Mar 4, 2013 at 3:41 PM, Thierry Reding
>>>>>>> <thierry.reding@avionic-design.de> wrote:
>>>>>>>> On Mon, Mar 04, 2013 at 01:46:48PM -0700, Tom Warren
>>>>>>>> wrote: [...]
>>>>>>>>> I kinda lost track of this patchset. I'd like to move
>>>>>>>>> it into u-boot-tegra/next if you think it's ready, but
>>>>>>>>> I'm not sure if it conflicts with/works with Stephen's
>>>>>>>>> 4th patch of his v2 series ("ARM: tegra: enable a
>>>>>>>>> common set of disk-related commands").
>>>>>>>>
>>>>>>>> I can rebase my patches on top of Stephen's work and
>>>>>>>> resend them if it helps.
>>>>>>>>
>>>>>>>> Thierry
>>>>>>> The only problem I see is that Stephen's patchset isn't
>>>>>>> exclusively Tegra-based, so I'm not sure I want to bring
>>>>>>> it into the Tegra tree and cause problems when I do a PR.
>>>>>>> The other half of the patchset is assigned to Tom Rini.
>>>>>>>
>>>>>>> Stephen - how would you like me to resolve this?
>>>>>>
>>>>>> Hmmm. Thierry's patch series does quite a few things at
>>>>>> once.
>>>>>>
>>>>>> I'd suggest that Thierry posts a series that /just/ enables
>>>>>> NAND support. It should be possible to apply that on its own
>>>>>> without any conflicts/dependencies on my series.
>>>>>>
>>>>>> Enabling FIT could also be a separate series without any
>>>>>> conflicts/dependencies.
>>>>>>
>>>>>> A lot of the rest of that series is effectively part of my
>>>>>> series, since I ended up enabling all those new options in
>>>>>> the various common Tegra config files in my series.
>>>>>>
>>>>>> The only thing left over is the removal of the custom
>>>>>> definition of CONFIG_BOOTCOMMAND in the AD headers. That
>>>>>> should happen after my series.
>>>>>>
>>>>>> Re: How to get my series into Tegra's tree. I think it'd be
>>>>>> fine to apply my series to the Tegra tree even though it
>>>>>> touches disk/partition code if you can get the/a maintainer
>>>>>> for that code to ack it. Probably someone like Tom Rini. That
>>>>>> way, Thierry's CONFIG_BOOTCOMMAND changes wouldn't have to
>>>>>> wait long I hope.
>>>>> Sorry, kinda dropped the ball on this while I was working on
>>>>> the padcfg changes.
>>>>>
>>>>> Tom Rini - do you agree with Stephen's approach for the disk
>>>>> parts of his patchset? If so, I can apply it to
>>>>> u-boot-tegra/next today & push.
>>>>
>>>> Can you give me some patchwork links?  I'm getting going on
>>>> another round of pulling things into master today.  Thanks!
>>>
>>> Sure:
>>>
>>> http://patchwork.ozlabs.org/patch/224204/
>>> http://patchwork.ozlabs.org/patch/224205/
>>> http://patchwork.ozlabs.org/patch/224206/
>>> http://patchwork.ozlabs.org/patch/224207/
>>>
>>> 204/205 are assigned to you; 206/207 to me.
>>
>> OK, ack'd, lets move them along the tegra tree since that's where
>> they're really used.
>>
>> - --
>> Tom
> Will do - thanks.
I've applied Stephen's patchset to u-boot-tegra/next (on top of my
padcfg/ctrl patchset and the T30 MMC patchset).  PTAL and either send
me new discrete patches as Stephen outlined, or let me know how to
apply your patchset individually w/current /next TOT.

Thanks,

Tom

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Thierry Reding]

Move the nand-controller node to the tegra20-tamonten.dtsi so that it
can be shared between all derived boards.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
---
 board/avionic-design/dts/tegra20-tamonten.dtsi | 11 +++++++++++
 board/avionic-design/dts/tegra20-tec.dts       | 11 -----------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/board/avionic-design/dts/tegra20-tamonten.dtsi b/board/avionic-design/dts/tegra20-tamonten.dtsi
index 86c7bab..f379622 100644
--- a/board/avionic-design/dts/tegra20-tamonten.dtsi
+++ b/board/avionic-design/dts/tegra20-tamonten.dtsi
@@ -279,6 +279,17 @@
 		status = "okay";
 	};
 
+	nand-controller at 70008000 {
+		nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
+		nvidia,width = <8>;
+		nvidia,timing = <26 100 20 80 20 10 12 10 70>;
+
+		nand at 0 {
+			reg = <0>;
+			compatible = "hynix,hy27uf4g2b", "nand-flash";
+		};
+	};
+
 	i2c at 7000c000 {
 		clock-frequency = <400000>;
 		status = "okay";
diff --git a/board/avionic-design/dts/tegra20-tec.dts b/board/avionic-design/dts/tegra20-tec.dts
index 1d7cf89..4c1b08d 100644
--- a/board/avionic-design/dts/tegra20-tec.dts
+++ b/board/avionic-design/dts/tegra20-tec.dts
@@ -32,17 +32,6 @@
 		clock-frequency = <216000000>;
 	};
 
-	nand-controller at 70008000 {
-		nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */
-		nvidia,width = <8>;
-		nvidia,timing = <26 100 20 80 20 10 12 10 70>;
-
-		nand at 0 {
-			reg = <0>;
-			compatible = "hynix,hy27uf4g2b", "nand-flash";
-		};
-	};
-
 	i2c at 7000c000 {
 		status = "disabled";
 	};
-- 
1.8.2

[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND

[Stephen Warren]

On 04/03/2013 08:52 AM, Thierry Reding wrote:
> Move the nand-controller node to the tegra20-tamonten.dtsi so that it
> can be shared between all derived boards.

The series,
Reviewed-by: Stephen Warren <swarren@nvidia.com>