topic Re: VF6xxx NFC (NAND) module clocking in Vybrid Processors

VF6xxx NFC (NAND) module clocking

billpringlemeir — Mon, 16 Dec 2013 22:08:20 GMT

Section 31.4.5 Fast Flash Configuration for EDO has the following,

The NFC clock must be configured fast enough (usually > 33 MHz) according to the data sheet of flash devices.

On the IMX25, there are various timing diagrams which show how the NAND clock affect the timing. Originally, the NFC_CLK (from Chapter 10) was 133MHz with the main line Linux. I set this to 66MHz and the normal mode starts to function in EDO mode on the Tower board. However, when I turn on the ECC code it fails. I set the clock to 33Mhz and it is functioning. 9.12 Maximum Frequencies Supported has a maximum clocking of 80Mhz for the module. What kind of clock ranges does the module accept and are there timing diagrams so we can run a timing budget with our NAND chip selection and PCB traces?

19.4.3 Clocks at Boot Time has some timings that the boot code sets, but it never has the ECC enabled. Clocks are 30.85 (Normal Frequency) and 45.25 (Fast Frequency). It seems odd that all of the MTD tests pass without ECC and a 66MHz clock, but they fail with ECC enabled. The raw signals to the flash chip should be un-altered by the ECC; but I maybe running the NAND chip out of spec; how do I know? Is the clocking different when the module ECC is enabled?

In my case, I have a software ECC (Hamming, much like boot code) and all checks pass. There are other CRC32 data validations and no data or filesystem corruptions are observed with no hardware ECC and a 66MHz NFC clock. However, as soon as the hardware ECC is enabled, usually the 2nd 16bit value is corrupted unless the clock is change to ~33Mhz.

Re: VF6xxx NFC (NAND) module clocking

karina_valencia — Wed, 18 Dec 2013 22:57:21 GMT

timesyssupport can you help on this case?

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Thu, 19 Dec 2013 15:49:32 GMT

To be clear, mainline linux, means I am using the Linux kernel 3.13-rc4 (actually the arm-soc for/next branch). In the TimeSys Linux 3.0, the fsl_nfc driver will not work unless u-boot sets up clocks; running the TimeSys 3.0 Linux from the mainline u-boot.imx has the SDHC/eMMC functioning, but the flash is not recognized due to the default clock that is set for the NFC peripheral. For the combination of TimeSys Linux + TimeSys u-boot, the NFC clock is ~16.6MHz. These are setup in lowlevel_init.S via the macros in vybrid.h,

CONFIG_SYS_CLKCTRL_CSCMR1 - platform bus clock
CONFIG_SYS_CLKCTRL_CSCDR2 - clock invert, divide by 5
CONFIG_SYS_CLKCTRL_CSCDR3 - divide by 2.

This is in the TimeSys u-boot source. I guess the platform bus clock is 166MHz. It seems like the TimeSys u-boot source divides by 10. This is actually out of spec according to the EDO text. So in the Linux source we have,

   /* SET FAST_FLASH = 1 */
   #if 0
       nfc_set_field(mtd, NFC_FLASH_CONFIG,
             CONFIG_FAST_FLASH_MASK,
             CONFIG_FAST_FLASH_SHIFT, 1);
   #endif

Which leaves the EDO feature disabled. Pg 22-23 of the Micron data sheets have the timing for EDO modes.

If the host controller is using a t RC of 30ns or greater, the host can latch the data on the

rising edge of RE# (see the figure below for proper timing). If the host controller is using

a t RC of less than 30ns, the host can latch the data on the next falling edge of RE#.

The EDO mode assumes a latch on the falling edge of RE#. The value 33MHz corresponds to a 30nS timing.

This controller seems to be far slower than the IMX version. Sustained transfers of only 2MB/s write and 4MB/s read. The IMX25 gets double the performance using a similar Micron chip set; The IMX25 is using an 8bit flash versus the Tower 16bit flash chip!

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Thu, 19 Dec 2013 16:11:44 GMT

Section 3.7.6.2 NAND Flash Controller (NFC) Timing of IMX25CEC.pdf has the kind of timing diagrams I would expect/like so that we can know what kind of signalling the NAND flash chip can expect. The IMX25 is a synchronously clocked controller. Using the same Micron series with 8-bit 256MB version,

