Restrictions on DOL Files and Boot-Related Terminology

Introduction

This document briefly describes boot-related terminology for Wii disc applications and facts that developers should know.

Refer to NADK descriptions for terminology related to NAND applications.

Apploader

The apploader module is stored on a disc to assist in booting disc applications. In the development environment, development machines use RVL/boot/apploader.img under the directory where Revolution SDK is installed.

DOL Files

The DOL file format is similar to the ELF file format used for the Wii. Use the makedol command to convert an application's ELF file into this format. This file is stored on a disc for disc applications. This file is given a .dsf extension, along with other system information, on the NDEV.

Address Restrictions on DOL Files (9 MB)

On a Wii console, sections cannot be placed at memory addresses above 0x8090_0000 (9 MB). In DEVELOPMENT mode on development hardware, sections cannot be placed at memory addresses above 0x8120_0000 (18 MB).

If violated, apploader will generate an assertion error. To solve this problem if you violate this restriction, consult the .map file for the application to see which section is big.

1. If the DATA or SDATA section is large:

Try placing data on a DVD and reading it at run time.

2. If the TEXT section is large:

Try using the relocatable module system or split it into DOL files. (See the OSExec function.)

3. If the BSS or SBSS section is large:

Instead of statically allocating memory using uninitialized variables, try allocating memory dynamically.

Comments: In Revolution SDK 3.3 patch 1 and later, the LCF file is changed so that the BSS section is located directly before the stack and the 9 MB restriction no longer applies to the BSS section.

FST (File Symbol Table)

The FST contains information for all of the files under DVDRoot. See the disc drive programming manual for more detail. The FST is included in a DSF file on the NDEV.

The FST is placed at the highest address (24 MB, the maximum FST length) in MEM1. For "FST max length," see the next section.

FST Max Length

The maximum FST length is the buffer size in MEM1 that must be prepared for the FST. For a game that consists of only one disc, the maximum FST length can be the same as that disc's FST length. For a game that consists of multiple discs, the FST for the second disc may be longer than the FST for the first disc. If this is the case, you need to prepare a big enough area for FST so that both the first and second discs' FST can fit. This area is usually MAX(FST size for the first disc, FST size for the second disc), which is the source of the term "FST max length."

The NDEV software supports creating multiple discs. Using this feature, the maximum FST length for multi-disc games will be calculated and set. For single-disc games, the disc's FST size will be the same as the maximum FST size.

Bootinfo2 (BI2)

The 8-KB Bootinfo2 region contains the following settings.

• MEM2 size to simulate (see setsmem2size)

On the NDEV, bootinfo2 is saved to a DSF file after running ndrun.

To modify settings in bootinfo2, use the corresponding settings script. For details on how to use these scripts, refer to each script's page in the Revolution Function Reference Manual.

Note that you must execute ndrun at least once to propagate changes before creating master data.

Bootinfo3 (BI3)

The 8-KB Bootinfo3 region contains the following settings.

• Country code for disc (see setcountrycode)
  
• Parental Controls settings

Bootinfo3 is included in the rvl.bin file. On the NDEV, this information is saved in an RCF file after running ndrun.

To modify settings in bootinfo3, use the corresponding settings script. For details on how to use these scripts, refer to each script's page in the Revolution Function Reference Manual.

Note that you must execute ndrun at least once to propagate changes before creating master data.

Revolution System File (rvl.bin)

The Revolution System File (rvl.bin) contains the following settings.

• Firmware version to use when the application is started
• Application game code
• Application company code

On the NDEV, this information is saved to an RCF file after running ndrun.

To modify these settings, use the corresponding settings script. For details on how to use these scripts, refer to each script's page in the Revolution Function Reference Manual.

Note that you must execute ndrun at least once to propagate changes before creating master data.

DSF Files

A DSF file is an NDEV-specific file that contains Bootinfo2, DOL files, and an FST.

RCF Files

An RCF file is an NDEV-specific file that contains Bootinfo3 and rvl.bin.

Linker Command Files (LCF Files)

Linker command files list settings for things like memory allocation for each section.
For details, see Chapters 14 and 15 in Build_Tools_Reference_NINTENDO_Wii.pdf, included in the CodeWarrior package.

Note:Starting with SDK 3.3, the old Dolphin SDK arena location settings (__ArenaLo，__ArenaHi) that were left in the linker command file have been deleted.

The location of the arena is set by the library at boot time. The lower boundary of the MEM1 arena is set to _dB_stack_addr when using a debugger, and to _stack_addr otherwise. The upper boundary of the MEM1 arena is set to 0x81700000.

To change the arena location, make settings inside your application using functions such as OSSetMEM1ArenaLo and OSSetMEM1ArenaHi.