VxWorks Hardware Considerations Guide VxWorks 6.
Copyright © 2004 Wind River Systems, Inc. All rights reserved. No part of this publication may be reproduced or transmitted in any form or by any means without the prior written permission of Wind River Systems, Inc. Wind River, the Wind River logo, Tornado, and VxWorks are registered trademarks of Wind River Systems, Inc. Any third-party trademarks referenced are the property of their respective owners. For further information regarding Wind River trademarks, please see: http://www.windriver.
Contents 1 Introduction ............................................................................................................. 1 2 Minimum System Requirements ........................................................................ 2 3 Processor and Architecture Support ................................................................... 3 4 Architecture Considerations ................................................................................ 4 Interrupt Handling ...................
VxWorks Hardware Considerations Guide, 6.0 7 Devices ...................................................................................................................... 15 Interrupts ................................................................................................... System Clock ............................................................................................. Auxiliary Clock .........................................................................................
VxWorks Hardware Considerations Guide 6.0 1. Introduction VxWorks runs on many architectures and targets from a wide variety of vendors, including custom and embedded hardware, VMEbus, Multibus, and PCIbus single-board computers, and workstation and PC mother boards. VxWorks can also boot from many different UNIX and Windows hosts using a variety of communication media.
VxWorks Hardware Considerations Guide, 6.0 The particulars of how an individual architecture implements these considerations are discussed in the VxWorks Architecture Supplement document for each architecture. This document is a general discussion of the issues and not an implementation-specific guide. NOTE: All file and directory paths in this manual are relative to the VxWorks installation directory. For installations based on VxWorks 5.x, this corresponds to installDir.
3. Processor and Architecture Support A bank of software controlled LEDs is also a desirable feature for the board. During development, they can indicate the state of the system relevant to the application being developed. And for product deployment, they can indicate system status. For more effective debugging, it is helpful to have a high resolution timer other than the system clock, to be configured as a timestamp device. It is also usually appropriate to include support for an auxiliary clock.
VxWorks Hardware Considerations Guide, 6.0 4. Architecture Considerations At the core of any VxWorks run-time environment is the target architecture. This section is dedicated to the capabilities and run-time ramifications of architecture selection. Some general observations follow, but most details are covered in documents devoted to a particular architecture, the architecture supplements.
4. Architecture Considerations take tens of uninterruptable microseconds. The operating system and application also contribute to interrupt latency by inhibiting the processor’s ability to receive interrupts. While each VxWorks architecture port has optimized these interrupt locks to an absolute minimum, be aware that some variation in performance exists when comparing one architecture to another. Non-maskable interrupts should not be used.
VxWorks Hardware Considerations Guide, 6.0 with this buffer. Having done all this, memory buffers for DMA operations are relatively safe from the effect of memory coherency in a copyback situation. Many processors implement write pipes that can buffer write operations when the bus controller is busy. Because of this, VxWorks device drivers make use of a macro, CACHE_PIPE_FLUSH, to flush cache contents. A CACHE_PIPE_FLUSH operation should be inserted between any I/O write operation and a I/O read operation.
5. Memory Higher-level transcendental functions are supported in VxWorks in one of these ways: ■ A portable version that avoids using any floating-point instructions is standard, but can be replaced with an optimized (assembly language) version for certain architectures with floating-point capabilities. For more information on selecting optional features, see the configuration discussion in your VxWorks programmer’s guide.
VxWorks Hardware Considerations Guide, 6.0 RAM VxWorks CISC processors require 1 MB of RAM for a development system that includes the standard VxWorks features, such as the shell, network, file system, loader, and others. RISC processors typically require more RAM space: 2 MB of RAM is the minimum; 4 MB is encouraged. For a scaled-down production system, the amount of RAM required depends on the application size and the options selected.
6. Bus Support NV_RAM_SIZE, NV_BOOT_OFFSET, and NV_RAM_ADRS. These macros are usually defined in config.h, bspname.h, or configAll.h. Parity Checking VxWorks makes no direct use of memory parity checking on the RAM. If parity checking is desired or needed, it is usually left to the BSP or the user to enable parity and to implement a parity error handling routine. Some architectures may specify an interrupt or exception vector to be used for parity error handling.
VxWorks Hardware Considerations Guide, 6.0 pciConfigLib, pciConfigShow, pciAutoCfg, and pciIntLib for more information. Wind River Technical Note #49 also contains information regarding PCI support. Addressing The standard Wind River PCI configuration causes all memory space on the PCI bus to be accessed through the MMU, which requires system memory to hold the page table entries (PTEs). Dual-Port Memory Most CPU boards have local (on-board) RAM on the processor bus.
6. Bus Support because all VME device drivers are configurable. However, conflicting devices may be a system issue. Dynamic Bus Sizing on VMEbus Accesses There are three address types defined in the specification: ■ ■ ■ A16 short A24 standard A32 extended In addition, there are often data width restrictions to off-board devices. Many implementers offer different windows with different data widths (D16 or D32) to the same VME address.
VxWorks Hardware Considerations Guide, 6.0 most applications, this is not a problem. However, for applications with extremely low latency requirements, this can be ameliorated somewhat by locating device buffers in VME memory. Read-Modify-Write (RMW) Read-modify-write (RMW) must be provided in an indivisible manner. The board must adhere to the RMW mechanism defined in the VME specification; namely, a master must keep the address strobe low between the read and the write portions of the cycle.
6. Bus Support Multiple bus request/grant levels may be critical for systems with many masters in the backplane; with round-robin arbitration it can guarantee timely access to the bus for each bus master. If masters on the same level are daisy chained, the masters far down the bus may become “starved.” Arbitration/System Controller The system controller functionality should be optional and selected by a jumper. The system controller should not be enabled through a register that can be set by software.
VxWorks Hardware Considerations Guide, 6.0 VMEbus Interrupts Although VxWorks does not require VMEbus interrupts, it is a good idea to support all VMEbus interrupts, especially if off-board Ethernet capability is required. It may be possible to jumper the enabling and disabling of these interrupts, but software control is preferable. Allowing software to read the interrupt state is valuable. VMEbus Interrupt Acknowledge VMEbus interrupt requests must be acknowledged by the receiver.
7. Devices or an In-Circuit Emulator. Emulator object file formats and operations are as varied as the vendors that sell them. Contact Wind River for information on appropriate combinations. The initial goal should be to get serial line activity. Start small. Build a simple polled serial driver and build up from there. Take advantage of any LEDs that can be blinked as checkpoints in the code are passed. Use an oscilloscope to see that interrupts are occurring and being acknowledged correctly.
VxWorks Hardware Considerations Guide, 6.0 corruption. Ideally, the driver can disable only the interrupt from the device the driver controls. However, because of some hardware with limiting designs, the driver must sometimes disable all interrupts on the board. This is not desirable, because no interrupts can be serviced during this lock-out period. Some devices are capable of supplying the interrupt vector during the interrupt acknowledge bus cycle.
7. Devices after reset, some programming of the device or other circuits must be done at kernel initialization time, to cause the device to de-assert its signal. The sort of device-specific knowledge needed to do this is usually contained only in the device’s driver. It is not appropriate to duplicate this sequence within the kernel initialization routines. The only other mandatory requirement for interrupt design is to provide a well diagramed and documented interrupt vector scheme.
VxWorks Hardware Considerations Guide, 6.0 Timestamp Clock Many of the generic timers in target/src/drv/timer include timestamp functionality. A timestamp driver provides a high-resolution time measurement facility, typically used by the WindView product. See the VxWorks Device Driver Developer’s Guide for more information on the API.
7. Devices Ethernet Controllers VxWorks is very “network oriented,” at least during the development phase; thus, it is highly desirable to have a networking interface available. The interface can be used for booting and downloading application code as well as application-specific inter-processor communication. VxWorks provides a device-independent interface to Ethernet controllers through netLib, which permits the use of RPC and NFS and other Internet protocols.
VxWorks Hardware Considerations Guide, 6.0 Designing a CPU board to include an Ethernet chip saves the expense of additional off-board networking hardware (in a “bus-full” environment) and, potentially, has a higher performance. A detailed description of writing a VxWorks END network device driver is included in the VxWorks Device Driver Developer’s Guide. USB Controllers Wind River USB host and peripheral stacks are provided for VxWorks starting with VxWorks 6.0. For releases prior to VxWorks 6.
7. Devices DMA Controllers DMA controllers can free the processor of lengthy copies to I/O devices or off-board memory and may optionally be used by SCSI device drivers. Reset Button A reset button should be provided that is functionally equivalent to a power-on reset. If operating in a bus-full environment, the reset signal may need to be propagated to the bus.
VxWorks Hardware Considerations Guide, 6.0 Parallel Ports VxWorks provides simple support of parallel ports. Refer to directory target/src/drv/parallel for supported devices and capabilities. 8. Flash Devices and Flash File System Support This section discusses TrueFFS features and functionality. In addition, this section provides generic information on flash devices and a discussion of TrueFFS usage. 8.
8. Flash Devices and Flash File System Support 8.2 Choosing TrueFFS as a Medium TrueFFS applications can read and write from flash memory just as they would from an MS-DOS file system resident on a magnetic-medium mechanical disk drive. However, the underlying storage media are radically different. While these differences are generally transparent to the high-level developer, it is critical that you be aware of them when designing an embedded system.
VxWorks Hardware Considerations Guide, 6.0 Block Allocation and Data Clusters As is required of a block device driver, TrueFFS maps flash memory into what appears to be (from the users perspective) a contiguous array of storage blocks, upon which a file system can read and write data. These blocks are numbered from zero to one less than the total number of blocks. Currently, the only supported file system is dosFs (for more information, see the appropriate VxWorks programmer’s guide for your release).
8. Flash Devices and Flash File System Support ■ Localizes Static File Blocks. Localizing blocks that belong to static files significantly facilitates transferring these blocks when the wear-leveling algorithm decides to move static areas. Read and Write Operations One of the characteristics of flash memory that differs considerably from the more common magnetic-medium mechanical disks is the way in which it writes new data to the medium.
VxWorks Hardware Considerations Guide, 6.0 block now maps to the area of flash that contains the modified data. This mapping information is protected, even during a fault. For more information on fault recovery and mapping information, see Recovering Mapping Information, p.29. Erase Cycles and Garbage Collection The write operation is intrinsically linked to the erase operation, since data cannot be “over-written.
8. Flash Devices and Flash File System Support known as the cycling limit, depends on the specific flash technology, but it ranges from a hundred thousand to a million times per block.1 Optimization Methods As mentioned, flash memory is not an infinitely reusable storage medium. The number of erase cycles per erase unit of flash memory is large but limited. Eventually, flash degrades to a read-only state.
VxWorks Hardware Considerations Guide, 6.0 degradation of performance. Given the large number of allowed erase cycles, this less-than-absolute approach to wear-leveling is sufficient. Dead Locks Finally, the TrueFFS wear-leveling algorithm is further enhanced to break a failure mode known as dead locks. Some simple wear-leveling algorithms have been shown to “flip-flop” transfers between only two or more units for very long periods, neglecting all other units.
8. Flash Devices and Flash File System Support TrueFFS can recover from the fault in all cases except when new data is being written to flash for the first time. In this case, the new data is lost. However, once data is safely written to flash, it is essentially immune to power failures. All data already resident in flash is recoverable, and the file and directory structures of the disk are retained.
VxWorks Hardware Considerations Guide, 6.0 Recovering During Garbage Collection After a fault, any garbage collection in process at the time of the failure must be restarted. Garbage area is space that is occupied by sections that have been deleted by the host. TrueFFS reclaims garbage space by first moving data from one transfer unit to another, and then erasing the original unit.
10. Partial Compliance to Standards Note that some processors have special requirements related to virtual memory. ! CAUTION: Due to a limitation in the current implementation of VxWorks, virtual addresses must equal physical addresses when using 68K MMUs (68K support is available for VxWorks 5.5 only). 10. Partial Compliance to Standards Many devices of all types have claims that they support certain standards. However, when the device’s errata are examined closely, there are significant exceptions.
VxWorks Hardware Considerations Guide, 6.0 transactions on the PCI bus. The result was that every device driver for devices which might be placed on the PCI bus would not work, because they use the full PCI capabilities and transactions of less than 64-bit size. So, no PCI devices would work for any system based on that host bridge with standard drivers, and all device drivers on such a system must be custom versions, resulting in greater software costs.