The Linux MTD test modules provide a means to measure flash performance.

NFC clock	T (nS)	Div	Write (MB/s)	Read (MB/s)	Erase (MB/s)
22MHz	45	/6	3.6	5.2	148
33MHz	30	/4	4.2	6.9	154
44MHz	22	/3	4.6	7.7	154

These values on an IMX25 (especially @44MHz) are double the current Vybrid speeds. I have re-written the fsl_nfc.c driver and am trying to prepare it for the mainline Linux. However, the hardware ECC doesn't not seem to work above speeds of 33Mhz with EDO enabled on the Vybrid. Why? I suspect that the hardware ECC is asynchronous and if we read too fast, it can not handle the data rate. Oddly, the faster clocking does not seem to increase the data rate much/at all for the Vybrid NFC controller.

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Sat, 21 Dec 2013 00:16:51 GMT

At least part of the performance issue is due to the Linux driver structure; at least for the write side. I am not sure why the read performance is so slow for the Vybrid controller. Also, I still don't understand why the hardware ECC fails with faster clock rates. Finally, it is not entirely clear what kind of signalling the NFC will generate. Maybe I have to solder a bunch of fly wires...

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Sat, 21 Dec 2013 00:43:57 GMT

Now, I am smoking the IMX25 [memcpy() vs memcpy_fromio()],

mtd_speedtest: MTD device: 1
mtd_speedtest: MTD device size 8388608, eraseblock size 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB size 64
mtd_test: scanning for bad eraseblocks
mtd_test: scanned 64 eraseblocks, 0 are bad
mtd_speedtest: testing eraseblock write speed
mtd_speedtest: eraseblock write speed is 4284 KiB/s
mtd_speedtest: testing eraseblock read speed
mtd_speedtest: eraseblock read speed is 16286 KiB/s
mtd_speedtest: testing page write speed
mtd_speedtest: page write speed is 3560 KiB/s
mtd_speedtest: testing page read speed
mtd_speedtest: page read speed is 15937 KiB/s
mtd_speedtest: testing 2 page write speed
mtd_speedtest: 2 page write speed is 3893 KiB/s
mtd_speedtest: testing 2 page read speed
mtd_speedtest: 2 page read speed is 16125 KiB/s
mtd_speedtest: Testing erase speed
mtd_speedtest: erase speed is 132129 KiB/s
mtd_speedtest: Testing 2x multi-block erase speed
mtd_speedtest: 2x multi-block erase speed is 234057 KiB/s
mtd_speedtest: Testing 4x multi-block erase speed
mtd_speedtest: 4x multi-block erase speed is 248242 KiB/s
mtd_speedtest: Testing 8x multi-block erase speed
mtd_speedtest: 8x multi-block erase speed is 256000 KiB/s

The buffering must be re-written to improve the write speed; it should be about 8MB/s. However, I still want to know why the ECC controller fails above 33MHz.

Re: VF6xxx NFC (NAND) module clocking

karina_valencia — Mon, 06 Jan 2014 16:33:37 GMT

timesyssupport do you have an update on this case?

Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Tue, 07 Jan 2014 15:50:23 GMT

Hello Bill,

Thank you for your detailed analysis of this issue. I have added this as a bug in our internal issue tracking for the Linux 3.0 kernel for Vybrid. I do not have an ETA on a fix for this, as our development resources are focused on updating to a later version of the kernel for Vybrid. If this is a time sensitive issue for you, I would recommend escalating with Timesys as a services project.

Thanks,

Timesys Support

Re: Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Tue, 07 Jan 2014 16:53:33 GMT

I am not sure what the issue you have filed is? Your driver is slow? I have attached patches for the 3.12-3.14 series that allow the Vybrid-NFC device to be used; It is GPL and your developers are free to use it. I am still working on minor issues before I try to submit it. The 'devm' and 'of' (open firmware/device tree) stuff would need to be removed to back-port to the 3.0 TimeSys series. Also, the 'FAST_FLASH' should not be set if the NFC clock remains under ~30Mhz as the TimeSys U-boot does. My original question was related to how the NFC clock input affects the module. If the clock is above 33MHz, the hardware ECC begins to fail. As the TimeSys code never runs above ~13MHz, you will never see this issue. I don't think that TimeSys can answer this question. This needs to be answered by Freescale or have I missed something in your reply?

