#
e9ac4169 |
| 15-Jul-2024 |
Warner Losh <imp@FreeBSD.org> |
Remove residual blank line at start of Makefile
This is a residual of the $FreeBSD$ removal.
MFC After: 3 days (though I'll just run the command on the branches) Sponsored by: Netflix
|
Revision tags: release/14.1.0, release/13.3.0, release/14.0.0 |
|
#
4722ceb7 |
| 17-Aug-2023 |
Ed Maste <emaste@FreeBSD.org> |
Use 115200 bps by default for serial communication
9600 was a standard baud rate decades ago, but 115200 is now more common so choose defaults that are useful to the largest number of users.
Note t
Use 115200 bps by default for serial communication
9600 was a standard baud rate decades ago, but 115200 is now more common so choose defaults that are useful to the largest number of users.
Note that boot0sio does not support rates above 9600 so it remains unchanged.
Reviewed by: bz, imp, manu Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D36295
show more ...
|
#
d0b2dbfa |
| 16-Aug-2023 |
Warner Losh <imp@FreeBSD.org> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0, release/13.0.0 |
|
#
c8c62548 |
| 22-Mar-2021 |
Alex Richardson <arichardson@FreeBSD.org> |
Don't add -Winline for WARNS=6
This warning is very rarely useful (inline is a hint and not mandatory). This flag results in many warnings being printed when compiling C++ code that uses the standar
Don't add -Winline for WARNS=6
This warning is very rarely useful (inline is a hint and not mandatory). This flag results in many warnings being printed when compiling C++ code that uses the standard library with GCC.
This flag was originally added in back in r94332 but the flag is a no-op in Clang ("This diagnostic flag exists for GCC compatibility, and has no effect in Clang"). Removing it should make the GCC build output slightly more readable.
Reviewed By: jrtc27, imp Differential Revision: https://reviews.freebsd.org/D29235
show more ...
|
Revision tags: release/12.2.0, release/11.4.0 |
|
#
fac6dee9 |
| 12-May-2020 |
Eric van Gyzen <vangyzen@FreeBSD.org> |
Remove tests for obsolete compilers in the build system
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree. Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions f
Remove tests for obsolete compilers in the build system
Assume gcc is at least 6.4, the oldest xtoolchain in the ports tree. Assume clang is at least 6, which was in 11.2-RELEASE. Drop conditions for older compilers.
Reviewed by: imp (earlier version), emaste, jhb MFC after: 2 weeks Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D24802
show more ...
|
#
e43d33d2 |
| 05-Mar-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Merge ^/head r358466 through r358677.
|
#
a2037dba |
| 04-Mar-2020 |
Dimitry Andric <dim@FreeBSD.org> |
Link stand/i386 components using a linker script
LLD 10.0.0 changed the behavior of the -Ttext option, so that using -Ttext=0x0 now causes linking of the loaders to fail with:
ld: error: output fil
Link stand/i386 components using a linker script
LLD 10.0.0 changed the behavior of the -Ttext option, so that using -Ttext=0x0 now causes linking of the loaders to fail with:
ld: error: output file too large: 18446744073707016908 bytes
I reported this in https://bugs.llvm.org/show_bug.cgi?id=44715, and initially reverted the upstream change in r357259 to work around it.
However, after some discussion with Fangrui Song in the upstream ticket, I think we can classify this as an unfortunate interaction between using -Ttext=0 in combination with --no-rosegment. (We added the latter in r332090, because btxld does not correctly handle input with more than 2 PT_LOAD segments.)
Fangrui suggested to use a linker script instead, and Warner was already attempting this in r305353, but had to revert it due to "crypto-using boot problems" (not sure what those were :).
This review updates the stand/i386/boot.ldscript to handle more sections, inserts some symbols like _edata and such that we use in libsa, and also discards any .interp section.
It uses ORG which is defined on the linker command line using --defsym ORG=value to set the start of all the sections.
Reviewed by: imp MFC after: 2 weeks Differential Revision: https://reviews.freebsd.org/D23952
show more ...
|
#
ca251958 |
| 04-Mar-2020 |
Toomas Soome <tsoome@FreeBSD.org> |
loader: crc32 is provided by libsa
Seems like leftover from moving crc32.c to libsa.
|
Revision tags: release/12.1.0, release/11.3.0, release/12.0.0 |
|
#
fdcfd483 |
| 20-Jul-2018 |
Warner Losh <imp@FreeBSD.org> |
NM and OBJCOPY are already defined for all builds. There's no need to conditionally define them here.
|
#
c1418270 |
| 13-Jul-2018 |
Ian Lepore <ian@FreeBSD.org> |
Extend loader(8) geli support to all architectures and all disk-like devices.
This moves the bulk of the geli support from lib386/biosdisk.c into a new geli/gelidev.c which implements a devsw-type d
Extend loader(8) geli support to all architectures and all disk-like devices.
This moves the bulk of the geli support from lib386/biosdisk.c into a new geli/gelidev.c which implements a devsw-type device whose dv_strategy() function handles geli decryption. Support for all arches comes from moving the taste-and-attach code to the devopen() function in libsa.
After opening any DEVT_DISK device, devopen() calls the new function geli_probe_and_attach(), which will "attach" the geli code to the open_file struct by creating a geli_devdesc instance to replace the disk_devdesc instance in the open_file. That routes all IO for the device through the geli code.
A new public geli_add_key() function is added, to allow arch/vendor-specific code to add keys obtained from custom hardware or other sources.
With these changes, geli support will be compiled into all variations of loader(8) on all arches because the default is WITH_LOADER_GELI.
Relnotes: yes Sponsored by: Microchip Technology Inc Differential Revision: https://reviews.freebsd.org/D15743
show more ...
|
Revision tags: release/11.2.0 |
|
#
62bd02ce |
| 18-Jun-2018 |
Warner Losh <imp@FreeBSD.org> |
stand: move libgeliboot into libsa.
Reduce by 1 the number of crazy libraries we need in stand by moving geli into libsa (where architecturally it belonged all along). This just moves things around
stand: move libgeliboot into libsa.
Reduce by 1 the number of crazy libraries we need in stand by moving geli into libsa (where architecturally it belonged all along). This just moves things around without any code changes.
show more ...
|
#
073193ed |
| 31-May-2018 |
Dimitry Andric <dim@FreeBSD.org> |
Fix build of stand with base gcc
* Make autoboot() a static function in stand/common/boot.c, so it does not shadow local variables in gptboot.c and zfsboot.c. * Remove -Winline from the Makefiles
Fix build of stand with base gcc
* Make autoboot() a static function in stand/common/boot.c, so it does not shadow local variables in gptboot.c and zfsboot.c. * Remove -Winline from the Makefiles for gptboot, gptzfsboot and zfsboot, as gcc will always fail to inline some functions, and there is nothing we can do about it. * For gcc <= 4.2.1, silence -Wuninitialized for isoboot, as it produces a false positive warning. * Remove deprecated and unnecessary -mcpu=i386 flag from stand/defs.mk, as there is already a -march=i386 flag further in the file.
Reviewed by: imp MFC after: 3 days Differential Revision: https://reviews.freebsd.org/D15628
show more ...
|
#
7acb51f6 |
| 05-Apr-2018 |
Benno Rice <benno@FreeBSD.org> |
Add isoboot(8) for booting BIOS systems from HDDs containing ISO images.
This is part of a project for adding the ability to create hybrid CD/USB boot images. In the BIOS case when booting from some
Add isoboot(8) for booting BIOS systems from HDDs containing ISO images.
This is part of a project for adding the ability to create hybrid CD/USB boot images. In the BIOS case when booting from something that isn't a CD we need some extra boot code to actually find our next stage (loader) within an ISO9660 filesystem. This code will reside in a GPT partition (similar to gptboot(8) from which it is derived) and looks for /boot/loader in an ISO9660 filesystem on the image.
Reviewed by: imp Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D14914
show more ...
|