Remote booting. Slave booting, backplane booting and 'headless' booting procedures for a VxWorks target

Transcription

1 Remote booting Slave booting, backplane booting and 'headless' booting procedures for a VxWorks target Copyright Wind River Systems Inc ALL RIGHTS RESERVED VxWorks, Wind River Systems, the Wind River Systems logo and wind are registered trademarks of Wind River Systems Inc Crosswind, IxWorks, Tornado, VxSim, VxVmi, WindC++, WindConfig, Wind Foundation Classes, WindNet, WindPower, WindSh and WindView are trademarks of Wind River Systems Inc All other trademarks used in this document are the property of their respective owners Wind Tech Notes are maintained and published by Wind River Systems Customer Support Telephone Fax Corporate 800/ Toll support@wrscom 510/ Free, US and Canada Europe (+) support@wrsecfr (+) Japan support@kkwrscom If you purchased your Wind River systems Product from a distributor, please contact your distributor to determine how to reach your technical support organization Please provide your license number when contacting Customer Support Version 2 Dec 2000

2 Introduction Many customers have remote booting requirements VxWorks supports three remote booting scenarios: slave booting over the network, backplane booting over the VME bus and 'headless' booting where the boot loader itself must be transferred to the target over a network These three scenarios are documented at varying levels of detail in the deliverable Tornado documentation In all cases, however, the documentation is generic and can be supplemented with explanation and examples that will improve a user's chance for quick success in implementing one of the remote booting procedures This technical summary addresses the 'loose' spots in the available documentation and provides real-world explanations and practical examples Let's consider three example systems where each of the referenced remote booting methods would be employed: 1 Slave booting over the network can be used in a multi-target system where all targets are connected via ethernet but where the VxWorks kernel(s) are stored on either mechanical storage device(s) or in permanent memory that is only accessible by one of the targets In this case the targets without direct access to their kernels can obtain them over the network 2 Backplane booting can be used in a multi-target system where all targets are on the same VME backplane but only a master CPU has an ethernet connection to a remote server where are stored the VxWorks kernels In this case the CPU's without ethernet connection can obtain their kernels by a network that uses the VME bus as a subnet and the master CPU as a gateway 3 Headless booting can be used in a system where (initially) the VxWorks boot loader is not available to a target locally, ie stored on an attached mechanical device or in on-board permanent memory This type of system is often encountered in military applications where there can be no mechanical storage devices connected and no permanent type memory installed on a target because of security Suggested Additional Documentation VxWorks Network Programmer's Guide 54, Edition 1 section 35 section 13 Slave booting Slave booting over the network means that a slave CPU card acquires its VxWorks kernel from another CPU card, which is running the VxWorks OS and which is connected to the slave CPU card, via ethernet This form of booting can be used by targets that have local access to the VxWorks boot loader, stored either in permanent on-board memory or on a connected mechanical storage device such as a floppy disk drive, but not their VxWorks kernel As an example, to implement a system with a master CPU card, which has all the VxWorks kernels stored on an attached hard drive, and slave CPU card, which will acquire its kernel from the master via ethernet, perform the following steps: 1 Build master CPU card VxWorks kernel with macro INCLUDE_FTP_SERVER defined 2 Boot master CPU card 3 After master CPU card has booted, execute a script containing the following commands: dosfsdevinitoptionsset (0x8) - makes hard drive file system exportable 55-2