Re: Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Tue, 07 Jan 2014 17:16:28 GMT

Hello Bill,

Thanks for attaching the patches. I filed the issue as that the ECC controller fails when the NFC clock is set over 33MHz. This may not be a driver issue, in which case Freescale would be better suited to assist with this issue. To confirm, you see the same issue when using your patches with mainline Linux, correct?

Thanks,

Timesys Support

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Tue, 07 Jan 2014 18:15:04 GMT

I can only see this issue with the main-line driver above; more over only the mainline has the infra-structure to set the input clock to the NFC. I guess if you edit the 'u-boot' source to change the NFC clock, you would see the issue with the TimeSys 3.0 driver; but I have not tried this. The way the 'u-boot' and 'Linux' combination is setup with TimeSys, there is no way to clock the NFC above ~13MHz unless the source is modified. With the mainline driver I have above, altering 'vf610-twr.dts' nfc '<clock>' line, you can change the frequency in divisors of 133Mhz (66, 44, 33, 26, 22, 19, 16, etc). To verify with the TimeSys driver, the u-boot's CONFIG_SYS_CLKCTRL_CSCDR2 and CONFIG_SYS_CLKCTRL_CSCDR3 can change to alter the divisor and the 'FAST_FLASH' should be enabled (EDO flash mode). The software ECC should work at 66MHz and 44Mhz, but the hardware ECC would fail (as per my observations). I have dumped the buffers and the 2nd word is corrupt always. I think that the ECC controller goes crazy with it's 'correction' if it is clocked above 33MHz, which is a magic number for the 'FAST_FLASH' to work. Clocking above 33Mhz does not significantly improve read/write/erase performance as the controller make NFC access CPU bound. However, below 33MHz, the time to move data from the flash starts to be more significant. tR_ECC is typical 45uS, max 70 uS for the Micron flash (move data from NAND cell to NAND buffer); during this time the NFC is waiting for READY/BUSY. The interface timing is ~16nS*1k -> 16uS (the minimum time for the NFC to act during a page read). This is the time related to NFC clock input; but I don't know how. It seems that 33MHz gives a read speed of ~15MB/s and 66MHz gives a read speed of 16.6MB/s. The Hardware ECC @33MHz gives 16.2MB/s as in the numbers above; it is in-between as the software doesn't run the ECC, but the interface time runs slower (the NFC moving data from flash to buffers time increased). If you could confirm the hardware ECC busts above 33MHz, that would help. If I confirm, can we get someone from Freescale to answer/act or should I open a service request with Freescale or something?

Also things may work as in HardwareECC@33MHz; but that doesn't mean they are right. I don't want the code to fail on one out of every 1000 units, especially on a hot day in some dirty location that I have to visit to diagnose the issue. I would like some official confirmation on the timing for the chip. Usually you must do a timing budget for the system, which is the flash chip, the flash controller and the PCB inter-connect. Each new Vybrid design using NAND flash should have the information on the controller so an appropriate clock can be picked (no matter what software is used). There really is no timing documentation on this NFC controller? The same controller seems to be used for the MPC5125 (PowerPC) and the MCF54418 (ColdFire) SOCs. Is there an NDA or public timing diagram for these SOC and the NFC in those implementations? I think the Hardware ECC failing above 33MHz is an errata, but only a system designer could say if it may reliably work at 33MHz under different voltage/temperatures. Or maybe I have set something up wrong; but if this is the case, it is most likely related to timing which I have no information on.

EDIT: The timing is available in Vybrid Fact sheet section 9.5.2. This was the electrical/timing data that I wanted. Now section 9.10.4 NFC clocking of the software user manual makes no sense. There is no mention of high/low time there. The clock inversion parameter makes more sense with the fact sheet timing. However, this additional information doesn't explain the Hardware ECC failure above 33MHz.

2nd EDIT: Apparently the Vybrid Fact sheet is a copy of the Kinetis parts? See: MQX and Kinetis. Also the MK70FN1M0VMJ12 data sheet, section 6.4.3. which is the same as the Vybrid document. This part seems to have a SIM_CLKDIV4; probably the Vybrid supplies tH/tL in a different way? So I still do not know of any definitive answer on the Vybrid timing. I think part of the story is in the fact sheet timing.

