Mac OS Rom Hacking

[nanopico]

I knew that some resources had to be referencing the parcels, I just had no idea which ones. Sending me a clean Parcles file would be great. Can you also send me the data fork files? Would I have to modify the cfrg to point to new offsets?

Also, what interesting features would you like to have added to the bootroom? I have already figured something out that lets you load the system folder from somewhere other than where the Mac OS ROM file is (non-interactively. You have to specify the path to the folder in a text file). I haven't posted it here quite yet. Any suggestions? I have no idea how useful my crazy improvements would actually be. 

The two PEF executables discussed are not parcels.  The are seperate for the parcels package.  They are actual code fragments.  If they are moved from their current offset, then yes the cfrg resource have to be updated.

[Daniel]

That makes sense. I am somewhat unfamiliar with the terminology.

Having to statically specify offsets into the Mac OS ROM file would be really inconvenient. Currently, I can just use BBEdit to add stuff to the CHRP script whenever I want to. Any offsets would have to be updated every time I modify the file. I technically can get around that, but it would be really hackish. I would have to use that system folder redirect I mentioned to load the system folder from a partition that has a valid Mac OS ROM file already in it. The chrp file would be run from the first Mac OS ROM file, but the System would load the fragments from another Mac OS ROM file.

[nanopico]

That makes sense. I am somewhat unfamiliar with the terminology.

Having to statically specify offsets into the Mac OS ROM file would be really inconvenient. Currently, I can just use BBEdit to add stuff to the CHRP script whenever I want to. Any offsets would have to be updated every time I modify the file. I technically can get around that, but it would be really hackish. I would have to use that system folder redirect I mentioned to load the system folder from a partition that has a valid Mac OS ROM file already in it. The chrp file would be run from the first Mac OS ROM file, but the System would load the fragments from another Mac OS ROM file.

Yeah it's nice that everything is not static.  Move the parcels package, no problem, move the two code fragments, no problem.  Just references have to be updated. Anything less static would make it way slower, anything more static would make it a pain to maintain.

I still need to check out the scripts and stuff you have. Hopefully I can get that today.  Would have had time yesterday, but wedding anniversary was a bit more fun touring Paisley Park and such.

[ELN]

Our build system does sets all the offsets for you when it rebuilds the parcels, trampoline, PEFs and forks.

Code: [Select]

#
# File: WrapMacOSROM
#
# Contains: This script wraps a Classic-style "MacOSROM" parcels blob
# in a CHRP booter along with a Forth script and a
# "Trampoline" ELF bootloader. It depends on ZeroPad, a file
# containing an ASCII EOF plus 0x4fff NULs, in the same dir.
# It also depends on :Tools:SixDigHex, which takes one arg.
# It ALSO depends on :Tools:SubstituteEquates, which deals
# in {Keys}.
#
# Change History (most recent first):
#
# 01/07/17 HQX Wrote script.


Set DirName "StreamEdit -e '¥,° Replace /[Â:]+°/ ¶"¶"'"

Set ScriptFile "{1}"
Set IconFile "{2}"
Set BadgeFile "{3}"
Set ElfFile "{4}"
Set ParcelsFile "{5}"
Set OutputFile "{6}"
Set ZeroPad "`Echo "{0}" | {DirName}`ZeroPad"

Set o1 "{TempFolder}cdg5BaseScript"
Set o2 "{TempFolder}cdg5PaddedScript"
Set o3 "{TempFolder}cdg5ShortenedScript"

Set WrapperSize `Count -c "{ZeroPad}"`
Set ElfSize `Count -c "{ElfFile}"`
Set ParcelsSize `Count -c "{ParcelsFile}"`
Set InfoSize `Evaluate {ElfSize} + {ParcelsSize}`

Set ElfOffset {WrapperSize}
Set ParcelsOffset `Evaluate {WrapperSize} + {ElfSize}`

Echo "<CHRP-BOOT>" > "{o1}"
Echo "<COMPATIBLE>" >> "{o1}"
Echo "MacRISC MacRISC3 MacRISC4" >> "{o1}"
Echo "</COMPATIBLE>" >> "{o1}"

Echo "<DESCRIPTION>" >> "{o1}"
Echo "MacROM for NewWorld." >> "{o1}"
Echo "</DESCRIPTION>" >> "{o1}"

Echo "<ICON" SIZE=64,64 COLOR-SPACE=3,3,2 ">" >> "{o1}"
Echo "<BITMAP>" >> "{o1}"
Catenate "{IconFile}" >> "{o1}"
Echo "</BITMAP>" >> "{o1}"
Echo "</ICON>" >> "{o1}"

