Patchwork [U-Boot,7/7] tegra: seaboard: disable SPI, move environment to eMMC

login
register
mail settings
Submitter Stephen Warren
Date May 24, 2012, 9:38 p.m.
Message ID <1337895519-13502-7-git-send-email-swarren@wwwdotorg.org>
Download mbox | patch
Permalink /patch/161226/
State Accepted
Delegated to: Tom Warren
Headers show

Comments

Stephen Warren - May 24, 2012, 9:38 p.m.
From: Stephen Warren <swarren@nvidia.com>

The SPI hardware on Seaboard is too broken to use; it is muxed with the
console UART and requires evil interactions between the SPI and UART
drivers to work even partially. The current code in U-Boot is not
sufficient to make this work correctly; auto boot is aborted due to
corruption in the UART RX channel interrupting it.

Instead, move the environment to eMMC, at the end of the second boot
sector. This should not conflict with any other eMMC usage, irrespective
of whether the board boots from SPI, NAND, or eMMC: if U-Boot is stored
in eMMC, it will be stored well below this location. The kernel only
uses the general area of the eMMC once booted, not the boot sectors.

Boards that are derivatives of Seaboard don't have the muxing issue,
and should/could have a separate U-Boot configuration file that does
enable SPI if desired.

Alternatively, the environment could be stored in NAND flash, but we
currently have no driver for that controller.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Cc: Simon Glass <sjg@chromium.org>
---
 include/configs/seaboard.h |   29 ++++-------------------------
 1 files changed, 4 insertions(+), 25 deletions(-)
Simon Glass - May 31, 2012, 11:39 p.m.
Hi Stephen,

On Thu, May 24, 2012 at 2:38 PM, Stephen Warren <swarren@wwwdotorg.org>wrote:

> From: Stephen Warren <swarren@nvidia.com>
>

Acked-by: Simon Glass <sjg@chromium.org>

But a question - what happens if we have a partition table and filesystems
on the eMMC - i.e. if we are not actually booting from eMMC?


>
> The SPI hardware on Seaboard is too broken to use; it is muxed with the
> console UART and requires evil interactions between the SPI and UART
> drivers to work even partially. The current code in U-Boot is not
> sufficient to make this work correctly; auto boot is aborted due to
> corruption in the UART RX channel interrupting it.
>
> Instead, move the environment to eMMC, at the end of the second boot
> sector. This should not conflict with any other eMMC usage, irrespective
> of whether the board boots from SPI, NAND, or eMMC: if U-Boot is stored
> in eMMC, it will be stored well below this location. The kernel only
> uses the general area of the eMMC once booted, not the boot sectors.
>
> Boards that are derivatives of Seaboard don't have the muxing issue,
> and should/could have a separate U-Boot configuration file that does
> enable SPI if desired.
>
> Alternatively, the environment could be stored in NAND flash, but we
> currently have no driver for that controller.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Cc: Simon Glass <sjg@chromium.org>
> ---
>  include/configs/seaboard.h |   29 ++++-------------------------
>  1 files changed, 4 insertions(+), 25 deletions(-)
>
> diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
> index f46740e..65fea8a 100644
> --- a/include/configs/seaboard.h
> +++ b/include/configs/seaboard.h
> @@ -51,30 +51,12 @@
>
>  /* On Seaboard: GPIO_PI3 = Port I = 8, bit = 3 */
>  #define CONFIG_UART_DISABLE_GPIO       GPIO_PI3
> -/*
> - * On Seaboard, SPIFLASH is muxed with UART4. The next 5 defines are
> - * needed to work around that design error.
> - */
> -#define CONFIG_SPI_UART_SWITCH
> -#define CONFIG_SPI_CORRUPTS_UART       NV_PA_APB_UARTD_BASE
> -#define CONFIG_SPI_CORRUPTS_UART_NR    3
> -#define CONFIG_SPI_CORRUPTS_UART_DLY   2500
> -#undef CONFIG_CMDLINE_EDITING          /* avoid NUL in input buffer */
>
>  #define CONFIG_MACH_TYPE               MACH_TYPE_SEABOARD
>  #define CONFIG_SYS_BOARD_ODMDATA       0x300d8011 /* lp1, 1GB */
>
>  #define CONFIG_BOARD_EARLY_INIT_F
>
> -/* SPI */
> -#define CONFIG_TEGRA2_SPI
> -#define CONFIG_SPI_FLASH
> -#define CONFIG_SPI_FLASH_WINBOND
> -#define CONFIG_SF_DEFAULT_MODE         SPI_MODE_0
> -#define CONFIG_CMD_SPI
> -#define CONFIG_CMD_SF
> -#define CONFIG_SPI_FLASH_SIZE          (4 << 20)
> -
>  /* I2C */
>  #define CONFIG_TEGRA_I2C
>  #define CONFIG_SYS_I2C_INIT_BOARD
> @@ -94,13 +76,10 @@
>  #define CONFIG_CMD_EXT2
>  #define CONFIG_CMD_FAT
>
> -/* Environment in SPI */
> -#define CONFIG_ENV_IS_IN_SPI_FLASH
> -#define CONFIG_ENV_SPI_MAX_HZ          48000000
> -#define CONFIG_ENV_SPI_MODE            SPI_MODE_0
> -
> -#define CONFIG_ENV_SECT_SIZE    CONFIG_ENV_SIZE
> -#define CONFIG_ENV_OFFSET       (CONFIG_SPI_FLASH_SIZE -
> CONFIG_ENV_SECT_SIZE)
> +/* Environment in eMMC, at the end of 2nd "boot sector" */
> +#define CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_ENV_OFFSET ((2 * 512 * 1024) - CONFIG_ENV_SIZE)
> +#define CONFIG_SYS_MMC_ENV_DEV 0
>
>  /* USB Host support */
>  #define CONFIG_USB_EHCI
> --
> 1.7.0.4
>
> Regards,
Simon
Stephen Warren - June 1, 2012, midnight
On 05/31/2012 05:39 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Thu, May 24, 2012 at 2:38 PM, Stephen Warren <swarren@wwwdotorg.org
> <mailto:swarren@wwwdotorg.org>> wrote:
> 
>     From: Stephen Warren <swarren@nvidia.com <mailto:swarren@nvidia.com>>
> 
> 
> Acked-by: Simon Glass <sjg@chromium.org <mailto:sjg@chromium.org>>
> 
> But a question - what happens if we have a partition table and
> filesystems on the eMMC - i.e. if we are not actually booting from eMMC?

