boot/modular_kickstart.txt

   1   Modern AROS bootstraps support modular kickstart. This means that the
   2 kickstart doesn't have to be a monolythic image and can be built on the
   3 fly from separate modules.
   4
   5   In order to simplify life for both developers and users, the distribution
   6 kickstart is broken down into several packages. A package is a collection
   7 of modules, which can come either in ELF or PKG format.
   8
   9   PKG format is currently not supported by all bootstraps, however it's
  10 the preferred way because PKG kickstart contains correct module names
  11 (for crash backtrace), and also helps to prevent 'multiple definition'
  12 problems which sometimes appear while linking a ELF kickstart.
  13
  14   Currently the following standard packages are defined:
  15
  16 1. BASE.
  17
  18   Base package contains machine-independent modules. This package is
  19 designed to be fully portable and independent of its enviromnemt. The
  20 same base package can run on both hosted and native AROS. There's no
  21 functional difference between ELF and PKG forms.
  22
  23   Currently base package includes the following modules:
  24
  25  console.device
  26  input.device
  27  gameport.device
  28  keyboard.device
  29  amberram-handler
  30  con-handler
  31  hiddclass.hidd
  32  graphics.hidd
  33  keyboard.hidd
  34  mouse.hidd
  35  aros.library
  36  debug.library
  37  dos.library
  38  graphics.library
  39  intuition.library
  40  keymap.library
  41  layers.library
  42  oop.library
  43  utility.library
  44  bootloader.resource
  45  dosboot.resource
  46  FileSystem.resource
  47  lddemon.resource
  48
  49   These modules are not allowed to have machine-specific code because it
  50 violates portability convention. As of 12.09.2011, m68k-amiga
  51 (chipset-specific code in graphics.library) and PowerPC-native (display
  52 driver setup kludge in dos.library boot code) ports do not conform to this rule.
  53
  54   Of course "machine-specific code" does not include "cpu-specific code".
  55 It's allowed for any module to have relevant portions in arch/<cpu>-all.
  56
  57   This package is described in rom/mmakefile.src.
  58
  59 2. FS
  60
  61   This package contains resident filesystems and partition.library needed
  62 to boot up native AROS. These components are left out if base for
  63 optimization purposes, because hosted AROS boots up from emul-handler.
  64
  65   For hosted flavours disk-based version of these components are built by
  66 default (arch/all-hosted/mmakefile). However this package also doesn't
  67 contain any machine specific code and can run on all ports. This package
  68 can also be used on hosted, for deeper testing and simulation purposes.
  69
  70   Described in arch/all-native/mmakefile.src.
  71
  72 3. Poseidon.
  73
  74   Contains resident portion of Poseidon USB stack (poseidon.library,
  75 pciusb.device and several classes). Needed to boot up from USB devices
  76 and use USB keyboard and mice at boot time on native AROS. Does not
  77 ontain any other hardware-specific code than PCI device driver.
  78
  79   Decribed in rom/usb/mmakefile.src.
  80
  81 4. BSP (Board Support Package)
  82
  83   This term originates from eCos embedded operating systems and covers all
  84 lowlevel hardware-specific code which actually makes the machine to run.
  85
  86   For AROS this means kernel and basic hardware drivers. Contents of this
  87 package varies from port to port, and this is the only package which is
  88 not portable.
  89
  90   A minimal BSP contains:
  91
  92  kernel.resource
  93  battclock.resource
  94  processor.resource
  95  exec.library
  96  expansion.library
  97  timer.device
  98  bootable storage device drivers (ata.device, trackdisk.device)
  99  basic input device drivers (keyboard, mouse)
 100  at least one basic display driver
 101  irq.hidd (oldstyle IRQ handling API for native)