3 usrataconfig (0, 0, "/hd0") - creates handle to hard drive file system hostadd ("<slave CPU card target name, eg vxtarget1>", "<slave CPU card IP address, eg 90002>") 4 Boot slave CPU card, interrupt the boot loader countdown and modify boot parameters as follows: boot device: <network device, eg dc> processor number: 1 host name: <master CPU card target name, eg vxtarget> boot file: /hd0/vxworks - see name applied to file system in script command usrataconfig above inet address: <slave CPU card IP address, eg 90002> host inet addr: <master CPU card IP address, eg 90001> logon id: <any id as a place holder, eg vxw> passwd: <any password as a place holder, eg passwd> flags: 0x0 target name: <slave CPU card target name, eg vxtarget1> 5 Allow slave CPU card to continue the boot process and observe successful slave network boot from a master CPU card, running the VxWorks OS Backplane booting Backplane booting over the VME bus means that a slave CPU card acquires its VxWorks kernel from another CPU card, which is running the VxWorks OS and which is connected to the slave CPU card via VME backplane This form of booting can be used by targets that have local access to the VxWorks boot loader, stored either in permanent on-board memory or on a connected mechanical storage device such as a floppy disk drive, but not their VxWorks kernel To boot a slave CPU card, from a master CPU card, via VME backplane, requires exercise of the VxWorks shared memory network on the backplane facility Documentation for the process is provided in the VxWorks Network Programmer's Guide 54, section 35 As an example, to implement a system with a master CPU card, which has an ethernet connection to a host platform, where are available all the VxWorks kernels, and a slave CPU card which is on the same VME backplane as the master CPU, perform the following steps: 1 To enable the shared memory network on the backplane, build both master and slave CPU card VxWorks kernels with the macro INCLUDE_SM_NET and the following additional parameters defined: Master CPU: #define SM_OFF_BOARD TRUE #if SM_OFF_BOARD #undef SM_ANCHOR_ADRS #define SM_ANCHOR_ADRS ((char *)0x ) #define SM_MEM_ADRS SM_ANCHOR_ADRS #define SM_MEM_SIZE 0x #define SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE) #define SM_OBJ_MEM_SIZE 0x10000 #define SM_INT_TYPE SM_INT_BUS #define SM_INT_ARG1 2 #define SM_INT_ARG2 80 #define SM_INT_ARG

