Re: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
Hi,
I got OMAP-L138 EVM and I'm running kernel v2.6.34
from khilman/linux-davinci.git and I would like to try the SPI patch. I
successfully applied the patch to the driver, and now I'm trying to modify
platform data in board-da850-evm.c. I added the following lines :
#include
[...]
static struct davinci_spi_config spidev_cfg = {
.parity_enable = 0,
.intr_level = 0,
.io_type= SPI_IO_TYPE_DMA,
.wdelay = 0,
.timer_disable = 1,
};
static struct spi_board_info da850_spi_board_info[] = {
[0] = {
.modalias = "spidev",
.controller_data = &spidev_cfg,
.mode = SPI_MODE_0,
.max_speed_hz = 1000,
.bus_num = 1,
.chip_select = 1,
},
};
[...]
static __init void da850_evm_init(void)
{
int ret;
[...]
ret = davinci_cfg_reg_list(da850_spi1_pins);
if (ret)
pr_warning("da850_evm_init: spi1 mux setup failed: %d\n", ret);
da850_init_spi1(NULL, 2, da850_spi_board_info,
ARRAY_SIZE(da850_spi_board_info));
[...]
}
I do not see spidev1.1 in /dev. Any clue?
Thank you.
Regards,
Nicolas
On Mon, Jun 14, 2010 at 3:13 PM, Brian Niebuhr wrote:
> > > diff --git a/arch/arm/mach-davinci/dm365.c
> > b/arch/arm/mach-davinci/dm365.c
> > > index a146849..0bd9f93 100644
> > > --- a/arch/arm/mach-davinci/dm365.c
> > > +++ b/arch/arm/mach-davinci/dm365.c
> > > @@ -625,12 +625,6 @@ static u64 dm365_spi0_dma_mask =
> > DMA_BIT_MASK(32);
> > > static struct davinci_spi_platform_data dm365_spi0_pdata = {
> > > .version= SPI_VERSION_1,
> > > .num_chipselect = 2,
> > > - .clk_internal = 1,
> > > - .cs_hold= 1,
> > > - .intr_level = 0,
> > > - .poll_mode = 1,/* 0 -> interrupt mode 1->
> > polling mode */
> > > - .c2tdelay = 0,
> > > - .t2cdelay = 0,
> > > };
> > >
> > > static struct resource dm365_spi0_resources[] = {
> >
> > This patch does not contain modifications to resource
> > structure to 'or' the
> > IORESOURCE_DMA_RX_CHAN, IORESOURCE_DMA_TX_CHAN and
> > IORESOURCE_DMA_EVENT_Q
> > flags with IORESOURCE_DMA. I don't think without this
> > modification driver
> > will work.
>
> You are right - my mistake. I will include that in the next version. I
> assume you added these flags when you were testing?
>
> ___
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [spi-devel-general] [PATCH 0/3] davinci: spi: replace existingSPI driver
> On Tue, Jun 15, 2010 at 00:43:06, Brian Niebuhr wrote: > > > > I have compiled with the davinci_all_defconfig, but I don't > > > have EVMs > > > > for the other davinci platforms to test with. > > > > > > > > > > I was testing this series on OMAP-L137, OMAP-L138 and > DM365 EVMs and I > > > found that on all these EVMS, Interrupt mode has problems. > > > Driver works > > > fine in DMA and POLL modes. Some problems which I had > > > observed with the > > > old driver are gone now. > > > > Do you have any idea what errors you're seeing in interrupt mode? I > > went and retested interrupt mode with several devices on my > custom board > > and it still appeared to be working fine. It may be an > interaction with > > code outside the driver because I'm running the identical > driver code > > but I'm not running the latest kernel from the davinci git > repository. > > I'm trying to figure out if I can get my DA850 EVM back into a state > > where I can debug this. Thanks for any hints you can give! > > > > You may be knowing that on OMAP-L138 EVM, we have M25P64 > Flash on SPI. When > the driver is configured in Interrupt mode, kernel booting > just hangs. I > noticed that the SPI probe function is not coming out of > spi_bitbang_start() > call. I configured the M25P64 on the DA850 EVM for both DMA and interrupt mode and my kernel still booted correctly. I wonder if your setting for intr_level is correct? For the DA850 it should be set to 1. I'm following up with a response to Nicolas showing the changes I made to the kernel to test this. Can you check if the changes you made match mine? Thanks, Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
> I got OMAP-L138 EVM and I'm running kernel v2.6.34 from
> khilman/linux-davinci.git and I would like to try the SPI
> patch. I successfully applied the patch to the driver, and
> now I'm trying to modify platform data in board-da850-evm.c.
> I added the following lines :
>
> [...]
>
> I do not see spidev1.1 in /dev. Any clue?
Following is a diff of changes I made to the board configuration to add
the M25P64 SPI flash to the DA850 EVM. Note that this is NOT
recommended as a patch - I just put in some quick and dirty code to
reproduce Sudhakar's issue with the driver. See diff below:
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/boa
index 2ec3095..4ecae04 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -27,6 +27,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -35,6 +37,7 @@
#include
#include
#include
+#include
#define DA850_EVM_PHY_MASK 0x1
#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -92,6 +95,59 @@ static struct platform_device
da850_evm_norflash_device = {
.resource = da850_evm_norflash_resource,
};
+static struct mtd_partition spi_flash_partitions[] = {
+ [0] = {
+ .name = "U-Boot",
+ .offset = 0,
+ .size = SZ_256K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [1] = {
+ .name = "U-Boot Environment",
+ .offset = MTDPART_OFS_APPEND,
+ .size = SZ_64K,
+ .mask_flags = MTD_WRITEABLE,
+ },
+ [2] = {
+ .name = "Linux",
+ .offset = MTDPART_OFS_NXTBLK,
+ .size = SZ_8M - (SZ_256K + SZ_64K + SZ_64K),
+ .mask_flags = 0,
+ },
+};
+
+struct davinci_spi_config m25p64_spi_cfg = {
+ .odd_parity = 0,
+ .parity_enable = 0,
+ .intr_level = 1,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+ .c2t_delay = 0,
+ .t2c_delay = 0,
+ .t2e_delay = 0,
+ .c2e_delay = 0,
+};
+
+static struct flash_platform_data spi_flash_data = {
+ .name = "m25p80",
+ .parts = spi_flash_partitions,
+ .nr_parts = ARRAY_SIZE(spi_flash_partitions),
+ .type = "m25p64",
+};
+
+static struct spi_board_info da850_spi_board_info[] = {
+ [0] = {
+ .modalias = "m25p80",
+ .platform_data = &spi_flash_data,
+ .controller_data = &m25p64_spi_cfg,
+ .mode = SPI_MODE_0,
+ .max_speed_hz = 3000,
+ .bus_num = 1,
+ .chip_select = 0,
+ },
+};
+
static struct davinci_pm_config da850_pm_pdata = {
.sleepcount = 128,
};
@@ -629,6 +685,61 @@ static int __init da850_evm_config_emac(void)
}
device_initcall(da850_evm_config_emac);
+static struct davinci_spi_platform_data da850_spi_pdata1 = {
+ .version = SPI_VERSION_2,
+};
+
+static struct resource da850_spi_resources1[] = {
+ [0] = {
+ .start = 0x01F0E000,
+ .end = 0x01F0E000 + 0xfff,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = IRQ_DA8XX_SPINT1,
+ .end = IRQ_DA8XX_SPINT1,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = EDMA_CTLR_CHAN(0, 18),
+ .end = EDMA_CTLR_CHAN(0, 18),
+ .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
+ },
+ [3] = {
+ .start = EDMA_CTLR_CHAN(0, 19),
+ .end = EDMA_CTLR_CHAN(0, 19),
+ .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
+ },
+ [4] = {
+ .start = 1,
+ .end = 1,
+ .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
+ },
+};
+
+static struct platform_device da850_spi_pdev1 = {
+ .name = "spi_davinci",
+ .id = 1,
+ .resource = da850_spi_resources1,
+ .num_resources = ARRAY_SIZE(da850_spi_resources1),
+ .dev = {
+ .platform_data = &da850_spi_pdata1,
+ },
+};
+
+static void __init da850_init_spi1(unsigned char* chip_sel,
+ unsigned int num_sel, struct spi_board_info *info, unsigned
num_dev)
+{
+ struct davinci_spi_platform_data *pdata =
+ da850_spi_pdev1.dev.platform_data;
+
+ spi_register_board_info(info, num_dev);
+
+ pdata->chip_sel = chip_sel;
+ pdata->num_chipselect = num_sel;
+ platform_device_register(&da850_spi_pdev1);
+}
+
static __init void da850_evm_init(void)
{
int ret;
@@ -739,6 +850,9 @@ static __init void da850_evm_init(void)
pr_warning("da850_evm_init: cpuidle registration failed:
%d\n",
ret);
+ da850_init_spi1(NULL, 1, da850_spi_board_info,
+
Re: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
Brian,
I modified board-da850-evm.c with what you proposed and it's working very
well. I didn't test the spi flash (because I do not have one on my custum
hardware), but my 2 SPI CS (spidev1.1 and spidev1.2) are working.
Thanks for your time.
Nicolas
On Wed, Jun 16, 2010 at 11:57 AM, Brian Niebuhr wrote:
> > I got OMAP-L138 EVM and I'm running kernel v2.6.34 from
> > khilman/linux-davinci.git and I would like to try the SPI
> > patch. I successfully applied the patch to the driver, and
> > now I'm trying to modify platform data in board-da850-evm.c.
> > I added the following lines :
> >
> > [...]
> >
> > I do not see spidev1.1 in /dev. Any clue?
>
> Following is a diff of changes I made to the board configuration to add
> the M25P64 SPI flash to the DA850 EVM. Note that this is NOT
> recommended as a patch - I just put in some quick and dirty code to
> reproduce Sudhakar's issue with the driver. See diff below:
>
> diff --git a/arch/arm/mach-davinci/board-da850-evm.c
> b/arch/arm/mach-davinci/boa
> index 2ec3095..4ecae04 100644
> --- a/arch/arm/mach-davinci/board-da850-evm.c
> +++ b/arch/arm/mach-davinci/board-da850-evm.c
> @@ -27,6 +27,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> @@ -35,6 +37,7 @@
> #include
> #include
> #include
> +#include
>
> #define DA850_EVM_PHY_MASK 0x1
> #define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
> @@ -92,6 +95,59 @@ static struct platform_device
> da850_evm_norflash_device = {
>.resource = da850_evm_norflash_resource,
> };
>
> +static struct mtd_partition spi_flash_partitions[] = {
> + [0] = {
> + .name = "U-Boot",
> + .offset = 0,
> + .size = SZ_256K,
> + .mask_flags = MTD_WRITEABLE,
> + },
> + [1] = {
> + .name = "U-Boot Environment",
> + .offset = MTDPART_OFS_APPEND,
> + .size = SZ_64K,
> + .mask_flags = MTD_WRITEABLE,
> + },
> + [2] = {
> + .name = "Linux",
> + .offset = MTDPART_OFS_NXTBLK,
> + .size = SZ_8M - (SZ_256K + SZ_64K + SZ_64K),
> + .mask_flags = 0,
> + },
> +};
> +
> +struct davinci_spi_config m25p64_spi_cfg = {
> + .odd_parity = 0,
> + .parity_enable = 0,
> + .intr_level = 1,
> + .io_type= SPI_IO_TYPE_DMA,
> + .wdelay = 0,
> + .timer_disable = 1,
> + .c2t_delay = 0,
> + .t2c_delay = 0,
> + .t2e_delay = 0,
> + .c2e_delay = 0,
> +};
> +
> +static struct flash_platform_data spi_flash_data = {
> + .name = "m25p80",
> + .parts = spi_flash_partitions,
> + .nr_parts = ARRAY_SIZE(spi_flash_partitions),
> + .type = "m25p64",
> +};
> +
> +static struct spi_board_info da850_spi_board_info[] = {
> + [0] = {
> + .modalias = "m25p80",
> + .platform_data = &spi_flash_data,
> + .controller_data = &m25p64_spi_cfg,
> + .mode = SPI_MODE_0,
> + .max_speed_hz = 3000,
> + .bus_num = 1,
> + .chip_select = 0,
> + },
> +};
> +
> static struct davinci_pm_config da850_pm_pdata = {
>.sleepcount = 128,
> };
> @@ -629,6 +685,61 @@ static int __init da850_evm_config_emac(void)
> }
> device_initcall(da850_evm_config_emac);
>
> +static struct davinci_spi_platform_data da850_spi_pdata1 = {
> + .version = SPI_VERSION_2,
> +};
> +
> +static struct resource da850_spi_resources1[] = {
> + [0] = {
> + .start = 0x01F0E000,
> + .end = 0x01F0E000 + 0xfff,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .start = IRQ_DA8XX_SPINT1,
> + .end = IRQ_DA8XX_SPINT1,
> + .flags = IORESOURCE_IRQ,
> + },
> + [2] = {
> + .start = EDMA_CTLR_CHAN(0, 18),
> + .end = EDMA_CTLR_CHAN(0, 18),
> + .flags = IORESOURCE_DMA | IORESOURCE_DMA_RX_CHAN,
> + },
> + [3] = {
> + .start = EDMA_CTLR_CHAN(0, 19),
> + .end = EDMA_CTLR_CHAN(0, 19),
> + .flags = IORESOURCE_DMA | IORESOURCE_DMA_TX_CHAN,
> + },
> + [4] = {
> + .start = 1,
> + .end = 1,
> + .flags = IORESOURCE_DMA | IORESOURCE_DMA_EVENT_Q,
> + },
> +};
> +
> +static struct platform_device da850_spi_pdev1 = {
> + .name = "spi_davinci",
> + .id = 1,
> + .resource = da850_spi_resources1,
> + .num_resources = ARRAY_SIZE(da850_spi_resources1),
> + .dev = {
> + .platform_data = &da850_spi_pdata1,
> + },
> +};
> +
> +static void __init da850_init_spi1(unsigned char* chip_sel,
> + unsigned int num_sel, struct spi_board_info *info, unsigned
> num_dev)
> +{
> + struct davinci_s
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
> I modified board-da850-evm.c with what you proposed and it's > working very well. I didn't test the spi flash (because I do > not have one on my custum hardware), but my 2 SPI CS > (spidev1.1 and spidev1.2) are working. Nicolas - Would you mind taking a few minutes and testing interrupt mode for the devices on your board? I'm trying to reproduce the issue that Sudhakar was seeing, and I would appreciate additional testing if you've got the time. Thanks, Brian ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
Brian, I changed .io_type from SPI_IO_TYPE_DMA to SPI_IO_TYPE_INTR with ".intr_level = 1". My kernel it not freezing at startup and both devices (CS1 and CS2) are still working fine. Anything else you would like to check? Nicolas On Wed, Jun 16, 2010 at 12:54 PM, Brian Niebuhr wrote: > > I modified board-da850-evm.c with what you proposed and it's > > working very well. I didn't test the spi flash (because I do > > not have one on my custum hardware), but my 2 SPI CS > > (spidev1.1 and spidev1.2) are working. > > Nicolas - > > Would you mind taking a few minutes and testing interrupt mode for the > devices on your board? I'm trying to reproduce the issue that Sudhakar > was seeing, and I would appreciate additional testing if you've got the > time. > > Thanks, > > Brian > > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 3/3] davinci: spi: modify platform data for updated SPIdriver
Brian, On Wed, Jun 16, 2010 at 23:07:45, Nicolas Luna wrote: > Brian, > > I changed .io_type from SPI_IO_TYPE_DMA to SPI_IO_TYPE_INTR with > ".intr_level = 1". My kernel it not freezing at startup and both devices > (CS1 and CS2) are still working fine. Anything else you would like to check? > > Nicolas > > > > On Wed, Jun 16, 2010 at 12:54 PM, Brian Niebuhr > wrote: > > > > I modified board-da850-evm.c with what you proposed and it's > > working very well. I didn't test the spi flash (because I do > > not have one on my custum hardware), but my 2 SPI CS > > (spidev1.1 and spidev1.2) are working. > > > Nicolas - > > Would you mind taking a few minutes and testing interrupt mode for the > devices on your board? I'm trying to reproduce the issue that Sudhakar > was seeing, and I would appreciate additional testing if you've got the > time. > My mistake, I had not set "intr_level" to 1. When I set intr_level to 1, even interrupt mode is working fine. Are you planning to submit any new version of this patch series to the list after addressing the minor comments I had? Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] rtc: omap: let device wakeup capability be configured from chip init logic
Hi Dave, Any thoughts on my responses below? If you are satisfied, would you please Ack my patch? Thanks, Sekhar On Mon, May 24, 2010 at 11:36:45, Nori, Sekhar wrote: > Hi Dave, > > On Thu, May 20, 2010 at 22:21:59, David Brownell wrote: > > > > > > This patch lets the wakeup capability to be set from > > > platform data and > > > > does not override the setting from the driver. For > > > DA850/OMAP-L138, this > > > > is done from > > > arch/arm/mach-davinci/devices-da8xx.c:da8xx_register_rtc() > > > > > > > > Note that this patch does not change the behavior on > > > any existing OMAP1 > > > > board since the platform device registration sets the > > > wakeup capability > > > > to 0 by default. > > Just to be clear, I was actually referring to the fact > that the device_initialize() in drivers/base/core.c is > already clearing the 'can wake-up' flag to 0, so there > should be no need to do so again in the driver. > > > > > Dave, would you please ack this patch if you are > > > satisfied? > > > > I don't see how it could work, since it always sets the > > wake capability to the default of "can't wake"... Even if > > the board *can* wake... > > Are you referring to da8xx_register_rtc() here? It sets the > 'can wake' flag to true. > > ret = platform_device_register(&da8xx_rtc_device); > if (!ret) > /* Atleast on DA850, RTC is a wakeup source */ > device_init_wakeup(&da8xx_rtc_device.dev, true); > > > > > The model I've worked with is that for devices which can issue > > wake events, the board init code sets that flag, and the driver > > responds appropriately. Presumably that could work here too... > > Yes, except that the response to the wakeup event is really specific > to DaVinci/DA850 and is handled in arch/arm/mach-davinci/sleep.S, not > in the RTC driver. > > > > > > > > Can you please ack this patch if it looks good (or suggest > > > any other changes you would like to see)? > > > > > >device_init_wakeup(&pdev->dev, 0); > > > > Having that line seems to defeat the purpose... > > Agreed, and the patch removes it for that reason. > > Thanks, > Sekhar > ___ > Davinci-linux-open-source mailing list > Davinci-linux-open-source@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM365 UBoot + NAND Query
Hi, The partition table information for the two NAND chips (each of 1GB, Blocksize 256KB) listed by kernel is as follows: Kernel Bootlog: = NAND device: Manufacturer ID: 0x2c, Chip ID: 0xd3 (Micron NAND 1GiB 3,3V 8-bit) 2 NAND chips detected Creating 5 MTD partitions on "nand_davinci.0": 0x-0x0078 : "bootloader" 0x0078-0x0080 : "params" 0x0080-0x00c0 : "kernel" 0x00c0-0x20c0 : "filesystem1" 0x20c0-0x8000 : "filesystem2" r...@10.100.3.65:~# cat /proc/mtd dev:size erasesize name mtd0: 0078 0004 "bootloader" mtd1: 0008 0004 "params" mtd2: 0040 0004 "kernel" mtd3: 2000 0004 "filesystem1" mtd4: 5f40 0004 "filesystem2" mtd5: 2000 0010 "spi_eeprom" I don't see anything wrong the NAND partition. I simply tried to erase the mtd4 partition using "flash_eraseall /dev/mtd4". The erase was successful. But next time when I reboot the board it does not booted up. It has erased the UBL/UBoot also. Am I missing something or doing something wrong? Please suggest. Erase Log: == Erasing 256 Kibyte @ 0 -- 0 % complete. Erasing 256 Kibyte @ 4 -- 0 % complete. Erasing 256 Kibyte @ 8 -- 0 % complete. Erasing 256 Kibyte @ c -- 0 % complete. || || || Erasing 256 Kibyte @ 5f1c -- 99 % complete. Erasing 256 Kibyte @ 5f20 -- 99 % complete. Erasing 256 Kibyte @ 5f24 -- 99 % complete. Erasing 256 Kibyte @ 5f28 -- 99 % complete. Erasing 256 Kibyte @ 5f2c -- 99 % complete. -- Regards, Krunal On 06/15/2010 11:43 PM, Steve Poulsen wrote: Krunal, I have not experienced this so I cannot offer any advice other than debugging methods, which you already know. Maybe you can cat /proc/mtd to make sure it agrees with what you expect. Steve On 06/11/2010 12:41 PM, Krunal Patil wrote: Steve, Thanks for the reply. I have solved ECC issue same way. I was using linux kernel 2.6.18. Anyways the major problem starts now. I tried to mount mtd partitions mtd3 and mtd4 from the linux prompt. I verified the size of mounted partition. mtd3 partition shows ~500MB and for mtd4 its 1.5G. When I copied more than 500 MB data (~650MB) on mtd4 partition and next time when I booted the board it was not booting. I think the UBL/UBoot partitions were overwritten. Again I flashed the UBL/UBoot and the board is booting without any problem. Have you ever experienced this? Regards, Krunal - Original Message - From: "Steve Poulsen" To: davinci-linux-open-source@linux.davincidsp.com Sent: Friday, June 11, 2010 8:53:35 PM Subject: Re: DM365 UBoot + NAND Query Krunal, What version kernel are you using? One thing to note is that the Chip ID of 0xd3 can actually correspond to several layouts of the NAND. The kernel seems to read the proper info and adjust accordingly but U-boot may not. If you are using 2.6.10, you will need to go through and increase several of the arrays because they do not handle the larger layout (4224 bytes) and will overflow and cause ECC errors or even lockups. If you are using 2.6.18, you will also want to either turn off the "use standard layout" option under the kernel config (Drivers-MTD-Nand, somewhere below that) OR you will want to make sure U-boot is using the larger layout. I have seen the exact error you seen and fixed it by changing the array sizes and disabling the Davinci use standard layout option. This puts newer kernels back to the 4-bit ECC as opposed to Software ECC. Some versions of the kernel may have broken HW-ECC though. Steve On 06/11/2010 04:46 AM, Krunal Patil wrote: Thanks for the pointers Jon. I will try your suggestions and get back with the results. -- Regads, Krunal - Original Message - From: "Jon Povey" To: "krunal patil" Cc: "Davinci List" Sent: Friday, June 11, 2010 3:13:54 PM Subject: RE: DM365 UBoot + NAND Query Krunal Patil wrote: > 1.How can I verify whether UBoot is detecting and accessing both the > NANDs not only one? u-boot can read, write and erase NAND; you could erase and write a page on one chip and see if it shows up on the other. > 2.Can you please through some light on "I would be more concerned > about the ECC errors and that the kernel is reporting BBT not found." Well, this should not happen: > > > nand_bbt: ECC error while reading bad block table And the kernel should find the BBTs, it should agree with U-boot. I suggest trying a more recent version of u-boot if that's an option. > 3.How can I verify "Large page OOB layout" in UBoot and Kernel? How > can I fix this mismatch? I find OpenOCD useful, it's JTAG software with davinci NAND drivers for both large page layouts, and config files for many davinci boards. If you do
