I created and tested this with a custom FreeSBIE cd-image.
PR: i386/96452
Submitted by: Yuichiro Goto <y7goto at gmail dot com>
MFC after: 3 days
Approved by: imp (mentor)
rather than treating them as a fatal exception and halting. At least one
storage BIOS (some newer mpt(4) parts) have a breakpoint instruction in
their disk read routine.
MFC after: 3 days
1. Make libefi portable by removing ia64 specific code and build
it on i386 and amd64 by default to prevent regressions. These
changes include fixes and improvements over previous code to
establish or improve APIs where none existed or when the amount
of kluging was unacceptably high.
2. Increase the amount of sharing between the efi and ski loaders
to improve maintainability of the loaders and simplify making
changes to the loader-kernel handshaking in the future.
The version of the efi and ski loaders are now both changed to 1.2
as user visible improvements and changes have been made.
to get the physical address doesn't work for all values of KVA_PAGES,
while masking 8 MSBs works for all values of KVA_PAGES that are
multiple of 4 for non-PAE and 8 for PAE. (This leaves us limited
with 12MB for non-PAE kernels and 14MB for PAE kernels.)
To get things right, we'd need to subtract the KERNBASE from the
virtual address (but KERNBASE is not easy to figure out from here),
or have physical addresses set properly in the ELF headers.
Discussed with: jhb
device (kind) specific unit field to the common field. This change
allows a future version of libefi to work without requiring anything
more than what is defined in struct devdesc and as such makes it
possible to compile said version of libefi for different platforms
without requiring that those platforms have identical derivatives
of struct devdesc.
are no longer limited to a virtual address space of 16 megabytes,
only mask high two bits of a virtual address. This allows to load
larger kernels (up to 1 gigabyte). Not masking addresses at all
was a bad idea on machines with less than >3G of memory -- kernels
are linked at 0xc0xxxxxx, and that would attempt to load a kernel
at above 3G. By masking only two highest bits we stay within the
safe limits while still allowing to boot larger kernels.
(This is a safer reimplmentation of sys/boot/i386/boot2/boot.2.c
rev. 1.71.)
Prodded by: jhb
Tested by: nyan (pc98)
Massive update. The highlights:
o dramatically cut memory usage by writing better, less intertwingled
code.
o implement booting off mmc/sd cards (sd only tested one at the moment)
o start to split out board specific stuff for boot2.
commits. For some reason I thought the scale factor was a shift count
rather than the multiplicand (that is, I thought leal (%eax,%edx,4) was
going to generate %eax + %edx << 4 rather than %eax + %edx * 4). What
I need is to multiply by 16 to convert a real-mode (seg, offset) tuple
into a flat address. However, the max multiplicand for scaled/index
addressing on i386 is 8, so go back to using a shl and an add.
- Convert two more inter-register mov instructions where we don't need to
preserve the source register to xchg instructions to keep our space
savings.
Tested by: Ian FREISLICH if at hetzner.co.za
MFC after: 1 week
another 16 bytes off of BTX (and thus boot2):
- Compare against the value of %eax that is saved on the stack instead of
loading it into %eax (which requires saving the current %eax on the
stack).
- Use %ch to examine the keyboard flag state in the BIOS to see if
Ctrl-Alt-Del is pressed instead of %al so we don't have to save %eax on
the stack anymore.
MFC after: 1 week
BTX (and thus boot2):
- Don't bother saving %eax, %ebx, or %ecx as it is not necessary.
- Use a more compact sequence to load the base value out of a GDT entry
by loading the contiguous low 24 bits into the upper 24 bits of %eax,
loading the high 8 bits into %al, and using a ror to rotate the bits
(2 mov's and a ror) rather than loading the pieces in smaller chunks
(3 mov's and a shl).
- Use movzwl + leal instead of movl + movw + shll + addl.
- Use 'xchgl %eax,%foo' rather than 'movl %eax,%foo' for cases where
it's ok to trash %eax. xchgl %eax, foo is a 1-byte opcode whereas the
mov is a 2-byte opcode.
- Use movzwl rather than xorl + movw.
MFC after: 1 week
rather than just emulating mov cr0, eax. This fixes some Compaq/HP BIOS
with DMA (as the BIOS tried to read cr3 so it could translate addresses
if paging was enabled).
MFC after: 1 week
sync() and sync_fsync() without losing MNT_ASYNC. Add MNTK_ASYNC flag
which is set only when MNT_ASYNC is set and mnt_noasync is zero, and
check that flag instead of MNT_ASYNC before initiating async io.
- Make the PROBE_KEYBOARD option better resemble the -P option in
boot2, i.e., if keyboard isn't present then boot with both
RB_SERIAL and RB_MULTIPLE set.
Reviewed by: jhb
8k boundary with this program still.
text data bss dec hex filename
7925 4 4476 12405 3075 bootiic.out
so we have like 293 bytes left before we have to play games. There
may be ways to reduce that somewhat, but they start to be very board
specific.
changes in the future. This helps with getting started and to
overcome the really sucky level of granuality this timeout has in
getc. A timeout of 1 means 'wait until top of next second' rather
than 'wait for at least a second'.
fixes filesystem corruption when nextboot.conf is located after
cylinder 1023. The bug appears to have been introduced at the time
bd_read was copied to create bd_write.
PR: bin/98005
Reported by: yar
MFC after: 1 week
selection and not always beeping on startup. The two bytes for the extra
'jmp' instruction were obtained by removing recognition of BSD/OS
partitions.
Requested by: many
Tested by: subset of many
Head nod: imp, keramida
MFC after: 2 weeks
Make this compile, assuming that you have linux installed in a
sensible place. tag_list is disabled by default, since we don't
distribute linux, but it is desirable to allow the boot loader to boot
Linux or FreeBSD (mostly for testing).
xmodem download. Then download the image you want in the flash.
This will burn the image into the flash. You must then reset the
unit and the new flash image will be used for booting...
xmodem download. Then download the image you want in the eeprom.
This will burn the image into the eeprom. You must then reset the
unit and the new eeprom image will be used for booting...
o Use a directory layout that is more akin to the i386 boot layout.
o Create a libat91 for library routines that are used by one or more
of the boot loaders.
o Create bootiic for booting from an iic part.
o Create bootspi for booting from an spi part.
o Optimize the size of many of these routines (especially emac.c). Except
for the emac.c optimizations, all these have been tested.
o eliminate the inc directory, libat91 superceeds it.
o Move linker.cfg up a layer to allow it to be shared.
For 32-bit SDRAM systems, enable D16 to D31 in the PIO controller.
Otherwise they read back as 0xffff.
Shave 8 bytes from the object size by using AT91C_BASE_PIOA directly
and by not assigning PIO_BSR to 0 in the DBGU init. That's a nop in
two ways (everything defaults to peripheral A, and writing 0 changes
nothing).
Many places used #define FOO ((unsigned int) 0x23) where a simpler
#define FOO 0x23u would have sufficed. This practice is overly
verbose and has the disadvantage that you can't say
#if FOO == BAR
#endif
because the extra "unsigned int" tokens choke cpp's little brain.
Migrate to the latter style to allow use in preprocessor statements.
The two are the same semantically anyway in a C context (at least for
the uses they are put to presently, C gurus can explain to me how they
differ).
via xmodem to the DBGU port when the AT91 comes up in recovery mode.
The recovery loader will then load your program via xmodem into SDRAM
at 1MB which can do its things. It needs to be tweaked to the
specific board one is using, but it fits in < 1kB (all of Atmel's ARM
products have at least 8kb of SRAM that I can tell, so this should
work for them all).
Parts of this code were provided by Kwikbyte with copyright
specifically disclaimed. I heavily modified it to act as a recovery
loader (before it was a bootstrap loader) and to optimize for size
(before I started the size was closer to 8k).
Bootstrap loaders for SPI and IIC to follow.
Otherwise, we could match on a filename that had the wrong last character
(such as /boot/loaded instead of /boot/loader).
PR: kern/95625
Submitted by: Oliver Fromme <olli@secnetix.de>
MFC after: 1 month
controller to get ready (65K x ISA access time, visually around 1 second).
If we have wait more than that amount it's likely that the hardware is a
legacy-free one and simply doesn't have keyboard controller and doesn't
require enabling A20 at all.
This makes cdboot working for MacBook Pro with Boot Camp.
MFC after: 1 day
Use 'BOOT_SENSITIVE_INFO=YES' variable to turn them on.
- Use 'uint*_t' instead of 'u_int*_t', correct compilation warnings, and
update copyright while I am here.
when checking whether it's greater than a struct stat st_size in order
to also catch the case when st_size is -1. Previously this check didn't
trigger on sparc64 when st_size is -1 (as it's the case for a file on
a bzipfs, TFTP server etc.), causing the content of the linker hints
file to be copied to memory referenced by a null-pointer.
PR: 91231
MFC after: 1 week
3MB of physical memory for heap instead of range between 1MB and 4MB.
This makes this feature working with PAE and amd64 kernels, which are
loaded at 2MB. Teach i386_copyin() to avoid using range allocated by
heap in such case, so that it won't trash heap in the low memory
conditions.
This should make loading bzip2-compressed kernels/modules/mfs images
generally useable, so that re@ team is welcome to evaluate merits
of using this feature in the installation CDs.
Valuable suggestions by: jhb
provide enough room for decompression (up to 2.5MB is necessary). This
should be safe to do since we load i386 kernels after 8MB mark now, so
that 16MB is the minimum amount of RAM necessary to even boot FreeBSD.
This makes bzip2-support practically useable.
memory directly available to loader(8) and friends was limited to 640K on i386.
Those times have passed long time ago and now loader(8) can directly access
up to 4GB of RAM at least theoretically. At the same time, there are several
places where it's assumed that malloc() will only allocate memory within
first megabyte.
Remove that assumption by allocating appropriate bounce buffers for BIOS
calls on stack where necessary.
This allows using memory above first megabyte for heap if necessary.
means:
o Remove Elf64_Quarter,
o Redefine Elf64_Half to be 16-bit,
o Redefine Elf64_Word to be 32-bit,
o Add Elf64_Xword and Elf64_Sxword for 64-bit entities,
o Use Elf_Size in MI code to abstract the difference between
Elf32_Word and Elf64_Word.
o Add Elf_Ssize as the signed counterpart of Elf_Size.
MFC after: 2 weeks
devices can be opened multiple times simultaneously but we're
expected to be able to do so by the rest of the loader.
This fixes booting from disks attached to the on-board SCSI
controller of Sun Ultra 1 (previously this triggered a trap)
and probably also of AX1115 boards.
- While here, remove unused variables and add empty lines where
style(9) requires such.
Tested on: powerpc (grehan), sparc64
MFC after: 1 month
> Cause all flags passed by boot2 to set the respective loader(8)
> boot_* variable. The end effect is that all flags from boot2
> are now passed to the kernel.
the serial console speed (i386 and amd64 only). If the previous
stage boot loader requested a serial console (RB_SERIAL or RB_MULTIPLE)
then the default speed is determined from the current serial port
speed. Otherwise it is set to 9600 or the value of BOOT_COMCONSOLE_SPEED
at compile time.
This makes it possible to set the serial port speed once in
/boot.config and the setting will propagate to boot2, loader and
the kernel serial console.
/boot.config or on the "boot:" prompt line via a "-S<speed>" flag,
e.g. "-h -S19200". This adds about 50 bytes to the size of boot2
and required a few other small changes to limit the size impact.
This changes only affects boot2; there are further loader changes
to follow.
which serial device to use in that case respectively to not rely on
the OFW names of the input/output and stdin/stdout devices. Instead
check whether input and output refers to the same device and is of
type serial (uart(4) was already doing this) and for the fallback
to a serial console in case a keyboard is the selected input device
but unplugged do the same for stdin and stdout in case the input
device is nonexistent (PS/2 and USB keyboards) or has a 'keyboard'
property (RS232 keyboards). Additionally also check whether the OFW
did a fallback to a serial console in the same way in case the
output device is nonexistent. While at it save on some variables
and for sys/boot/sparc64/loader/metadata.c move the code in question
to a new function md_bootserial() so it can be kept in sync with
uart_cpu_getdev_console() more easily.
This fixes selecting a serial console and the appropriate device
when using a device path for the 'input-device' and 'output-device'
OFW environment variables instead of an alias for the serial device
to use or when using a screen alias that additionally denotes a
video mode (like e.g. 'screen:r1024x768x60') but no keyboard is
plugged in (amongst others). It also makes the code select a serial
console in case the OFW did the same due to a misconfiguration like
both 'input-device' and 'output-device' set to 'keyboard' or to a
nonexisting device (whether the OFW does a fallback to a serial
console in case of a misconfiguration or one ends up with just no
console at all highly depends on the OBP version however).
- Reduce the size of buffers that only ever need to hold the string
'serial' accordingly. Double the size of buffers that may need to
hold a device path as e.g. '/pci@8,700000/ebus@5/serial@1,400000:a'
exceeds 32 chars.
- Remove the package handle of the '/options' node from the argument
list of uart_cpu_getdev_dbgport() as it's unused there and future
use is also unlikely.
MFC after: 1 week
from OpenFirmware be 16 pages to avoid fragmentation in the list
of mappings returned when the kernel requests it in pmap_bootstrap.
This allows a static buffer to be used when obtaining the existing
mappings - very useful on the G5 when random physical pages can't
be grabbed because they can't be BAT-mapped.
MFC after: 3 days
variables to loader:
hint.smbios.0.enabled "YES" when SMBIOS is detected
hint.smbios.0.bios.vendor BIOS vendor
hint.smbios.0.bios.version BIOS version
hint.smbios.0.bios.reldate BIOS release date
hint.smbios.0.system.maker System manufacturer
hint.smbios.0.system.product System product name
hint.smbios.0.system.version System version number
hint.smbios.0.planar.maker Base board manufacturer
hint.smbios.0.planar.product Base board product name
hint.smbios.0.planar.version Base board version number
hint.smbios.0.chassis.maker Enclosure manufacturer
hint.smbios.0.chassis.version Enclosure version
These strings can be used to detect hardware quirks and to set appropriate
flags. For example, Compaq R3000 series and some HP laptops require
hint.atkbd.0.flags="0x9"
to boot. See amd64/67745 for more detail.
Note: Please do not abuse this feature to resolve general problem when it
can be fixed programmatically. This must be used as a last resort.
PR: kern/81449
Approved by: anholt (mentor)
and visible effect of the bug what that autoboot would boot a kernel
after only a couple of seconds had passed instead of waiting the
full 10 seconds it's supposed to wait by default.
Add my copyright notice, since one was missing and I reimplemented
the one and only function in this file.
MFC after: 1 week
- Teach the i386 and pc98 loaders to honor multiple console requests from
their respective boot2 binaries so that the same console(s) are used in
both boot2 and the loader.
- Since the kernel doesn't support multiple consoles, whichever console is
listed first is treated as the "primary" console and is passed to the
kernel in the boot_howto flags.
PR: kern/66425
Submitted by: Gavin Atkinson gavin at ury dot york dot ac dot uk
MFC after: 1 week
be assumed that modules are contiguous in memory (they're not)
so don't blindly __syncicache start/end. In fact, don't bother
syncing the icache for modules since the kernel will do it after
fixing up relocations.
This fixes the trap when loading modules at boot time.
Reported by: orlando at break dot net
user to interrupt autoboot process at all. Currently, even when
`autoboot_delay' is set to 0, loader(8) still allows autoboot process to be
interrupted by pressing any key on the console when the loader reads kernel
and modules from the disk. In some cases (i.e. untrusted environment) such
behaviour is highly indesirable and user should not be allowed to interfere
with the autoboot process at all.
Sponsored by: PBXpress Inc.
MFC after: 3 days
copying, rather than a page at a time. This was creating far
too many single-page mappings, and eventually OFW overflowed
some internal data structure and refused to map any more.
The new algorithm creates far less mappings and fixed a bug
where multiple mappings for the same page would be created.
'Twas known this was a problem, but only became urgent when the
install CD's mfs_root grew large enough to cause the overflow.
- Move MD files into <arch>/<arch>.
- Move bus dependent files into <arch>/<bus>.
Rename some files to more suitable names.
Repo-copied by: peter
Discussed with: imp
I think all we really need is -fno-sse2.
I really don't like cluttering up the compiler invocation,
but this bigger hammer will fix reported problems for now.
to stll be able to mount NFS root as prescribed by DCHP configuration. Since
pxeboot is using TFTP to get to the files, pxeboot can not rely on NFS to
provide it a root directory hande as a side effect. pxeboot has to make RPC
mount call itself.
place.
This moves the dependency on GCC's and other compiler's features into
the central sys/cdefs.h file, while the individual source files can
then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to
refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42.
By now, GCC and ICC (the Intel compiler) have been actively tested on
IA32 platforms by netchild. Extension to other compilers is supposed
to be possible, of course.
Submitted by: netchild
Reviewed by: various developers on arch@, some time ago
they would leave enough elements on the stack that if you escaped to the
loader prompt and then typed 'setenv', it would pull in all of the leaked
junk and cause an exception in the environment. There still seems to be
3 leaked elements, but they don't appear to be coming from this file.
