Hello everyone, I have learned a lot of help from enthusiastic netizens on the Network since I learned VxWorks. Now I have transplanted some things by referring to the BSP of B0. Everyone is me, and I am everyone, so now I will write out the porting process under the smartarm2200. My mailbox is walkingman321@163.com, I hope that interested friends can communicate with me and make progress together.
I. Development Environment Establishment
The development environment I use is tornado2.2 + H-JTAG + ads1.2. I am usually busy and don't have much time for development. So I can only skip bootrom development and write a rom_resdient image directly. The main functions are clock interruption and serial drive.
It is not difficult to transplant VxWorks itself. In fact, the most difficult thing is to establish the debugging environment at the beginning. It is better that some predecessors have posted methods on the Internet. The specific setting method is as follows:
First, change tool = Diab to tool = GNU in BSP makefile. Diab and GNU are two different compilation tools. The former has higher compilation efficiency and the latter is more common. I tried it. It seems that both tools can be debugged under axd, but the ELF file compiled by Diab is very unstable, the source code can only be displayed under the axd once every three times; the GNU command is almost successful.
After changing the makefile, Because I compile the rom_res image, I need to change the compilation target under $ (tgt_dir)/H/make/rules. BSP
EXE
: VxWorks. res_rom
Finally, add the-gdwarf rule in the $ (tgt_dir)/H/tool/GNU/defs. Arm file so that the axd can parse the symbols in the ELF File.
Cc_optim_driver
=-Gdwarf-fno-builtin-fvolatile
Cc_optim_normal
=-Gdwarf-fno-builtin
Cc_optim_target
=-Gdwarf-fno-builtin-fvolatile
After the above changes, the axd can be used almost, but in the actual debugging process, it is found that the start PC pointer is incorrect during the running. I don't know how others solve this problem. I am stupid about this. I first create another project in the ADS environment and compile a small executable file, the starting PC address of the executable file is easy to set. Then, when debugging VxWorks, load the small file first. After the file is loaded, the PC pointer is located at 0x80000000 (the starting address of lpc2210 is 0x80000000, which is a little different from other arm films ). Then select load image to load VxWorks and overwrite the first applet. In this way, the pointer is still located on the original 0x80000000 when VxWorks is started.
In addition, if the c file is included, for example, in syslib. # include "sysserial. C ", then sysserial. the functions in the C file cannot be debugged. When the axd goes here, the pointer will be messy. The solution is to modify the makefile so that sysserial. C can be compiled separately, and then replace # include "sysserial. C" with # include "sysserial. h ".
Another point is that it is too slow to directly burn an image on flash, and the software breakpoint cannot be added. The Development Board can be used with jumpers to choose whether to start from Ram or ROM. The external Ram provided by smartarm is 16 Mb. I use the front 2 MB as flash, and then separate the back 2 MB as the actual Ram. Run VxWorks. If you do not run a large program, 2 m Ram is more than enough, so I only use 4 m space (2 m Rom + 2 m RAM) during the development process ). The smaller the memory space will greatly improve the development efficiency, because the idle memory space will be cleared 0 during the VxWorks startup, if the CPU frequency is slow, it would take a considerable amount of time to clear 16 MB of memory at once.
Ii. System Startup
The next step is the official migration to VxWorks. The first file executed after VxWorks power-on is in rominit. S, and the function name is rominit. This function is mainly used to configure basic power-on configurations, set the stack pointer, and then jump to the romstart function. The stack pointer here is set to 0x80204000, 0x80200000 ~~ The IP address between 0x80204000 is specially empty, and the data segment is placed after 0x80204000. I am still confused about this stack pointer, because the bsp I refer to is defined as follows:
# Define
Resident_data
_ Sdata
However, it is found that _ sdata is located at 0x80204004, so that. Long at 0x80204000 is
Replace func (copyright_wind_river. So I can only modify it as follows:
# Define
Resident_data
Wrs_kernel_data_start
After running rominit, the system enters romstart. Because it is a rom_res image, the main task here is to copy the data segment in the Rom to Ram (because Ram is used to simulate the Rom, therefore, the data at 0x80000000 + dataoffset is copied to 0x80204000. For details, see config. H and makefile files), as well as clearing BSS and unused Ram space. Then enter the usrinit function.
So far, the initial start of the system is almost complete. Hardware initialization and interrupt vector settings are required in the usrinit function.
Iii. Interrupt settings
First, we need to differentiate the concepts of exception vectors and interrupt vectors. These two are completely different. The exception vectors are determined by the ARM architecture, including reset, undefinedaddr, SWI, prefetch, dataabort, IRQ, and FIQ. IRQ is determined by the specific ARM chip. When an interrupt occurs, the CPU first jumps to the IRQ exception vector, which is provided by VxWorks. Then, in the execution of the exception vector, the CPU determines which interrupt vector is based on the interrupt source, and jump to the interrupt service program corresponding to the interrupt vector. This interrupt service program is the interrupt entry we set using the intconnect function.
There are many articles on exception vector settings on the Internet. The main idea is how to move the system exception vector to a proper position, then, when the interrupt occurs, set the jump program to jump to the exception vector table you set. This is probably because bootrom is used by everyone. The exception vector table at arm startup is occupied by bootrom and has to be redirected. Fortunately, I am using rom_res, so I can directly set the abnormal vector table at the beginning of the rominit function:
_ Rominit:
LDR
PC, resetaddr
LDR
PC, undefinedaddr
LDR
PC, swi_addr
LDR
PC, prefetchaddr
LDR
PC, dataabortaddr
. Long
Zero X 00000000
LDR
PC, irq_addr
LDR
PC, fiq_addr
Resetaddr:
. Long
Cold
Undefinedaddr:
. Long
Excenterundef
Swi_addr:
. Long
Excenterswi
Prefetchaddr:
. Long
Excenterprefetchabort
Dataabortaddr:
. Long
Excenterdataabort
Irq_addr:
. Long
Intent
Fiq_addr:
. Long
Fiq_handler
VxWorks has provided us with ready-made exception vector entry functions, including excenterundef, excenterswi, excenterprefetchabort, excenterdataabort, and intent, which can be directly declared and then used. FIQ VxWorks is not used and must be defined by yourself. Here we can see that when an interrupt occurs, it jumps to the intent function.
So what is the role of intent? It is to determine the interrupt source and jump to the interrupt vector table. Before that, we have to initialize the interrupt vector table. Here we call the lpc2210excvecinit function, which is in sysalib. S.
_ Arm_function (lpc2210excvecinit)
Stmfd SP !, {R0-r10, LR}
BL func (arminitexceptionmodes)
LDR r0, L $ __func_armirqhandler
LDR R1, L $ _ excinthandle
STR R1, [R0]
NOP
Ldmfd SP !, R0-r10, PC}
Arminitexceptionmodes and _ excinthandle are both built-in with VxWorks. For the specific principles of this function, you can refer to other articles on the Alibaba Cloud and the Network for details.
In addition, you also need to call the initialization function of intlibinit and interrupt controller driver in syshwinit2. Intlibinit is used to allocate and initialize the space of the interrupt vector table. We call the intconnect registration interrupt entry function to register the interrupt vector table. With regard to the interrupt controller driver, you can look at the source code of various BSP porting on the network. It is easy to understand, mainly to register some callback function entries, assign these function entries to the global variables provided by vxwroks. There are a total of four global variables, which are
Sysintlvlvecchkrtn, sysintlvlenablertn, sintlvldisablertn, and sysintlvlvecackrtn. Enable and disable are functions that enable and disable specific interruptions. Intlvlchk is important. It is called by intent during each interruption to determine which interrupt source is generating an interrupt. It returns an interrupt vector, then, intent can jump to the function entry in the interrupt vector table based on the interrupt vector. Ack is called after each interruption. Because I use a non-preemptible interrupt mode, this function can be called to respond to new interruptions.
Iv. Clock interruption, serial port and others
Once the interrupted framework is set up, the following is very simple. Clock interruption is the heartbeat of the system. In reality, it should be at least 20 times per second, but here I simply set it to once per second (directly copied from Zhou licong's code, ). During clock interruption, A tickannounce function is called. This function is provided by VxWorks, which performs the necessary operations in the system heartbeat.
The serial port driver is simpler. There are a lot of online materials, and there is also a book about BSP which also describes in detail. I will not talk about it here.
V. Conclusion
It seems that nothing can be summarized here. There are a lot of transplant materials on the Internet. As a supplement, I seem to have written enough. Recently, I was busy working, so I didn't add networks, graphics, and other complex modules, or even wdb. When there is time, it will be all done. During the entire transplantation process, I personally felt that it was the most difficult to establish the environment at the beginning, so I wrote this part in the most detail. We recommend that you take a look at the documents of the makefile and the syntax of the link script that comes with tornado before porting, and master some concepts such as VMA and LMA, which is very helpful for porting.
BSP Source Code address: http://download.csdn.net/source/319315
