Debug the tffs File System of VxWorks in S3C2440

With the bcng2440 Development Board, the Board is configured with the flash of am29lv160db.
Objective: To implement the tffs File System under VxWorks.
2007-1-16
1. Use the latest BSP to build a new project, add tffs support and tffs show support to the VxWorks configuration options, and re-compile the kernel, it is found that a new effecffs is automatically copied in the BSP directory. c file, and then report the compilation error,
E: \ tornado2.2 \ target \ config \ bcng2440 \ effecffs. C: 116: 69: # error "effecffs: Verify system Mac
Ros and function before first use"
I don't know what the error macro is for, so I have to delete this sentence.
Oh, let the first compilation be prone to errors and remind you to make various macro definitions,
No matter how many things, change the address
# Define flash_base_adrs 0x00000000
Re-compile, successful, download, the results are as follows:
-> Tffsshow
0: ***** communication failed with error-1 ****
Value = 48 = 0x30 = '0'
-> Tffsshowall
Tffs Version 2.2
0: ***** communication failed with error-1 ****
Value = 48 = 0x30 = '0'
Copy the wamdmtd. C program in the original code to the BSP directory, add the modification file in the project, re-compile the kernel, and The. h file is not found. Then modify the file:
# Include "tffs/flflash. H"
# Include "tffs/backgrnd. H"
Can be compiled, code modified at the same time, and support for our flash is added,
# Define am29lv160_flash 0x0149/* added by xiyong */
Vol. type = am29lv160_flash)
Re-compile, download, error, in
After further tracking, we found that the flwamdmtdidentify function was not entered at all:

Change wamdmtd. C to ximtd. c
Modify flwamdmtdidentify to xyflwamdmtdidentify and
Mtdidentifyroutine mtdtable [] =
# Ifdef include_mtd_wamd
Xyflwamdmtdidentify,
# Endif
Even so, xyflwamdmtdidentify is not called.
How can tffs call its own flash read/write function? Does it already have a library in the default, to call the default library.
 
Later, we found that wamd is not supported in the VxWorks Kernel configuration, and wamd is not supported in ipvffs. Otherwise, the system will crash.
It is further confirmed that if the name is not changed to xyflwamdmtdidentify, it will also crash. It seems that all interface functions in ximtd. C need to be renamed.
 
2. Summarize the current situation

1) makefile in the BSP directory contains ximtd. o
Mach_extra = ximtd. o
2) added the FFS. c file.
# Define include_mtd_am29lv160
Remove other flash drivers
3) tffsconfig. c file modification
Flstatus xyflwamdmtdidenvol (flflash vol );
Declare and modify the Function
Mtdidentifyroutine mtdtable [] =
# Ifdef include_mtd _ am29lv160
Xyflwamdmtdidentify,
# Endif
4) ximtd. c file modification
# Define am29lv160_flash 0x0149/* added by xiyong */
Flstatus xyflwamdmtdidenvol (flflash vol)
{......
Vol. type = am29lv160_flash)/* xiyong add here */
Vol. chipsize = 0x200000l * vol. interleaving;
5) regenerate the VxWorks kernel,
Remove the MMU configuration, add tffs, FTL, tffsshow and other components, compile and download, and the current phenomenon is:
Xiyong Debug: tffsshowallaa
-> Tffs Version 2.2 noofdrives 1
Xiyong Debug: flwamdmtdidentify
Xiyong Debug: flwamdmtdiden1_vol. type is 49
0: ***** communication failed with error-1 ****
Finally, I called my function.
The problem is that there is a problem with Flash ID reading. I should have read 0x0149, but now it's a high position and it's gone.
 
3. Continue debugging

