[U-Boot] [PATCH 1/7] env_mmc: align buffers using ALLOC_CACHE_ALIGN_BUFFER
From: Stephen Warren swarren@nvidia.com
This allows MMC drivers to perform cache flusing on the bufffers without issue.
Signed-off-by: Stephen Warren swarren@nvidia.com Cc: Andy Fleming afleming@gmail.com --- common/env_mmc.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/env_mmc.c b/common/env_mmc.c index 0c58ae1..be2f2be 100644 --- a/common/env_mmc.c +++ b/common/env_mmc.c @@ -95,7 +95,7 @@ static inline int write_env(struct mmc *mmc, unsigned long size,
int saveenv(void) { - env_t env_new; + ALLOC_CACHE_ALIGN_BUFFER(env_t, env_new, 1); ssize_t len; char *res; struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV); @@ -104,16 +104,16 @@ int saveenv(void) if (init_mmc_for_env(mmc) || mmc_get_env_addr(mmc, &offset)) return 1;
- res = (char *)&env_new.data; + res = (char *)&env_new->data; len = hexport_r(&env_htab, '\0', &res, ENV_SIZE, 0, NULL); if (len < 0) { error("Cannot export environment: errno = %d\n", errno); return 1; }
- env_new.crc = crc32(0, env_new.data, ENV_SIZE); + env_new->crc = crc32(0, &env_new->data[0], ENV_SIZE); printf("Writing to MMC(%d)... ", CONFIG_SYS_MMC_ENV_DEV); - if (write_env(mmc, CONFIG_ENV_SIZE, offset, (u_char *)&env_new)) { + if (write_env(mmc, CONFIG_ENV_SIZE, offset, (u_char *)env_new)) { puts("failed\n"); return 1; } @@ -140,7 +140,7 @@ static inline int read_env(struct mmc *mmc, unsigned long size, void env_relocate_spec(void) { #if !defined(ENV_IS_EMBEDDED) - char buf[CONFIG_ENV_SIZE]; + ALLOC_CACHE_ALIGN_BUFFER(char, buf, CONFIG_ENV_SIZE); struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV); u32 offset;
From: Stephen Warren swarren@nvidia.com
This chip is present on the Compulab TrimSlice.
Signed-off-by: Stephen Warren swarren@nvidia.com --- drivers/mtd/spi/winbond.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c index a6a6653..c20faa2 100644 --- a/drivers/mtd/spi/winbond.c +++ b/drivers/mtd/spi/winbond.c @@ -68,6 +68,14 @@ static const struct winbond_spi_flash_params winbond_spi_flash_table[] = { .name = "W25X64", }, { + .id = 0x4014, + .l2_page_size = 8, + .pages_per_sector = 16, + .sectors_per_block = 16, + .nr_blocks = 16, + .name = "W25Q80BL", + }, + { .id = 0x4015, .l2_page_size = 8, .pages_per_sector = 16,
On Thursday 24 May 2012 17:38:34 Stephen Warren wrote:
From: Stephen Warren swarren@nvidia.com
This chip is present on the Compulab TrimSlice.
Signed-off-by: Stephen Warren swarren@nvidia.com
thanks, merged into my sf branch -mike
From: Stephen Warren swarren@nvidia.com
Store the environment in eMMC, at the end of the second boot sector. This should not conflict with any other eMMC usage: U-Boot is stored well below this location, and the kernel only uses the general area of the eMMC once booted, not the boot sectors.
Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/ventana.h | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/configs/ventana.h b/include/configs/ventana.h index 2c7355b..665076d 100644 --- a/include/configs/ventana.h +++ b/include/configs/ventana.h @@ -57,8 +57,10 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT
-/* Environment not stored */ -#define CONFIG_ENV_IS_NOWHERE +/* Environment in eMMC, at the end of 2nd "boot sector" */ +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_ENV_OFFSET ((2 * 1024 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_SYS_MMC_ENV_DEV 0
/* USB Host support */ #define CONFIG_USB_EHCI
From: Stephen Warren swarren@nvidia.com
Store the environment in eMMC, at the end of the second boot sector. This should not conflict with any other eMMC usage: U-Boot is stored well below this location, and the kernel only uses the general area of the eMMC once booted, not the boot sectors.
Note: This assumes the user plugged the standard 8MB MoviNAND card into J29/HSMMC/POP. If they didn't, the boot sector layout may be different. However, use of that particular card is standard practice as far as I know.
Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/whistler.h | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/configs/whistler.h b/include/configs/whistler.h index 51f806a..ec96cff 100644 --- a/include/configs/whistler.h +++ b/include/configs/whistler.h @@ -66,8 +66,15 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT
-/* Environment not stored */ -#define CONFIG_ENV_IS_NOWHERE +/* + * Environment in eMMC, at the end of 2nd "boot sector". Note: This assumes + * the user plugged the standard 8MB MoviNAND card into J29/HSMMC/POP. If + * they didn't, the boot sector layout may be different. However, use of that + * particular card is standard practice as far as I know. + */ +#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
From: Stephen Warren swarren@nvidia.com
The chosen flash offset matches Compulab's downstream U-Boot.
Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/trimslice.h | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/include/configs/trimslice.h b/include/configs/trimslice.h index 21b9ef2..dec9125 100644 --- a/include/configs/trimslice.h +++ b/include/configs/trimslice.h @@ -47,6 +47,14 @@
#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 + /* I2C */ #define CONFIG_TEGRA_I2C #define CONFIG_SYS_I2C_INIT_BOARD @@ -66,8 +74,12 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT
-/* Environment not stored */ -#define CONFIG_ENV_IS_NOWHERE +/* 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 (512 * 1024)
/* USB Host support */ #define CONFIG_USB_EHCI
From: Stephen Warren swarren@nvidia.com
Store the environment in eMMC, at the end of the second boot sector. This should not conflict with any other eMMC usage: U-Boot is stored well below this location, and the kernel only uses the general area of the eMMC once booted, not the boot sectors.
Signed-off-by: Stephen Warren swarren@nvidia.com --- include/configs/paz00.h | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/configs/paz00.h b/include/configs/paz00.h index 3edd102..0390530 100644 --- a/include/configs/paz00.h +++ b/include/configs/paz00.h @@ -50,8 +50,10 @@ #define CONFIG_CMD_EXT2 #define CONFIG_CMD_FAT
-/* Environment not stored */ -#define CONFIG_ENV_IS_NOWHERE +/* Environment in eMMC, at the end of 2nd "boot sector" */ +#define CONFIG_ENV_IS_IN_MMC +#define CONFIG_ENV_OFFSET ((2 * 1024 * 1024) - CONFIG_ENV_SIZE) +#define CONFIG_SYS_MMC_ENV_DEV 0
/* USB Host support */ #define CONFIG_USB_EHCI
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(-)
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
Hi Stephen,
On Thu, May 24, 2012 at 2:38 PM, Stephen Warren swarren@wwwdotorg.orgwrote:
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.orgwrote:
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.comAcked-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
participants (3)
-
Mike Frysinger -
Simon Glass -
Stephen Warren