Echo "<BOOT-SCRIPT>" >> "{o1}"
SubstituteEquates "{ScriptFile}" ¶
{FeatureSet} ¶
-d ElfOffset=`SixDigHex {ElfOffset}` ¶
-d ElfSize=`SixDigHex {ElfSize}` ¶
-d ParcelsOffset=`SixDigHex {ParcelsOffset}` ¶
-d ParcelsSize=`SixDigHex {ParcelsSize}` ¶
-d InfoSize=`SixDigHex {InfoSize}` ¶
| StreamEdit -e "¥,° Replace -c ° />/ '&gt;'" -e "¥,° Replace -c ° /</ '&lt;'" ¶
>> "{o1}"
Echo "</BOOT-SCRIPT>" >> "{o1}"

Echo "<OS-BADGE-ICONS>" >> "{o1}"
Catenate "{BadgeFile}" >> "{o1}"
Echo "</OS-BADGE-ICONS>" >> "{o1}"
Echo "</CHRP-BOOT>" >> "{o1}"

Catenate                  "{o1}" "{ZeroPad}" > "{o2}"
FileDiv -b -n {WrapperSize}                     "{o2}" "{o3}"
Catenate                                              "{o3}01" "{ElfFile}" "{ParcelsFile}" > "{OutputFile}"

SetFile -t tbxi -c chrp "{OutputFile}"


[Daniel]

I have not set up the cdg5 build system. Judging from your posts, it requires Docker, Make, QEMU, Python 3, and the Toolbox Toolbox you made. Everything has to be in the right folder and you have to cd to the folder containing the files you want to build. Is that correct?

Looking at the build script, it would be pretty easy to modify. Is the zeropad so you can avoid having to change the prcl resources?

[ELN]

Nosir! Just MPW. Using Classic on Tiger lets you use git, which helps, but is not essential. Ignore the GitHub repos! It is now hosted privately in GitLab.

Old versions did use Docker (and used Docker to install Python and all the other stuff). Nanopico shamed me into porting it to MPW, so that was my summer project.

I'll be super happy to get you started. Just let me get tomorrow's exam out of the way.

[nanopico]

Nanopico shamed me into porting it to MPW, so that was my summer project.

I'm not so sure I shamed you as much as I was a stubborn asshole who was working on OS 9 and wanted to us OS 9 to do the work.  Though I think it is better to be using MPW and ELN using it in OS X does make a nice blend of options, but the stubborn sadistic side of me uses only OS 9 and MPW. That's it. Well for me anyway.
There were many advantages to using MPW (not that it was easy to get everything moved there, thank ELN).
Native Mac tools that understand the mac system and formats with out questionable third party tools that sometimes don't work. I do have to say I miss having an editor with intelisense, but I'll live.  It was done before and it can be done now.

Is the zeropad so you can avoid having to change the prcl resources?

The parcels can be changed and modified if need be. The zero padding is just to ensure it starts on a location that is a multiple of I can't remember. Or maybe the Apple dev's had more debug stuff in there that got removed and they just felt like leaving the space empty? The script will adjust the PEF offsets as need be like ELN stated.

[Daniel]

I have a ton of questions about the parcels and the Trampoline.

What is the format of the Parcels from the Trampoline's perspective?

Does the order the Parcels are in matter?