2007-1-18
Using the previous 8260 amd code, we found that
Vol. interleaving = 2 needs to be changed to 1
It can be displayed now
-> Tffsshowall
Xiyong Debug: tffsshowallaa
Tffs Version 2.2 noofdrives 1
0: Socket = RFID: TYPE = 0x149, unitsize = 0x10000, mediasize = 0x200000
Value = 49 = 0x31 = '1'
But run
Tffssysformat crashes
After repeated debugging, it is found that the interruption needs to be disabled in both erasure and write operations.
-> Effecffsformat
Debug: 5 entering amd MTD identification routine.
Debug: identified AMD or Fujitsu Flash Media.
Debug: 5 entering amd MTD identification routine.
Debug: identified AMD or Fujitsu Flash Media.
Debug: Entering amd MTD flwamdmtderase routine firstblock 8 numofblocks 1.
Debug: flwamdmtderase flash PTR 80000
Debug: amd mtd flwamdmtderase end.
Debug: Entering amd MTD flwamdmtdwrite routine address 80000 length 4C.
Debug: 2 flwamdmtdwrite routine unlockaddr1 80aaa unlockaddr2 80554 data is 13 3 43 49 53
46 30 0 46 54
Debug: Entering amd MTD flwamdmtdwrite routine address 80014 length 2.
Debug: 2 flwamdmtdwrite routine unlockaddr1 80aaa unlockaddr2 80554 data is 8 0 0 0 8 0 0
0 7C F4
Debug: Entering amd MTD flwamdmtderase routine firstblock 9 numofblocks 1.
Debug: flwamdmtderase flash PTR 90000
Debug: amd mtd flwamdmtderase end.
Debug: Entering amd MTD flwamdmtdwrite routine address 90000 length 4C.
Debug: 2 flwamdmtdwrite routine unlockaddr1 90aaa unlockaddr2 90554 data is 13 3 43 49 53
46 30 0 46 54
Debug: Entering amd MTD flwamdmtdwrite routine address 90014 length 2.
Debug: 2 flwamdmtdwrite routine unlockaddr1 90aaa unlockaddr2 90554 data is 9 0 FF 33 9 0
0 0 7C F4
.............
Debug: Entering amd MTD flwamdmtdwrite routine address 800fc length 4.
Debug: 2 flwamdmtdwrite routine unlockaddr1 80 AAA unlockaddr2 80554 data is Fe FF 4
0 2a 0 0 2E 4
Debug: Entering amd MTD flwamdmtdwrite routine address 85c00 length 200.
Debug: 2 flwamdmtdwrite routine unlockaddr1 80aaa unlockaddr2 80554 data is 0 0 0 0 0 0 0
0 0 0
Debug: Entering amd MTD flwamdmtdwrite routine address 800fc length 4.
Debug: 2 flwamdmtdwrite routine unlockaddr1 80aaa unlockaddr2 80554 data is 40 2a 0 0 40
2a 0 0 2E 4
Value = 0 = 0x0
-> D 0x80000
00080000: 0313 4943 4653 0030 5446 314c 3030 0100 *... cisf0.ftl100 ..*
00080010: 0001 0000 0008 1009 0008 3a00 0018 *.............:..*
00080020: 0000 0001 0017 ff00 0000 0000 0000 *................*
00080030: 0044 0000 FFFF * D ...............*
00080040: FFFF 0030 0000 0030 d240 FFFF * ...... 0 ...... 0 ...@...*
00080050: d440 FFFF d640 FFFF d840 FFFF da40 FFFF *@...@...@...@...*
00080060: dc40 FFFF de40 FFFF e040 FFFF e240 FFFF *@...@...@...@...*
00080070: E440 FFFF e640 FFFF e840 FFFF EA40 FFFF *@...@...@...@...*
00080080: ec40 FFFF ee40 FFFF f040 FFFF f240 FFFF *@...@...@...@...*
00080090: f440 FFFF f640 FFFF f840 FFFF fa40 FFFF *@...@...@...@...*
000800a0: fc40 FFFF fe40 FFFF 0040 0000 0240 *@...@...@...@...*
000800b0: 0440 0000 0640 0000 0840 0a40 0000 *@...@...@...@...*
000800c0: 0c40 0000 0e40 0000 1040 0000 1240 *@...@...@...@...*
000800d0: 1440 0000 1640 0000 1840 1a40 0000 *@...@...@...@...*
000800e0: 1c40 0000 1e40 0000 2040 0000 2240 *@...@...@..@"..*
000800f0: 2440 0000 2640 0000 2840 2a40 0000 * @ $ ..@&..@(..@*..*
Value = 0 = 0x0
-> Usrtffsconfig (0, 0, "/tffs0 /");
Debug: 5 entering amd MTD identification routine.
Debug: identified AMD or Fujitsu Flash Media.
Value = 0 = 0x0
-> Devs
DRV name
0/null
1/Tyco/0
1/Tyco/1
5 bcng:
6/Vio
3/tffs0/
Value = 0 = 0x0
->
 
For the arm cpu, flash operations must be disabled,
This problem was not found in the past on powerpc.
 
4. tffs debugging of MMU

2007-1-19
The base address of Flash is changed to 0xf0000000, and tffsshow is called to report an error;
First, modify the Flash. C application testing program. The following problems are encountered:

1)
# DEFINE _ WR (ADDR, data) * (*) (flashbaseaddr + (ADDR <1) = () data
# DEFINE _ RD (ADDR) (*) (flashbaseaddr + (ADDR <1 ))))
Add a base address, but the base address cannot be moved left. Otherwise, an error is returned;
It is found that it can only be read but not written. In syslib. C, Flash is defined as not writable. Open it.

2) at this time, we found that tffs under MMU has been implemented.
 
Now there is a problem: the BSP in bootrom defines the flash base address as 0, while the BSP defines 0xf0000000 in VxWorks;
In fact, VxWorks does not need to start tffs unless it is self-updating.