__start.c File Reference

Functions
void	InitMetroTRK ()
void	exit (int)
int	main (int argc, char *argv[])
void	__init_user (void)
void	InitMetroTRK_BBA (void)
void	DBInit ()
	__declspec (section ".init")
static void	__copy_rom_section (void *dst, const void *src, size_t size)
static void	__init_bss_section (void *dst, size_t size)

Function Documentation

__copy_rom_section()

static void __copy_rom_section ( void * dst, const void * src, size_t size )

inlinestatic

__declspec()

__declspec

(

section ".init"

)

Check the BI2 debug flag to determine how to call InitMetroTRK.

This can be done by either checking the value from the DVD (OSBI2.debugFlag), or by checking the global OS_BI2_DEBUG_FLAG.

If the DVD BI2 is available, it is prioritized over the global value.

At this point, we do one last check to decide whether we want to setup the TRK debugger.

If the OS boot info specifies an arena hi, we grab the BI2 debug flag using the global OS_BI2_DEBUG_FLAG.

(This must be some heuristic, but I don't understand it)

The BI2 debug flag/level decides how to set up TRK.

Most importantly, it decides how InitMetroTRKCommTable is called, by specifying a type of hardware.

ID 1: NDEV hardware ID 2: BBA hardware Anything else: "Unknown" to TRK, defaults to GDEV hardware

BI2 debug level maps to TRK comm hardware ID as follows:

• BI2 Level 2 -> ID 0 (GDEV)
• BI2 Level 3 -> ID 1 (NDEV)
• BI2 Level 4 -> ID 2 (BBA)

I think at one point this used to call InitMetroTRK as they set r5 here; however, in this version it goes unused.

What currently happens is __set_debug_bba sets Debug_BBA, which will result in a call to InitMetroTRK_BBA after the OS is initialized.

Maybe this is a leftover from how things worked before InitMetroTRK_BBA was written?

Call InitMetroTRK The MetroTRK hardware ID is specified in r5

After setting up the hardware and the debugger, we next setup the program arguments. This label checks whether any arguments exist.

BI2 contains an offset from itself to the argument data, which is formatted as follows:

typedef struct BI2Args { int argc; union { char* argument; u32 offset; } argv[]; } BI2Args;

This loop unpacks the arguments by converting them from offsets to pointers, in-place.

The offsets are relative to the start of the BI2, so we just add the offset to the BI2 pointer and write it back.

Both the MEM1 arena hi and the MEM1 limit are adjusted to preserve the BI2 args.

They are set to eight bytes into the BI2 arguments, rounded down to the nearest 32 bytes.

Either there was no BI2 available, or it did not contain any arguments

Here, the OS and its debug monitor are initialized, and then we check if we should call __check_pad3.

__check_pad3 is called before future initialization if the disk drive device code is 0x0001, or if the OS' inquiry fails (emulation or some debug hardware?)

The apploader reads the button state of the fourth GCN controller and writes it to GC_PAD_3_BTN (zero-indexed), which is used in __check_pad3. WiiBrew states that this is for GameCube NR disc support, so that could explain the unusual DVD device code address.

If the BI2 debug level from earlier was set to four, we need to initialize the debugger for BBA hardware.

1. Initialize C++ runtime
2. Call main(argc, argv)
3. Teardown C++ runtime

__init_bss_section()

static void __init_bss_section ( void * dst, size_t size )

inlinestatic

__init_user()

void __init_user ( void )

extern

DBInit()

void DBInit ( )

extern

exit()

void exit ( int status )

extern

InitMetroTRK()

void InitMetroTRK ( )

extern

InitMetroTRK_BBA()

void InitMetroTRK_BBA ( void )

extern

main()

int main ( int argc, char * argv[] )

extern