Reference Veneer patch catalogue

Reference: veneer patch catalogue

Updated 15 September 2026. Three sites were missing from this page and are now in tools/mkveneer.py, which applies every patch below to the file rather than to memory:

VA	shipped	patched	why
0x514E0	0x48000605	0x60000000	claim SYSTEM PARAMETER BLOCK — skip the failure path (ledger row 1)
0x51E3C	0x4BFFFCA9	0x60000000	claim RESTART BLOCK — likewise
0x53DB0	0x554AA016	0x39400000	li r10,0 in the boot-path derivation; CD-only, paired with the \PPC\SETUPLDR string at 0x5CD30

mkveneer.py verifies each site's shipped word before writing and refuses an image these addresses were not derived from — the check a distributable patcher needs.

This page owns: every firmware patch this project applies, what it fixes, and — critically — which media it is correct for.

All of these are applied to VENEER.EXE. They used to be poked into memory at load time; since 15 September mkveneer.py writes them into a copy of the file instead, which is what lets a cold boot need no pokes at all. Either way the patches are ours and the veneer is the user's: nothing here is redistributed.

⚠ Addresses are specific to one binary. They are image virtual addresses in the VENEER.EXE from the OEM 000-48303 CD, loaded at base 0x50000. A different veneer build would differ, and nothing checks.

---

Reading the addresses

Two address spaces appear below, and confusing them is a known time sink:

Image address	what the disassembler shows, what documentation cites
Poke address	image address ^ 4 for a word, ^ 7 for a byte — the little-endian munge

So the patch at image 0x54748 is written machine.memory.poke.l 0x5474c. Both are correct. → Little-endian PowerPC

---

The catalogue

#	Image address	What	Applies to
1	(inherited)	Two nops over the claim failure paths	always
2	0x52254, 0x52258	OFClose return-value slot	always
3	0x5D0C0, 0x5E168	the partition(1) and :0 strings	CD-era; restored for disk
4	0x54748	VrOpen's partition branch → nop	CD only
5	0x5F420 (11 bytes)	the SCSI model string → NCR,825A	always
—	0x5CD30–0x5CD4F	the boot-file path buffer	disk boots; see the warning
—	0x60C0C	VrDebug tracing mask	optional
—	0x5C228+	the injected ARC environment	disk boots

---

What each one is

1 — the claim nops

Inherited from the community thread that first got this far. The veneer's memory-claim failure paths abort where they need not. Needs a story for real hardware, since nobody here derived them.

2 — OFClose return-value slot (image 0x52254, 0x52258)

li   r9, 0
stw  r9, 8(r3)

OFClose does not give Open Firmware's client interface an nret slot, so every close fails. Twelve instances leak and the CD stops opening — with no message, looking exactly like a media fault. A genuine bug fix, applied by patching.

3 — the partition(1) and :0 strings

Blanked during CD-era work; restored for a disk boot. They are string constants the veneer appends when building Open Firmware paths.

4 — VrOpen's partition branch (image 0x54748) ⚠ CD ONLY

nop over the branch that takes the "a partition was named" path, forcing raw opens down the whole-device route.

Correct for the CD, where Apple's disk-label answers :N on an ISO with the root directory as a file — so NT's checksum of "sector 0" reads a directory record and the boot device is declared inaccessible.

Catastrophic for a hard disk, where :N is the only thing that gives partition-relative sectors. With this applied, every filesystem recogniser fails, and the loader reports an error about disk partition tables that has nothing to do with partition tables.

This single row is the best argument for keeping a ledger at all. → ledger row 4

5 — the SCSI model string (image 0x5F420, 11 bytes)

NCR,53C810 → NCR,825A, so Setup's mass-storage detection selects symc810.sys for the 53C825As. Without it the controllers are reported as UNKNOWN SCSI, nothing binds, and the machine has no disk.

A TXTSETUP [Map.SCSI] addition on an OEM disk would be cleaner.

The boot-file path buffer (image 0x5CD30) ⚠ do not write in place

The shipped buffer holds \os\winnt\osloader.exe — 22 characters — and the argv table's slot-0 name string 'OsLoader' begins immediately after it at 0x5CD48.

A 24-character path written in place erases that name. The veneer then emits the loader's path as a bare argv entry, the loader's lookup is by name, and it dies with "The 'osloader' parameter does not point to a valid file" — with the value present and correct the whole time.

mkbootscript.py relocates the path into .text tail padding and repoints the table instead.

---

How they are applied

Never by hand. tools/mkbootscript.py generates them, and reads the two restored ranges out of your VENEER.EXE — which is how the tool is publishable without carrying Microsoft code.

A checkpoint freezes whatever patches were applied when it was taken, so a rebuilt checkpoint silently loses any patch not in the script. That has cost a day once already. → Checkpoints and deltas §4

---

What would retire all of them

A replacement for the veneer — an ARC implementation of our own, or fixes accepted upstream. Until then, "type these into Open Firmware" is not an answer a published project can stand on.

→ The ledger of workarounds group 1