| Message ID | 1337895519-13502-7-git-send-email-swarren@wwwdotorg.org |
|---|---|
| State | Accepted |
| Delegated to: | Tom Warren |
| Headers | show |
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
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.
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
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