4 For the above example, assume the master CPU is equipped with 64MB of RAM Shared memory is therefore allocated from the master CPU's RAM in spite of the definition of the macro SM_OFF_BOARD The shared memory is specified to occupy local RAM just above 32 MB and to occupy a total space for both shared memory and shared memory objects of 128KB The interrupt notification method selected is via VME bus interrupt (SM_BUS_INT) at level 2 and vector of 80 Usually, no changes to the master CPU VME bus default 'window' configurations are required Default VME bus 'window' configurations, as provided by WRS supported PPC BSP's, always include opening of a slave window that encompasses all of local RAM, automatically, as part of the boot sequence For the slave CPU, also equipped with 64MB RAM, the shared memory is truly located off-board and is accessed over the VME bus Therefore, the local address used to access the shared memory must translate to a VME bus address that will access the master CPU's local RAM starting at its SM_ANCHOR_ADRS Slave CPU: #define SM_OFF_BOARD TRUE #if SM_OFF_BOARD #undef SM_ANCHOR_ADRS #define SM_ANCHOR_ADRS ((char *)0x0A000600) #define SM_MEM_ADRS SM_ANCHOR_ADRS #define SM_MEM_SIZE 0x #define SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE) #define SM_OBJ_MEM_SIZE 0x10000 #define SM_INT_TYPE SM_INT_BUS #define SM_INT_ARG1 4 #define SM_INT_ARG2 82 #define SM_INT_ARG3 0 Usually, no changes to the master CPU VME bus default 'window' configurations are required Default VME bus 'window' configurations, as provided by WRS supported PPC BSP's, always include opening of a master window whose local starting address (0x ) results in a VME bus address that is translated by a master CPU card (processor #0, via boot parameters) slave window to access the start of local RAM Thus an anchor address, of local address 0x x (= 0x0A000600), is specified 2 Re-build both master and slave CPU kernels 3 Cycle power on both master and slave CPU's and interrupt the boot loader countdowns in order to modify the boot parameters as follows: Master CPU: boot device: <network device, eg dc> processor number: 0 host name: <arbitrary host name> file name: <path to master CPU VxWorks kernel on remote server> inet on ethernet: <master target IP address, coincident with remote server LAN> inet on backplane: <arbitrary master CPU backplane network IP address, eg > host inet: <remote server's IP address> 55-4

5 Slave CPU: boot device: sm=0x0a processor number: 1 host name: <arbitrary host name> file name: <path to slave CPU VxWorks kernel on remote server> inet on ethernet: <LEAVE BLANK> inet on backplane: <arbitrary slave CPU backplane network IP address, eg > host inet: gateway inet: <remote server's IP address> <master CPU backplane network IP address, eg > 4 Before allowing the master and slave CPU's to proceed with the VxWorks boot sequence, the remote server must be informed of the route to the backplane network For UNIX type remote servers, refer to the VxWorks Network Programmer's Guide 54, section 354 For NT remote servers, the route must be added to the NT hosts route table From an NT MS-DOS command prompt, type route<enter> for usage For example: route ADD <arbitrary slave CPU backplane network IP address, eg > MASK <master target IP address, coincident with remote server LAN> 1 Headless booting Headless booting means that the VxWorks boot loader is transferred to a target CPU card via network and automatically loaded into memory and executed to start the VxWorks OS boot sequence This form of booting can be used by targets that DO NOT have local access to either the VxWorks boot loader or their VxWorks kernel Generic documentation for the process is provided in the VxWorks Network Programmer's Guide 54, section 13 Note: Headless booting is only possible for targets that include on-board BIOS type software that can be configured for direct booting from the network rather then from an attached mechanical storage device or permanent on-board memory The procedure to successfully boot a VxWorks target by downloading the VxWorks boot loader, from a UNIX workstation, to the CPU card, is as follows: FYI: Procedure steps 2 and 6 are specific for an x86 target that includes the popular LanWorks firmware Procedure step 4 example is specific for an NT system development host 1 Start a DHCP deamon on the UNIX workstation and configure the DHCP config file, dhcpdconf, as shown below FYI: DHCP is a superprotocol over BOOTP and so for BOOTP purposes the difference lies only in the configuration of the daemon As a side note, the DHCP protocol also supports NT clients Note: Starting the DHCP deamon and configuration of the dhcpdconf file are subjects for discussion with the UNIX workstation system administrator 55-5

6 The pertinent lines to be added to the file /etc/dhcpdconf are as follows: host vxtarg03 { fixed-address vxtarg03engwrscom; hardware ethernet 08:00:2b:22:78:69; next-server steinmetzengwrscom; filename "/vxw/bootromsys"; } Where: vxtarg03 is named in the /etc/hosts file and has the IP address of the target vxtarg03engwrscom refers to the target domain hardware ethernet is the CPU card MAC address FYI: If the MAC address is not documented, then it must be determined by booting the target under any OS that supports network communication, 'pinging' the target from the UNIX host, then running 'arp -a' which returns the MAC addresses of the last few targets pinged next-server is the UNIX host domain filename is the full path on the UNIX host to a boot loader image named bootromsys 2 Modify BSP files, configh and Makefile, as follows: Note: The following modifications are required because LanWorks firmware loads a host provided image to the protocol standard memory location 0x10000 The VxWorks boot loader is a non-relocatable image and its build control macros, included in generic VxWorks BSP's, direct that the image be built with a different starting address As shown below, for the generic x86 BSP's, a starting address of 0x8000 is default a In the configh file make changes as follows: #ifdef BOOTCODE_IN_RAM #define ROM_BASE_ADRS 0x /* base address of ROM */ #ifdef BOOTCODE_IN_RAM #define ROM_BASE_ADRS 0x /* base address of ROM */ #define RAM_HIGH_ADRS 0x /* Boot image entry point */ #define RAM_HIGH_ADRS 0x /* Boot image entry point */ b In the Makefile make changes as follows: 55-6

7 # ifdef BOOTCODE_IN_RAM ROM_TEXT_ADRS = # ROM entry address - A: or C: # ifdef BOOTCODE_IN_RAM ROM_TEXT_ADRS = # ROM entry address - A: or C: RAM_HIGH_ADRS = # RAM text/data address RAM_HIGH_ADRS = # RAM text/data address 3 Create the boot loader image bootrom_uncmp 4 Create the bootromsys image As example, from an NT development host, from the directory /WIND_BASE/host/x86-win32/bin, run the batch command 'vxcopy' from a DOS command prompt: vxcopy /WIND_BASE/target/config/<BSP directory>/bootrom_uncmp /WIND_BASE/ target/ config/ <BSP directory>/bootromsys 5 Use FTP, binary mode, to transfer bootromsys to the UNIX workstation to the path as specified in the DHCP config file /etc/dhcpdconf file 6 Configure target BIOS to direct booting from the network rather then from another media Note: The following steps are specific for the x86 targets with BIOS that includes the popular LanWorks firmware a Enter BIOS setup by interruption of the power-up sequence when directed by on-screen prompt b Configure BIOS to direct booting from the network, save and exit c Enter LanWorks setup by interruption of the power-up sequence when directed by on-screen prompt d Select TCP/IP DHCP protocol for LanWorks operation, save and exit 7 If the UNIX workstation has been configured as described above then cycling target CPU card power will cause the file bootromsys file to be loaded and executed Immediately after which, the VxWorks boot loader countdown will appear on the selected standard output 55-7