A 32-bit libstand is needed on 64-bit platforms for use by various
bootloaders. Previously only the 32-bit version was built, installed as
/usr/lib/libstand.a.
A new 64-bit libstand consumer will arrive in the near future, so move
the bootloader-specific 32-bit version to sys/boot/libstand32/.
Explicitly link against this version in the 32-bit loaders.
Sponsored by: The FreeBSD Foundation
Hetzel <swhetzel@gmail.com> on the -doc mailing list.
Also modify the Author section to be clear that I wrote the man page,
not gptboot.
MFC after: 3 days
directly to the linker (LD_FLAGS) from flags passed indirectly, via the
compiler driver (LDFLAGS).
This is because several Makefiles under sys/boot/i386 and sys/boot/pc98
use ${LD} directly to link, and the normal LDFLAGS value should not be
used in these cases.
MFC after: 3 days
in gpart(8) and boot(8), adding references to gptboot(8) in both.
Reviewed by: jhb, ae, pjd, Paul Schenkeveld <bsdcan@psconsult.nl>, david_a_bright@dell.com (portions), gjb
MFC after: 1 week
get rid of testing explicitly for clang (using ${CC:T:Mclang}) in
individual Makefiles.
Instead, use the following extra macros, for use with clang:
- NO_WERROR.clang (disables -Werror)
- NO_WCAST_ALIGN.clang (disables -Wcast-align)
- NO_WFORMAT.clang (disables -Wformat and friends)
- CLANG_NO_IAS (disables integrated assembler)
- CLANG_OPT_SMALL (adds flags for extra small size optimizations)
As a side effect, this enables setting CC/CXX/CPP in src.conf instead of
make.conf! For clang, use the following:
CC=clang
CXX=clang++
CPP=clang-cpp
MFC after: 2 weeks
gpt and zfs boot blocks are not nearly as size-constrained as boot2
from which they inherited their current optimization and anti-optimization
options. As such the current options do not provide any benefit, but
make debugging of the code much harder.
Also, it has been demonstrated that combination of -mrtd and
-fno-unit-at-a-time may result in mis-compilation of the boot code
with the current base gcc.
Additionally, intermediate assembly file filtering is removed for
zfsboot.
The new boot blocks are all compile- and boot- tested using qemu.
gptzfsboot is tested with real hardware.
Reported by: Peter Jeremy <peterjeremy@acm.org> [miscompilation]
Discussed with: bde, jhb
Tested by: Sebastian Chmielewski <chmielsster@gmail.com> [gptzfsboot]
Approved by: re (kib)
MFC after: 3 weeks
It used to choke on the notation "inb (%dx),%al" for "inb %dx,%al"; GNU
as accepts both forms. Which notation is more 'correct' is an open
question. :)
clean up most layering violations:
sys/boot/i386/common/rbx.h:
RBX_* defines
OPT_SET()
OPT_CHECK()
sys/boot/common/util.[ch]:
memcpy()
memset()
memcmp()
bcpy()
bzero()
bcmp()
strcmp()
strncmp() [new]
strcpy()
strcat()
strchr()
strlen()
printf()
sys/boot/i386/common/cons.[ch]:
ioctrl
putc()
xputc()
putchar()
getc()
xgetc()
keyhit() [now takes number of seconds as an argument]
getstr()
sys/boot/i386/common/drv.[ch]:
struct dsk
drvread()
drvwrite() [new]
drvsize() [new]
sys/boot/common/crc32.[ch] [new]
sys/boot/common/gpt.[ch] [new]
- Teach gptboot and gptzfsboot about new files. I haven't touched the
rest, but there is still a lot of code duplication to be removed.
- Implement full GPT support. Currently we just read primary header and
partition table and don't care about checksums, etc. After this change we
verify checksums of primary header and primary partition table and if
there is a problem we fall back to backup header and backup partition
table.
- Clean up most messages to use prefix of boot program, so in case of an
error we know where the error comes from, eg.:
gptboot: unable to read primary GPT header
- If we can't boot, print boot prompt only once and not every five
seconds.
- Honour newly added GPT attributes:
bootme - this is bootable partition
bootonce - try to boot from this partition only once
bootfailed - we failed to boot from this partition
- Change boot order of gptboot to the following:
1. Try to boot from all the partitions that have both 'bootme'
and 'bootonce' attributes one by one.
2. Try to boot from all the partitions that have only 'bootme'
attribute one by one.
3. If there are no partitions with 'bootme' attribute, boot from
the first UFS partition.
- The 'bootonce' functionality is implemented in the following way:
1. Walk through all the partitions and when 'bootonce'
attribute is found without 'bootme' attribute, remove
'bootonce' attribute and set 'bootfailed' attribute.
'bootonce' attribute alone means that we tried to boot from
this partition, but boot failed after leaving gptboot and
machine was restarted.
2. Find partition with both 'bootme' and 'bootonce' attributes.
3. Remove 'bootme' attribute.
4. Try to execute /boot/loader or /boot/kernel/kernel from that
partition. If succeeded we stop here.
5. If execution failed, remove 'bootonce' and set 'bootfailed'.
6. Go to 2.
If whole boot succeeded there is new /etc/rc.d/gptboot script coming
that will log all partitions that we failed to boot from (the ones with
'bootfailed' attribute) and will remove this attribute. It will also
find partition with 'bootonce' attribute - this is the partition we
booted from successfully. The script will log success and remove the
attribute.
All the GPT updates we do here goes to both primary and backup GPT if
they are valid. We don't touch headers or partition tables when
checksum doesn't match.
Reviewed by: arch (Message-ID: <20100917234542.GE1902@garage.freebsd.pl>)
Obtained from: Wheel Systems Sp. z o.o. http://www.wheelsystems.com
MFC after: 2 weeks
gptzfsboot. I got the segment and offset fields reversed in the structure,
but I also succeeded in crossing the assignments so the actual EDD packet
ended up correct.
MFC after: 1 week
set the %eflags used during a BIOS call via BTX to 0x202. Previously
the flags field was uninitialized garbage, and thus it was "random" if
interrupts were enabled or not during BIOS calls.
- Use constants from <machine/psl.h> for fields in %eflags.
MFC after: 3 days
weren't displayed on the new console. However, the config string has been
altered as part of being parsed so we only display the first option. Fix
this by saving a copy of /boot.config before parsing it and displaying the
saved copy after parsing.
MFC after: 1 week
PR: i386/103972
Submitted by: Alexandre Belloni alexandre.belloni of netasq.com
defined. This lets each boot program choose which version of cgbase() it
wants to use rather than forcing ufsread.c to have that knowledge.
MFC after: 1 week
Discussed with: imp
on i386 and amd64 machines. The overall process is that /boot/pmbr lives
in the PMBR (similar to /boot/mbr for MBR disks) and is responsible for
locating and loading /boot/gptboot. /boot/gptboot is similar to /boot/boot
except that it groks GPT rather than MBR + bsdlabel. Unlike /boot/boot,
/boot/gptboot lives in its own dedicated GPT partition with a new
"FreeBSD boot" type. This partition does not have a fixed size in that
/boot/pmbr will load the entire partition into the lower 640k. However,
it is limited in that it can only be 545k. That's still a lot better than
the current 7.5k limit for boot2 on MBR. gptboot mostly acts just like
boot2 in that it reads /boot.config and loads up /boot/loader. Some more
details:
- Include uuid_equal() and uuid_is_nil() in libstand.
- Add a new 'boot' command to gpt(8) which makes a GPT disk bootable using
/boot/pmbr and /boot/gptboot. Note that the disk must have some free
space for the boot partition.
- This required exposing the backend of the 'add' function as a
gpt_add_part() function to the rest of gpt(8). 'boot' uses this to
create a boot partition if needed.
- Don't cripple cgbase() in the UFS boot code for /boot/gptboot so that
it can handle a filesystem > 1.5 TB.
- /boot/gptboot has a simple loader (gptldr) that doesn't do any I/O
unlike boot1 since /boot/pmbr loads all of gptboot up front. The
C portion of gptboot (gptboot.c) has been repocopied from boot2.c.
The primary changes are to parse the GPT to find a root filesystem
and to use 64-bit disk addresses. Currently gptboot assumes that the
first UFS partition on the disk is the / filesystem, but this algorithm
will likely be improved in the future.
- Teach the biosdisk driver in /boot/loader to understand GPT tables.
GPT partitions are identified as 'disk0pX:' (e.g. disk0p2:) which is
similar to the /dev names the kernel uses (e.g. /dev/ad0p2).
- Add a new "freebsd-boot" alias to g_part() for the new boot UUID.
MFC after: 1 month
Discussed with: marcel (some things might still change, but am committing
what I have so far)
macros to treat the 'slice' field as a real part of the bootdev instead
of as hack that spans two other fields (adaptor (sic) and controller)
that are not used in any modern FreeBSD boot code.
MFC after: 1 week
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
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)
/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.
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 4.0 and RELENG_3), the BTX mini-kernel used paging rather than flat
mode and clients were limited to a virtual address space of 16 megabytes.
Because of this limitation, boot2 silently masked all physical addresses
in any binaries it loaded so that they were always loaded into the first
16 Meg. Since BTX no longer has this limitation (and hasn't for a long
time), remove the masking from boot2. This allows boot2 to load kernels
larger than about 12 to 14 meg (12 for non-PAE, 14 for PAE).
Submitted by: Sergey Lyubka devnull at uptsoft dot com
MFC after: 1 month