3rd Edit: I have open Service Request SR 1-1262845281. This confirms that the electrical data sheet does not have the complete information. Ie, the SIM_CLKDIV4 register doesn't exist on the Vybrid and there is some other timing source to the NFC controller; probably 9.10.4, but is the clock ever asymmetric. Ie, Is there still GLUE between these? Or is NFC clock feed direct, which makes the NFC_CLK_INV bit in CCM_CSCDR2[14] rather confusing unless there is some phase relation. I believe the MQX driver divides the platform clock by 5 for a 26MHz source and it does not set FASTFLASH, which also indicates a clocking under 33MHz. The MQX driver does enable hw-ecc by default.

Re: VF6xxx NFC (NAND) module clocking

karina_valencia — Fri, 10 Jan 2014 16:51:05 GMT

timesyssupport please continue with the follow up.

Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Sat, 11 Jan 2014 00:02:55 GMT

We are looking into reproducing this issue with the Timesys BSP. We expect to have an update early next week.

Thanks,

Timesys Support

Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Mon, 13 Jan 2014 23:02:49 GMT

Hello Bill,

In an attempt to reproduce this issue with the Timesys BSP, in u-boot 2011.12, I set CONFIG_SYS_CLKCTRL_CSCDR2 to 0x30114210 (for a total nfc clock divide of 4, leaving the nfc clock over 33MHz).

In Linux 3.0, I removed the #if block around the FAST_FLASH comment to enable EDO mode, and set CONFIG_MTD_NAND_FSL_NFC_SWECC=n in the kernel configuration (so hardware ecc is used). I was not successful in seeing any problems - the kernel loaded successfully, and I was also able to mount a jffs2 image as the root filesystem. Was there anything else you would like us to try under these conditions?

Thanks,

Timesys Support

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Tue, 14 Jan 2014 16:20:34 GMT

4th Edit: I had an off by one error in setting the NFC clock. My divide by 3 was actually 4; the CCM adds one to everything. My '/3' is actually divide by 4 or 33MHz, which works.

3rd Edit: I am running the same test with the mainline u-boot and the TimeSys 3.0 Linux driver and I also don't see any issues when running the mtd_pagetest.ko. I will look into this some more. It is odd that the mtd_speedtest.ko is giving the same results no matter what the clock is, but maybe the driver is the overhead.

2nd Edit: To quickly test, use the mtd_pagetest.ko as I have done below. Hopefully it passes with Software ECC and at lower speed hardware ECC. If it always fails, then you can not use this test and need to fix your driver. I have high lighted some issues below; mainly the current driver doesn't detect hardware ECC errors and turns off hardware ECC for some critical pages.

The CONFIG_SYS_CLKCTRL_CSCDR2 and CONFIG_SYS_CLKCTRL_CSCDR3 must both change; they both have NFC divisors. With a divisor of four, the platform bus speed is 133MHz and this gives the 33MHz value. Are you sure you are clocking faster than 33MHz? You should be able to divide by 2 or 3. '3' should fail at either 133MHz or 166Mhz platform bus and be in-range according to spec. Also, it may boot and mount. The driver you are using doesn't check for errors. Look for fsl_nfc_check_ecc_status(); There is a bug in the documentation in regards to the ecc_status line. Change the '7' to a '4' and I think you will read the correct ECC status (also there is an implementation in nfc_correct_data() in my 2nd patch above if you want to refer to that). The symptom of the corruption for me was that the 2nd word was invalid. Can you compile the 'mtd tests' (CONFIG_MTD_TESTS) and load these modules (from drivers/mtd/test/*.ko) to validate the nand flash system? I think this is a more reliable test.

Finally, there is if(!(page%0x40)) in fsl_nfc_command(). This should be un-needed, but it maybe what is making jffs2 work as usually flash headers are placed at the start of an erase sector which I think is what the '0x40' is about (64*2k=128k erase block). I am not really familiar with jffs2 and always use ubi/ubifs; but the mtd tests are best. The 'page test' is the most basic one which should pass. Enable the fsl_nfc_check_ecc_status() (with fix) in fsl_nfc_read_page(), and see if there are any kernel logs printed where the ECC is reported as failed. When I turn the NFC clock above 33MHz, the controller gives errors. Inspecting read/write buffers was showing the 2nd word as failing. The ECC stops here and the rest of the buffer is fine.

