check for keystroke (int 16h, AH=01h) before getting keystroke (int 16h,
AH=00h), fixes bootloader keyboard input with Apple firmware, from Taylor R
Campbell
file-systems can be critical for mountroot; as kernel cannot have access
to module(7)s without having / mounted first... yes, you see the point.
See http://mail-index.netbsd.org/port-i386/2011/02/11/msg002323.html
XXX Hopefully, /stand does not reside in a separate partition :o
remove drm drivers, we don't need them for install.
i386 GENERIC has FFS and ELF support compiled as modules, so we hit
an interesting "chicken-egg" situation when the kernel attempts to mount
a ffs ramdisk, while the module might be contained inside... the ramdisk.
Interesting scenario: my netbsd-INSTALL.gz testing involved a QEMU image
which already contained an installed system, including modules. So the
bootloader was able to get the ffs.kmod, and lead to a successful mount
of the ramdisk.
Caught off-guard by gson@ automated builds... Erf. My fondest apologies.
Lesson learnt. Hopefully, this will unbreak the floppy install.
Waiting for the release build to finish...
Reasons being:
- INSTALL is GENERIC with an embedded ramdisk, and as such, can benefit from
features included within.
- INSTALL_FLOPPY has its own config(5) file, and is tailored for "small"
floppy images; it misses features/drivers that could be needed to boot
in a decent environment for recent x86 machines (like ACPI)
- makes it closer to floppies distrib available for amd64
While here, comment out INSTALL_FLOPPY and bootfloppy-big image build. NetBSD
does not use the 3.6MiB image for El Torito cdroms anymore.
Remove the FLOPPYMAX limit; i386 needs 4 floppies now. Modify boot.cfg and
release/contents to reflect reality.
See http://mail-index.netbsd.org/port-i386/2011/02/08/msg002307.html
No comments, no objections.
video mode. "vesa on" will now select the preferred mode @ 8bpp if it can
be determined and is supported by the display adapter, otherwise it will
use 640x480 @ 8bpp.
copyright. Confirmed by Mike Hibler, mike at cs.utah.edu - thanks!
Also, merge UCB and Utah copyright texts back into one, as they
originally were.
Extra verification by snj@.
as found in the vortex86 SoCs (http://www.vortex86dx.com).
Ported from freebsd.
Not added to amd64's GENERIC because this CPU is 32bit only.
thanks to DM&P Electronics, Inc for providing documentation and sample
devices for this work.
disabled by -D) from the output of newvers_stand.sh. Change -D to the
inverted logic, so that it adds the date to bootprog_rev in ().
Change all platforms accordingly. -D is added if MKREPRO is not yes and
wasn't present before. Platforms that didn't use -D don't depend on
MKREPRO now either.
Honour this for dependency processing in bsd.dep.mk. Switch i386 and
amd64 assembly to use ISO C90 preprocessor concat and drop the
-traditional-cpp on this platform.
we don't overwrite valid data when moving the symbol and string
tables.
Assume for instance that the boot-loader left us with:
+--------------+ +--------+ +--------------+
| string table | | kernel | | symbol table |
+--------------+ +--------+ +--------------+
The new addresses computed by lines 338-359 (here, it's really
lines 344-345) will move the tables so that they end up as:
+--------+--------------+--------------+
| kernel | symbol table | string table |
+--------+--------------+--------------+
The current version (rev. 1.20) will, however, first copy the
string table and then the symbol table. But the copy of the
string table will overwrite the symbol table (see the pictures).
The old code (rev. 1.19) uses the right order of table copy to
make sure that we don't overwrite one table when moving the
other. Here, we simply restore this behavior. This makes
multibooting from GRUB2 work again (for MONOLITHIC).
ok jmcneill@
A similar change was made in v1.38 of Makefile.bootxx about 13 months ago,
no reason these shouldn't be consistent with each other, like they were before.
libsa-based program. As such, build bootxx_cd9660 where its source lives.
This has been done by moving bootxx/bootxx_cd9660/Makefile to cdboot/Makefile
and adjusting the relative paths appropriately, so as to minimize binary change.