How does the Trampoline respond to duplicate parcels? I have successfully managed to copy the parcels file into memory twice, so that the Trampoline would get a duplicate of every parcel. It booted fine. That simply tells me that it can handle duplicate parcels; it does not tell me how it handles them. Say, for example, we had a regular toolbox file with a replacement nanokernal tacked on to the end of it in memory(maybe it came from another file...). Which nanokernal would take precedence? I want to be able to have a primary parcels file in the Mac OS ROM and be able to override parcels in it by sticking replacements in another file(I am pretty sure that I can do that. I just can't test it at the moment).

Can one of you create a replacement nanokernal that puts an easily noticeable line in the NKLog or something? Please send it to me correctly formated so that it can just be appended to the Parcels and it will work.

As for the build system working in MPW, awesome!!! 

[ELN]

Quick primer on the parcels.

Introduced with Mac OS ROM 2.x or 3.x, their only job is to make binaries available to the Trampoline bootloader at runtime. Most of the parcels are drivers, which the Trampoline actually squishes into the Open Firmware device tree, later to be discovered by the MacOS environment after the 68k boot code takes control. By loading only the parcels that match hardware, memory is saved. But the most important parcel is the "Mac OS ROM Parcel", which is just a compressed 4 MB ROM image, the same as any other Power Mac. While it has had its initialisation code ripped out, the ROM parcel still contains the NanoKernel and emulator, as well as a full 3 MB 68k ROM with the Toolbox, OS and many drivers. It is always loaded (with some free space scooped out of the middle, again to save memory).

By the way, you'll also find a raw parcels file somewhere in Classic Startup.app.

Because the 'prcl' blob is a reasonably complex structure, I have made a build system for it inspired by other Apple code. It is my second attempt, coming after all that toolboxtoolbox stuff. It works pretty darn well, too. Here is the Rez code that tells the ParcelLayout program which parcels to put into the structure. The structure is essentially a linked list of groups of binary blobs with metadata sprinkled in. The order is described below: mostly alphabetical, but with some special parcels coming first. The {string, string} pairs are {name, compatible} strings for the benefit of the Trampoline.

Make a GitLab account (this goes for anyone) and PM me the name. I'll add you to the repo as a developer, and show you around it. Among other useful tasks, it automates the process of doing a full Mac OS ROM rebuild every time you change a little thing in (say) the NanoKernel.

I'd be very surprised if the Trampoline was actually reading from two 'prcl' blobs consecutively. They need a bit more work to concatenate than that.

Code: [Select]

/*
File: Parcels.r

Contains: Parcel descriptions which are compiled and used by ParcelLayout

Change History (most recent first):

  1/9/16 HQX Updated with info from earlier Mac OS ROM versions
  1/8/16 HQX Painstakingly adapted from the output of a Python script
*/


#include "RomTypes.r"


/* The CodeRegister, CodePrepare, ROM and Checksum parcels are special, and go first */



resource 'prcl' (100, "CodePrepare") {
kPropertiesForSpecialNode,
{"CodePrepare Node Parcel"},
0x00020000,
{
"name",
0x00000000,
useCstring {"AAPL,CodePrepare"};

"AAPL,prepare_order",
0x00000000,
useCstringArray {{"Placeholder"}};

#if BlueBox
kUseResName,
0x00020094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "InterruptTreeBlueBoxLib"};
#else
/* MotherBoardHAL was present in 6.1, absent in 7.5.1 */
//kUseResName,
//0x00020094,
//fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "MotherBoardHAL"};

kUseResName,
0x00020094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "TimeManagerLib"};

kUseResName,
0x00020094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "NVRAMServicesLib"};

kUseResName,
0x00020094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "RTCServicesLib"};
#endif
};
};


resource 'prcl' (110, "CodeRegister") {
kPropertiesForSpecialNode,
{"CodeRegister Node Parcel"},
0x00010000,
{
"name",
0x00000000,
useCstring {"AAPL,CodeRegister"};

kUseResName,
0x00010094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "NativePowerMgrLib"};

#if !BlueBox
/* AGPLib was absent in 7.5.1, present in 8.4 */
kUseResName,
0x00010094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "AGPLib"};

/* EtherPrintfLib AND StartLib were absent in 3.8 and earlier, present in 6.1 */
kUseResName,
0x00010194,
fromResource {RsrcDir, "MiscLibs.rsrc", 'nlib', "EtherPrintfLib"};
#endif

kUseResName,
0x00010094,
fromResource {RsrcDir, "MiscLibs.rsrc", 'shlb', "StartLib"};
};
};


/* Naturally the most important parcel */

resource 'prcl' (200, "The Really Important Parcel") {
'rom ',
{"Mac OS ROM Parcel"},
0x00000000,
{
"",
0x00000005,
fromDataFork {ImageDir, "RiscMondo"};
};
};


/* I wonder what these calculated checksums are used for... */

resource 'prcl' (300, "Property Checksum") {
'psum',
{"Property Checksum"},
0x00000000,
{
"",
0x00000000,
useCstringArray {{
"name",
"model",
"compatible",
"device_type",
"reg",
"assigned-addresses",
"slot-names",
"vendor-id",
"device-id",
"class-code",
"devsel-speed",
"fast-back-to-back",
"bootpath",
"mac-address",
}};

"",
0x00000000,
useCstringArray {{
"boot-rom",
"macos",
}};

"",
0x00000000,
useCstringArray {{
"Placeholder",
}};

"",
0x00000000,
useCstringArray {{
"Placeholder",
}};

"",
0x00000000,
useCstringArray {{
"usb",
"ieee1394",
}};
};
};


/* Now the 'prop' parcels, which are used to modify actual devices in the tree */
/* (in alphabetical order) */

