- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
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
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page