############################################################################ # 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/sdcards.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 # # 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