/* BlueBox uses: a "bal" (BlueAbstractionLayer) parcel
a MacOSROMFile-version parcel
all parcels containing a PowerMgrPlugin
*/


#if !BlueBox
resource 'prcl' (1000, "Network: apple21143") {
kPropertiesForExistingNode,
{"apple21143", "network"},
0x0000000c,
{
"lanLib,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "Network.rsrc", 'shlb', "apple21143"};
};
};
#endif


/* backlight driver was absent in 3.8, present in 6.1 */
#if !BlueBox
resource 'prcl' (1010, "Backlight") {
kPropertiesForExistingNode,
{"backlight", "backlight"},
0x00000009,
{
"driver,AAPL,MacOS,PowerPC",
0x00000000,

#if CusterBacklightParcel
fromResource {RsrcDir, "Display.rsrc", 'ndrv', "CusterBacklightDriver"};
#else
fromResource {RsrcDir, "Display.rsrc", 'ndrv', "BacklightDriver"};
#endif

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"BacklightDriver"};
};
};
#endif


#if BlueBox
resource 'prcl' (1015, "BAL PowerMgrPlugin") {
kPropertiesForExistingNode,
{"bal", "power-mgmt"},
0x00000009,
{
"pef,AAPL,MacOS,PowerPC,register",
0x00000000,
fromResource {RsrcDir, "PowerManagement.rsrc", 'ndrv', "bal"};

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"PowerMgrPlugin"};
};
};
#endif


/* bmac+ driver was absent in 7.5.1, present in 8.4 */
#if !BlueBox
resource 'prcl' (1020, "Network: bmac+") {
kPropertiesForExistingNode,
{"bmac+", "network"},
0x0000000c,
{
"lanLib,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "Network.rsrc", 'shlb', "bmac+"};
};
};
#endif


/* PCCard library was in "cardbus"-named parcel in 3.8,
/* moved down to "cardbus"-compat parcel in 6.1 */

#if !BlueBox
//resource 'prcl' (1025, "Old CardBus Parcel") {
// kPropertiesForExistingNode,
// {"cardbus", "cardbus"},
// 0x00000009,
// {
// kUseResName,
// 0x00010094,
// fromResource {RsrcDir, "PCCard.rsrc", 'nlib', "PCCard"};
// };
//};
#endif


/* chrp-named parcels were present in 3.8, absent in 6.1 */

#if !BlueBox
//resource 'prcl' (1026, "CHRP parallel?") {
// kPropertiesForExistingNode,
// {"chrp,ecp", "parallel"},
// 0x0000000c,
// {
// "driver,AAPL,MacOS,PowerPC",
// 0x00000006,
// fromResource {RsrcDir, "LegacyDrivers.rsrc", 'ndrv', "parallel"};
// };
//};
#endif


#if !BlueBox
//resource 'prcl' (1027, "chrp,ide/ide") {
// kPropertiesForExistingNode,
// 0x0000000c,
// {
// "driver,AAPL,MacOS,PowerPC",
// 0x00000006,
// fromResource {RsrcDir, "LegacyDrivers.rsrc", 'ndrv', "ide"};
// };
//};
#endif


#if !BlueBox
resource 'prcl' (1030) {
kPropertiesForExistingNode,
{"cmd646-ata", "ata"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "ATA.rsrc", 'ndrv', "cmd646-ata"};
};
};
#endif


/* cofb driver was absent in 3.8, present in 6.1 */
#if !BlueBox
resource 'prcl' (1040, "Framebuffer... generic?") {
kPropertiesForExistingNode,
{"cofb", "display"},
0x00000008,
{
"driver,AAPL,MacOS,PowerPC",
0x00000024,
fromResource {RsrcDir, "Display.rsrc", 'ndrv', "cofb"};
};
};
#endif


/* Present in both BlueBox and bare metal */
resource 'prcl' (1050, "CUDA PowerMgrPlugin") {
kPropertiesForExistingNode,
{"cuda", "via-cuda"},
0x0000000c,
{
"pef,AAPL,MacOS,PowerPC,register",
0x00000000,
fromResource {RsrcDir, "PowerManagement.rsrc", 'ndrv', "cuda"};

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"PowerMgrPlugin"};
};
};


