src-test2/sys/boot, branch release/5.2.1_cvs

This commit was manufactured by cvs2svn to create tag

2004-02-23T15:32:56Z

'RELENG_5_2_1_RELEASE'. This commit was manufactured to restore the state of the 5.2.1-RELEASE image. Releases prior to 5.3-RELEASE are omitting the secure/ and crypto/ subdirs.

MFC: Save %cx around calls to the BIOS to read data to workaround bugs in

2004-01-25T01:20:36Z

certain BIOSs when booting from a USB CD-ROM. Also, fix the twiddle to actually twiddle. Approved by: re

MFC rev 1.9:

2004-01-10T03:36:14Z

Disable the APIC when selection the 'Safe Boot' option. Approved by: rwatson

This commit was manufactured by cvs2svn to create branch 'RELENG_5_2'.

2003-12-07T03:02:28Z

With the beastie menu a problem was introduced in which selecting a

2003-11-21T19:01:02Z

different kernel to boot with kernel="NAME" would load the kernel and loader.conf-selected modules from /boot/NAME, but it would not change module_path. So, for instance, the automatically loaded acpi.ko would come from /boot/kernel/acpi.ko, *always*. Mind you, this happened for unassisted boot. If you interrupted, typed "unload" and then "boot NAME", it would Do The Right Thing. The source of the problem is the double initialization with beastie's loader.rc. One would happen inside "start", and would load the kernel. The next one would happen later in the loader.rc script, resetting module_path. Because module_path is set to the Right Value by the functions in support.4th that actually load the kernel, when beastie.4th proceeded to boot module_path would remain wrong, as the kernel was already loaded. This can be corrected by removing either initialization, and also by changing the command used by beastie.4th from "boot" to "boot-conf", which makes sure you use the right kernel and modules. I chose to remove the second initialization, since this let you interrupt (or confirm) boot before beastie even comes up. I avoid also doing the boot-conf change because that would simply cause the kernel and modules to be loaded twice (in fact, that was my original patch, until, in writing this very commit message, I saw the error of my ways). This commit changes the semantics of module loading when using the beastie menu. Now it does what one would expect it to, but not what it was actually doing, so something may break for unusual setups depending on broken behavior. As our japanese friends so nicely put it, shikata ga nakatta. :-) Approved by: re (scottl)

Update the size of the OS string table that wasn't updated in the previous

2003-11-20T20:28:18Z

commit that removed the UNIX entry. Submitted by: Rudolf Cejka Approved by: re (rwatson)

When rebooting the machine jump to 0xf000:0xfff0 instead of 0xffff:0x0.

2003-11-16T18:24:23Z

While we end up the same place, we end up with two different CS register values after the jump and 0xf000 is compatible with the hardware reset value. This makes a difference if the BIOS does a near jump before a far jump. Detective work and patch by: Adrian Steinmann

MFi386: revision 1.13.

2003-11-15T12:25:47Z

Changed the RB_PAUSE flag from 0x40000 to 0x100000 and marked the old

2003-11-15T10:04:06Z

value as reserved for internal use in boot blocks, because RB_PAUSE broke binary compatibility by usurping the RB_DUAL flag. Probably no one except me has boot blocks for which this matters, since most boot blocks based on biosboot including pc98's boot2 can't boot elf kernels, and /boot/loader doesn't properly pass flags set by the previous stage. reboot.h: Also mark the historical RB_PROBEKBD flag (0x80000) as reserved for internal use in boot blocks. boot2.c: Added comments to inhibit usurping of other flags. Approved by: guido, imp MFC after: 1 week

Set RB_SERIAL in boothowto if the firmware output-device is ttya or ttyb.

2003-11-11T18:01:44Z

This ensures that uart gets a higher console priority than syscons when a serial console is being used. Testing against the "console" environment variable doesn't make sense since we only have one loader console driver.