Home

OS-9 OEM Installation Manual

1. E 7 Step One Create a New Init Module E 7 Step One Create a New I nued E 8 Step Two Create a New Bootfile E 9 Step Three Test SSM Operation E 9 Creating a System Security Module E 10 SSM Module Structure srrnrrnrvveverrvrrrnnnrrrrrnerneen E 12 Hardware Considerations A E 15 Complete Source Listing ii E 17 Using the OS 9 System Security Module Memory Management Units This section describes the level of support for the various memory management units MMU provided by Microware Included are e Motorola 68451 typically for 68010 systems e Motorola 68851 typically for 68020 systems e Embedded M M Us found on the 68030 and 68040 microprocessors The 68451 requires only minor modification before use while the others are implementation independent Instructions and an example are also included for instances where an OEM may wish to design their own MMU OS 9 OEM Installation Manual Hardware Software Requirements Versions of SSM040 OS 9 OEM Installation Manual Using the OS 9 System Security Module The following hardware and software is required for use with the OS 9 System Security Module SSM e OS 9 Version 2 4 or greater e A Memory Management Unit must be installed on the system e asa discrete chip e embedded on the microprocessor or asa separate card Therearetwo version
2. e The debug files rombug Not all of the relocatable files This code is used during the port you can exclude it listed are supplied in the distribution package some from the final production boot ROM All debug files are are created during the provided in relocatable format The source code to the porting process debug files is not supplied with the Port Paks because you do not need to edit or assemble these files Source Relocatable Contents Jf rombugil Full featured ROM debugger IMPORTANT Read the rest of this chapter before you begin editing the systyped file OS 9 OEM Installation Manual 3 9 Step One Porting the Boot Code The Defsfile File The defsfilefile acts as a master include file to include all definition d files within assemblies in the PORTS lt target gt directory defsfile will typically include lt oskdefs d gt from SRC DEFS and systyped from PORTS lt target gt at a minimum OS 9 OEM Installation Manual The Oskdefs d File Do not edit oskdefs d oskdefs dis used for generic system wide target independent definitions only If system specific definitions are needed edit systype d OS 9 OEM Installation Manual Step One Porting the Boot Code The oskdefs d file is OS 9 s system wide symbolic definitions file It can be found in the SRC DEFS directory oskdefs d defines some of the names used in systyped You should make
3. 1 20 OS 9 OEM Installation Manual Developing a Plan OS 9 OEM Installation Manual Getting Started Congratulations You have chosen to use OS 9 the world s leading real time operating system for Motorola 68000 based real time and embedded systems That was easy Now we hope you will find it just as easy to actually port OS 9 to your new target system But to do that it is important that you takea little time to develop a plan for accomplishing that If you have not already realized it you will need to determine what your development environment will be This will include such things as e What kind of host development system you will use to edit and re compile OS 9 source files e What additional development equipment will be needed to test your port of OS 9 on your target and how that equipment will be connected to your host development system This will be closely tied to the mode of operation that you will use to port the OS 9 Boot ROMs to your target We strongly suggest that you read through at least the first three chapters of this manual before attempting to start the port This will give you a good perspective on what will be required to accomplish the port and that will help you develop a better plan Before installing OS 9 you need to understand two terms host system The development system used to edit and re assemble OS 9 source files target system The system on which you intend to port OS 9
4. aa i i 3 10 The Oskdefs d BE 3 11 TNESYSKYPE OA FIG relitto 3 12 The ROM Configuration Values 3 13 Target Specific Labels ek 3 13 Target Configuration Labels 3 15 CPUTyp Label and Supported Processors 3 17 Low Level Device Configuration Labels 3 18 Target System Memory Labels 3 19 Example Memory Definitions 3 19 OS 9 OEM Installation Manual Step One Porting the Boot Code ThE VeCtOrSa FINE allea 3 21 TneBoota File pied aaa 3 22 Steps Boot a Goes Through to Boot Mek ECH gegen E 3 22 Memory Search Explanations 3 26 The RAM Search AA 3 26 The Special Memory Search 3 27 The Patch Locations scia 3 28 The ioxxx and ioyyy Eileen 3 29 I O Driver Entry Points 3 30 CONSID Gli vasene sene 3 30 GE EN 3 31 OE 3 31 DEE eege a 3 31 Consiste 3 32 Zoe pg Re TS 3 32 CONS S E 3 32 MERENER uviss enn 3 33 CREKRPOFE iii ii rien 3 33 OUPO Ee 3 33 Kri Ge VE 3 34 Se i I NE NE 3 34 The Sysinit a FIS ri 3 35 The Syslnit Entry Point 3 35 The SI nitTwo Entry Point eee 3 36 The UseDebug Entry Point 3 36 Ra en Dt e UE 3 38 Theilnitext a Files ein 3 39 3 2 OS 9 OEM Installation Manual Step One Porting the Boot Code Putting the ROM Together 3 40 OS 9 OEM Installation Manual 3 3 Step One Porting the Boot Code Introduction Th
5. Read logical sector zero which contains the bootstrap pointers of the OS9Boot file These values are available at offsets DD BT and DD _BSZ These variables contain e thelogical sector number of the location of the OS 9B oot file DD BT on the disk e thesize of the bootfile DD BSZ itself Call the boot code s memory request routine to obtain memory to hold the OS 9Boot file Read the OS9Boot file into memory Placethe address and size of the loaded OS9Boot data into the OS 9 initial ROM search table The size returned should be the actual bootfile size not the size rounded up to the next sector Totest and debug the disk boot routines you must perform the following steps Preparea bootable OS 9 system disk that contains the system OS 9 modules This disk should have an OS 9B oot file that includes all the modules you have been downloading including the new disk driver and descriptor module OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code Create a bootable OS 9 system disk The method you use depends on if your host system is an OS 9 system or a non OS 9 system e If your host is an OS 9 system and has the same size floppy disks as the target if not use the same procedures as a non OS 9 system format a floppy and use the os9gen utility to create the OS 9B oct file on it You can use the same modul es as your romboot file e If your ho
6. 5 14 5 1 OS 9 OEM Installation Manual Debugging Clock Modules on a ROM Based EE eege 5 15 Creating Disk Drivers A 5 16 Testing the Disk Driver 5 17 Creating and Testing the Disk Boot Routines 5 18 Testing the CBoot Disk Boot Module 5 20 Further Considerations 5 21 Completing the System i 5 22 5 2 Step Three Creating Customized I O Drivers and Finishing the Boot Code Introduction OS 9 OEM Installation Manual In this step you will produce a version of OS 9 that has ticker drivers Real Time clock drivers disk drivers and uses a bootstrap to boot OS 9 from a disk ag fthe target system is to be ROM based and without disk support skip the sections on Creating Disk Drivers Step Three Creating Customized I O Drivers and Finishing the Boot Code Guidelines for Selecting a Tick Interrupt Device Theinterrupt level associated with thetimer should beas high as possible Level 6 is recommended A high interrupt level prevents ticks from being delayed and or lost due to interrupt activity from other peripherals Lost ticks will cause the kernel s time keeping functions tolosetrack of real time This can cause a variety of problems in processes requiring precise time scheduling Theinterrupt service routine associated with the timer should be ableto determine the source of theinterrupt and servicethe request as quickly as possible O
7. OBJDIR rom INITEXT RBGSTB OFILE OBJDIR rommer MAKE make make utility CFP cfp command file processor CFPOPTS s MAKE f S MAKEOPTS MERGE merge REDIR gt CHD chd DEL del ALLFILES TOUCH touch F 12 OS 9 OEM Installation Manual X rom date MAKER CFP CFPOPTS MAKERS MERGE FILES REDIR OFILE clean MAKER CHD RELSDIR DEL ALLFILES end of file OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles rom_common make Makefile for the common boot modules in the OEM example ROM ROOT BASEROOT CPUROOT SRCROOT SDIR TYPE RDIR RDUP LIBROOT SYSDEFS TMPDIR MAKER SYSBOOT OBJECTS OLIB COMDEFS DEFS RBUG MBUGTRC RAMLOAD SPEC_RFLAGS mode compat RC SRCHDIRS RFLAGS TOUCH CHD MERGE REDIR x D GER E base of dir system ROOT 68000 dir system for LIB etc ROOT 68000 dir system for output ROOT SRC dir system for source SRCROOT ROM COMMON specific source dir ROMBUG RELS TYPE Lea RDIR SRCROOT DEFS std OS defs dd rom common make sysboot r use sysboot a instead of CBOOT vectors r boot r SYSBOOT rom common 1l SYSDEFS oskdefs d systype d COMDEFS aROMBUG aMBUGTRC enables MBUG tracing and breakpoints for testing aRAMLOAD support rombug load directly for porting MBUGTRC
8. SSM global static storage a6 system global pointer ERROR cc carry bit set OUTPUT dl w error code if error DESTROYS The Init routine may destroy the values of d0 and dl DESCRIPTION Init is called by 0S 9 during coldstart and serves as the protection module s initialization entry point Init initializes the following e Any system global variables e The protection hardware e SSM service requests OS 9 OEM Installation Manual SSM Module Structure continued OS 9 OEM Installation Manual Using the OS 9 System Security Module Thename of the memory protection module usually ssm must be included in a list of extension module names found in the system configuration module init This informs the kernel to link to the protection module during coldstart and if found to execute its init entry point The init entry point is run in system state before any user state processes have begun If necessary the protection module may declare its own static global vsect variables If a vsect is included the vsect data is allocated and cleared at coldstart and a pointer to these variables is passed to the init routine in the a3 register NOTE Initialized variables are not allowed in the vsect The kernel never deallocates or reuses the vsect memory If the SSM service requests areinstalled with a3 intact the kernel also passes this vsect pointer to each service routine when it is called This enables the
9. e Set the system s ticks per second value D_TckSec e Addthetick timer tothe system interrupt polling table e Call the tick timer s initialization routine Attempt to link to a module called rtclock If thertclock module is not found then return e Without error if the caller is setting the time explicitly e An error if the caller is asking to read the real time clock Ifthertdock module is found then call the module s e setimeentry if the caller is explicitly setting the time e getimeentry if the caller is reading the current time OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code Ticker Support The tick functions for various hardware timers are contained in the tkXXX a files There are two ticker routines e Tick initialization entry routine This routine is called by tickgeneric and enables the The ticker module name is timer to produce interrupts at the desired rate user defined and should be included in the Init module e Tick interrupt service routine This routine services the tick timer interrupt and calls the kernel s clock service routine ThetkXXX a and the tickgeneric a files are linked together as a single tkXXX module Real Time Clock The real time clock functions for various real time clock Support devices are contained in the rtcXXX a files The two real time clock routines are e Get time This
10. BOOTOBJS MVME050 CMC MB2470 MVME050 MVME107 MVME320 MVME374 OEM_MINIMUM 68020 Fr CMDS DEFS LIB PORTS SYS BOOTOBJS MVME133_4 MVME147 MVME165 MVME167 CPU32 CMDS DEFS LIB PORTS SYS BOOTOBJS BCC332 BCC340 WW349 As you can see there is a different subdirectory structure for each processor family in the 68000 architecture Commands and system modul es common across all 68000 families re side in 68000 CMDS and 68000 CM DS BOOTOB S Similarly descriptors for VM E Bus peripherals MVM E 050 MVM E 320 and MVME 374 that apply to all 68000 families reside in the respective directory in 68000 PORTS Clock drivers specific to the MVM E050 are built in 68000 SYSMODS GCLOCK MVME050 Each PORTS directory contains directories for example ports to various target VME Bus pro cessors MVM E 107 in 68000 PORTS MVME 133 4 MVME147 and MVME 165 in 68020 PORTS BCC332 BCC340 and WW349 in CPU 32 PORTS OS 9 OEM Installation Manual 1 17 Getting Started Directory Contains CBOOT General purpose booters and common code libraries SYSBOOT CBOOT TAPE Boot tape driver source subdirectories CBOOT BOOTP timer sources TIMER COMMON Common assembler sources for all boot ROMs DEBUGGER ROM bug debugger source ROMBUG DISK Assembly language boot disk drivers LIB Intermediate object libraries for linkage into target ROM images MVME050 Assembly language system
11. BOOTROOT sysboot 1 1 SYSBOOT BOOTROOT flushcache 1 1 CACHEFL LSYSBOOT LCACHEFL LCLIB LSYS CLIB LMLIB LSYSL OS 9 OEM Installation Manual LIBDEPS mode compat LC LF LAGS TOUCH CHD MERGE REDIR x rom_image date SYSBOOT CACHEFL CLIB SYS_CLIB MLIB SYSL 168 r FF800000 swam M 3k g b 4 touch chd merge gt ODIR TARGET TOUCH ODIR TARGET FILES LIBDEPS MAKER LC LFLAGS FILES LIBS O REDIR map OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles bootio c Copyright 1993 by Microware Systems Corporation Reproduced Under License This source code is the proprietary confidential property of Microware Systems Corporation and is provided to licensee solely for documentation and educational purposes Reproduction publication or distribution in any form to any party other than the licensee is strictly prohibited include lt sysboot h gt my favorite loop function define LOOP for utility routines define ESC Ox1b define CR 0x0d define TAB 0x09 define BS 0x08 define BEL 0x07 char getinchar char inchar inchar InChar if inchar gt A amp amp inchar lt inchar CASEBIT return inchar int outhex h u_int32 h u_int32 t 1 0 cha
12. Getting Started The Host System Hardware The Microware provided software the binex and exbin utilities can convert data to S record format if necessary The host system can be any of the following A 68000 family based computer with at least 2MB RAM and OS 9 68000 A Sun computer running SunOS 3 x or 4 x An HP9000 computer running HP UX 6 3 Any 286 PC or greater running DOS The installation procedure may vary at times according to the type of development system being used This is noted when important You will also need the following on the host system A hard disk The directory structure of the files supplied in the distribution package assume that the host system has a hard disk This is for storage capacity not speed If you use floppy disks you must rearrange and edit many of the source files and make files Microware does not guarantee that OS 9 can be rebuilt on a host system with only floppy disks Extra RS 232 serial ports for communicating with the target system PROM programmer and any PROM or microprocessor emulation systems that you choose to use A PROM programmer that can accept data from the host system because you will have to make one or more PROMs Many commercial PROM programmers and emulators which interface through RS 232 serial links accept programming data in the form of Motorola standard S records S records are simply binary data usually object programs converted
13. break if inchar BS if valspec newprmpt TRUE OutChar BEL continue if newval y n 3 else if newval n n 2 else n 4 outerase n valspec FALSE continue if valspec newval inchar if inchar y outstr es valspec TRUE OS 9 OEM Installation Manual Example ROM Source and Makefiles continue if inchar n OutChar o valspec TRUE continue if quit amp amp inchar q I outstr uit valspec TRUE continue newprmpt TRUE OutChar BEL return newval Dummy entry points to satisfy linker until this is put into sysboot 1 void checknvram void outendis error code rc btlist error code rc _endis error code rc_int error code rc_vmeints error_code reconfig OS 9 OEM Installation Manual F 25 Example ROM Source and Makefiles F 26 OS 9 OEM Installation Manual Numerics 68000 1 13 3 28 7 7 8 2 8 4 emulation system 1 4 68008 3 28 8 4 68010 3 28 8 4 E 2 68020 1 13 3 28 8 4 E 2 68030 3 28 8 4 68040 3 28 8 4 68070 3 28 8 4 68349 8 4 CIC bank flags 8 8 683XX processor naming conventions 3 17 68681 serial device B 8 A Adaptec ACB4000 Disk Controller D 6 add devices example D 6 address translation and DMA transfers 8 13 baud rate 1 7 OS 9 OEM Installation Manual INDEX BERR 7 7 binboot c A 4 binex 1 4 boot ker
14. 02de 57ca dbeq 02e2 5242 addq w OS 9 OEM Installation Manual Q Wait 8 wait queue use immediately if found Q Dead 7 dead process use immediately Q Sleep 6 timed sleep queue Q Sleep 5 untimed sleep queue Q Debug 4 inactively debugging Q Event 3 event queue Q Active 2 active queue lowest priority Q Currnt 1 currently running OPref number of entries in table a0 temp proc desc ptr al task table entry ptr a2 preference tbl ptr a3 best process found d2 d3 a0 a3 a7 save regs 0 d3 clear best queue type found MAXTASK 1 d0 number of tasks available 1 for dbra al a0 get next task s proc desc ptr P QueuID a0 dl get the process queue ID OPref pc a2 get queue type preference tbl ptr 0Types 1 d2 number of table entries 1 for dbra a2 di find preference of queue type d2 FindTsk20 repeat until found 1 d2 adjust preference Using the OS 9 System Security Module 02e4 b23c 02e8 660a 02ea 082a 02 0 6602 02 2 5342 02 4 b403 02 6 651c 02 8 6210 02fa b43c 02fe 6214 0300 3228 0304 b26b 0308 640a 030a 1602 030c 2648 030e b63c 0312 6408 0314 51c8 0318 4a03 031a 6718 031c 7000 031e 206b 0322 2008 0324 670e 0326 3028 032a 4268 032e 4cdf 0332 4e75 0334 323c 0338 003c 033c 60 0 FindTsk30 FindTsk40 FindTsk50 FindTsk60 FindTsk90 FindTskER move b movea 1 cmp b bhs s dbra tst b beq s moveq movea 1 move 1 beq s move w clr w movem 1 rts move w
15. MWOS directory structure 1 11 N NoClock 5 12 non contiguous boot file 7 4 O OMTI5400 D 2 Controller D 3 OS 9 cache control 8 2 download 4 8 soft bus errors 7 7 OS 9 Boot failed B 5 OS 9 driver D 2 OS 9 OEM Installation Manual Index OS9Boot 5 18 5 22 os9gen 5 18 7 4 OS9P2 modules 4 4 os9svc m 1 14 oskdefs d 3 11 OutlHex A 9 Out2Hex A 9 Out4Hex A 9 OutChar 3 31 OutChar A 8 OutHex A 8 OutPort 3 33 OutRaw 3 31 outstr A 7 P PARITY 3 15 patch locations 3 28 PD SSize 9 3 physical sector size 7 2 Port 4 4 port comm 3 30 console 3 30 PortDeln 3 34 porting boot code 2 7 kernel 2 7 porting OS 9 2 1 Portlnit 3 32 PORTS directory 1 17 powerof2 A 11 Priority 4 5 problem resolution 3 40 B 2 PROM emulators 1 5 R RAM memory define normal search area 3 26 RAMVects 3 15 3 21 3 23 RB2333 D 4 OS 9 OEM Installation Manual RB5400 D 4 RBF media conversion 9 6 support for variable sector sizes 9 2 reach32 m 1 14 read A 6 real time clock device 5 7 real time clock support 5 9 register conventions before enteringthe kernel 3 25 when jumping to SysBoot 3 24 relocation register ROMbug 4 9 requirements target 1 5 ROM 1 12 configuration values 3 13 debuggers 3 5 global data space 3 26 ROM debugger prompt power up 2 4 rom make 3 7 rom_common 3 8 ROM based system 5 15 ROM based target system 5 3 romboot c A 5 ROMBUG 3 15 ROMBug B 11 ROMbug 1 5 caching 8 9 RomBug 2
16. OS 9 Cache Control Address If drivers adopt these methods the driver will function A irrespective of the address translation issues Boot drivers can Translation and also deal with this issue in a similar manner by using the DMA Transfers TransF act global label in the bootstrap ROM continued 8 14 OS 9 OEM Installation Manual RBF Variable Sector Support MEAT armi 9 2 RBF Device Drivers zioni iano 9 3 Converting Existing Drivers to U se Variable Sector Size Support sssr 9 4 RBF Media Conversion 9 6 Benefits of Non 256 Byte Logical Sectors 9 7 BOCKstrap DFIVErs scri aa 9 8 RBE DISKUTIIIES ira 9 9 OS 9 OEM Installation Manual 9 1 RBF Variable Sector Support Introduction Refer to the OS 9 Technical LO Manual for information about RBF The Random Block File Manager RBF supports sector sizes from 256 bytes to 32768 bytes in integral binary multiples that is 256 512 1024 32768 This section addresses the issues that areimportant for writing or modifying disk drivers to support variable logical sector sizes E OS 9 Version 2 4 was the first release of RBF to support variable sector sizes If you are modifying disk drivers that only support 256 byte logical sectors you should read this section carefully OS 9 OEM Installation Manual RBF Variable Sector Support RBF Device RBF uses the SS VarSect GetStat function to dynamically e determine whether the
17. OS 9 OEM Installation Manual Trouble Shooting Setting Up the DevCon Descriptor Field for the Sc68681 Serial Driver There is an area of 256 bytes with the kernel s system globals called OEM Global Data The kernel does not use this area OEMs may use it for whatever they like The MC68681 serial device has a peculiar feature in that two of its registers are write only registers These registers are e Thelnterrupt Mask Register IMR e The Auxiliary Control Register ACR Because this device has three functions Serial port A serial port B and a ticker changes to these two write only registers must be communicated to other drivers using this device The sc68681 driver generates a shadow register pair of the IMR and ACR within the OEM Global Data area In this way the driver running for port A can communicate changes for the driver running for port B as well as the ticker routines One shadow register pair is required for each physical 68681 serial device used in the system so that the drivers for each side of each device can communicate with each other The allocation of each pair is communicated to the driver via the DevCon section of the SCF Descriptor for each logical device An example allocation is Device fl A side port TERM pair 1 Device fl B side port TI pair 1 Device 2 A side port T2 pair 2 Device 2 B side port T3 pair 2 etc Each pair of bytes co
18. Sector Size Support Continued These types of drivers are known as deblocking drivers as they combine split the physical sectors from the disk into the logical sectors RBF requires OS 9 OEM Installation Manual RBF Variable Sector Support The media logical and physical sector sizes were NOT the same I n this case the driver would translate the logi cal sector count and starting LSN passed by RBF into a physical count address convert those values to the physical disk address if required and then perform the I O transfer You can convert drivers written with this method to variable logical sector operation although they may require more work than non deblocking drivers Apart from adding the code to handle the GetStat SS_VarSect call you should remove e Thedriver s deblocking code e Any hardwired assumptions about sector sizes and fixed buffers In effect you are converting the driver from a deblocking driver to a non deblocking driver RBF Variable Sector Support RBF Media Conversion Refer to the Utilities Reference manual for information about using format Once you have updated the driver tosupport the new RBF you need to decide whether or not to convert your media specifically hard disk drives to non 256 byte logical sector sizes e If you convert your media you must reformat it e Ifyou are using a 256 byte logical sector size you can immediately use the media when
19. abba Using the OS 9 System Security Module d0 SPU Task set SPU task register P_SPUImg a2 a0 get process SPU image ptr a0 d0 none allocated should be impossible A11Tsk90 exit if so SPU_RAM al get base of SPU image RAM 256 S_SPUBlks a3 256 blocks AllTsk60 move only 64 longs if so a0 d0 d7 update SPU image d0 d7 0 4 al 128 pages a0 d0 d7 d0 d7 8 4 al 128 pages 16 4 al al move to second half of SPU image a0 d0 d7 d0 d7 0 4 al 128 pages a0 d0 d7 d0 d7 8 4 al 128 pages a7 d1 d7 a0 restore regs a7 d0 al a2 restore regs exit kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Subroutine FindTsk Pas sed Returns Find a task number to assign to a process Process currently assigned a task number are examined to find the least active Its task number is then deallocated for use by the new process al Task Table ptr a6 system global data ptr d0 w task number found cc carry set dl w error code if error Destroys dl Queue preference high to low 02be 00 OPref dc b 02bf 00 dc b 02c0 00 dc b 02c1 00 dc b 02c2 00 dc b 02c3 00 dc b 02c4 00 dc b 02c5 00 dc b 00000008 QTypes equ Register use d0 task loop counter dl temp queue type d2 task priority pref d3 best preference found 02c6 48e7 FindTsk movem 1 02ca 7600 moveq 02cc 303c move w 02d0 2059 FindTsk10 movea l 02d2 1228 move b 02d6 45fa lea 02da 7407 moveq 02dc b21a FindTsk20 cmp b
20. about disk drivers You should now create a disk driver for your target system This is similar to creating a console terminal driver as in the previous step However disk drivers are more complicated Again you can use a Microware supplied sample disk driver source file as a prototype If the target system has both floppy disks and hard disks you should create the floppy disk driver first unless they both use a single integrated controller You can create the hard disk driver after the system is up and running on the floppy You must have a test disk of the correct type with OS 9 formatting e If you are using an OS 9 based host system this is no problem because you can make test disks on the host system e Ifyou are using a cross development system UNIX DOS etc you should obtain sample pre formatted disks from Microware Werecommend that you make a non interrupt driver for the first time This can make your debugging task easier Make a new download file that includes the disk driver and descriptor modules along with one or two disk related commands such as dir and free for testing If you are using the ROM bug ROM debugger include the driver s stb module for easier debugging You can addthe previously tested and debugged console driver and descriptor modules to your main system boot at this time This minimizes download time as in the previous step OS 9 OEM Installation Manual Step Three Creating Custo
21. if timer is at fixed I RQ level RT CBase Real time clock device address if using a real time clock Set up the Init module s CONFIG macro to reflect the tick module name and the system ticks per time slice value For example ClockNm dc b tk147 0 tick module name Slice set 4 ticks slice default is 2 if this field is not specified OS 9 OEM Installation Manual Using Generic Clock Modules continued Philosophy of Generic Clock Modules OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code Create a makefile which specifies the system s tick module and if necessary real time clock Use the example makefile makefile in the GCLOCK directory as a model Make the tick module and if necessary real time clock with the make utility Make the Init module Create a bootfile for the system to include the new I nit module tick module and if necessary real time clock module Using generic clock modules has proven to be a successful flexible method for tailoring OS 9 clock functions to a variety of hardware configurations The following is a partial list of the benefits of using generic clock modules You only need to write the hardware specific portions of the tick timer code If you want real time clock support you only need to write the hardware specific portions of the code The real time clock module is only essential to system op
22. 0 or 1 respectively Se Type If equated to H 68K an onboard chip accessible baud rate generator is available A flag TimPort will need to be equated to address of this baud rate generator Codes within this conditionalized code will need to be modified to set the baud rate generator correctly If there is no chip accessible baud rate generator SerT ype should not be defined at all ConsType If equated to R68560 1068560 is used for console 1 0 CommT ype If equated to R68560 i068560 is used for communication 1 0 CPUTypelf equated to CPU29 another flag BusWidth will need to be defined BusWidth label will determinethe addressing for the registers on the 68560 If CPU Typeis not defined at all the default addressing or bus width is 2 registers are accessed on every other byte By default the driver will access registers starting at the base address If you wish to start accessing the registers at base address 1 equate label OBdT ypeto 2 Upgrading from Version 2 3 Flags for io68562 a Flags for io68564 a ConsT ype If equated to S68562 i068562 driver will handle console I O CommType If equated to S68562 1068562 will handle communication 1 0 CPUType This label can be defined to CPU 30 If not defined or defined to be something else the registers of the 68562 will start at the Cons Addr or Comm Adr and be addressed by every byte If this label is set to CPU 30 another label BusWidth will need to be
23. 2 2 Understanding the OS 9 Booting Process i 2 3 Tne Four Pong SES svever Spel 2 7 OS 9 OEM Installation Manual iii 3 Step One Porting the Boot Code IMEFOAUCEron isla aaa le 3 4 About the Boot E alare 3 5 How to Begin the Port The Boot Code ii 3 6 Testing the e e e ee aeree 3 7 ROM Image Versions asia nale Saar 3 7 Component Files of the ROM Image iii 3 8 Mate E EE 3 10 TheOskdefs d File sorso solai elia 3 11 The Systype d NEE 3 12 The ROM Configuration Values 3 13 Target Specific Labels iran ella 3 13 Target Coniguration Ek PAS lille 3 15 CPUTyp Label and Supported Processors vvvrrnrrrrrrrrrnnrnnnnnvvrrrrrrsrnnrrrrrersssnnnnnnr 3 17 Low Level Device Configuration Labele A 3 18 Target System Memory Labels kk ENEE 3 19 Example Memory Definitions kk ENNEN 3 19 TRE VEUS a File Lasses e da eee 3 21 TVG OGG SPE nihil alii 3 22 Steps Boot a Goes Through to Boot the Kernel i 3 22 Memory Search ll E lge EE 3 26 The RAM SCARY EE 3 26 The Special Memory Search iii 3 27 The Pat We Le AE 3 28 The ioxxx and ioyyy FIG s iaia aiar iii 3 29 YO Driver EE EEN 3 30 ConsDel n Deinitialize Console Port from Polled Mode 3 30 OutRaw Output Character to Console Device 3 31 OutChar Output Character to Console Device 3 31 InChar Read Character from Device s Input Port n 3 31 Consl nit Initial
24. 256 bytes allows more file segment entries in the file descriptor RBF Variable Sector Support Bootstrap Drivers In general the RBF driver deals with the same issues hard wired assumptions about 256 byte sectors for example as the BootStrap driver The next section contains more information about booting concerns with variable sector sizes Converting RBF drivers and media to non 256 byte logical sectors alsoimplies a changetothe bootstrap code if the media is to continue to provide system bootstrap support If the BootStrap driver is to support booting from any logical sector size note the following The BootStrap driver must be able to read the identification sector LSN 0 of the media Depending on the actual hardware situation and capabilities this may require e Querying the drive for the sector size that is Mode Sense command to SCSI drives e Reading a fixed byte count from the drive that is partial sector read e Attempting to read the sector using all possible sector sizes Once LSN 0 has been successfully read the BootStrap driver should inspect the DD LSNSizefield of sector zero This field gives the media s logical sector size if it is O a size of 256 is assumed and this value combined with the known physical size allows the BootStrap driver to load the actual bootstrap file If the logical and physical sector sizes differ the BootStrap driver can use deblocking algorith
25. A 14 elle Tt EE A 14 MN A 15 SA NEE A 15 SVSIESEL mn tiene retired A 16 NWPDIODEI sicario A 16 OS 9 OEM Installation Manual Introduction CBOOT is mainly written in C Examining the code in the CBOOT directory can answer many questions OS 9 OEM Installation Manual The C Boot Technology OS 9 Version 3 0 is the first release to recommend the C booting technology referred toas CBOOT Although CBOOT requires a larger amount of ROM space than the assembler boots supported in previous releases it has several added features CBOOT allows you to create drivers in either C or assembly In previous versions the boot routines had to manage the device and have a knowledge of the file structure from which it was booting The CBOOT system provides front end code for various booting methods Such as disk and tape which make calls to the hardware level boot drivers This greatly simplifies the writing of boot code as the only code you need to write is generally the actual code to manage the hardware interface You can also create a driver source that can be conditionalized such that it could be used as a boot driver as well as an OS 9 driver see the MWOS OS9 SRC 10 RBF DRVR SCSI RBTEAC directory as an example You can interface previous assembler booters into the CBOOT system relatively easily Toupdate existing boot drivers to use with CBOOT use the sysboot m macro For example boot320 a has been updated to w
26. A 6 test for existence A 16 high level drivers D 4 host defined 1 3 interconnection with target 1 7 requirements 1 4 host CPU D 3 hwprobe A 16 1 0 drivers entry points 3 30 subroutines 3 29 InChar 3 31 InChar A 8 InChChek 3 33 InChChek A 8 init A 6 initdata c A 4 initext a 3 39 Iniz boot driver A 14 InPort 3 34 input port read character from 3 31 Insert A 12 1 29 INSTBERR 7 7 instr A 7 instruction cache 8 11 interrupts mask A 15 Inttoascii A 10 IO 1 12 10 Xxx 3 29 lo yyy 3 29 io2661 a C 2 i06850 a C 3 i068560 a C 3 i068562 a C 4 i068564 a C 4 i068681 a C 5 i068901 a C 6 IOMAN 1 12 loxxx a 2 7 ioxxx a 3 8 loyyy a 2 7 ioyyy a 3 8 ioz8530 a C 6 IRQLevel 4 4 K KERNEL 1 12 kernel coldstart routine 4 10 porting 2 7 tests 6 3 L label definitions example 3 14 Idora m 1 14 LIB 1 12 logical sector size 7 3 low level I O driver flags C 2 M Compat2 8 7 8 8 8 12 MACROS 1 12 1 30 Index macros 1 14 MainFram 4 3 make utility 1 8 makefile defined 1 8 makelower A 10 MAKETMPL 1 13 MANUAL_RAM_ 3 15 mask_irq A 15 MC68451 and SSM EA Mem Beg 3 19 Mem End 3 19 MemDefs 3 19 3 24 3 26 example 3 19 memory read requested number of blocks into A 6 memory management units MMU E 2 memory map information 3 12 memory search 3 26 misc c A 4 Motorola 68451 E 2 Motorola 68851 E 2 MPU incompatible with OS 9 kernel B 5 MPUType 3 23 MVME147 D 3 D 6 MVME147 CPU D 4
27. Manual 2 7 Porting OS 9 The Four Porting Steps continued Creating customized I O drivers and finishing the boot code In this porting procedure more high level drivers are developed and debugged for other serial ports disk drivers and controllers clocks and any other available devices Once the high level drivers are working you can modify the boot code to boot from the various devices which are available The C Boot routines are good in this regard For example once the basic port of a board has been completed porting procedure s and a high level driver for a floppy drive or other installable media is developed next Once it is Known to work you can format a floppy disk and install an OS 9 bootfile on the floppy At this point you can create a low level driver for C Boot which may use much of the same logic and code as the high level driver which will boot the system from the floppy Testing and Validation This involves the final testing and verification of the complete system Your distribution package was designed to follow this procedure OS 9 OEM Installation Manual Step One Porting the Boot Code IMEFGAUCHOn arnie 3 4 About the Boot Code 3 5 How to Begin the Port The Boot Code 3 6 Testing the Boot Code 3 7 ROM Image Versions 3 7 Component Files of the ROM Image n n 3 8 The Def file File
28. Olfa 4231 clr b al dl w Olfe 3601 Protec50 move w d1 d3 0200 e44b lsr w 2 d3 0202 8530 or b d2 a0 d3 w 0206 5241 Protec60 addq w Hl dl 0208 e5la rol b 2 d2 020a 51c8 dbra d0 Protec40 020e 7000 moveq 0 do 0210 4cdf Protec90 movem 1 a7 d0 d3 a0 0214 4e75 rts KAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Subroutine AllTSsk exit if not decrement SPU block count protect block if zero skip if no underflow reset block count lt lt possible glitch gt gt copy block number convert block number to byte offset protect block in SPU image move to next block shift mask for next block repeat until end of area requested clear carry a2 restore regs update SPU image if changed end task table 1 ptr 1 dbra continue if unused task number found find an appropriate task to use times four bytes per long form ptr to task table entry mark task number in use by this process Allocate task number to current process update SPU image if necessary The SPU task register is set to the allocated number Passed a3 SPU global data ptr a4 current process descriptor ptr to allocate a6 system global ptr Returns cc carry set dl w error code if error Destroys dl Data S_TskTbl S_SPUBlks Calls FindTsk Note the task table is an array of pointers to bi the process descriptor that each task is using ALLTsk 0216 48e7 movem 1 d0 al a2 a7 save regs 021a 246c movea l P SPUMem a4 a2 get SP
29. RAM list has the following structure struct dumbmem struct dumbmem ptr ptr to next free block u_int32 size size of this block Multiple blocks are defined by adjacent structures together A NULL pointer terminates the RAM list Exception jump table pointer This is a pointer to the exception jump table for which boot a set up RAM space The ROM list This is the area of ROM found by boot a Its memory structure is the same as the RAM lists OS 9 OEM Installation Manual The coldstart Routine OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O With the preceding parameters coldstart performs the following steps O Fill in default values into the system globals The kernel or system global variables are assigned default values in this step Determine if this is the correct kernel for the processor The kernel checks the value boot a determined the processor to be with an internal value with which the kernel was made This determines if this is the correct kernel for the processor Set up system exception jump table The kernel fills in the jump addresses in the exception jump table Boot a allocated space for the exception jump table and filled in the code to push the exception addresses However it does not know at the time what address the kernel will be at Allocate and initialize system process descriptor initial module directory and dispatch table
30. Serial Port This is the baud rate for the serial port This code is explained fully in the SCF section of the I O Technical Manual Module Name of Device Driver This name is determined by the programmer and is used by the I O system to attach the device descriptor to the driver Along with the nit module you can add the TERM descriptor to the makefile The driver uses these values to determine the parity word length and baud rate of the device These values are usually standard codes that device drivers use to access device specific index tables These codes are defined in the OS 9 Technical Manual Step Two Bringing Up the Kernel and Console I O Creating a Console I O Driver Refer to the OS 9 Technical Manual the OS 9 Technical I O Manual and the sample source files supplied for guidance Refer to the Utilities Reference manual for more information about ident and fixmod You must create an OS 9 driver module for the console device There is a good chance that Microware has an existing driver that is based on the same device your target system uses If this is the case the set up of the proper configuration labels within the systyped file for the device is all that is required Otherwise you must create a new driver module The easiest way to create a new driver module is to modify an existing Microware supplied serial driver Along with the Init module and the term descriptor you can als
31. Up At this point the kernel is fully functional coldstart next the System the Rest calls a routine called cold2 to bring the system the rest of the of the Way way up The cold2 routine performs the following steps Enable IRQs This part enables the IRQs that boot a disabled This is necessary because the following steps include the initiation of devices which may need IRQs enabled Execute Pre lO modules cold2 executes any modules that have been defined in the PrelO list in the Init module Execute IOMan modules cold2 executes any modules that have been defined in the lOMan list in the Init module The default OMan module supplied by Microware does the following e Initialize the system console The system console usually specified as term is opened Any errors that result from the open are displayed as the message can t open console term 4 12 OS 9 OEM Installation Manual Cold2 Bringing Up the System the Rest of the Way continued OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O TheM Consol field in the nit module specifies what theconsoledevicenameis Thelabel ConsolNm from the systyped file sets M Console e Initialize the system device IOMan performs a chd to the system device which will initialize the device The system device is obtained from the M SysDev field in the I nit module and the SysDev label in the systyp
32. a different address The Init module s colored memory lists provide a way to set up the local external addressing map for the system Device drivers can determinethis mapping in a generic manner using the F Trans system call Thus you should write drivers that have to deal with DMA devices in a manner that ensures the code will run on any address mapping situation You can do this using the following algorithm If you must pass a pointer to an external bus master call the kernel s F T rans system call e If F Trans returns an unknown service request error no address translation is in effect for the system and the driver can pass the unmodified address to the other master e fF Trans returns any other error something is seriously wrong The driver should return the error to the file manager e IfF Transreturns no error the driver should check that the size returned for the translated block is the same as the size requested If so thetranslated address can be passed to the other master If not the driver can adopt one of two strategies Refuse to deal with split blocks and return an error to the file manager Break up the transfer request into multiple calls to the other master using multiple calls to F Trans until the original block has been fully translated Drivers usually adopt method as the current version of the kernel does not allocate memory blocks that span address translation factors
33. area Passed d0 l size of area dl b permission requested Read_ Write_ Exec_ a2 address of area requested a3 SPU global data ptr a4 process descriptor requesting access h a6 system global ptr Returns cc carry bit set dl w error code if error Destroys none Data S_BlkBit Calls none Permit 00b2 48e7 movem 1 d0 d3 a0 a2 a7 save regs 00b6 4a80 tst 1 do zero size requested 00b8 6700 beq Permit 90 exit if so 00bc 74ff moveq 1 d2 sweep reg 00be 0801 btst WriteBit dl write permission requested 00c2 6706 beg s Permit10 continue if not 00c4 0202 andi b i ReadProt WritProt d2 allow reads and writes 00c8 600a bra s Permit20 continue 00ca 0201 Permit10 andi b Read Exec dl read or exec permission request 00ce 6772 beg s Permit 90 exit if not 00d0 0202 andi b ReadProt d2 allow reads 00d4 4aac Permit20 tst 1 PSSPUMem a4 is SPU process memory allocated 00d8 6604 bne s Permit25 continue if so 00da 616c bsr s ALLSPU allocate SPU image amp block counts 00dc 6564 bcs s Permit 90 abort if error 00de 7600 Permit25 moveq 0 d3 sweep register 00e0 162b move b S_BlkBit a3 d3 get SPU block size power 2 n 00e4 220a move 1 ai dl copy beginning block address 00e6 d081 add 1 d1 do form end of requested area 1 ptr 00e8 5380 subq 1 1 d0 end of requested area 00ea e6a8 lsr l d3 d0 convert end addr to last block num 00ec e6a9 lsr l d3 dl convert address to block number OS 9 OEM Installation Manual Us
34. block to return insert returns the new pointer to the head of the memory list NOTE This pointer is also found in the global variable freememlist extract getbootmem Allocate Memory for Bootfile SYNOPSIS DESCRIPTION error code getbootmem sizereq u int32 sizereg indicated size of requested memory block getbootmen allocates memory for a bootfile via the extract function If memory for a bootfile has already been allocated by some previously called function getbootmem returns that block to the system via the insert function sizereq indicates the size of the requested memory block The pointer to the bootfile memory allocated is returned in the global variable bootram The actual size of the memory allocated is returned in theglobal variable mensize If an error occurs getbootmem returns the error code to the caller Otherwise it returns SUCCESS OS 9 OEM Installation Manual The C Boot Technology gethexaddr Read Hexadecimal Address SYNOPSIS DESCRIPTION void gethexaddr gethexaddr reads the console input device for a hexadecimal address up to eight characters in length 32 bits This address is then converted to a 32 bit integer and returned to the caller gethexaddr ignores any character received from the console other than hexadecimal ASCII a carriage return or the letter qor Q The letter q or Q returns a special abort error designation of 3 to the caller If a
35. boot a boot a e Sets up the registers according to the kernel s specifications e Jumps tothe execution entry point in the kernel OS 9 OEM Installation Manual 2 5 Porting OS 9 For more information about the kernel s cold routine refer to Chapter 4 Bringing Up the Kernel and Console IVO Kernel entry point to prompt The cold part of the kernel finishes the task of booting OS 9 It sets up variables in the system global data table commonly referred to as the system globals It also e Builds the kernel s RAM memory pools by searching the memory list e Builds the module directory by searching colored memory ROM areas special memory areas and ROM memory areas e Initializes system tables such as the device path table From here it will Open the console device Chd tothe system device Execute any P2 modules from the I nit modules E xtens list amp Fork the first process The cold part of the kernel will then disinherit the first process and exit by calling the kernel s system execution loop The OS 9 system should now be booted and executing as expected OS 9 OEM Installation Manual Porting OS 9 The Four Porting F our steps are required to port OS 9 on your target hardware The following chapters explain these procedures in greater Steps detail Porting the boot code This procedure includes steps and of the OS 9 boot Chapter 3 Porting the Boo
36. can occur Try moving the libraries to the end and see if that helps OS 9 OEM Installation Manual Trouble Shooting Step 2 Porting If you encountered problems during Step 2 Porting the OS 9 Kernel and Basic 1 0 System look for the error the OS 9 Kernel message that you received and read that section carefully and Basic I O System e MPU incompatible with OS 9 kernel You are using the wrong kernel for that specific processor The boot code has produced a bus error stack frame and from this it has determined which specific processor is being run that is 68000 68010 68020 68030 There is a specific kernel for each of these processors and the wrong kernel is being used e OS 9 Boot failed can t find init The kernel could not find the Init module Verify that the I nit module is in the same special memory bank as the kernel and that it has a module name of Init This error can also occur when boot a finds an exceedingly For additional information small amount or noRAM Verify the amount of RAM about d0 and a4 refer to SN by register dO and a4 at the first boot stage Code e Can t allocate name of gt table The kernel is trying to allocate room for its own table and has run out of RAM Verify the amount of RAM by register dO and a4 at the first boot stage The error message usually reports an error number in e Can t open console terminal Hex to indicate the reason e w
37. code endc ends OS 9 OEM Installation Manual Using the OS 9 System Security Module After nam ssmdefs ttl definitions for system security module KAKAAAAAAAAAAAAAAAAAAAA This file contains definitions which may need to be changed for diferent applications of the MC68451 These include the base address of the MMU chip and the Address space table registers used for the various types of memory accesses HF OF opt 1 use lt oskdefs d gt use lt systype d gt opt 1 psect ssmdefs 0 0 0 0 0 kkkkkkkkkkkkkkkkkkxk Define the address of the MMU chip MMU_Addr equ FA8000 assume heurikon AST register definitions for Eltec VEX CPU Eltec uses the normal layout as described in the Motorola MC68451 manual MMU_UserData equ 02 offset to user data entry in ast MMU_UserCode equ 04 to user s code MMU_SysData equ 0A to system data MMU_SysCode equ 0C to system code ends Once the ssmdefs a file has been modified to match your hardware you can assemble ssmdefs a and link it to the ssm r file the relocatable code for the MC68451 SSM module to create the ssm object code A makefile is included on the distribution disk for this purpose To accomplish this follow these two steps Change to the SSM 451 directory Enter makessm451 For example chd hO MWOS OS9 SRC SYSMODS SSM SSM451 make ssm451 You can now install the SSM module on your system E 6 OS 9 OEM Installation Manual A
38. debug additional drivers as required by your target system The clock driver is a must and you may also need other drivers for hard disks parallel ports etc A sample clock driver module is included in the distribution package You can continue to usethe ROM debugger for testing these Add the additional OS 9 modules for pipes RAM disk etc your OS9Boot file and test it Also do not forget to edit the startup password and motd files as appropriate for your system If the target system is to be ROM based you may want to edit and reassemble the init and or sysgo modules so they directly call your application program instead of sysgo or shell upon startup Make a final version of the boot ROM for distribution In most cases the final version will not have ROM bug You can create the ROM version by entering make f rom make OS 9 OEM Installation Manual OS 9 OEM Installation Manual Step Four Testing and Validation General Comments Regarding Testing 6 2 KEANE TESE aridi iii 6 3 Serial 1 O SCF Tests Lr 6 4 DISKO RBF TeSt nnn enednn 6 5 EIK T SS used 6 6 Piel TESTS ui 6 7 System Configuration Checkout 6 8 A Final Note iii 6 9 Step Four Testing and Validation General Comments Regarding Testing The quickest basic test of a new installation is to start using thesystem immediately This usually reveals major problems if they exist Thetests described in this section can h
39. define Definitions Continued Mem Beg or Spc Beg as 0 Mem Beg is usually offset by 0x400 bytes to allow room for the vector table This is especially important if VBRBase is set to an area of RAM The memory location of the vectors and general system RAM memory must not exist in the same place If you have a ROM bank that starts at 0 then be sure to offset the Spc Beg by an even number of bytes usually 2 to 4 The following is another MemDef example This example has multiple banks of RAM and special areas MemDefs macro dc 1 Mem Beg Mem End 1st RAM bank start end address dc 1 Meml Beg Meml End 2nd RAM bank start end address dc 1 Mem2 Beg Mem2 End 3rd RAM bank start end address dc 1 0 Null terminator dc l Spc Beg Spc End 1st special bank start end addr dc 1 Spcl Beg Spcl End 2nd special bank start end addr dc 1 0 Null terminator 1 0 0 0 0 0 0 0 0 Additional padding for patching The additional areas for patching allow you to patch the memory list without remaking the ROM image MPORTANT During the initial porting phase it is often customary to define an area of RAM as special memory in addition to any ROM areas The reason for this is that when you try to debug As described later in boot a any high level drivers either the serial driver or O So da PE later the disk driver it is easier to download the sel mener SNE driver toRAM debug it there make changes in the non destructive read only source and when reb
40. developer to select the booting method algorithm best suited for the system A int getbootmethod Initialize the boot drivers F 8 OS 9 OEM Installation Manual Example ROM Source and Makefiles NOTE The order of initialization determines the order of priority when using the AUTOSELECT booting method iniz boot driver binboot nulstr Boot Manually Loaded Bootfile Image ml iniz boot driver romboot ROM Boot from ROM ro iniz boot driver loadrom ROM Load from ROM lr iniz boot driver sysreset nulstr Restart the system q vflag TRUE return USERSELECT getboottype When the boot method determined by the above function is set to SWITCHSELECT this function allows the developer to select the actual booting type device ROM etc according to hardware switches non volatile RAM or hard code a single boot device type NOTE for this devpak this is a dummy function Bdrivdef getboottype return NULL OS 9 OEM Installation Manual F 9 Example ROM Source and Makefiles rombug make Makefile for OEM example ROM with ROMBUG b TYPE RELSDIR OBJDIR ROMBUG RELS TYPE CMDS BOOTOBJS TYPE ROMBUG customization flags RBUG RBUG aROMBUG CBUG TDIR TYPE TYPE TARGET ROMDBG Testing options MBUGTRC MBUGTRC aMBUGTRC RAMLOAD RAMLOAD aRAMLOAD MAKERS rom common make ro
41. dump and ROMbug prompt If you are debugging O drivers and want to insert breakpoints do so now Type gb again This should start the system If all is well and a breakpoint was not encountered first you should see the following display Shell If the shell does not come up see the next section for debugging instructions If you included some utilities such as mfreeand mdir you can run them Go to Chapter 5 if the system seems to work properly Step Two Bringing Up the Kernel and Console I O Cold Part of The kernel uses a routine called coldstart to boot itself Kernel Refer to The Boot a File section in Chapter 3 Porting the Boot Code for more information about the available growth methods Before coldstart can run properly boot a must pass it the following information Total RAM found by boot ROM This is an unsigned integer value of the total amount of ROM that boot a found The processor or MPU type This is the processor number that is 68000 68010 68040 as determined by boot a System debugger active flag This unsigned character will be non zero if you have selected to boot by boot stages Warmstart flag This unsigned character is the growth method determined by boot a The ROM entry point This is a pointer tothe Rest flag in boot a The kernel uses this pointer if it ever reboots itself The RAM list This isthe RAM list found by boot a This
42. in systyped defines the memory to initialize Specify that you must explicitly enable RAM memory This enabling is usually performed in SysI nit Therefore the 32 bit bra to Sysl nit does not work if you have not enabled the RAM Toallow operation in this situation define MANUAL RAM and the call to Syst nit will be a straight bra instruction This means that the bra target must be within a 16 bit offset Step One Porting the Boot Code Label Effect TRANSLATE Definethe valueto use for the boot driver DMA address translation If the local CPU memory appears at a different address for other bus masters boot drivers can access the global TransF act label to determine the system s address translation factor If this label is not defined TransFact defaults to 0 VBRBase Define the address for the system s Vector Base Register 68020 68030 68040 and CPU 32 processors only Boot code can access the global VBRPatch label defined in boot a to determine where the vectors are located If this label is not defined VBRPatch defaults to 0 CPUTyp Specify the CPU type Valid values for CPUTyp are defined in the next section 3 16 OS 9 OEM Installation Manual Step One Porting the Boot Code CPUTyp Label and Supported Processors The large number of variations of processors available from Motorola makes it important to ensure that the label CPUT yp defined in systyped for your system is correctly set so t
43. initialization support routines for the MVME 050 SERIAL Assembly language low level console and communications port drivers TAPE Assembly language boot tape drivers OS 9 OEM Installation Manual Additional Reference Materials OS 9 OEM Installation Manual Getting Started If you are not familiar with OS 9 review some of the other Microware manuals All of the manuals listed here are pertinent to the installation process and are included with the software distribution Using OS 9 Utilities Reference Manual OS 9 Technical Manual The Assembler and Linker Manual The Programmer s Toolbox OS 9 ROM Debugger User s Manual OS 9 Technical I O Manual Review these books until you have a basic idea of how OS 9 works and how it is organized You should be familiar enough with these manuals so that you can easily locate essential information for reference Other reference books may also be useful depending on your system s configuration You can order the following reference books from your Microware distributor Using PCBridge Using UniBridge Using FasTrak FasTrak System Administrator s Manual OS 9 68000 System State Debugger User s Manual OS 9 Insights Depending on your hardware configuration you may find some or all of the following reference books useful You can order these reference books directly from Motorola or through most bookstores MC68020 32 Bit Microprocessor User s Manual Prentice Hall M
44. is running you can reference the system globals with either RomBug or SysDbg to see the module directory For example d vbr 3c 10 Thename string of the module is pointed to by a pointer stored at offset Oxc into the module This offset is the offset of the name string from the beginning of the module This can be referenced indirectly from the debugger and added on tothe beginning of the module Use the following debugger to find the name of the first module d vbr 3c vbr 3c c The second and third module names can be found as follows d vbr 3c 10 vbr 3c 10 c d vbr 3c 20 vbr 3c 20 c As a shortcut to displaying the modules the following sequences of commands can be used ROMbug rl vbr 3c d r1 r1 c 10 rl rl 10 Simply use control A repeatedly after entering the second line to display the names in the module directory in sequence OS 9 OEM Installation Manual C Low Level Driver Flags FROAN see C 2 Flags for 16266018 WEE C 2 Flags for 106850 dvd C 3 Flags for 10685604 aiar n iaia C 3 Flags for 10685628 ini C 4 Flags for 1068564 C 4 Flags for io68681 a ssesseerrrresesrrererrrrrrsrsrrern C 5 Flags for io68901 a aaa C 6 Flags for 1028530 a ui iii C 6 OS 9 OEM Installation Manual C 1 Upgrading from Version 2 3 Introduction Flags for i02661 a This appendix explains the low level I O driver flags for each driver in the Port
45. like to have different boards handle different interrupt levels The base of all your control registers on your board starts at address F 800 0000 and the offset to this particular register is 8 The register isa single byte with each bit corresponding to a interrupt level Setting the bit enables the interrupt Conceptually the register may look something like the following 7 0 F8000008 NA L7 L6 L5 L4 L3 L2 L1 L IRQ Level Step One Porting the Boot Code Target Specific Labels Continued Your label definitions for this register might look like the following Define control registers ControlBase equ 800 0000 Other registers defined IRQControl equ ControlBase 8 Other registers defined Define Control Register Values LevellEnable equ 00000001 Level2Enable equ 00000010 Level3Enable equ 00000100 Level4Enable equ 00001000 Level5Enable equ 00010000 Level6Enable equ 00100000 Level7Enable equ 01000000 DisableAll equ 0 LowlevelEnable equ LevellEnable Level2Enable Level3Enable HighLevelEnable equ Level4Enable Level5Enable Level6Enable EnableAll equ LowLevelEnable HighLevelEnable Level7Enable NOTE This is only an example and more than likely will not be valid for your hardware However it does show you how to handle these definitions e If your hardware has a lot of special registers such as these this can be a lengthy list e If your hardware does not have many registers like this the
46. low level ioxxx a drivers the scxxx signifies a specific high level driver For example sc6850 is the high level driver for the 6850 serial device and so on The Init module must be within the same bank of special memory as the kernel Otherwise the kernel will not be able to find the Init module The serial driver and descriptor can be loaded into a RAM special memory bank for debugging purposes In the second step of the porting process you will actually load and run the OS 9 system Because you are now at the OS 9 system level you are dealing with the OS 9 modules Most of the OS 9 modules needed for the OS 9 system are already supplied For a basic OS 9 system use the following modules kernd scf ioman sysgo cio recommended she csl math recommended fpu fpsp040 if you are porting to 68040 Because these modules are supplied ready to run you can burn them into ROM within a special memory area To complete this step of the port you need to make or create three other modules within the I O directory Name Description Init The kernel s configuration data module Tem A descriptor for a high level console serial driver SCXXX High level console serial driver NOTE ThelO directory contains the source to the high level drivers and descriptors To create these three modules you need to e Expand the systyped file e Create a makefile within the 1O directory As with th
47. message desired for the boot driver on a menu line This entry is also used when the AUTOSELECT method is used to inform the user from which boot device SysBoot is attempting to boot For example Now trying to lt menuline gt idstring is a pointer toa null terminated character string that is the identification code to tell SysBoot which boot driver to call This string appears in the menu at the end of a menu entry to indicate to the user what to type in to select a given boot driver idstring is also used to match the string returned by getboottype in order to determine the boot driver selected calldebug Invoke System Level Debugger SYNOPSIS DESCRIPTION void calldebug calldebug starts the system level debugger If no debugger is present the system reboots when the call is made OS 9 OEM Installation Manual The C Boot Technology mask_irq Mask Interrupts SYNOPSIS DESCRIPTION u intl6 mask irq mask u intl6 mask mask irq masks theinterrupts in the 68xxx MPU status register tothe level indicated by the interrupt mask bits in the parameter mask mask irq returns the previous contents of the status register to the caller NOTE mask is actually inserted directly into the 68xxx MPU status register The caller must ensure that the supervisor state bit is not changed The condition codes are also affected NOTE mask irq does not take steps to preserve the trace flag If soft breakpoints
48. module returns an error because it lacks real time clock hardware The system time will be invalid but time slicing will occur You can correctly set the real time once the system is up For example you could run setime from the startup file The system has a working tick module and real time clock support If the NoClock bit in the Init module s M Compat byte is clear the kernel performs the F STimecall Thetick timer code is executed to start the tick timer running and the real time clock code is executed to read the current time from the device If the time read from the real time clock is valid no errors will occur and system time slicing and time keeping will function correctly You do not need to set the system time OS 9 OEM Installation Manual Automatic System Clock Startup continued OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code If the time read from the real time clock is not valid the real time clock code returns an error This could occur if the battery back up malfunctions The system time will be invalid but time slicing will occur You can correctly set the real time once the system is up The system does not have a fully functional debugged tick timer module and or real time clock module In this situation executing the tick and or real time clock code has unknown and potentially fatal effects on the system To debug the modules preven
49. no overflow 1 al dl w reset to max count 255 lt lt glitch gt gt 2 d2 shift mask for next block 1 d1 move to next block d0 Permit 40 repeat until end of area requested 0 do return carry clear a7 d0 d3 a0 a2 restore regs kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Subroutine A11SPU Passed Returns Allocate and initialize SPU structures for new process The data size per process is either 640 or 320 bytes a4 process descriptor ptr cc carry set dl w error code if error Destroys dl 0148 48e7 ALl1SPU movem 1 014c 7000 moveq 014e 302b move w 0152 2200 move l 0154 e480 asr l 0156 2400 move l 0158 d081 add 1 015a d0bc add 1 0160 4e40 os9 0164 6530 bcs s 0166 294a move l 016a 426a clr w 016e 43 2 lea 0172 2549 move L 0176 45ea lea 017a e44a lsr w 017c 5382 subq 1 017e 72 moveq E 20 d0 d2 a1 a2 a7 save regs 0 do sweep register S_SPUBlks a3 d0 get number of SPU blocks per map do di save size of block counts 2 do divided by 4 entries per map byte d0 d2 save size of image map dl d0 get combined size P_SPUImg d0 add size of non map variables F SRqMem request system memory A11SPU90 abort if error a2 P SPUMem a4 save ptr to SPU memory P_Task a2 initialize task number P_SPUImg a2 d2 1 al get ptr to block count map al P_BlkCnt a2 save ptr to block counts P_SPUImg a2 a2 get ptr to image map 2 d2 div size of image map by 4 bytes long 1 d2 minus on
50. possible situations If the system boots from ROM and has disk support you should exclude clock module s from the ROMs until they are fully debugged They can be debugged in the Same manner as for disk based systems If the system boots from ROM and does not have disk support you should exclude the clock module s from the ROMs and download them into special RAM until they are fully debugged Downloading into RAM is required sothat you can set breakpoints in the modules To debug the clock modules Make the Init module with the NoClock flag in the M Compat byte set Program the ROMs with enough modules to bring the system up but do not include the clock module s under test Power up the system so that it enters the ROM debugger Download the module s to test into the special RAM area Bring up the system completely Use the system state debugger or ROM debugger to set breakpoints at appropriate places in the clock module s Run the setime utility to access the clock module s Repeat steps to until the clock modules are operational the clock module s are operational Remake the I nit module so that the NoClock flag is clear Remakethe bootfile to include the new I nit module and the desired clock module s Reboot the system Step Three Creating Customized I O Drivers and Finishing the Boot Code Creating Disk Drivers Refer to the I O Technical Manual for further information
51. protection image is an exact copy of the protection map used by the hardware E 16 OS 9 OEM Installation Manual Using the OS 9 System Security Module Complete Source Listing NOTE Previous versions of the System Security Module were called the System Protection Unit SPU As a result the source code used in this manual refers toSPU rather than SSM Customized 68020 protection module Task Allocation routines nam Task Allocation routines 00000010 Edition equ 16 current edition number 00000c01 Typ Lang equ Systm lt lt 8 Objct 0000a000 Attr Rev equ ReEnt SupStat lt lt 8 0 psect spu Typ_Lang Attr_Rev Edition 0 Init use lt oskdefs d gt opt 1 kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk System Protection Unit SPU hardware definitions 00000040 MAXTASK equ 64 total number of SPU tasks available 01e00000 SPU_RAM equ 1e00000 SPU map image RAM area uses odd addr 01e80000 SPU_Stat equ 1e80000 address of SPU status register 01d00000 SPU_Ct1 equ 1d00000 address of SPU control register 01d80000 SPU_Task equ 1d80000 address of SPU task register SPU task RAM protection bits in map image 00000001 00000002 ReadProt WritProt equ equ 00000001 00000010 enable read protect enable write protect SPU status register currently unimplemented 00000001 E SPU equ 00000001 SPU error 00000002 E IO equ 00000010 I O bus error 00000004 E TimeO equ 00000100 time out error 00000008 E Parity equ 00001
52. r or suffixes You will only have to edit a few source files You will then use the make command to assemble these files and link them with the other I files to create the ROM binary image file Step One Porting the Boot Code How to Begin the The first step in porting OS 9 is to port the boot code or Port The Boot Code _ basically the code that will always reside in the ROM Todo this you need to create several files in a new PORTS lt target gt directory Name The File Should Contain systype d The target system hardware dependent These files are specific to definitions eee S sysinit a Any special hardware initialization that your covered later in this chapter system may require after a reset occurs The files provided in Appendix F are code to a working example and will not work for your particular hardware However these are minimal examples and can be reworked to match your hardware if necessary Create these files in your own PORTS lt target gt directory in one of the processor family object directories In most cases you do not need to write the low level drivers Do not modify the other files iOxxx a and ioyyy a because the Development Kit contains such as vectors a boot a code to many existing devices If you have a device for which and sysboot a Altering code has not been written the entry points needed for drivers these files may cause the port to not function are docu
53. reports the actual required global data space 3 26 OS 9 OEM Installation Manual The RAM Search Continued The Special Memory Search OS 9 OEM Installation Manual Step One Porting the Boot Code The actual RAM memory search is performed by reading the first four bytes of every 8K memory block of the areas given in the search list If a bus error occurs it is assumed that there isnoRAM or special memory in the block Then a test pattern is written and read back If the memory changed the search assumes that this was a valid RAM block and is added to the system free RAM list As described earlier you can define the PARITY label in the systyped file to initialize memory before any read is performed This initialization pattern is F EEDCODE in order to more easily see what RAM was initialized The second part or the special memory part of the search list is strictly a non destructive memory search This is necessary so that the memory search does not overwrite modules that may have been downloaded into RAM or NVRAM During the porting process you should temporarily include enough RAM usually about 64K in the special memory list to download parts of the boot file If this download area has parity memory you may need to e Manually initialize it e Disable the CPU s parity if possible e Include a temporary routine in the sysinit a file The RAM and special memory searches are performed during Step 14 of
54. run at 19 2K Baud If not defined the default is 9600 Baud PACERMOS If this label is defined the CONS port will be on the A side of chip one andthe COMM port will be on the B side of chip two This also sets the port to be even parity and seven bits character CPUType This label has several different definitions Its main purpose is to define the registers on the 68681 are addressed VME 165 addressing is every fourth byte VME135 VME140 VME141 SYS360 MC68340 addressing is every other byte In addition to the above the following CPU Type labels have affects MC68340 There is a separate mode register 2 and this allows coding for it SYS360 Sets up RTS on the CONS port Upgrading from Version 2 3 Flags for io68901 a Flags for ioz8530 a ConsT ype If set to MOS68901 the io68901 a will be used as the console drivers Comm ype If set to MOS68901 the i068901 a will be used on the communications driver BC_68901 This label should be equated to the bus width of the ship s register addressing If not defined the default bus width is two for addressing the registers on every other byte ConsT ype If equated to ZA the A side of the chip is the console port If equated to ZB the B side is the console port CommType If equated to ZA the A side of the chip is the communications port If equated to ZB the B side is the communications port CPUType This will determine the addressing of 8530 If set to VME1
55. ssm 0 endm Other default values may be set here Remake the I nit module by using the makefile located in the OS9 SRC SYSMODS INIT directory make init Make new init module OS 9 OEM Installation Manual Step Two Create a New Bootfile Step Three Test SSM Operation For more information on the maps utility refer to the Using OS 9 Utilities manual OS 9 OEM Installation Manual Using the OS 9 System Security Module Edit the bootlist file so that the SSM you will use appears in that list For example ssm851 for systems using an MC68851 chd MWOS 0S9 680X0 PORTS lt your CPU gt os9gen h0fmt z bootlist Create the bootfile After making the new bootfile reboot the system and test the basic functions of SSM operation To check that the SSM was found and initialized correctly attempt to access a protected area of memory Onememory area that is protected from all user state accesses is the Mem Beg address in the system s systyped file Most systems will have Mem Beg set to 400 debug Call user state debugger dbg d 400 Access Mem Beg 0x00000400 bus error Access prevented bus error results To test the SSM functionality more thoroughly use the supplied maps utility Run maps on all processes in the system and exercise all options of maps maps 1 Loop through all processes Installation of SSM is now complete Using the OS 9 System Security Module Creating a Sy
56. the driver is ready If you are reformatting the media it may only require a logical reformat that is converting a deblocking 512 byte physical sector disk to 512 byte logical In this case you should perform the following steps Backup the media to convert Reformat themedia A physical format is only required if you need or wish to change the media s physical sector size Use the format utility s np option if you do not wish a physical reformat Reinstall the data saved in step Y our conversion to a non 256 byte logical sector size should now be complete OS 9 OEM Installation Manual Benefits of Non 256 Byte Logical Sectors OS 9 OEM Installation Manual RBF Variable Sector Support Using different logical sector sizes can provide the following benefits depending on your application requirements The bitmap sector count will decrease This may mean that you can decrease the minimum cluster size of the media on large hard disks The number of clusters in a bitmap sector will increase This allows faster bitmap searches and potentially larger segments to be allocated in the file descriptor segment list The media capacity may increase Many disk drives both floppy and hard disks can store more data on the disk due to the decrease in the number of sectors per track and thus less inter sector gaps The chances of segment list full errors will decrease Expanding the sector size beyond
57. the port to fit into your particular hardware configuration you will use flags to conditionalize the code that is assembled compiled These flags are fully explained later in this manual You should customize these makefiles to fit your hardware configuration 1 8 OS 9 OEM Installation Manual Common File Name Suffixes Getting Started Microware uses the following file name suffixes to identify file In general OS 9 does not require file name suffixes However certain utilities such as UMACS and cc do require file name suffixes to determine the mode of operation OS 9 OEM Installation Manual types Suffix Definition a Assembly language source code C C language source code d Definitions defs source code for assembly h C header file source code Jl Microware intermediate code I code files Jl Microware intermediate code libraries l Library files m Macro files 0 Assembly language source from the compiler backend Ra Relocatable object code for linker input created by the assembler none Object binary files Getting Started Checking the You should become familiar with the contents of the Contents of the distribution package provided by Microware Verify that it is Distribution e Complete Package e The correct version for your host system The distribution software consists of a set of OS 9 diskettes or tape cartridges Refer tothe MWOS dir
58. timing loops If specific time delays are required you may have to rewrite the loops for a worst case loop Worst case is the quickest time Alternatively you could disable caching for the body of the loop OS 9 OEM Installation Manual Building Instructions in the Data Space OS 9 OEM Installation Manual OS 9 Cache Control Programs that use their data space for building temporary instruction sequences need to flush the instruction cache before executing the sequences Failure to do so may result in unpredictable program behavior OS 9 Cache Control Data Caching and DMA Stale data occurs when another bus master writes to alters the memory of the local processor The bus cycles executed by the other master may not be seen by the local cache processor Therefore the local cache copy of the memory is inconsistent with the contents of main memory Indication of Cache Coherency Direct Memory Access DMA support if available significantly improves data transfer speed and general system performance because the MPU does not have to explicitly transfer the data between the I O device and memory Enabling these hardware capabilities is generally desirable although systems that include cache particularly data cache mechanisms need to be aware of DMA activity occurring in the system so as to ensure that stale data problems do not arise Device drivers that perform DMA are required to ensure that stale
59. to ASCII hex characters in a standardized format A 68000 emulation system optional If possible the emulator should have at least 128K overlay memory The emulator provides handy real time debugging facilities and the overlay memory is a convenient substitute for making ROMs during the testing process OS 9 OEM Installation Manual The Host System Software The Target System Hardware OS 9 OEM Installation Manual Getting Started e PROM emulators optional This type of device is most useful with a target that is known to be functional and an existing resident debugger that does not have downloading capability or when no debugger exists and no emulation system is available The OS 9 Developer s Kit is a source release for Original Equipment M anufacturers OE Ms designed to be installed on a host system Use of the OS 9 Developer s Kit requires a separately available toolkit designed for the host system The types of toolkits available are e FasTrak or UniBridge for Unix systems e PCBridge for MSDOS PCs e A resident toolkit for OS 9 systems Each of the above toolkits includes the Ultra C compiler assembler and linker and all utilities necessary to rebuild OS 9 The target system should consist of the following hardware e A 68000 family CPU e Atleast 128K RAM 512K is recommended e Atleast 64K ROM capacity or an emulator with 64K of overlay memory however 128K is required if you plan to use ROM
60. 000 parity error SPU control register bits 00000000 Mem2MB equ 00000000 two megabyte address space 00000001 Mem4MB equ 00000001 four megabyte address space 00000002 Mem8MB equ 00000010 eight megabyte address space 00000003 Mem16MB equ 00000011 sixteen megabyte address space max 00000008 EnabSPU equ 00001000 enable SPU when set 00000010 EnCache equ 00010000 enable 68020 inst cache hardware 0000 0020 SPUSizes de 1 200000 400000 800000 1000000 0010 0d0d BlkSizes dc b 13 13 14 15 corresponding block sizes 2 n 0014 0100 SPUBlks dc w 256 512 512 512 corresponding number of SPU blocks kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk SPU global variable definitions NOTE this memory is allocated and cleared but NOT initialized by OS 9 vsect 00000000 ds b 1 reserved 00000001 S_BlkBit ds b 1 system block size as a power of 2 00000002 S_SPUBlks ds w 1 of blocks the addr space is div into 00000004 S_TskTbl ds 1 MAXTASK SPU task allocation table 00000000 S_MemSiz equ size of global storage 00000000 ends kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk OS 9 OEM Installation Manual Using the OS 9 System Security Module SPU process variable definitions 00000000 00000000 00000002 00000006 P_SPUImg FF FF FF HF F P_Task P BlkCnt org do w 0 1 task number assigned to process 1 ptr to block count map beginning of SPU image map task number ptr to blk counts SPU image I 64 or 12
61. 17 VME 107 or VME 162 the addressing starts at Cons Addr or Comm Adr 1 and is accessed on every byte ConsBaud Setting this sets the console device baud rate If this is not defined the label WR12Std will need to be set This label is set to the value to be put into write register 12 to set the baud rate CommBaud Same as ConsBaud except that is sets the baud rate for the communications port WR14Std This label will need to be set up for write register 14 of the 8530 End of Appendix C OS 9 OEM Installation Manual OS 9 OEM Installation Manual D SCSI System Notes OS 9 SCSI System Drivers n D 2 Hardware Configuration D 3 Software Configuration eessen D 4 Example One NR D 5 Example TWO D 6 Example Thre soleil D 6 SCSI System Notes OS 9 SCSI System Drivers When you write a device driver do not include MPU CPU specific code This will make the device driver portable Refer to the OS 9 Technical Manual for more information about device drivers The basic premise of this system is to break the OS 9 driver into separate high level and low level areas of functionality This allows different file managers and drivers to talk to their respective devices on the SCSI bus The device driver handles the high level functionality The device driver is the module that is called directly by the appropriate file manager Device drivers deal with all controlle
62. 5 3 23 rombug make 3 7 rompak m 1 14 ROMPAK2 3 36 RTCBase 5 10 S SB5400 D 4 SCF device descriptor macro definitions 4 4 SCSI bus D 5 SCS1147 DA SCSl system drivers D 2 l 31 search module directory B 11 sector size 7 2 serial 1 O tests 6 4 serial port parity code 4 5 setexcpt A 15 SInitTwo functions 3 36 snoopy absent flags 8 8 soft bus errors 7 7 software configuration D 4 Spc Beg 3 19 Spc End 3 19 special memory 3 27 4 8 SRC 1 13 s records defined 1 4 SS VarSect 9 3 SSM structure E 12 SSM040 E 3 staledata 8 12 streq A 13 SYS 1 12 SysBoot 2 5 3 24 sysboot c A 5 sysboot m 1 14 sysboot glue c A 5 SysCache 8 3 default modules 8 4 syscom c 2 7 syscon c 3 8 SysDev 4 3 SysDisk 3 18 sysglob m 1 14 Syslnit 2 4 3 22 functions 3 35 Sysinit 3 39 sysinit a 2 4 2 7 3 6 3 8 3 35 3 37 3 38 2 Syslnit2 3 23 1 32 Index SYSMODS 1 12 SysParam 4 3 sysreset A 16 SysStart 4 3 system memory list return memory to A 12 restart A 16 system global 3 26 system globals 2 6 system level debugger start A 14 System Security Module SSM E 1 systype d 2 7 3 6 3 8 3 10 3 12 3 20 5 10 T tapeboot c A 5 target defined 1 3 interconnection with host 1 7 requirements 1 5 target specific labels 3 13 temporary instruction sequences 8 11 term A 6 test boot code 3 7 CBoot disk boot module 5 20 disk boot routines 5 18 disk driver 5 17 disk I O 6 5 kernel 6 3 serial I O 6 4 t
63. 8 bytes lt block count map 256 or 512 bytes kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkxk Passed Returns HAN 001c 48e7 0020 226e 0024 4lfa 0028 7003 002a b3d8 002c 53c8 0030 625c 0032 0200 0036 0000 003a 13c0 0040 0240 0044 7600 0046 163b 004a 1743 004e 07c3 0050 4203 0052 2d43 0056 d040 0058 363b 005c 3743 0060 7400 0062 723 0064 e44b 0066 5343 0068 33c1 006e 207c 0074 3003 0076 10c2 Destroys Data D AddrLim Subroutine Init Called by OS 9 coldstart to initialize SPU hardware and related global variables a3 SPU global data ptr a6 system global ptr none dl Init InitSP10 InitSP20 InitSP30 D_BlkSiz movem 1 movea 1 lea moveq cmpa 1 dbls bhi s eori b ori b move b andi w moveq move b move b bset clr b move L add w move w move w moveq moveq lsr w subq w move w movea 1 move w move b d0 d2 d3 a0 a1 a7 save regs D AddrLim a6 al get highest accessable address SPUSizes pc a0 table of possible SPU block sizes 3 d0 a0 al would this spu size be large enough d0 InitSP10 keep searching if not InitErr abort if address space too large 0011 do convert to SPU ctl word size EnabSPU EnCache d0 add SPU amp cache enable bit s d0 SPU Ctl enable SPU 0011 d0 strip out SPU blocksize index 0 d3 BlkSizes pc d0 w d3 get size of spu block power of 2 d3 S_BlkBit a3 set it d3 d3 conver
64. AK2 These macros are defined in the file SRC MAC ROS rompak m The initext code is activated by placing the initext routines onto the end of the boot ROM image so that they are located immediately after the bootROM image in ROM Both example makefiles rombug make and rom make perform this concatenation OS 9 OEM Installation Manual Step One Porting the Boot Code Putting the ROM Together Refer to the Utilities Reference manual for information about using romsplit You are now ready to begin your port At this point you should create your own specific files and try to make everything into a final ROM image You can use the example files within this manual to help you begin If you have problems when trying to make your image such as assembler or linker errors you will need to O Verify that systyped is configured correctly Verify that sysinit a is referencing the labels within systype d correctly Make sure that the makefile has the correct names of your customized files ioxxx a and ioyyy a After the files have been assembled and linked properly you can make a ROM or load the code into the emulator overlay memory w TNelinker output is a pure binary file If your PROM programmer or emulator requires S records use the binex command to convert the data If your PROM programmer cannot burn more than one8 bit wide PROM at a time and your system has the ROMS addressed as 16 bit or 32 b
65. Beg equ 0 Spc2 End equ 0 endc kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Hardware type definitions MPUChip equ 68000 define the microprocessor in use CPUTyp set MPUChip pay the old label ifeq CPUType VME162 IOBase equ FFF00000 TERMBase equ IOBase 45000 Zilog 85230 SCC TermBase equ TERMBase 4 SCC port A console port ConsType equ ZA Cons_Adr equ TermBase console device address TlBase equ TermBase 4 SCC port B communication port for download CommType equ ZB Comm_Adr equ TlBase auxilliary device address endc kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkxk Configuration module constants used only by init module CONFIG macro MainFram dc b OEM example target 0 SysStart dc b sysgo 0 name of initial module to execute SysParam dc b 0 parameters to pass to initial module SysDev set 0 ROM based system has no disk ConsolNm dc b term 0 console terminal pathlist ClockNm dc b tk_oem 0 clock module name Extens dc b os9p2 syscache ssm sysbuserr fpu 0 endc Colored memory list definitions for init module user adjustable F 4 OS 9 OEM Installation Manual Example ROM Source and Makefiles align MemList MemType type priority attributes blksiz addr limits name DMA offset on board ram covered by boot rom memory list doesn t need parity iniz MemType SYSRAM 250 B_USER ProbeSize Mem Beg Mem End OnBoard CPUBeg TRANS dc 1 0 terminate this list OnBoard dc b on board ram 0 e
66. C68030 Enhanced 32 Bit Microprocessor User s Manual Prentice Hall MC68881 MC68882 Floating Point Coprocessor User s Manual Prentice Hall Getting Started Additio na I MC68851 User s Manual Prentice Hall Reference e CPU32 Reference Manual M a eh al S d Motorola con Mug MC68332 SIM User s Manual Motorola TPU Reference Manual Motorola Programmer s Reference Manual Motorola You can order this reference book from Signetics or Philips 16 32 Bit Highly Integrated Microprocessor SCC68070 User Manual Philips Parts I hardware and Il software 1 20 OS 9 OEM Installation Manual OS 9 OEM Installation Manual 2 Porting OS 9 Getting Started ns 2 2 Understanding the OS 9 Booting Process 2 3 The Four Porting Steps rai 2 7 2 1 Porting OS 9 Getting Started Once you have installed all of OS 9 s boot code sources driver sources and system modes such as the kernel the sheer volume of files may overwhelm you Knowing your hardware well will make it easier for you to port OS 9 to it The following information is extremely helpful You should keep in mind that Microware provides example source files for many during the porting procedure different types of device drivers whether they be e What I O devices do you have serial disk controller i i ere a a e e How are these devices mapped into memory CUI CU NS Sg MEER e How is the memory organized target hardware has availab
67. DESCRIPTION Q N ConsSet Input None Output None ConsSe disables the console port from causing interrupts It is called each time the debugger is called but is intended to disable interrupts from occurring primarily after the system has been booted up and the system debugger is being used that is to trace through system code or when the break utility is called ConsSet should save the state of the device so that ConsDeln can restore it OS 9 OEM Installation Manual Step One Porting the Boot Code InChChek Check Console Port SYNOPSIS DESCRIPTION InChChek Input None Output dO 1 Character read or 1 if no data available InChChek checks the console input port to determine if a character is available to be read and if so return the character If no character is available InChChex must return 1 This is similar to the ChekPort routine for the Comm port ChekPort Check Comm Port SYNOPSIS DESCRIPTION ChekPort Input None Output d0 1 character read or 1 if no data available ChekPort checks the Comm input port to determine if a character is available to be read and if so return the character If no character is available ChekPort must return 1 This is similar to the InChChek routine for the Console port OutPort Output Character on Comm Port SYNOPSIS DESCRIPTION OutPort Input dO bi character to write Output None OutPort outputs a character on theComm port wi
68. Memory for these tables are allocated and initialized The system service routines are installed into the kernel at this time Locate Init module coldstart searches for the Init module in the same bank of memory in which the kernel resides Once the Init module is found system parameters are copied from it and put into the system globals Find system RAM coldstart searches RAM and builds the kernel s free memory list Either the RAM that boot a found is verified or the colored memory list if defined is used instead Both pattern matching and bus error is used to verify RAM Search ROM list for modules coldstart builds the module directory from the ROM list boot a found and from any colored memory having an attribute of B ROM Step Two Bringing Up the Kernel and Console I O The Coldstart Call the ROM debugger Routine continued The system debugger flag parameter which was passed to coldstart from boot a is checked If it is set coldstart calls the ROMbug This allows you to set breakpoints to aid in the debugging of drivers for applications Allocate memory and initialize system tables coldstart allocates memory and initializes the system tables These tables include the process descriptor table IRQ polling table device table and path descriptor table This step also includes setting up the alternate I RQ stack and moving the system stack pointer to the system process descriptor Cold2 Bringing
69. OS 9 OEM Installation Manual OS 9 OEM Installation Manual COPYRIGHT AND REVISION HISTORY Copyright 1993 Microware Systems Corporation All Rights Reserved Reproduction of this docu ment in part or whole by any means electrical mechanical magnetic optical chemical manual or otherwise is prohibited without written permission from Microware Systems Corporation Source Code Version OS 9 Version 3 0 A Revision Publication date November 1993 Product Number IST680ERAMO DISCLAIMER The information contained herein is believed to be accurate as of the date of publication However Microware will not be liable for any damages including indirect or consequential from use of the OS 9 operating system Microware provided software or reliance on the accuracy of this documentation The information contained herein is subject to change without notice REPRODUCTION NOTICE The software described in this document is intended to be used on a single computer system Micro ware expressly prohibits any reproduction of the software on tape disk or any other medi um except for backup purposes Distribution of this software in part or whole to any other party or on any other system may constitute copyright infringements and misappropriation of trade secrets and confidential processes which arethe property of Microware and or other parties Unauthorized distribution of soft ware may cause damages far in excess of the value of the copie
70. P ak These flags deal with chip addressing and other issues that are different between hardware processor boards There are also flags that determine which driver is using the Cons port and which is using the Comm port These flags should be defined in systyped If a driver is included in the PortPak and is not listed here simply view the source to determine what each of the flags do ConsType If equated to SC2661 the driver will handle console 1 O CommType If equated to SC2661 the driver will handle communication 1 0 SerType If equated to DBC68 the registers on the chip are addressed for every byte addressing If this label is not defined or defined to be something else the chip s registers are addresses for every other byte For example if SerType DBC68 these addressing is base 0 baset1 baset2 base 3 if Sa Type DBC68 the addressing is base 0 base 2 baset4 base 6 OS 9 OEM Installation Manual Flags for i06850 a Flags for io68560 a OS 9 OEM Installation Manual Upgrading from Version 2 3 ConsType If equated to MC6850 the i06850 a is used for console 1 0 CommT ype If equated to M C6850 the i06850 a is used for communication 1 0 IOType This flag must be equated to either 0 or 1 This driver will access the 6850 s status register with an offset of zerofrom the Cons Addr or Comm Adr and the data register is accessed either by an offset of 1 or 2 depending on whether IO Type is equated to
71. PU global data ptr a4 process descriptor requesting access a5 caller s register image ptr a6 system global ptr R d0 a5 system minimum block size R d2 a5 size of information buffer used cc carry bit set dl w error code if error GSPUMp GSPUMp20 GSPUMp50 GSPUMp60 movem 1 move 1 move 1 moveq bsr bcs s move l os9 bcs s clr l move l move l beq s lea move 1 moveq move w lsr l cmp l bls s move l move l add 1 move l beq s subq w move b moveq moveq d0 d2 d3 a0 a2 a7 save regs d2 d0 copy block size a0 a2 copy address Write_ Read_ dl request read write permission ChkMem is memory accessible GSPUMp99 abort if not a7 d0 restore process id F GProcP get process descriptor ptr GSPUMp99 abort if error R d2 a5 default no bytes in buffer P SPUMem al al get address of process spu info al d0 is process spu buffer allocated GSPUMp90 exit if not P_SPUImg al a2 get address of protection info P_BlkCnt al al get address of spu block count map 0 do sweep register S_SPUBlks a3 d0 get the number of SPU blocks 1 d2 convert user buffer size to num of blks d0 d2 enough room for entire map GSPUMp20 skip if not d0 d2 copy the entire map d2 d copy number of blocks to move do do convert to bytecount d0 R d2 a5 return the amount of buffer used GSPUMp90 exit if no bytes to copy 1 d2 blockcount 1 for dbra s a2 dl1 get the next permission byte 4 d3 numb
72. RAMLOAD aFASTCONS r68 u u SYSDEFS q RBUG aCBOOT SPEC_RFLAGS SRCHDIRS touch chd merge gt rom_common date LIBROOT OLIB TOUCH Sg LIBROOT OLIB OBJECTS CHD RDIR MERGE OBJECTS REDIR RDUP OS 9 OEM Installation Manual OBJECTS DEFS MAKER OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles rom_serial make Makefile for the I O driver in the OEM example ROM ROOT gaf eal oa base of dir system BASEROOT ROOT 68000 dir system for LIB etc CPUROOT ROOT 68000 dir system for output SRCROOT ROOT SRC dir system for source SDIR SRCROOT ROM SERIAL specific source dir TYPE ROMBUG RDIR RELS TYPE RDUP LIBROOT RDIR SYSDEFS SRCROOT DEFS std OS defs SYSMACS SRCROOT MACROS TMPDIR dd MAKER rom Serial make OBJECTS ioz8530 r OLIB rom serial l COMDEFS SYSDEFS oskdefs d DEFS systype d COMDEFS RBUG aROMBUG MBUGTRC aMBUGTRC enables MBUG tracing and breakpoints for testing RAMLOAD aRAMLOAD support rombug load directly for porting SPEC_RFLAGS MBUGTRC RAMLOAD aFASTCONS mode compat RC r68 SRCHDIRS u u SYSDEFS u SYSMACS RF LAGS q RBUG aCBOOT SPEC RFLAGS SRCHDIRS TOUCH touch CHD chd MERGE merge REDIR gt x rom Serial dat
73. S RC r68 RSRCHDIRS u u SYSDEFS u SYSMACS RFLAGS q RBUG aCBOOT SPEC_RFLAGS RSRCHDIRS F 18 OS 9 OEM Installation Manual Example ROM Source and Makefiles TOUCH touch CHD chd MERGE merge REDIR gt x rom_port date LIBROOT OLIB TOUCH LIBROOT OLIB OBJECTS CHD RDIR MERGE OBJECTS REDIR RDUP SYSINIT DEFS MAKER SYSCON MAKER OS 9 OEM Installation Manual F 19 Example ROM Source and Makefiles rom_image make Makefile for linked rom image in the OEM example ROM b ROOT BASEROOT CPUROOT SRCROOT BOOTROOT SYSROOT TYPE RDIR RDUP LIBROOT TMPDIR MAKER ODIR TARGET ROMDBG ROMIO FILES CLIB LCLIB SYS_CLIB LSYS_CLIB MLIB LMLIB SYSL LSYSL SYSBOOT LSYSBOOT CACHEFL LCACHEFL LIBS e ec Bal ws ROOT 68000 ROOT 68000 ROOT SRC SRCROOT ROM LIB BASEROOT LIB base of dir system dir system for LIB etc dir system for output dir system for source ROMBUG RELS TYPE EF E RDIR dd rom image make CMDS BOOTOBJS TYPE rombug BOOTROOT rombug 1 BOOTROOT romio 1 LIBROOT rom_common 1 LIBROOT rom_port 1 LIBROOT rom_serial 1 ROMDBG ROMIO SYSROOT clib 1 1 CLIB SYSROOT sys clib 1 1 SYS CLIB SYSROOT os_lib 1 1 MLIB SYSROOT sys 1 1 SYSL
74. S 9 OEM Installation Manual OS 9 Tick Timer Setup OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code You can set the tick timer rate to suit the requirements of the target system You should define the following variables Ticks Per Second This valueis derived from the count value placed in the tick timer s hardware counter It reflects the number of tick timer interrupts that will occur each second Most systems set the tick timer to generate 100 ticks per second but you can vary it A slower tick rate makes processes receive longer time slices which may make multitasking appear sluggish A faster rate may burden the kernel with extra task switching overhead due to more rapid swapping of active tasks Ticks Per Time Slice This parameter is stored in the I nit module s M Slicefield It specifies the number of ticks that can occur before the kernel suspends an active process The kernel will then check the active process queue and activate the highest priority activetask Thel nit module sets this parameter to a default value of 2 but this can be modified with the CONFIG macro in the system s systyped file by setting the Slice definition to the desired value Tick Timer Module Name The name of the tick timer module is specified in the nit module Use the ClockNm entry in the systyped file s CONFIG macro to define this name For example ClockNm dc b tk147 0 tick
75. Type Max Beg Max End CopyBack dc l 1 terminate list If needing to turn off caching on a particular area another field can be added to the cache list The following is an example cache list CPUALIGN CacheList NOTE that these have been constructed to match the regions defined in the MemType entries above CacheType Mem Beg Mem End CopyBack CacheType Max Beg Max End CopyBack CacheType 0x 0000000 0x f f f CISer dc l 1 terminate list The above cache list will turn off cachingin VME standard space and VME short I O space NOTE Thelnit module controls a number of other features of caching Thelnit module fields M Compat and M Compat2 are used for this control Features controlled are e Cache burst mode 68030 only e Cache coherency hardware snoopiness e Code bank enabling 68349 only 8 6 OS 9 OEM Installation Manual Custom Configuration for External Caches The module produced with the SYSCACHE macro is specific for the target system making all cache hardware operational OS 9 OEM Installation Manual OS 9 Cache Control The default cache operation modules supplied by Microware only control the on chip caches of the CPUs These caches are the only known guaranteed cache mechanisms for those types of systems When dealing with systems equipped with external or custom hardware caches you can easily produce a customized SysCache module for the individual t
76. U process memory 021e 302a move w P Task a2 d0 task already assigned to process 0222 6712 beq s ALLTsk05 continue if not 0224 08ac bclr ImgChg PS State a4 test clear image change flag 022a 663c bne s Al11Tsk50 022c 33c0 move w d0 SPU_Task select task 0232 6000 bra AllTsk99 exit 0236 43eb AllTsk05 lea S_TskTbl MAXTASK 4 a3 al 023a 303c move w MAXTASK 2 d0 of tasks 1 avoid task 0 023e 4aal A1l1TSk10 tst l al unused task 0240 57c8 dbeq d0 A11Tsk10 keep searching if not 0244 6714 beq s Al11Tsk20 0246 6100 bsr FindTsk 024a 6500 bcs Al1Tsk99 abort if error 024e 3200 move w do di copy task number 0250 e541 asl w 2 dl 0252 43eb lea S_TskTbl a3 al get task table ptr 0256 d2c1 adda w dl al 0258 5340 subq w 1 d0 025a 228c AllTsk20 move 1 a4 al 025c 08ac belr ImgChg P State a4 clear image change flag 0262 5240 addq w 1 d0 0264 3540 move w dO P_Task a2 0268 48e7 AllTsk50 set process task number Update SPU mapping RAM from process SPU image movem 1 dl d7 a0 a7 save regs OS 9 OEM Installation Manual 026c 0272 0276 0278 027a 0280 0286 0288 028c 0292 0296 029c 02a0 02a4 02aa 02ae 02b4 02b8 02bc 33c0 4lea 2008 673a 227c Oc6b 6718 4cd8 48e9 4cd8 48e9 43e9 4cd8 48e9 4cd8 48e9 4cdf 4cdf 4e75 move w lea move 1 beq s movea 1 cmpi w beq s movem movem movem movem lea A11Tsk60 movem movem movem movem A11Tsk90 movem A11Tsk99 movem rts HPHHH
77. WD33C93 chip as the SCSI interface controller but it uses a NEC DMA controller chip Thus you need to create a new low level module for the VME 620 we will call the module SCSI 620 To create this module edit the existing files in the SCSI 33C93 directory to add the VME 620 specific code This new code would typically be conditionalized You could then create a new makefile such as Make vme620 to produce the final SCS1620 low level module The high level driver for the new OMT15400 is already written RB5400 so you only have to create a new device descriptor for the new hard disk Apart from any disk parameter changes pertaining tothe actual hard disk itself such as the number of cylinders you could take one of the existing RB 5400 descriptors and modify it so that the DevCon offset pointer points to a string containing SCSI 620 the new low level module The conceptual map of the OS 9 modules for the system would now look like this nome OS 9 Kernel evel RBF disks b Sl File Manager Level SBF tapes Device Driver Level Physical Bus Level OS 9 OEM Installation Manual D 5 SCSI System Notes Example Two This example adds an Adaptec ACB4000 Disk Controller to the SCSI bus on the MVME 147 CPU To add a new different controller to an existing bus you need to write a new high level device driver You would create a new directory such as RB4000 and write the high level driv
78. a listing of both systyped and oskdefs d Study them so you understand how they are used and how they are related If you have undefined name errors when assembling various other routines later the files were probably not included or were not configured properly Notice that many hardware dependent values and data structures are defined as macros in systyped These macros are used in many other parts of the boot ROM as well as files used in later stages of the installation In particular device driver and descriptor source files reference these macros Step One Porting the Boot Code The Systype d The systyped file should contain the target system File hardware dependent definitions This includes e Basic memory map information e Exception vector methods for example vectors in RAM or ROM e 1 0 device controller memory addresses e Initialization data Definitions that are target specific are all You must create a systyped file before you reassemble any included in the systype dfile other routines This allows you to maintain all target system specific ORI systyped is included in the assembly of many other source files by means of the assembler s use directive You need to make a new systyped file that defines your target system as closely as possible using the sample file provided in the distribution package Some definitions are not used until later in the porting process so some of these definitions are not cove
79. a reference in a library usethe following type of command rdump a lt library 1 gt grep lt reference name gt libgen le lt library 1 gt grep lt reference name gt Once the library reference is found include the library in the LIBS macro of the makefile The ordering of the libraries is incorrect If you find the references are all in the libraries that you are including then the problem may be with the ordering of the libraries The linker is a single pass linker If a function references an external variable or a function that was defined earlier in the same library or another library and if the linker has already moved pass that point thelinker will not be ableto resolvethe reference For this reason the ordering of the libraries is important To determine the ordering of the OS 9 standard libraries e Compile a simple program in verbose mode Ch with Ultra C bp with the version 3 2 C compiler Theccexecutivewill pass thelibraries in the correct order to the linker e Lookatthelinker line generated by the cc executive Trouble Shooting e Note the ordering of the specific libraries in which you are interested Many other libraries need to be linked in front of the standard libraries for they often call functions out of these standard libraries Thelibraries are in the wrong position in the link line Sometimes if the libraries are not included at the end of the linker line unresolved references
80. ach block in the address space Two of the protection module s subroutines F Permit and F Protect will update this map rather than the hardware Another map which contains the number of times specific memory blocks have been made accessible to the program is also kept for each process OS 9 OEM Installation Manual E 11 Using the OS 9 System Security Module SSM Module Structure For more specific information about memory modules refer to the OS 9 Technical Manu al Refer to the Required Subrou tines section of this appendix for more information about these subroutines The System Security Module must conform to the basic structure of all OS 9 modules It must be a system object module with the supervisor state attribute The example code illustrates how the module s psect header establishes this At a minimum you must include seven subroutines in the module body e Init e F Pemit e F Protect e FS AIITSk e F DeTsk e F ChkMem e F GSPUMp E xcept for I nit these subroutines are installed as system calls that the OS 9 kernel calls at appropriate times The subroutines are not large or difficult the challenge in writing a protection module is deciding how to make the memory protection hardware conform to 0S 9 s Memory protection model Asidefrom that the structure of the module depends entirely on the system s specific hardware and the whim of the programmer The required subroutines are INPUT a3
81. al version of flushcachel If you do provide a separate routine do not link the ROM with the default flushcachel library Calls to the ROM debugger through F SysDbg for example using the break utility will work correctly because the system call maintains cache integrity OS 9 Cache Control Peripheral Access Timing Violations Timing Loops When caching is enabled peripheral access timing violations sometimes occur in device drivers especially when tight loops are written to poll device status registers If peripheral devices begin to exhibit erratic behavior you should take the following steps Disable all caching for the system Debug thedriver until it is stable Reenable caching for the system If erratic behavior continues timing violations are probably occurring because of cache hits In this case the driver can e Disable data and or instruction caching during critical sections of the driver for example interrupt service routine e Reenable caching when the critical section is completed When a driver manipulates the cache it should try not to access the cache hardware directly F CCtl calls should be performed instead The driver s code will betransportable and will not conflict with the system s cache control operations Interrupt service routines can call F CCtl therefore cache operations may occur at any time Cache enabling may break routines that use fixed delay
82. al hardware initialization Initialize the Console port and print boot strap message This is the first sign that the system is doing anything 3 23 Step One Porting the Boot Code Steps Boot a Goes Through to Boot the Kernel continued There are several routines written to help sysboot a is a routine that searches the ROM area for the kernel There is no need to adjust this file it will work as is The C boot routines are also available to simplify booting from various devices Step 14 Step 15 Step 16 Perform RAM and special memory searches of memory and parity enable memory if needed The routines use both bus error and pattern matching to determine RAM and ROM sizes This relies on the MemDefs macro to determine the memory areas to search Enter ROMbug if it is enabled The debugger is finally reached At this point everything needed to find the kernel has been done Call SysBoot label to obtain kernel You determine how this codeworks A pointer tothe kernel is all that needs to be returned SysB oot will have the following register conventions when it is jumped to Register Description al Boot ROM entry point a3 Port address from DiskPort label a4 System free RAM list a5 Exception jump table pointer a6 Operating system global data area 4K scratch memory a7 System ROM list When SysBoot returns the following registers must be set as follows Regi
83. any given read If the device cannot read 64K the read entry point must deblock the read term Disable Hardware SYNOPSIS error code term DESCRIPTION term disables the hardware and ensures that any interrupts from the device are disabled OS 9 OEM Installation Manual P The C Boot Technology CBOOT Library Entry Points instr Read String from Console Device SYNOPSIS char instr str size char str pointer to beginning of input string u_int32 size determines buffer size DESCRIPTION instr reads a string from the console device into a buffer designated by the pointer str instr handles the following rudimentary line editing functions Name Description lt CTRL gt X Back up the cursor to the beginning of the line lt CTRL gt A Display the previous contents of the buffer BACKSPACE gt Back up the cursor one character instr returns to the caller when it receives a carriage return n from the console A pointer tothe beginning of the input string is passed back to the caller size is a 32 bit unsigned integer used to determine the size of the buffer to which the input string is written NOTE instr ignores any character other than a carriage return if itis received when the buffer is already full outstr Send String to Console Output Device SYNOPSIS error code outstr str char str ptr to first character in string to be sent DESCRIPTION out
84. are enabled and ROM breakpoints are active mask_irq can disable them and the breakpoint may be missed setexcpt Install Exception Service Rouitne SYNOPSIS DESCRIPTION u_int32 setexcpt vector irqsvc u_char vector vector number u_int32 irqsvc address of exception service routine setexcpt installs an exception service routine directly into the exception jump table vector should be a vector number 2 255 irqsvc should be the address of the exception service routine setexcpt returns the address of the exception service routine previously installed on the vector You can use setexcpt to set up specialized exception handlers such as bus trap and address trap and to install interrupt service routines NOTE Thecaller must save the address of the previously installed exception handler and restore it in the exception jump table via setexcpt once the caller is no longer using the vector OS 9 OEM Installation Manual A 15 The C Boot Technology sysreset Restart System SYNOPSIS void sysreset DESCRIPTION sysreset restarts the system from dead start initialization sysreset does not return to the caller hwprobe Test for Existence of Hardware SYNOPSIS error code hwprobe address char address DESCRIPTION hwprobe tests for the existence of hardware at address hwprobe installs a bus error handler and attempts to read from address hwprobe returns SUCESS if the har
85. arget system This is accomplished with the SYSCACHE macro included in the syscachea file in the SYSCACHE directory If this macro is undefined to syscachea a default no op macro for SYSCACHE allows the file to assemble without error This is how the Microware default modules are produced You may provide a custom SYSCACHE macro in a file called syscachem You can include this file via a local defs file This custom macro should contain the code for manipulating the system s external custom cache hardware Upon entry tothe integrator supplied routine the d0 register indicates which cache operations are desired Theintegrator s routine does not need to check for the validity of operations For example a request by a user to flush the data cache when the data cache is currently disabled by another process results in no flush on the data cache The integrator supplied code does not see the data cache flush request for this particular call Control of cache functionality is implemented via the M Compat2 byte in the Init module OS 9 Cache Control M Compat2 Bit Fields The bit fields within M Compat2 are defined as follows Bit 0 1 Description 0 0 External instruction cache is not snoopy 1 External instruction cache is snoopy or absent 1 0 External data cache is not snoopy 1 External data cache is snoopy or absent 2 0 On chip instruction cache is not snoopy 1 On chip instruction cache is snoopy o
86. at were not included in previous tests Thoroughly exercise the system in multi user interactive operation if appropriate for your application Compile and or assemble large programs OS 9 OEM Installation Manual 6 7 Step Four Testing and Validation System Check that all standard modules are in the OS 9B oot file Configuration including the RAM disk and pipeline related modules Verify that all standard end user distribution files are Checkout on the system disk in the correct directories This includes the standard utility set in the CMDS DEFS and SYS directories Check these for completeness according to the information provided in your License agreement Set up and or customize the motd startup and password files 6 8 OS 9 OEM Installation Manual A Final Note OS 9 OEM Installation Manual Step Four Testing and Validation Congratulations You have completed your first port You may now consider yourself an OS 9 expert If you perform another installation in the future you will probably take some shortcuts compared to the procedures outlined here This is expected It means you have gained a good insight into the system The reason for this is that the technique you followed the first time was not the minimal approach but it is the least risky and most educational method for your first port If you have created new drivers for commonly used peripherals you May want to donate source code to our
87. bank must be large enough to hold the system globals the data area for the ROM debugger and the entire bootfile if booting from a device Refer to the section on the boot a file later in this chapter for more information OS 9 OEM Installation Manual Step One Porting the Boot Code Target system memory labels define where system memory is located The MemDefs macro in the systyped file is the mechanism in the boot code to define Memory It consists of two areas e General system free RAM e Special memory The free RAM is self explanatory The special memory definitions are the areas through which the kernel will search for modules when booting You need to define the following labels Label Description Mem Beg The start of system RAM Mem End The end of system RAM SpcBeg The start of the special memory list SpcEnd The end of the special memory list You can define several banks of non contiguous RAM and special memory The entire RAM list is null terminated and the entire special list is null terminated The following is an example MemDef memory definition MemDefs macro dc 1 Mem Beg Mem End lst RAM bank start end address dc 1 0 Null terminator dc 1 Spc Beg Spc End lst special bank start end addr dc 1 0 Null terminator dc 1 0 0 0 0 0 0 0 0 Additional places for padding endm Step One Porting the Boot Code Example Memory NOTE Sincethe list is a null terminated list never
88. bled during supervisor state accesses e Thekernel assumes that the user state address space may be divided into equal sized blocks which may be protected independently of each other OS 9 OEM Installation Manual Using the OS 9 System Security Module i SSM determines the size of the memory blocks based on the Creating 3 amount of addressable system memory and the protection System Security hardware being used The blocks are usually 4 8 or 16K bytes Module each Smaller blocks are preferred when possible A process continued can access memory in two ways e It may be part of a module to which the process links the process primary module is implicitly linked e t may be part of the process data area Linked modules are not considered to be owned by a process they are owned by the system and the process has been granted permission to access them A process data area is considered owned by the process and must not be accessibleto other processes F or each process the protection module must keep track of the following e The memory blocks the process may access e Theread write permissions for these blocks e Thenumber of times each block has been made accessible to the process In the example code each process has associated with its process descriptor a map of the system memory blocks it may access This map is a copy of the memory protection hardware s task image and contains read write permissions for e
89. bug The 64K ROM is for convenience in bringing up OS 9 If the system is disk based the eventual target system can use as little as 32K for a boot ROM e Two serial 1 O ports one for a terminal and one for communications with the host system These are only required for the porting process e Any other 1 0 devices which OS 9 must eventually support optional These are not used in the initial installation steps Getting Started An existing debugger on a functional target can be used in lieu of an emulation system for debugging the OS 9 boot ROMs until ROM bug is functional enough to be used In this type of configuration the OS 9 boot ROM image can be built to run from RAM However some mechanism must exist to get the image into RAM either by downloading through a serial port using the existing debugger or by accessing memory from another processor in the same system a master CPU ina VMEbus system for example Pre Porting Steps Before you port OS 9 e Makesure the hardware works It is difficult to simultaneously debug the hardware and the software If the target system is an untested prototype use the assembler to make a simple stand alone test ROM that The time invested in writing just prints a message on a terminal to verify basic basic diagnostic software hardware functionality Using emulators and logic that fully exercises memory analyzers aids in simulation of hardware and software I O devices and interrup
90. c initialization part 2 SInitTwo ROMPAK2 rts kkkkkkkkkkkkkkkkkxk UseDebug return status of system debugger enabled not enabled UseDebug btst b 0 CallDBug pc test the debug flag eori b Zero ccr flip the zero bit rts kkkkkkkkkkkkkkkkkkkkkkkkxkk entry points for ifndefCBOOT _stklimit dc 1 80000 _stkhandler rts endc F 6 OS 9 OEM Installation Manual ends end of file OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles syscon c syscon c Boot configuration routines for the OEM example target Edition History Date Comments By LL s teane tc ton e_ ctos t tto cot o otcote c icon t_itco ate 01 93 10 28 Genesis ats L _ _ _ _ _ _ ___ __ ____ _ ___ _ ____ _ ___ __ _ _ _ include lt sysboot h gt ifdef NOBUG int errno u_char trapflag endif ifdef _UCC u_int32 _stklimit 0x80000 big to limit _stkhandler calls from clib 1 calls endif Declarations for real functions extern error_code sysreset binboot char nulstr only need one of these ifdef UCC Dummy _stkhandler routine for clib l calls Ss _stkhandler endif getbootmethod This function allows the
91. carriage return is received from the console and there was no previous input gethexaddr returns a 1 to indicate a no address input error NOTE Any hexadecimal input value from 0x0 to Oxfffffffc is returned to the caller streq Compare Two Strings for Functional Equality SYNOPSIS DESCRIPTION u_int32 streg stgl stg2 char stgl char stg2 streg compares two strings for functional equality The case is ignored on alphabetic characters for example a A If the twostrings match streq returns TRUE 1 Otherwise it returns FALSE 0 OS 9 OEM Installation Manual A 13 The C Boot Technology iniz_boot_driver Initialize Boot Driver SYNOPSIS DESCRIPTION error code iniz boot driver address name menuline idstring void address ptr to execution entry point char name ptr to the boot driver s name string char menuline ptr to message for menu line char idstring ptr to identification code iniz_boot_driver initializes a boot driver by placing the parameters in the boot driver definition array address is a pointer to the boot driver s execution entry point nameis a pointer toa null terminated character string that is the name of the boot driver SysBoot uses this name for messages concerning the boot driver For example An error occurred in the lt name gt boot driver menulineis a pointer to a null terminated character string that is the
92. criptors term and tl are for the lst 68681 device TERM macro SCFDesc TermBase TermVect TermLevel 1 0 14 sc68681 DevCon dc w D_681_1 offset in OEM global storage endm Tl macro SCFDesc TlBase TlVect TlLevel 2 0 14 sc68681 DevCon dc w D 681 1 offset in OEM global storage endm Trouble Shooting Descriptors t2 and t3 are for the 2nd 68681 device T2 macro SCFDesc T2Base T2Vect T2Level 2 0 14 sc68681 DevCon dc w D_681 2 offset in OEM global storage endm T3 macro SCFDesc T3Base T3Vect T3Level 2 0 14 sc68681 DevCon dc w D_681 2 offset in OEM global storage endm Descriptors t4 and t5 are for the 3rd 68681 device T4 macro SCFDesc T4Base T4Vect T4Level 2 0 14 sc68681 DevCon dc w D_681 3 offset in OEM global storage endm T5 macro SCFDesc T5Base T5Vect T5Level 2 0 14 sc68681 DevCon dc w D_681 3 offset in OEM global storage endm B 10 OS 9 OEM Installation Manual Searching the Module Directory OS 9 OEM Installation Manual Trouble Shooting The gb command at the ROM Bug prompt starts the boot stages for ROM Bug This tells the debugger to go in boot stages After the initial go the debugger will break out of the boot procedure just before the boot a code jumps to thekernel This is to check if the boot code performed like it should The registers should bein OS 9 format as documented in the boot a section of Chapter 3 If all seems well another gb in RomBug or gin debug will allow t
93. d by Microware supports only one MMU sotheMMU Addr in the ssmdefs a file should be changed to either 00fa8000 or 00fa8200 You must also remove the conditional code for the Motorola MVME121 for the Eltec VEX CPU OS 9 OEM Installation Manual Using the OS 9 System Security Module Before nam ssmdefs ttl definitions for system security module KAKAAAAAAAAAAAKAAAAAAAAA This file contains definitions which may need to be changed for different applications of the MC68451 These include the base address of the MMU chip and the Address space table registers used for the various types of memory accesses opt 1 use lt oskdefs d gt use lt systype d gt opt 1 psect ssmdefs 0 0 0 0 0 ifndef VME121 VME121 equ 121 endc ifndef CPUType CPUType set 0 endc CPUType set VME121 KAKAAAAAKAAAAAAKAAAAA Define the address of the MMU chip ifne CPUType VME121 MMU_Addr equ FE7000 assume heurikon else MMU_Addr equ F60000 base address of the mmu for VME121 endc ifeq CPUType VME121 AST register definitions for non Heurikon MMU_UserData equ 02 offset to user data entry in ast MMU_UserCode equ 04 to user s code MMU_SysData equ 0A to system data MMU_SysCode equ 0C to system code else AST register definitions for Heurikon MMU_UserData equ 12 offset to user data entry in ast MMU_UserCode equ 14 for user s code area MMU_SysData equ 1A for system data MMU_SysCode equ 1C for system
94. data problems will not occur Typically the driver will need to flush the system caches at appropriate times for example prior to writing data to the device after reading data from the device unless the caches are coherent through hardware means The M Compat2 variable also has flags that indicate whether or not a particular cache is coherent Flagging a cache as coherent when it is allows the kernel to ignore specific cache flush requests using F CCtl This provides a speed improvement to the system as unnecessary system calls are avoi ded and the caches are only explicitly flushed when absolutely necessary F An absent cache is inherently coherent so you must indicate absent as well as coherent caches Device drivers that use DMA can determine the need to flush the data caches using the kernel s system global variable D_SnoopD This variable is set to a non zero value if BOTH the on chip and external data caches are flagged as snoopy or absent Thus a driver can inspect this variable and determine whether a call to F CCtl is required or not OS 9 OEM Installation Manual Address Translation and DMA Transfers OS 9 OEM Installation Manual OS 9 Cache Control In some systems the local address of memory is not the same as the address of the block as seen by other bus masters This causes a problem for DMA 1 O drivers in that the driver is passed the local address of a buffer but the DMA device itself requires
95. dding SSM to the OS 9 Bootfile Step One Create a New Init Module OS 9 OEM Installation Manual Using the OS 9 System Security Module Three steps are required to add SSM to the OS 9 Bootfile e Create a new init module e Create a new bootfile e Test SSM operation Each step is detailed below Tocreate a new init module change your working directory to h0 MWOS OS9 680X0 PORTS lt your CPU gt Edit the system s systyped file CONFIG macro so that the string ssm appears in the nit Module Extension list NOTE Most systems will not define E xtens in this macro because the default extension module 059p2 is defined in init a if no extension module list is given in CONFIG Before CONFIG macro Mainfram dc b Motorola VME 110 0 SysStart dc b sysgo 0 name of initial module to execute SysParam dc b C CR 0 parameter to SysStart SysDev dc b D0 0 initial system disk pathlist ConsolNm dc b Term 0 console terminal pathlist ClockNm dc b mc6840 0 clock module name endm Other default values may be set here Using the OS 9 System Security Module Step One Create a New Init Module continued After CONFIG macro Mainfram dc b Motorola VME 110 0 SysStart dc b sysgo 0 name of initial module to execute SysParam dc b C CR 0 parameter to SysStart SysDev dc b D0 0 initial system disk pathlist ConsolNm dc b Term 0 console terminal pathlist ClockNm dc b mc6840 0 clock module name Extens dc b os9p2
96. de if error Destroys none Data S_BlkBit Calls none ChkMem 037e 48e7 movem l d0 d3 a0 a7 save regs 0382 4a80 tst 1 do zero size requested 0384 675a beq s ChkMem90 exit if so 0386 7400 moveq 0 d2 sweep reg 0388 0801 btst WriteBit dl write request 038c 6704 beg s ChkMem10 continue if not 038e 843c or b WritProt d2 check for writes 0392 0201 ChkMem10 andi b Read_ Exec_ dl read or exec request 0396 6704 beq s ChkMem20 continue if not 0398 843c or b ReadProt d2 check reads 039c 4a02 ChkMem20 tst b d2 read and or write request 039e 6740 beq s ChkMem90 exit if not 03a0 4aac tst l P SPUMem a4 is SPU memory allocated 03a4 6742 beg s ChkMemEr abort if not very strange 03a6 7600 moveq 0 d3 sweep register 03a8 162b move b S_BlkBit a3 d3 get SPU block size power 2 n 03ac 220a move l ai dl copy beginning block address 03ae d081 add 1 dl d0 form end of requested area 1 ptr 03b0 6536 bcs s ChkMemEr abort if address wraparound 03b2 5380 subq 1 1 d0 end of requested area 03b4 e6a8 lsr l d3 d0 convert end address to last block num 03b6 e6a9 lsr l d3 dl convert address to block number 03b8 9041 sub w dl d0 convert to number of blocks 1 03ba 1601 move b dl d3 copy beginning block number 03bc 0203 andi b 50011 d3 strip off lower two bits 03c0 d603 add b d3 d3 make SPU bit offset of first block 03c2 e73a rol b d3 d2 shift request bits into init position 03c4 206c movea l P SPUMem a4 a0 get ptr to SPU process memor
97. defined Also the registers will start at Cons Addr 1 or Comm Adr 1 BusWidth label is set to the number of bytes between each register There are no flag or label definitions for this driver All of the register labels for the 68564 start at Cons_Addr or Comm_Adr and is addressed for every byte If the addressing for your hardware is different these labels will need to be changed to fit your hardware OS 9 OEM Installation Manual Flags for io68681 a OS 9 OEM Installation Manual Upgrading from Version 2 3 The standard version of this code assumes that the Console device is the A side chip port and the communications device is the B side port of the same chip When this situation does not apply you need to implement system specific conditionals via ifdef statement see PACERMOS for example coding For all versions the I MR shadow images for the CONS port is assumed to be held in the first pair of bytes starting at the OEM global area D_Start For the PACER system the MR shadow image for the COMM is expected to reside in the second pair of OEM Globals For further information about OEM Globals and shadow registers please refer to the section in Appendix B Setting Up the DevCom Descriptor Field for the sc68681 Serial Driver There are three label definitions that need to be defined for this driver FASTCONS PACERMOS and CPUType FASTCONS If this label is defined the CONS port and COMM port will
98. der OS 9 lecita 7 7 8 OS 9 Cache Control OS 9 Came Control ae ean 8 2 System Implementation siriaca aaa 8 3 Install Gade Operations aaa 8 3 Default SysCache Modules ia 8 4 Caching TNS LE 8 5 Custom Configuration for External Caches AAA 8 7 MSCompat2 Bit FIAT ul i at 8 8 ROM Debugger and Caches ii 8 9 Peripheral Access Timing Violations ii 8 10 dt ee EE 8 10 Building Instructions in the Data Space i 8 11 Biere ville Eine RT KEEN 8 12 Indication of Cache Coherency kk EEN 8 12 Address Translation and DMA Transfers 8 13 9 RBF Variable Sector Support IER OCIICEION scala 9 2 RBF e RT E 9 3 Converting Existing Drivers to Use Variable Sector Size Support 9 4 RBF EIER A Ce EE 9 6 Benefits of Non 256 Byte Logical SectorsS m rrvvrrmmmmvvvveverrrrrrrrrrrererrnnnrrvererssrrnnr 9 7 Bootstrap Drivers EEN 9 8 RBF Tee EE eege aaa p aaa adaa daaa t a a aaa da EEE 9 9 A The C Boot Technology Fig 6 0 0 ce ANEA nan A EEST ia A 3 TheCBOOT Common BOLENS ipa ani A 4 CBOOT Driver Entry POS iti Ee A 6 vi OS 9 OEM Installation Manual init PFE ZETA RG WOE rale A 6 read Read Number of Blocks Requested into Memory_ A 6 term Disable Hardware rrnnnannvnrrnnnnnnvverrnnnnnnnnevrnnnnnnnnerrnrnnnnsnersernnnneeen A 6 CBOOT Library Entry Points isti dial A 7 instr Read String from Console Device MM n A 7 outstr Se
99. directory which holds yet more subdirectories for each high level SCSI driver In addition to the file manager subsystems there is a SCSI directory for low level SCSI drivers whose usage spans across several file managers See the SCSI system notes in Appendix D for more information about SCSI drivers OS 9 OEM Installation Manual 1 15 Getting Started MWOS OS9 SRC ROM Directory Structure Taking a closer look at MWOS OS9 SRC ROM we see CBOOT COMMON DEBUGGER DISK LIB MVME050 SERIAL TAPE DEFS DISK INETBOOT NETWORK SYSBOOT TAPE TIMERS BOOTLIB BOOT374 BOOT82596 BOOTCMC BOOTMT2ST BOOTVIPER BOOT7990 BOOTBP BOOT327 BOOT33C93 BOOT5380 BOOT53C94 BOOTSCCS DESC These directories are as follows Directory Contains CBOOT Contains almost all of the boot code written in C except for some SCSI driver whose source is shared with the normal running system drivers As can be seen in the above diagram it has a subdirectory structure contained within it CBOOT DEFS Include h files for interface and media independent definitions CBOOT DISK Boot disk driver and descriptor source subdirectories CBOOT BOOTP client source INETBOOT CBOOT BOOTP network driver source subdirectories NETWORK 1 16 OS 9 OEM Installation Manual Getting Started The Object Directories The object directories look like this 68000 rrr CMDS DEFS LIB PORTS SYS SYSMODS GCLOCK MC6830X
100. drive is assumed to be described by the path descriptor n Implies a version 2 4 or later disk drive and the logical sector size is n Thepath descriptor determines the physical sector size If the logical and physical sector sizes do not match the driver must provide such a mapping If the driver is written for use with the CBOOT system this issue is addressed and handled by CBOOT SYSBOOT diskboot c which calls the driver Currently CBOOT does not support a physical sector size that is smaller than the logical sector size If this were necessary the driver would need to manage the mapping As a whole boot drivers should support the formats that are allowed by the high level drivers in the system In the case of floppy disks OS 9 high level drivers allow you to create and use floppy disks at various sector sizes However the boot for floppies assumes that the floppy drive will be formatted with 256 byte sectors This simplifies the driver It also decreases the number of attempts to read the disk before determining the correct format of the disk The current suggested format for floppy disks is the OS 9 Universal Format Miscellaneous Application Concerns Bootstrap File Specifications Refer to the Utilities Reference manual for information about using os9gen Making Boot Files Originally RBF bootstrap files required that they be contiguous and less than 64K bytes in size The os9gen utility insta
101. driver it is calling can support logical Drivers sector sizes other than 256 bytes SSIS RO When you open a path to an RBF device RBF calls the driver DEG auetics ine with SS_VarSect and depending on the results of the call driver to determine if support ere for variable logical sector takes the appropriate action sizes is available Refer to the OS 9 Technical Manual If the Driver EH for more information about Batirns Description SS VarSect Without error RBF assumes that the driver can handle variable logical sector sizes It then uses the PD_SSizefield of the path descriptor to set the media path s logical sector size so that RBF s internal buffers may be allocated etc An unknown RBF assumes that it is running with a service driver that presumes a logical sector size of request error 256 bytes RBF allocates its buffers accordingly and does not usethe PD_SSize field of the path descriptor Any other RBF aborts the path open operation error deallocates any resources and returns the error to the caller Support for variable logical sector sizes is optional under the new RBF as existing drivers operate in the same manner as they do under previous versions of RBF Such as in the second case above OS 9 OEM Installation Manual 9 3 RBF Variable Sector Support Converting Existing Drivers to Use Variable Sector Size Support Refer to the OS 9 Technical Manual for more informat
102. dware is present or E BusE rr if it fails A 16 OS 9 OEM Installation Manual OS 9 OEM Installation Manual Trouble Shooting VAOU O ana B 2 Step 1 Porting the Boot Code rnsnrrnnnnnnnnnnnnnnnnnnn B 3 Step 2 Porting the OS 9 Kernel and Basic LO System UE B 5 Setting U p the DevCon Descriptor Field for the Sc68681 Serial Driver eessen B 8 Searching the Module Directory B 11 Trouble Shooting Introduction This appendix is designed to help if you run into problems while porting OS 9 To use this chapter most effectively Identify during which step of the booting process you are having problems Gotothat section in this appendix Locatethe description that best describes your problem amp Read and follow the directions that you find there B 2 OS 9 OEM Installation Manual Step 1 Porting the Boot Code OS 9 OEM Installation Manual Trouble Shooting If you encountered problems during Step 1 Porting the Boot Code read this section carefully If you are getting unresolved references during linking this error is the result of one of three conditions A library is missing from the link line Two utilities rdump and libgen are available to help you find which library contains the unresolved reference The libgen utility will locate references for Ultra C compiler libraries whilerdump will find references for libraries created with the Version 3 2 compiler To search for
103. e LIBROOT OLIB TOUCH LIBROOT OLIB OBJECTS CHD RDIR MERGE OBJECTS REDIR RDUP F 16 OS 9 OEM Installation Manual OBJECTS DEFS MAKER OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles rom_port make Makefile for port modules in the OEM example ROM ROOT ET es base of dir system BASEROOT ROOT 68000 dir system for LIB etc CPUROOT ROOT 68000 dir system for output SRCROOT ROOT SRC dir system for source SDIR specific source dir TYPE ROMBUG RDIR RELS TYPE RDUP LIBROOT RDIR BOOTDEFS SRCROOT ROM CBOOT DEFS SCSIDEFS SRCROOT I0 SCSI DEFS SYSDEFS SRCROOT DEFS std OS defs SYSMACS SRCROOT MACROS CDEFS ROOT SRC DEFS std C defs TMPDIR dd MAKER rom port make SYSINIT sysinit r SYSCON bootio r syscon r OBJECTS SYSINIT SYSCON OLIB rom port l COMDEFS SYSDEFS oskdefs d DEFS systype d COMDEFS RBUG aROMBUG MBUGTRC aMBUGTRC enables MBUG tracing and breakpoints for testing RAMLOAD aRAMLOAD support rombug load directly for porting SPEC_RFLAGS MBUGTRC RAMLOAD aFASTCONS CBUG dNOBUG SPEC_CFLAGS CBUG mode compat CC cc CSRCHDIRS v v BOOTDEFS v SCSIDEFS v SYSDEFS v CDEFS CFLAGS qst TMPDIR 0 0 dCBOOT SPEC_CFLAGS CSRCHDIR
104. e for dbra 1 d1 OS 9 OEM Installation Manual 0180 24c1 0182 5lca 0186 302b 018a e448 018c 5380 018e 7200 0190 24c1 0192 51c8 0196 4cdf 019a 4e75 A11SPU10 A11SPU20 ALLSPU90 move l dbra move w lsr w subq 1 moveq move 1 dbra movem 1 rts dl a2 d2 A11SPU10 Using the OS 9 System Security Module initialize SPU image S_SPUBlks a3 d0 get size of block count map 2 d0 1 d0 40 di dl a2 d0 A11SPU20 divide by 4 bytes per long minus one for dbra initialize block counts a7 d0 d2 a1 a2 restore regs kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Subroutine Protect Update SPU image in user process to disallow access to a specified memory area Passed d0 l size of area a2 address of area returned Returns 019c 48e7 01a0 4a80 Ola2 676c 01la4 4aac 01a8 6766 Olaa 7600 Olac 162b 01b0 220a 01b2 d081 01b4 5380 01b6 e6a9 01b8 e6a8 Olba 9041 Olbc 1601 Olbe 0203 01c2 d603 01c4 7403 01c6 e73a 01c8 262c Olcc 670e 0lce c78c 01d0 2 00 01d2 202 01d6 61c4 01d8 c78c Olda 201 01dc 08ec 01e2 246c Ole6 226a Olea 41lea Olee 2608 a3 SPU global data ptr a4 process descriptor removing access a6 system global ptr cc carry bit set dl w error code if error Destroys none Data S_BlkBit Protect Protec20 movem 1 tst 1 beq s tst 1 beq s moveq move b move 1 add 1 subq 1 lsr l lsr l sub w move b andi b add b moveq
105. e the download is com pleted The kernel is expected to be the first module Once the download is completed it jumps to the kernel entry point This is a series of Support subrou tines for CBOOT OS 9 OEM Installation Manual Examples of boot drivers are located in the SRC ROM CBOOT directory Examining these drivers can be very OS 9 OEM Installation Manual The C Boot Technology File Booters Description romboot c romboot ThisistheROM boot front end It loadrom searches the ROM list spaces for a module with the name kernel and verifiesthemoduleheader parity The code returns the address of the kernel to CBOOT loadrom differs from romboot in that after finding a kernel module it moves it and all modules contiguously following it to system RAM and begins executing the kernel there sysboot c Sysboot is the mainline for the CBOOT system It makes calls to the routine getbootmethod and routes its activity accordingly sysboot This code provides the interface _gluec between the assembler boot a code call to sysboot a and the CBOOT boot code tapeboot c tapeboot This is the magnetic tape front end It knows about the format that is expected of a boot tape and manages the memory and reading of the tape It calls drivers that are expected to do little morethan manage the hardware The file syscon c in PORTS lt target gt provides the routines getbo
106. eTsk Release Protection Structures e F ChkMem_ Check Access Permissions e F GSPUMp Check Access Permissions E 14 OS 9 OEM Installation Manual Hardware Considerations OS 9 OEM Installation Manual Using the OS 9 System Security Module The protection module code provided with this manual was designed for use with a custom designed board that provides memory protection without address translation The hardware is automatically disabled during system state processes Thehardwaresupports up to 64 independent tasks It may be configured in one of four ways depending on the amount of memory in the system System Memory Size a o 2 Meg 4 Meg 8 Meg 16 Meg A task number 0 63 is stored in the protection unit s hardware task register to select one of the 64 available tasks The selected task s hardware protection image appears as RAM on the bus at the SPU_RAM address The protection image for a task consists of either 256 or 512 contiguous data bytes depending on how the hardware has been configured Using the OS 9 System Security Module Each byte in the protection image contains a two bit protection mask for every four blocks of main memory The protect ion blocks are arranged in descending order within each byte For example Byte offset in image Byte 0 Byte 1 Byte 2 Byte 3 ect Address block 3210 7654 BA98 FDEC ete Protection bits wrwrwrwr wrwrwrwr wrwrwrwr wrwrwrwr The software
107. ectory structure described in this chapter for the organization of the shipping development directory structure 1 10 OS 9 OEM Installation Manual Structure of the Distribution Package on the Host System OS 9 OEM Installation Manual Getting Started The distribution package contains a largenumber of files that comprise the operating system and its utilities A few files are source code text files Most others are object code files The files are organized into subdirectories according to major subsystems ROM IO CMDS and so forth A master directory called MWOS is created The entire distribution package file system should be copied intact into this directory structure Wehave assumed that you will usea hard disk based system with sufficient storage capacity to contain the entire file system Microware has adopted this general directory structure across all of its product lines This allows all source products to reside together in a single directory and provides a means for sharing code across all operating system products ag The files in the distribution package assume this specific file and directory organization They will not assemble and link correctly if the organization is not correct Getting Started MWOS OS9 SRC Directory Structure Taking a closer look at MWOS OS9 SRC we see IO IOMAN KERNEL LIB MACROS ROM SYS SYSMODS These directories are as follows Directory Contains DEFS Fil
108. ed file will set M SysDev Execute custom modules cold2 executes any modules that have been defined in the Extens list in the I nit module These are commonly referred to as P2 modules Fork initial process The M SysGo field is the name of the first executable module cold2 forks the initial process with any parameters defined in the M SParam field of the I nit module The SysStart label in systype d sets up M SysGo and the SysParam label sets up M SParam Start the system clock If specified in the M Compat field of the Init module cold2 starts the system clock and ticker Call the kernel cold2 exits by calling the main part of the kernel itself At this point the system is fully booted and operating Step Two Bringing Up the Kernel and Console I O Debugging Hints If you suspect serious problems related to interrupts and extensive debugging efforts are not fruitful try making and running a non interrupt driven version of the driver This can definitively isolate the problem if it is interrupt related After the simpler version is debugged you can add the interrupt logic If OS 9 does not come up the system may have one of these common problems The system download file is missing a module or modules The download files were improperly downloaded or the second download file the driver overwrote the first The console driver has serious bugs The console descriptor module is not
109. edit boot a to change this table the table is defined by the MemDefs macro in the systyped file Thefirst part of the search list defines the areas of the address space where OS 9 should normally search for RAM memory This reduces the time it takes for the system to perform the search It also prevents the search and also OS 9 from accessi ng special use or reserved Memory areas such as 1 0 controller addresses or graphics display RAM The first entry or bank in this list must point to a block of RAM that is at least long enough for storing system global data and global data for ROM bug and boot code This is the area of memory cleared out by Step 4 of the boot a process If the system boots from disk or another device then this first bank needs to be large enough to hold e The system globals e Theglobal data needed by the ROM bug and boot code e The size of the bootfile Two factors determine the size of the system s ROM global data space The required stack size The amount of vsect and initialized data space used by the code Memory that is allocated for initialized and vsect data is part of the bootrom global data area and thus E permanently allocated for bootrom functions If a boot driver requires large buffers for example disk sector blocks they can be dynamically allocated from and returned tothe free memory pool The CBOOT system provides routines to do this The linker executed in rom_image make
110. elow level ioxxx driver there are several source code supplied high level scxxx drivers with the package as well Also configuration labels for the scx driver will need to be defined in systyped Check the high level driver sources in SRC 10 SCF DRVR for the configuration labels applicable to your selected driver When the OS 9 system is running you can include some standard OS 9 utilities such as mfree and mdir in your special memory areas OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O Creating the Init Within the systyped file is a section called CONFIG which is Module commonly referred to as the CONFIG macro Within this CONFIG macrois all the configuration values and labels that will be assembled and linked into the Init module The example systyped file from Appendix F has an example CONFIG macro You can modify this for your particular For more information about system The following are the basic variables within the the Init module refer to the CONFIG macro OS 9 Technical Manual Name Description MainFram SysStart SysParam SysDev ConsolNm A character string used by programs such as login to print a banner which identifies the system You may modify the string A character string used by the OS 9 kernel to locate the initial process for the system This process is usually stored in a module called sysgo Two general versions of sysgo have bee
111. elp reveal more subtle problems If your testing or later use of OS 9 reveals bugs please report them to Microware so they can be corrected in future releases Please forward a complete description of the problem and examples if possible Address bug reports and comments to Microware Systems Corporation Customer Support Department 1900 NW 114th Street Des Moines IA 50325 7077 USA Fax 515 224 1352 E mail support microware com OS 9 OEM Installation Manual Kernel Tests OS 9 OEM Installation Manual Step Four Testing and Validation These tests check the kernel s basic memory management and multi tasking functions Run the mfree and mdir e commands to verify that all installed RAM and ROM memory is accounted for Run multiple background tasks and then use kill to terminate them one by one Verify with the procs command Leave the system running overnight with multiple tasks running Run mfree and procs at the beginning and end of the test and compare After a system reset run themfreecommand and record the exact amount of free Memory Thoroughly exercise the system by running a large number of processes Kill all processes and then run mfree again checking for lost memory Set up test cases with two and three active processes and use the setpr command to alter process priority Use the procs command to verify correct allocation of CPU time Load link and unlink utility modules Verif
112. embly Also whenever possible the drivers are written to be port independent for multi port devices The ConsPort and CommPort symbol definitions in systyped then direct the driver to a specific port These techniques greatly facilitate multi driver coexistence and code reuse from one target to another See Appendix C for the values of these definitions The following describes the entry points into the driver ConsDeln Deinitialize Console Port from Polled Mode SYNOPSIS ConsDeIn Input None Output None DESCRIPTION ConsDdn deinitializes the Console port from the polled mode to the interrupt driven I O the high level drivers use The ROM debugger calls ConsDe n before resuming normal time sharing Essentially ConsDdn should restore the state of the I O device which the Consl nit function saved 3 30 OS 9 OEM Installation Manual Step One Porting the Boot Code OutRaw Output Character to Console Device SYNOPSIS DESCRIPTION OutChar OutRaw Input d0 b character to write Output None OutRaw outputs a character to the console device without considering flow control X On and X Off or carriage return line feed CR LF combi nations This is similar to the OutPut routine for the Comm port SYNOPSIS DESCRIPTION Output Character to Console Device OutChar Input d0 b character to write Output None OutChar outputs a character to the console device Before outputting the character the input por
113. er based on an existing example such as RB5400 You do not need to write a low level module as this already exists You then need to create your device descriptors for the new devices with the module name being rb4000 and the low level module name being scsi 147 The conceptual map of the OS 9 modules for the system would now look like this Kernel Level OS 9 Kernel File Manager Level RBF disks SBF tapes Device Driver RB5400 RB2333 RB4000 SB5400 Level Sees Physical Bus phe SCSI147 SCSI Bus 1 Example Three Perhaps the most common reconfiguration will occur when you add additional devices of the same type as the existing device For example adding an additional Fujitsu 2333 disk to the SCSI bus on the MVME147 To add a similar controller to the bus you only need to create a new device descriptor There are no drivers to write or modify as these already exist RB2333 and SCSI 147 You need to modify the existing descriptor for the RB2333 device to reflect the second device s physical parameters that is SCSI ID and change the actual name of the descriptor itself D 6 OS 9 OEM Installation Manual OS 9 OEM Installation Manual E Using the OS 9 System Security Module Memory Management Units E 2 Hardware Software Requirements E 3 Versions of SSM040 AA E 3 Configuring SSM for MC68451 Systems E 4 Adding SSM tothe OS 9 Bootfile
114. er of permission blocks per byte ReadProt WritProt d0 OS 9 OEM Installation Manual 0440 0442 0444 0446 0448 044a 044e 0452 0458 045c c001 10c0 10d9 e409 5343 57ca 56ca 2b6e 4cdf 4e75 0000045e GSPUMp70 GSPUMp90 GSPUMp99 and b move D move b lsr b subq w dbeq dbne move 1 movem 1 rts ends OS 9 OEM Installation Manual Using the OS 9 System Security Module d1 do strip out bits for current block do a0 copy block permissions to buffer al a0 copy block count to buffer 2 dl shift permission bits for next block 1 d3 dec num of blocks in current perm byte d2 GSPUMp60 repeat until end of byte or end of buf d2 GSPUMp50 repeat if more blocks D BlkSiz a6 R d0 a5 the blk size used clear carry a7 d0 d2 d3 a0 a2 restore regs End of Appendix E Using the OS 9 System Security Module OS 9 OEM Installation Manual F Example ROM Source and Makefiles 0 5 EE F 2 SED PE use ease F 3 SV SHIT Cech vesen F 6 NEO ee F 8 rombug make ire F 10 FOM MaKe ioniche F 12 rom COMMON MAKE AAA F 14 rom_serial Make iis F 16 Fom Pot MARKS dee F 18 Se null glo Dn E F 20 DONO Cdl aa F 22 OS 9 OEM Installation Manual Example ROM Source and Makefiles defsfile opt f issue form feeds use lt oskdefs d gt use systype d OS 9 OEM Installation Manual Example ROM Source and Makefiles systype d System Definitions for OEM example opt 1 pag kkkkkkkkk
115. eration if F STimesystem calls are made that require reading the real time clock This allows the real time clock code to be developed independently of the tick timer code You can change the real time clock hardware without modifying the tick timer code To use a different real time clock device Create the new module Replace the old real time clock module in the bootfile with the new one Reboot the system Step Three Creating Customized I O Drivers and Finishing the Boot Code Automatic System Clock Startup The kernel can automatically start the system clock during its coldstart initialization The kernel checks the I nit module s M Compat byte at coldstart If the NoClock bit is clear bit 5 0 the kernel performs a F STimesystem call with the month parameter equal to zero to start the tick timer and set the real time This automatic starting of the clock can posea problem during clock driver development depending on the state of the real time clock hardware and the modules associated with the tick timer and real time clock If the system software is fully debugged you should not encounter any problems The following are three common scenarios and their implications The system has a working tick module but no real time clock support If the NoClock bit in the Init module s M Compat byte is clear the kernel performs the F STimecall Thetick timer code is executed to start the tick timer but the tick
116. es of definitions that apply system wide or are target independent These will be both assembler d and C h include files IO Sources for all 1 O subsystems including file managers drivers and descriptors The file s subdirectories are organized by subsystem detailed below IOMAN Source for the IOMan module if you purchased a license for IOM an source whose functionality was integral to the kernel in previous releases KERNEL Source for all kernel variants if you purchased a license for kernel source LIB Sources for all system and subsystem libraries MACROS Files of assembly language macro definitions that apply system wide or are target independent ROM Sources for rebuilding all boot ROM components except for a few which share source with SCSI drivers in 10 SYS A repository for files and scripts which would end up residing in the OS 9 SYS directory on a root device SYSMODS Sources for system extension modules OS 9 OEM Installation Manual Getting Started MWOS OS9 Directory Structure The top most directory structure is as follows MWOS OS9 peg a SRC MAKETMPL 68000 68020 CPU32 These directories are as follows Directory Contains SRC MAKETMPL 68000 68020 and CPU 32 The source files for the OS 9 drivers descriptors system modules defs and macros It is intended to be a source directory containing hardware specific code which is written to be reuseable from target to tar
117. ger that is passed in as the size of the block requested The actual size of the block allocated is returned in this same location men is a pointer to the pointer to the requested block NOTE Boot devices use this routine to request memory not declared in the boot driver s vsect declarations Typically this dynamic allocation is performed by boot drivers that have buffer requirements that are not known at compilation time Such as disk boot drivers supporting variable sector sizes This method of dynamic allocation is useful for saving system memory usage as any storage declarations made at compilation time are fixed into the boot ROM global data area If the memory buffers are to be released so that they can be used by the kernel for example they should be returned to the boot ROM free memory list using the insert call If an error occurs extract returns the error code Otherwise it returns SUCCESS OS 9 OEM Installation Manual A 11 The C Boot Technology insert Return Memory to System Memory List SYNOPSIS DESCRIPTION SEE ALSO Dumb mem insert size mem vu int32 size size of block returned vu int32 mem ptr to block to return insert returns memory to the system memory list Memory is returned in 16 byte increments For example if 248 is passed as the size to return insert rounds up and returns 256 bytes size specifies the size of the returned block mem is a pointer to the
118. get It is not intended to bethe repository for final object modules that are built from this source although intermediate object files may be found within it s subdirectories A directory for common makefile templates include files for makefiles In this release any templates found in this directory apply only to makefiles for I SP and related products These remaining directories can be though of as object directories for target processor architectures or families It is in these directories that processor family specific objects are deposited when built and where target specific source code makefiles and final objects reside OS 9 OEM Installation Manual 1 13 Getting Started OS 9 Macro Routines Do not edit these macros Many varied source files use these macros and your changes may have unforeseen consequences to other users The macros in the SRC MACROS directory are designed to be useful general purpose macros for driver file manager kernel development Do not place macros that pertain to specific drivers for example in this directory The following list summarizes each macro s purpose f you add any macros to this directory please update this list accordingly Name Description btf m Create branch if true false instruction sequences for situations where Scc instructions are used to manipulate flags os9sve m Make a system call quickly in a driver or file manager This is ge
119. har byte Out1H ex converts the unsigned character parameter byteto two ASCII hexadecimal characters 0 F and sends them to the console output device via the OutChar function Out2Hex Convert Parameter to ASCII SYNOPSIS DESCRIPTION void Out2Hex word u_int16 word Out2H ex converts the 16 bit unsigned parameter word to four ASCII hexadecimal characters 0 F and sends them to the console output device via the OutChar function Out4Hex Convert Parameter to ASCII SYNOPSIS void Out4Hex longword vu int32 longword DESCRIPTION Out4Hex converts the 32 bit unsigned parameter longword to eight ASCII hexadecimal characters 0 F and sends them to the console output device via the OutChar function OS 9 OEM Installation Manual A 9 The C Boot Technology inttoascii Convert Parameter to ASCII SYNOPSIS u_char inttoascii value bufptr vu int32 value parameter to convert char bufptr ptr to character buffer DESCRIPTION _ inttoascii converts the unsigned 32 bit integer parameter valuetoa null terminated string of up to ten characters of numeric ASCII Leading zeroes beyond the hundreds digit are ignored At least three digits are guaranteed valueis the parameter to convert bufptr is a pointer to a character buffer in which to deposit the string inttoascii returns the buffer pointer after it is incremented to point to the first character after the ASCII string convhex Co
120. hat certain features of the BootStrap code are correctly invoked The label CPUT yp is used for conditional assembly of portions of the boot code The actual processor type is detected by the boot a code and passed to the kernel If you incorrectly define CPUTyp the processor type passed by the boot a code will still be correct however some portions of the bootstrap code may have conditional parts missing or incorrectly invoked CPUTyp Value Processor Value Passed to Kernel 68000 68000 68008 68301 68303 68305 68306 0 68302 68302 0 68010 68010 10 68020 68020 68EC020 20 68030 68030 68EC030 30 68040 68040 68EC040 68LC040 40 68070 68070 aka 9xC1x0 family 70 68300 68330 68331 68332 68333 68334 68340 300 68341 68349 68360 68349 68349 300 NOTES 1 The naming conventions for 683XX processors can be confusing The processors numbered in the range 68301 68306 are 68000 core based processors and thus from a software point of view the boot a code will take any value of CPUTyp that is in the range from 68301 to 68309 to be a 68000 processor The processors in the number range 68330 and up are CPU 32 or CPU 32 aka CPU 030 based cores and thus the bot a code will take any value of CPUT yp that is in the range from 68330 through to 68399 as a CPU 32 based processor 2 CPUTyp having a value of 68302 causes the boot a code to reserve vectors 60 63 but otherwise it is treated like a 68000 3 The value passed to the ke
121. he SPU structures structures used by the process Passed a3 SPU global data ptr a4 process descriptor ptr to clear a6 system global ptr Returns cc carry set dl w error code if error Destroys dl Data S_TskTbl S_SPUBlks DelTsk 033e 48e7 movem 1 0342 246c movea l PSSPUMem a4 a2 0346 200a move 1 a2 d0 0348 672e beq s DelTsk90 034a 302a move w P_Task a2 d0 034e 6710 beq s DelTsk10 0350 426a clr w P_Task a2 0354 b07c cmp w MAXTASK d0 0358 6406 bhs s DelTsk10 035a e540 asl w 2 qd0 035c 42b3 clr l 0360 7000 DelTsk10 moveq 0 do sweep register OS 9 OEM Installation Manual Using the OS 9 System Security Module 0362 302b move w S_SPUBlks a3 d0 get number of SPU blocks per map 0366 e480 asr l 2 do divided by 4 entries per map byte 0368 d06b add w S_SPUBlks a3 d0 add sz of SPU blk ct map 036c d07c add w P_SPUImg d0 add size of pre image variables 0370 42ac clr l P SPUMem a4 0374 4e40 os9 F SRtMem return system memory 0378 4cdf DelTsk90 movem l a7 d0 a0 a2 restore regs 037c 4e75 rts kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkxk Subroutine ChkMem tal Check SPU image in user process to determine if access to a specified memory area is allowed Passed d0 l size of area dl b permission requested Read Write Exec_ a2 address of area requested a3 SPU global data ptr a4 process descriptor requesting access a6 system global ptr Returns cc carry bit set dl w error co
122. he jump to the kernel and for the boot procedure to break again The debugger will break in the cold part of the kernel The code for cold has just completed the memory verification and the ROM memory module searches It is just about ready to fork theinitial process At this point you can manually search the module directory to see if all the modules have been found At this point the memory location pointed to by the vbr register or memory location 0 if on a 68000 processor will point to the beginning of system globals Offset 0x3c from the system globals will bethe address of the module directory list Each directory entry is 16 bytes or 10 hex bytes which can make dumping it very handy The first long word in a directory entry is the address to the module itself From a debugger the following will get to the module directory d vbr 3c The following will actually get to the first module listed in the directory which should be kernel d vbr 3c NOTE These examples assume a CPU with a VBR If your CPU does not have a VBR substitute the value of 0 in the following examples Trouble Shooting Remember all modules begin with the code 4afc The next module would be obtained by d vbr 3c 10 The modules should be listed as they were put into the ROMs or bootfile To find thename of the module Get the name offset from the header Add the offset to the beginning of the header Once the system
123. he names of e NN If your target system uses a common type of I O device you devices used by the specific can probably use a Microware supplied file directly or with target system For example little modification Otherwise you need to create a new source a source file for the Motorola file using the supplied files as examples 6850 device is called i06850 a a source file for the Signetics 2661 is called ThE physical 1 0 port addresses and related i02661 a and so on A A i information are obtained from systyped If the console port and the communications port use the same type of device you can use a single combined file for both OS 9 OEM Installation Manual 3 29 Step One Porting the Boot Code I O Driver Entry Points The low level I O drivers are generally polled drivers which will allow themselves to force themselves onto the port if necessary The driver consists of two sides e A console side for connection to an operator s terminal e A communications si de for connection to a host system which facilitates downloading object files into the target These are commonly referred to as the Console port and the Comm port respectively Many of Microware s example low level serial drivers conditionally assemble entry points and support routines for the console side separately from the communications side The ConsT ype and CommT ype symbol definitions in systype d control this conditional ass
124. hy the failure occurred IOMan is trying to open the console name that is These error numbers are defined in the M Consol field of the Init module An standard OS 9 error codes error has occurred preventing I OM an from booting This error can occur for many reasons including a Thedriver and descriptor modules do not have owners of 0 0 You can use the ident utility to verify this and you can usethefixmod utility to change the owner of a module OS 9 OEM Installation Manual B 5 Trouble Shooting b Either the driver descriptor or the SCF file manager was not found during the kernel s module search list Review the Searching the Module Directory section of this chapter and verify that these modules were found If not check the special memory areas and verify that these modules are in these areas Also check the ROM list at the first boot stage to make sure that all special memory areas were found The driver returned an error For some reason the driver s Init routine is returning with an error Either the driver must be debugged using RomBug or review the source to determine the reasons why an error can be returned If you are using the sc68681 driver a common problem is the proper setting of the DevCon descriptor field Review the section on setting up the DevCon field later in this appendix Can t open default device IOMan is trying to open the default device name that is defined in the M S
125. ick interrupt device 5 4 tick timer activation 5 6 OS 9 setup 5 5 tickgeneric a 5 8 TicksSec 5 10 timing loops 8 10 TransFact 3 28 TRANSLATE 3 16 OS 9 OEM Installation Manual Index U UseDebug 2 4 3 23 functions 3 36 V variable sector size RBF support 9 2 variable sector size support advantages of 9 7 convert existing drivers 9 4 VBRBase 3 16 VBRPatch 3 28 Vector 4 4 vectors a 2 7 3 8 3 21 3 34 VME620 SCSI controller D 5 W write through 8 5 OS 9 OEM Installation Manual 1 33 Index I 34 OS 9 OEM Installation Manual
126. ike with not serialized accesses There will be no reordering of reads over writes This is the mode to use when using physical hardware registers e Cacheinhibited not serialized access This is a cache inhibited mode However with this mode reads may get optimized with respect to writes Basically the 68040 is trying to keep its pipeline full and it may reorder a physical read in front of a physical write This may not be a desirable affect when writing to hardware registers The ssm040 module under OS 9 has the ability to build these tables when OS 9 is booted It gets the data to build these tables from the Cache et entry from within the init module The system configuration information for the init module comes from the CONFIG macro in the systyped file For caching there is a label named CacheList Following this Cache ist label are the specific CacheT ype macro invocations for the systype The CacheT ype needs three parameters the beginning address ending address and caching mode OS 9 Cache Control For OS 9 the caching mode is defined as follows e For writethrough WrtThru e For Copy back CopyBack e Cache inhibited serialized access CISer e Cache inhibited not serialized access CINotSer An example cache list for the MVME 167 is as follows CPUALIGN CacheList NOTE that these have been constructed to match the regions defined in the MemType entries above CacheType Mem Beg Mem End CopyBack Cache
127. image is burned into the eprom and installed in your target turn the system on and get to Rombug prompt ROMbug will automatically find and attach to the symbol table information within the stb file Type or to enable soft breakpoints Set up any needed breakpoints within the boot code Type gb If all goes well the CBoot routines should now read the OS 9Boot file from the disk into RAM unless a breakpoint was encountered first Afterward you should get another register dump and a ROMbug prompt At this point you can usethe ROM debugger s memory dump command to display the modules loaded by the CBoot routine Type gb again This executes the kernel s initialization code including the OS 9 module search You should get another register dump and ROMbug prompt At this point you should verify the entire OS 9Boot file was loaded and all modules within it found To do this follow the steps listed in Searching the Module Directory from Appendix B Type gb again This should start up the system If successful the following message appears shell If the shell prompt does not appear your target system s module is probably bad F or example files may be missing or OS9Boot is missing required modules You will need to go through the normal procedures for debugging 5 20 OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code Further Before going on to the next step
128. ing the OS 9 System Security Module 00ee 9041 00 0 1601 00 2 0203 00 6 d603 00 8 e73a 00fa 262c 00fe 6714 0100 c78c 0102 48e7 0106 4cef 010c 61a4 010e c78c 0110 4cdf 0114 08ec 011a 246c Olle 226a 0122 4lea 0126 3601 0128 e44b 012a c530 012e 5231 0132 6404 0134 5331 0138 e5la 013a 5241 013c 51c8 0140 7000 0142 4cdf 0146 4e75 sub w move b andi b add b rol b move 1 beq s exg movem movem 1 bsr s exg movem 1 bset movea 1 movea 1 lea move w lsr w and b addq b bcc s subq b rol b addq w dbra moveq movem 1 rts LA Permit30 Permit40 Permit50 Permit 90 d1 do convert to number of blocks 1 dl d3 copy beginning block number 30011 d3 strip off lower two bits d3 d3 make SPU bit offset of first block d3 d2shift perm bits into initial position P DbgPar a4 d3 is this program being debugged Permit 30 continue if not d3 a4 switch to par s debugger s process desc d0 d1 a7 save regs 8 a7 d0 d1 restore original size of area perm Permit update parent debugger SPU image ad d3 restore process descriptor ptr a7 d0 d1 restore regs ImgChg P State a4 mark SPU image change P SPUMem a4 a2 get SPU process memory ptr P_BlkCnt a2 al ptr to SPU map block count P_SPUImg a2 a0 ptr to SPU image dl d3 copy block number 2 d3 convert block number to byte offset d2 a0 d3 w unprotect block in SPU image 1 al dl w increment SPU block count Permit 50 continue if
129. ion about F SRqmem and F SRtMem If you want to use the variable sector size support use the following guidelines to convert existing drivers In general device drivers written for the old RBF were written to operate under one of two situations The media logical and physical sector sizes were the same In this case the driver would accept the sector count and starting LSN convert it to the physical disk address if required and then perform the I O transfer To convert these drivers written to support other logical physical sector sizes you need to e Add support for the GetStat SS _VarSect call e Ensurethatthe driver does not have any hard wired 256 byte assumptions Typically this implies that the driver should e Usethe sector size field PD_SSize in the path descriptor whenever it needs to convert sector counts to byte counts for example when loading DMA counters e Maintain any disk buffers in a dynamic manner sothat a sector size change on the media does not cause a buffer overrun This usually means that fixed sized buffers allocated in the static storage of the driver should now be allocated and returned as required using the F SRqMen and F SRtMem system calls In many cases a correctly written driver only needs the addition of the SS_VarSect handler to simply return NO ERROR to work with variable sector sizes OS 9 OEM Installation Manual Converting Existing Drivers to Use Variable
130. is chapter deals with the first step of porting OS 9 This involves creating and installing a ROM that contains the system initialization code and a special ROM debugger ROM bug OS 9 OEM Installation Manual About the Boot Code OS 9 OEM Installation Manual Step One Porting the Boot Code In a sense the name boot code can be misleading The boot code does not try to boot the system by reading data from a disk that comes in a later step At this point the boot code has the following functions Initializethe basic CPU hardware into a known stable state Determine the extent and location of RAM and ROM memory Provide low level console I O amp Call the ROM bug debugger The ROM bug debugger is located in the same part of the ROM as the boot code The ROM bug debugger can download software from the host system It provides powerful debugging facilities such as e Tracing e Single instruction stepping e Setting breakpoints The ROM bug debugger remains in place for the entire porting process It can also be used to help debug all of your applications especially any system state or driver code However for your final production ROM you may wish to exclude ROM bug The ROM is made from a number of different files that are linked together to produce the final binary object code The vast majority of the code is not system dependent and therefore is supplied in relocatable object code form files with
131. it wide Memory use the romsplit utility to convert the ROM object image into 8 bit wide files After you have installed the ROM code and powered up the system you should see the following message on the terminal OS 9 68K System Bootstrap 3 40 OS 9 OEM Installation Manual Putting the ROM Together continued OS 9 OEM Installation Manual Step One Porting the Boot Code A register dump and a debugger prompt should follow If the debugger did not come up you must carefully review the previous steps Particularly review The primitive 1 O code The memory definitions in systyped and sysinit a The terminal connections The baud rate selections Step One Porting the Boot Code Notes 3 42 OS 9 OEM Installation Manual OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O Preparing the First Stage OS 9 Configuration 4 2 Creating the Init Module n 4 3 SCF Device Descriptor Macro Definitions 4 4 Creating a Console I O Driver 4 6 Preparing the Download File sasssa 4 7 Downloading and Running the System 4 8 Cold Part of Kernel rmuummeessvsvvrvvrererreravanssverereeer 4 10 The coldstart Routine 4 11 Cold2 Bringing Up the System the Rest of the Way 4 12 Debugging Hints solita 4 14 4 1 Step Two Bringing Up the Kernel and Console I O Preparing the First Stage OS 9 Configuration As with the
132. ize Console Port aio 3 32 Porti nit Set Up and Initialize COMM POF 3 32 ConsSet RE Ee We E RE 3 32 InChChek Check Console POT scribi alii 3 33 ChekPort Ch k COTM RE 3 33 OutPort Output Character on Comm Port rrrmarnnnnnnvvvvrnvrnnrnsrvrrnererrsnnnnnr 3 33 InPort Read Character from Comm Port i 3 34 PortDeln Deinitialize Comm Port from Polled Mode 3 34 PG SV ae File celare aaa 3 35 Th Sysinit Entry Pollaiolo lalla lella 3 35 TVS Hive NO Entry Potassio ei 3 36 The UseDebug Entry Point tolo lola 3 36 bat ee D UE 3 38 Rat Haben RE 3 39 OS 9 OEM Installation Manual Putting the ROM Together cilea 3 40 4 Step Two Bringing Up the Kernel and Console I O Preparing the First Stage OS 9 Configuration i 4 2 Creating the Init te EE 4 3 SCF Device Descriptor Macro Definitions mmmnnnnrrrrrrrnnnnnnnnrvrrrrrrnrsnvrrnnerersnnnnnnnne 4 4 Creating a Console 1 0 Driver aa 4 6 Preparing the Download File ii 4 7 Downloading and Running the System wurnnnnnrrrvrnrnnrnnnnvvvnnnsrnannrvrrrnnessrnnnnnvvesssnsennnr 4 8 Ee Io Re ge WE gt DEE 4 10 The OAldstart Rutine usle kst dernest 4 11 Cold2 Bringing Up the System the Rest of the Way ii 4 12 BLE altere iare ga lla i paia eases 4 14 5 Step Three Creating Customized I O Drivers and Finishing the Boot Code Modus Sean 5 3 Guidelines for Selecting a Tick Interrupt Device rrrnnnrrannnnvvvvrrrnnrnnnnnvvrrsrr
133. kkkkkkkkkkkkkkkkkkkkkkk Edition History x date comments by Fi n en Se a a eS a E a ae E ee ee ae ee ee ee Se Se ee Se Se 93 05 21 genesis XYZ 93 10 28 updated for OS 9 V3 0 XYZ test example on MVME162 VME162 equ 162 CPUType set VME162 kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk System Memory Definitions These are used by the MemDefs for rom and MemList for init module macros to describe the system ram structure VBRBase equ 0 base address of vectors RAMVects equ included exception vectors are RAM ifndef TRANS TRANS equ 0 no address translation endc TRANSLATE equ TRANS ProbeSize equ 1000 block probe size 4K DRAMBeg equ 0 physical start of system memory DRAMSize equ 100000 assume 1MB total system memory LoadSize equ 20000 make available 64K for downloaded rombug ifdef RAMLOAD CPUSize equ DRAMSize LoadSize else NOT RAMLOAD CPUSize equ DRAMSize entire DRAM available for system memory endc MapOut equ 400 vector table space at beginning of DRAM These are the ROM definitions for the on board ROM sockets Rom Size equ 40000 say we have 256K for ROM Rom Beg equ FF800000 ROM starting address OS 9 OEM Installation Manual F 3 Example ROM Source and Makefiles Rom End equ Rom Beg Rom Size Mem Beg equ DRAMBeg MapOut Mem End equ DRAMBeg CPUSize Spcl Beg equ Rom Beg Spcl End equ Rom End ifdef RAMLOAD Spc2 Beg equ Mem End Spc2 End equ Mem End LoadSize else Spc2
134. le If you need the e What does the memory map of the entire system look disk space you can get rid of like the rest Remember your Microware distribution tape or disks still contain all of the files This can considerably narrow down your focus of porting 2 2 OS 9 OEM Installation Manual Understanding the OS 9 Booting Process The bootfile must contain the kernel OS 9 OEM Installation Manual Porting OS 9 Although the OS 9 system itself that is the kernel file managers and processes is very modular in its architecture the boot code is different and a distinction is made between the OS 9 system and the OS 9 boot code You can think of the OS 9 boot code as one program consisting of several different files that gets linked together and burned into ROM in order to bring up the OS 9 system A bootfile must exist in order to boot OS 9 This bootfile is simply merged OS 9 system and program modules with the kernel usually being the first module This bootfile can exist e In ROM e Onadisk e On atape e Any other type of media The purpose of the boot code is to e Set the hardware into a known stable state e Set up certain table and memory configurations e Find the bootfile and start executing the kernel Three steps are necessary to boot OS 9 These are covered in the following pages Porting OS 9 Step is the most difficult step to complete and unless you have an emulato
135. le device output character to 3 31 read string from A 7 console output device send stringto A 7 console port 3 30 check 3 33 deinitialize 3 30 disable 3 32 initialize 3 32 output character to 3 31 ConsolNm 4 3 ConsSet 3 32 ConsType 3 18 convhex A 10 copy back 8 5 CPU32 1 13 CPUTyp 3 16 3 17 create disk boot routines 5 18 disk drivers 5 16 creatie system security module E 10 D D SnoopD 8 12 DD BSZ 7 4 7 5 DD BT 7 4 7 5 deblocking drivers 9 5 debug files 3 9 define Memory 3 19 OS 9 OEM Installation Manual Index DEFS 1 12 defsfile 3 10 development environment 1 3 Direct Memory Access DMA 8 12 address translation 8 13 disk driver boot routines 5 18 test 5 17 disk I O tests 6 5 diskboot c A 4 distribution package 1 11 download OS 9 4 8 prepare file 4 7 driver flags C 2 DriverName 4 5 drivers deblocking 9 5 E embedded MMU E 2 entry points 3 35 error codes B 7 errors B 5 example makefiles F 1 ROM source F 1 Exbin 1 4 exception service routine install A 15 Extens 2 6 4 4 external caches 8 9 extract A 11 F F Trans 8 13 FD V 3 18 FDsk Vct 3 18 filename suffixes 1 9 floppy disk OS 9 OEM Installation Manual suggested format 7 3 flow control 1 7 Fujitsu 2333 hard disk D 3 G gb command B 11 generic clock modules 5 8 5 10 getbootmem A 12 getbootmethod 3 38 gethexaddr A 13 growth method 3 22 H hardware configuration D 3 disable A 6 initialize
136. list can be very short You can review the supplied systyped files to see how to define hardware registers However the values in the supplied systyped file will not work on your target hardware For more information about the use of these labels refer to the section on the sysinit a file 3 14 OS 9 OEM Installation Manual Target Configuration Labels OS 9 OEM Installation Manual Step One Porting the Boot Code The target configuration labels are needed to configure the boot code properly for your target hardware The following are a list of these variables Label Effect ROMBUG CBOOT RAM Vects PARITY MANUAL_RAM Specify that ROM bugis used Theinitial stack area is increased in size to accommodate the larger usage by the C drivers and the size of the ROM global data area is determined dynamically Several of the vectors are pointed intothe ROMbug handlers Boot a also calls the ROMbug initialize data routine Specify that CBOOT technology is to be used The ROM global data area size is determined dynamically You can also use this flag to enable sync codes in assembler code This allows the assembler boot drivers to be interfaced with the CBOOT sysboot routines Specify that the vectors arein RAM This allows boot a to copy the vectors to the appropriate place Specify that parity memory is present boot a initializes parity by writing a pattern into the memory The MemList macro
137. lled the bootstrap file by enforcing the contiguous data requirement and then updating the media s identification sector LSN 0 with the bootstrap pointers The pointers originally used are Name Description DD BSZ Word value of bootfile size DD BT 3 byte value of the starting LSN of the bootstrap DATA At V2 4 the original specifications were expanded so that the identification sector pointers are defined in an upwards compatible manner as follows Name Description DD BSZ If DD BSZ is non zero this field contains the size of the bootstrap file as per the original specification If this is zero the DD_BT fieldis a pointer tothe file descriptor FD of the bootstrap file TheFD contains the boot file size and the segment pointer s for the boot file data If DD_BSZ is not zero this is the starting LSN of the bootstrap data as per the original specification If DD_BSZ is zero this is the LSN of the file descriptor for the bootfile DD_BT Use the os9ge utility to make the bootstrap files By default os9gen creates a contiguous boot file that is less than 64K this follows the original specification If you want a large or non contiguous boot file use os9gen s e option OS 9 OEM Installation Manual Bootstrap Driver Support OS 9 OEM Installation Manual Miscellaneous Application Concerns If your system requires large non contiguous bootstrap files you need
138. m serial make rom_port make rom_image make rom initext make MAKEOPTS RBUG CBUG TDIR TARGET ROMDBG MBUGTRC RAMLOAD MAKER rombug make this file INITEXT OBJDIR initext RBGSTB OBJDIR STB rombug stb FILES OBJDIR rombug INITEXT RBGSTB OFILE OBJDIR rombugger MAKE make make utility CFP cfp command file processor CFPOPTS s MAKE f MAKEOPTS MERGE merge REDIR gt CHD chd DEL del ALLFILES TOUCH touch F 10 OS 9 OEM Installation Manual X rombug date MAKER CFP CFPOPTS MAKERS MERGE FILES REDIR OFILE clean MAKER CHD RELSDIR DEL ALLFILES end of file OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles rom make Makefile for OEM example ROM without ROMBUG b TYPE NOBUG RELSDIR RELS TYPE OBJDIR CMDS BOOTOBJS TYPE ROM customization flags RBUG RBUG CBUG CBUG dNOBUG TDIR TYPE TYPE TARGET TARGET rom ROMDBG ROMDBG Testing options MBUGTRC MBUGTRC aMBUGTRC RAMLOAD RAMLOAD aRAMLOAD MAKERS rom_common make rom_serial make rom_port make rom_image make rom initext make MAKEOPTS RBUG CBUG TDIR TARGET ROMDBG MBUGTRC RAMLOAD MAKER rom make this file INITEXT OBJDIR initext RBGSTB OBJDIR STB rom stb FILES
139. m to install a soft bus error handler across the bus error jump table entry to allow software to determine the cause of the bus error The soft bus error handler can determine whether to re run the instruction or pass the bus error along to a previously installed handler such as the MMU code Tousethis facility create a file buserr m that has two macros Name Description INSTBERR Hardware enable for soft bus error Setup hardware to detect soft bus errors BERR Bus error handler Detect whether bus error is soft or hard If soft rerun the faulted instruction Otherwise call the original handler The details of the entry to these macros is documented in SRC SYSMODS SYSBUSERR sysbuserr a Miscellaneous Application Concerns 7 8 OS 9 OEM Installation Manual OS 9 OEM Installation Manual 8 OS 9 Cache Control OS 9 Cache Control scuri 8 2 System Implementation ia 8 3 Install Cache Operations 8 3 Default SysCache Modules AA 8 4 E Leg eet 8 5 Custom Configuration for External Caches 8 7 M Compat2 Bit Fields 8 8 ROM Debugger and Caches AAA 8 9 Peripheral Access Timing Violations 8 10 TIMINg LOOPS maren 8 10 Building Instructions in the Data Space 8 11 Data Caching and DMA rrvrrvrrvvrsvvvrsvrvrssrrssrresseen 8 12 Indication of Cache Coherency 8 12 Address Translation and DMA Tra
140. master library This can help save others time and trouble in the future If you wish todoso please forward them to M icroware We will make sure credit is given to the authors Finally we at Microware want to thank you for your selection of OS 9 Weare confident that you will find it a powerful and useful system Please let us know if we can assist you in any way Step Four Testing and Validation 6 10 OS 9 OEM Installation Manual OS 9 OEM Installation Manual Miscellaneous Applica tion Concerns Disk Booting Considerations 7 2 Boot Drivers that Support Variable Sector Size 7 2 Bootstrap File Specifications i 7 4 MoakKingBootF IS andai 7 4 Bootstrap Driver Support 7 5 Soft Bus Errors Under OS 9 7 7 Miscellaneous Application Concerns Disk Booting Considerations Boot Drivers that Support Variable Sector Size You must consider three features for new and existing boot drivers e Variable logical sector sizes e Boot files that exceed 64K in size e Non contiguous boot files RBF logical sectors may range in size from 256 bytes to 32768 bytes in integral binary multiples that is 256 512 1024 32768 This allows the RBF s logical sector size to match the driver s physical sector size Drivers written under the CBOOT system that are called by the diskboot front end need not be concerned with these issues because diskboot handles these consideratio
141. mediately after a system reset You should not need to edit this file The sysinit a file is reserved as a place for you to put code for any special hardware initialization your system might require after reset Steps Boot a Goes Boot a goes through the following steps to boot the kernel Through to Boot the Kernel Step 1 Assume a full cold start for growth method The kernel validates modules using a growth method e With a full growth method when the kernel validates modules it first validates the module header and then validates the full module s CRC number e With a quick growth method the kernel simply validates the module header Although booting is quicker there is more room for error A module may be in memory and may be corrupted Step 2 Mask interrupts to level 7 Interrupts are masked to ensure that the boot code has a chance to run Step 3 Call the Syslnit label Sysl nit ensures that all interrupts are cleared and that the hardware is in a known stable state Step 4 Clear out RAM Clears out the RAM used for the system globals and the global static storage used by ROMbug and the boot code Step 5 Record growth method in the Crystal global variable This growth method is passed tothe kernel when the kernel is jumped to Sysinit is defined in the sysinit a file 3 22 OS 9 OEM Installation Manual Steps Boot a Goes Through to Boot the Kernel continued UseDebug is located in the
142. mented later in this chapter Once you have properly adjusted the systype d and sysinit a files use the make f rombug make command to produce a ROM image file 3 6 OS 9 OEM Installation Manual Step One Porting the Boot Code Testing the Boot To test the boot code code Burn a set of ROMs with this image Turn on your hardware See if a ROM debugger prompt will come up e Ifthe ROM debugger prompt does come up you have successfully completed the initial port and are ready to continue e If it does not come up look at the section called Troubleshooting ROM Image Versions Generally two slightly different makefiles exist in the PORTS lt target gt directory rom make and rombug make rombug make Full boot menu with ROMbug Contains all the C boot functionality with the ROM bug ROM debugger This will be a large image found in PORTS lt target gt CMDS BOOTOBJ S ROMBUG rombug rom make Full boot menu Contains the C boot functionality without a ROM debugger This image is much smaller than the ROMbug image alone You will find it in the PORTS lt target gt CM DS BOOTOB S NOBUG rom This could be considered the final production version OS 9 OEM Installation Manual 3 7 Step One Porting the Boot Code Component Files of The rom make and rombug make makefiles create the ROM the ROM Image image by combining and linking several sets of files to make the binary object code e The comm
143. mized I O Drivers and Finishing the Boot Code Testing the Disk Test the disk driver using the following procedure Driver After a reset set the debugger s relocation register to the RAM address where you want the system modules now including the console driver loaded NOTE Steps 1 iand 2 are not necessary if the system Download the system modules Do not insert modules are in ROM breakpoints yet Set the debugger s relocation register to the RAM address where you want the disk driver and descriptor loaded Ensure that this address does not overlap the area where the system modules were previously loaded amp Download the disk driver and descriptor modules Do not insert breakpoints yet Type gb to start the sysboot kernel search If all is well the following message should appear Found OS 9 Kernel module at xxxxxxxx This is followed by a register dump and a ROM bug prompt If you do not see this message the system modules were probably not downloaded correctly or were loaded into the wrong memory area Type gb again This executes the kernel s initialization code including the OS 9 module search You should get another register dump and debug prompt If you want to insert breakpoints in the disk driver do so now This is greatly simplified by attaching to the driver Type gb again This should start up the system If all is well and a breakpoint was not encountered first yo
144. module name Step Three Creating Customized I O Drivers and Finishing the Boot Code Tick Timer You need to explicitly start the tick timer to allow the kernel Activation to begin multitasking This is usually performed by the setime utility or by a F STimesystem call during the system startup procedures Refer to the Utilities When F STimeis called it attempts to link to the clock Reference manual for DE information about using module name specified in the nit module If the clock module setime or the OS 9 is found the module s entry point is called toinitialize the tick Technical Manual for timer hardware information about F STime An alternative is to clear bit 5 of the compatibility flag in the init module If this bit is cleared the kernel will automatically start the tick timer during the kernel s cold start routine This is equivalent to a setime s 5 6 OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code Real Time Clock Real time clock devices especially those equipped with e battery backup allow the real time to be set without operator Device Support input OS 9 does not explicitly support the real time functions of these devices although the system tick generator may bea real time clock device The real time functions of these devices are used with the tick timer initialization If the system supports a real time clock the tick timer code should be writ
145. ms or return an error OS 9 OEM Installation Manual RBF Disk Utilities dcheck checks the disk file structure Refer to the Utilities Reference manual for information about using dcheck OS 9 OEM Installation Manual RBF Variable Sector Support Utilities that need to ascertain the media s logical sector size such as the dcheck utility can do so by Opening a path to the device CheckingthePD_SctSizfield of the path options section with the GetStat SS_OPT function code RBF sets the PD_SctSiz field to the media s logical sector size when the path is opened If the field contains a 0 an old RBF is running in the system and the logical sector size is assumed to be 256 bytes RBF Variable Sector Support 9 10 OS 9 OEM Installation Manual OS 9 OEM Installation Manual A The C Boot Technology Introduction alii A 3 The CBOOT Common Booters A 4 CBOOT Driver Entry Points a A 6 AE sa A 6 FOCAL Ja A 6 ET VIG EE A 6 CBOOT Library Entry Points A 7 ISP A 7 eltren ep lle aaa A 7 MERCHER O EE A 8 MENER ee A 8 KIEM aiar A 8 OUE ORG ira A 8 OUTIHEX siria A 9 The C Boot Technology QUEZIIOX clio A 9 OUTHEN sian A 9 MEEORS CHIE snc A 10 ONS Lilia A 10 MAak eloWert abilita A 10 ee ge e RE A 11 SUIT TOR A TN A 11 ME Eee A 12 GEEDOGEMIGNA e cnedesssenecuckededt A 12 gethexaddr EEN A 13 Te A 13 iniz boot_driver alla
146. n E 9 Creating a System Security Module ii E 10 SSM Module SU e TE E 12 Hardware Considerations E E 15 Complete Source Listing E 17 F Example ROM Source and Makefiles EEE RE RE F 2 SEL SER aac F 3 SE ea F 6 SELG E E E E NA EE E A F 8 Wa le ie ent F 10 POPP Tae EE EE EE F 12 rom COMMON E F 14 rom SSP LAD Ka CR iii dala F 16 MT ERRE IATA F 18 rom Dan e Dun EEE ira F 20 Pelican F 22 Index viii OS 9 OEM Installation Manual OS 9 OEM Installation Manual Getting Started Developing a Plan 1 3 The Host System Hardware 1 4 The Host System Software 1 5 The Target System Hardware 1 5 Me gellen EE 1 6 The Make Utility srl 1 8 Common File Name Suffixes 1 9 Checking the Contents of the Distribution Package EE 1 10 Structure of the Distribution Package on the LOSE SYSTEM iaia 1 11 MWOS OS9 SRC Directory Structure 1 12 MWOS OS9 Directory Structure 1 13 OS 9 Macro ROUEN iii 1 14 MWOS OS9 SRC IO Directory Structure 1 15 Getting Started MWOS OS9 SRC ROM Directory ST eg lg 1 16 Taking a closer look at MWOS OS9 SRC ROM es iii 1 16 These directories are as follows 1 16 The Object Directories A 1 17 The object directories look like this 1 17 Additional Reference MaterialS 1 19 Additional Reference Materials continued
147. n chip cache hardware The module validates the parameters passed to the F CCtl system routine and exits with no error The 68020 SysCache module controls the on chip instruction cache for the 68020 CPU The 68030 SysCache module controls the on chip instruction and data caches for the 68030 CPU The 68040 SysCache module controls the on chip instruction and data caches for the 68040 CPU The 68349 SysCache module controls the on chip instruction cache banks for the 68349 CPU 8 4 OS 9 OEM Installation Manual Caching Tables OS 9 OEM Installation Manual OS 9 Cache Control The memory management unit for the 68040 has the feature of defining memory areas of specific caching types These caching types are described as follows e Writethrough This is a cache active mode Basically in write through mode whenever a write happens both the cache and the physical hardware location are updated Even though this is a caching mode it is slower than copy back since the physical hardware is updated on each write Reads however will come from the cache as normal e Copy back This is a cache active mode This is the highest level of caching attainable Both reads and writes will be cached and the physical hardware may or may not be updated with a write This is the fastest mode possible e Cacheinhibited serialized access This is a cache inhibited mode With serialized access reads and writes will happen as expected unl
148. n provided in the files e sysgo a for disk based OS 9 e sysgo nodisk a for ROM based OS 9 A character string that is passed to the initial process This usually consists of a single carriage return A character string that contains the name of the path to the initial system disk The kernel coldstart routine sets the initial data directory to this device before forking the SysStart process Set this label to zerofor a ROM based system For example SysDev set 0 A character string that contains the name of the path to the console terminal port Messages to be printed during start up appear here OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O Name Description ClockNm E xtens A character string that contains the name of the clock module A list of OS9P2 modules the kernel will execute before the system is running For the initial port this field is not necessary However it must be defined or you will get linker errors To change the I nit module s default values once the port is complete you can define these changes within the CONFIG macro Refer totheinit a sourcefile located in theSYSMODS directory to see what symbolic labels are used for which Init parameters This will allow you to tune your system without modifying the generic init a file SCF Device The SCF device descriptor macro definitions are used when Descriptor Macro creati
149. nd String to Console Output Device i A 7 InChChek Perform Unblocked Read of One Character A 8 InChar Wait to Physically Receive One Character A 8 OutChar Physically Send One Character mmmnnnnnnnnnrnrnrrrrnnvnnnnnnnnnessssssnn A 8 OutHex Convert Parameter to ASCII i A 8 Out1H ex Convert Parameter to ASCII rnnnnrnnrnnnvnverrrrrerrennsnssrrrsnnnnnnnnnn A 9 Out2H ex Convert Parameter to ASCII i A 9 Out4H ex Convert Parameter to ASCII ii A 9 inttoascii Convert Parameter to ASCII A 10 convhex Convert Parameter to Hexadecimal Nibble A 10 makelower Convert Upper Case Characters to Lower Case A 10 power of2 Convert Value to Power Of Two A 11 extract Allocate Memory from Boot ROM Free Memory List A 11 insert Return Memory to System Memory LiSt s e A 12 getbootmem Allocate Memory for Bootfile i A 12 gethexaddr Read Hexadecimal Address rrrrrnrnnnnnnnnnnnnrrrrrrrrnnrnnnnnnnnnrersennr A 13 streq Compare Two Strings for Functional Equality A 13 iniz_boot_driver Initialize Boot Driver eee ee eeeeeeeeeeeeeeeeeeeeeeetee A 14 calldebug Invoke System Level Debugger kk A 14 mask_irq Mask Interrupts Ane r a iatale A 15 setexcpt Install Exception Service Rouitne rrrrvvnnnnnnnnnnvvernrrnarsnvvene
150. ndm kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkxk SCF device descriptor definitions used only by SCF device descriptor modules SCFDesc Port Vector IRQlevel Priority Parity BaudRate DriverName TERM macro SCFDesc Port Vector IRQlevel Priority Parity BaudRate DriverName default descriptor values can be changed here DevCon set 0 endm These two labels are obsolete under SysBoot but are still required to link in boot a SysDisk set 0 FDsk_Vct set 0 kkkkkkkkkkkkkkkkkkkkkkkkkkk Memory list definitions MemDefs macro dc 1 Mem Beg Mem End the normal memory search list dc 1 0 dc l Spcl Beg Spcl End PROM dc l Spc2 Beg Spc2 EndSpecial RAM load area dc 1 0 dc 1 0 0 0 0 0 0 0 0 0 0 0 0 free bytes for patching endm opt 1 OS 9 OEM Installation Manual F 5 Example ROM Source and Makefiles sysinit a SysInit perform system specific initialization part 1 SysInit reset reset all system hardware that can be movea l VBRPatch pc a0 get patchable vbr address movec a0 vbr set vbr ifdefRAMVects copy reset vectors from the rom into ram rom appears at 0 for first 4 cycles after a reset then it s the ram move l VectTbl pc 0 a0 copy reset vectors across move l VectTbl 4 pc 4 a0 endc SIExit ROMPAK1 bra SysRetrn return to boot a kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk SInitTwo perform system specifi
151. ne A 15 sysreset Restart System acciao ea A 16 hwprobe Test for Existence of Hardware iii A 16 B Trouble Shooting Big 8 Fe ME B 2 Step 1 Porting hg Te e ge TEE B 3 Step 2 Porting the OS 9 Kernel and Basic 1 0 System B 5 Setting Up the DevCon Descriptor Field for the Sc68681 Serial Driver B 8 Searching the Module Directory ENNEN ENNER B 11 C Low Level Driver Flags Introduction EN vey etn dessin cant O A C 2 Fiags or102606La arie e Lane C 2 Flags for 100850 5 EE C 3 Flags for 10685600 EEN C 3 le Gage ee EE CA le Care WE EE CA OS 9 OEM Installation Manual vii Flags for 1068681 E C 5 Flags tor 106890 d gialla aaa C 6 Flags for GR DA E C 6 D SCSI System Notes OS 9 SC Sa STAN DF IV E D 2 Hardware Configuration silicati D 3 Software Configuration D 4 F DE ONE iena D 5 EANET D 6 EET NERE eee D 6 E Using the OS 9 System Security Module Memory Management Units ii E 2 Hardware Software Requirements ii E 3 Versions el TR E 3 Configuring SSM Tor MC68451 Systems scrl E 4 Adding SSM tothe OS 9 Bootfile iii E 7 Step One Create a New Init Module rrrnnnnvrnennnovnnnnnnvnnnrnvnnvnnrnnnnennsnnnnvennnnnneennnn E 7 Step Two Create a New Bootfile rrrrnnrrrrvvvnrrernnnnnvrvvernnnnnnnnvnnnversnssnnnvnvnnsnssnnnnner E 9 Step Three Test SSM Operation rrrraannanrvvvnnnrennnnnnvvnvessnnnnnnnvnnnsssssssnnvnnnnnsnsnnnnnnn
152. nel 3 22 stages 4 8 boot code 2 3 finishing 2 8 initial function 3 5 porting 2 7 boot driver initialize A 14 boot drivers considerations 7 2 boot file large 7 4 boot files 3 8 boot a 2 4 2 5 2 7 3 8 3 22 3 28 bootfile 2 3 add SSM E 7 allocate memory for A 12 bootio c 2 7 3 8 bootstrap driver Support 7 5 bootstrap drivers 9 8 breakpoints 4 9 btf m 1 14 1 27 bug reports 6 2 bus errors 7 7 C cache coherency 8 12 control 8 2 custom configuration 8 7 DMA support 8 12 external 8 9 inhibited not serialized access 8 5 inhibited serialized access 8 5 peripheral access timing violations 8 10 timing loops 8 10 caching mode 8 6 CallDBug 3 37 calldebug A 14 Can t allocate table B 5 Can t open console terminal B 5 Can t open default device B 6 CBOOT 1 16 3 15 7 3 drivers entry points A 6 library entry points A 7 overview A 3 ChekPort 3 33 ClkLevel 5 10 CIkPort 5 10 CIkPrior 5 10 ClkVect 5 10 clock tests 6 6 clock module debugging 5 14 generic 5 10 clock modules 5 11 generic 5 8 real time support 5 9 select tick interrupt device 5 4 tick timer setup 5 5 ClockNm 4 4 5 5 cold2 4 12 4 13 coldstart errors B 7 coldstart 4 10 4 11 4 12 comm port 3 30 1 28 Index check 3 33 deinitialize 3 34 read character from 3 34 set up and initialize 3 32 3 33 Comm Adr 3 18 CommType 3 18 CONFIG macro 4 3 Cons Addr 3 18 ConsDeln 3 30 Conslnit 2 4 3 32 console device driver 4 7 I O driver 4 6 conso
153. nerally useful only for system calls that do not return parameters such as F Sleep 0 F Send This call heavily relies on intimate knowledge of the kernel so it should not be considered as a replacement for performing system calls via Trap 0 for example OS9 F xxx ldbra m Make a dbra loop using a 32 bit value sysglob m Get the system global data pointer sysboot m Bootstrap routines It allows several bootstrap modules to be used together without getting name clashes for SysBoot rompak m Set for Syslnit ROM extension code reach32 m Makea 32 bit PC relative branch OS 9 OEM Installation Manual Getting Started MWOS OS9 SRC IO Directory Structure Taking a closer look at MWOS OS9 SRC 10 we see lO 7 ARE N E O INET NFM PCF PIPE RBF SBF CF SCSI ee DEFS DOC DRVR ETC FM LIB MAKETMPL UTILS DESC DRVR DESC DRVR FM DEFS SCSI327 SCSI33C93 SCSI5380 SCSI SCSI53C710 SCSI53C94 SCSICOM RB327 RB5400 RBSCCS RBTEAC RBVCCS Almost all of the file manager subsystems contain at least two additional subdirectories DESC except for INET which holds descriptor sources DRVR which holds driver sources and possibly FM which holds file manager source if you purchased a license for file manager source Some file manager subsystem directories contain additional subdirectories for additional functional modularization For example the RBF DRVR directory has a SCSI sub
154. ng SCF device descriptor modules Seven elements are Definitions needed Name Description Port Address of Device on Bus Generally this is the lowest address that the device has mapped Port is hardware dependent Vector Vector Given to Processor at Interrupt Time Vector is hardware software dependent Some devices can be programmed to produce different vectors ROL oe Interrupt level 1 7 for Device When a device interrupts the processor the level of the interrupt is used to mask out lower priority devices 4 4 OS 9 OEM Installation Manual OS 9 does not allow a device to claim exclusive use of a vector if another device has already been installed on the vector nor does it allow another device to use the vector once the vector has been claimed for exclusive use OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O Name Description Priority Parity BaudRate Drive Name Interrupt Polling Table Priority Priority is software dependent A non zero priority is used to determine the position of the device within the vector Lower values are polled first A priority of zero indicates that the device desires exclusive use of the vector Parity Code for Serial Port This code will set up the parity number of bits per character and the number of stop bits for theserial port This codeis explained fully in the SCF section of the I O Technical Manual Baud Rate Selection for
155. ns For boot code that was written before OS 9 Version 2 4 you must address two problems Determining the physical sector size of the device If you can query the device for the size of a sector for example SCSI Read Capacity the issue is relatively simple If not the issue somewhat depends on the flexibility of the hardware There are two examples of drivers that may prove helpful in this issue Name Description SRC ROM This driver attempts to read the disk at a DISK sector size of 256 f that fails it attempts boot320 a to read the disk at 512 bytes per sector SRC 10 RBF The OMTI 5400 reads in the requested DRVR SCSI number of bytes as determined by the RB5400 Assign Parameters This allows the driver to read sector 0 and update the path descriptor Closely examine the SRC ROM CBOOT SYSBOOT diskboot c file for assistance in the creation of a booting algorithm OS 9 OEM Installation Manual Boot Drivers that Support Variable Sector Size continued OS 9 OEM Installation Manual Miscellaneous Application Concerns The logical sector size for the drive You can use the DD_LSNSize field in logical sector 0 to determine the logical sector size of the drive CBOOT SYSBOOT diskboot c uses the following logic for dealing with disk drives DD_LSNSize Description 0 Implies a pre 2 4 version disk drive The logical sector sizeis assumed to be 256 The physical size of the
156. nsfers 8 13 OS 9 Cache Control OS 9 Cache as B ee ell ko bai Ma a y i Ve sy erformance These cache systems Control are implemented as e On chip caches 68020 68030 68040 and 68349 CPUs e External cache hardware on the CPU e An independent module e A combination of these methods On OS 9 systems cache control is available in a flexible manner that provides you with total control over cache operation It also allows you to customize cache control for any special hardware requirements your system may have 8 2 OS 9 OEM Installation Manual System Implementation Refer to the OS 9 Technical Manual for information about how the kernel works Install Cache Operations OS 9 OEM Installation Manual OS 9 Cache Control To allow maximum flexibility of the cache control operations a separate system module called SysCache contains all of OS 9 s system caching functions The kernel installs the SysCache module as an extension module during system cold start initialization The kernel searches for extension modules specified in the I nit module If the specified module is found the kernel calls the module s initialization entry point For theSysCachemodule this entry point performs the following functions Replace the kernel s default no operation F CCtl system call with the active version in SysCache Flush and enable the system cache hardware To install cache operations in the s
157. nt as an example of writing Sysl nit or SI nitT wo Initial interrupt control register or bus controller movea IRQControl a0 move b EnableAll a0 The purpose is to make the code more readable The included sysinit a files further demonstrate this procedure The third entry point UseDebug indicates whether the ROM debugger is enabled e Ifthisroutine returns the Zero flag of the CCR true the debugger is disabled e Ifthe Zero flag is false the debugger is enabled Often whether the ROM debugger is enabled is determined by e Reading the state of a user configured switch on the system e Conditioning the Zero flag accordingly 3 36 OS 9 OEM Installation Manual Step One Porting the Boot Code The UseDebug Entry If no user configured switch is available there are two other Point Continued methods to set the Zero flag Hard code the UseDebug routine so that it always conditions the Zero flag to enable disable the ROM debugger Testtheoptional CallDBugflag availablein boot a The least significant bit of this byte may be used as a flagto indicate whether the debugger is enabled The following code fragment shows how to access and test this flag UseDebug btst b 0 CallDbug pc test the debug flag eori b Zero ccr flip Zero bit 0 0 indicates enabled rts OS 9 OEM Installation Manual 3 37 Step One Porting the Boot Code The Syscon c The syscon c file contains the code needed to build a bo
158. ntains the current value of these registers for each 68681 serial device in the system e The first byte of the pair is thel nterrupt Mask Register IMR image e The second byte of the pair is the Auxiliary Control Register ACR image OS 9 OEM Installation Manual OS 9 OEM Installation Manual Trouble Shooting Allocation of each pair of bytes is done via an offset pointer located in the DevCon section of SCF device descriptors The offset pointer is the address offset into this area as follows Byte Offset Device Number o BEE gt gt device 1 Aere eee gt gt device 2 A Ee gt gt device 3 You can put the following example code into your systyped file to make proper descriptors KAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Make Descriptors for sc68681 device Need to set up DevCon field correctly org 0 base offset starts at OEM_Glob D_681_1 do w 1 shadow register pair for device 1 D_681_2 do w 1 shadow register pair for device 2 D_681_3 do w 1 shadow register pair for device 3 D_681_4 do w 1 shadow register pair for device 4 D_681_5 do w 1 shadow register pair for device 5 D_681_6 do w 1 shadow register pair for device 6 D_681_7 do w 1 shadow register pair for device 7 KAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SCF device descriptor definitions used only by scf device descriptor modules SCFDesc Port Vector IRQlevel Priority Parity BaudRate DriverN ame MSVect MSIRQLV1 MS Prior Des
159. nvert Parameter to Hexadecimal Nibble SYNOPSIS int convhex inchr char inchr DESCRIPTION convhex converts the hexadecimal ASCII character parameter inchr into a hexadecimal nibble and returns it to the caller If inchr is not a hexadecimal ASCII character convhex returns 1 to the caller to indicate an error condition makelower Convert Upper Case Characters to Lower Case SYNOPSIS char makelower c char er DESCRIPTION make ower converts an uppercase alphabetic ASCII character to lowercase and returns it to the caller Any other character is simply returned to the caller intact A 10 OS 9 OEM Installation Manual The C Boot Technology powerof2 Convert Value to Power of Two SYNOPSIS DESCRIPTION int powerof2 value u_int32 value power of2 converts the unsigned 32 bit integer parameter value into a power of two bit position Any remainder is discarded If valueis equal to zero powerof2 returns 1 to indicate an error condition extract Allocate Memory from Boot ROM Free Memory List SYNOPSIS DESCRIPTION error_code extract size mem u_int32 size ptr to size of requested block u_char mem ptr to pointer to the block requested extract allocates memory from the boot ROM free memory list Memory is allocated in 16 byte increments For example if 248 bytes were requested extract rounds up and allocates 256 bytes sizeis a pointer to a 32 bit unsigned inte
160. o add the serial driver to the makefile Once the I nit module term descriptor and serial driver have been made an ident on each module should be performed to verify that the module owner is 0 0 If it is not the fixmod utility should be run on the module s with the u 0 0 option This will change the module owner to 0 0 OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O Preparing the After you are confident that the console device driver and e descriptor modules are in good shape you can prepare a Download File downioad file Merge each of the binary files of the OS 9 modules into a single file The order they are merged in is not Init needs to be set up to be ROM based Therefore set important however by convention the kernd is first EE keng init fou or fpsp040 SySgo shel cio recommended Cl scf math recommended Merge two new modules into a second file serial driver term descri ptor NOTE Actual file names vary according to I O controller names Refer to the Utilities Convert the two binary files to S record files using the Reference manual for more binex utility If your version of binex asks for a load information about binex address use zero We recommend that you make download and binex the two groups of files separately This saves a lot of downloading time You can keep the OS 9 standard modules in RAM and just download the driver descript
161. oad system modules to special memory areas Download OS 9 to the special memory area only Use the following procedure directly after a reset that is at the first prompt Only do both steps and if you are downloading the standard system modules If these modules are in ROM skip to step OS 9 OEM Installation Manual Downloading and Running the System continued OS 9 OEM Installation Manual Step Two Bringing Up the Kernel and Console I O Set ROM bug s relocation register tothe RAM address where you want the system modules Such as the kernel loaded Download the system modules Do not insert breakpoints yet Set ROM bug s relocation register tothe RAM address where you want the console driver and descriptor loaded The size of this code varies from less than 1K to as much as 2K Be careful not to overwrite the system modules Download the console driver and descriptor modules Do not insert breakpoints yet Type gb for RomBug to start the sysboot kernel search This will start boot stages If all is well you should see the following Found OS 9 Kernel module at xxxxxxxx This is followed by a register dump and a ROM bug prompt If you do not see this message the system modules were probably not downloaded correctly or were loaded at the wrong memory area Type gb again This executes the kernel s initialization code including the OS 9 module search You should see another register
162. of testing and validating the Considerations rest of your porting will need to be completed at this point Any additional drivers and booters should be developed now Further information within this manual should be reviewed at this time especially Chapter 7 Miscellaneous Application Concerns and Chapter 8 OS 9 Cache Control especially if using an 68020 68030 68040 or 68349 that uses caching If using disks Chapter 9 RBF VariableSector Support should be reviewed If using SCSI Appendix D SCSI System Notes should be reviewed Once all system software has been developed proceed to Chapter 6 Steo Four Testing and Validaton OS 9 OEM Installation Manual 5 21 Step Three Creating Customized I O Drivers and Finishing the Boot Code Completing the System If the resulting ROM is too large for your target system you can make one that omits the talk through and or download features by adjusting the DBG1 macro accordingly You should keep on hand a copy of the previous version that includes the system debugger for future system maintenance After testing the boot routine You must make a new boot debug ROM This one will have the sysboot a module replaced by your new bootxxx a module Makethenew ROM by repeating the procedure given in Chapter 3 Steo One Porting the Boot Code in the section on Putting the ROM Together To make the new boot debug ROM simply enter make bootdebug Create and
163. on Concerns Bootstrap Driver Reading the segment entries of the boot file data requires that Support continued the bootstrap loader have a reasonable knowledge of the way RBF allocates files In particular the last segment entry for the file may be rounded up to the cluster size of the media RBF always allocates space on a cluster basis The bootstrap driver can determine the media cluster size from the DD BIT value in the identification sector While RBF may allocate space on a cluster basis the bootstrap loader should always read the exact boct file size rounded up to the nearest sector 7 6 OS 9 OEM Installation Manual Soft Bus Errors Under OS 9 OS 9 OEM Installation Manual Miscellaneous Application Concerns Some instructions of the MC68000 family of processors are intended to be indivisible in their operation examples include TAS and CAS Systems that have on board memory off board memory and allow other bus masters to access the on board memory can run into deadlock situations when the on board CPU attempts to access the external bus while the external master is accessing the on board memory Often the bus arbiter breaks the deadlock by returning a bus error tothe CPU Thisisnot a hard bus error like non existent memory it is a soft bus error If the instruction is rerun it will typically succeed as the deadlock situation will have terminated The file SRC SYSMODS SYSBUSERR sysbuserr a provides a mechanis
164. on target startup rom_common This is built from target independent source files vectors a and boot a in the SRC ROM COMMON directory Source Relocatable Contents systyped System wide hardware definitions boot a boot r Standard system initialization code vectors a vectors r Exception vector table e The low level serial IO code rom serial l The actual names of the This is built from target independent source files files ioxxx a and ioyyy r vary ioxxx a and ioyyy a if needed in the according to the hardware SRC ROM SERIAL directory device type For example a driver for a Motorola 6850 will have the name 06850 a Source Relocatable Contents and so on OXXX a I OXXX F Console device primitive I O rou tines ioyyy a ioyyy r Communication port 1 0 routines e The target specific startup and bootmenu code rom port I This is built from target specific source files Sysinit a syscon c and bootio c in the PORTS lt target gt directory Source Relocatable Contents sysinit a sysinit r Custom initialization code syscon c syscon r Custom initialization code bootio c bootio r I O support routines for binboot 3 8 OS 9 OEM Installation Manual Step One Porting the Boot Code e The CBoot libraries sysboot I romio I etc Source Relocatable Contents sysboot sysboot library routines romi ol I O routines for CBoot and ROM debugger
165. ooting download the driver search again This way you do not need to burn an EPROM everytime you change the driver This special area of RAM must be carved out of the normal RAM list and put as a seperate bank of special memory Once the port is complete and all drivers are debugged the special RAM area can be returned to the general RAM memory list Modules needed in the bootlist are covered further in Chapter 4 Bringing Up the Kernd and the Console 1 0 3 20 OS 9 OEM Installation Manual Step One Porting the Boot Code The Vectors a The vectors a file contains definitions for the exception vector Fil table You normally do not need to edit this file unless your Ile target system has an unusual requirement Depending on your system hardware the actual vectors can be located in RAM or ROM Tospecify the location of the vectors define the label RAM Vecs in the systyped file If ROM space Refer to Appendix D for details of the conditional is exceedingly tight all vectors except the reset vectors may assembly flags used by this be located in RAM This is only possible if the final production file version of the boot ROM has noROM debugger and the reset vectors are included in ROM This saves a little ROM space due to lack of duplication OS 9 OEM Installation Manual 3 21 Step One Porting the Boot Code The Boot a File The boot a file contains the system initialization code that is executed im
166. or file by itself whenever it changes You can also merge the first set of files into the boot ROM image Wherever you put or load these modules verify that the memory area is defined in the special memory list and not in the RAM list OS 9 OEM Installation Manual 4 7 Step Two Bringing Up the Kernel and Console I O Downloading and Running the System Refer to the OS 9 ROM Debugger User s Manual and Appendix to be filled in later when the order of appendices is more settled for more information on setting the relocation register and downloading S Records You are now ready to download OS 9 to the target system and attempt to run it using the following procedure ROM bug has the ability to stage the boot in what we call boot stages Boot stages consist of breaking during the boot process twice in order to help verify that everything is all right The first of the two breaks will occur in boot a just before boot a jumps to the kernel Here the registers can be investigated to verify thay are all right before containing The second of the two breaks is within the coldstart routine of the kernel At this point the module directory has been completed and modules that need to be debugged can have break points inserted at this time At each of the two breaks in boot stages ROM bug will display the registers and give a prompt At each Rombug prompt enter gb The following explains the procedure to downl
167. ori bra s 0 Sleep dl FindTsk30 is process in sleep queue continue if not TimSleep P State a2 timed sleep FindTsk30 1 d2 d3 d2 FindTsk50 FindTsk40 2 d2 FindTsk50 P Prior a0 dl P Prior a3 dl FindTsk50 d2 d3 a0 a3 7 d3 FindTsk60 d0 FindTsk10 d3 FindTskER 0 do P SPUMem a3 a0 get chosen process a0 d0 FindTskER continue if so make sleep 0 lower than timed sleep is this least active so far keep searching if not update best task found if so is process current or active skip it if not get task s priority is its priority lowest so far skip it if not save best queue type found save ptr to best process task found inert process found use it if so search for most inactive process ANY available tasks found surely abort if not sweep register SPU memory any abort if not should be impossible P_Task a0 d0 get task number chosen P_Task a0 mark it stolen a7 d2 d3 a0 a3 restore regs ESNoTask dl Carry ccr FindTsk90 kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Subroutine DelTsk error no available tasks return carry set abort d0 a0 a2 a7 save regs is SPU memory allocated exit if not get process task number continue if none or task 0 clear process task is task number in range continue if not task number times 4 bytes per entry S_TskTbl a3 d0 w release task number Called when a process terminates TermProc to release t
168. ork with CBOOT CBOOT allows you to create menus that can be displayed on the system terminal This allows you to use a terminal to select the device from which to boot rather than by setting switches The C Boot Technology The CBOOT Common Booters The following is an overview of the common booter source files located in the MWOS OS9 SRC ROM CBOOT SYSBOOT directory As a whole you should not need to modify these sources They are however valuable as documentation File diskboot c initdata c binboot c MISC C Booters diskboot bi nboot Description This is the front end code for floppy and hard disk boots If necessary the code performs logical to physical mapping of sectors and deblocks physical blocks It also allocates the memory for the boot file If the boot file is large greater than 64K or non contiguous diskboot performs the necessary requests to read the boot file The requirements for the low level boot driver are thus reduced to hardware management This code can call either a CBOOT C driver or a converted assembly language driver This is part of the glue that initializes data for the CBOOT system when ROM bug is not being used ROM bug has its own initdata c routine This is the entry point used for testing downloaded boot routines It prompts for the bootfile size in dicates the load address to the op erator and waits for the operator to indiact
169. ot code source you must modify this file to initialize specific hardware devices on thetarget board Sysl nit branches back to boot a boot a then e Determines on which processor it is running e Performs memory searches e Calls Conslnit in ioxxx a to initialize the console port e Calls Syslnit2 and UseDebug which are also defined in the sysinit a file OS 9 OEM Installation Manual Porting OS 9 After returning to boot a the ROM debugger is called to give a register dump of the processor and prompt for more instructions The following diagram illustrates this process Apply power vectors a boot a sysinit a i OXXX A ROM bug to processor initial SP initial PC gt Reset bra Syslnt gt Syslnit SysRetrn lt Bra SysRetrn bsr Consl nit gt Consl nit ne 2 rts bsr Sysl nit2 sSysInit2 se iS bsr UseDebug ___UseDebug ae BIS bsr Debug gt At Rombug s prompt Figure 2 1 Chart of Files and the Subroutines They Contain NOTE Boot a is covered in more detail in Chapter 3 Porting the Boot Code ROMbug prompt to kernel entry boot a branches to the SysBoot routine SysBoot e Prompts the operator for the boot media or optionally auto boots from predetermined media target specific e Finds the bootfile e Finds the kernel e Returns a pointer to the kernel in the a0 register Once SysB oot has found the bootfile and the kernel s pointer is returned to
170. ot menu File that the CBOOT routines will present totheconsoleuser when boot a calls the Sysboot routine This file should contain a routine getbootmethod which should make repeated iniz_boot_driver calls to register all boot drivers which the user can initiate In addition getbootmethod should return an AUTOSELECT or USERSELECT value to indicate to the CBOOT routines whether the user should initiate the boot manually or if the CBOOT routines can attempt an auto boot It is typical for this kind of a decision to be made by getbootmethod based on either a switch or jumper setting or perhaps a value in non volatile memory 3 38 OS 9 OEM Installation Manual The ilnitext a File Step One Porting the Boot Code The Sysinit routines provide the basic initialization functions for the system Sometimes you need to provide application specific for example custom hardware that generates an interrupt on power up initialization functions You can include this type of functionality in the normal Sysinit code or in the initialization extension code initext Including this code in a initext a separate linked object file allows greater flexibility for production ROM image building as you can use a standardized boot ROM image and initext modules as building blocks for tailoring final ROM configurations You can use the example sysinit a filein Appendix F as an ex ample of how to use the initext macros ROMPAK1 and ROMP
171. otmethod and getboottype for the CBOOT system Y ou should review and understand this file Ifthe system contains hardware switches that are to be used to select the booting method you should place a routine to read the switches and configure the system for booting in this file There are also a set of variables defined in syscon c that are required for proper system operation You can create variables that are global to the drivers running under CBOOT by defining them in syscon c The systypeh file in PORTS lt target gt performs a similar function for C code as the assembler language systype d file by controlling system wide definitions Review this file for further information The C Boot Technology CBOOT Driver Entry Points Under CBOOT the boot drivers entry points are init Initialize Hardware SYNOPSIS error code init DESCRIPTION _ init initializes the hardware for use It may install interrupt service routines if necessary read Read Number of Blocks Requested into Memory SYNOPSIS error code read nsect lsect u_int32 nsect number of sectors to read u_int32 lsect starting logical sector DESCRIPTION red calculates any physical sector address needed for the device for example head sector and reads the requested sectors into memory nsect specifies the number of sectors to read Leet specifies the starting logical sector NOTE Thetotal byte count is guaranteed not to exceed 64K for
172. r s LUN 3 Fujitsu 2333 Hard Disk with Embedded SCSI Controller e Addressed as SCSI IDO Host CPU MVME147 e Uses WD33C93 SBIC Interface chip e Own ID of chip is SCSI ID 7 The hardware setup would look like this SCSI Bus gt SCSI GE F2333 Controllers ID 6 ID 0 Physical H D F D Tape H D Devices LUN 0 LUN 2 LUN 3 LUN 0 OS 9 OEM Installation Manual D 3 SCSI System Notes Software Configuration The high level drivers associated with this configuration are Name Handles RB5400 Hard and floppy disk devices on the OMTI 5400 SB5400 Tape device on the OMTI 5400 RB2333 Hard disk device The low level module associated with this configuration is Name Handles SCSI 147 WD33C93 Interface on the MVME 147 CPU A conceptual map of the OS 9 modules for this system would look like this Kernel Level OS 9 Kernel File Manager Level 3 RBF disks SBF tapes Device Driver Level RB5400 RB2333 SN Physical Bus Level SCSI147 If you have followed the previous guidelines you can easily expand and reconfigurethe SCSI devices both in hardware and software Three examples show how this could be achieved D 4 OS 9 OEM Installation Manual SCSI System Notes Example One This example adds a second SCSI bus using the VME620 SCSI controller This second bus has an OMTI 5400 controller and associated hard disk The VME620 module uses the
173. r absent 3 0 On chip data cache is not snoopy 1 On chip data cache is snoopy 4 O CIC bank Ois SRAM 1 CIC bank 0 is cache 5 O CIC bank 1is SRAM 1 CIC bank 1is cache 6 0 CIC bank 2is SRAM 1 CIC bank 2 is cache 7 1 CIC bank 3is SRAM 0 CIC bank 3 is cache NOTE Bits 4 7 are for 68349 CPU only The snoopy absent flags allow the kernel to make intelligent decisions as to when to actually flush thesystem s caches with F CCtl calls If the system s hardware capabilities allow the caches to maintain coherency via hardware means you can set the appropriate flags so that the kernel performs only essential cache flushes The 68349 CIC bank flags allow the integrator to control the mix of SRAM cache usage for the system OS 9 OEM Installation Manual ROM Debugger and Caches Refer to the OS 9 68000 ROMbug User s Manual for more information about ROMBug OS 9 OEM Installation Manual OS 9 Cache Control The ROM bug debugger has a limited knowledge of caching If you use ROM bug in a system where there are no caches external tothe CPU chip link it with flushcachel when the ROM is constructed When using a 68349 CPU you should link flush349 1 instead of the usual flushcachel routine If external caches are available you should provide a separate routine that flushes any on chip caches as well as the external caches You can add this routine to the sysinit a file or link in your own loc
174. r d OutChar 0 OutChar x if th OutChar 0 return 1 for t 0x10000000 t gt 1 t 0x10 if h gt t break skip leading zeros OS 9 OEM Installation Manual for t gt 1 t 0x10 d h t if d lt 9 OutChar d else OutChar d 10 l h 0 a h d t return 1 int outint i u_int32 i u_int32 t 1 0 if i OutChar 0 return 1 t 10 for t 1000000000 t gt 1 skip leading zeros if i gt t break for t gt 1 t 10 OutChar i t 0x30 i i i t t l return 1 void outsome s u_char s if s outstr lt none gt else outstr s void outerase n u_int32 n int i OutChar OutChar BS for i n 1 i gt 0 i OutChar BS OutChar OutChar BS OS 9 OEM Installation Manual Example ROM Source and Makefiles Example ROM Source and Makefiles u_char ask_ynq quit u_int32 quit char inchar newval newprmpt valspec u_int32 n valspec FALSE newprmpt TRUE LOOP if newprmpt outstr n lt yes gt lt no gt if quit outstr lt quit gt outstr if valspec if newval y outstr yes else if newval n outstr no else outstr quit newprmpt FALSE inchar getinchar if inchar CR if valspec newprmpt TRUE OutChar BEL continue
175. r or existing debugger on your running target much of this step is done blind However once ROMbug is available it is a good debugging tool for the remainder of the port You can think of boot a as the kernel for booting It is prewritten and you do not have to modify it Chapter 3 Porting the Boot Debug ROM contains additional information about boot a For more information about sysinit a refer to Chapter 3 Porting the Boot Code Power up the ROMbug prompt Once you supply power to the 68000 processor or a reset occurs the processor e Performs a longword read cycle at address 0 e Places the result in the a7 register stack pointer e Performs a longword read cycle at address 4 e Places the result into the program counter PC register e Starts executing instructions as it normally does Many computer boards have address logic which maps these first two reads to wherever the ROM is actually located Then the address mapping returns to the board s standard memory map Once this has been done the processor can execute machine language instructions like it normally does The initial PC valuein the OS 9 boot code is a label called Reset This label is defined in the boot a file Once boot a starts executing it Sets up a few variables Branches toa label called Sys nit Sysl nit is defined in the sysinit a file Although examples of sysinit a are available from the bo
176. r specific device class issues for example disk drives on an OMTI 5400 The high level drivers Prepare the command packets for the SCSI target device Pass this packet to the low level subroutine module The low level subroutine module passes the command packet and data if necessary to the target device on the SCSI bus The low level code does not concern itself with the contents of the commands data it simply performs requests for the high level driver The low level module also coordinates all communication requests between the various high level drivers and itself Thelow level module is often an MPU CPU specific module and thus can be written as an optimized module for the target system The device descriptor module contains the name strings for linking the modules together The file manager and device driver names are specified in the normal way The low level module name associated with the device is indicated via the DevCon offset in the device descriptor This offset pointer points to a string containing the name of the low level module An example system setup shows how drivers for disk and tape devices can be mixed on the SCSI bus without interference OS 9 OEM Installation Manual SCSI System Notes Hardware Configuration OMTI5400 Controller e Addressed as SCSI ID 6 e Hard disk addressed as controller s LUN 0 e Floppy disk addressed as controller s LUN 2 e Tape drive addressed as controlle
177. r user may do this Create a large file then copy and or merge it several times until the media is full Then delete files one by one and use the free command to ensure that all disk Space is properly recovered F ormat media for all formats supported by your system Verify with dcheck free and dir Pay particular attention to interleaving Only the super user may do this Test simultaneous floppy disk and hard disk operations if your system is so equipped Especially look for DMA contention problems if applicable Test the system with multiple drives installed to maximum expansion capability Step Four Testing and Validation Clock Tests These tests exercise and verify correct operation of the system clock O Test the ability to set and reset the date and time using the setime and date t commands Test the time of day accuracy against a stopwatch with disk and terminal I O operations in progress pre load and use the date command for testing Test the system tick accuracy against a stopwatch with and without disk and terminal I O operations in progress pre load and use the sleep command for testing Use at least a 10 minute test period for a rough test then a 12 to 24 hour period for a high accuracy test amp Run multiple concurrent tasks and test proper timeslicing 6 6 OS 9 OEM Installation Manual Step Four Testing and Validation Final Tests Test all other supported I O devices if any th
178. red until later in this manual systype d consists of five main sections that are used when porting OS 9 ROM configuration values Target system specific definitions Init module CONFIG macro amp SCF device descriptor macros and definitions RBF device descriptor macros and definitions The ROM configuration values and the target system specific definitions arethe only sections that areimportant for the boot code Therefore these section are covered in this chapter Chapter 4 Bringing Up the Kernel and Consolel O covers the remaining sections 3 12 OS 9 OEM Installation Manual The ROM Configuration Values Target Specific Labels OS 9 OEM Installation Manual Step One Porting the Boot Code The ROM configuration values are normally listed at the end of the systyped file These values are used to construct the boot ROM and consist of the following Target specific labels Target configuration values Low level device values amp Target system memory definitions Target specific labels are label definitions specific for your target hardware They can define e Memory locations for special registers on your hardware e Specific bit values for these registers For example your target hardware processor has a register which controls to which interrupt levels on a bus the board will respond This may be necessary if several target boards are sharing the same bus and you would
179. rnel is a biased value in that the kernel adds a value of 68000 to the value passed up and then stores that new value in the kernel s system global D MPUTyp OS 9 OEM Installation Manual 3 17 Step One Porting the Boot Code Low Level Device Low level device configuration labels configure the low level Configuration Labels I O These values are as follows Label Effect Thisis the base address of the console device This is used by the low level ioxxx a serial driver Cons Addr This is used by the ioxxx a code to determine which device will be the console ConsT ype This is the base address of the communications port or Comm port It is used by the ROM debugger to download S record files from the host This is used by the ioyyy a code to determine which device will be the Comm port Comm_Adr CommT ype Each individual ioxxx a and ioyyy a driver has its own configuration labels These labels are defined for each driver within the source of the driver as well as Appendix C of this manual Refer to the driver you will use and set these labels correctly You need to define the following labels for the low level disk booter e FD Vet e FDsk_Vct e SysDisk You should define these labels as 0 if you do not have a disk booter 3 18 OS 9 OEM Installation Manual Target System Memory Labels Example Memory Definitions Due to the way that the boot code has been written the first RAM
180. rol b move l beq s exg move 1 move 1 bsr s exg move 1 bset movea 1 movea 1 lea move 1 OS 9 OEM Installation Manual d0 d3 a0 a2 a7 save regs do Protec90 PSSPUMem a4 Protec90 0 d3 zero size returned exit if so SPU image allocated exit if not strange sweep register S_BlkBit a3 d3 get SPU block size power 2 n a2 dl dl do 1 do d3 dl d3 do d1 do d1 d3 0011 d3 d3 d3 copy beginning block address form end of requested area 1 ptr end of requested area convert address to beginning block num convert end addr to last block number convert to number of blocks 1 copy beginning block number strip off lower two bits make SPU bit offset of first block ReadProt WritProt d2 protection mask d3 d2 shift mask into initial position P DbgPar a4 d3 is this program being debugged Protec20 d3 a4 d0 a7 4 a7 d0 Protect a4 d3 a7 do continue if not switch to parent debugger s proc desc save reg restore original size of area update parent debugger SPU image restore process descriptor ptr restore reg ImgChg P State a4 mark SPU image change P SPUMem a4 a2 get ptr to SPU process memory P_BlkCnt a2 al ptr to SPU map block count P_SPUImg a2 a0 ptr to SPU image a0 d3 any allocated Using the OS 9 System Security Module 01 0 67le beq s Protec90 01 2 5331 Protec40 subq b 1 al dl wi 01 6 6706 beq s Protec50 01 8 640c bcc s Protec60
181. routine reads the current time from the real time clock device e Set time This routine sets the current timein the real time clock device Under the generic clock system the real time clock module is always a subroutine module called rtclock OS 9 OEM Installation Manual 5 9 Step Three Creating Customized I O Drivers and Finishing the Boot Code Using Generic Clock Modules To create system clock modules Determine the type of tick device to use for the system Examine the MWOS OS9 SRC SYSMODS GCLOCK directory e If an existing tkXXX a file supports the system s tick device this file is the system s tick module e If none of the files are appropriate create a tick module by using an existing version as a model Examine the existing rtcXXX a files in the GCLOCK directory if the system requires real time support e Ifartoxx a file that supports the tick device already exists this file is the system s real time clock module e If none of the files are appropriate create a real time clock module by using an existing version as a model Edit the system s systype d file so that the following variables describe the system s clock configuration Variable Description ClkVect Tick timer vector ClkPrior Tick timer priority on vector Should be highest ClkPort Tick timer base address TicksSec Ticks per second usually 100 ClkLevd Tick timer IRQ level may not be required
182. rsrsrvrrvneeens 5 4 OS 9 Tiek Timer SAP sed 5 5 Tide TIME PACE WAU OWN allieva 5 6 Real Time Clock Device Support NENNEN 5 7 Microware Generic Clock Modules ii 5 8 Wie ze Vgl RE 5 8 Ticker SUP v re 5 9 Real Time Clock Support sel alla le acl iad fede ate 5 9 Using Generic Clock Modules serge ek Seege EE losanna 5 10 Philosophy of Generic Clock Modules A 5 11 Automatic System Clock Startup orarie alia 5 12 Debugging Clock Modules on a Disk Based Gvstem in 5 14 Debugging Clock Modules on a ROM Based System 5 15 Creal no DISKDFIVes a lella ia 5 16 Testing the Disk Driver eege ear 5 17 Creating and Testing the Disk Boot Routines mssrrvvvrnrannnnvvvrrnrrrrnnnnnvvrrerrsnssvrvvnnene 5 18 Testing the CBoot Disk Boot Module A 5 20 FURE EC NS de AS alia a 5 21 Completing the System arv 5 22 6 Step Four Testing and Validation General Comments Regarding Testing 6 2 Kernel Tests aa 6 3 Serral FOS CE Tesla 6 4 Disk DREPTE eene ee eebe 6 5 OS 9 OEM Installation Manual v CUI TS EE 6 6 FTSE un 6 7 System Configuration ET e e DEE 6 8 A Final NOS anelli elia a 6 9 7 Miscellaneous Application Concerns Disk Booting Considerations sa 20 senka wie a iat bette 7 2 Boot Drivers that Support Variable Sector SIZE mmssrrrvvrrrrrnnnvrrrvrernrnnnnrrvererrrrrenr 7 2 Bootstrap File Spec tee Le cilea ae aa 7 4 Making Boot areale ere 7 4 Bootstrap Driver SUpport illo ai 7 5 Soft Bus Errors Un
183. s involved For additional copies of this software or documentation or if you have questions concerning the above notice the software or the documentation please contact your Microware supplier TRADEMARKS OS 9 and OS 9000 are registered trademarks of Microware Systems Corporation All other product names referenced herein are either trademarks or registered trademarks of their respective owners ISO 9001 Microware Systems Corporation Reg No A3084 MUCOUYHR 1900 N W 114th Street Des Moines Iowa 50325 7077 Phone 515 223 8000 Table of Contents 1 Getting Started Developingia Plana aiar 1 3 The Host System HardWare 1 4 The Host EENEG Le 1 5 The Target System Hardware ira aaa 1 5 PrePorting EE 1 6 TRE MAKE Utility varar desember Geddes 1 8 Common File El SUIXG vaare ee Le 1 9 Checking the Contents of the Distribution Package AAA 1 10 Structure of the Distribution Package on the Host System rrmnnrrnnnnvvvrrvrrnrsvvrrvnenr 1 11 MWOS OS9 SRC Directory Structure 1 12 MWOS OS9 Diredory e TEE 1 13 OS 9 El ge de en 1 14 MWOS OS9 SRC IO Directory Structure 1 15 MWOS OS9 SRC ROM Directory Structure ii 1 16 Taking a closer look at MWOS OS9 SRC ROM we SEE nn 1 16 These directories are as follows kk 1 16 The Object Directories eege Dee dd es 1 17 The object directories look likethiS ii 1 17 Additional Reference Materials NEEN 1 19 2 Porting OS 9 GE UNS ATA suse
184. s of SSM 040 The difference between the two is the cache mode for supervisor state e ssm040 is writethru e ssm040_cbsup is copy back In both cases the user state cache mode defaults to write thru Select the appropriate SSM module for the supervisor state cache mode desired and then set up cache overrides in the nit module cache list entries to turn on copy back etc regions for user state Using the OS 9 System Security Module Configuring SSM for MC68451 Systems Refer to pages 3 4 of the April 1983 for a complete description of the Address Space Table Motorola MC68451 manual You may need to modify the code for the MC68451 SSM module for your particular hardware A short source file ssmdefs a is included with the OS 9 OEM distribution to allow you to specify the base address of the MC68451 chip and the offsets intothe Address Space Table used by the SSM code In most cases you will only need to change the device base address Some hardware implementations of the MC68451 Specifically the Heurikon M10 V10 CPU s use the DMA portion of the Address Space Table AST instead of the MPU section which is normally used You should change the offsets for the AST registers to match your hardware The ssmdefs a file has conditional directives to accommodate either the standard or Heurikon style implementations For example the Eltec VEX CPU has two MC68451 chips located at 00fa8000 and 00fa8200 The SSM code supplie
185. service routines toshare some private global variables Two system global variables are of particular interest to the protection module e D AddrLimisthehighest RAM ROM address found by the kernel s coldstart routine Init can use D_AddrLim to determine the physical block size most appropriate for the memory protection hardware e D BlkSizis the system s minimum memory allocation sizein bytes Theinit routine should reset D_BIkSiz to the minimum blocksize the memory protection hardware can accept The value must be an integral power of two and has a default value of sixteen bytes Both D_AddrLim and D_BIkSiz are of type long In the example code the protection module allocates global storage to contain a task allocation table This table contains one entry for each hardware task number available to be assigned to a process E ach four byte entry contains a pointer to the process assigned tothe task number If thetask number has not been assigned to a process the entry is NULL NOTE If init returns the carry bit set cold start will abort and the system will not come up Using the OS 9 System Security Module The remaining subroutines implemented as system calls are SSM Module documented in the OS 9 Technical Manual F or reference Structure these are continued e F Pemit Allow Process Access to Specified Memory e F Protect Remove Process Permission to Memory Block e FS AIITSK Ensure that Protection Hardware Is Ready e F D
186. set up correctly or it was forgotten Thereis a hardware problem that is related to interrupt exception processing The manager driver and descriptor modules ownership is not in the super group 0 n The most likely problem is a defective driver module This requires actual debugging work The best way to debug the driver is to repeat the procedure outlined previously in the section entitled Downloading and Running the System putting breakpoint s at the entry points in the driver s INIT GETSTAT SETSTAT and WRITE routines in step You can then tracethrough the driver as it initializes the hardware and tries to print the shell message If the system never reaches this point problems a b or d are likely OS 9 OEM Installation Manual OS 9 OEM Installation Manual 5 Step Three Creating Customized I O Drivers and Finishing the Boot Code ACOUGO aan 5 3 Guidelines for Selecting a Tick Interrupt Device 5 4 OS 9 Tick Timer Setup E 5 5 Tick Timer Activation asa 5 6 Real Time Clock Device Support 5 7 Microware Generic Clock Modules 5 8 Tickgeneric Support REENEN 5 8 Tiker SUPPE Guns ee 5 9 Real Time Clock Support 5 9 Using Generic Clock Modules 5 10 Philosophy of Generic Clock Modules 5 11 Automatic System Clock Startup 5 12 Debugging Clock Modules on a Disk Based System
187. st is a non OS 9 system your target system will need to format the floppy and put the bootfile onto the floppy by using os9gen Before using os9gen all of the modules needed for the OS 9B oot file must reside on a disk somewhere either in a RAM disk or on the floppy itself Put these modules on disk by using either thesaveutility to save them from memory to the disk or using kermit to transfer the modules Once these modules are on the disk use the os9gen utility to make the floppy a system disk Create a low level disk boot driver To debug this low level boot driver use the ROM bug ROM debugger The CBoot routines and the low level driver are linked into a ROM image and tested The procedure to debug or test is explained later in this chapter The rom_imagemakefile will need to be modified to include this low level boot dirver in the FILES macro Also you will need to modify syscon c to add a menu item to start up your new low level disk boot driver See the files 68020 PORTS MVME147 SYSCON C and 68020 PORTS MVME 147 RECONFIG C for examples of how this is done OS 9 OEM Installation Manual 5 19 Step Three Creating Customized I O Drivers and Finishing the Boot Code Testing the CBoot Disk Boot Module The following procedure tests and debugs the CBoot disk boot module Merge the stb file to the end of the ROM image by uncommenting the RBGSTB macro in rombug make prior to making the image Once the
188. stem Security Module This section explains how to write a System Security Module SSM for an OS 9 system with memory protection hardware that Microware currently does not support The code for individual systems will vary considerably according to the design of the hardware Source code for a customized system security module is provided in a later section to illustrate the memory management principles discussed The module you write must accomplish the same tasks but may accomplish these tasks in whatever way you deem most effective The System Security Module SSM protects system memory by preventing processes from accessing memory not assigned to the process Each time a process accesses memory the memory address is passed through memory protection hardware which checks the address to see if the process has access to it If the address is protected a bus error exception is generated The purpose of the SSM is to install a group of system service requests which the kernel invokes when it gives a process access to specific memory blocks NOTE TheSSM does not provide address translation of any kind even if the memory management hardware is capable of this The OS 9 kernel s memory management routines are designed to make the implementation of an SSM as easy as possible To accomplish this the kernel must make two assumptions about how the protection hardware works e Thekernel assumes that the memory protection hardware will be disa
189. ster Description a0 Pointer to an executable module with a valid header hopefully the kernel a4 Possibly updated free RAM list a5 Must be intact from above a7 Possibly updated system ROM list cc Carry set dl w error status if bootstrap failed 3 24 OS 9 OEM Installation Manual Steps Boot a Goes Through to Boot the Kernel continued OS 9 OEM Installation Manual Step One Porting the Boot Step 17 Validate the kernel After SysBoot returns to boot a with a pointer to the kernel boot a validates the kernel header Step 18 Initialize registers for entry to the kernel Before entering thekernel theregisters should have the following conventions Code Register do dl l d2 l d3 d4 d7 a0 al a2 a3 a4 a5 Els a7 Description Total RAM found in the system MPUT ype Trapflag for system debug Growth startup method Clear Kernel entry point Boot ROM entry point Clear System free RAM list Exception jump table pointer Operating system global data area 4K scratch Memory System ROM map Step 19 Jump to the kernel s execution point 3 25 Step One Porting the Boot Code Memory Search Explanations The RAM Search An important function of boot a is building the system s memory allocation using a memory search list OS 9 uses this search list to define the usable areas of the target system s RAM and special memory You do not have to
190. str sends a null terminated string to the console output device str is a pointer to the first character in the string to send NOTE outstr always returns SUCCESS OS 9 OEM Installation Manual A 7 The C Boot Technology InChChek Perform Unblocked Read of One Character SYNOPSIS int Inchchek DESCRIPTION InChChek performs an unblocked read of one character from the console input device If the device has not received a character InChChek does not wait but returns an error designation of 1 tothe caller Otherwise the character is returned InChar Wait to Physically Receive One Character SYNOPSIS char InChar DESCRIPTION nChar waits for the hardware to physically receive one character echoes the input character back to the console output device via the OutChar function and returns the character to the caller OutChar Physically Send One Character SYNOPSIS void outchar c char Cc DESCRIPTION OutChar physically sends one character to the console output device OutHex Convert Parameter to ASCII SYNOPSIS void OutHex nibble char nibble DESCRIPTION OutHex converts the lower four bits of the parameter nibble to an ASCII hexadecimal character 0 F and sends it to the console output device via the OutChar function b 8 OS 9 OEM Installation Manual The C Boot Technology Out Hex Convert Parameter to ASCII SYNOPSIS DESCRIPTION void OutlHex byte u_c
191. sysinit a file Sysinit2 is also located in the sysinit a file OS 9 OEM Installation Manual Step 6 Step 7 Step 8 Step 9 Step 10 Step 11 Step 12 Step 13 Step One Porting the Boot Code Set up 68000 vector table to vbr register or memory location 0 if needed If the vector needs to be copied from the ROM toa RAM area this is where it occurs This copy will occur if the RAMVects label is defined Set up OS 9 exception jump table The exception jump table is an intermediate table between the vector table and the kernel The pea and jmp instructions are set up in the table at this time Each vector in the vector table points to a particular entry in the exception jump table Each entry in the exception jump table has the following format pea vector_table_address a7 jmp vector_exception_handler Initialize global data for RomBug if needed If you use RomBug its global data needs to be initialized before it can run Determine CPU type Possible CPU types include 68000 68010 68020 68030 68040 68070 or 68300 The CPU type is saved in the MPUT ype system global variable When running the kernel keys off of this variable to determine the type of processor on which it is running Branch to the UseDebug label If UseDebug returns with the zero bit in the CCR cleared the ROMbug is enabled Initialize ROMbug if it is enabled Run the Sysinit2 routine Performs any fin
192. t all system hardware Copy thereset stack pointer and initial PC vectors from ROM to RAM if the system has its vectors in RAM boot a initializes the other vectors Initialize any devices not connected to the reset line amp Initialize any CPU control registers and status displays Example is initialization of VBR register Attempt to locate and execute the extension code initext a rompak m if the ROMPAK1 macro is used This routine does not return via an rts instruction The return to boot a is made directly by a bra SysRetrn instruction Step One Porting the Boot Code The SInitTwo Entry Point If any device still needs to be initialized or setup this is the place to do it The UseDebug Entry Point The second entry point SI nitT wo is used for any system initialization that may be required after the first call Often this routine consists of a simple rts instruction as most systems can perform all their required initialization during the first call to SysI nit SInitTwo is called after boot a has e Initialized the vector table for vectors in RAM and the exception jump table e Performed the memory searches e Determined the CPU type If the ROMPAK2 macro is used it attempts to locate and execute the extension code associated with the second call to sysinit initext a rompak m To further explain the RQ control register example from systyped you can use the following code segme
193. t process The files needed to accomplish this are Code contains more vectors a boot a ioxxx a ioyyy a Sysinit a systyped information about the files syscon c bootio c and the sysboot and rombug libraries pede This step includes e Hardware dependent initialization and configuration sysinit a e ROM bug e Theability to boot from ROM or an image downloaded into RAM You will need to define key labels in systyped and the makefile to correctly configure the code for your particular target hardware w For your initial port of OS 9 to your target we strongly recommend that you first create a ROM RAM based system to reduce the complexity of the port downloading target specific modules into RAM through ROM bug s communication port from the development system Later as more of the port is accomplished you can incorporate other booting methods For this reason source for a simple ROM RAM boot routine has been included in Appendix G This simple menu booter is syscon c Porting the OS 9 kernel and basic UO system e This involves more modification to the systyped file module from which the E kernel configures itself For You will need to make an Init module and high level more information about the serial drivers and descriptors for your particular Init module refer to Chapter hardware Once this is complete and is working a E ROM able OS 9 system exists Technical Manual OS 9 OEM Installation
194. t should be read for an X Off character If an X Off character is present OutChar should delay until the character is no longer present in the input port OutChar also needs to check the output character to see if it is a CR 0x0d character and if so output an LF 0x0a character as well InChar Read Character from Device s Input Port SYNOPSIS DESCRIPTION InChar Input None Output d0 b character to read InChar reads a character from the device s input port If a character is not present InChar must loop until one is After the character is read a branch to OutChar is necessary to echo the character Ifthel O driver is being written for the obsolete Debug ROM debugger you need to convert all lowercase characters to uppercase The ROM bug ROM debugger has no requirements OS 9 OEM Installation Manual 3 31 Step One Porting the Boot Code Consinit Initialize Console Port SYNOPSIS DESCRIPTION ConsInit Input None Output None Consl nit initializes the Console port It should reset the device set up for transmit and receive and set up baud rate parity bits per byte number of stop bits and desirable interrupts on the device Portinit Set Up and Initialize Comm Port SYNOPSIS DESCRIPTION PortInit Input None Output None Portl nit sets up and initializes the Comm port in the same or similar way that the Conslnit routine initializes the Console port ConsSet Disable Console Port SYNOPSIS
195. t the kernel from performing a F STimecall during coldstart by setting the N oC ock flag in the I nit module s M Compat byte bit 5 1 This allows the system to come up without the clock running Once the system is up you can debug the clock module s as required Step Three Creating Customized I O Drivers and Finishing the Boot Code Debugging Clock Modules ona Disk Based System Microware highly recommends that you exclude the clock modules from the bootfile until they are fully operational To debug the clock modules pg Make the Init module with the NoClock flag in the M Compat byte set Exclude the module s to be tested from the bootfile Bring up the system Load the tick real time clock module s explicitly Use the system state debugger or a ROM debugger to set breakpoints at appropriate places in the clock module s Run the setime utility to access the clock module s Repeat steps to until the clock modules are operational When the clock module s are operational Remake the I nit module so that the NoClock flag is clear Remake the bootfile to include the new I nit module and the desired clock module s Reboot the system OS 9 OEM Installation Manual Debugging Clock Modules ona ROM Based System OS 9 OEM Installation Manual Step Three Creating Customized I O Drivers and Finishing the Boot Code For ROM based systems there are two
196. t to number d3 clear extraneous bits d3 D BlkSiz a6 reset system block size do do times two bytes per entry SPUBlks pc d0 w d3 get number of spu blocks da3 S_SPUBlks a3 save number of SPU blocks 0 d2clear SPU mapping RAM MAXTASK 1 dl start with highest task number 2 d3 divide SPU blocks by 4 blocks per word 1 d3 minus one for dbra dl SPU Task select task HSPU RAM a0 get SPU mapping RAM ptr d3 do number of words per task d2 a0 clear mapping RAM for task OS 9 OEM Installation Manual 0078 51c8 007c 51c9 0080 43fa 0084 4e40 0088 4cdf 008c 4e75 008e 003c 0092 323c 0096 60 0 0098 0000 009c 0000 00a0 0000 00a4 0000 00a8 0000 00ac 0000 00b0 ffff dbra dbra lea os9 movem 1 rts ori move w bra s Init99 InitErr SvcTbl de de de de de de dc w z Using the OS 9 System Security Module d0 Init SP30 dl InitSP20 SvcTbl pc al F SSvc install SPU system calls a7 d0 d42 d3 a0 al restore regs return carry clear return carry set return sic error repeat for all pages of task repeat for all tasks Carry ccr E NoTask dl Init99 F DelTsk SysTrap DelTsk 4 F A11Tsk SysTrap AllTsk 4 F Permit SysTrap Permit 4 F Protect SysTrap Protect 4 F ChkMem SysTrap ChkMem 4 F GSPUMp GSPUMp 4 1 end of table kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Subroutine Permit Update SPU image in user process to allow access to a specified memory
197. ten so that the real time R clock is accessed to read the current time or set the time after efer to the OS 9 Technical O Oo the ticker is initialized When F ST ime s month parameter about F STime is zero a call is made to read the current time When the month parameter is not zero the new time is set in the real time clock device OS 9 OEM Installation Manual 5 7 Step Three Creating Customized I O Drivers and Finishing the Boot Code Microware Generic Clock Modules Tickgeneric Support You should never need to modify this code because all system specific functions are concentrated in the ticker and real time clock portions of the generic clock system To allow maximum flexibility for mixing the various types of tick timer devices and real time clock devices and to simplify the implementation of system clock functions Microware has developed a suite of routines called the generic clock routines These routines are located in the MWOS OS9 SRC SYSMODS GCLOCK directory They provide three separate levels of support e Tickgeneric support e Ticker support e Real time clock support The tickgeneric a file performs all common functions for tick and real time clock initialization This routine is the main body of the clock system and it uses the following algorithm Test if system clock is running If so then skip tick timer initialization Initialize the tick timer
198. the boot a process 3 27 Step One Porting the Boot Code The Patch Two globally available patch locations are available for the Locations following functions Name Description TransF act This is a 32 bit location that should represent the translation constant between the CPU S address versus a DMA device s address for the same location The default value is zero Boot drivers that use DMA should use this value Refer to Chapter 8 when passing address pointers to from the Miscellaneous Application DMA device Concerns for details of th P reel SE SE VBRPatch This is a 32 bit location that you can use to set override the default values the VBR of the 68020 68030 68040 and CPU 32 processors if the vectors are to be located at an address other than the default value of 0 NOTE Relocating the VBR is not supported for the 68000 68008 68010 and 68070 processors 3 28 OS 9 OEM Installation Manual Step One Porting the Boot Code The ioXXX and Twosourcefiles contain very low level O subroutines to ioyyy Files handle the console I O port and the communications port e The console I O routines are used by the boot for error DEE E messages and by the debugger for its interactive I O I O routine files are referred e The communications port is used for the download and to as o xxx and io yyy The talk through functions actual names of these files usually reflect t
199. thout considering flow control X On and X Off or carriage return line feed CR LF combi nations This is similar to the OutRaw routine for the Console port OS 9 OEM Installation Manual 3 33 Step One Porting the Boot Code InPort Read Character from Comm Port SYNOPSIS InPort Input None Output d0 b Character read DESCRIPTION InPortreads a character from the Comm port If no character is available it must wait until one is available PortDeln Deinitialize Comm Port from Polled Mode SYNOPSIS PortDeIn Input None Output None DESCRIPTION PortDdn deinitializes the Comm port from a polled modeto an interrupt driven mode This is similar to the ConsDeln routine for the Console port 3 34 OS 9 OEM Installation Manual The Sysinit a File The Sysinit Entry Point For more information about ROMPAK1 refer to the section on initext a OS 9 OEM Installation Manual Step One Porting the Boot Code The sysinit a file should contain all special hardware initialization that your system will require after a reset or system reboot The sysinit a file consists of three different sections or entry points e Syslnit e SInitTwo e UseDebug The first entry point Sysl nit is called almost immediately after a reset by boot a Sysl nit performs any special hardware actions that the system may require during start up Sysinit needs to do the following Execute a reset instruction to rese
200. to modify pre V2 4 bootstrap drivers accordingly When reading a boct file the main considerations for the bootstrap driver are as follows Support should be maintained for contiguous less than 64K boot files because this is os9gen s default Once the bootstrap driver has read the media s identification sector it should inspect the bootstrap variables to decide whether a bootstrap file is present If both the bootstrap fields are zero the media is non bootable and an appropriate error should be returned If the bootstrap file is present the bootstrap driver should determine what type it is If both bootstrap fields are non zero the driver is dealing with a contiguous less than 64K boot file The driver typically e Allocates memory for the boot file specified by DD BSZ e Locates the start of the bootstrap data specified by DD BT e Reads the data If the bootstrap size field DD BSZ iszeroandthe data pointer DD BT isnon zero DD BT is pointing to the RBF file descriptor associated with the boot file The driver should then e Read the file descriptor into memory e Inspect the file size F D_SIZ and segment entries FD_SEG todeterminethe boot file s size and location s on the disk The driver typically reads each segment until the entire boot file has been read into memory When loading the boot file into memory the driver must ensure that the data appears in a contiguous manner Miscellaneous Applicati
201. ts is f often well worth it e Hook up the serial ports that link the host to the target system and if possible test the communications link using existing software that already runs on your host system 1 6 OS 9 OEM Installation Manual Getting Started The following is a typical host and target interconnection Target EG CRT Workstation Figure 1 1 Typical Host and Target Interconnection If you are porting to a slow Ge SCH DE NOTES Use 9600 baud or the highest possible data rate GE TEE for RS 232 links to maximize download speed in order for the processor to The default is 9600 baud ki ith the transfer l E The X On X Off protocol is used for flow control OS 9 OEM Installation Manual Getting Started The Make Utility While you are porting OS 9 to the target system you will use the make utility extensively The OS 9 make utility uses makefiles to re assemble and link many major parts of OS 9 M akefiles simplify software creation and maintenance Familiarize yourself with the We strongly recommend that you use and maintain the e teo makefiles as you port OS 9 The makefiles for each major OS 9 if you are using an subsystem are located in the subsystem s highest level OS 9 based host system or directory and are usually named makefile the make 1 documentation if you are using a UNIX Knowing how the makefiles work is a key to understanding a Peis SL RIEN port In order for
202. u should see the following display Shell Insert a diskette correctly formatted for OS 9 in the drive and try to run the dir utility If this fails begin debugging by repeating this procedure with breakpoints inserted in the driver s INIT GETSTAT SETSTAT and READ routines during step OS 9 OEM Installation Manual 5 17 Step Three Creating Customized I O Drivers and Finishing the Boot Code Creating and Testing the Disk Boot Routines The os9gen utility builds and links the OS9Bootfile Refer to the Utilities Reference manual for more information about how os9gen creates the OS9Boot file If using CBoot these four oper ations are performed automati cally by the diskboot c routine See chapter 7 The C Boot Technology After creating and debugging the basic disk driver you must create a simple disk boot routine You may use the sample assembler bootxxx a files as prototypes or writea CBoot driver To usea C Boot driver refer to Appendix A The C Boot Technology However finish reading this section for needed instructions The basic function of the disk boot routine is to load from a system disk a file called OS9Boot which contains the OS 9 component modules OS9Boot is created and specially linked on the system disk by the os9gen utility The system disk almost always has a CM DS directory that contains the OS 9 standard command set The main operations of the disk boot subroutine in order are
203. y 03c8 41e8 lea P_SPUImg a0 a0 ptr to SPU image 03cc 3601 ChkMem40 move w dl d3 copy block number 03ce e44b lsr w 2 d3 convert block number to byte offset OS 9 OEM Installation Manual Using the OS 9 System Security Module 03d0 03d4 03d6 03d8 03da 03dc 03e0 03e2 4cdf 03e6 4e75 03e8 3f7c 03ee 003c 03 2 60ee 1630 c602 6610 e5la 5241 51c8 7000 ChkMem90 ChkMem95 ChkMemEr move b and b bne s rol b addq w dbra moveq movem 1 rts move w ori bra s a0 d3 w d3 get SPU image byte d2 d3 match request with SPU image ChkMemEr abort if illegal request 2 d2 shift mask for next block 1 d1 move to next block d0 ChkMem40 repeat until end of area requested 0 d0 return carry clear a7 da0 d3 a0 restore regs ESBPAddr 6 a7 return Illegal block addr error Carry ccr return carry set ChkMem95 exit kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk Subroutine GSPUMp Return data about specified process memory map Returns 03 4 48e7 03 8 2002 03fa 2448 03fc 7203 03fe 6100 0402 6554 0404 2017 0406 4e40 040a 654c 040c 42ad 0410 2269 0414 2009 0416 673a 0418 45e9 041c 2269 0420 7000 0422 302b 0426 e28a 0428 b480 042a 6302 042c 2400 042e 2002 0430 d080 0432 2b40 0436 671a 0438 5342 043a 121a 043c 7604 043e 7003 Returns Passed d0 w process id whose information is returned d2 1 size of information buffer a0 information buffer ptr a3 S
204. y link counts using the mdir command Step Four Testing and Validation Serial I O SCF These tests exercise and verify the correct operating of the Tests serial I O Exerciseand verify correct basic operation of each serial and or parallel 1 O port Run xmodeon each port to verify that each device descriptor has the desired default initialization values Manually test the following operations for each SCF type driver e Screen Pause Mode e Halt output character lt control gt W e Keyboard abort and keyboard interrupt lt lt ontrol gt E and lt control gt C e X OFF X ON flow control lt control gt Q and control gt S e Proper baud rate configuration at all rates if software controllable amp Check for correct operation of a maximum number of I O ports running simultaneously 6 4 OS 9 OEM Installation Manual Step Four Testing and Validation Disk VO RBF These tests exercise and verify correct operation of the disk Test system s The OS 9 dcheck utility is the basic tool used to test esis the integrity of the disk file structure O Test the reading and writing of test patterns using a Q OS 9 OEM Installation Manual simple C or Basic program Create and delete files Verify with dir and dcheck Create and delete directories Verify with dir and dcheck Ensure that all sectors on a disk are accessible using a complete physical disk copy such as copy d 0 dl Only the supe
205. ysDev field of the Init module The reasons for this error aresimilar to those for the console device given above with the exception that the file manager used is RBF OS 9 OEM Installation Manual Trouble Shooting Coldstart Errors for the Atomic Versions of the Kernel and IOMan When running in an Atomic environment if the Kernel or IOM an cannot complete their startup procedures correctly then an error code will be printed to the system console These error codes are currently defined as Module Error kernel K 001 K 002 K 003 K 004 K 005 K 006 K 007 K 008 K 009 ioman 1 001 002 1 003 Meaning the processor type and kernel are not compatible the kernel can t find the init module the kernel can t allocate the process block table the kernel can t allocate its irq stack the kernel can t fork the initial process an error was returned from an Extension module the kernel can t allocate its irq polling table the kernel can t allocate the event table the total size of a process descriptor is greater than 32K ioman can t install its service requests ioman can t locate the init module ioman can t allocate memory for the system path and device tables If a problem occurs with startup using the Development kernel or I OMan a full text message will be printed on the system console instead of an error code Generally errors during system startup are caused by inappropriate values in the system s Init module
206. ystem you should Add the SysCache module s name to the I nit module s extension module list For example Extens dc b OS9P2 SysCache 0 Remakethelnit module Generate a new bootstrap file for the system which includes the SysCache module and the new nit module Boot the system The system cache function is now enabled If cachingis not required for the system you can disable cache operations by excluding the SysCachemodule from the bootfile or not having the SysCache module name specified in the I nit module s E xtens list OS 9 Cache Control Default Microware provides default SysCache modules to simplify your task of implementing cache control Each version applies og to a specific sub family of the 68000 series CPUs odules The following modules are supplied CPU Module i Operations Type Name FILE Nome Performed 68000 SysCache Cache none no on chip cache hardware 68008 SysCache Cache none no on chip cache hardware 68010 SysCache Cache none no on chip cache hardware 68070 SysCache Cache none no on chip cache hardware 68020 SysCache Cache020 on chip instruction cache 68030 SysCache Cache030 on chip instruction and data cache 68040 SysCache Cache040 on chip instruction and data cache 68349 SysCache Cache349 on chip instruction cache banks The 68000 SysCache module is essentially a no operation cache control module as these CPUs do not have any o

OS-9 OEM Installation Manual

Contents

Download Pdf Manuals

Related Search

Related Contents