[U-Boot] [PATCH v5 0/5] enable support for x16 NAND devices
*changes v4 -> v5* [PATCH 1/5] <no change> [PATCH 2/5] fixed compilation error for OMAP3 platforms [PATCH 3/5] <no change> [PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width [PATCH 5/5] additional cleanup in include/configs/cm_t35.h Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
*changes v3 -> v4* [PATCH 1/5] <no update> [PATCH 2/5] <new> mtd: nand: force NAND_CMD_READID onto 8-bit bus [PATCH 3/5] <new> mtd: nand: fix GET/SET_FEATURES address on 16-bit devices [PATCH 4/5] same as [PATCH v2 2/3] rebased over http://lists.denx.de/pipermail/u-boot/2014-April/177323.html [PATCH 5/5] <no update>
*changes v2 -> v3* [PATCH v3 1/3] (new) porting Brian Norri's patch from linux tree This patch allows reading of ONFI params independent of controller configuration and NAND device width. [PATCH v3 2/2] rebase [PATCH v2 2/4] on latest release [PATCH v3 3/3] (new) cleaned remaining GPMC_NAND_ECC_LP_xx macros from OMAP3 platform Compile Tested#> ./MAKEALL -s omap3 -s omap4 -s omap5 -s dra7xx -s am33xx
*changes v1 -> v2* [PATCH v2 1/4]: - dropped NAND_BUSWIDTH_AUTO, instead using CONFIG_SYS_NAND_ONFI_DETECTION - added check in nand_flash_detect_onfi() for x8 mode [PATCH v2 2/4]: (new) Adds CONFIG_SYS_NAND_DEVICE_WIDTH - updated for auto-detection of bus-width in non-SPL and ONFI_DETECTION mode Refer: http://lists.denx.de/pipermail/u-boot/2013-September/163748.html [PATCH v2 3/4] <no update> [PATCH v2 4/4] disabled Pulls on output only I/O pads. - updated commit description to add details about NAND cape
*original v1* This series includes independent patch-sets aiming to enable x16 NAND support on AM33xx boards (like beaglebone-LT). [PATCH 1/4]: This patch is ported from linux driver/mtd/nand to allow detection device-width of NAND by reading ONFI parameter page. [PATCH 2/4]: enable NAND_BUSWIDTH_AUTO feature in omap_nand.c [PATCH 3/4]: cleaning of GPMC configs for NAND and NOR
Brian Norris (2): mtd: nand: don't use read_buf for 8-bit ONFI transfers mtd: nand: force NAND_CMD_READID onto 8-bit bus
David Mosberger (1): mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
Pekon Gupta (2): mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT
arch/arm/cpu/armv7/omap3/mem.c | 12 ------------ arch/arm/include/asm/arch-omap3/mem.h | 8 -------- board/compulab/cm_t35/cm_t35.c | 12 ++++++------ doc/README.nand | 18 ++++++++++++++++++ drivers/mtd/nand/am335x_spl_bch.c | 2 +- drivers/mtd/nand/atmel_nand.c | 2 +- drivers/mtd/nand/nand_base.c | 11 +++++++---- drivers/mtd/nand/nand_spl_simple.c | 2 +- drivers/mtd/nand/omap_gpmc.c | 13 +++++++++---- include/configs/am3517_crane.h | 1 + include/configs/cm_t335.h | 1 - include/configs/cm_t35.h | 1 - include/configs/devkit8000.h | 1 + include/configs/dig297.h | 1 + include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm_common.h | 2 +- include/configs/omap3_igep00x0.h | 1 + include/configs/omap3_logic.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/omap3_zoom1.h | 1 + include/configs/pengwyn.h | 1 - include/configs/tam3517-common.h | 1 + include/configs/tao3530.h | 2 +- include/configs/tseries.h | 1 - include/linux/mtd/nand.h | 19 +++++++++++++++++++ 25 files changed, 73 insertions(+), 43 deletions(-)
From: Brian Norris computersforpeace@gmail.com
Porting below commit from linux-tree, preserving original authorship & commit log commit bd9c6e99b58255b9de1982711ac9487c9a2f18be Author: Brian Norris computersforpeace@gmail.com mtd: nand: don't use read_buf for 8-bit ONFI transfers
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth devices, we need to avoid the upper I/O[16:9] bits. See the following commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875 (from linux-tree) Author: Uwe Kleine-König u.kleine-koenig@pengutronix.de Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfers
Now, I think that all barriers to probing ONFI on x16 devices are removed, so remove the check from nand_flash_detect_onfi().
Signed-off-by: Pekon Gupta pekon@ti.com --- drivers/mtd/nand/nand_base.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 1ce55fd..5d3232c 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2582,7 +2582,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip, int *busw) { struct nand_onfi_params *p = &chip->onfi_params; - int i; + int i, j; int val;
/* Try ONFI for unknown chip or LP */ @@ -2593,7 +2593,8 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1); for (i = 0; i < 3; i++) { - chip->read_buf(mtd, (uint8_t *)p, sizeof(*p)); + for (j = 0; j < sizeof(*p); j++) + ((uint8_t *)p)[j] = chip->read_byte(mtd); if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) == le16_to_cpu(p->crc)) { pr_info("ONFI param page %d valid\n", i);
On Tue, May 06, 2014 at 12:46:16AM +0530, pekon gupta wrote:
From: Brian Norris computersforpeace@gmail.com
Porting below commit from linux-tree, preserving original authorship & commit log commit bd9c6e99b58255b9de1982711ac9487c9a2f18be Author: Brian Norris computersforpeace@gmail.com mtd: nand: don't use read_buf for 8-bit ONFI transfers
Use a repeated read_byte() instead of read_buf(), since for x16 buswidth devices, we need to avoid the upper I/O[16:9] bits. See the following commit for reference:
commit 05f7835975dad6b3b517f9e23415985e648fb875 (from linux-tree) Author: Uwe Kleine-König u.kleine-koenig@pengutronix.de Date: Thu Dec 5 22:22:04 2013 +0100
mtd: nand: don't use {read,write}_buf for 8-bit transfersNow, I think that all barriers to probing ONFI on x16 devices are removed, so remove the check from nand_flash_detect_onfi().
Signed-off-by: Pekon Gupta pekon@ti.com
Applied to u-boot-ti/master, thanks!
From: Brian Norris computersforpeace@gmail.com
As per following Sections in ONFI Spec, NAND_CMD_READID should use only lower 8-bit for transfering command, address and data even on x16 NAND device.
*Section: Target Initialization" "The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus. The host shall not issue commands that use a word data width on x16 devices until the host determines the device supports a 16-bit data bus width in the parameter page."
*Section: Bus Width Requirements* "When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h."
Thus porting following commit from linux-kernel to ensure that column address is not altered to align to x16 bus when issuing NAND_CMD_READID command.
commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7 mtd: nand: force NAND_CMD_READID onto 8-bit bus Author: Brian Norris computersforpeace@gmail.com (preserving authorship)
The NAND command helpers tend to automatically shift the column address for x16 bus devices, since most commands expect a word address, not a byte address. The Read ID command, however, expects an 8-bit address (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or 0x20).
This fixes the column address for a few drivers which imitate the nand_base defaults.
Signed-off-by: Pekon Gupta pekon@ti.com --- drivers/mtd/nand/am335x_spl_bch.c | 2 +- drivers/mtd/nand/atmel_nand.c | 2 +- drivers/mtd/nand/nand_base.c | 6 ++++-- drivers/mtd/nand/nand_spl_simple.c | 2 +- include/linux/mtd/nand.h | 10 ++++++++++ 5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/am335x_spl_bch.c b/drivers/mtd/nand/am335x_spl_bch.c index c84851b..86572a2 100644 --- a/drivers/mtd/nand/am335x_spl_bch.c +++ b/drivers/mtd/nand/am335x_spl_bch.c @@ -55,7 +55,7 @@ static int nand_command(int block, int page, uint32_t offs, }
/* Shift the offset from byte addressing to word addressing. */ - if (this->options & NAND_BUSWIDTH_16) + if ((this->options & NAND_BUSWIDTH_16) && !nand_opcode_8bits(cmd)) offs >>= 1;
/* Set ALE and clear CLE to start address cycle */ diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index e1fc48f..e73834d 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -1195,7 +1195,7 @@ static int nand_command(int block, int page, uint32_t offs, u8 cmd)
hwctrl(&mtd, cmd, NAND_CTRL_CLE | NAND_CTRL_CHANGE);
- if (this->options & NAND_BUSWIDTH_16) + if ((this->options & NAND_BUSWIDTH_16) && !nand_opcode_8bits(cmd)) offs >>= 1;
hwctrl(&mtd, offs & 0xff, NAND_CTRL_ALE | NAND_CTRL_CHANGE); diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 5d3232c..376976d 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -575,7 +575,8 @@ static void nand_command(struct mtd_info *mtd, unsigned int command, /* Serially input address */ if (column != -1) { /* Adjust columns for 16 bit buswidth */ - if (chip->options & NAND_BUSWIDTH_16) + if ((chip->options & NAND_BUSWIDTH_16) && + !nand_opcode_8bits(command)) column >>= 1; chip->cmd_ctrl(mtd, column, ctrl); ctrl &= ~NAND_CTRL_CHANGE; @@ -668,7 +669,8 @@ static void nand_command_lp(struct mtd_info *mtd, unsigned int command, /* Serially input address */ if (column != -1) { /* Adjust columns for 16 bit buswidth */ - if (chip->options & NAND_BUSWIDTH_16) + if ((chip->options & NAND_BUSWIDTH_16) && + !nand_opcode_8bits(command)) column >>= 1; chip->cmd_ctrl(mtd, column, ctrl); ctrl &= ~NAND_CTRL_CHANGE; diff --git a/drivers/mtd/nand/nand_spl_simple.c b/drivers/mtd/nand/nand_spl_simple.c index cead4b5..700ca32 100644 --- a/drivers/mtd/nand/nand_spl_simple.c +++ b/drivers/mtd/nand/nand_spl_simple.c @@ -78,7 +78,7 @@ static int nand_command(int block, int page, uint32_t offs, }
/* Shift the offset from byte addressing to word addressing. */ - if (this->options & NAND_BUSWIDTH_16) + if ((this->options & NAND_BUSWIDTH_16) && !nand_opcode_8bits(cmd)) offs >>= 1;
/* Begin command latch cycle */ diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 0546565..4be8858 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -719,4 +719,14 @@ static inline int onfi_get_sync_timing_mode(struct nand_chip *chip) } #endif
+/** + * Check if the opcode's address should be sent only on the lower 8 bits + * @command: opcode to check + */ +static inline int nand_opcode_8bits(unsigned int command) +{ + return command == NAND_CMD_READID; +} + + #endif /* __LINUX_MTD_NAND_H */
On Tue, May 06, 2014 at 12:46:17AM +0530, pekon gupta wrote:
From: Brian Norris computersforpeace@gmail.com
As per following Sections in ONFI Spec, NAND_CMD_READID should use only lower 8-bit for transfering command, address and data even on x16 NAND device.
*Section: Target Initialization" "The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus. The host shall not issue commands that use a word data width on x16 devices until the host determines the device supports a 16-bit data bus width in the parameter page."
*Section: Bus Width Requirements* "When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h."
Thus porting following commit from linux-kernel to ensure that column address is not altered to align to x16 bus when issuing NAND_CMD_READID command.
commit 3dad2344e92c6e1aeae42df1c4824f307c51bcc7 mtd: nand: force NAND_CMD_READID onto 8-bit bus Author: Brian Norris <computersforpeace@gmail.com> (preserving authorship) The NAND command helpers tend to automatically shift the column address for x16 bus devices, since most commands expect a word address, not a byte address. The Read ID command, however, expects an 8-bit address (i.e., 0x00, 0x20, or 0x40 should not be translated to 0x00, 0x10, or 0x20). This fixes the column address for a few drivers which imitate the nand_base defaults.Signed-off-by: Pekon Gupta pekon@ti.com
Applied to u-boot-ti/master, thanks!
From: David Mosberger davidm@egauge.net
As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need byte-addressing on 16-bit devices.
*Section: Target Initialization" "The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus. The host shall not issue commands that use a word data width on x16 devices until the host determines the device supports a 16-bit data bus width in the parameter page."
*Section: Bus Width Requirements* "When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h."
So porting following commit from linux kernel commit e34fcb07a6d57411de6e15a47724fbe92c5caa42 Author: David Mosberger davidm@egauge.net (preserving authorship) mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
Signed-off-by: Pekon Gupta pekon@ti.com --- include/linux/mtd/nand.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h index 4be8858..991bd8e 100644 --- a/include/linux/mtd/nand.h +++ b/include/linux/mtd/nand.h @@ -725,7 +725,16 @@ static inline int onfi_get_sync_timing_mode(struct nand_chip *chip) */ static inline int nand_opcode_8bits(unsigned int command) { - return command == NAND_CMD_READID; + switch (command) { + case NAND_CMD_READID: + case NAND_CMD_PARAM: + case NAND_CMD_GET_FEATURES: + case NAND_CMD_SET_FEATURES: + return 1; + default: + break; + } + return 0; }
On Tue, May 06, 2014 at 12:46:18AM +0530, pekon gupta wrote:
From: David Mosberger davidm@egauge.net
As per following Sections in ONFI Spec, GET_FEATURES and SET_FEATURES also need byte-addressing on 16-bit devices.
*Section: Target Initialization" "The Read ID and Read Parameter Page commands only use the lower 8-bits of the data bus. The host shall not issue commands that use a word data width on x16 devices until the host determines the device supports a 16-bit data bus width in the parameter page."
*Section: Bus Width Requirements* "When the host supports a 16-bit bus width, only data is transferred at the 16-bit width. All address and command line transfers shall use only the lower 8-bits of the data bus. During command transfers, the host may place any value on the upper 8-bits of the data bus. During address transfers, the host shall set the upper 8-bits of the data bus to 00h."
So porting following commit from linux kernel commit e34fcb07a6d57411de6e15a47724fbe92c5caa42 Author: David Mosberger davidm@egauge.net (preserving authorship) mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
Signed-off-by: Pekon Gupta pekon@ti.com
Applied to u-boot-ti/master, thanks!
GPMC controller needs to be configured based on bus-width of the NAND device connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI parameters is not possible in following situations: SPL: SPL NAND drivers does not support ONFI parameter reading. U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init() which is called before probing for devices, hence any ONFI parameter information is not available during GPMC initialization.
Thus, OMAP NAND driver expected board developers to explicitely write GPMC configurations specific to NAND device attached on board in board files itself. But this was troublesome for board manufacturers as they need to dive into lengthy platform & SoC documents to find details of GPMC registers and appropriate configurations to get NAND device working.
This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config hich indicates that connected NAND device has x16 bus-width. And then based on this config GPMC driver itself initializes itself based on NAND bus-width. This keeps board developers free from knowing GPMC controller specific internals.
Signed-off-by: Pekon Gupta pekon@ti.com --- doc/README.nand | 18 ++++++++++++++++++ drivers/mtd/nand/omap_gpmc.c | 13 +++++++++---- include/configs/am3517_crane.h | 1 + include/configs/devkit8000.h | 1 + include/configs/dig297.h | 1 + include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm_common.h | 2 +- include/configs/omap3_igep00x0.h | 1 + include/configs/omap3_logic.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/omap3_zoom1.h | 1 + include/configs/tam3517-common.h | 1 + include/configs/tao3530.h | 1 + 13 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand index b91f198..2bc5b39 100644 --- a/doc/README.nand +++ b/doc/README.nand @@ -190,6 +190,24 @@ Configuration Options: This is used by SoC platforms which do not have built-in ELM hardware engine required for BCH ECC correction.
+ CONFIG_SYS_NAND_BUSWIDTH_16BIT + Indicates that NAND device has 16-bit wide data-bus. In absence of this + config, bus-width of NAND device is assumed to be either 8-bit and later + determined by reading ONFI params. + Above config is useful when NAND device's bus-width information cannot + be determined from on-chip ONFI params, like in following scenarios: + - SPL boot does not support reading of ONFI parameters. This is done to + keep SPL code foot-print small. + - In current U-Boot flow using nand_init(), driver initialization + happens in board_nand_init() which is called before any device probe + (nand_scan_ident + nand_scan_tail), thus device's ONFI parameters are + not available while configuring controller. So a static CONFIG_NAND_xx + is needed to know the device's bus-width in advance. + Some drivers using above config are: + drivers/mtd/nand/mxc_nand.c + drivers/mtd/nand/ndfc.c + drivers/mtd/nand/omap_gpmc.c +
Platform specific options ========================= diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c index 325ebfd..89f8c0a 100644 --- a/drivers/mtd/nand/omap_gpmc.c +++ b/drivers/mtd/nand/omap_gpmc.c @@ -782,13 +782,18 @@ int board_nand_init(struct nand_chip *nand) nand->priv = &omap_nand_info; nand->cmd_ctrl = omap_nand_hwcontrol; nand->options |= NAND_NO_PADDING | NAND_CACHEPRG; - /* If we are 16 bit dev, our gpmc config tells us that */ - if ((readl(&gpmc_cfg->cs[cs].config1) & 0x3000) == 0x1000) - nand->options |= NAND_BUSWIDTH_16; - nand->chip_delay = 100; nand->ecc.layout = &omap_ecclayout;
+ /* configure driver and controller based on NAND device bus-width */ + gpmc_config = readl(&gpmc_cfg->cs[cs].config1); +#if defined(CONFIG_SYS_NAND_BUSWIDTH_16BIT) + nand->options |= NAND_BUSWIDTH_16; + writel(gpmc_config | (0x1 << 12), &gpmc_cfg->cs[cs].config1); +#else + nand->options &= ~NAND_BUSWIDTH_16; + writel(gpmc_config & ~(0x1 << 12), &gpmc_cfg->cs[cs].config1); +#endif /* select ECC scheme */ #if defined(CONFIG_NAND_OMAP_ECCSCHEME) err = omap_select_ecc_scheme(nand, CONFIG_NAND_OMAP_ECCSCHEME, diff --git a/include/configs/am3517_crane.h b/include/configs/am3517_crane.h index 4407b45..ad4cbd8 100644 --- a/include/configs/am3517_crane.h +++ b/include/configs/am3517_crane.h @@ -329,6 +329,7 @@ #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
/* NAND boot config */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h index 16a00eb..5308790 100644 --- a/include/configs/devkit8000.h +++ b/include/configs/devkit8000.h @@ -314,6 +314,7 @@ #define CONFIG_SPL_BSS_MAX_SIZE 0x80000
/* NAND boot config */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 diff --git a/include/configs/dig297.h b/include/configs/dig297.h index af6f56b..ce205e9 100644 --- a/include/configs/dig297.h +++ b/include/configs/dig297.h @@ -138,6 +138,7 @@ * Board NAND Info. */ #define CONFIG_NAND_OMAP_GPMC +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_ADDR NAND_BASE /* physical address */ /* to access nand */ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h index 0b57421..793d651 100644 --- a/include/configs/omap3_beagle.h +++ b/include/configs/omap3_beagle.h @@ -422,6 +422,7 @@ #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
/* NAND boot config */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 diff --git a/include/configs/omap3_evm_common.h b/include/configs/omap3_evm_common.h index 7f3424b..ae4ce63 100644 --- a/include/configs/omap3_evm_common.h +++ b/include/configs/omap3_evm_common.h @@ -120,7 +120,7 @@
/* Max number of NAND devices */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 - +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 /* Timeout values (in ticks) */ #define CONFIG_SYS_FLASH_ERASE_TOUT (100 * CONFIG_SYS_HZ) #define CONFIG_SYS_FLASH_WRITE_TOUT (100 * CONFIG_SYS_HZ) diff --git a/include/configs/omap3_igep00x0.h b/include/configs/omap3_igep00x0.h index d56d5b0..79daabd 100644 --- a/include/configs/omap3_igep00x0.h +++ b/include/configs/omap3_igep00x0.h @@ -187,6 +187,7 @@
/* NAND boot config */ #ifdef CONFIG_NAND +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 diff --git a/include/configs/omap3_logic.h b/include/configs/omap3_logic.h index 0d03c75..8dcbba3 100644 --- a/include/configs/omap3_logic.h +++ b/include/configs/omap3_logic.h @@ -141,6 +141,7 @@
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of */ /* NAND devices */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_JFFS2_NAND /* nand device jffs2 lives on */ #define CONFIG_JFFS2_DEV "nand0" diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h index 007e27f..661d2ec 100644 --- a/include/configs/omap3_overo.h +++ b/include/configs/omap3_overo.h @@ -312,6 +312,7 @@ #define CONFIG_SPL_LDSCRIPT "$(CPUDIR)/omap-common/u-boot-spl.lds"
/* NAND boot config */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h index f0fa96e..e4c50af 100644 --- a/include/configs/omap3_zoom1.h +++ b/include/configs/omap3_zoom1.h @@ -140,6 +140,7 @@ /* CS0 */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_JFFS2_NAND /* nand device jffs2 lives on */ #define CONFIG_JFFS2_DEV "nand0" diff --git a/include/configs/tam3517-common.h b/include/configs/tam3517-common.h index 3522c1a..eda536b 100644 --- a/include/configs/tam3517-common.h +++ b/include/configs/tam3517-common.h @@ -249,6 +249,7 @@ #define CONFIG_SPL_BSS_MAX_SIZE 0x80000
/* NAND boot config */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 #define CONFIG_SYS_NAND_PAGE_COUNT 64 #define CONFIG_SYS_NAND_PAGE_SIZE 2048 #define CONFIG_SYS_NAND_OOBSIZE 64 diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h index 9c04c23..4471935 100644 --- a/include/configs/tao3530.h +++ b/include/configs/tao3530.h @@ -141,6 +141,7 @@
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ +#define CONFIG_SYS_NAND_BUSWIDTH_16BIT 16 /* Environment information */ #define CONFIG_BOOTDELAY 3
On Tue, May 06, 2014 at 12:46:19AM +0530, pekon gupta wrote:
GPMC controller needs to be configured based on bus-width of the NAND device connected to it. Also, dynamic detection of NAND bus-width from on-chip ONFI parameters is not possible in following situations: SPL: SPL NAND drivers does not support ONFI parameter reading. U-boot: GPMC controller iniitalization is done in omap_gpmc.c:board_nand_init() which is called before probing for devices, hence any ONFI parameter information is not available during GPMC initialization.
Thus, OMAP NAND driver expected board developers to explicitely write GPMC configurations specific to NAND device attached on board in board files itself. But this was troublesome for board manufacturers as they need to dive into lengthy platform & SoC documents to find details of GPMC registers and appropriate configurations to get NAND device working.
This patch instead adds existing CONFIG_SYS_NAND_BUSWIDTH_16BIT to board config hich indicates that connected NAND device has x16 bus-width. And then based on this config GPMC driver itself initializes itself based on NAND bus-width. This keeps board developers free from knowing GPMC controller specific internals.
Signed-off-by: Pekon Gupta pekon@ti.com
Applied to u-boot-ti/master, thanks!
OMAP3 used GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT macros to configure GPMC controller for x7 or x8 bit device connected to its interface. Now this information is encoded in CONFIG_SYS_NAND_DEVICE_WIDTH macro, so above macros can be completely removed.
Signed-off-by: Pekon Gupta pekon@ti.com --- arch/arm/cpu/armv7/omap3/mem.c | 12 ------------ arch/arm/include/asm/arch-omap3/mem.h | 8 -------- board/compulab/cm_t35/cm_t35.c | 12 ++++++------ include/configs/cm_t335.h | 1 - include/configs/cm_t35.h | 1 - include/configs/pengwyn.h | 1 - include/configs/tao3530.h | 1 - include/configs/tseries.h | 1 - 8 files changed, 6 insertions(+), 31 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/mem.c b/arch/arm/cpu/armv7/omap3/mem.c index e649409..1832aff 100644 --- a/arch/arm/cpu/armv7/omap3/mem.c +++ b/arch/arm/cpu/armv7/omap3/mem.c @@ -21,17 +21,6 @@ struct gpmc *gpmc_cfg;
#if defined(CONFIG_CMD_NAND) -#if defined(GPMC_NAND_ECC_SP_x8_LAYOUT) || defined(GPMC_NAND_ECC_LP_x8_LAYOUT) -static const u32 gpmc_m_nand[GPMC_MAX_REG] = { - SMNAND_GPMC_CONFIG1, - SMNAND_GPMC_CONFIG2, - SMNAND_GPMC_CONFIG3, - SMNAND_GPMC_CONFIG4, - SMNAND_GPMC_CONFIG5, - SMNAND_GPMC_CONFIG6, - 0, -}; -#else static const u32 gpmc_m_nand[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG1, M_NAND_GPMC_CONFIG2, @@ -40,7 +29,6 @@ static const u32 gpmc_m_nand[GPMC_MAX_REG] = { M_NAND_GPMC_CONFIG5, M_NAND_GPMC_CONFIG6, 0 }; -#endif #endif /* CONFIG_CMD_NAND */
#if defined(CONFIG_CMD_ONENAND) diff --git a/arch/arm/include/asm/arch-omap3/mem.h b/arch/arm/include/asm/arch-omap3/mem.h index 1804191..d90fe16 100644 --- a/arch/arm/include/asm/arch-omap3/mem.h +++ b/arch/arm/include/asm/arch-omap3/mem.h @@ -353,14 +353,6 @@ enum {
#define GPMC_CS_ENABLE 0x1
-#define SMNAND_GPMC_CONFIG1 0x00000800 -#define SMNAND_GPMC_CONFIG2 0x00141400 -#define SMNAND_GPMC_CONFIG3 0x00141400 -#define SMNAND_GPMC_CONFIG4 0x0F010F01 -#define SMNAND_GPMC_CONFIG5 0x010C1414 -#define SMNAND_GPMC_CONFIG6 0x1F0F0A80 -#define SMNAND_GPMC_CONFIG7 0x00000C44 - #define M_NAND_GPMC_CONFIG1 0x00001800 #define M_NAND_GPMC_CONFIG2 0x00141400 #define M_NAND_GPMC_CONFIG3 0x00141400 diff --git a/board/compulab/cm_t35/cm_t35.c b/board/compulab/cm_t35/cm_t35.c index 00bcf41..0944903 100644 --- a/board/compulab/cm_t35/cm_t35.c +++ b/board/compulab/cm_t35/cm_t35.c @@ -54,12 +54,12 @@ static u32 gpmc_net_config[GPMC_MAX_REG] = { };
static u32 gpmc_nand_config[GPMC_MAX_REG] = { - SMNAND_GPMC_CONFIG1, - SMNAND_GPMC_CONFIG2, - SMNAND_GPMC_CONFIG3, - SMNAND_GPMC_CONFIG4, - SMNAND_GPMC_CONFIG5, - SMNAND_GPMC_CONFIG6, + M_NAND_GPMC_CONFIG1, + M_NAND_GPMC_CONFIG2, + M_NAND_GPMC_CONFIG3, + M_NAND_GPMC_CONFIG4, + M_NAND_GPMC_CONFIG5, + M_NAND_GPMC_CONFIG6, 0, };
diff --git a/include/configs/cm_t335.h b/include/configs/cm_t335.h index 26b615b..4d1dd28 100644 --- a/include/configs/cm_t335.h +++ b/include/configs/cm_t335.h @@ -141,7 +141,6 @@ #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x200000
#define CONFIG_CMD_NAND -#define GPMC_NAND_ECC_LP_x8_LAYOUT #define MTDIDS_DEFAULT "nand0=nand" #define MTDPARTS_DEFAULT "mtdparts=nand:2m(spl)," \ "1m(u-boot),1m(u-boot-env)," \ diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h index aae05e0..8c60e22 100644 --- a/include/configs/cm_t35.h +++ b/include/configs/cm_t35.h @@ -158,7 +158,6 @@ /* CS0 */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ -#define GPMC_NAND_ECC_LP_x8_LAYOUT
/* Environment information */ #define CONFIG_BOOTDELAY 3 diff --git a/include/configs/pengwyn.h b/include/configs/pengwyn.h index fc25966..8510405 100644 --- a/include/configs/pengwyn.h +++ b/include/configs/pengwyn.h @@ -149,7 +149,6 @@ #define CONFIG_SYS_NAND_U_BOOT_START CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_NAND_U_BOOT_OFFS 0x80000
-#define GPMC_NAND_ECC_LP_x8_LAYOUT 1 #define MTDIDS_DEFAULT "nand0=omap2-nand.0" #define MTDPARTS_DEFAULT "mtdparts=omap2-nand.0:128k(SPL)," \ "128k(SPL.backup1)," \ diff --git a/include/configs/tao3530.h b/include/configs/tao3530.h index 4471935..1b0fee9 100644 --- a/include/configs/tao3530.h +++ b/include/configs/tao3530.h @@ -137,7 +137,6 @@ #define CONFIG_SYS_NAND_BASE NAND_BASE /* physical address */ /* to access nand at */ /* CS0 */ -#define GPMC_NAND_ECC_LP_x16_LAYOUT
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND */ /* devices */ diff --git a/include/configs/tseries.h b/include/configs/tseries.h index 8fb87ac..948f88a 100644 --- a/include/configs/tseries.h +++ b/include/configs/tseries.h @@ -157,7 +157,6 @@ /* don't change OMAP_ELM, ECCSCHEME. ROM code only supports this */ #define CONFIG_NAND_OMAP_ELM #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH8_CODE_HW -#define GPMC_NAND_ECC_LP_x16_LAYOUT 1 #define CONFIG_SYS_NAND_5_ADDR_CYCLE #define CONFIG_SYS_NAND_BLOCK_SIZE (128*1024) #define CONFIG_SYS_NAND_PAGE_SIZE 2048
On Tue, May 06, 2014 at 12:46:20AM +0530, pekon gupta wrote:
OMAP3 used GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT macros to configure GPMC controller for x7 or x8 bit device connected to its interface. Now this information is encoded in CONFIG_SYS_NAND_DEVICE_WIDTH macro, so above macros can be completely removed.
Signed-off-by: Pekon Gupta pekon@ti.com
Applied to u-boot-ti/master, thanks!
Hello Scott, Tom,
From: Gupta, Pekon
*changes v4 -> v5* [PATCH 1/5] <no change> [PATCH 2/5] fixed compilation error for OMAP3 platforms [PATCH 3/5] <no change> [PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width [PATCH 5/5] additional cleanup in include/configs/cm_t35.h Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
This series few other patch series are awaiting response from long time. In particular without this series many of the platforms will _not_ work out-of-the box with x16 NAND device. Hence, please give these patches a look and accept them if all okay.
Also, another series which has simple changes and clean-up is awaiting acceptance from long. [PATCH v2 0/7] mtd: nand: omap: clean up of omap_elm and omap_gpmc driver
This all will save some effort in resolving merge conflicts and rebases, while moving forward with new patches.
with regards, pekon
*changes v3 -> v4* [PATCH 1/5] <no update> [PATCH 2/5] <new> mtd: nand: force NAND_CMD_READID onto 8-bit bus [PATCH 3/5] <new> mtd: nand: fix GET/SET_FEATURES address on 16-bit devices [PATCH 4/5] same as [PATCH v2 2/3] rebased over http://lists.denx.de/pipermail/u-boot/2014- April/177323.html [PATCH 5/5] <no update>
*changes v2 -> v3* [PATCH v3 1/3] (new) porting Brian Norri's patch from linux tree This patch allows reading of ONFI params independent of controller configuration and NAND device width. [PATCH v3 2/2] rebase [PATCH v2 2/4] on latest release [PATCH v3 3/3] (new) cleaned remaining GPMC_NAND_ECC_LP_xx macros from OMAP3 platform Compile Tested#> ./MAKEALL -s omap3 -s omap4 -s omap5 -s dra7xx -s am33xx
*changes v1 -> v2* [PATCH v2 1/4]:
- dropped NAND_BUSWIDTH_AUTO, instead using CONFIG_SYS_NAND_ONFI_DETECTION
- added check in nand_flash_detect_onfi() for x8 mode
[PATCH v2 2/4]: (new) Adds CONFIG_SYS_NAND_DEVICE_WIDTH
- updated for auto-detection of bus-width in non-SPL and ONFI_DETECTION mode
Refer: http://lists.denx.de/pipermail/u-boot/2013-September/163748.html [PATCH v2 3/4] <no update> [PATCH v2 4/4] disabled Pulls on output only I/O pads.
- updated commit description to add details about NAND cape
*original v1* This series includes independent patch-sets aiming to enable x16 NAND support on AM33xx boards (like beaglebone-LT). [PATCH 1/4]: This patch is ported from linux driver/mtd/nand to allow detection device-width of NAND by reading ONFI parameter page. [PATCH 2/4]: enable NAND_BUSWIDTH_AUTO feature in omap_nand.c [PATCH 3/4]: cleaning of GPMC configs for NAND and NOR
Brian Norris (2): mtd: nand: don't use read_buf for 8-bit ONFI transfers mtd: nand: force NAND_CMD_READID onto 8-bit bus
David Mosberger (1): mtd: nand: fix GET/SET_FEATURES address on 16-bit devices
Pekon Gupta (2): mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width omap3: remove remnant macros GPMC_NAND_ECC_LP_x8_LAYOUT and GPMC_NAND_ECC_LP_x16_LAYOUT
arch/arm/cpu/armv7/omap3/mem.c | 12 ------------ arch/arm/include/asm/arch-omap3/mem.h | 8 -------- board/compulab/cm_t35/cm_t35.c | 12 ++++++------ doc/README.nand | 18 ++++++++++++++++++ drivers/mtd/nand/am335x_spl_bch.c | 2 +- drivers/mtd/nand/atmel_nand.c | 2 +- drivers/mtd/nand/nand_base.c | 11 +++++++---- drivers/mtd/nand/nand_spl_simple.c | 2 +- drivers/mtd/nand/omap_gpmc.c | 13 +++++++++---- include/configs/am3517_crane.h | 1 + include/configs/cm_t335.h | 1 - include/configs/cm_t35.h | 1 - include/configs/devkit8000.h | 1 + include/configs/dig297.h | 1 + include/configs/omap3_beagle.h | 1 + include/configs/omap3_evm_common.h | 2 +- include/configs/omap3_igep00x0.h | 1 + include/configs/omap3_logic.h | 1 + include/configs/omap3_overo.h | 1 + include/configs/omap3_zoom1.h | 1 + include/configs/pengwyn.h | 1 - include/configs/tam3517-common.h | 1 + include/configs/tao3530.h | 2 +- include/configs/tseries.h | 1 - include/linux/mtd/nand.h | 19 +++++++++++++++++++ 25 files changed, 73 insertions(+), 43 deletions(-)
-- 1.8.5.1.163.gd7aced9
On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
Hello Scott, Tom,
From: Gupta, Pekon
*changes v4 -> v5* [PATCH 1/5] <no change> [PATCH 2/5] fixed compilation error for OMAP3 platforms [PATCH 3/5] <no change> [PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width [PATCH 5/5] additional cleanup in include/configs/cm_t35.h Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
This series few other patch series are awaiting response from long time.
Sorry for the delay -- I've been fairly busy, and don't usually get around to processing U-Boot patches until after the merge window closes. The IRC channel topic has been lying and saying the merge window is still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that the merge window is open and will close in negative 24 days).
Given that I don't do much with NAND myself these days, that the patch volume is higher than when I started as NAND custodian, and that I now have maintainership duties in Linux competing for my time, I'm wondering if someone else (maybe you or Heiko?) wants to step into the NAND custodian role.
-Scott
On Tue, May 27, 2014 at 12:21:21PM -0500, Scott Wood wrote:
On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
Hello Scott, Tom,
From: Gupta, Pekon
*changes v4 -> v5* [PATCH 1/5] <no change> [PATCH 2/5] fixed compilation error for OMAP3 platforms [PATCH 3/5] <no change> [PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width [PATCH 5/5] additional cleanup in include/configs/cm_t35.h Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
This series few other patch series are awaiting response from long time.
Sorry for the delay -- I've been fairly busy, and don't usually get around to processing U-Boot patches until after the merge window closes. The IRC channel topic has been lying and saying the merge window is still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that the merge window is open and will close in negative 24 days).
Bah, I always forget to update those parts as well, beyond the actual releases...
Given that I don't do much with NAND myself these days, that the patch volume is higher than when I started as NAND custodian, and that I now have maintainership duties in Linux competing for my time, I'm wondering if someone else (maybe you or Heiko?) wants to step into the NAND custodian role.
It's been a pleasure working with you. Pekon? Heiko? Either of you interested in this particular role? Thanks!
Hello Tom,
Am 28.05.2014 23:00, schrieb Tom Rini:
On Tue, May 27, 2014 at 12:21:21PM -0500, Scott Wood wrote:
On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
Hello Scott, Tom,
From: Gupta, Pekon
*changes v4 -> v5* [PATCH 1/5]<no change> [PATCH 2/5] fixed compilation error for OMAP3 platforms [PATCH 3/5]<no change> [PATCH 4/5] dropped old [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width instead new [PATCH] mtd: nand: omap: add CONFIG_SYS_NAND_BUSWIDTH_16BIT to indicate NAND device bus-width [PATCH 5/5] additional cleanup in include/configs/cm_t35.h Build tested for: MAKEALL -s am33xx -s omap3 -s omap4 -s omap5 Rebased above series: http://lists.denx.de/pipermail/u-boot/2014-April/177323.html
This series few other patch series are awaiting response from long time.
Sorry for the delay -- I've been fairly busy, and don't usually get around to processing U-Boot patches until after the merge window closes. The IRC channel topic has been lying and saying the merge window is still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that the merge window is open and will close in negative 24 days).
Bah, I always forget to update those parts as well, beyond the actual releases...
Given that I don't do much with NAND myself these days, that the patch volume is higher than when I started as NAND custodian, and that I now have maintainership duties in Linux competing for my time, I'm wondering if someone else (maybe you or Heiko?) wants to step into the NAND custodian role.
It's been a pleasure working with you. Pekon? Heiko? Either of you interested in this particular role? Thanks!
I am not a NAND expert and I am little bit under water currently... (but if nobody else volunteers I can try it ...)
Pekon?
bye, Heiko
From: Heiko Schocher [mailto:hs@denx.de]
Am 28.05.2014 23:00, schrieb Tom Rini:
On Tue, May 27, 2014 at 12:21:21PM -0500, Scott Wood wrote:
On Tue, 2014-05-27 at 11:48 +0000, Gupta, Pekon wrote:
[...]
This series few other patch series are awaiting response from long time.
Sorry for the delay -- I've been fairly busy, and don't usually get around to processing U-Boot patches until after the merge window closes. The IRC channel topic has been lying and saying the merge window is still open (also, http://www.denx.de/wiki/U-Boot/ReleaseCycle says that the merge window is open and will close in negative 24 days).
Bah, I always forget to update those parts as well, beyond the actual releases...
Given that I don't do much with NAND myself these days, that the patch volume is higher than when I started as NAND custodian, and that I now have maintainership duties in Linux competing for my time, I'm wondering if someone else (maybe you or Heiko?) wants to step into the NAND custodian role.
It's been a pleasure working with you. Pekon? Heiko? Either of you interested in this particular role? Thanks!
I am not a NAND expert and I am little bit under water currently... (but if nobody else volunteers I can try it ...)
Pekon?
bye, Heiko
Yes, Heiko please proceed. I might be transitioning to new work soon. So for few months I don't want to commit for something which I might not be able to fulfill. But I'll surely help in reviewing the patches, apart from OMAP ones.
Also looping "Stefan Roese sr@denx.de" CFI flash custodian [1] as he has helped in reviewing many OMAP and MTD/NAND patches. Stefan ?
It would be good, if the custodianship is transferred bit gradually at stable release, so that we don't miss any old reviews and feedback.
[1] http://www.denx.de/wiki/U-Boot/Custodians
with regards, pekon
participants (5)
-
Gupta, Pekon -
Heiko Schocher -
Pekon Gupta
-
Scott Wood -
Tom Rini