Firmware Fn registerBlocking

registerBlocking — CArr_DYNA_Main::registerBlocking

Part of Firmware Reversing.

• Naive symbol-table address: 0x639898 (VA 0xf6ec758c) — lands 304 bytes into the function's real body (mid a floating-point distance computation)
• True prologue start: 0x639768 (VA 0xf6ec745c)
• Status: 🟡* Partially traced — fully bounded (clean blr at 0x639f88, matching its own 0x460-byte frame exactly; size 0x820 / 2,080 bytes — a genuinely large function), real call targets resolved throughout, but not transcribed line-by-line given the size. Contains one more confirmed instance of the central "undecodable data" anomaly (0x639908-0x63990c) mid-body.
• Full mangled name: registerBlocking__14CArr_DYNA_MainUi (confirmed by argument shape: r3=this, r4=a Ui checked against a global flag early on)

Found via a real, confirmed call site on a function named mr_veh_pos in the symbol catalog — itself not yet separately traced (its own boundary search found a real prologue only 1,812 bytes before its naive address, too large a gap to chase down this session).

Real, confirmed structure

A huge 0x460 (1,120)-byte stack frame, saving 3 floating-point registers (f29-f31) alongside the usual GPRs — real, explicit double-precision floating-point math throughout (lfd/stfd/fsub/ fmadd/fctiwz), including the classic PowerPC "magic constant" int-to-double conversion trick (lis r26, 0x4330) — consistent with real geographic distance/coordinate calculations. This is the first function on this wiki with explicit FPU instructions, confirming the real MPC5200/e300 core here has working hardware floating point.

Real, confirmed call targets — and a correction

The call ADDRESSES below are 100% reliable (real relocations, directly encoded in this already-verified function's own bytes — not in question). The NAMES attached to them come from the broader, independently-known-unreliable symbol catalog (see Firmware Reversing) — 3 of the 6 checked turned out wrong, caught by cross-referencing their addresses against Draw's own now-confirmed byte range (0x81e070-0x81e384) once that page existed: 2 land squarely inside it (mid-body of Draw's own tag-scanning logic, not a separate function at all), and a 3rd (createLocation) was already found to land on pure string data. Corrected here rather than left standing:

Target address	Claimed name	Verdict
0x81e070	Draw__17ElectronicHorizonRC8MapPoint	Real — anchors Draw's own page. A real, previously-uncatalogued class: ElectronicHorizon — a genuine real-world ADAS term (predictive road-ahead data)
0x81f624	__34CfcMdlAspModelObjectChangedMessage (constructor)	Real — same message-construction call seen on mr_veh_pos
0x81e314	cleanupMemory__9MapLoader	Wrong name — this address is mid-body of Draw's own tag-scanning loop (confirmed: falls inside its 0x81e070-0x81e384 range), not a separate MapLoader method. The real call here is just registerBlocking jumping into Draw's shared logic a 2nd time, not a 2nd class
0x831ef4	sqlite3_version	Real (high confidence — a well-known, standard, exported SQLite symbol name, unlikely to collide by chance) — direct confirmation this codebase links actual SQLite, not just a SQL-like custom layer
0x8fe098	createLocation__19LocationManagerImplP17CfcTypeCoordinate	Wrong name — lands on pure readable string/debug data, not code at all
0x81e234	__vn__11MapJobQueueUi	Wrong name — also mid-body of Draw's own range, same issue as cleanupMemory above

Net read

CArr_DYNA_Main::registerBlocking is a real, substantial function that computes a real geographic distance (floating point), calls into ElectronicHorizon::Draw's shared tag-parsing logic (twice, at 2 different internal points — not 2 different subsystems as first thought), queries real, genuine SQLite, and notifies via the generic CfcMdlAsp* messaging layer already seen elsewhere. The MapLoader/MapJobQueue/LocationManagerImpl names originally attributed here were artifacts of the same unreliable broader-catalog resolution already documented failing elsewhere this session — removed rather than left standing. The ElectronicHorizon class name remains the one genuinely new, solid lead from this function: a real, named, well-understood real-world ADAS concept this project hadn't found any trace of before this session.