Friivolution standalone route (FRIIV_CFG argsboot handoff) [DRAFT]

[KakarottoCake]

Draft — Friivolution standalone route for Riivolution-compatible mod loading.

What this does

Lets USB Loader GX launch Wii backups through standalone Friivolution (which owns
mod preparation and game launching), reusing the exact Nintendont handoff GX
already ships: AddBootArgument(loaderPath) + AddBootArgument(&cfg, sizeof cfg)

• BootHomebrewFromMem(). Delivery is the raw FRIIV_CFG (384 bytes, v1) as the
  second boot argument, per Friivolution's launcher/include/FriivConfig.h
  (vendored here with a provenance banner; no XML parsing, patch planning, or
  runtime serving in this adapter).

User flow: per-game Game Load menu → Friivolution: ON → Friivolution Mod: All mods | <name>.xml (cycles /riivolution/*.xml found on SD+USB) → Play.
Global Custom Paths → Friivolution Loader Path (default sd:/apps/friivolution/,
resolved to boot.dol then boot.elf). Normal launches are untouched when the
toggle is off (the default).

Diff (+846/−1, one commit on enhanced)

• source/riivolution/FriivConfig.h — vendored v1 contract (banner-only addition).
• source/riivolution/FriivAdapter.{h,cpp} — pure path/config builder (~3.4 KB
  text, no heap): SD/first-USB translation, first-part split rule, .ciso /
  missing-path / multi-USB refusals with prompt-ready reasons, mod-dir scan.
• source/usbloader/GameBooter.{hpp,cpp} — BootFriivolution (argsboot only;
  Friivolution documents no config-file fallback): loader discovery, meta.xml
  ≥1.01 advisory check, binary-arg chainload.
• Settings: per-game FriivMode (default OFF) + FriivModXml, global
  FriivLoaderPath, two Wii-only GameLoadSM rows, one CustomPathsSM row,
  GameWindow::BootGame hook with EmuNAND refusal and Ocarina/alt-DOL
  Continue/Cancel guards (neither applies under Friivolution; never dropped
  silently).
• source/riivolution/hosttest/ — contract test feeding real builder bytes
  into Friivolution's real BootCfg_ValidateSized.

Deliberate refusals (prompt, never silent): usb2+ volumes (v1 names no
partition), EmuNAND (save redirection ≠ EmuNAND), .ciso, WBFS partitions,
missing mod file (Friivolution side cancels to picker rather than booting
vanilla — separate Friivolution-side change).

Verification (no console yet)

• Container make zip (devkitppc:20250527): green — full ELF +7,012 bytes
  (text +6532, data +352, bss +128); transient 384 B MEM2 arg freed pre-chainload.
• Host contract test: SD/USB paths, disc, split first-parts, companion-part and
  malformed/short-input refusals — friiv-contract: ok.
• Pending hardware: controlled chainload test (OFF-toggle control first, then
  modded handoff with a pre-chosen changed asset, two-mod isolation, B-cancel,
  missing-mod refusal). This PR stays draft until a console result lands.

Test pair (preserved, not part of this repo)

GX d0efa041 (this branch) + Friivolution 8ff2874
(friivolution/v1-argsboot-hardening): v1 validation hardening, sized entry
point, missing-mod refusal, NO_PATCHES/ModXml v1 semantics kept (ModXml ignored).

Questions for review

1. Is the v1-only scope acceptable (multi-USB-partition, EmuNAND, per-option
   editing explicitly out, with refusals instead of guesses)?
2. Is the usb1-only rule acceptable until a versioned contract names volumes?
3. Should the GameLoadSM rows stay visible when no Friivolution install is
   detected, or gate behind loader detection?

[DraconicNEO]

Do we know if Friivolution can do this yet? I mean I'm sure the guy behind it could add a way to do this since it's clearly still being worked on. It would be great to be able to do this.

[iam4pple]

Do we know if Friivolution can do this yet? I mean I'm sure the guy behind it could add a way to do this since it's clearly still being worked on. It would be great to be able to do this.

yes, https://git.gay/december/friivolution/src/branch/main/launcher/include/FriivConfig.h

[wiidev]

I'd mentioned this to NGT, but if you look at my past commits, you'll see that I only share my changes on the day of release. So there are actually a lot of pending changes, which would likely conflict with this pull request 😅

I assume the code in this pull request was generated by Claude, given its use of comments, test files, and unnecessary path checks. For example, when the loader creates its list of games, it has already filtered everything "bad" out. So it would never pass gameid.wbf1 or gameid.wbf2 to Friivolution.

Since I've drastically changed which file systems and drives the loader will support, I'll need to guard against displaying the Friivolution options to users when they're not applicable, since Friivolution only supports FAT32 partitions for both mod files and game files.

So, if it's okay with you, I'll just use this pull request as a rough reference and give you a mention in my changelog?