How to stop mtd char device generating ECC on writes?
I am trying to write a binary image to NAND flash using nandwrite on TI DaVinci DM355. For historical reasons involving badly-written ROM bootloaders, I want to write the "legacy" OOB format for one area of flash (the UBL, second-stage bootloader). For reference the legacy layout of a 2KB flash page is 4x (512B data followed by 16B OOB (6 spare then 10 ECC)). The "new" format used by u-boot, MTD etc. is 2KB data followed by 64B OOB (24 spare then 40 ECC). I can get a bootloader image with the needed (legacy) OOB and ECC using nanddump -f ubl0.dump -s 0x2 -l 0x8000 -n /dev/mtd0 But I can't seem to write it back properly using nandwrite. Testing on another partition mtd6, If I do this: nandwrite -r -s 0x2 /dev/mtd6 ubl0.dump then it seems my 64 bytes of "OOB" are skipped and I get a generated 24 bytes of 0xFF spare and 40 bytes of generated ECC. If I use --noecc --oob instead of -r, it looks like my 64 bytes of "OOB" does get written, but then hardware ECC is getting written OVER THE TOP, i.e. the last 40 bytes have various bits 0 that should be 1 (but no 1s that should be 0) I am looking through the nandwrite and drivers/mtd sources at the moment, but would love to get a clue if someone can tell me - Does MTD support what I'm trying to do from userland? - If yes, could this be a bug in the DaVinci NAND driver? - Or, is nandwrite supposed to support this? or do I need to modify it? Thanks folks, -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: How to stop mtd char device generating ECC on writes?
Matthieu CASTET wrote: > Jon Povey a écrit : >> - Does MTD support what I'm trying to do from userland? > yes write in raw mode + MEMWRITEOOB. But you will need 2 number of > program. Thanks Matthieu. Sod's law, I actually found the answer a few minutes after sending the email.. Realised I hadn't tried "--noecc --raw" combination of switches. Works great. Sorry for noise, hopefuly some archive reader can learn from my mistake. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] davinci: I2C: Adding bus frequency as module parameter
With current implementation, when I2C is used as a module,
for slave devices which operate at different frequencies,
the bus frequency needs to be modified in the board
configuration file and kernel needs to be re-built.
This patch addresses this issue by adding bus frequency as
module parameter.
Signed-off-by: vishwa
---
Since v1:
a. added MODULE_PARAM_DESC.
b. Moved module parameter definitions to the beginning of the file.
c. 'pdata->bus_freq' is being set in i2c_davinci_init() function.
drivers/i2c/busses/i2c-davinci.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index c87..8fbfaa2 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -98,6 +98,10 @@
#define DAVINCI_I2C_IMR_NACK BIT(1)
#define DAVINCI_I2C_IMR_AL BIT(0)
+static int i2c_davinci_busfreq;
+module_param(i2c_davinci_busfreq, int, 0);
+MODULE_PARM_DESC(i2c_davinci_busfreq, "bus frequency");
+
struct davinci_i2c_dev {
struct device *dev;
void __iomem*base;
@@ -243,6 +247,9 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev)
/* put I2C into reset */
davinci_i2c_reset_ctrl(dev, 0);
+ if (i2c_davinci_busfreq != 0)
+ pdata->bus_freq = i2c_davinci_busfreq;
+
/* compute clock dividers */
i2c_davinci_calc_clk_dividers(dev);
--
1.5.6
___
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 RFC v9] MUSB: DA8xx/OMAP-L1x glue layer
Hello. Greg KH wrote: Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver. Signed-off-by: Sergei Shtylyov Signed-off-by: Yadviga Grigorieva --- The patch is against the recent Linus' tree. Felipe, please ACK it soonish, so it can go into 2.6.36 at last... It's too late for .36, sorry, patches needed to be in my tree _before_ the merge window opened. How much longer will I have to wait with this, I wonder? You could have merged version 8 but Felipe just ignored it. :-( I rely on Felipe to be the one to send me musb patches. If he's ignoring your patches, please take it up with him. Well, he's on CC list of this mail... thanks, greg k-h WBR, Sergei ___ 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] m25p80: add support for a callback to platform code on successful device probe
Hi Mike, On Wed, Aug 11, 2010 at 00:32:00, Mike Frysinger wrote: > On Tue, Aug 10, 2010 at 09:07, David Brownell wrote: > >> On Tue, Aug 10, 2010 at 12:47:05, Mike Frysinger wrote: > >> it is necessary > >> > that you do these things from kernel space instead of > >> standard > >> > userspace. > > > > Hard to get userspace to do this stuff if > > you're doing a network boot, and thus need > > to have the MAC address working early.. it's > > easy if the kernel can get the MAC address, > > else not possible to boot. Right? > > no, that isnt true at all. you can easily have a small initramfs to > handle all of your random setup. if that's too much overhead, you can > add a late initcall to your boards file that is run after the MTD > devices are probed and let that read the required information. all of > this is more than documented: > http://www.denx.de/wiki/view/DULG/EthernetDoesNotWorkInLinux > I looked around in the kernel and found mtd_notifier callbacks which get called upon addition of MTD device. Inside this callback, I am checking for the device in which I am interested and doing a mtd->read to get the MAC address. So this patch can be dropped. 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: GIT Kernel and CMEM 2.25.04.10
Hello: El Viernes, 23 de Julio de 2010 17:57:13 Vitaly Makarov escribió: > Dear All, > > I am trying to compile the latest CMEM (2.25.04.10) for the latest git > kernel and getting the following error: > WARNING: "arm926_dma_map_area" [BSP/cmem/src/module/cmemk.ko] > and this module can not be used with the kernel due unresolved symbol. > > Did anyone faced the issue and successfully resolved it? > > Thank you I don't know the answer to your question, but I've noticed a new linuxutils has been released after the ones you are using [0]. I've also seen this wiki page useful as general information: [1] HTH, [0] http://software- dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html [1] http://processors.wiki.ti.com/index.php/LinuxUtils_Internals -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ 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] davinci: I2C: Adding bus frequency as module parameter
vishwa writes:
> With current implementation, when I2C is used as a module,
> for slave devices which operate at different frequencies,
> the bus frequency needs to be modified in the board
> configuration file and kernel needs to be re-built.
>
> This patch addresses this issue by adding bus frequency as
> module parameter.
>
> Signed-off-by: vishwa
> ---
> Since v1:
> a. added MODULE_PARAM_DESC.
> b. Moved module parameter definitions to the beginning of the file.
> c. 'pdata->bus_freq' is being set in i2c_davinci_init() function.
>
> drivers/i2c/busses/i2c-davinci.c |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-davinci.c
> b/drivers/i2c/busses/i2c-davinci.c
> index c87..8fbfaa2 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -98,6 +98,10 @@
> #define DAVINCI_I2C_IMR_NACK BIT(1)
> #define DAVINCI_I2C_IMR_AL BIT(0)
>
> +static int i2c_davinci_busfreq;
> +module_param(i2c_davinci_busfreq, int, 0);
> +MODULE_PARM_DESC(i2c_davinci_busfreq, "bus frequency");
> +
> struct davinci_i2c_dev {
> struct device *dev;
> void __iomem*base;
> @@ -243,6 +247,9 @@ static int i2c_davinci_init(struct davinci_i2c_dev *dev)
> /* put I2C into reset */
> davinci_i2c_reset_ctrl(dev, 0);
>
> + if (i2c_davinci_busfreq != 0)
> + pdata->bus_freq = i2c_davinci_busfreq;
I don't really like using a module parameter to modify the contents of
struct platform_data, especially when this comes from a board file.
Intead this should look something like
if (!i2c_davinci_busfreq)
i2c_davinci_bus_freq = pdata->bus_freq;
and the code should use i2c_davinci_busfreq instead of pdata->bus_freq.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: The 6467t evm goes to reset immediately after the switching to PCI mode from nand
wenaideyu wenaideyu wrote on Tuesday, August 10, 2010 8:59 PM: > Hi: >thanks a lot for your advice. I have printed the value of > PCI_RST(GPIO[13]) before switching from NAND to PCI, the value is 1. > Itmeans PCI_RST has been driven high. > >but the board still resets while the kernel calls > "davinci_cfg_reg(DM646X_PCIEN)" in the file of board-dm646x-evm.c > >I just select the PCI bus support in the configuration of > kernel,and I do not select the support of mtd and ata in kernel. > > shoud I do some configuration about the Davincihd1080p evm while it acts > as a PCI host? > >best wishes! By default, GPIO13 may not be used as PCI_RST. As per the wiki link, "The Altera CPLD on the board controls the mux switches depending on whether or not the EVM is plugged into a PCI backplane. To instead control the switches with a GPIO, the CPLD must be reprogrammed with a modified firmware..." - Hemant ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
