######################################################################################
# Config file : /boot/platform/hwm_bw/cmdline.txt
# Purpose.....: Native Raspberry Pi 2nd-stage bootloader configuration file.
#               This sets the command line passed to the Linux kernel for the
#               Slackware OS.
# Important..:  This file must NOT contain any empty lines, otherwise you'll boot with
#               a default set of command line operators, most likely resulting in
#               failure to boot.
######################################################################################
# Notes:
######################################################################################
# Raspberry Pi Kernel fork
# `````````````````````````
# When using the Raspberry Pi Kernel fork, you should adjust both the cmdline setting
# below and the OS' /etc/inittab
#
# For more information, see https://docs.slackware.com/slackwarearm:cstmz_kernel_rpi
######################################################################################
# This file is not actively managed by the Slackware OS.
############################################################################
# The Slackware OS initrd's '/init' understands the following Linux
# Kernel command line operators, which you may wish to configure by adding
# them to the command line at the foot of this file.
# 
# 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 features:
#              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_load_subsyst_soc
#              Load platform/SoC IP core drivers via module aliases
# kmod_load_subsyst_pci
#              Load PCI drivers via module aliases
# kmod_load_subsyst_usb
#              Load USB drivers via module aliases (already-enumerated devices only)
#
# 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.
############################################################################
rootfstype=%ROOTFSTYPE% root=%ROOTDEV% %POST_INST_OS_CMDLINE_APPEND%
