New Feature
Opening this as a discussion, not a pull request. I have working code but I do
not think it is ready to propose as a patch, and I would rather get the design
direction wrong on paper than in your tree.
Problem
On an exFAT-formatted memory stick, ARK-DC cannot be booted. The raw IPL stage
is filesystem-agnostic — it is read by LBA from sectors before the first
partition — but everything after it loads files by path (/TM/DCARK/msipl.raw,
then the model-specific payload), and that reader is FAT-only.
This matters more on later models than it first appears. On PSP-3000 the pre-IPL
is patched, so Pandora and Baryon Sweeper are not available, and cIPL lives in
the same NAND region a bad flash destroys — so it is not insurance against
IPL-level damage. cIPL plus a memory stick is effectively the only software
recovery path on those units. If DC cannot boot from the card the owner is
using, there is no software recovery at all.
Large cards make this concrete: 512GB adapters now exist, the PSP cannot format
them natively, and exFAT is the natural filesystem at that size.
Proposed direction
Put a minimal read-only exFAT parser behind the existing MsFat* API rather
than adding a parallel code path.
The reason I am raising this here rather than only in ARK-4: psp-cfw-sdk's
libiplsdk.a exports MsFatMount, MsFatOpen, MsFatRead, MsFatClose,
MsFatSeek, MsFatFindFile, MsFatGetNextCluster, MsFatIsValidCluster and
MsFatReadLogicalSector. ARK-5's CustomIPL has no fat.c of its own and links
that library; ARK-4 carries a private copy at libs/iplsdk/fat.c. So the same
work done in libiplsdk would serve both, whereas doing it only in ARK-4's copy
creates a fork.
I would like your view on whether that split is the right one, and whether
ARK-4's copy should converge on upstream libiplsdk or stay independent.
One concrete defect, independent of the above
In the existing exFAT-capable directory scan, a checksum or name-length mismatch
does return -1, which aborts the entire directory scan rather than skipping the
offending entry. A single oddly-formatted file on the card means msipl.raw is
never found — black screen, no diagnostic.
continue is the correct behaviour, but changing it makes an entry-count cap
mandatory rather than optional: a corrupted circular directory would otherwise
spin forever in IPL with no way out.
Current status, stated plainly
- Not hardware-verified. The most recent attempt installed DC from exFAT and
then black-screened on the next cold boot. Cause not yet identified.
- I cannot currently reproduce the shipped
ARK_DC/ARK_cIPL EBOOTs. Legacy
psp-gcc 4.3.5 fails on kubridge header conflicts; current psp-gcc 15.2 fails on
-Wint-conversion and implicit-function-declaration, which GCC 14 promoted
from warnings to errors. If there is a known-good toolchain vintage for this
tree, that alone would help me a lot.
- An external review of my parser flagged real problems: its entry-set recovery
can swallow a new primary entry, it is over-restrictive toward benign vendor
extension entries, its partial-read contract is ambiguous, and its scan cap is
not derived from the mounted filesystem. I agree with all four.
- I have not established whether the ~128 GiB addressing wall lives in the MS
protocol/hardware layer or in software. Until that is settled I do not think a
hard-coded 28-bit limit belongs in the code.
What I am asking for
Direction on the libiplsdk question above, and on whether you would want this
as a series of small separate PRs (the continue fix and the entry cap are
independently reviewable) or as one feature branch.
I am publishing everything openly rather than keeping it private. Happy to be
told the whole approach is wrong.
ARK_exFAT_GitHub_Discussion_v2_20260802.zip
ARK_exFAT_GitHub_Discussion_v2_20260802.zip
New Feature
Opening this as a discussion, not a pull request. I have working code but I do
not think it is ready to propose as a patch, and I would rather get the design
direction wrong on paper than in your tree.
Problem
On an exFAT-formatted memory stick, ARK-DC cannot be booted. The raw IPL stage
is filesystem-agnostic — it is read by LBA from sectors before the first
partition — but everything after it loads files by path (
/TM/DCARK/msipl.raw,then the model-specific payload), and that reader is FAT-only.
This matters more on later models than it first appears. On PSP-3000 the pre-IPL
is patched, so Pandora and Baryon Sweeper are not available, and cIPL lives in
the same NAND region a bad flash destroys — so it is not insurance against
IPL-level damage. cIPL plus a memory stick is effectively the only software
recovery path on those units. If DC cannot boot from the card the owner is
using, there is no software recovery at all.
Large cards make this concrete: 512GB adapters now exist, the PSP cannot format
them natively, and exFAT is the natural filesystem at that size.
Proposed direction
Put a minimal read-only exFAT parser behind the existing
MsFat*API ratherthan adding a parallel code path.
The reason I am raising this here rather than only in ARK-4:
psp-cfw-sdk'slibiplsdk.aexportsMsFatMount,MsFatOpen,MsFatRead,MsFatClose,MsFatSeek,MsFatFindFile,MsFatGetNextCluster,MsFatIsValidClusterandMsFatReadLogicalSector. ARK-5's CustomIPL has nofat.cof its own and linksthat library; ARK-4 carries a private copy at
libs/iplsdk/fat.c. So the samework done in
libiplsdkwould serve both, whereas doing it only in ARK-4's copycreates a fork.
I would like your view on whether that split is the right one, and whether
ARK-4's copy should converge on upstream
libiplsdkor stay independent.One concrete defect, independent of the above
In the existing exFAT-capable directory scan, a checksum or name-length mismatch
does
return -1, which aborts the entire directory scan rather than skipping theoffending entry. A single oddly-formatted file on the card means
msipl.rawisnever found — black screen, no diagnostic.
continueis the correct behaviour, but changing it makes an entry-count capmandatory rather than optional: a corrupted circular directory would otherwise
spin forever in IPL with no way out.
Current status, stated plainly
then black-screened on the next cold boot. Cause not yet identified.
ARK_DC/ARK_cIPLEBOOTs. Legacypsp-gcc 4.3.5 fails on kubridge header conflicts; current psp-gcc 15.2 fails on
-Wint-conversionand implicit-function-declaration, which GCC 14 promotedfrom warnings to errors. If there is a known-good toolchain vintage for this
tree, that alone would help me a lot.
can swallow a new primary entry, it is over-restrictive toward benign vendor
extension entries, its partial-read contract is ambiguous, and its scan cap is
not derived from the mounted filesystem. I agree with all four.
protocol/hardware layer or in software. Until that is settled I do not think a
hard-coded 28-bit limit belongs in the code.
What I am asking for
Direction on the
libiplsdkquestion above, and on whether you would want thisas a series of small separate PRs (the
continuefix and the entry cap areindependently reviewable) or as one feature branch.
I am publishing everything openly rather than keeping it private. Happy to be
told the whole approach is wrong.
ARK_exFAT_GitHub_Discussion_v2_20260802.zip
ARK_exFAT_GitHub_Discussion_v2_20260802.zip