The source scheduler (C_MGR_SRC)¶

C_MGR_SRC decides which audio source plays. Every HMI source sends it a request, it picks a winner per list, and it restores the saved source at boot. This page reads all 71 functions in the C_MGR_SRC family of the stock NAV SMEG5.43.A.R2 image: 60 C_MGR_SRC methods and 11 C_MGR_SRC_msg_private methods, about 7 600 instructions. The AUX-specific consequences are in The AUX chain; the HMI side that sends the requests is in How HMI apps request sources.

How this was read¶

• Decompilation: every function was decompiled by the shared Ghidra server (see Toolchain). The output stays local; it is derived from vendor code.
• Disassembly: where the decompiler was unclear, the code was checked with tools/ppcdis.py:
• the literal 1 in ChangeToNextSchedulerPosition;
• the type→list jump table;
• the no_source tail of ExecuteAllocation;
• the unnamed helpers at 0x0169537c and 0x016953c8.
• Field names: these come from ShowStatus()'s own format strings (m_Mgr_src_…), which name almost every field.
• Where a field name is matched to an offset by print order, not by a traced load, it is marked inferred.
• Evidence tiers:
• read means the decompiled or disassembled code was followed;
• executed means run under ppcemu or observed on the car. AddRequest, ChangeToNextSchedulerPosition and the boot restore reach that tier.

The less obvious behaviour (what +0x7c is, why "next position" is always 1, when the source is saved, a missing NULL check) is collected under Notable behaviour.

The object (0x3f4 bytes, one instance)¶

Instance() allocates 0x3f4 bytes. It registers the object in C_OBJ_PTR_Table under 0x62d4 (25300).

• That is the same id the spy uses, which is why the unit's dump lands in RAMDISK_SPY/25300/.
• The active-object base is created with the name "MGR_SOURCE" and version "5.42".

Globals used alongside the object:

• 0x035e4cd4: Mgr_src_CurrentStatus.
• m_Mgr_src_CurrentLockedStatus.
• m_mgr_src_diag_test_status and m_mgr_src_diag_test_source.
• m_is_no_source_active, a byte written in ExecuteAllocation via 0x7a16(r29).
• m_Instance.

The request node (MGR_SRC_ReqData_t + list links)¶

The first 0x2c bytes are the request exactly as sent (GetMsgReqData copies 0x2c). The column names come from the spy's request-list header and WriteMgrSrcSpy(char const*, MGR_SRC_ReqData_t const*)'s format string.

The type→list map is the jump table at 0x02f4b080, read via FUN_0169537c:

Type 4 is handled separately in AddRequest (below).

Modes¶

SetCurrentStatus writes Mgr_src_CurrentStatus. The mode decides which priority field counts and whether position matters.

Temporary lists 1–3 always pick their lowest-priority request, using Norm, Lock or NoSr according to the mode. Position is ignored for them. read

The request lifecycle¶

1. Sending a request. A client calls one of two entry points. Both copy the request into a C_MGR_SRC_msg_private and post it to the object's own message queue (C_BASE_ACTIVE::SendMessage). - AllocateSource(req) posts message kind 0. - ReleaseSource(MsgSrc, SrcId, Type) builds a request and posts kind 1. It sets Sched_Typ from GetLastSourceType(Sched_Pos).

2. Dispatch. HandleMessage (id 0x62d5) → HandlePrivateMessage takes the mutex and switches on the kind:

The watchdog callbacks Mgr_src_SCHED_INIT_TIMEOUT and Mgr_src_SCHED_TYPE_TIMEOUT only post kinds 3 and 4, so every timer effect runs on the manager's own task. read

3. AddRequest. - It rejects: - a duplicate (MsgSrc, SrcId) on the same list, as "already added !"; - an invalid type; - a full pool (RequestNb ≥ 9), which is answered with END. - A valid request is appended to its list's tail. - A type 5 or 6 request whose (pos, prio) matches the Radio or Media slot has its MsgSrc recorded in that slot. - The PrOnly/ScheduledInit logic then runs exactly as The AUX chain documents, and every path ends in ExecuteAllocation.

read; executed under emulation (The AUX chain)

4. ExecuteAllocation. 1. Records the old permanent winner's position. 2. Calls SetCurrentStatus and clears the four winners. 3. Runs ExecuteAllocationFirstRound, which picks per-list winners using the mode rules above. 4. Runs CheckAfterFirstRound. This drops the NotMixable winner if it does not beat the Mixable one, and drops the Mixed/Mixable winners if the NotMixable winner outranks them. 5. Runs SendAllocationMessages, then SetSourceContext. 6. Saves (see below), and flags no_source when the winner is 0xba00.

read

5. SendAllocationMessages turns the winners into verdicts. Each verdict is published as a 16-byte record {code, SrcId, seq, MsgSrc} to context data 0x62d4/0x62db.

