NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Knowledge > HowToMakeCCUPROMS (r1.1 vs. r1.2)
   Readme | Changes | Index | Search | Go
 <<O>>  Difference Topic HowToMakeCCUPROMS (r1.2 - 14 Sep 2007 - JoeBrandt)
Changed:
<
<

At this point you have a file vxWorks.st_rom.hex, which contains lots of hex numbers. This is a Motorola S-record format file, which we need to:

>
>

*OR*
Create ROM boot loader images: Step 6: make bootrom

Step 7: make bootrom.hex

At this point you have a file vxWorks.st_rom.hex or bootrom.hex, which contains lots of hex numbers. This is a Motorola S-record format file, which we need to:


 <<O>>  Difference Topic HowToMakeCCUPROMS (r1.1 - 08 Jul 2004 - JoeBrandt)
Added:
>
>

%META:TOPICINFO{author="JoeBrandt" date="1089319740" format="1.0" version="1.1"}% %META:TOPICPARENT{name="MnCKnowledge"}%

Problem

How to make boot ROM images for vxWorks? (SCCU in particular)

Solution

Note: Much of this is changing as we move the code to 5.3!

Building the SCCU Code:

To setup an environment for building the GBT servo from source, execute (assuming a bash session):

Step 1: source ./Profile 5.1

The code must be built in two steps. The first is to build the SCU code itself, located in ./source/sccu. So the next step is to go there:

Step 2: cd ./source/sccu

If you want a clean build, do a rm *.o *.lib *.ro. Now compile the code:

Step 3: make

followed by:

Step 4: make sccu.ro

Now you have the servo code, ready for either booting as an application across the network, (like most GBT applications) or ready for linking into the OS.

If the OS/SCCU code is to be ROM'ed, the SCCU code must be built and linked with the vxWorks OS. Configuring and building the OS is a subject of a HOW-TO of itself. I will cover only the final stages, assuming you know how to configure and build vxWorks.

The link-point between OS and servo code is located in the file: ./vxWorks/config/all/usrConfig.c. This file has a function named usrRoot(), which is called as the system boots to start-up various system facilities. The usrRoot() function contains code to perform a count-down, after which the sccuPost() function in the servo code is called. The sccuPost() function is the entry point to spawn all servo related tasks.

I should note that the servo SBC EEPROM must contain one of the strings: 'SCU' or 'CCU' (without quotes) in the 'other' field of the EEPROM. This configures the system to look for either CCU or SCU hardware.

Building the OS:

Set your environment as in the step 1 above.

Step 5: cd ./vxWorks5.1/config/mv167

Create the ROM images from the binary:

Step 6: make vxWorks.st_rom

Step 7: make vxWorks.st_rom.hex

At this point you have a file vxWorks.st_rom.hex, which contains lots of hex numbers. This is a Motorola S-record format file, which we need to:

  • (a) make a binary file, and
  • (b) split the binary into upper and lower word hunks to put into ROMS.
This is a step in which things can get very confusing, because of byte/word orientation issues. The Motorola 68040 and Sparc architectures are the same, but the ROM burner is a PC based device, so some pre-swapping is required. This may change as the tools and build host changes. I assume here a Sparc host is used for builds, and a x86 PC is used for PROM programming.

Translate the SRecords into pure binary:

Step 8: objcopy68k -I srec -O binary vxWorks.st_rom.hex t1.bin

Note: You will get an error: "Output file cannot represent architecture UNKNOWN!" (ignore it)

This is not an issue, as long as your on a same endianess as the target. This will not work (for example) on a i386-linux host, trust me on this one.

The objcopy is a GNU program which can almost split the files, but not quite. We need to split 16bit words, which is not supported (in the version we have at least). I wrote a program called makeRoms which does this simple operation. (The source and binary is located in ./tools directory. It assumes a sparc host.)

So now we can split our binary file into upper and lower 16 bit words. This could be straight-forward, but the ROM-burners we own are PC-oriented, so they end up byte swapping the ROM's. In order to fix this, the makeRoms program does one more pre-swap, to fix the problem.

Run the makeRoms program:

Step 9: makeRoms t1.bin ROM.U1 ROM.U2

The U1/U2 should follow the board silkscreen nomenclature. You can run a sanity check by examining what happens to the strings in t1.bin:

start of data Copyright 1984-1992 Wind River Systems, Inc. This program contains confidential information of Wind River Systems, Inc. and disclosure and copying are prohibited.

The way to read is 2 1 6 5 ... 4 3 8 7 ...

So after the makeROMS step it becomes:

 ROM.U1:
ts td <cr>a
oCir t4899iWR resysmnIT
 sgo mtnsnnoedainimroifoniiR rts,scnnaidolerdnpognerorib.d
                                                                                         
 ROM.U2:
rafota
yphg911- 2dnviS et ,.cihrparociac iftn lofta nW  devySmeI
. dcsusa c iya p ihet

-- JoeBrandt - 08 Jul 2004 %META:FORM{name="WebForm"}% %META:FIELD{name="TopicClassification" title="TopicClassification" value="NoDisclosure"}% %META:FIELD{name="OperatingSystem" title="OperatingSystem" value=""}% %META:FIELD{name="OsVersion" title="OsVersion" value=""}%


Topic HowToMakeCCUPROMS . { View | Diffs | r1.2 | > | r1.1 | More }
Revision r1.1 - 08 Jul 2004 - 20:49 GMT - JoeBrandt
Revision r1.2 - 14 Sep 2007 - 19:36 GMT - JoeBrandt
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.