The eMMC is divided into:

* Boot block 0, 512K
* Boot block 1, 512K
* Main area, the rest

This patch stores the environment at the end of boot block 1.

The Linux kernel sees each of those 3 areas as separate block devices
(and indeed the 2 boot blocks are read-only by default and require sysfs
writes to enable writing). As such, any partition table etc. would be
confined to the main area. So, there should be no conflict between PT/FS
and saved environment.

SD cards don't have these separate areas, and it may even be optional on
eMMC. Still, the Seaboard/Springbank eMMC has these separate blocks.
Simon Glass - June 1, 2012, 1:06 a.m.
Hi Stephen,

On Thu, May 31, 2012 at 5:00 PM, Stephen Warren <swarren@wwwdotorg.org>wrote:

> On 05/31/2012 05:39 PM, Simon Glass wrote:
> > Hi Stephen,
> >
> > On Thu, May 24, 2012 at 2:38 PM, Stephen Warren <swarren@wwwdotorg.org
> > <mailto:swarren@wwwdotorg.org>> wrote:
> >
> >     From: Stephen Warren <swarren@nvidia.com <mailto:swarren@nvidia.com
> >>
> >
> >
> > Acked-by: Simon Glass <sjg@chromium.org <mailto:sjg@chromium.org>>
> >
> > But a question - what happens if we have a partition table and
> > filesystems on the eMMC - i.e. if we are not actually booting from eMMC?
>
> The eMMC is divided into:
>
> * Boot block 0, 512K
> * Boot block 1, 512K
> * Main area, the rest
>
> This patch stores the environment at the end of boot block 1.
>

OK, I suppose this depends on the device, but these are the devices that
are soldered down on these boards. Bear in mind we might use the fdt to
select between board variants, but ok.


>
> The Linux kernel sees each of those 3 areas as separate block devices
> (and indeed the 2 boot blocks are read-only by default and require sysfs
> writes to enable writing). As such, any partition table etc. would be
> confined to the main area. So, there should be no conflict between PT/FS
> and saved environment.
>
> SD cards don't have these separate areas, and it may even be optional on
> eMMC. Still, the Seaboard/Springbank eMMC has these separate blocks.
>

Thanks for the explanation, that sounds fine.

Regards,
Simon

Patch

diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
index f46740e..65fea8a 100644
--- a/include/configs/seaboard.h
+++ b/include/configs/seaboard.h
@@ -51,30 +51,12 @@ 
 
 /* On Seaboard: GPIO_PI3 = Port I = 8, bit = 3 */
 #define CONFIG_UART_DISABLE_GPIO	GPIO_PI3
-/*
- * On Seaboard, SPIFLASH is muxed with UART4. The next 5 defines are
- * needed to work around that design error.
- */
-#define CONFIG_SPI_UART_SWITCH
-#define CONFIG_SPI_CORRUPTS_UART	NV_PA_APB_UARTD_BASE
-#define CONFIG_SPI_CORRUPTS_UART_NR	3
-#define CONFIG_SPI_CORRUPTS_UART_DLY	2500
-#undef CONFIG_CMDLINE_EDITING		/* avoid NUL in input buffer */
 
 #define CONFIG_MACH_TYPE		MACH_TYPE_SEABOARD
 #define CONFIG_SYS_BOARD_ODMDATA	0x300d8011 /* lp1, 1GB */
 
 #define CONFIG_BOARD_EARLY_INIT_F
 
-/* SPI */
-#define CONFIG_TEGRA2_SPI
-#define CONFIG_SPI_FLASH
-#define CONFIG_SPI_FLASH_WINBOND
-#define CONFIG_SF_DEFAULT_MODE		SPI_MODE_0
-#define CONFIG_CMD_SPI
-#define CONFIG_CMD_SF
-#define CONFIG_SPI_FLASH_SIZE		(4 << 20)
-
 /* I2C */
 #define CONFIG_TEGRA_I2C
 #define CONFIG_SYS_I2C_INIT_BOARD
@@ -94,13 +76,10 @@ 
 #define CONFIG_CMD_EXT2
 #define CONFIG_CMD_FAT
 
-/* Environment in SPI */
-#define CONFIG_ENV_IS_IN_SPI_FLASH
-#define CONFIG_ENV_SPI_MAX_HZ		48000000
-#define CONFIG_ENV_SPI_MODE		SPI_MODE_0
-
-#define CONFIG_ENV_SECT_SIZE    CONFIG_ENV_SIZE
-#define CONFIG_ENV_OFFSET       (CONFIG_SPI_FLASH_SIZE - CONFIG_ENV_SECT_SIZE)
+/* Environment in eMMC, at the end of 2nd "boot sector" */
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_ENV_OFFSET ((2 * 512 * 1024) - CONFIG_ENV_SIZE)
+#define CONFIG_SYS_MMC_ENV_DEV 0
 
 /* USB Host support */
 #define CONFIG_USB_EHCI