Showing results for 
Search instead for 
Did you mean: 
Honored Contributor I

Issue with 16-bit CFI Flash



We use a CFI Flash with 16 bits of data width on our board (JS28F256) 

And we use nios2-linux (kernel version 2.6.30) to read/write on it. 


We know that the Linux version works well with 8-bit CFI Flash (same manufacturer) because we have an other board with a 8-bit flash running the same linux version. And reading/writing on CFI Flash works well. 


However with our 16-bit CFI Flash there are some problems. What I noticed : 

- Writing on the flash is successful (I try with a very small JFFS2 filesystem : just one text file) 

- this filesystem starts with the magic number 0x1985 but when I read back the flash (using hexdump on the board) I have the following : 

0000000 1919 2020 0000 0000 b0b0 e4e4 1919 e0e0 0000010 0000 0000 0909 c5c5 0000 0000 0000 0000So I have 0x1919 instead of 0x1985 


Obviously when I try to mount the partition : 

mount -t jffs2 /dev/mtdblock2 /mnt/config/ MTDSB: dev_name "/dev/mtdblock2" MTDSB: lookup_bdev() returned 0 MTDSB: New superblock for device 2 ("config/jffs2") jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x1919 instead jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000008: 0xb0b0 insteadSo I think there is an issue somewhere (in the mtd driver maybe) that does not allow to handle 16-bit cfi flash. 

I ran also : "nios2-flash-programmer -B 0x400000+100 -R mtd2 --base=0x08000000" to see what is really written to the Flash and I have the following : 

S2244000001919202000000000B0B0E4E41919E0E0000000000909C5C5000000000000000073 S2244000200000000049494E4E080800001C1C2E2EA1A1E4E47070FFFF1919E0E000000000CF So it really seems that 0x1919 is really written to the Flash (not an issue while reading) 


Some details : 

- I tryed to write on flash using : "dd", "flashw", "cp" : none is able to give a good result 

- I tryed to disable 8-bit bus width in the kernel : 

Specific CFI Flash geometry selection Support 8-bit buswidth (NEW) Support 16-bit buswidth (NEW) But doing this the kernel hangs :  

Altera Triple Speed MAC IP Driver(v8.0) developed by SLS,August-2008,--Linux 2.6.27-rc3 physmap platform flash device: 02000000 at 08000000 BUG: failure at /mtd/maps/ Kernel panic - not syncing: BUG!- The FPGA is able to load its bitstream from this CFI Flash at startup : so it is not an Hardware issue. I use nios2-flash-programmer to load this bitstream or Altera flash programmer GUI. 


I notice also that if I write the filesystem by using : 

- bin2flash --input=config.jffs2 --location=0x400000 --output=config.flash 

- nios2-flash-programmer --base=0x08000000 config.flash 

I can mount the filesystem in Linux but I have many errors on logs : 

physmap-flash.0: block erase error: (bad command sequence, status 0xb0) Erase at 0x00100000 failed immediately: errno -22I can list the file inside my filesystem but I can't "cat" it : 

cat /mnt/config/ip Node CRC 00b000b0 != calculated CRC f07afde7 for node at 00000038 Node CRC 00b000b0 != calculated CRC f07afde7 for node at 00000038Best regards
0 Kudos
1 Reply
Honored Contributor I

Ok I found the solution. 

In linux-2.6/arch/nios2/kernel/config.c you can find : 


static struct physmap_flash_data nios2_flash_data = { # if defined(CONFIG_ALTERA_NEEK_C3) || defined(CONFIG_ALTERA_CYCLONE_III) .width = 2, /* 16 bits data bus # else .width = 1, /* 8 bits data bus */ # endif But my config is not CONFIG_ALTERA_NEEK_C3 nor CONFIG_ALTERA_CYCLONE_III. 

So I just force the width to be 2 


This type of bug will not happen with the latest kernel that use device-tree, hopefully ! 


Best regards