############################################################################
# File...: /boot/extlinux/extlinux.conf
# Purpose: U-Boot configuration to boot Slackware Linux ARM / AArch64
#          using U-Boot's 'sysboot' feature.
############################################################################
# This file has been created by
# ftp://ftp.arm.slackware.com/slackwarearm/platform/aarch64/bootware/src/inst_dskimg.build
# and is not a component of any Slackware package.
#
# Typically this file is placed upon an SD card, and this
# file is located by U-Boot's default boot script, and subsequently
# loaded and executed by U-Boot's 'sysboot' command.
#
# The Kernel cmdline parameters (set by the 'append' directives below)
# set the root file system device, file system type and these are
# configured at install time by the Slackware installer.
#
# Typically you won't need to edit this file.
#
############################################################################
# The Slackware OS initrd's '/init' understands the following Linux
# Kernel command line operators, which you may wish to configure
# using the 'APPEND' configuration directive (see below).
# 
# init=
# luksdev=/dev/
# lukskey=
# rescue=
# resume=
# root=/dev/  OR  root=LABEL= (use LABEL= syntax to avoid pinning
#                                your root partition to a particular
#                                storage subsystem or location on the
#                                storage bus)
# root=UUID=   Or use the UUID rather than the label. See above.
#
# rootfs= OR rootfstype= (these are synonymous)
# rootflags=
# waitforroot= OR rootdelay=* (these are synonymous)
############################################################################
# Slackware ARM additions:
#
# awaitrootdev Await the appearance of the root device (as configured
#              by the 'rootdev=' cmdline operator) within /dev, after
#              waiting for the duration specified by the 'waitforroot='
#              Kernel cmdline operator.
#
#              On occasion, the RockPro64's USB storage bus would take time
#              to come online and would cause a boot failure.
#              This option has been tested using native storage devices
#              such as /dev/sda.
#              However, this has not been tested with LUKS, LVM or RAID
#              and this author suspects it will be incompatible.
#
#              If you have trouble with this, remove it from the boot
#              options below, and if you have trouble with your storage
#              sub systems coming online, try the next option:
#
# awaitdev=    Await the appearance of one or a number of devices within
#              /dev.
#
#              If you have trouble with LVM, LUKS or RAID subsystems during
#              boot, it may be because the underlying storage layer upon
#              which the abstraction layer relies, has yet to come online.
#
#              This code is executed directly after '/init' pauses for any
#              delay specified in the Kernel cmdline operators:
#              waitforroot=*|rootdelay=
#              Subsequently, the LVM, RAID and LUKS handling code will
#              execute.
#
#              Do not use both 'awaitdev=' and 'awaitrootdev' together.
#              If you are not using any abstraction layer, and have the
#              root filesystem on 'native' storage (e.g. /dev/sda) then
#              only use 'awaitrootdev'.
#
#              The syntax a comma separated list of device names, relative
#              to /dev:
#                awaitdev=sda2,sda3
#
# kmod_load_subsyst - development feature
#              Load all Kernel modules for the major sub systems (ARM SoC IP cores, PCI, USB).
#              This helps light up the entire range of supported hardware rather than
#              manually defining it within the loader scripts.
#
# kmod_megaload - development feature
#              Recursively load all of the Kernel's major sub systems contained
#              within the Kernel's /lib/modules directory.  This is a development
#              feature to help onboard new Hardware Models.
#              This may crash your system!
#
# platwalk     platwalk loads all Hardware Model Kernel module loader scripts
#              unconditionally, rather than selectively based on the detected
#              Hardware Model. This approach facilitates the onboarding of new
#              Hardware Models by ensuring that as many Kernel modules as
#              possible are loaded, increasing the likelihood of hardware
#              functionality being activated. It is primarily intended for
#              developers.
#
# The following options will pause the boot process and require using the serial port.
# Do not use these if you do not have a serial console on the machine.
#
# slkpbs      Pre Boot Shell
#
#             This Kernel commandline setting opens a shell at the
#             three stages of Kernel module loading.
#
#             Stage 1: Pre-loading any of the Kernel Module Loader scripts.
#                      This provides an opportunity to edit those scripts to
#                      change any of the modules or configuration prior to
#                      them being processed.
#
#             Stage 2: Kernel Module Loader scripts have been processed but the
#                      Kernel Modules have yet to be loaded into the Kernel.
#
#             Stage 3: Post loading Kernel modules, prior to returning
#                      execution to /init.
#
#             The purpose of this functionality is to more easily enable
#             developers to break into the environment at key events
#             within the boot proces.
#
#             Users can also achieve similar results by adding the
#             hook scripts (see '/load_kernel_modules' within the OS
#             initrd) to the OS initrd; but that method is for permanent
#             'local' changes.
#
#             Note: The 'pre boot shell' has read-only access to the
#             environment, so cannot edit the Kernel module variables.
#             However, whilst inside the environment users can create or
#             directly edit the hook scripts which will allow them to modify
#             the execution and adjust the variables as needed.
#
# slkpbs3     Pre Boot Shell Stage 3
#             Start Pre Boot Shell directly at stage 3 once all modules have been
#             defined and loaded.
#             This is to help with input systems (e.g. USB keyboards) that won't
#             come live at stages 1-2 because the modules have yet to be loaded.
#
# slkpbs_modstep
#             Confirm loading of each Kernel module.  This is for debugging and
#             troubleshooting.
#             This can also be enabled from stage 1 or 2 of the Pre-boot shell by
#             $ touch /.modloadstep
#
#             This is a crude troubleshooting tool: a subsequent module may load
#             a rejected module as a dependency.  However, that's not the case for
#             all, so it's still useful.
############################################################################

# We ship these SD cards configured to boot the installer.
# The Slackware installer switches this to boot the OS by default.
DEFAULT Installer
MENU TITLE Slackware Linux
PROMPT 0
TIMEOUT 90