Also, if it is still passing and you have patches can you supply them and so I can retry on my hardware? Perhaps the silicon revision maters? This should tell if it is my code with an issue or not.

Thanks,

Bill Pringlemeir.

Edit: Below is a sample session from an initramfs to test an MTD.

# cd /lib/modules
# ls
drwxr-xr-x 2 0 0     0 .
drwxr-xr-x 4 0 0     0 ..
-rwxr-xr-x 1 0 0  8511 mtd_nandecctest.ko
-rwxr-xr-x 1 0 0 12970 mtd_speedtest.ko
-rwxr-xr-x 1 0 0 13878 mtd_subpagetest.ko
-rwxr-xr-x 1 0 0 12640 mtd_nandbiterrs.ko
-rwxr-xr-x 1 0 0 16479 mtd_oobtest.ko
-rwxr-xr-x 1 0 0  9593 mtd_readtest.ko
-rwxr-xr-x 1 0 0 13869 mtd_pagetest.ko
-rwxr-xr-x 1 0 0  9826 mtd_stresstest.ko
# insmod ./mtd_pagetest.ko dev=1

=================================================
mtd_pagetest: MTD device: 1
mtd_pagetest: MTD device size 8388608, eraseblock size 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB size 64
mtd_test: scanning for bad eraseblocks
mtd_test: scanned 64 eraseblocks, 0 are bad
mtd_pagetest: erasing whole device
mtd_pagetest: erased 64 eraseblocks
mtd_pagetest: writing whole device
mtd_pagetest: written up to eraseblock 0
mtd_pagetest: written 64 eraseblocks
mtd_pagetest: verifying all eraseblocks
mtd_pagetest: verified up to eraseblock 0
mtd_pagetest: verified 64 eraseblocks
mtd_pagetest: crosstest
mtd_pagetest: reading page at 0x0
mtd_pagetest: reading page at 0x7ff800
mtd_pagetest: reading page at 0x0
mtd_pagetest: verifying pages read at 0x0 match
mtd_pagetest: crosstest ok
mtd_pagetest: erasecrosstest
mtd_pagetest: erasing block 0
mtd_pagetest: writing 1st page of block 0
mtd_pagetest: reading 1st page of block 0
mtd_pagetest: verifying 1st page of block 0
mtd_pagetest: erasing block 0
mtd_pagetest: writing 1st page of block 0
mtd_pagetest: erasing block 63
mtd_pagetest: reading 1st page of block 0
mtd_pagetest: verifying 1st page of block 0
mtd_pagetest: erasecrosstest ok
mtd_pagetest: erasetest
mtd_pagetest: erasing block 0
mtd_pagetest: writing 1st page of block 0
mtd_pagetest: erasing block 0
mtd_pagetest: reading 1st page of block 0
mtd_pagetest: verifying 1st page of block 0 is all 0xff
mtd_pagetest: erasetest ok
mtd_pagetest: finished with 0 errors
=================================================
#

On a system clocked over 33MHz, this gives me errors. You may wish several MTD partitions as the errors are large. For example, adding mtdparts=NAND:256k(loader),8M(boot0),8M(boot1),-(root) to bootargs will give a small 256k mtd0 which is good as the kernel log will be large if the problem occurs for you. Above, I tested an 8M partition.

Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Tue, 14 Jan 2014 22:30:55 GMT

Hello Bill,

I set CONFIG_SYS_CLKCTRL_CSCDR2 to 0x30114210 and CONFIG_SYS_CLKCTRL_CSCDR3 to 0x00003F1F, which had a total divisor of 4. I can try with a total divisor of 2 (eg change CONFIG_SYS_CLKCTRL_CSCDR2 to 0x30114200). I will change fsl_nfc_check_ecc_status() and try compiling and running the mtd tests, and let you know what the results are. I will supply patches once I have completed running the tests as well.

Thanks,

Timesys Support

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Wed, 15 Jan 2014 00:06:57 GMT

Edit: As per above, the '/3' is actually '/4' or 33MHz. I changed the CSCDR2 from 0x??????3? to 0x??????2? and the TimeSys 3.0 Linux NFC also starts to fail in hardware ECC mode for me.

