summaryrefslogtreecommitdiff
path: root/stand/forth
Commit message (Collapse)AuthorAgeFilesLines
* loader.4th(8): Fix a typo in the manual pageGordon Bergling2022-04-151-1/+1
| | | | | | | | - s/commmand/command/ Approved by: re@ (gjb) (cherry picked from commit ad49d7c54cca4906179369e2196c1edbcf509342)
* loader: support.4th resets the read buffer incorrectlyJohn Hood2021-09-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Large nextboot.conf files (over 80 bytes) are not read correctly by the Forth loader, causing file parsing to abort, and nextboot configuration fails to apply. Simple repro: nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx shutdown -r now That will cause the bug to cause a parse failure but shouldn't otherwise affect the boot. Depending on your loader configuration, you may also have to set beastie_disable and/or reduce the number of modules loaded to see the error on a small console screen. 12.0 or CURRENT users will also have to explicitly use the Forth loader instead of the Lua loader. The error will look something like: Warning: syntax error on file /boot/loader.conf.local foo="xxxxxxxxxxxxxxnextboot_enable="YES" ^ /boot/support.4th has crude file I/O buffering, which uses a buffer 'read_buffer', defined to be 80 bytes by the 'read_buffer_size' constant. The loader first tastes nextboot.conf, reading and parsing the first line in it for nextboot_enable="YES". If this is true, then it reopens the file and parses it like other loader .conf files. Unfortunately, the file I/O buffering code does not fully reset the buffer state in the reset_line_reading word. If the last file was read to the end, that doesn't matter; the file buffer is treated as empty anyway. But in the nextboot.conf case, the loader will not read to the end of file if it is over 80 bytes, and the file buffer may be reused when reading the next file. When the file is reread, the corrupt text may cause file parsing to abort on bad syntax (if the corrupt line has <>2 quotes in it), the wrong variable to be set, no variable to be set at all, or (if the splice happens to land at a line ending) something approximating normal operation. The bug is very old, dating back to at least 2000 if not before, and is still present in 12.0 and CURRENT r345863 (though it is now hidden by the Lua loader by default). Suggested one-line attached. This does change the behavior of the reset_line_reading word, which is exported in the line-reading dictionary (though the export is not documented in loader man pages). But repo history shows it was probably exported for the PNP support code, which was never included in the loader build, and was removed 5 months ago. One thing that puzzles me: how has this bug gone unnoticed/unfixed for nearly 2 decades? I find it hard to believe that nobody's tried to do something interesting with nextboot, like load a kernel and filesystem, which is what I'm doing. Tested by: Gary Jennejohn PR: 239315 MFC After: 3 weeks Reviewed by: imp (and correctly applied this time) Differential Revision: https://reviews.freebsd.org/D31328 (cherry picked from commit dbdf2b52f59df7374eb1f799b4df1b54e4502e40)
* Revert "loader: support.4th resets the read buffer incorrectly"Warner Losh2021-07-271-1/+1
| | | | | | | | | This reverts commit 9c1c02093b90ae49745a174eb26ea85dd1990eec. It seems to have broken all old nextboot.conf files causing hangs on boot. PR: 239315 (cherry picked from commit 4783fb730fa1cfdbe5c905bb23ac74f681e2df6b)
* loader: support.4th resets the read buffer incorrectlyJohn Hood2021-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Large nextboot.conf files (over 80 bytes) are not read correctly by the Forth loader, causing file parsing to abort, and nextboot configuration fails to apply. Simple repro: nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx shutdown -r now That will cause the bug to cause a parse failure but shouldn't otherwise affect the boot. Depending on your loader configuration, you may also have to set beastie_disable and/or reduce the number of modules loaded to see the error on a small console screen. 12.0 or CURRENT users will also have to explicitly use the Forth loader instead of the Lua loader. The error will look something like: Warning: syntax error on file /boot/loader.conf.local foo="xxxxxxxxxxxxxxnextboot_enable="YES" ^ /boot/support.4th has crude file I/O buffering, which uses a buffer 'read_buffer', defined to be 80 bytes by the 'read_buffer_size' constant. The loader first tastes nextboot.conf, reading and parsing the first line in it for nextboot_enable="YES". If this is true, then it reopens the file and parses it like other loader .conf files. Unfortunately, the file I/O buffering code does not fully reset the buffer state in the reset_line_reading word. If the last file was read to the end, that doesn't matter; the file buffer is treated as empty anyway. But in the nextboot.conf case, the loader will not read to the end of file if it is over 80 bytes, and the file buffer may be reused when reading the next file. When the file is reread, the corrupt text may cause file parsing to abort on bad syntax (if the corrupt line has <>2 quotes in it), the wrong variable to be set, no variable to be set at all, or (if the splice happens to land at a line ending) something approximating normal operation. The bug is very old, dating back to at least 2000 if not before, and is still present in 12.0 and CURRENT r345863 (though it is now hidden by the Lua loader by default). Suggested one-line attached. This does change the behavior of the reset_line_reading word, which is exported in the line-reading dictionary (though the export is not documented in loader man pages). But repo history shows it was probably exported for the PNP support code, which was never included in the loader build, and was removed 5 months ago. One thing that puzzles me: how has this bug gone unnoticed/unfixed for nearly 2 decades? I find it hard to believe that nobody's tried to do something interesting with nextboot, like load a kernel and filesystem, which is what I'm doing. PR: 239315 Reviewed by: imp (cherry picked from commit 9c1c02093b90ae49745a174eb26ea85dd1990eec)
* loader: do not output empty menu titleToomas Soome2021-04-281-1/+5
| | | | | | | | | | | As we output spaces around the menu title, we should also check, if the title is actually empty string. PR: 255299 Submitted by: Jose Luis Duran Reported by: Jose Luis Duran (cherry picked from 4ba91fa0736bb0672d475b6b56d9e7b06e78ff69)
* loader: insert spaces around menu titleToomas Soome2021-04-031-1/+2
| | | | | | Small visual nit, make menu title more clean (cherry picked from 62ffcaab8f3ccba6053d4a5622c5ef2de9f636b5)
* loader_4th: brand image is aligned rightToomas Soome2021-03-061-1/+1
| | | | | | | With screen border removed, I forgot to update forth brand image coordinates to avoid image alignment. (cherry picked from commit 6a3095aa6d0350dda89bac66d26f22a01e2257c4)
* loader: implement framebuffer consoleToomas Soome2021-01-028-31/+152
| | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a few mandoc issuesGordon Bergling2020-10-092-9/+16
| | | | | | | | | | | | - whitespace at end of input line - skipping paragraph macro: Pp at the end of Sh - new sentence, new line - consider using OS macro: Fx - AUTHORS section without An macro - skipping paragraph macro: Pp before Ss Notes: svn path=/head/; revision=366575
* loader: zfs should support bootonce an nextbootToomas Soome2020-09-211-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* loader: Fully reset terminal settings, not just colorsRyan Moeller2020-03-273-0/+10
| | | | | | | | | | | | Reviewed by: kevans Reviewed by: tsoome Approved by: mav (mentor) MFC after: 1 week Sponsored by: iXsystems, Inc. Differential Revision: https://reviews.freebsd.org/D21733 Notes: svn path=/head/; revision=359371
* loader_4th: menu items need to reset color attribute, not switch to whiteToomas Soome2019-09-222-3/+3
| | | | | | | | Forth menu kernel and BE entries, instead of resetting the color attribute, are switching to white color. Notes: svn path=/head/; revision=352599
* loader: Respect loader_color=YES for serial consolesKyle Evans2019-09-201-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | It's not uncommon these days for the terminals attached to serial consoles to support ANSI escape sequences. However, we assume escape sequences may break some serial consoles and default to not using them when boot_serial or boot_multicons (or if console contains "comconsole" in the forth loader) for broader compatibility. We also have loader_color which can be explicitly set to "NO" to disable the use of ANSI escape sequences. The problem is that loader_color=YES gets ignored when boot_serial=YES or boot_multicons=YES (or when console contains "comconsole" in the forth loader). To fix, the existing default behavior remains unchanged when loader_color is unset, loader_color=NO explicitly disables the use of ANSI escape sequences still, and the change is that loader_color=YES can now be used to explicitly allow ANSI escapes when a serial console is enabled. Submitted by: Ryan Moeller <ryan@ixsystems.com> Reviewed by: tsoome (forth), kevans (lua) MFC after: 1 week Sponsored by: iXsystems, Inc. (Ryan) Differential Revision: https://reviews.freebsd.org/D21732 Notes: svn path=/head/; revision=352559
* loader: provide u> and xemit words if neededToomas Soome2019-09-171-0/+23
| | | | | | | | We have external interpreter (userboot.so) which may be lagging behind with updates and may be missing u> xemit words. Notes: svn path=/head/; revision=352454
* loader_4th: scan_buffer can leave empty string on stackToomas Soome2019-09-161-0/+2
| | | | | | | | When the file processing is done, we will have string with lenght 0 in stack and we will attempt to allocate 0 bytes. Notes: svn path=/head/; revision=352420
* loader: use teken teminal emulator for x86 and uefiToomas Soome2019-09-051-21/+21
| | | | | | | | | | | Replace mini cons25 emulator with teken, this does enable us proper console terminal for loader and will make it possible to implement different back end callbacks to draw to screen. At this time we still only "draw" in text mode. Notes: svn path=/head/; revision=351900
* Regularize the Netflix copyrightWarner Losh2019-02-041-2/+2
| | | | | | | | | | | | | | | Use recent best practices for Copyright form at the top of the license: 1. Remove all the All Rights Reserved clauses on our stuff. Where we piggybacked others, use a separate line to make things clear. 2. Use "Netflix, Inc." everywhere. 3. Use a single line for the copyright for grep friendliness. 4. Use date ranges in all places for our stuff. Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files) Notes: svn path=/head/; revision=343755
* Restore the ability to prevent the user from interrupting the boot processDevin Teske2018-10-211-1/+2
| | | | | | | | | | | | without first entering the password stored in loader.conf(5). PR: kern/207069 Reported by: david@dcrosstech.com MFC after: 3 days Sponsored by: Smule, Inc. Notes: svn path=/head/; revision=339509
* check-password.4th(8): Fix manual [in]accuracyDevin Teske2018-06-241-4/+4
| | | | | | | | | | | | SVN r280384 updated the maximum password length from 16 bytes to 255. The manual was not updated to reflect this. Found while working on kern/207069. MFC after: 3 days X-MFC-to: stable/11 stable/10 Sponsored by: Smule, Inc. Notes: svn path=/head/; revision=335607
* forthloader: Remove "EFI boot environment message"Kyle Evans2018-04-251-2/+0
| | | | | | | | | | | | Contrary to what the message says, this is not only executed in an EFI context- it provides functions for use in an EFI environment. I don't think there's much reason to broadcast this fact when we haven't in the past, so just remove it. Reported by: emaste (a while ago), cperciva Notes: svn path=/head/; revision=332985
* Revert r332275, r332272, r332270Warner Losh2018-04-113-4/+15
| | | | | | | | | | There's problems with them. The order of efi stuff isn't quite right, and there's various problems. Revert until thos problems can be fixed. Reviewed by: kevans@ Notes: svn path=/head/; revision=332413
* loader: 332270 did use wrong path for efi.4thToomas Soome2018-04-081-1/+1
| | | | | | | The correct path is still /boot/efi.4th Notes: svn path=/head/; revision=332272
* loader: include efi.4th only if we do have uefiToomas Soome2018-04-083-15/+4
| | | | | | | Also simplify efi.4th. Notes: svn path=/head/; revision=332270
* forthloader: Don't break BIOS boots...Kyle Evans2018-03-221-1/+1
| | | | | | | | | | | | | | | I thought I tested this scenario, but clearly I failed to. =( BIOS boots won't have efi-autoresizecons, so trying to use it as a forth word fails during include. Use evaluate on "efi-autoresizecons" as a string instead to move any potential errors to runtime- safely after we've already checked that we're booting UEFI. Pointy hat to: me Reported by: cy Notes: svn path=/head/; revision=331341
* Forth version of EFI autoresizingKyle Evans2018-03-213-1/+16
| | | | | | | | | | | | | | | r331321 delegated autoresizing to an efi-autoresizecons command that currently is expected to be done in forth/lua prior to drawing anything useful. Add the Forth version of the lua addition in r331321, hook efi.4th up to be installed. efiboot? was written by dteske@; anything outside of that may be blamed on me. Notes: svn path=/head/; revision=331326
* These two directories build man pages, so it's incorrect to tag themWarner Losh2018-02-261-2/+0
| | | | | | | NO_OBJ. Also, make sure the loader.conf.5 man gets built and installed. Notes: svn path=/head/; revision=330021
* Go back to one loader.confWarner Losh2018-02-263-901/+1
| | | | | | | | | We really only need one loader.conf. The other loader.conf was created because the current one took forever to parse in FORTH. That will be fixed in the next commit. Notes: svn path=/head/; revision=330005
* Add NO_OBJ to those directories that don't make anything.Warner Losh2018-02-261-0/+2
| | | | | | | | | | | For directories that don't many anything, add NO_OBJ=t just before we include bsd.init.mk. This prevents them from creating an OBJ directory. In addition, prevent defs.mk from creating the machine related links in these cases. They aren't needed and break, at least on stable, the read-only src tree build. Notes: svn path=/head/; revision=330004
* Remove pcibios forth support.Warner Losh2018-02-022-48/+0
| | | | | | | | | I had thought that this would be useful. However it was committed too late, and wound up being unused. It's in the way of future work now, so retire it rather than bring it forward. Notes: svn path=/head/; revision=328781
* These 4th words were an attempt to allow integration into the bootWarner Losh2018-02-022-4/+0
| | | | | | | | | loader scripts. However, that path won't be taken after all it seems. Remove this code before it decays into uselessness. Also remove build dependencies on forth no longer needed. Notes: svn path=/head/; revision=328780
* Retire pnp.4th and the code needed only for 4th words used here.Warner Losh2018-02-021-205/+0
| | | | | | | | | | | This has never been installed. It was added to the tree disconnected to the build in FreeBSD 5 (17 years ago) and has never been used as far as I can tell. The desired improvements never really happened (despite a couple minor cleanups along the way). It's relevance is long past, so better to retire it. Notes: svn path=/head/; revision=328779
* stand: Add /boot/overlays to allow separation of overlays from base FDTKyle Evans2018-01-181-1/+1
| | | | | | | | | | | | This matches directory structure used commonly in Linux-land, and it's cleaner than mixing overlays into the existing module paths. Overlays are still mixed in by specifying fdt_overlays in loader.conf(5). Reviewed by: manu Differential Revision: https://reviews.freebsd.org/D13922 Notes: svn path=/head/; revision=328107
* Move sys/boot to stand. Fix all references to new locationWarner Losh2017-11-1438-0/+8711
Sponsored by: Netflix Notes: svn path=/head/; revision=325834
generated by cgit v1.3 (git 2.53.0) at 2026-05-11 15:04:20 +0000