#if !BlueBox
resource 'prcl' (1060, "Network: bmac+") {
kPropertiesForExistingNode,
{"gmac", "network"},
0x0000000c,
{
"lanLib,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "Network.rsrc", 'shlb', "gmac"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1070, "Grackle... the G3 PCI controller?") {
kPropertiesForExistingNode,
{"grackle","pci"},
0x0000000c,
{
"pef,AAPL,MacOS,PowerPC,prepare",
0x00000016,
fromResource {RsrcDir, "PCI.rsrc", 'nlib', "Grackle_PCICyclesLib"};

"code,AAPL,MacOS,name",
0x00000000,
useCstring {"Grackle_PCICyclesLib"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1080, "ATA: Heathrow") {
kPropertiesForExistingNode,
{"heathrow-ata", "ide"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "ATA.rsrc", 'ndrv', "heathrow-ata"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1090, "ATA: Heathrow again!") {
kPropertiesForExistingNode,
{"heathrow-ata", "ata"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000002,
fromResource {RsrcDir, "ATA.rsrc", 'ndrv', "heathrow-ata"};
};
};
#endif


/* The Kauai driver is present in 9.1.1 and later, absent in 9.0.1 and earlier */
#if !BlueBox
resource 'prcl' (1100, "ATA: Kauai") {
kPropertiesForExistingNode,
{"kauai-ata", "ata"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "ATA.rsrc", 'ndrv', "kauai-ata"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1110, "ATA: KeyLargo") {
kPropertiesForExistingNode,
{"keylargo-ata", "ata"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "ATA.rsrc", 'ndrv', "keylargo-ata"};
};
};
#endif


/* The I2C driver is present in 9.6.1 and later, absent in 9.1.1 and earlier */
/* (See also uni-n-i2c below) */
#if !BlueBox
resource 'prcl' (1120, "I2C on KeyWest") {
kPropertiesForExistingNode,
{"keywest-i2c", "i2c"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "I2C.rsrc", 'ndrv', "i2c"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1130, "NVRAM on MacIO") {
kPropertiesForExistingNode,
{"mac-io", "nvram"},
0x0000000a,
{
"driver,AAPL,MacOS,PowerPC",
0x00000004,
fromResource {RsrcDir, "NVRAM.rsrc", 'ndrv', "mac-io"};
};
};
#endif


resource 'prcl' (1140, "File version") {
kPropertiesForExistingNode,
{"macos"},
0x00000001,
{
"MacOSROMFile-version",
0x00000000,

#if BlueBox
useCstring {"4.8GMc1"};
#else
useCstring {"10.2f1"};
#endif

};
};


#if !BlueBox
resource 'prcl' (1150, "'flash' NVRAM??") {
kPropertiesForExistingNode,
{"nvram,flash", "nvram"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000004,
fromResource {RsrcDir, "NVRAM.rsrc", 'ndrv', "flash"};
};
};
#endif


/* PCCard library was in a parcel called "cardbus" in 3.8 and earlier, moved here in 6.1 */
/* These two CardBus drivers were separate in 7.5.1 and earlier, merged in 8.4 */
#if !BlueBox
resource 'prcl' (1160, "CardBus 1") {
kPropertiesForExistingNode,
{"pci104c,ac1a", "cardbus"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000016, /* 0x14 in 7.5.1 and earlier; like this in 8.4 */
fromResource {RsrcDir, "PCCard.rsrc", 'ndrv', "cardbus"};

"PCCard",
0x00010094,
fromResource {RsrcDir, "PCCard.rsrc", 'nlib', "PCCard"};
};
};
#endif


/* This second CardBus parcel was absent in 6.1 and earlier, present in 7.5.1 */
#if !BlueBox
resource 'prcl' (1170, "CardBus 2") {
kPropertiesForExistingNode,
{"pci104c,ac50", "cardbus"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000016,
fromResource {RsrcDir, "PCCard.rsrc", 'ndrv', "cardbus"};

"PCCard",
0x00010094,
fromResource {RsrcDir, "PCCard.rsrc", 'nlib', "PCCard"};
};
};
#endif


/* FireWire parcel absent in 3.0, present in 3.7 */
#if !BlueBox
resource 'prcl' (1180, "FireWire") {
kPropertiesForExistingNode,
{"pciclass,0c0010", "ieee1394"},
0x0000020c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000004,
fromResource {RsrcDir, "FireWire.rsrc", 'ndrv', "firewire"};

kUseResName,
0x00010096,
fromResource {RsrcDir, "FireWire.rsrc", 'nlib', "FWServicesLib"};

kUseResName,
0x00010096,
fromResource {RsrcDir, "FireWire.rsrc", 'nlib', "DevNLib"};

kUseResName,
0x00010096,
fromResource {RsrcDir, "FireWire.rsrc", 'nlib', "DFMLib"};

kUseResName,
0x00010096,
fromResource {RsrcDir, "FireWire.rsrc", 'nlib', "GenericDriverFamily"};
};
};
#endif


resource 'prcl' (1190) {
kPropertiesForExistingNode,
{"pmu", "power-mgt"},
0x0000000c,
{
"pef,AAPL,MacOS,PowerPC,register",
0x00000000,
fromResource {RsrcDir, "PowerManagement.rsrc", 'ndrv', "pmu"};

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"PowerMgrPlugin"};

"target-mode-capable",
0x00000002,
useCstring {"SCSI"};

/* This came before the one above in 3.8, in this position in 6.1. Wonder why... */
kUseResName,
0x00010096,
fromResource {RsrcDir, "PowerManagement.rsrc", 'nlib', "PMULib"};
};
};


/* The I2C driver is present in 9.6.1 and later, absent in 9.1.1 and earlier */
/* (See also keywest-i2c above) */
#if !BlueBox
resource 'prcl' (1200, "I2C on UniNorth") {
kPropertiesForExistingNode,
{"uni-n-i2c", "i2c"},
0x0000000c,
{
"driver,AAPL,MacOS,PowerPC",
0x00000006,
fromResource {RsrcDir, "I2C.rsrc", 'ndrv', "i2c"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1210) {
kPropertiesForExistingNode,
{"uni-north", "pci"},
0x0000000c,
{
"pef,AAPL,MacOS,PowerPC,prepare",
0x00000016,
fromResource {RsrcDir, "PCI.rsrc", 'nlib', "UniNorth_PCICyclesLib"};

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"UniNorth_PCICyclesLib"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1220, "RTC on CUDA") {
kPropertiesForExistingNode,
{"via-cuda", "rtc"},
0x0000000a,
{
"driver,AAPL,MacOS,PowerPC",
0x00000004,
fromResource {RsrcDir, "RTC.rsrc", 'ndrv', "cuda"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1230, "NVRAM on PMU") {
kPropertiesForExistingNode,
{"via-pmu", "nvram"},
0x0000000a,
{
"driver,AAPL,MacOS,PowerPC",
0x00000004,
fromResource {RsrcDir, "NVRAM.rsrc", 'ndrv', "pmu"};
};
};
#endif


#if !BlueBox
resource 'prcl' (1240, "RTC on PMU") {
kPropertiesForExistingNode,
{"via-pmu", "rtc"},
0x0000000a,
{
"driver,AAPL,MacOS,PowerPC",
0x00000004,
fromResource {RsrcDir, "RTC.rsrc", 'ndrv', "pmu"};
};
};
#endif


/* The PMU2000 parcel was absent in 6.1 and earlier, present in 7.5.1 */
resource 'prcl' (1250) {
kPropertiesForExistingNode,
{"via-pmu-2000", "power-mgt"},
0x0000000c,
{
"pef,AAPL,MacOS,PowerPC,register",
0x00000000,
fromResource {RsrcDir, "PowerManagement.rsrc", 'ndrv', "pmu-2000"};

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"PowerMgrPlugin"};

kUseResName,
0x00010096,
fromResource {RsrcDir, "PowerManagement.rsrc", 'nlib', "PMULib"};
};
};

resource 'prcl' (1260) {
kPropertiesForExistingNode,
{"via-pmu-99", "power-mgt"},
0x0000000c,
{
"pef,AAPL,MacOS,PowerPC,register",
0x00000000,
fromResource {RsrcDir, "PowerManagement.rsrc", 'ndrv', "pmu-99"};

"code,AAPL,MacOS,name",
0x00000002,
useCstring {"PowerMgrPlugin"};

kUseResName,
0x00010096,
fromResource {RsrcDir, "PowerManagement.rsrc", 'nlib', "PMULib"};
};
};


[Daniel]

I have no idea if the Trampoline is actually reading from both parcels. I just know that the parcels file was read into memory twice and the Trampoline was told the offset and length of the double size parcel. For all I know, the parcels file might have a special "I'm done" signal at the end. I will set up a GitLab account soon.

Code: [Select]

" Toolbox" load-from-path
load-base 2 + constant parcels-offset
load-size 2 - 2 * constant parcels-size
parcels-size pagesz-1 + pagemask and constant parcels-pages
cr ." Starting toolbox allocation"
parcels-pages 400000 claim-mem constant rom-phys parcels-pages 1000 claim-virt constant rom-virt rom-phys rom-virt parcels-pages 10 do-map rom-phys rom-virt parcels-pages 10 do-map 
\ copy the compressed image
debug? if cr ." copying compressed ROM image" then
rom-virt parcels-pages 0 fill
parcels-offset rom-virt parcels-size 2 / move
parcels-offset rom-virt parcels-size 2 / + parcels-size 2 / move
debug? if cr ." MacOS-ROM phys,virt,size: " rom-phys u. ." , " rom-virt u. ." , " parcels-size u. then
\ create the actual property
debug? if cr ." finding/creating '/rom/macos' package" then
device-end 0 to my-self
" /rom" find-device
" macos" ['] find-device catch if 2drop new-device " macos" device-name finish-device then
" /rom/macos" find-device
debug? if cr ." creating 'AAPL,toolbox-parcels' property" then
rom-virt encode-int parcels-size encode-int encode+ " AAPL,toolbox-parcels" property
device-end
Edit:
Just to be clear, this code it part of the Custom ROM file I built. It will not work if you stick it in an ordinary ROM file.

[DieHard]

I am so glad you guys are NOT personal messaging all these developments; I get a woody just reading this thread !

This is so amazing in the sense that we seem to be very close to reverse engineering and running a fully-working modified replacement ROM that conquer the world ! (Or at least replace the "Happy Face" with an OS9 Lives Logo upon boot)
 

[devils_advisor]

I wish i could find the mentioned os7 sources. Supposedly somebody spread them but it seams to be a myth.

[Daniel]

The system 7 source code link is here:
http://www.toddp.com/classic/Software%20Install/Apple%20Source%20Code/System%207.1%20Source/Tools/
I have had it on my bookmark bar in Safari since before I came to this forum.

As for developments via private messages, I have kind of moved to that a bit for working on CDG5. Sorry
Not all that much has happened since I joined as a developer on GitLab(it was only a few days ago). We did figure out that code like this will not work inside loops or conditionals.

Code: [Select]

dev /
I will try to post when we make major breakthroughs.

[MacOS Plus]

I am so glad you guys are NOT personal messaging all these developments; I get a woody just reading this thread!

<chuckles> We're still a 'family website', right?

[DieHard]

I will try to post when we make major breakthroughs.

As you wish    But many of us enjoy the details... not everything has to be a breakthrough. 

It's nice to see it build and we appreciate all the hard work that you guys have done

[nanopico]

The system 7 source code link is here:
http://www.toddp.com/classic/Software%20Install/Apple%20Source%20Code/System%207.1%20Source/Tools/
I have had it on my bookmark bar in Safari since before I came to this forum.

As for developments via private messages, I have kind of moved to that a bit for working on CDG5. Sorry
Not all that much has happened since I joined as a developer on GitLab(it was only a few days ago). We did figure out that code like this will not work inside loops or conditionals.

Code: [Select]

dev /
I will try to post when we make major breakthroughs.

I had that problem with selecting the cpu with the code I have to check the cpu version and change it if need be.
You have to use select-dev

Code: [Select]

" /" select-dev


I will try to post when we make major breakthroughs.

As you wish    But many of us enjoy the details... not everything has to be a breakthrough. 

It's nice to see it build and we appreciate all the hard work that you guys have done

I agree. I haven't had anything to report though.
I think the last thing I had to say, I already posted, but in case I didn't.

I had a theory and ELN is starting to confirm that it is very possible a solution.
The theory is that the 68K emulator and a cache file are mapped to 1.5 GB.  Funny how that is the limit.
The trampoline is what is doing that load and mapping. It is also responsible for generating a mapping of the usable RAM and handing off the total RAM (which in this case don't map).  The trampoline would need to be modified to map the emulator and cache to a higher memory location and pass the usable memory correctly to the kernel.
This would all be done in the trampoline. So reversing that now.

Again this is a theory that ELN is showing this is very much the problem.  We still could be wrong, but something this likely is worth chasing.

This part is not easy and will take time.  We have no existing code base or person who worked on it.  This means a complete reverse, which is a very manual process.  You almost have to literally walk through the code by hand one instruction at a time. Very time consuming. As various methods are identified and the functionality is determined, then it starts to get faster.  So start slow, get faster. Emulators can sort of help, but with out source to match to they are almost useless.  The role they would play would be to find the last instruction before the nanokernel's first instruction.  This would make it able to work backwards and forwards, but backwards won't get very far.  So this is something I'm working through and because it's a slow process, don't expect much yet.

If I make no sense, I'm sorry.

[WolfpackN64]

I had a theory and ELN is starting to confirm that it is very possible a solution.
The theory is that the 68K emulator and a cache file are mapped to 1.5 GB.  Funny how that is the limit.
The trampoline is what is doing that load and mapping. It is also responsible for generating a mapping of the usable RAM and handing off the total RAM (which in this case don't map).  The trampoline would need to be modified to map the emulator and cache to a higher memory location and pass the usable memory correctly to the kernel.
This would all be done in the trampoline. So reversing that now.

Again this is a theory that ELN is showing this is very much the problem.  We still could be wrong, but something this likely is worth chasing.

This part is not easy and will take time.  We have no existing code base or person who worked on it.  This means a complete reverse, which is a very manual process.  You almost have to literally walk through the code by hand one instruction at a time. Very time consuming. As various methods are identified and the functionality is determined, then it starts to get faster.  So start slow, get faster. Emulators can sort of help, but with out source to match to they are almost useless.  The role they would play would be to find the last instruction before the nanokernel's first instruction.  This would make it able to work backwards and forwards, but backwards won't get very far.  So this is something I'm working through and because it's a slow process, don't expect much yet.

If I make no sense, I'm sorry.

You guys are doing amazing work anyhow. I just wish I could throw some money your way. 

[Daniel]

I had a theory and ELN is starting to confirm that it is very possible a solution.
The theory is that the 68K emulator and a cache file are mapped to 1.5 GB.  Funny how that is the limit.
The trampoline is what is doing that load and mapping. It is also responsible for generating a mapping of the usable RAM and handing off the total RAM (which in this case don't map).  The trampoline would need to be modified to map the emulator and cache to a higher memory location and pass the usable memory correctly to the kernel.
This would all be done in the trampoline. So reversing that now.

Again this is a theory that ELN is showing this is very much the problem.  We still could be wrong, but something this likely is worth chasing.

This part is not easy and will take time.  We have no existing code base or person who worked on it.  This means a complete reverse, which is a very manual process.  You almost have to literally walk through the code by hand one instruction at a time. Very time consuming. As various methods are identified and the functionality is determined, then it starts to get faster.  So start slow, get faster. Emulators can sort of help, but with out source to match to they are almost useless.  The role they would play would be to find the last instruction before the nanokernel's first instruction.  This would make it able to work backwards and forwards, but backwards won't get very far.  So this is something I'm working through and because it's a slow process, don't expect much yet.

If I make no sense, I'm sorry.

Nice. I didn't even have to suggest working on the Trampoline next
Is there any particular reason the Trampoline is in an Elf file? It is just code and data. It could probably be turned into an xcoff file. You would have to look at the relocation tables and stuff(I am unfamiliar on the exact terminology) to figure out how to arrange the data so that the code can get to it. You would also have to figure out if the method for finding the OF client interface is different in an xcoff. BootX seems like a good place to look for that(its source code is even available somewhere). Once we get the Trampoline in a format that can be built easily with MPW then we can start turning it into assembly(and possibly C or Pascal). I am afraid that I will not be of much help until then. I have essentially no experience with ppc assembly, elf files, or xcoff files

[nanopico]

Nice. I didn't even have to suggest working on the Trampoline next
Is there any particular reason the Trampoline is in an Elf file? It is just code and data. It could probably be turned into an xcoff file. You would have to look at the relocation tables and stuff(I am unfamiliar on the exact terminology) to figure out how to arrange the data so that the code can get to it. You would also have to figure out if the method for finding the OF client interface is different in an xcoff. BootX seems like a good place to look for that(its source code is even available somewhere). Once we get the Trampoline in a format that can be built easily with MPW then we can start turning it into assembly(and possibly C or Pascal). I am afraid that I will not be of much help until then. I have essentially no experience with ppc assembly, elf files, or xcoff files

It's disassembled. Method boundaries are mostly identified.  Code functionality is be determined.  Specific methods that should exists are being looked for.  Loops and recursive methods are being determined for first round analysis as they will be the parcel processing and device tree walker.

ELF xcoff and raw are loadable by OF. Why ELF is beyond me.  The ELF is static and not relocatable.  There are no relocation tables. There is one data section and one code section.  The layout and memory of the loaded code is known.

It really is just a lot of manual work at this point since there is absolutely no code reference for this.

BootX does a lot less than the trampoline.  Most of what the trampoline does is built into XNU. You have to look at XNU init code, kexts and all the hardware frameworks to figure that out.  And it's not as fun as manual reversing.

Progress is being made.  I was going to be working on it a lot this past weekend, but with the past week of almost non-stop rain a lot of houses here have some mild to major flooding in basements.  I spent all weekend pumping water out of my basement. Thankfully the water never touched any of my mac's.

[Daniel]

Wow. That is way farther along than I had thought we were