Sorry, I don't know if you saw my post. It went to a moderator. I have altered the mainline u-boot to setup the clocks for the TimeSys 3.0 Linux NFC and I set the clock to divide by 3 and it still seems to work! With Linux 3.13+, I can print-out the clock tree and the platform bus clock is 133MHz. I am not 100% sure what the platform bus clock is for your case. But a divide by four of 133MHz gives ~33MHz. However, I haven't seen any issue with the TimeSys 3.0 version of the driver running at /3 bus speed (should be 44Mhz). I get some marginal increases with speedtest,^{Preceding information is wrong.}

stock -> 2053kb/S read and 4023 kb/S write.

/3/4hw -> 2265kb/S read and 4654 kb/S write

/3/4sw -> 2570kb/S read and 4457 kb/S write.

This with the TimeSys 3.0 nfc driver. The clock does increase the speed marginally.

I am still investigating what else is different between the drivers. My code does work until the clock goes above 33Mhz and the the hardware ECC signals error on reads. With Software ECC, I can run at 66Mhz without errors with the updated driver. It must be some sort of race in the driver if it is software related. The TimeSys driver is running about 4x slower due to the software structure.

The controller doesn't support running above 80Mhz; make sure you don't exceed that.

Re: Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Thu, 16 Jan 2014 17:06:45 GMT

Hi Bill,

After making the attached modifications to u-boot (platform clock divider = 3) and Linux, and setting CONFIG_MTD_NAND_FSL_NFC_SWECC=n in the kernel configuration, I was able to run mtd_pagetest successfully. I also tried booting from a jffs2 image in NAND. There are a number of 'ECC failed to correct all errors!' messages printed to console, but system appears to be functional.

Thanks,

Timesys Support

Re: VF6xxx NFC (NAND) module clocking

billpringlemeir — Thu, 16 Jan 2014 18:42:21 GMT

Can you retry with CSCDR3 as 0x00000F1F 0x1F1F? We currently have 0x00003F0F and both must have mis-read the data sheet. Maybe I mis-read it and you just followed my mistake...;your patches clued me in. Anyways, I don't think we have had the clock set to >33Mhz with the TimeSys 3.0 code. I have a u-boot set this way and I get failures now with the 3.0 code.

A few 'ECC fail...' are normal as when code reads an erased page, there is no ECC bytes in the OOB (extra area).

So, originally, the clock was running at /20 of 133Mhz or ~6.5Mhz. I also confirmed that the platform bus clock seems to be 133Mhz (at least in my setup). I enable CLK_DEBUG and patched the mach-mvf/clock.c,

+++ b/arch/arm/mach-mvf/clock.c
@@ -1956,11 +1956,13 @@ int __init mvf_clocks_init(unsigned long ckil, unsigned long osc,
 
        apll_base = MVF_IO_ADDRESS(MVF_ANATOP_BASE_ADDR);
 
-       for (i = 0; i < ARRAY_SIZE(lookups); i++)
-               clkdev_add(&lookups[i]);
-
        clk_tree_init();
 
+       for (i = 0; i < ARRAY_SIZE(lookups); i++) {
+               clkdev_add(&lookups[i]);
+               clk_debug_register(lookups[i].clk);
+       }

Do a mount -t debugfs debugs /sys/kernel/debug and there are then files in /sys/kernel/debug/clock which have the clock rates as Linux sees things.

Edit: I did read the data sheet correctly the first time. Bits 13-15 in CSCDR3 are the NFC_PRE_DIV. I was thinking Bits 12-15 when I wrote the striked out text above.

Re: VF6xxx NFC (NAND) module clocking

timesyssupport — Tue, 21 Jan 2014 00:34:22 GMT

Hi Bill,

I made the above modifications to the Linux 3.0 kernel to see what the platform bus clock rate is. Unfortunately, this is just hard-coded in the kernel source (in the

_clk_periph_get_rate() function in clock.c, as 132MHz), so it is not giving a true glimpse of the clock rate.

After re-running mtd_pagetest with CSCDR2 = 0x30114220 and CSCDR3 = 0x00001F1F set in u-boot (nfc clock divider of 3), I too am getting numerous errors (mtd_pagetest: error: verify failed at 0x*),

so this does not appear to be a bootloader/kernel specific issue. Also, when setting the NFC clock divider <=3, this causes u-boot 2011.12 to not recognize the NAND flash controller: It is recognized in Linux, however, which made it possible to run mtd_pagetest.

Thanks,

Timesys Support