[U-Boot] [PATCH 1/4] Tegra: All Tamonten-derived boards use onboard NAND
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@70008000 { + nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */ + nvidia,width = <8>; + nvidia,timing = <26 100 20 80 20 10 12 10 70>; + + nand@0 { + reg = <0>; + compatible = "hynix,hy27uf4g2b", "nand-flash"; + }; + }; + i2c@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@70008000 { - nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */ - nvidia,width = <8>; - nvidia,timing = <26 100 20 80 20 10 12 10 70>; - - nand@0 { - reg = <0>; - compatible = "hynix,hy27uf4g2b", "nand-flash"; - }; - }; - i2c@7000c000 { status = "disabled"; };
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 */
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.
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
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 */
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 */
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@70008000 {nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */nvidia,width = <8>;nvidia,timing = <26 100 20 80 20 10 12 10 70>;nand@0 {reg = <0>;compatible = "hynix,hy27uf4g2b", "nand-flash";};};i2c@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@70008000 {nvidia,wp-gpios = <&gpio 23 0>; /* PC7 */nvidia,width = <8>;nvidia,timing = <26 100 20 80 20 10 12 10 70>;nand@0 {reg = <0>;compatible = "hynix,hy27uf4g2b", "nand-flash";};};i2c@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
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
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
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.
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
-----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
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
-----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
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.
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
participants (4)
-
Stephen Warren -
Thierry Reding -
Tom Rini -
Tom Warren