1. VxWorks Loading
1.1 load from the tffs File System
Tornado trueffs is a m-systems Flite implementation method compatible with VxWorks. It provides a unified block device interface for a wide variety of flash storage devices, it also features reentrant and thread security and supports most popular CPU architectures. With tornado trueffs, applications read and write to flash storage devices as if they operate on disk devices that own MS-DOS file systems. As shown in 18, trueffs consists of the core layer and three functional layers: the translation layer, MTD layer, and socket layer. {
Window. Open ("http://blog.51cto.com/viewpic.php? Refimg = "+ this. SRC)
} 'Src = "http://img1.51cto.com/attachment/201003/13/109393_1268462998O8av.jpg" border = "0" alt = "clip_image002" Height = "100"> figure 18 trueffs layer structure layout core layer (core layer ): the core layer is mainly used to connect to other layers. At the same time, it can also be used for debris collection, timer and maintenance of other system resources. Generally, WinDriver provides this part of the content as a binary file. The Translation Layer provides advanced interaction between trueffs and dosfs. It also includes the Intelligent Processing functions required to control the ing of flash to blocks, wear-leveling, fragment collection, and data integrity. There are currently three different Translation Layer modules available. Which layer to choose depends on whether the Flash Media you use adopts the nor-based, NAND-based, or ssfdc-based technology. The socket layer provides interfaces for trueffs and card hardware (such as flash cards. Its name comes from the physical slots that users can insert into flash cards. It is used to register a socket device to the system, Detect Device plugging, hardware write protection, and so on. The functions are described in detail later. The MTD layer (memory technology drivers) function is mainly used to implement read, write, erase, ID Recognition and other drives for specific flash, and set parameters closely related to flash. Trueffs already contains MTD-layer drivers that support Intel, AMD, and Samsung flash chips. New chips require new MTD support. You can use a standard interface to add these drivers. In the above four parts, we usually need to work on the last two layers.
Mx29lv160bt
Build trueffs on the chip
File System1. The configuration file is here. Taking nor flash mx29lv160bt as an example, the development tool is tornado2.2 for PPC. To include the trueffs File System in the VxWorks image, you must first define include_tffs In the config. h file. This allows the VxWorks initialization code to call tffsdrv () to create the structure and global variables required to manage trueffs, and register the socket component driver for all mounted flash devices. During the link, the necessary software modules of trueffs can be linked to the VxWorks image by parsing the symbols associated with tffsdrv. To support trueffs, each BSP directory must contain a javasffs. c file. It links all trueffs layers (Translation Layer, socket layer and MTD layer) together and binds them to VxWorks. Therefore, you must edit the file and decide which MTD and Translation Layer module should be included in trueffs. That is: # define logs/* mx29lv160bt MTD driver */# define logs/* FTL Translation Layer */# define flash_base_adrs 0x2a10000/* flash memory base address */# UNDEF flash_size # define flash_size 0x001f0000/ * flash memory size, 2 m (parameter block) */other unrelated MTD driver containing headers # UNDEF drop, and define the base address and size of flash in the system. In addition, you must edit the sysphysmemdesc [] array in syslib. C and add the flash base address and size to MMU for future flash access. Otherwise, flash access will fail. If there is no javasffs. c file in the BSP directory, we can copy one from the other BSP directory and then make the above modifications. Other contents can be basically not modified. Next, we need to modify the tffsconfig. c file. To facilitate management, we usually copy the file under the src/drv/tffs/directory to our BSP directory, and then make changes. Add the following statement to the mtdidentifyroutine mtdtable [] Table: # ifdef include_mtd_mx29lv mx29lvmtdidentify, # endif/* include_mtd_mx29lv */and declare it at the beginning of the file. # Ifdef include_mtd_mx29lv flstatus mx29lvmtdidenvol (flflash vol); # endif/* include_mtd_mx29lv */Add our flash-related MTD driver to makefile. That is: mach_extra = mx29lvmtd. o to facilitate MTD driver debugging, before re-compiling the VxWorks image, the necessary functions such as formatting flash, creating a trueffs block device, and binding this block device to dosfs should be included in the VxWorks image. For example: # define attributes # ifdef include_tffs # define attributes # define include_dosfs/* dosfs File System */# define attributes/* Show routines for system facilities */# define attributes # define include_io_system # define include_disk_util # endif/* include_dosfs */2. after completing the above configuration, the MTD driver enters the VxWorks operating system and uses the tffsshow tool on the shell to display flash information. The tffsshow function will eventually call the mx29lvmtdidentiy () function in the MTD driver. In the mx29lvmtdidentiy () function, the device and vendor ID of the mx29lv160bt chip are read to identify the function, then initialize the flflash structure members. The main parameters are: Type: The jedec id of the flash memory; erasableblocksize: the size of the erased block (in bytes) of the flash memory ). Interleaving should be taken into account when setting this value. Therefore, the following method is usually used to set the size; vol. erasableblocksize = mx29lv_mtd_sector_size * vol. interleaving; For mx29lv160bt, mx29lv_mtd_sector_size is 64 K bytes; chipsize: the actual flash size (in bytes) used to build the trueffs file system; noofchips: the actual flash quantity used to build the trueffs file system; interleaving: interleaving factor ). That is, the number of devices that expand the data bus. For example, on a 32-bit data bus, we can use four 8-bit or two 16-bit devices; Map: point to the flash memory ing (MAP) function. This function maps flash to the memory area; read: refers to the READ function of flash memory. In the MTD-driven recognition function, this member function has been initialized as the default read function. In general, we do not need to initialize it, otherwise we need to modify many related functions; write: Write function pointing to flash memory. This member must be initialized. This is an important task. Erase: the erasure function pointing to the flash memory. This member must be initialized, which is also an important task. For flflash structure members, the two functions we care about are write and erase functions. The mx29lvmtdidentiy () function must be defined as vol. Write = mx29lvwrite; vol. Erase = mx29lverase; In mx29lvwrite () function, data must be written to flash. First, you must unlock the slice and write the write command before writing data. Finally, you need to determine whether the data has been written. To ensure the operation is successful, we should compare the data after writing each data and perform the next data operation only after the data is correct. In mx29lverase (), the flash sector is erased. Flash is usually erased by sector. Before the erasure operation, you should first unlock the slice, and then write the command to erase the establishment and sector erasure. The content in Flash should be 0 xFFFF. Therefore, to ensure the operation is successful, we should make a comparison after the erasure. After the comparison is correct, we can proceed to the erasure operation for the next sector. Otherwise, an erasure error mark will be returned. Therefore, the MTD driver debugging is basically debugging the write and erase functions. During the debugging process, we can add print statements to the corresponding positions of the two functions for debugging. To debug these two functions, we enter the tffsdevformat command on the shell to format the Flash. tffsdevformat will eventually call the mx29lverase and mx29lvwrite functions. If the two functions are successful, 0 is returned. Otherwise,-1 is returned. Of course, you can also call the tffsdevcreate function to verify the correctness of our write and erase functions. Figure 19 illustrates the call process of tffsdevcreate. {
Window. Open ("http://blog.51cto.com/viewpic.php? Refimg = "+ this. SRC)
} 'Src = "http://img1.51cto.com/attachment/201003/13/109393_1268463002nYIk.jpg" border = "0" alt = "clip_image004" Height = "160"> Figure 19 tffsdevcreate () The call process verifies mx29lvmtdidentiy on the shell using tffsshow. & Gt; tffsshow0: Socket = PGA: TYPE = 0x2249, unitsize = 0x10000, mediasize = 0x1f1_value = 49 = 0x31 = "1" indicates that the mx29lv160bt device is correctly identified and the device number is 0x2249.
Create tffs
Device1. After the MTD driver is successfully debugged, we can connect the DOS device name to the flash device, as shown in the following figure: Format: & gt; tffsdevformat
Value = 1
& Gt; usrtffsconfig 0, "/tffs0"
Value = 0
View the mounted device name through Devs: & gt; Devs
DRV name
0/null
1/Tyco/0
1/Tyco/1
5 Host:
6/PtY/rlogin. s
7/PtY/rlogin. m
3/tffs0/
8/Vio
Value = 25 = 0x19. If/tffs0/indicates that the mounted device has been successfully mounted, you can use the dosfs file system commands to operate flash. Such as LS and copy. Use code to complete the above process: Status flashinit (void) {status rc = OK; If (tffsdrv ()! = OK) {printf ("cocould not initialize. /n "); Return (error) ;}# if 0 printf (" attaching to flash file system... "); # endifdosfsinit (num_dosfs_files);/* initialize DOS-FS */If (usrtffsconfig (drivenumber1, 0, sys_base_fs) = Error) {printf ("/ncore file system not exist. /n "); rc = effecffsformat (0, 0, 0, 0, sys_base_fs, 0, 0);} return RC;} The effecffsformat () in the above Code calls tffsdevformat () format, for example, tffsdevformat (drivenumber, (INT) Params); Params is the tffsdevformatparams struct pointer, that is, the formatting parameter, such as: # define tffs_format_param_with_room_for_config_word/{1, 99, 1, 0x0000l, null, {0 }, null, 2, 0, null}, ftl_format_if_needed}, while usrtffsconfig () combines tffsdevcreate () and dosfsdevinit (), which is a quick function. 2. start and download the VxWorks image from flash. To download the VxWorks image from flash, first copy the VxWorks image to flash. In the shell, run the copy "VxWorks" command ", "tffs0/VxWorks", and then modify config. in the hfile, the bootstrap line is as follows: # define default_boot_line/"tffs = () Host: /tffs0/VxWorks H = 192.168.0.153 E = 192.168.0.154 u = target PW = target o = CPM "after modification, recompile and generate bootrom_uncmp.bin, and burn it into flash. Restart and you will see the following boot screen: boot device: tffs =
Unit number: 0
Processor number: 0
Host Name: Host
File Name:/tffs0/VxWorks
Inet on Ethernet (e): 192.168.0.154
Host iNet (h): 192.168.0.153
User (u): Target
FTP password (PW): Target
Flags (F): 0x0
Other (o): CPM
Attaching to tffs... done.
Loading/tffs0/VxWorks... 894304
Starting at 0x10000...
Development System
VxWorks version 5.5.1
Kernel: Wind version 2.6
Copyright Wind River Systems, Inc., 1984-2003
CPU: Motorola ads-PowerPC 860. processor #0.
Memory size: 0x1000000. BSP version 1.2/5.
Wdb comm type: wdb_comm_end
Wdb: Ready. At this point, the boot is successful. Flash's entire tffs File System has been established successfully.
In a flash
Upper
Simultaneously loading bootrom
, VxWorks
FileWe map the flash Address into two address segments, one for bootrom, the other for VxWorks, and the other for bootrom for 0xfff00000 ~ 0xfff80000. The IP address segment used for VxWorks is 0x04080000 ~ 0x04800000 (assuming the flash size is 8 Mb), in 0xfff00000 ~ 0xfff80000 address segment is written to bootrom, which is in 0x04080000 ~ 0x04800000 address segment is written to VxWorks. After power-on, the PC pointer will jump to 0xfff00100 address to execute the First Command, boot bootrom, and finally boot the Vxworks system successfully. Implementation process: 1. chip selection (?) In rominit. in the s file, perform the following part Selection: Select 0 as the boot flash Address, and select 1 as the flash Address, where rom_base_adrs is 0xfff00000/* optional /*--------------------------------------------------------*/
/* Initialize chip select 0 for bootrom */
/*-------------------------------------------------------------*/
Lis R5, hiadj (rom_base_adrs | br_ps_8 | br_wp | br_v)
Addi R5, R5, Lo (rom_base_adrs | br_ps_8 | br_wp | br_v)
STW R5, br0 (0) (R4)
Lis R5, hiadj (0xfff80000 | 0x00000100 | 0x00000080)
Addi R5, R5, Lo (0xfff80000 | 0x00000100 | 0x00000080)
STW R5, or0 (0) (R4)
/*--------------------------------------------------*/
/* Initialize chip select 1 for flash */
/*--------------------------------------------------*/
Lis R5, hiadj (0x04000000 | br_ps_16 | 0x00000001)
Addi R5, R5, Lo (0x04000000 | br_ps_16 | 0x00000001)
STW R5, br1 (0) (R4)
Lis R5, hiadj (0xff800000 | 0x00000100 | 0x00000080)
Addi R5, R5, Lo (0xff800000 | 0x00000100 | 0x00000080)
STW R5, or1 (0) (R4) 2. the address is mapped to syslib. the C file contains the sysphysmemdesc address ing array statement. After the boot flash and flash addresses are mapped according to the following address, the VxWorks System will allow you to perform read and write operations on the address. {
(Void X) 0x04000000,
(Void X) 0x04000000,
0x00800000,/* 8 m-flash window 1 */
Vm_state_mask_valid | vm_state_mask_writable,
Vm_state_valid | vm_state_writable
},
{
(Void *) rom_base_adrs,
(Void *) rom_base_adrs,
Rom_size,/* flash memory */
Vm_state_mask_valid | vm_state_mask_writable |
Vm_state_mask_cacheable,
Vm_state_valid | vm_state_writable |
Vm_state_cacheable_not
} 3. there is still a problem with file burning because boot flash can be burned in the burning recorder, while Flash chips are directly welded to the motherboard of the MPC860, you can read and write data only through the Flash Driver. It is not possible to burn data through the recorder. To solve this problem, you can only solve the problem as follows. The bootrom flash block should be retained on the motherboard, and a boot flash chip from boot flash should be provided. The bootrom program that has been installed and can run normally should be included in the boot flash chip, first, add the chip to the bootrom flash seat, power up the system to boot up, and then write bootrom and VxWorks into the flash function in advance to write bootrom and VxWorks files into the corresponding address segment of flash, note that the write address must be correct, that is, the first instruction of bootrom must be written in 0xfff00100 address. After power-off, take the boot flash from the seat. After power-on, the system will boot from flash.
1.2 load from Serial Port
1. Configure config. h file a. Modify default_boot_line to guide the VxWorks image in TSFS (Target Server File System) mode: # define default_boot_line/
"TSFS (0000) Aman:/VxWorks H = 192.168.0.108 E = 192.168.0.67 u = amd PW = Tn = snds100"
B. If include_end is defined, # UNDEF will drop it. C. Block the original serial port settings. If there are two available serial ports, add the following Configuration: ―――――――――――――――――――――――――――――――――――
/* Serial port configuration */
# Define include_serial # UNDEF console_tty
# Define console_tty 1/* console channel */
# UNDEF lele_baud_rate
# Define console_baud_rate 38400/* redefine to PP1 default */# UNDEF wdb_tty_channel
# Define wdb_tty_channel 0 # UNDEF wdb_comm_type
# Define wdb_comm_type wdb_comm_serial/* 0 communication through serial port */# UNDEF wdb_tty_baud # define wdb_tty_baud 38400 # define include_tsfs_boot
--At this time, the serial port 0 channel will used as a channel for download and handshake of VxWorks images, the serial port 1 is used as the printing channel for console information. Both of them have a baud rate of 38400. If there is only one serial port, you must configure it as follows: ―――――――――――――――――――――――――――――――――――
# UNDEF lele_tty
# Define console_tty none
# UNDEF wdb_tty_channel
# Define wdb_tty_channel 0
# UNDEF wdb_comm_type
# Define wdb_comm_type wdb_comm_serial
# UNDEF wdb_tty_baud
# Define wdb_tty_baud 38400
# Define include_tsfs_boot there will be no console at this time, so the boot parameter cannot be changed. 2. Configure Tornado's target servera. Select "Tools"> "target server"> "Config…" under Tornado ..." -& Gt; "new": Creates a target server. As shown in :{
Window. Open ("http://blog.51cto.com/viewpic.php? Refimg = "+ this. SRC)
} 'Src = "http://img1.51cto.com/attachment/201003/13/109393_1268463004xeiF.jpg" border = "0" alt = "clip_image005" Height = "244"> B. Configure the core file as shown in, specify the VxWorks image file to download :{
Window. Open ("http://blog.51cto.com/viewpic.php? Refimg = "+ this. SRC)
} 'Src = "http://img1.51cto.com/attachment/201003/13/109393_1268463007Fw4D.jpg" border = "0" alt = "clip_image006" Height = "244"> C. Configure the TSFS file system as shown in :{
Window. Open ("http://blog.51cto.com/viewpic.php? Refimg = "+ this. SRC)
} 'Src = "http://img1.51cto.com/attachment/201003/13/109393_1268463012wrQ0.jpg" border = "0" alt = "clip_image007" Height = "244"> 3. complete all the configurations. Recompile bootrom and VxWorks, connect two serial lines, and configure the Super Terminal as the console. Start the target server of Tornado and restart the target server. The following interface is displayed :{
Window. Open ("http://blog.51cto.com/viewpic.php? Refimg = "+ this. SRC)
} 'Src = "http://img1.51cto.com/attachment/201003/13/109393_1268463014iKfO.jpg" border = "0" alt = "clip_image009" Height = "181"> the target machine downloads the VxWorks image from the serial port 0 and runs it. Finally, wdb: Ready is printed. For more details, see tornado online help: TSFS boot configuration. Target service file system: although the target service file system (TSFS) is a VxWorks file system with full features, it performs file operations by using the file system currently located on the host. TSFS uses the wdb driver to transfer requests from the I/O system to the target server. The target server reads and executes the request using the host file system. When you use TSFS to open a file, the opened file is actually on the host. In the future, the read () and write () calls to the file descriptors obtained in the open () call will actually read and write files from the open host.
