aboutsummaryrefslogtreecommitdiff
path: root/stand/i386
Commit message (Collapse)AuthorAgeFilesLines
* pxeboot(8): remove antiquated informationGuangyuan Yang2021-02-151-16/+7
| | | | | | | | | | | | | While I was there: - Fix some typos - Fix an excessive argument "indent" reported by mandoc -Tlint - Replace a dead link with the one suggested by https://www.uefi.org/uefi Submitted by: linimon (in part) Reviewed by: bcr MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D27774
* loader: remove BORDER_PIXELSToomas Soome2021-02-091-2/+2
| | | | | | | | BORDER_PIXELS is left over from picking up the source from illumos port. Since FreeBSD VT does not use border in terminal size calculation, there is no reason why should loader use it. MFC after: 1 week
* stand/amd64: remove unused addr parameter from bi_load64Roger Pau Monné2021-02-014-10/+10
| | | | | | | | | | | All callers of bi_load64 pass 0 as the addr parameter, so just remove it and always calculate the last load address from the module chain. No functional change. Sponsored by: Citrix Systems R&D Reviewed by: tsoome, imp Differential revision: https://reviews.freebsd.org/D28412
* stand/multiboot: adjust the protocol between loader and kernelRoger Pau Monné2021-01-291-117/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a currently ad-hoc protocol to hand off the FreeBSD kernel payload between the loader and the kernel itself when Xen is in the middle of the picture. Such protocol wasn't very resilient to changes to the loader itself, because it relied on moving metadata around to package it using a certain layout. This has proven to be fragile, so replace it with a more robust version. The new protocol requires using a xen_header structure that will be used to pass data between the FreeBSD loader and the FreeBSD kernel when booting in dom0 mode. At the moment the only data conveyed is the offset of the start of the module metadata relative to the start of the module itself. This is a slightly disruptive change since it also requires a change to the kernel which is contained in this patch. In order to update with this change the kernel must be updated before updating the loader, as described in the handbook. Note this is only required when booting a FreeBSD/Xen dom0. This change doesn't affect the normal FreeBSD boot protocol. This fixes booting FreeBSD/Xen in dom0 mode after 3630506b9daec9167a89bc4525638ea45a00769e. Sponsored by: Citrix Systems R&D MFC after: 3 days Reviewed by: tsoome Differential Revision: https://reviews.freebsd.org/D28411
* loader: start kernel in text mode when there is no vbefb vt driverToomas Soome2021-01-261-0/+10
| | | | | If kernel is built without VT vbefb driver, make sure we start kernel in text mode.
* loader: create built in font from bold font faceToomas Soome2021-01-231-1/+1
| | | | | We did replace full version of default font 8x16v with bold, also use bold version for built in font.
* loader: handle malloc failures in vbe_init, use consistent namingToomas Soome2021-01-191-16/+24
| | | | | | | | | | | | Handle malloc failures in vbe_init(). If it should so happen and we do get malloc failure in vbe_init(), use original mode list. Replace nitems with nentries to have naming consistency and avoid confusion with nitems() macro. Reported by: yuripv, rpokala
* loader: create local copy of mode list provided by vbeinfoblockToomas Soome2021-01-161-33/+49
| | | | | Apparently some systems do corrupt mode list memory area, so we need to use local copy instead.
* loader: do not update palette in text mode (real fix)Toomas Soome2021-01-151-1/+1
| | | | | | Apparently palette update while in text mode, will cause some adapters to end up with blank display. Previous update had condition reversed.
* loader: term_image_display() should test screen_bufferToomas Soome2021-01-101-0/+3
| | | | Make sure screen_buffer is not NULL.
* loader: do not update palette in text modeToomas Soome2021-01-071-1/+1
| | | | | Apparently palette update while in text mode, will cause some adapters to end up with blank display.
* loader: instead of hw.vga.textmode, use screen.textmodeToomas Soome2021-01-061-6/+5
| | | | | | | | | | | | | hw.vga.textmode is directing VT VGA backend to use text mode. The default screen mode for BIOS loader is text, and default screen mode for VT VGA backend is graphics (unless we are running on hypervisor or hw.vga.textmode is set to 1). Using hw.vga.textmode for loader does remove possibility to have graphical mode VT VGA with text mode loader. screen.textmode can have possible values "0" to disable text mode, and "1" to set text mode.
* loader: remove left over call to unsetenv()Toomas Soome2021-01-061-1/+0
| | | | We do not touch kern.vt.fb.default_mode.
* loader: rewrite vidc_install_fontToomas Soome2021-01-061-32/+34
| | | | | | | | | Instead of trying to set reasonable register values, save significant register values, then prepare for font upload and then restore registers from saved data. This seems to fix text mode for most cases where text mode breakage was reported.
* loader: only use vidc_install_font() with vga controllerToomas Soome2021-01-043-0/+17
| | | | | If the controller does not support VGA, we should not touch VGA registers.
* loader: vidc_load_palette() does not need argumentsToomas Soome2021-01-041-2/+2
| | | | Remove left over argument from vidc_load_palette.
* loader: implement framebuffer consoleToomas Soome2021-01-0210-182/+1916
| | | | | | | | | | | | | | | | | | | | | | | Draw console on efi. Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list, vbe set xxx). autoload font (/boot/fonts) based on resolution and font size. Add command loadfont (set font by file) and variable screen.font (set font by size). Pass loaded font to kernel. Export variables: screen.height screen.width screen.depth Add gfx primitives to draw the screen and put png image on the screen. Rework menu draw to iterate list of consoles to enamble device specific output. Probably something else I forgot... Relnotes: yes Differential Revision: https://reviews.freebsd.org/D27420
* stand: properly declare subdir deps or .WAIT, do parallel buildKyle Evans2020-12-311-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | buildworld already runs the stand build in parallel[1], so make it easier to identify ordering issues by properly establishing dependencies or adding .WAIT where needed. Everything in stand/ relies on libsa, either directly or indirectly, because libsa build is where the stand headers get installed and it gets linked in most places. Interpreters depend on their libs, machine dirs usually depend on top-level libs that are getting built and at least one of the interpreter flavors. For i386, order btx/libi386/libfirewire before everything else using a big-ol-.WAIT hammer. btx is the most common dependency, but the others are used sporadically. This seems to be where the race reporting on the mailing list is- AFAICT, the following sequence is happening: 1.) One of the loaders gets built based on stale btx/btxldr 2.) btx/btxldr gets rebuilt 3.) installworld triggers loader rebuild because btx was rebuilt after This seems like the most plausible explanation, as they've verified system time and timestamps. While we're here, let's switch stand/ over to a completely parallel build so we can work out these kinds of issues in isolation rather than in the middle of a larger build. Reviewed by: bdragon, sjg, tsoome Tested by: bdragon (-j1024, no failures, significant speed improvement) Differential Revision: https://reviews.freebsd.org/D23411
* zfsboot: add prototype for main()Toomas Soome2020-11-151-0/+2
| | | | | | | | | | Some compilers are complaining about missing prototype. PR: 251150 Reported by: markiyan.kushnir@gmail.com Notes: svn path=/head/; revision=367710
* loader: edd_device_path_v3 is too smallToomas Soome2020-10-121-18/+1
| | | | | | | | | | | | | | | The EDD v3[1], see table 13, page 33, does define device path as double qword, that is, 16 bytes, we have only qword. Also remove edd_device_path_v4 and edd_params_v4 because those are not used, and there is no size difference in v3 versus v4. [1] http://www.t13.org/documents/UploadedDocuments/docs2004/d1572r3-EDD3.pdf MFC after: 2 weeks Notes: svn path=/head/; revision=366631
* loader: fix non-zfs buildToomas Soome2020-09-232-1/+3
| | | | | | | | | We can not include zfs headers while building without zfs. Reported by: Oscar Holmlund Notes: svn path=/head/; revision=366087
* Work around cp breakage in current from last weekWarner Losh2020-09-231-1/+1
| | | | | | | | | | | | | | | There was a small window cp was broken. Work around this by using :> instead of cp /dev/null. Ideally, we'd keep the cp /dev/null in the build as a regression test, but doing so breaks people that upgraded during the cp breakage and this is simpler than bootstrapping a working cp since there's no good __FreeBSD_version sign posts for that. Suggested by: lots of people Too stubborn for his own good: imp Notes: svn path=/head/; revision=366042
* loader: zfs should support bootonce an nextbootToomas Soome2020-09-215-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bootonce feature is temporary, one time boot, activated by "bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag. By default, the bootonce setting is reset on attempt to boot and the next boot will use previously active BE. By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will be set permanently active. bootonce dataset name is recorded in boot pool labels, bootenv area. in case of nextboot, the nextboot_enable boolean variable is recorded in freebsd:nvstore nvlist, also stored in boot pool label bootenv area. On boot, the loader will process /boot/nextboot.conf if nextboot_enable is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf processing on next boot. bootonce and nextboot features are usable in both UEFI and BIOS boot. To use bootonce/nextboot features, the boot loader needs to be updated on disk; if loader.efi is stored on ESP, then ESP needs to be updated and for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated (gpart or other tools). At this time, only lua loader is updated. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25512 Notes: svn path=/head/; revision=365938
* When we have a command returned by zfs_nextboot() that is longerGleb Smirnoff2020-08-201-1/+6
| | | | | | | | | | | | | than command in the loader.conf, the latter needs to be nul terminated, otherwise garbage trailer left from zfs_nextboot() will be passed to parse_cmd() together with loader.conf command. While here, reset cmd to empty string if read() returns error. Reviewed by: tsoome Notes: svn path=/head/; revision=364441
* zfs: add an option to the bootloader to rewind the ZFS checkpointMariusz Zaborski2020-08-181-1/+1
| | | | | | | | | | | | | | | | | | The checkpoints are another way of keeping the state of ZFS. During the rewind, the pool has to be exported. This makes checkpoints unusable when using ZFS as root. Add the option to rewind the ZFS checkpoint at the boot time. If checkpoint exists, a new option for rewinding a checkpoint will appear in the bootloader menu. We fully support boot environments. If the rewind option is selected, the boot loader will show a list of boot environments that existed before the checkpoint. Reviewed by: tsoome, allanjude, kevans (ok with high-level overview) Differential Revision: https://reviews.freebsd.org/D24920 Notes: svn path=/head/; revision=364355
* Allow overriding the tool used for stripping binariesAlex Richardson2020-08-111-1/+1
| | | | | | | | | | | | | | | | | | | Since the make variable STRIP is already used for other purposes, this uses STRIPBIN (which is also used for the same purpose by install(1). This allows using LLVM objcopy to strip binaries instead of the in-tree elftoolchain objcopy. We make use of this in CheriBSD since passing binaries generated by our toolchain to elftoolchain strip sometimes results in assertion failures. This allows working around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248516 by specifying STRIPBIN=/path/to/llvm-strip Obtained from: CheriBSD Reviewed By: emaste, brooks Differential Revision: https://reviews.freebsd.org/D25988 Notes: svn path=/head/; revision=364119
* Revert that!Simon J. Gerraty2020-07-191-7/+3
| | | | Notes: svn path=/head/; revision=363351
* Oops missed Makefile.configSimon J. Gerraty2020-07-191-3/+7
| | | | Notes: svn path=/head/; revision=363350
* loader: cstyle cleanupToomas Soome2020-07-191-229/+250
| | | | | | | | | No functional changes intended. Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=363318
* loader: implement GELI writesToomas Soome2020-07-111-1/+1
| | | | | | | | | | | | | Bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247482 This patch is based on initial work from allanjude. PR: 247482 Obtained from: https://reviews.freebsd.org/D10236 Differential Revision: https://reviews.freebsd.org/D25605 Notes: svn path=/head/; revision=363090
* Revert r362466Baptiste Daroussin2020-06-221-2/+2
| | | | | | | | | Such change should not have happen without prior discussion and review. With hat: transitioning core Notes: svn path=/head/; revision=362488
* Improve wording to be more precise and clear.Hans Petter Selasky2020-06-211-2/+2
| | | | | | | | | | | | No functional change intended. s/Master Boot/Main Boot/ (also called MBR) MFC after: 1 week Sponsored by: Mellanox Technologies Notes: svn path=/head/; revision=362466
* loader: create single zfs nextboot implementationToomas Soome2020-06-204-852/+349
| | | | | | | | | | | | | | | | | | | | We should have nextboot feature implemented in libsa zfs code. To get there, I have created zfs_nextboot() implementation based on two sources, our current simple textual string based approach with added structured boot label PAD structure from OpenZFS. Secondly, all nvlist details are moved to separate source file and restructured a bit. This is done to provide base support to add nvlist add/update feature in followup updates. And finally, the zfsboot/gptzfsboot disk access functions are swapped to use libi386 and libsa. Sponsored by: Netflix, Klara Inc. Differential Revision: https://reviews.freebsd.org/D25324 Notes: svn path=/head/; revision=362431
* loader: vidc_init should also erase the screenToomas Soome2020-06-171-5/+2
| | | | | | | | | | | | Inject \e[J to erase the initial loader screen. We have two options, find where out cursor is and use BIOS scroll for data from boot2 or erase the display and start from origin. Erasing the screen is easier and we also get the screen buffer initialized. Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=362259
* boot2: need to expand tab output and mask getcharToomas Soome2020-06-161-2/+28
| | | | | | | | | | The BIOS ouput char function does not expand tab. Mask getchar with 0xFF. Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=362239
* zfsboot: cstyle cleanupToomas Soome2020-06-141-644/+673
| | | | | | | | | No functional changes intended. Sponsored by: Netflix, Klara Inc. Notes: svn path=/head/; revision=362184
* Remove tests for obsolete compilers in the build systemEric van Gyzen2020-05-122-6/+0
| | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=360964
* Avoid using non-portable dd conv=osync optionAlex Richardson2020-05-113-3/+3
| | | | | | | | | | | | The same thing can be achieved using the bs=$SIZE and conv=sync options. Unlike conv=osync, conv=sync is support on both Linux and macOS. Reviewed By: imp, jhb (earlier version) Obtained from: CheriBSD Differential Revision: https://reviews.freebsd.org/D24788 Notes: svn path=/head/; revision=360894
* Stop setting PG_U in bootstrap mappings.Mark Johnston2020-04-241-4/+3
| | | | | | | | | | | | | | These mappings are never visible to userspace as they get replaced when the amd64 pmap is bootstrapped, but there is no need to set PG_U in the first place. Reviewed by: alc, kib MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D24547 Notes: svn path=/head/; revision=360260
* loader: remove libsa/crc32.c and use version from zlibToomas Soome2020-03-192-0/+2
| | | | | | | | | | | | | we have crc32(const void *, size_t) in libsa. Unfortunately zlib has crc32(long, const unigned char *, unsigned) and we have conflict. Since we do build libsa with zlib, we can use zlib version instead. Reviewed by: allanjude Differential Revision: https://reviews.freebsd.org/D24068 Notes: svn path=/head/; revision=359153
* test if port does exist via using scratch registerToomas Soome2020-03-121-0/+10
| | | | | | | | | | | | | | The SCR, scratch register was not present on the 8250 and 8250B UART, so we can use to test if we actually do have serial port. We need this test because some systems will get long delays while attempting to write to non-existing port and this will slow down the console IO to extreme. MFC after: 1 week Notes: svn path=/head/; revision=358906
* veloader use vectx API for kernel and modulesSimon J. Gerraty2020-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vectx API, computes the hash for verifying a file as it is read. This avoids the overhead of reading files twice - once to verify, then again to load. For doing an install via loader, avoiding the need to rewind large files is critical. This API is only used for modules, kernel and mdimage as these are the biggest files read by the loader. The reduction in boot time depends on how expensive the I/O is on any given platform. On a fast VM we see 6% improvement. For install via loader the first file to be verified is likely to be the kernel, so some of the prep work (finding manifest etc) done by verify_file() needs to be factored so it can be reused for vectx_open(). For missing or unrecognized fingerprint entries, we fail in vectx_open() unless verifying is disabled. Otherwise fingerprint check happens in vectx_close() and since this API is only used for files which must be verified (VE_MUST) we panic if we get an incorrect hash. Reviewed by: imp,tsoome MFC after: 1 week Sponsored by: Juniper Networks Differential Revision: https://reviews.freebsd.org//D23827 Notes: svn path=/head/; revision=358813
* veloader use vectx API for kernel and modulesSimon J. Gerraty2020-03-083-6/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The vectx API, computes the hash for verifying a file as it is read. This avoids the overhead of reading files twice - once to verify, then again to load. For doing an install via loader, avoiding the need to rewind large files is critical. This API is only used for modules, kernel and mdimage as these are the biggest files read by the loader. The reduction in boot time depends on how expensive the I/O is on any given platform. On a fast VM we see 6% improvement. For install via loader the first file to be verified is likely to be the kernel, so some of the prep work (finding manifest etc) done by verify_file() needs to be factored so it can be reused for vectx_open(). For missing or unrecognized fingerprint entries, we fail in vectx_open() unless verifying is disabled. Otherwise fingerprint check happens in vectx_close() and since this API is only used for files which must be verified (VE_MUST) we panic if we get an incorrect hash. Reviewed by: imp,tsoome MFC after: 1 week Sponsored by: Juniper Networks Differential Revision: https://reviews.freebsd.org//D23827 Notes: svn path=/head/; revision=358744
* Link stand/i386 components using a linker scriptDimitry Andric2020-03-048-21/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Notes: svn path=/head/; revision=358643
* loader: crc32 is provided by libsaToomas Soome2020-03-042-4/+4
| | | | | | | Seems like leftover from moving crc32.c to libsa. Notes: svn path=/head/; revision=358632
* Move smbios.c to libsa.Warner Losh2020-02-204-495/+2
| | | | | | | | | | | | | smbios used to be an i386 only kinda weird quirk to the x86 architecture. But UEFI picked it up, dusted it off and now it's many other locations. Make it base technology by moving it to libsa and fixing up the compliation. The code has issues with unaligned access still, but that will be addressed in a followup commit. Differential Revision: https://reviews.freebsd.org/D23660 Notes: svn path=/head/; revision=358136
* Create ptov() function.Warner Losh2020-02-202-8/+7
| | | | | | | | | | | | | Create a ptov() function. It's basically the same as the btx PTOV macro, but works everywhere. smbios needs this to translate addresses, but the translation differs between BIOS booting and EFI booting. Make it a function so one smbios.o can be used everywhere. Provide definitions for it in the two loaders affected. Differential Revision: https://reviews.freebsd.org/D23660 Notes: svn path=/head/; revision=358135
* zfsboot: vdev_read_pad2 does allocate buffer with wrong sizeToomas Soome2020-02-051-1/+1
| | | | | | | | | | | | vdev_read_pad2() does read VDEV_PAD_SIZE of data, and will copy size bytes of it, hence, we need buffer of VDEV_PAD_SIZE bytes. Issue introduced in r357497. Reported by: se Notes: svn path=/head/; revision=357569
* vdev_read_pad2: freeing wrong pointerToomas Soome2020-02-051-1/+1
| | | | | | | | | | Shoud free previously allocated tmp buffer instead. Issue introduced in r357497. Reported by: rpokala Notes: svn path=/head/; revision=357567
* loader: rewrite zfs reader zap code to use mallocToomas Soome2020-02-041-9/+20
| | | | | | | | | | First step on removing zfs_alloc. Reviewed by: delphij Differential Revision: https://reviews.freebsd.org/D23433 Notes: svn path=/head/; revision=357497
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-04 08:42:06 +0000