Boot, Startup and Runtime Configuration
Any and every PC system boots the same way. The first step, that is: Load and run the first sector off of the boot device, known as the 'primary boot' is simply the 'boot sector'. From this point on, the journey is different, depending on the code found in the initial boot sector. However, the second step is pretty much standard too: Load the next block on the device - aka the secondary boot record, and execute that. From there on, the process is operating system dependent.
However, even at this point there may be variants. If we're booting off of a non-partitioned (aka flat) hard drive or a floppy disk, the above is exactly what happens. If the hard drive is partitioned, it's slightly different: In this case the boot sector, known as the MBR, the Master Boot Record, includes a partition table with 4 entries, at least one of which is marked as 'active' (if not, boot will fail). The MBR, instead of just loading the next block from the medium as described above, will read the partition table, find the active (i.e. marked as 'bootable'), load the fist sector of that partition and jump to it.
Terms:
- Boot sector: The first physical sector on a bootable device.
- MBR: A hard disk boot sector which includes a partition table
- Boot block: Secondary boot - the block loaded and jumped to by the boot sector code
In the TLVC case, and if the file system type is 'minix', the 'partition boot block' happens to be identical to the floppy boot block. So from a boot procedure perspective, there is no difference between a floppy, a flat hard drive and a partition. The only variance in the picture is the MBR - on partitioned drives. By the way, while 'modern' MBRs allow several partition tables to be chained together to form so-called 'Extended Partitions', TLVC doesn't support that. 4 partitions per drive is enough.
The basic boot process then, consists of 3 stages. Further, a basic MBR is will work on most operating systems. It does what we described above, and TLVC will work fine with standard MBRs created by the MSDOS format and fdisk commands - and those created by other operating systems. However, and again like many operating systems, TLVC has its own MBR with additional functionality. Like the ability to choose boot device and which partition to boot from, potentially overriding the 'active partition' per the partition table. This capability comes in really handy during development, like when the last kernel loaded on a partition turns out to not work, we can just select a different partition to boot from, then replace the bad kernel and boot back to the original (development) partition.
In TLVC, the code related to booting is located in the bootblocks directory. mbr.S is what the name says, the MBR code - in assembler. boot_sect.S is the boot sector that the BIOS loads and jumps to if floppy or no partitions, and boot_minix.c is the secondary boot for minix filesystems.
If we're booting off of a FAT volume, whether floppy or hard disk, the process is slightly different. [TBD]
[TBD]
[TBD]
Boot code - whatever the level - is notoriously tight on space. The messages - for errors and other information - are correspondingly terse, usually just a code - a letter, number or character. Here's the translation:
-
.- a block read successfully from the boot device -
*- block read error, will be retried up to five times, happens on small floppies mostly, occasionally on MFM hard disks, in most cases recoverable -
1!- Too many retirees on read -
2!- Cannot read second sector of MINIX boot (no payload) -
3!- Kernel (/linux) not found in system directory (no system) -
4!- Bad system file format (incorrect header or invalid /linux image)
[TBD]
Boot messages are short messages from various components and stages during the boot and startup process. All operating systems emit messages during startup - some verbose, others rather terse. While not necessarily useful to the average user, the messages deliver important information to system administrators and developers. Some times showing error messages, most of the time just status information - of the type 'this device was found at this address' or 'this disk has these partitions with these sizes'.
A historical example follows - boot messages from a DEC PDP11/70 system loading Berkely Unix BSD 2.11. While this particular example is run on a simulator, the messages look exactly like they did on a real system in the 80s. Notice in particular the error condition reported numerous times - about file system full, which messes up the flow of messages - actually a good thing since it attracts attention.
Most systems keep these messages in a log file so they may be examined later. Extremely useful when tracking down elusive problems that may have developed over time. TLVC does not have that 'luxury' simply because it would be too expensive in terms of resources. Plus such logging require administration, a more or less automatic process to manage (delete, compress, archive, ...) the log files. We're not there yet.
In this context our focus is boot messages, but keep in mind that system messages will continue to appear on the console continue while the system is running: Notices about unusual conditions, errors, notable events - or simply printing the time and date at regular intervals in order to keep track of when various events happened. The degree of verbosity may be configurable - a useful aid when diagnosing problems.
Boot from ra(0,0,0) at 0172150
:
: ra(0,0,0)unix
Boot: bootdev=02400 bootcsr=0172150
2.11 BSD UNIX #11: Sep 9 16:28:47 PDT 2019
root@Mon:/usr/src/sys/PIDP11
ra0: Ver 3 mod 3
ra0: RA82 size=1954000
attaching de0 csr 174510
attaching lo0
phys mem = 3932160
avail mem = 3553280
user mem = 307200
January 11 12:33:33 init: configure system
dz 0 csr 160100 vector 310 attached
ra 0 csr 172150 vector 154 vectorset attached
rx 0 csr 177170 vector 264 attached
tms 0 csr 174500 vector 260 vectorset attached
cn 1 csr 176500 vector 300 skipped: No CSR.
erase, kill ^U, intr ^C
# ^D
Fast boot ... skipping disk checks
checking quotas: done.
Assuming NETWORKING system ...
add host pdp11.home.lan: gateway 127.0.0.1
add net default: gateway 192.168.10.1
starting system logger
/usr: file system full
checking for core dump...
preserving editor files
clearing /tmp
standard daemons: update cron accounting.
starting network daemons:Jan 11 12:34:13 pdp11 syslogd: /usr/adm/messages: No space left on device
Jan 11 12:34:13 pdp11 vmunix: ra0: Ver 3 mod 3
Jan 11 12:34:13 pdp11 vmunix: ra0: RA82 size=1954000
inetd rwhod printer.
starting local daemons:Jan 11 12:34:18 pdp11 syslogd: /usr/adm/cron: No space left on device
Jan 11 12:34:18 pdp11 January 11 12:34:18 lpd[97]: unable to get hostname for remote machine rpi
sendmail ntpd.
Sat Jan 11 12:40:09 MET 2025
/usr: file system full
Jan 11 12:40:13 pdp11 January 11 12:40:13 init: kernel security level changed from 0 to 1
2.11 BSD UNIX (pdp11) (console)
login:
TLVC fits nicely into this 'tradition', being slightly on the verbose side which makes sense for a system under development - and just as unintelligible for the average user (line numbers added for later reference):
SeaBIOS (version rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org
Booting from Floppy...
TLVC......Linux OK........................................................................
....................................
0: TLVC Setup .........Ft00B0 f0FDE d1423
1: Direct console, polling kbd 80x25 emulating ANSI (3 virtual consoles)
2: ttyS0 at 0x3f8, irq 4 is a 16550A
ttyS1 at 0x2f8, irq 3 is a 16550A
ttyS2 at 0x3e8, irq 7 is a 16550A
ttyS3 at 0x2e8, irq 10 is a 16550A
3: 40 ext buffers (base @ 0x95c0), 6K L1-cache, 20 req hdrs
4: eth: ne0 at 0x300, irq 12, (ne2k) MAC 52:54:00:12:34:56 (QEMU), flags 0x80, bufs 2r/0t
eth: wd0 at 0x280, irq 2, ram 0xcc00 not found
eth: ee0 at 0x360, irq 11, (ee16) not found
5: hd0: AT/IDE controller at 0x1f0
hda: IDE CHS: 63/16/63, Multisector I/O, max 16 sects
hdb: IDE CHS: 614/4/17, Multisector I/O, max 16 sects
6: hd1: Controller not found at 0x170 (376)
7: hd: found 2 hard drives
8: df: Direct floppy driver, FDC 8272A @ irq 6, DMA 2
9: df0: 1.44M (type 4) [CMOS]
10: Partitions: hda:(0,63504) no mbr (flat drive assumed)
hdb:(0,41752) hdb1:(17,41667)
11: PC/AT class, cpu 7, syscaps 0xff, 639K base ram, 18 tasks, 64 files, 96 inodes
12: TLVC 0.6.0 (62352 text, 17488 ftext, 12128 data, 7680 bss, 45726 heap)
13: Kernel text 0xb0, ftext 0xfe9, init 0x11a7, data 0x142e, top 0x9fc0, 494K free
14: MINIX: inodes 256 imap 1 zmap 1, first data 12
15: VFS: Mounted root 0x0200 (minix filesystem).
16: Running /etc/rc.sys script
Starting networking on ne0
ktcp -b -p ne0 10.0.2.1 255.255.255.0
ktcp: ip 10.0.2.1, gateway 255.255.255.0, netmask 255.255.255.0
ktcp: /dev/ne0 mac 52.54.00.12.34.56 mtu 1500
Starting daemons 'telnetd' 'ftpd -d' QEMU mode
Sun Jan 12 12:24:41 2025
17: /bin/init: Can't open /dev/ttyS2 (errno 6)
[tlvc15] TLVC 0.6.0
login:
Different but pretty much the same, reflecting the three phases of startup - hardware/first level boot, kernel startup, system startup.
Back in the day, the system console was a paper-terminal, like a Teletype ASR33, DEC LA120, TI Silent33 or something similar. Slow but with the advantage that neither boot messages nor anything else scrolled off the screen. A sysadmin would come to work in the morning and immediately head to the system consoles to check what had been going on overnight.
Fast forward to the PC, and anything other than the last 24 lines will be gone - scrolling off the top before you can read them (unless you film them using your cell phone!). Which makes using a serial console very advantageous during development - preferably one with a huge scroll buffer. Thus TLVC may be set up to use a serial console as the default (via menuconfig) or at boot time via bootopts.
As the system boots, messages start appearing on the console almost immediately. This is before the serial line has been initialized - which happens after the kernel has started. No problem, a brief look at the physical console, and we're up to date. Except with some activity those messages may already have scrolled off the screen. Or we're working remotely via the serial port and the physical screen is unavailable. Formerly this 'challenge' was partly solved via the cons command, which continuously monitors the console to any terminal window:
To make this even simpler, and to avoid risking that the interesting information scrolls off the screen before we get to it, TLVC was recently changed (shortly before v0.8.0 was released) to copy the contents of the console before activating the serial console, thus ensuring everything is available to the user/developer/administrator. The output on the serial console may look like this (XT class system):
A+FDD [A] C+HDD [C] F6ComDtct F8RomBoot
-=XTIDE Universal BIOS (XT)=- @ C800h
r625 (2023-02-19)
Released under GNU GPL v2
Master at 300h: STI Flash 8.0.0
Slave at 300h: not found
Booting C+C
Welcome to TLVC MBR Boot Manager
TLVC....Linux OK................................................................
...............................
TLVC Setup .........Ft0250 f10AE d14F6
moving bootopts (size 948) from 9000:1812 to 14f6:41fe
Direct console, scan kbd 80x25 emulating ANSI (3 virtual consoles)
ttyS0 at 0x3f8, irq 4 is a 16450
ttyS1 at 0x2f8, irq 3 is a 16450
64 ext buffers (base @ 0xa000), 8K L1-cache, 20 req hdrs
umb: 64k added to main memory, 128k block at 0xd000
...
… using line numbers from the listing 3 items up. Keep in mind that the messages will vary depending on the system and the kernel configuration. For example, there are no xms related messages in this example, which means that XMS support was not compiled into the kernel.
-
TLVC Setup .........Ft00B0 f0FDE d1423- 'Setup' is a stand-alone program loaded as part of the kernel that finalises the boot process, relocates the kernel and hands over control to it. It runs in high memory (upper part of base RAM) and the memory it runs in is immediately release for general use after it finishes. The output from Setup may be useful for debugging. The 'F' means thatbootopts- was NOT loaded from a FAT volume. If the next character is 'H', thehma=kerneldirective was found inbootopts, and the kernel will be loaded into HMA if possible. If so, the number next to the following 't' will beffff. Next is 'f' followed by the start of the kernel fartext segment and finally a 'd' followed by the kernel data segment base address (all three are repeated in the boot messages later).
The value of showing them here is for debugging - if the kernel does not load or something else prevents the system from starting, these letters and numbers provide a clue. The Moving bootopts ... line is also for debugging (the kernel relocates the bootopts file content into its own data segment for processing, then releases that memory) and may go away in a future release.
-
Direct console, polling kbd 80x25 emulating ANSI (3 virtual consoles)- Info about the (physical) console and keyboard drivers used (chosen viamenuconfig, in the 'character driver' section). 'Direct console' is the reliable choice, the other alternatives are for development and special purposes, and their use discouraged. ANSI emulation is the default for screen and cursor control, also chosen viamenuconfig. The alternatives are 'VT52' and 'None'. ANSI is the default and most powerful, VT52 is more compact (a subset of ANSI). ANSI is also known as 'VT100'. Consequently 'ansi' is the correct TERM setting when running screen oriented programs likevion the system. This is also the default. Note that if the system is set up to boot into a shell and not/bin/init, the normal initialization is not run and environment variables like TERM must be set manually (usingsetenv TERM=ansifor example). -
ttyS0 at 0x3f8, irq 4 is a 16550A emulating ANSI (3 virtual consoles)- one or more lines from the serial (tty) driver, informing about what it found when initializing itself. Typically one line, sometimes more. The port addresses are the defaults set in theports.hfile. The IRQs may be changed inbootoptsvia thecomirq=directive, see thebootopts'manual' below. The type (like '16550A') is useful information only at a very technical level and indicates the capabilities (and generation) of the serial IO chip this line is attached to. -
40 ext buffers (base @ 0x95c0), 6K L1-cache, 20 req hdrsis system buffer configuration info, either system defaults or from settings inbootopts. This system is set up to use 40 external (L2) buffers, most likely via thebufs=directive inbootopts, refer to the [Memory and Buffer System](TLVC Memory and Buffer subsystem) Wiki for details. The 'base address' is where the external buffer block starts in memory, usually at the top if the main memory section - information useful to developers (you will find it in the display frommeminfo -Malso). '6K L1 cache' is again most likely a setting frombootopts(thecache=directive), while 'req hdrs' ('request headers') is a resource used by the asynchronous IO system, useful for developers for scaling purposes. If the system is set ups to use - and has the necessary hardware - XMS buffers, this line will look slightly different:xms: using unreal mode, 120 xms buffers (base @ 0x100000), 8K L1-cache, 20 req hdrs- In this case, the L2 buffers are located in XMS memory and the quantity set by thexmsbufs=directive inbootopts. More about XMS buffers in the Memory and Buffer System document referenced before. -
eth: ne0 at 0x300, irq 12, (ne2k) MAC 52:54:00:12:34:56 (QEMU), flags 0x80, bufs 2r/0t- The system may have up to 4 Ethernet interfaces configured and possibly installed, even though only one may be active at any time (refer to thebootopts'manual' below for details). What's interesting in this context is which interfaces - if any - were found. As can be seen from the listing above, all Ethernet interfaces (commonly called 'NICs') configured into the kernel will be listed. I not found - either because int's not installed or the default or specified (inbootopts) IO address is incorrect - it will be marked as such. Having drivers that will never be used in the kernel is a waste of resources. Usemenuconfigto remove them. -
hd0: AT/IDE controller at 0x1f0- A standard AT class IDE disk controller was found at the default IO address. Zero, one or two drives may be attached to each controller. In many cases, the controller will not show up if no drives are attached to it. The attached drive(s) will be identified in the following line(s), likehda: IDE CHS: 63/16/63, Multisector I/O, max 16 sectsandhdb: IDE CHS: 614/4/17, Multisector I/O, max 16 sects.hdis the controller type, the following number is either 0 or 1,aandbare drive 'numbers', a and b belonging to controller 0, c and d to controller 1 - max 2 drives per controller, max 4 per system. IOW, if you have 2 controllers with one drive on each, presumably the 'master' drive, they will be namedhdaandhdcrespectively. A controller with no master but a slave drive is unlikely but possible. In that case we would have, say,hdaandhdd. The 'Multisector' message tells the developer the size of the buffer on the disk drive, usually between 2 and 16 sectors. More about CHS values and IDE drives in the Developer Notes pt. I Wiki. -
hd1: Controller not found at 0x170 (376)- The second standard IDE controller was probed and not found. This message is useful only to the developer and may not show up on your system. -
hd: found 2 hard drives- This message is really superfluous (for debugging), we know already how many drives were found. This message may not show up on your system. -
df: Floppy controller, FDC 8272A @ irq 6, DMA 2- All vintage PCs have a floppy controller at this address/IRQ/DMA. This message simply confirms that everything is OK and also tells which FDC (floppy disk controller) is installed on the system. 8272A is the same as NEC765C, the chip used on XT and early AT class systems. Newer systems have more capabilities, but most of these are unused by TLVC simply because what they add is not very relevant to the system. Keep in mind though that while the XT and AT have the same controller chip, the floppy drives/densities supported are different. Check out the Floppy Types and Autoprobe chapter in the Developer Notes Pt. III Wiki. -
df0: 1.44M (type 4) [CMOS]- This line lists the floppy drives found, their type/capacity and the source of configuration info (either CMOS or bootopts). If the system is XT class the there is no configuration info inbootopts, 2 360k drives will be reported regardless of what is physically present. -
Partitions: hda:(0,63504) no mbr (flat drive assumed) hdb:(0,41752) hdb1:(17,41667)- Partition check on the hard drives found. 'No mbr' means there was no partition table and the drive is assumed to be unpartitioned, which means there is one file system occupying the entire drive. The numbers in parentheses are the per partition starting sector and size (also in sectors) per partition. -
PC/AT class, cpu 7, syscaps 0xff, 639K base ram, 18 tasks, 64 files, 96 inodes- Kernel initialization is done. This line shows important basics about the system: AT or XT class, cpu type (7 means 386 or higher),syscapshas flags indicating whether certain capabilities are present in the system, relevant only for pre-AT systems (keyboard type, disk technology, irq mapping, …). Useful to developers only. The total memory size may be of interest - does it match what is actually in the system? Refer to the Memory and Buffer system Wiki for details. The tasks, files and inodes numbers may be default or set inbootopts, worth keeping an eye on if you're tuning the system. Check thebootoptsmanual for details. -
TLVC 0.6.0 (62352 text, 17488 ftext, 12128 data, 7680 bss, 45726 heap)- The kernel is identifying itself - name, version and sizes. The latter may be important because memory is usually the most critical resource on these systems. The example shows a really big kernel where the text (code) size almost hits the ceiling (64k) even with a rather big chunk of code diverted to the fartext segment. Data size is moderate, but that's normal because most of the sizeable allocations are made from the kernel heap (use thememinfocommand to see the details). -
Kernel text 0xb0, ftext 0xfe9, init 0x11a7, data 0x142e, top 0x9fc0, 494K free- More details about kernel memory, these are the starting segments for the various blocks whose sizes were reported in the previous line. 'Top' is actually the total memory size as reported on line 11, this time in hex. 'Free' is the size of main memory, a significant part of which will be occupied before startup has completed. If the kernel is loaded high (HMA), the address following 'Kernel text' will be 0xfff. Again usememinfofor details. -
MINIX: inodes 256 imap 1 zmap 1, first data 12- Kernel initialization is on its last leg, mounting the root file system, in most cases the boot drive (the active partition if a partitioned hard disk). The message is actually from themount()system call which will always report such data when a file system is mounted. -
VFS: Mounted root 0x0200 (minix filesystem).- This is a diagnostic (for debugging) message that may not appear on your system. It simply confirms the mounting of the root file system, which may be Minix type or FAT type. More about supported filesystems in the Wiki document Developer Notes pt. IV. At this point, kernel startup has completed and/bin/initor something else (depending on theinit=setting inbootopts) is taking over to complete system startup. -
Running /etc/rc.sys script- At this point,/bin/initis running and executing the/etc/rc.sysshell script which starts various subsystems depending on system configuration. If thenet=directive is present in the environmmountent,rc.syswill attempt to start the network via the/bin/netscript and the settings in/etc/net.cfg. It will also run the/etc/mount.cfgscript to check and mount filesystems in addition to root. The message lines following this line reflect whatrc.sysis actually doing and whether various subsystems and commands succeed or fail. -
/bin/init: Can't open /dev/ttyS2 (errno 6)- the final step if the system is configured to run multiuser (the absence of the 'n' command inbootopts) is for/bin/initto run through/etc/inittabto start subsystems according to the desired run level (set inbootopts, usually '3'). This error message warns thatinittabwants a/bin/getty(login) process to be started on the serial line/dev/ttyS2, but that line does not exist on this system ('errno 6' means 'No such device or address'). Nothing serious, just a reminder to edit the/etc/inittabfile to match the system.
After this, the getty process is started on the console and possibly serial lines available. The system is now running (presumably) normally and you're ready to log in. Use 'root' to login, there is no password.
Note: In the boot messages you may find 2 or even 3 items with the same IRQ. This may be, but usually isn't an error. First of all, devices may be present in the kernel but not in the physical machine. Secondly, since TLVC doesn't allocate an IRQ line until a device is actually opened, physical devices may share and IRQ, as long as they don't attempt to allocate it at the same time. Not an entirely reliable expectation since the hardware wasn't designed that way, but one that usually works.
There are two main mechanisms available to configure a TLVC system. The first - and most basic - is menuconfig, the configuration system that uses the make command to set compile time parameters for the system. menuconfig not only configures system/kernel settings and which modules/drivers etc to include or exclude, it also defines the environment, the boot disks, which applications to include and more. Check out the Configure and Build TLVC Wiki for more on menuconfig.
The second mechanism is the /bootopts file, the kernel boot-time configuration text-file with settings that defines the runtime system. While a TLVC system may be built without bootopts-support or the bootopts-file may be missing, it is almost unthinkable not having this extremely convenient tool available. As the number of settings have increased over the years, the more indispensable the file has become.
The /bootopts file, as a safety measure, MUST start with the two characters '##'. While formerly restricted to 1023 bytes, as of version 0.8.0 it may be of any size. It it's missing or not starting with the mentioned characters, a message to that effect will be displayed.
[Practical hint] A safe 'trick' to make a missing bootopts-file easy to detect is to make sure a HOSTNAME= statement is part of the file. The hostname, when set, will be part of the shell prompt in the running system (as in tlvc15# ). If it's missing (the shell prompt is just a hash character #), then something is wrong and bootopts was not read. If the boot volume is a FAT (aka MSDOS) file system, there is a chance the bootopts file will not be found even if it's there. The system boot process assumes that 1) the directory entry belonging to the file is in the first block of the root directory, and 2) the file must be contiguous. If the volume was created by the TLVC build process, this is not a problem. If an old FAT volume was made bootable it may be.
The bootopts-file has 3 types of settings: Regular parameters, environment settings and init-arguments. The regular parameters have the form name=value[,value…], like root=dhda1 or comirq=4,3,7,10. Environment settings look mostly the same but by convention, most of them have uppercase names - like the HOSTNAME= setting just mentioned, or LOCALIP=10.0.2.15. 'Mostly' because there are exceptions both ways: net=ne0 and sync=30 are both environment settings, an efficient way to pass settings from bootopts to the runtime system (which means /bin/init). And - in the opposite direction so to speak, there is TZ=, which is a regular parameter, not an environment setting. You will recognize the environment settings from bootopts by issuing the printenv command to the singleuser shell:
# printenv
HOSTNAME=tlvc15
QEMU=1
LOCALIP=10.0.2.15
NET=ne0
PATH=/bin
sync=30
GATEWAY=10.0.2.1
HISTPAGE=20
TZ=GMT0
HISTORY=30
#
There is a meaning to this 'mess': While the lowercase environment settings (like sync=30) are passed to the first process to run on the system after boot, usually /bin/init, in some cases /bin/sh or /bin/sash, they are not passed on in a multiuser setting. The uppercase settings on the other hand, are passed on. This distinction provides a flexible means for the developer and user to customize the system in a lot of ways without having to make low level changes.
Finally, there is the #-character: Like on most Linux and Unix systems, the hash starts a comment which extends to the end of the line.
The available bootopts settings are described in detail below (check out the example file towards the bottom). Because there are so many, they've been roughly grouped by functionality which hopefully will make it easier to find what you're looking for. Since the size restriction on bootopts was lifted, the verbosity of comments in the file has increased, providing valuable documentation 'on the run'. Further, in addition to the document below, there is a man-page for bootopts with pretty much the same information.
Samme bootopts file as of v0.8.0:
## TLVC startup configuration - needs CONFIG_OPTSEG_HIGH
console=ttyS0,57600 # serial console
3 # init level, 3 = multiuser, serial active
#n # no rc.sys
#root=hda1 # make any drive or partition root
#ro rw # rootfs rdonly or rw, override config
#TZ=MDT7
# networking
NET=ne0 # start netw @ boot w/this interface
LOCALIP=10.0.2.15
GATEWAY=10.0.2.1
HOSTNAME=tlvc15
ne0=12,0x300,,0x80 # defaults in ports.h
wd0=2,0x280,0xCC00,0x80
#3c0=11,0x330,,0x80
#ee0=11,0x360,,0x80
#le0=
#mac=11:22:33:44:55:66 # set MAC addr, ne2k only
netbufs=0,0 # net buffers, recv/trans, ne2k only, def 2,0
comirq=,,7,10 # IRQ for com ports, max 4
# kernel tuning, buffers are 1k each
#cache=8 # L1 cache
#bufs=40 # L2 buffers (default 64)
#heap=30 # max heap (kB), def ca. 50k
#tasks=16 bufs=64 cache=8 files=64 inodes=96 # defaults
#tasks=18 # tasks, default 16, max ~24
#files=68 inodes=100 # defaults, must match tasks
#mem=640 # memsize kB
#umb=000011111 # enable UMBs, 1 digit per 32k starting @ A000
sync=30 # autosync buffers (secs)
# kernel debugging, needs CONFIG_TRACE
debug=2 # Enable kernel debug functionality
#strace # enable system call tracing
#kstack # enable kernel stack tracing
# XMS - 286 and up
xms=on # if available
xmsbufs=256
hma=kernel # load kernel in HMA if available, must start in col 1!
# mass storage
#hdparms=823,4,38,-1,63,16,63,-1 # CHSW for 2 drives, overrides CMOS & BIOS
#xtflpy=3,1 # meaningful for XT systems w/720k type 3 drive(s)
fdcache=5 # floppy read cache for slow systems <= 286
#xtide=0x300,5,1,,, # addr, IRQ, flgs for 2 XT-IDE controllers
#system startup
#init=/bin/init 3 n # multiuser (lev 3), no /etc/rc.sys
#init=/bin/sh # singleuser shell (may be /bin/sash)
debug=0 If debug has been enabled for any of the subsystems in the kernel (see include/linuxmt/debug.h), this setting determines the level of verbosity for the output. Zero means 'turn off'. This mechanism obviously depends on the programmer to actually use the prototypes defined for its use. The number may be anything, but above 5 is rarely meaningful. Details in the Kernel Debugging Wiki.
sync=20 Tells the kernel to sync dirty buffers to disk/floppy with this interval (in seconds). 15-30 is reasonable. If not present, there will be no syncing, which is risky and will lead to data loss if the system crashes. If the system has a large number of xms buffers, syncing may cause noticeable 'lagging' at times. This is an environment setting picked up by the /bin/init command, which is taking care of the actual syncing. Check the TLVC Memory and Buffer subsystem for details.
cache=8 Sets the size (in k bytes) of the level 1 (L1) buffer cache. The default is 8, numbers between 6 and 12 are reasonable. If the system has no L2 buffers (see below), a higher number (12-20) is advisable to get reasonable performance. Space for the cache is allocated from the kernel heap. The system will not work without a L1 cache. Refer to the TLVC Memory and Buffer subsystem Wiki for details.
bufs=40 If the system is configured to use external buffers, this parameter sets the number of second level (L2) buffers for the system (a buffer is always 1k in size). Buffer space is allocated outside the kernel data segment and up to 64 buffers may be allocated. 32 to 64 are reasonable values given enough memory. Note that if the system is configured for - and is capable of - xms-buffers and the xmsbufs= parameter is >0, the bufs= setting will be ignored. Values lower than 4 are unsmart and may lead to 'thrashing'. Zero is not allowed. If set to zero, the system default (from menuconfig) will be used. More info in the TLVC Memory and Buffer subsystem Wiki.
tasks=16 Tasks (or 'processes') in TLVC are managed by the kernel via a 'task structure array' which occupies a significant 822 bytes per task, and thus represent a significant 'static' memory 'load'. This parameter tells the kernel how many such entries to allocate at startup time, which becomes the max number of processes the system can run at any one time. The smallest possible number is 3, and requires that the systems boots into a shell /single user) instead of starting /bin/init(see the init parameter below). The max number is currently 20. The default is 16. Note that there is no sanity check on the value, setting a wild number (i.e. <3, >20) will wither prevent the system from booting or make it unstable.
files=64 Sets the number of files that may be open concurrently on the system. The default is 64, which is reasonable if the number of tasks is 16. A task needs at least 3 open files to run, adding 1 per task delivers this number: Too small for some applications, too large for others - which averages out reasonably.
inodes=96 The size of the kernel inode-table, the number of inodes that may be active on the system at any time. In addition to an inode-entry per open file, the inode table also holds inodes for every open directory, device and mount, thus the extra capacity compared to the open-file table. Refer to the Developer Notes on the Minix File system (TBD) for details.
heap=32 By default the kernel data segment is always extended to its max size, 64k bytes (refer to the TLVC Memory and Buffer Subsystem Wiki for details). The data segment has 3 parts: kernel initialized data ('kernel data'), uninitialized data ('kernel bss') and the kernel heap. The former two have fixed sizes set when the kernel is compiled and linked. The kernel heap normally takes the rest of the segment: 64k minus the sum of kerne data and kernel bss. If this is not desirable, the 'heap=' parameter may be used to reduce the size of the heap appropriately. Use the kernel boot messages and the actual heap usage (using the meminfo tool) to tune the heap setting. Beware that a too low value will cause system startup to fail.
mem=512 (Formerly memsize=) Sets the size of conventional memory on the system. While normally set correctly by querying the BIOS at startup time, there are cases when the BIOS value may be wrong or the size needs to be adjusted for debugging.
xms=on If the cpu is 286 or higher, this setting enables XMS support. If the CPU is 386 or higher, unreal mode is used for XMS access (TLVC always runs in real mode). If 286, the loadall instruction is used. If the parameter to xms= is int15, the system will us a BIOS call for XMS memory access, regardless of CPU-type.
xmsbufs=1250 Set the number of xms-buffers on the system. Reasonable values are 100-2975. Read about xms-buffers in the TLVC Memory and Buffer Subsystem Wiki.
strace Enables process stack tracing if compiled into the system. Inactive unless CONFIG_TRACE is set in the configuration. Refer to the TLVC Kernel Debugging Wiki for details.
kstack Enables kernel stack tracing if compiled into the system. Like above, it's inactive unless CONFIG_TRACE is set. Read more in the TLVC Kernel Debugging wiki.
hdparms=306,4,17,128,614,4,17,-1 Defines the CHSW values for the first 2 IDE or MFM drives on the system. CHSW = Cylinders, Heads, Sectors, Write-precomp. Write-precomp is relevant only for the older of MFM drives. While IDE/ATA drives have CHS values that will be read from the drives during boot, these may not always be what you want (refer to the TLVC Developer Notes pt. I for lots of details). For MFM (the XD driver, XT class systems only) this setting is required unless the drive is a standard 10MB PC/XT drive (306/4/17/128 parameters).
fdcache=5 Sets the size of the floppy disk sector cache and requires that memory for the cache has been allocated in the kernel configuration (the default config reserves 7k bytes for this purpose). This cache is useful for slow systems (286 and down) only, and is automatically turned off for faster systems (386+). Check the TLVC Developer notes pt. III for details.
xtide=0x300,5,1,0x320,0,0 This setting is required if running IDE hard disks via an XT-IDE or XT-CF card, and tells the standard IDE driver to behave in certain ways depending on the configuration. Two controllers (with up to 2 drives each) may be configured via this setting. The parameters are 'IOport (hex), IRQ (decimal), flags'. Fields may be empty or missing: xtide=0x300,5,1,,, and xtide=0x300,3,2are both valid. The 'flags' field is important: 0 means 'standard XT-IDE, 1 means XT-CF Lite, 2 means XT-IDE HighSpeed PIO. Refer to the detail rundown in Developer Notes pt. I.
xtflpy=3,1 Applies only to XT class systems that don't have NVRAM/CMOS for system parameter storage. Only useful if the system has floppy drive(s) different from the default 360k 5.25in drives. The numbers have the same meaning as on newer (AT+) systems with CMOS, '3' in the example meaning 720k/3.5in drive.
NET=wd0 If present, tells the system to start networking automatically at boot time, and defines the default interface for the net command to use. Note the capitalisation, which means that this line will be part of the environment when logging into the system. this is important because commands like net and configurations scripts like /etc/net.cfg expect this to be able to auto configure networking at boot time - and later when the user stos and restarts the network.
netbufs=0,0 Currently applies to the ne0 interface only and specifies the number of receive and transmit buffers (respectively) to allocate. The feature is considered experimental and does not currently have significant performance effect unless the system is very heavily loaded. Reasonable settings are 2,0 or 2,2. 2,0 is the default, set in tlvc/arch/i86/driver/net/netbuf.h`. Refer to the TLVC Developer Notes pt. II: Networking section for details. Also, there is a section devoted to this option in particular in the Wiki document TLVC Networking Guide.
mac=00:00:00:00:00:00 Manually sets the low level MAC address for the active interface, currently implemented in the ne2k driver only.
ne0=, wd0=, ee0= , 3c0= , le0= These are settings for each individual network interface type. Remember that the system supports only one active network interface at any time. You may, however, install many physical NICs in the system as long as they con't 'collide' in terms of port addresses and memory mapped segments.
With several NICs installed (and initialized correctly during startup, check the boot messages on the console), you can switch between them on a running system using the net stop and net start command. The parameters are: IRQ (decimal), base IO port (hex), shared memory address (hex), flags (hex), like wd0=11,0x320,0xCC00,0x80.
NICs without shared memory capability will ignore the shared memory field. Leave the commas in place though. Also note that if more than one physically installed NIC uses shared memory, their memory segments cannot overlap! Again refer to the TLVC Developer Notes Wiki for details. A physically installed interface may be disabled by setting the port address to 0.
Several NICs sharing the same IRQ may or may not work: The IRQ is allocated when a NIC is opened, not when it's configured. Similarly the IRQ is released when the NIC device is closed, making to available to a different NIC. However, since the ISA specification doesn't cover this situation, the first NIC using a particular IRQ line may hold on to it after the driver has released it anyway. IOW your mileage will vary.
NET= See networking above
LOCALIP= Set the system's IP address. DHCP is not implemented.
GATEWAY= Set the system's default router address.
HOSTNAME= Set the system's hostname. Should match /etc/hosts.
These are command line parameters to the /bin/init program, normally the first program started by the kernel when the startup process has completed (unless overridden by the init= parameter, see below).
n - Don't run the /etc/rc.sys script, which means no automatic network startup and not auto-mounting of extra file systems (in addition to root).
3 (runlevel) - This is the runlevel init uses when parsing the /etc/inittab table. Introduced in Unix System III, inittab provides an easy way to switch between runtime settings, typically singleuser and multiuser. Read the comments at the top of /etc/inittab for details about the 1-6 levels available. The default is 1.
hma=kernel With this setting, and if extended memory (XMS) is available, the kernel will be loaded high, into the so called High Memory Area. The xms= setting does not affect this, and TLVC considers XMS memory to start at 1M + 64k, i.e. above the HMA. Note that this is the only bootopts-setting that MUST start at the beginning of a line.
root= This option is extremely useful during development, in particular storage driver development. It allows for the root device to be different from the boot device. For example, you may be booting off of a floppy drive (/dev/df0) and mount root on /dev/df1 by setting root=df1. This is particularly valuable since df1 is not bootable. Likewise you may boot from hard disk, say /dev/hdc and mount root from /dev/hdc3. And so on.
ro Mount the root filesystem ReadOnly.
rw Mount the root filesystem ReadWrite, This is the default.
TZ= Set the timezone for this machine. The default is GMT, which is the CMOS clock setting unless configured otherwise via menuconfig.
console=tty1 Use this to redirect the system console to a device different from the default PC screen/keyboard (may also be redirected via menuconfig). The syntax is console=ttyS0,57600 - 'device, speed'. tty2,0 is a valid choice and will redirect the console output to the second virtual screen on the PC (ALT-2). The default is tty1.
comirq=4,3,, Sets the IRQ lines to use with the serial lines, match match the hardware settings. The default is 4,3,5,7. Be aware the IRQ 5 does not work (is not generally available) on many newer systems. comirq=,,7,10 works well if you have 4 ports and configure them correspondingly.
init=/bin/init Allows the system to boot into a different program than /bin/init which is the default. Using init=/bin/sh og init=/bin/sash are viable choices for a single user system with severe memory constraints. /bin/sash is the 'standalone shell', which is significantly smaller than the regular shell, and functionally constrained, but very fast.