• Permanent list, losers: a loser that was active gets SUSPEND; one that was not gets WAIT.
• Permanent list, winner: it gets ACK only if no temporary source outranks it. Otherwise it gets PAUSE: a NotMixable or Mixable winner, or a Mixed winner on a type-6 request.
• Temporary lists: the winner gets ACK. A loser gets SUSPEND or WAIT if its Suspend/PostPone flag allows it; otherwise it gets END and is removed.
• A request that receives ACK becomes m_Mgr_src_SourceActivePtr[list].

read

6. RemoveRequest(req) unlinks the node. - Temporary lists: if the node was active, allocation re-runs. - Permanent list, when the node is the current source (+0xb4/+0xac match): if the release's Sched_Typ is 0, it jumps to the Media slot's position. Otherwise it returns to +0xe4, the previous position, or to the first position if that fails. - Either way: the matching Radio/Media slot is cleared, and the type watchdog is re-armed if no replacement is found.

read

The boot restore and the timers¶

This is the same as The AUX chain, restated for completeness.

1. Construction: the ctor creates both watchdogs. Init then:
2. clears the lists, the pool, ScheduledInit and +0x3c0;
3. sets +0xb4 = +0xac = 1;
4. loads the Radio/Media slot positions and priorities from supervisor.Src_*. Their defaults are position 1 and priority 250 when a key is missing.
5. StartUp:
6. sets +0xb4 = 0, then restores Last_Source → +0xb4 (and +0xe4) and Last_Source_Priority → +0xac;
7. logs the saved Last_Source to the spy (WriteMgrSrcSpy at 0x01699488, from lwz r5,8(r1)) before storing it at 0x0169948c. So the spy's Last_Source line always shows the saved value, not the one aux-boot-default substitutes at 0x0169948c (read);
8. subscribes to diag event 0x3dbb;
9. arms both watchdogs for 7.5 s (0x1d4c).
10. Init timer fires: SchedulerInitTimeout sets +0x3c0 and calls ChangeToNextSchedulerPosition(false, false).
11. On success, that function writes the literal 1 to +0xb4 and allocates.
12. If no permanent request with Sched_Pos ≠ 0xff exists, it fails. The timer is then re-armed for 5 s and +0x3c0 is cleared again.
13. Type timer fires: SchedulerTypeTimeout fills any empty Radio/Media slot from the first permanent request of that Sched_Typ. If none exists, it re-arms for 5 s. Then it runs SetSourceContext.

read

Notable behaviour¶

1. +0x7c is the "no source" status, and nothing in this class sets it.
2. The byte that switches the manager into mode 4 (MGR_SRC_NOSRC, priority field NoSr) is only ever cleared inside C_MGR_SRC. A scan of the family's 71 functions finds five stb …,0x7c, all storing 0.
3. So either another class writes it, or mode 4 is unreachable.
4. Status: read (the scan). Who sets it is not known; this family was the only range scanned.
5. "Next" always means position 1.
6. ChangeToNextSchedulerPosition walks the permanent list and computes the highest Sched_Pos above the current one into r7. It then discards it and stores li r0,1 (0x01697b44).
7. Its only success condition is that some permanent request has Sched_Pos ≠ 0xff (and, with byType, the right Sched_Typ).
8. Status: read (disassembly), then executed under emulation. The full picture, its four callers and why no patch is recommended are in the section below.
9. Patching that literal is the wrong lever for boot-to-AUX; see below.
10. The source is saved only on a change, and never for the first two ACKs after boot.
11. ExecuteAllocation calls ImmediateSourceSave only when the permanent winner's position differs from the previous pass and m_Mgr_src_RequestCounter (+0xe8) is above 2. Init sets +0xe8 to 1, and each ACK increments it.
12. ImmediateSourceSave writes all six supervisor keys at once through UP_MOD::SetCommonKeysImmediate.
13. Status: read. Consequence (inferred): a boot that settles on its first or second ACK does not rewrite Last_Source, so the saved value can survive a boot where another source won. Why the saved value is sometimes 1 after AUX boots is not known.
14. ExecuteAllocation dereferences the NotMixable winner without a NULL check.
15. When a permanent winner exists, 0x016974ec loads +0x3e0 and reads +0x1c from it unconditionally. With no NotMixable winner, that is a read from address 0x1c.
16. Status: read (disassembly). Harmless on VxWorks with page 0 mapped (inferred). It matters only to anyone emulating ExecuteAllocation: map low memory, or the emulator will fault there.
17. Diag test positions.
18. SetCurrentDiagTestSource maps the diag object's byte as follows: 2 → position 2, 3 → 4, 4 → 9, anything else → 1. It then posts kind 2, which forces that position without allocating.
19. Status: read. The position names are not known. The POS_* strings in ShowStatus are not in enum order.
20. GetLastSourceType does not follow the Radio/Media naming. Its result:
21. pos 1 → 1 (Media);
22. pos 2–5, 7–10 → 0 (Radio);
23. anything else → 2.

Yet +0x9c is saved as Src_Radio_SchedPos, and the spy shows the tuner at position 1. In practice the value only steers RemoveRequest's "where to go when the current source leaves" choice. Releasing a source at positions 2–10 (AUX included) jumps to the Media slot's position.

