I have an OMAP3630/DM3730 device and I am trying to attach a NOR chip to the device tree. I can get the bootloader to read the NOR chip, I can erase the NOR chip, and I can sometimes write large data to it, but it's very inconsistent. I have tested these GPMC timings with a bootloader, and it ran for 5 days at extreme temperature and I was able to write data, read data and compare the MD5SUM of the entire NOR chip (16MB) and it was successful. However, under linux, it's not reliable. The GPMC timings are as follows: [ 0.276214] cs2 GPMC_CS_CONFIG1: 0x00211200 [ 0.276214] cs2 GPMC_CS_CONFIG2: 0x000a1302 [ 0.276245] cs2 GPMC_CS_CONFIG3: 0x000f1302 [ 0.276245] cs2 GPMC_CS_CONFIG4: 0x0a021303 [ 0.276245] cs2 GPMC_CS_CONFIG5: 0x00120f18 [ 0.276275] cs2 GPMC_CS_CONFIG6: 0x0a030000 [ 0.276275] gpmc cs2 access configuration: [ 0.276275] gpmc,mux-add-data = <2>; [ 0.276306] gpmc,device-width = <2>; [ 0.276306] gpmc,wait-pin = <1>; [ 0.276306] gpmc,wait-on-write = <1>; [ 0.276336] gpmc,burst-length = <4>; [ 0.276336] gpmc cs2 timings configuration: [ 0.276367] gpmc,cs-on-ns = <10>; /* 6 ns - 10 ns; 2 ticks */ [ 0.276367] gpmc,cs-rd-off-ns = <95>; /* 91 ns - 95 ns; 19 ticks */ [ 0.276397] gpmc,cs-wr-off-ns = <50>; /* 46 ns - 50 ns; 10 ticks */ [ 0.276397] gpmc,adv-on-ns = <10>; /* 6 ns - 10 ns; 2 ticks */ [ 0.276397] gpmc,adv-rd-off-ns = <95>; /* 91 ns - 95 ns; 19 ticks */ [ 0.276428] gpmc,adv-wr-off-ns = <75>; /* 71 ns - 75 ns; 15 ticks */ [ 0.276428] gpmc,oe-on-ns = <15>; /* 11 ns - 15 ns; 3 ticks */ [ 0.276458] gpmc,oe-off-ns = <95>; /* 91 ns - 95 ns; 19 ticks */ [ 0.276458] gpmc,we-on-ns = <10>; /* 6 ns - 10 ns; 2 ticks */ [ 0.276489] gpmc,we-off-ns = <50>; /* 46 ns - 50 ns; 10 ticks */ [ 0.276489] gpmc,rd-cycle-ns = <120>; /* 116 ns - 120 ns; 24 ticks */ [ 0.276519] gpmc,wr-cycle-ns = <75>; /* 71 ns - 75 ns; 15 ticks */ [ 0.276519] gpmc,access-ns = <90>; /* 86 ns - 90 ns; 18 ticks */ [ 0.276550] gpmc,page-burst-access-ns = <0>; /* 0 ns - 0 ns; 0 ticks */ [ 0.276550] gpmc,bus-turnaround-ns = <0>; /* 0 ns - 0 ns; 0 ticks */ [ 0.276550] gpmc,cycle2cycle-delay-ns = <0>; /* 0 ns - 0 ns; 0 ticks */ [ 0.276580] gpmc,wait-monitoring-ns = <0>; /* 0 ns - 0 ns; 0 ticks */ [ 0.276580] gpmc,clk-activation-ns = <0>; /* 0 ns - 0 ns; 0 ticks */ [ 0.276611] gpmc,wr-data-mux-bus-ns = <15>; /* 11 ns - 15 ns; 3 ticks */ [ 0.276611] gpmc,wr-access-ns = <50>; /* 46 ns - 50 ns; 10 ticks */ I am able to erase this and mount it with jffs2, however when I attempt to write a 14MB file to teh 16MB partition, I get the following error, and I must reboot the system. On an earlier kernel (3.0), I found the GPMC timeout was causing a problem, but I am not sure how to disable or change the GPMC timeout or if it's even the same error. I am not sure how much information is useful, and I don't want to paste the whole dump, but I was hoping someone might have some insight on the cause. # cp rand /mnt/jff2-nor/ [ 154.894622] Unhandled fault: external abort on non-linefetch (0x1008) at 0xd10f882c [ 154.902648] pgd = ce30c000 [ 154.905487] [d10f882c] *pgd=8e1e1811, *pte=10f78653, *ppte=10f78453 [ 154.912048] Internal error: : 1008 [#1] SMP ARM [ 154.916778] Modules linked in: [ 154.919982] CPU: 0 PID: 132 Comm: cp Not tainted 4.14.0-00002-g62ee9fd-dirty #2 [ 154.927642] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 154.934173] task: ce3500c0 task.stack: cd854000 [ 154.938934] PC is at chip_ready+0x44/0x78 [ 154.943115] LR is at get_chip+0x238/0x310 [ 154.947296] pc : [<c058c380>] lr : [<c058ddf4>] psr: 600a0013 [ 154.953857] sp : cd855a58 ip : 00000000 fp : ffffc7b5 [ 154.959320] r10: ce1d349c r9 : ce1d4f40 r8 : 00000007 (snip) [ 155.387115] 5fe0: b6e5eab0 be873ab4 00019d34 b6e5eabc 600a0010 00000004 00000000 00000000 [ 155.395690] [<c058c380>] (chip_ready) from [<c058ddf4>] (get_chip+0x238/0x310) [ 155.403259] [<c058ddf4>] (get_chip) from [<c05900d8>] (cfi_amdstd_write_buffers+0x180/0x7f8) [ 155.412078] [<c05900d8>] (cfi_amdstd_write_buffers) from [<c0581d4c>] (mtd_writev+0x94/0xe4) [ 155.420898] [<c0581d4c>] (mtd_writev) from [<c03c592c>] (jffs2_flash_writev+0x2c4/0x4a4) [ 155.429382] [<c03c592c>] (jffs2_flash_writev) from [<c03bc3fc>] (jffs2_write_dnode+0x150/0x3fc) [ 155.438476] [<c03bc3fc>] (jffs2_write_dnode) from [<c03bce20>] (jffs2_write_inode_range+0x334/0x3dc) [ 155.448028] [<c03bce20>] (jffs2_write_inode_range) from [<c03b73e4>] (jffs2_write_end+0x16c/0x344) [ 155.457397] [<c03b73e4>] (jffs2_write_end) from [<c020f72c>] (generic_perform_write+0x108/0x1a0) [ 155.466583] [<c020f72c>] (generic_perform_write) from [<c0211d50>] (__generic_file_write_iter+0x104/0x1bc) [ 155.476684] [<c0211d50>] (__generic_file_write_iter) from [<c0211f7c>] (generic_file_write_iter+0x174/0x250) [ 155.486968] [<c0211f7c>] (generic_file_write_iter) from [<c0271ab4>] (__vfs_write+0xd0/0x120) [ 155.495880] [<c0271ab4>] (__vfs_write) from [<c0271b44>] (__kernel_write+0x40/0xd0) [ 155.503906] [<c0271b44>] (__kernel_write) from [<c02a3d70>] (write_pipe_buf+0x3c/0x54) [ 155.512176] [<c02a3d70>] (write_pipe_buf) from [<c02a414c>] (__splice_from_pipe+0x60/0x198) [ 155.520904] [<c02a414c>] (__splice_from_pipe) from [<c02a4940>] (splice_from_pipe+0x58/0x70) [ 155.529724] [<c02a4940>] (splice_from_pipe) from [<c02a49a0>] (default_file_splice_write+0x20/0x44) [ 155.539184] [<c02a49a0>] (default_file_splice_write) from [<c02a30ec>] (direct_splice_actor+0x38/0x44) [ 155.548919] [<c02a30ec>] (direct_splice_actor) from [<c02a38b0>] (splice_direct_to_actor+0xc8/0x238) [ 155.558471] [<c02a38b0>] (splice_direct_to_actor) from [<c02a3aac>] (do_splice_direct+0x8c/0xb8) [ 155.567657] [<c02a3aac>] (do_splice_direct) from [<c0271348>] (do_sendfile+0x19c/0x314) [ 155.576019] [<c0271348>] (do_sendfile) from [<c02725cc>] (SyS_sendfile64+0x104/0x130) [ 155.584228] [<c02725cc>] (SyS_sendfile64) from [<c0107aa0>] (ret_fast_syscall+0x0/0x48) Thank you, adam -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
