0x5ba5d0 — unnamed

Part of Firmware Reversing.

• File offset: 0x5ba5d0 (VA 0xf6e482c4) — starts immediately after 0x5ba570's own clean blr, no gap.
• Status: 🟡* Partially traced — real prologue confirmed (stwu r1,-0xf0(r1)), but its own real end was NOT found: scanned nearly 2,700 bytes forward without ever finding a matching addi r1,r1,0xf0 epilogue OR a bare blr of any kind (only blrl calls) — this is a genuinely large function, larger than this pass could responsibly bound. A different, smaller function (0x90-byte frame) starts at 0x5ba9c8, textually inside the scanned range — only the call targets found BEFORE that embedded boundary are reported below, applying the lesson from Firmware Reversing's "long scan can overshoot" note; everything past it was discarded as unattributable.
• Real name source: not found in the symbol table under any name searched so far.

Real, confirmed call targets (verified safe — found before the first embedded boundary at 0x5ba9c8)

Target	What it suggests
ReceiveNavGraphSync__15DummyMOSTDevicePUc	A real MOST-bus "receive NavGraph sync" handler on a DummyMOSTDevice — directly ties this function to the ADAS NAV_GRAPH* datagram family documented in Firmware Reversing's ADAS section (AdasTools::UnPackNavGraphDatagram etc.)
__nw__Q215MapLoaderJobEDB25ShapesInRectangleReceiverUi	Operator new for a real MapLoaderJobEDB::ShapesInRectangleReceiver — ties this function to the EDB (Extensions Database) map-loading layer
addKey__15MapLoaderJobEDBRC12MapParcelKey	Adds a real MapParcelKey to a MapLoaderJobEDB — map-tile/parcel loading, the same MapParcelKey/parcel-loading family as MDCacheParcelSpanContainer (mv_lefthand_traffic)

Net read

A real, substantial function that receives a NavGraph sync message from the (dummy/stub) MOST device abstraction and, in response, kicks off map-tile/parcel loading via the EDB map-loader-job machinery — consistent with "when the ADAS module's navigation graph resyncs, make sure the relevant map tiles/parcels are loaded." Its true full extent and remaining behavior are not determined — a genuinely large function whose real size exceeds what this pass could safely bound without risking the same misattribution already caught and fixed on calculateManeuvers and getSegProperty.