Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Issue with 16-bit CFI Flash

Hello,

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 0000
So 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 instead
So 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 -22
I 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 00000038
Best regards

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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