i just found by a google search some old internal apple documentation about the OF ROM of the blue&white powermac G3
...it defines "MacOS-X" as: UNIX-based MacOS; think of it as "Mac OS NT".
it also mentions putting the macio MMIO physical address at 0x80800000 "to boot NT just in case" haha
it also mentions that OF's little endian mode "actually works in OF"
looking at the disassembly of the B&W's init code i have, it actually should work!
basically, when little-endian is set, after setting MSR[LE] it will set bit 5 (LE_MODE bit, turns on little endian) to PICR1, by using CONFIG_ADDR/CONFIG_DATA writes, and only uses every second instruction to do that (with each other instruction being a nop mainly) because of how MSR_LE works
in fact it seems the bootrom of every ppc mac after this has the exact same code, even those that use a different memory controller, no WONDER little-endian? is notorious for bricking lol
and any HP system where its custom protection against performing db/dbx updates is enabled
also:
the file doesn't exist right now, but there's code (behind a registry(?) flag) to apply "dbxupdate2024.bin", and debug strings imply that would revoke the PCA 2011 cert entirely!(GetSecureBootUpdateFilePathPCA2011RevokeDBX)
i expected that to be done, but only on new systems, fun (given that it's behind a flag it may well happen only on new systems)
@wolf480pl IF older systems get the cert revoked it should be able to be reverted in the uefi firmware setup, which has an option to revert db/dbx back to the default (in the uefi firmware)
unmapping 0x80000000 to 0x80010000 works, but obviously breaks any accesses to hardware that happens to be there
which includes the IDE controller
BUT, for booting NT I only really care about 0x80004000 - and binaries load far above there anyway (so I can map physmem starting at 0x80082000 and mark physmem before that as firmware temporary etc and use the other mapping for needing to touch low memory before NT kernel init)
unmapping 0x80004000 to 0x80010000 works, that should be more than enough space for the ARC system table etc
and everything i care about still works, i don't know what MMIO is there but i wouldn't be surprised if it's just address mirrors there
current status: used all my remaining blank CDs on powerpc mac related things, everything classic mac or osx i've burned so far (and that includes the one already installed on the 20GB hd, which is ja-jp 9.2.2) reconfigures the framebuffer to 640x480
...i know the radeon 7500s in these ibook G3s are notorious for dying, but OF's setting up the initial 1024x768 framebuffer fine...
i would burn disc 1 of 10.2.4 for ibook g3, but as just said i'm out of blank CDs
oh well, if I port NT to this thing I'll only care about the OF framebuffer anyway
@Rairii as in, reconfigures and there's no way to change it back? that sounds like very normal Mac OS behaviour if the OS was set to 640x480 in software
so i messed around with the uninorth registers a bit, the ones at 0xF8000000 and noticed some things, but those things are mainly about how the address space mirroring works there
bootmgr in 26052 updated the revocation version to 2.0 (from 1.0) and also changed the checks for said revocation version (early in main() and when boot application loads bootmgr) to parse dbx (using a new GUID for that) instead of just checking a NV|BS variable
the way the new dbx parameter was implemented is "interesting" (blame OEM's implementations for this i guess):
dbx is walked through looking for EFI_CERT_SHA256_GUID entries with signature owner EFI_IMAGE_DBX_SVN_GUID (9D132B6C-59D5-4388-AB1C-185CFCB2EB92)
when such an entry is found, the 0x20 bytes of "revoked hash" is instead the following structure:
BYTE Unused; // (version? accidentially using the wrong offset? whatever)
GUID BinaryIdentifier; // Identifies the binary being revoked by GUID. bootmgr's is 9D132B61-59D5-4388-AB1C-185CFCB2EB92
DWORD VersionNumber; // Identifies the minimum version of this binary that is allowed to run.
BYTE Padding[11];
where multiple entries exist for the same BinaryIdentifier, the largest VersionNumber is used.
this is basically the same as a proposal I gave MS some time ago (use an authenticated variable with updates, use the largest version for multiple entries), but using dbx for it and extended to support an arbitrary number of binaries.