1. Power on/reset, early setup
At power on the amiga hardware is in undefined state. Certain things do happen though, the ROM overlay bit in CIA-A is enabled, and thus the Amiga Kickstart ROM appears at address 0. The M68K reset/poweron cycle fetches two longwords from address 0. Since the ROM is mapped, these two longwords are read from the ROM beginning. For KS 3.1 they are:
0x11144EF9
0x00F800D2
The first longword is the initial SSP (supervisor stack pointer), and the 2nd longword is placed to PC (program counter). The cpu will then begin code execution at address of the PC.
The kickstart rom early startup will now set up proper temporary SSP pointer (0x400, it will be chipmem once overlay is turned off), checksum the kickstart. If ROM at 0x00f00000 contains valid ID, the execution is diverted there (BPPC uses this for example). The custom hardware is initialized to known state. The overlay is turned off and chipmem will now appears at address 0 (and thus the temp stack will work now). CPU vectors and other low level setup is done. ColdCapture is taken at this point, if available.
The CPU type is determined.
The system probes the amount of chip memory, and sets the initial memory header up, from which temporary execbase is allocated. exec.library is initialized, and ranger (slow) memory amount scanned. Exec will now know the chip, slow memory, and have all the functions available. Finally the ROM is scanned for resident tags (basically the individual ROM components initialize later). The residenttag array is priority ordered. The residents are now initialized by calling InitCode(RTF_SINGLETASK, 0);
2. Initializing RTF_SINGLETASK modules
One of the very first modules is expansion.library. It will probe the system for Zorro expansions and initialize them. All found expansions are added to expansion.library ConfigDev list.
exec.library is initialization will now commence, and allocate new execbase. Any info from the old exec is moved to new one. This tries to make sure the exec is moved to fastest possible memory available. At this point supervisor stack is also allocated and SSP is made to point to it. Next the system will prepare itself for multitasking. Various functions are patched depending on the CPU type. Initial task is prepared and fired up. From now on, the system is running with multitasking enabled. CoolCapture vector is run at this point, if available. Next stage of the initialization is entered with InitCode(RTF_COLDSTART, 0). The execution will never return here (if it does, the screen will be rendered all purple and system will hang).
3. Initializing RTF_COLDSTART modules
This is the real deal: Most resident modules are RTF_COLDSTART and will be initailized in sequence now, adding various libraries, devices and resources to system as they go.
trackdisk.device is available in most (if not all?) amigas. It will probe the system for floppy drives and add DFx entry to expansion.library MountList entries. DF0 has higher priority than other possible units.
Any other media devices (such as scsi.device) will also probe the hardware for existing bootable medium (for hard disk or other block medium it is RDB with bootable partitions) and add the mountable / bootable entries to MountList if found.
Eventually system runs into bootstap module. This is the final module in which either the user is presented with 'Please insert floppy to boot' -animation, or if any bootable MountList entry is found the system is booted off it. If there is a bootable entry found it is now initialized and booting will commence.
DFx/trackdisk is special and the floppy disk is probed only at this time. Also, A1200/A600 bootable PCMCIA card is special is handled here. These units are also probed for bootable media while the 'please insert floppy to boot' -animation is played.
trackdisk.device DFx is special since it will try to load a bootblock off any inserted disk and if proper one is found it will be executed. Normal system bootblock contains a code that will FindResident() dos.library resident and InitResident() it. The bootblock might choose to do something else aswell, such as to load a demo/game using custom loader routines and never return or try continue initializing system.
For most harddisk controllers the bootblock is just ignored and the bootable MountList entry will internally FindResident() dos.library and call InitResident() for it.
4. dos.library and RTF_AFTERDOS.
dos.library will set up itself like any other library. It will also set up system vectors so that initial shell will be able to bring up system components (shell, con, ram, ffs etc).
At this point "Initial CLI" process is started. It will be fed the highest priority bootable volume from MountList. This entry will become SYS: device. The data is passed to the Initial CLI by sending a startup packet to it using PutMsg(). The very first exec task will now commit suicide by calling RemTask(NULL), and the execution will continue wih the "Initial CLI".
5. Initial CLI and shell, startup-sequence
Initial CLI (shell) will parse the input data from the startup packet. This data will indicate that this is the "Initial CLI", and will instruct shell to call special private vector is dos.library to set up further data. This function will among other things set up some initial handlers (PAR, SER, ... CON, RAM), assigns, add some residents such as Shell, handle ks 1.x compatible :devs/system-configuration, set up CLI for the process. At this point any RTF_AFTERDOS residents are executed with InitCode(RTF_AFTERDOS, 0). Finally depending on the expansion.library flags (eb_Flags), force the shell console to open (no EBF_SILENTSTART, not set by KS 1.x bootblock, but set by 2.x+ one), and open :S/startup-sequence of the system disk (no startup file is used if EBF_DOSFLAG is set, this is used by bootmenu "boot with no startup-sequence"). The CLI now has stream to fetch command lines from (startup-sequence), or no stream in which case it will drop into shell prompt.
6. startup-sequence
:S/startup-sequence will execute whatever commands are there.
If EBF_DOSFLAG was set, the shell will wait for user to enter commands.
-----
Note: I ran out of time here. I will fix typos and revise any stupid mistakes later.