Status: read. Whether the enum is simply misnamed is not known.

AddRequest also materialises the string R_TP_FLAG_CHANGED, which the decompiled body does not show being used. Not known.

ChangeToNextSchedulerPosition, in full¶

Stock NAV SMEG5.43.A.R2. The function was disassembled, every caller found (4 materialised sites, no bl), and the function itself run under tools/ppcemu.py with the lock, unlock and ExecuteAllocation stubbed.

In short

• The computed value is never used (read, then executed). It is not "the next position" either: the loop computes the highest scheduled position above the current one. The stored value is always 1.
• In normal mode, position 1 means "the tuner, or no permanent source" (read). ExecuteAllocationFirstRound picks the permanent winner only among requests whose Sched_Pos equals +0xb4; nothing falls through to the next available position.
• Whether the 1 is deliberate is not known. The dead computation suggests a vestigial or disabled "next" algorithm (inferred). The rest of the class treats position 1 as the canonical fallback: ChangeToFirstSchedulerPosition forces it, and so does the timer.
• Returning to the previous source already exists natively (read). See below.

What it does (0x01697a70, 99 instructions)¶

ChangeToNextSchedulerPosition(bool clear, bool byType):

1. Locks the mutex at +0x80, then walks the permanent list from +0xd4 (following +0x3c), with r5 = r7 = +0xb4 (the current position) and r6 = 0 (read).
2. Per node: Sched_Pos (+0x18) of 0xff is skipped. With byType, the node counts only if Sched_Typ (+0x1c) equals +0xb0. A counting node sets r6 = 1 ("something schedulable exists"), and if its position is above r7, r7 takes it, so r7 ends as the maximum (read; executed).
3. If r6 == 0: unlocks and returns −1, storing nothing (executed).
4. Otherwise: saves the old position to +0xe4 ("previous"); li r0,1 at 0x01697b44 (38000001) then stw r0,0xb4 sets the current position to 1; with clear, stores 0 to the no-source byte +0x7c; calls ExecuteAllocation; unlocks and returns 0 (read; executed). r7 is not read after the loop (read).

Emulation, stock image (executed). The request nodes are scratch memory holding only +0x18, +0x1c and +0x3c.

tests/test_firmware_nav.py carries two of these rows as tests that run against your own image.

Every caller (read)¶

Return to the previous source¶

ChangeToFirstSchedulerPosition has one caller, RemoveRequest (0x016980cc). When the current permanent source is released, it first calls ForceSchedulerPosition(+0xe4, 0, 1), which returns to the previous position. Only if that fails does it call ChangeToFirst…, and then ChangeToNext…, ending at 1 (read, 0x016980a0–0x016980dc).

So returning to the previous source when AUX drops (the request tracked as issue #4) may need no patch at all: if AUX's release reaches RemoveRequest while the previous source's request is still queued, the manager goes back to +0xe4 (read). Whether that request is still queued at that moment is not known. A car test of aux-signal-switch without aux-sticky would settle it.

Why no patch is recommended¶

A. 0x01697b44 38000001 (li r0,1) → 7ce03b78 (mr r0,r7). CANDIDATE, executed under emulation for this function only. It stores the highest scheduled position above the current one (current 7 with requests 8, 9, 10 stores 10), not the next or the previous one. Per caller (inferred): the boot timer would jump to the highest queued source (iPod or USB), not FM or AUX; bcm_ActivateNextSource would always land on the top position and never wrap; ChangeToFirst… would land on the highest position instead of staying at 1. Worse than stock.

B. A true "next-higher, wrap to lowest" would mean rewriting about six words of the loop at 0x01697ad4–0x01697b1c (initialise r7 to a sentinel, take a node when current < pos < r7, wrap to the lowest if none). It is expressible in place, but it changes all four callers at once, and only bcm_ActivateNextSource's callers plausibly want it. Not designed further until what triggers SwitchNextSource is known and "next source" is a real problem on the car.

For boot-to-AUX, patching this literal is the wrong lever. aux-boot-restore (with aux-boot-default) avoids the timer altogether by making AUX match the restore, which cancels it; that pair boots to AUX on the car (executed; Verification).

Every function¶

Every row below is read or better; no function in the family was left unread.

Reached by comes from tools/survey.py (see Firmware map):

• mat×n: n lis/addi sites build the address, i.e. called via bctrl;
• ptr×n: data (vtable) pointers;
• none of these functions has a direct bl caller.

Two helpers without symbols sit just before the class and are used throughout: FUN_0169537c (the type→list map) and FUN_016953c8 (clear a pool node: SrcId -1, Sched_Typ 2, the rest 0). Both were read from disassembly.

The vxWorks calls reached through 0x0058xxxx stubs are named here from their error strings: semTake/semGive/semDelete/semMCreate and wdCreate/wdStart/wdCancel/wdDelete. That naming is inferred; the stubs themselves were not read.