Mac OS 9 Discussion > Mac OS 9, Hacks & Upgrades

The Trampoline (Inside booting the Mac with a microscope)

<< < (3/11) > >>

MacTron:
Thanks for this really great explanation.  :)

nanopico:
I've found some more documentation that brings more detail to the boot process. 
It looks like the memory manager and process manager start earlier than expected.
Either I interpreted earlier documentation wrong or I interpreted this new stuff wrong.
I will update the process once I figure out what is correct. 
Oh the joy's of work in progress.

nanopico:
Steps 1 -7 outlined above are still accurate based on current knowledge.  But the remainder I believe is different so here is the updated order of steps from 8 on.
This is kind of a high level view and may get more and more detailed as we learn more.



* And now we are to the nanokernel (the actual OS is now starting up.

* Happy Mac Icon displayed
* The interrupt system is initialized
* I/O Drivers initialized. This is not all devices just some required to boot.  One of them being memory
* Memory Manager started up.
* The nanokernel looks to the boot block of the start up device to find the location of the System folder, name of the first application to launch (The finder), and the name of the debugger if there is one.
A copy of the boot block is stored as a resource in the System Folder.  The resource type is boot and resource id 0 is the boot block.
When an OS 9 system folder is blessed that resource is copied to the boot block on disk.
Most of what follows is considered part of the start manager.

* System file is loaded.
* The data fork of the System file contains the next level of boot code.  There is some relation between this and the resource id 1 of type boot in the system file

* The 68k Emulator is started up.  Not surprisingly a lot of the low level OS stuff runs off this.
* The resource manager is started up
* Machine specific and CPU specific patches are loaded from resources in the system file. 
This may be where the CPU version is checked to determine if the CPU is supported. It is the most logical spot for that code.
* Set up Disk cache
* ROM patches are located from resources in the system file.  The ROMversion is checked and patched based on it's version.
This is probably more relevant to old world ROM's as the boot process is different for them.

* ROM resource overrides are loaded.  These are stored in the ROv# resources in the System file
* The Time Manager is started and initialized along with the NVRAMServices.  This is required for drivers to be installed and hardware started up.
* Script systems are loaded and initialized and initialization resources are executed from the System File.
* Data structures are setup for internal use
* The debugger if specified is loaded. so that early startup function can be debugged.This is loaded at the top of RAM usually.
The debugger is loaded and the memory it is loaded to is setup by the memory manager but somehow hidden from the system.
An interrupt and trap is set so that the debugger can be jumped too.
The debugger is not controlled by the process manager so that it can interrupt anything.
The error handling in the kernel probably checks an entry in it's jump table to determine if it should drop into the debugger.

* The nanokernel starts loading system extensions (including control panels). 
Extensions are loaded in order by the file name alphabetically.
Extensions can be in the root of the System Folder, or the Extensions folder.  I believe it actually loads the ones in the root before the ones in the Extensions folder.
There are three types of resources loaded as extensions. Each extensions can reference further resources, allocate memory in the system stack and patch code.

* PACK - ROM extensions.  These are different from system extensions are used to extend specific ROM code.
* INIT - Your normal system extensions and control panels.
* DRVR - these are for hardware devices.  But they can also be virtual software drivers that appear to the system as hardware.
* Most other managers are loaded.
* Process manager is started. It is initialized and treated as standard application except that is loaded in a slightly different order due to it's relationship with the System heap.

* Memory manager loads code resources for the process manager
* The heap is loaded first and initialized. (Generally the stack is loaded and intialized first).
Part of the initialization is to grow the heap to the size referenced in a resource.  This resource is either in a resource in the System file or embedded in one of the code segments in the code resources for the process manager.
This is the point where the 1.5 GB limit is enforced. At this point it may be that we find the resource for the process manager size and update it and we have all 2 GB of RAM.
* The A5 world and stack pointer are loaded. The A5 world contains a bunch of global stuff that the OS uses and the application uses.  See the Memory book of Inside Macintosh page 1-12 for a better explanation of A5
* The jump table is loaded. If your not familiar with this, it's the table of function definitions for the application. Since applications may not be loaded at the same location in memory, this table is used to map the function to it's actual memory address.  Each application has it's own jump table.
* The stack is loaded and placed just below the A5 sections.
* The the process manager starts running.
* The process managers works pretty close with the memory manager and is almost a sub system of the memory manager
All programs actually run from with in the memory allocated by the memory manager to the process manager.
Programs are loaded at the top of available memory of the process manager.  So programs load from top to bottom in memory.

* Depending on configuration certian parts of AppleTalk related to printing are loaded
* The Finder (Or what ever was specified in the boot block) is loaded and started and you are ready to use the machine
Additional digging is going to happen to get an even better picture. 

nanopico:
Additional info on the boot process.  Eln and I have been really ripping things apart.  Here is some info for those that like to geek out on this stuff.

This is the boot process I'm 100% sure of.

1. Power on the machine and the built in firmware ROM starts up hardware as much as it needs to to build a device tree in open firmware (OF for now)

2. OF locates and loads the boot file from disk (The Mac OS ROM file).

3. On loading the image to RAM the boot script is executed to further setup the environment for the trampoline.

4. The script allocates memory for the trampoline, parcels and the info pages that the kernel will use. 

5. The trampoline contains three segments. A code sgement, data segment and notes segment (which is pretty useless at the moment).
The code segment is loaded to physical/virtual address 0x200000 and the data segment at 0x100000

6. The trampoline starts executing at memory address 0x20F078


Now the exact order and detail is not 100% clear for the next parts.

7. Trampoline initiates a client interface to OF

8. Trampoline obtains handles to the do-translate, do-map, do-unmap, claim-mem, release-mem,claim-virt and release-virt methods of the mmu and mmc devices
It will use these methods to setup the memory mapping for the hardware in the device tree and to set it all up for the kernel.

9. Trampoline get's the address the parcels package is stored at

10. Memory will be claimed for a flattened directory tree structure (or whatever it is the kernel and os want's for hardware access)

11. The OF device tree will be crawled and compared to the parcels

12. Parcels that are to be added as nodes will be loaded into ram and mapped to the flattened structure

13. Parcels that add properties and code to existing nodes will get loaded into ram and mapped to the flattened structure

14. Some devices (primarly ATA controllers and intterupt controllers) have some info about them in the trampoline code and not in a parcel that details how to start them up.  This will need to be updated for the ATA controller in the xserve and then a parcel with an OS 9 ndrv may need to be added to provide boot support from the internal ATA controller

15. The various info structures  will be created and populated for the kernel. (config info, cpu info...)

16. (this step I know is 100% true)  The trampoline disables open firmware

17.  The nano kernel starts up and setups up more memory stuff and loads various pieces of code. It then updates the memory map to clober a bunch of the early boot stuff and relocate structures and code to the final address without having to actually move them around.

18. Then from their it's loading libraries and code fragments and the managers and such and then off to the finder and the users does stupid shit and watches porn or something.

So that's the low level boot process. A couple more interesting tidbits for those who care.

The chrp boot script does a bunch of memory setup and mapping for the info pages, trampoline and parcels. 
These parts are allocated the following amounts of ram.
Trampoline    24   4k pages  (98304 bytes)
Parcels         610 4K pages  (2498560 bytes)
Info Pages    638 4k pages   (2613248 bytes)

nanopico:
Here is a little bit more on the trampoline code.
In case anyone wants to know.
The trampoline consists of at least 4568 lines of assembly code.  This is code that is verified as referenced and used.
There is another 11973 lines of code that I have not determined if is data or code.
At this time it appears that there are 118 methods in the code.  This has not been verified yet. Some of these methods would be debugging methods.

Now it's time to analyze every line of code by hand.

Navigation

[0] Message Index

[#] Next page

[*] Previous page