Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.

Issue with 16-bit CFI Flash

Altera_Forum
Honored Contributor II
915 Views

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 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
Altera_Forum
Honored Contributor II
134 Views

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
Reply