summaryrefslogtreecommitdiffstats
path: root/lib/libstand
Commit message (Collapse)AuthorAgeFilesLines
* Add strlcat and strlcpy to libstand on ia64. This is conceptually partian2016-01-201-0/+1
| | | | | of the MFC done in r294342, but since ia64 is gone in -current this is a direct commit to 10-stable to add the functions.
* MFC r292583:ian2016-01-191-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow dhcp/bootp server-provided values to be overriden from environment variables in loader(8) and other libstand applications. Sometimes a dhcp server provides incorrect information along with the IP address. It would be useful to have a way to override this with locally-supplied information, such as command line parameters passed from a prior-stage bootloader. This change allows pre-existing env vars to take precedence over values delivered by the dhcp or bootp server. The bootp/dhcp code in libstand automatically creates environment variables from the data provided by the server (dhcp.root-path, dhcp.domain-name, etc). It also transcribes the values to some global variables such as 'rootpath' and 'hostname'. This change does two things: When adding dhcp.* vars to the environment, don't replace existing vars/values. When setting the global vars rootpath and hostname, use the dhcp.root-path and dhcp.host-name env var values if they exist. This allows the platform-specific part of loader(8) to obtain override values in some platform-specific way and store them in the environment before opening the network device. The set of values that can be overriden is currently limited to just string options. The values that are delivered as binary data are things that probably shouldn't be overridden (IP, netmask, gateway, etc). The original patch this evolved from was submitted by martymac@ PR: 202098 Relnotes: Yes
* MFC r292234, r292527:ian2016-01-191-2/+2
| | | | Add strlcat() and strlcpy() to libstand and libstand32.
* MFC 279949:jhb2015-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | The System V ABI for amd64 allows functions to use space in a 128 byte redzone below the stack pointer for scratch space and requires interrupt and signal frames to avoid overwriting it. However, EFI uses the Windows ABI which does not support this. As a result, interrupt handlers in EFI push their interrupt frames directly on top of the stack pointer. If the compiler used the red zone in a function in the EFI loader, then a device interrupt that occurred while that function was running could trash its local variables. In practice this happens fairly reliable when using gzipfs as an interrupt during decompression can trash the local variables in the inflate_table() function resulting in corrupted output or hangs. Fix this by disabling the redzone for amd64 EFI binaries. This requires building not only the loader but any libraries used by the loader without redzone support. Thanks to Jilles for pointing me at the redzone once I found the stack corruption.
* MFC 279931:jhb2015-04-091-1/+2
| | | | | Spin the twiddle in dosfs to give visual feedback for disk I/O on FAT filesystems as is done for other filesystems in the loader.
* MFC r276079, r276087:ian2015-02-1110-28/+44
| | | | | | | | Add a divisor parameter to twiddle() so that callers can request that output only happen on every Nth call. Add a new loader(8) variable, twiddle_divisor, allowing control over the output frequency of the "twiddle" IO progress indicator.
* MFC r276412:nwhitehorn2015-01-141-1/+6
| | | | | | | Fix loader's ability to read the 10.1 release PowerPC ISOs. There appears to be some kind of problem with the version of makefs used for these disks. There may be a better way to handle this problem, so I've set the MFC timer for a fairly long time period.
* MFC r266878, r266879: Add support for snprintf() to libstand.ian2014-10-262-5/+55
|
* MFC UEFI loaderemaste2014-09-041-16/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MFC consists of the following SVN revisions: 258741 261568 261603 261668 263115 263117 263968 264078 264087 264088 264092 264095 264115 264132 264208 264261 264262 264263 264319 265028 265057 268974 Detailed commit messages: r258741: Note that libstand is 32-bit on amd64 and powerpc64 r261568: Build libstand as a 64-bit library on amd64 The 32-bit bootloaders now link against libstand.a in sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a to be 32-bit. r261603: Don't force efi to a 32-bit build on amd64 r261668: Build libstand as a 64-bit library on ppc64 The 32-bit bootloaders now link against libstand.a in sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a to be 32-bit. This is equivalent to r261568 for amd64. r263115: Add amd64 EFI headers r263117: Connect 64-bit boot ficl to the build It is not yet used, but this will ensure it doesn't get broken. r263968: Use EFI types for EFI values (silences warnings). EFI UINTN is actually a 64-bit type on 64-bit processors. r264078: Put each source file on a separate line This will simplify rebasing the amd64 UEFI patch set. r264087: Build boot/ficl as 64-bit library on amd64 The 32-bit bootloaders on amd64 now use the 32-bit version in ficl32, as is done with libstand32. The native 64-bit ficl will be used by the upcoming UEFI loader. r264088: Merge efilib changes from projects/uefi r247216: Add the ability for a device to have an "alias" handle. r247379: Fix network device registration. r247380: Adjust our load device when we boot from CD under UEFI. The process for booting from a CD under UEFI involves adding a FAT filesystem containing your loader code as an El Torito boot image. When UEFI detects this, it provides a block IO instance that points at the FAT filesystem as a child of the device that represents the CD itself. The problem being that the CD device is flagged as a "raw device" while the boot image is flagged as a "logical partition". The existing EFI partition code only looks for logical partitions and so the CD filesystem was rendered invisible. To fix this, check the type of each block IO device. If it's found to be a CD, and thus an El Torito boot image, look up its parent device and add that instead so that the loader will then load the kernel from the CD filesystem. This is done by using the handle for the boot filesystem as an alias. Something similar to this will be required for booting from other media as well as the loader will live in the EFI system partition, not on the partition containing the kernel. r247381: Remove a scatalogical debug printf that crept in. r264092: Add -fPIC for amd64 r264095: Support UEFI booting on amd64 via loader.efi This is largely the work from the projects/uefi branch, with some additional refinements. This is derived from (and replaces) the original i386 efi implementation; i386 support will be restored later. Specific revisions of note from projects/uefi: r247380: Adjust our load device when we boot from CD under UEFI. The process for booting from a CD under UEFI involves adding a FAT filesystem containing your loader code as an El Torito boot image. When UEFI detects this, it provides a block IO instance that points at the FAT filesystem as a child of the device that represents the CD itself. The problem being that the CD device is flagged as a "raw device" while the boot image is flagged as a "logical partition". The existing EFI partition code only looks for logical partitions and so the CD filesystem was rendered invisible. To fix this, check the type of each block IO device. If it's found to be a CD, and thus an El Torito boot image, look up its parent device and add that instead so that the loader will then load the kernel from the CD filesystem. This is done by using the handle for the boot filesystem as an alias. Something similar to this will be required for booting from other media as well as the loader will live in the EFI system partition, not on the partition containing the kernel. r246231: Add necessary code to hand off from loader to an amd64 kernel. r246335: Grab the EFI memory map and store it as module metadata on the kernel. This is the same approach used to provide the BIOS SMAP to the kernel. r246336: Pass the ACPI table metadata via hints so the kernel ACPI code can find them. r246608: Rework copy routines to ensure we always use memory allocated via EFI. The previous code assumed it could copy wherever it liked. This is not the case. The approach taken by this code is pretty ham-fisted in that it simply allocates a large (32MB) buffer area and stages into that, then copies the whole area into place when it's time to execute. A more elegant solution could be used but this works for now. r247214: Fix a number of problems preventing proper handover to the kernel. There were two issues at play here. Firstly, there was nothing preventing UEFI from placing the loader code above 1GB in RAM. This meant that when we switched in the page tables the kernel expects to be running on, we are suddenly unmapped and things no longer work. We solve this by making our trampoline code not dependent on being at any given position and simply copying it to a "safe" location before calling it. Secondly, UEFI could allocate our stack wherever it wants. As it happened on my PC, that was right where I was copying the kernel to. This did not cause happiness. The solution to this was to also switch to a temporary stack in a safe location before performing the final copy of the loaded kernel. r246231: Add necessary code to hand off from loader to an amd64 kernel. r246335: Grab the EFI memory map and store it as module metadata on the kernel. This is the same approach used to provide the BIOS SMAP to the kernel. r246336: Pass the ACPI table metadata via hints so the kernel ACPI code can find them. r246608: Rework copy routines to ensure we always use memory allocated via EFI. The previous code assumed it could copy wherever it liked. This is not the case. The approach taken by this code is pretty ham-fisted in that it simply allocates a large (32MB) buffer area and stages into that, then copies the whole area into place when it's time to execute. A more elegant solution could be used but this works for now. r247214: Fix a number of problems preventing proper handover to the kernel. There were two issues at play here. Firstly, there was nothing preventing UEFI from placing the loader code above 1GB in RAM. This meant that when we switched in the page tables the kernel expects to be running on, we are suddenly unmapped and things no longer work. We solve this by making our trampoline code not dependent on being at any given position and simply copying it to a "safe" location before calling it. Secondly, UEFI could allocate our stack wherever it wants. As it happened on my PC, that was right where I was copying the kernel to. This did not cause happiness. The solution to this was to also switch to a temporary stack in a safe location before performing the final copy of the loaded kernel. r247216: Use the UEFI Graphics Output Protocol to get the parameters of the framebuffer. r264115: Fix printf format mismatches r264132: Connect sys/boot/amd64 to the build r264208: Do not build the amd64 UEFI loader with GCC The UEFI loader causes buildworld to fail when building with (in-tree) GCC, due to a typedef redefinition. As it happens the in-tree GCC cannot successfully build the UEFI loader anyhow, as it does not support __attribute__((ms_abi)). Thus, just avoid trying to build it with GCC, rather than disconnecting it from the build until the underlying issue is fixed. r264261: Correct a variable's type for 64-bit Ficl FICL_INT is long. r264262: Fix printf args for 64-bit archs r264263: Add explicit casts to quiet warnings in libefi r264319: Fix EFI loader object tree creation on 9.x build hosts Previously ${COMPILER_TYPE} was checked in sys/boot/amd64, and the efi subdirectory was skipped altogether for gcc (since GCC does not support a required attribute). However, during the early buildworld stages ${COMPILER_TYPE} is the existing system compiler (i.e., gcc on 9.x build hosts), not the compiler that will eventually be used. This caused "make obj" to skip the efi subdirectory. In later build stages ${COMPILER_TYPE} is "clang", and then the efi loader would attempt to build in the source directory. r265028 (dteske): Disable the beastie menu for EFI console ... which doesn't support ANSI codes (so things like `at-xy', `clear', and other commands don't work making it impossible to generate a living menu). r265057 (nwhitehorn): Turn off various fancy instruction sets... as well as deduplicate some options. This makes the EFI loader build work with CPUTYPE=native in make.conf on my Core i5. r268974 (sbruno): Supress clang warning for FreeBSD printf %b and %D formats Relnotes: Yes Sponsored by: The FreeBSD Foundation
* MFC r269077 (sbruno): libstand qdivrem warning fixesemaste2014-09-042-13/+14
| | | | | | | | | | | | | | | | libstand's qdivrem.c assumes that sizeof(int) == sizeof(long), this is not true on amd64 I'm not quite positive this is the "correct" solution for this but it does seem to compile and shut up the spew of warnings when compiling libstand for userboot. Add two _Static_asserts() so that in the future somebody will get a compile failure if an architecture develops that violates the assumptions of this code. (strongly suggested by jmg) Change commetns to indicate int types instead of long. (noted by ian in phabric review) Phabric: https://phabric.freebsd.org/D443
* MFC r261591 (nwhitehorn):emaste2014-09-041-27/+106
| | | | Make libstand setjmp work for both 64- and 32-bit ABIs.
* MFC r261530ian2014-07-254-8/+25
| | | | | | Set the malloc alignment to 64 bytes on platforms that use the U-Boot API device drivers. Recent versions of u-boot run with the MMU enabled, and require DMA-based I/O to be aligned to cache line boundaries.
* MFC r257532 (by adrian):dim2013-12-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix this build for clang. MFC r259730: To avoid having to explicitly test COMPILER_TYPE for setting clang-specific or gcc-specific flags, introduce the following new variables for use in Makefiles: CFLAGS.clang CFLAGS.gcc CXXFLAGS.clang CXXFLAGS.gcc In bsd.sys.mk, these get appended to the regular CFLAGS or CXXFLAGS for the right compiler. MFC r259913: For libstand and sys/boot, split off gcc-only flags into CFLAGS.gcc. MFC r259927: Fix pc98 build, by also forcing COMPILER_TYPE in sys/boot/pc98/boot2's Makefile. Pointy hat to: dim
* Unbreak zfsloader with LOADER_TFTP_SUPPORT onkan2013-10-091-2/+6
| | | | | | | | | | Only accept 'net' and 'pxe' devices as underlying transport in tftp.c on x86. Prior to this change tftp code would attempt to send packets over any boot device, including zfs one with predictably sad results. Approved by: re (gjb) MFC After: 1 month
* Move pos++ out of the complicated equation, introduced at r240780.mav2013-07-011-2/+3
| | | | | | | | There is an oppinion that result of that equation is compiler-specific. Submitted by: dt71@gmx.com, kientzle Reviewed by: rmacklem MFC after: 3 days
* libstand: Reset the seek pointer in ext2fs as done in UFS.pfg2013-06-091-0/+2
| | | | | | | | | | | | | | | | | | | | | Based on r134760: Reset the seek pointer to 0 when a file is successfully opened, since otherwise the initial seek offset will contain the directory offset of the filesystem block that contained its directory entry. This bug was mostly harmless because typically the directory is less than one filesystem block in size so the offset would be zero. It did however generally break loading a kernel from the (large) kernel compile directory. Also reset the seek pointer when a new inode is opened in read_inode(), though this is not actually necessary now because all callers set it afterwards. PR: 177328 Submitted by: Eric van Gyzen Reviewed by: iedowse MFC after: 5 days
* Remove an extra copy of _setjmp from libstand. We have used the libc versionandrew2013-06-071-106/+0
| | | | of this function since r183876.
* Enable building string functions as part of libstand on mips; the Makefilerwatson2013-04-281-3/+1
| | | | | | | | | is a bit obfuscated here, as ia64 adds string source files elsewhere, so simply exclude it here. Reviewed by: imp MFC after: 3 days Sponsored by: DARPA, AFRL
* Merge @228176 from Perforce to fix a bug introduced in r249553:rwatson2013-04-281-2/+0
| | | | | | | | | | Trim two now-unneeded (and likely harmful) lines from the libstand setjmp/longjmp for MIPS. Spotted by: jmallett MFC after: 3 days Sponsored by: DARPA, AFRL
* Use a suitable code generation when building libstand for MIPS.rwatson2013-04-161-0/+3
| | | | | | Reviewed by: imp Sponsored by: DARPA, AFRL MFC after: 3 days
* Adapt libstand's setjmp/longjmp MIPS support to be portable across 32-bitrwatson2013-04-161-56/+27
| | | | | | | | | and 64-bit MIPS. Don't use the floating-point coprocessor in the libstand context for MIPS. Reviewed by: imp MFC after: 3 days Sponsored by: DARPA, AFRL
* Add __clzsi2 and ctzsi2. They are required on ARMv4 and ARMv5 to implementandrew2013-03-071-0/+3
| | | | a number of builtin functions.
* Make this WARNS=9 clean on i386 w/ clang.marcel2013-03-021-15/+14
|
* Fix warnings (control reaches end of non-void function).marcel2013-03-021-1/+2
|
* Fix nandfs support by providing the same crc32 function as is usedmarcel2013-03-021-2/+23
| | | | | | in newfs_nandfs. In libstand we get crc32 from libz. The polynomial is not the same as used for nandfs, which is the crc32 used in the kernel.
* Fix includes for use in libstand.kientzle2013-02-191-3/+1
|
* Add strtoul() to libstand by copying from libc and clipping outkientzle2013-02-183-1/+125
| | | | locale code.
* * Add the integer div & mod functions and ARM EABI support functions toandrew2013-02-051-0/+13
| | | | | | libstand. * Stop linking the ARM U-Boot loader against libgcc now libstand has the required symbols.
* Remove unused file.glebius2013-01-291-261/+0
|
* Move the 64-bit _setjmp to lib/libstand.rpaulo2012-12-211-0/+93
|
* Correct detection of a superblock.gber2012-10-031-8/+7
| | | | Obtained from: Smartcom Bulgaria AD
* Revert r240850 and remove redundant NULL check before free(3).kevlo2012-09-241-8/+4
| | | | | | free(3) handles NULL parameter fine. Reviewed by: kib, Garrett Cooper
* Avoid NULL dereferencekevlo2012-09-231-2/+4
|
* Make nfs_readdir() more careful about using response data, cached in globalmav2012-09-211-20/+24
| | | | | | buffer. For now it fixes bug when following `ls` command will return data from previous one aborted by pager. Also it should allow to read several directories same time, for example, for recursive tracerse.
* Don't use global nfs_root_node variable as per-file storage. There aremav2012-09-211-51/+35
| | | | fields that should be file-specific.
* MFV: Update zlib to 1.2.7.delphij2012-06-211-6/+12
| | | | | | | | (x86 assembler optimization disabled for now because it requires the new .cfi_* directives that is not supported by base system binutils). MFC after: 1 week
* Consitently use "__LP64__".obrien2012-05-241-1/+1
| | | | | [there are 33 __LP64__'s in the kernel (minus cddl/ and contrib/), and 11 _LP64's]
* Import work done under project/nand (@235533) into head.gber2012-05-173-0/+1045
| | | | | | | | | | | | | | The NAND Flash environment consists of several distinct components: - NAND framework (drivers harness for NAND controllers and NAND chips) - NAND simulator (NANDsim) - NAND file system (NAND FS) - Companion tools and utilities - Documentation (manual pages) This work is still experimental. Please use with caution. Obtained from: Semihalf Supported by: FreeBSD Foundation, Juniper Networks
* Replace index() and rindex() calls with strchr() and strrchr().ed2012-01-031-3/+3
| | | | | | | | | | The index() and rindex() functions were marked LEGACY in the 2001 revision of POSIX and were subsequently removed from the 2008 revision. The strchr() and strrchr() functions are part of the C standard. This makes the source code a lot more consistent, as most of these C files also call into other str*() routines. In fact, about a dozen already perform strchr() calls.
* Merge index() and strchr() together.ed2012-01-031-8/+7
| | | | | | | | | | | | | | | | | As I looked through the C library, I noticed the FreeBSD MIPS port has a hand-written version of index(). This is nice, if it weren't for the fact that most applications call strchr() instead. Also, on the other architectures index() and strchr() are identical, meaning we have two identical pieces of code in the C library and statically linked applications. Solve this by naming the actual file strchr.[cS] and let it use __strong_reference()/STRONG_ALIAS() to provide the index() routine. Do the same for rindex()/strrchr(). This seems to make the C libraries and static binaries slightly smaller, but this reduction in size seems negligible.
* Add placeholder code for prepending pathnames to tftp.ed2011-12-221-0/+7
| | | | | | | | | | | | At work we have a single tftp server that provides installation data for a variety of operating systems. I'd rather place our FreeBSD-related files in a subdirectory, instead of the root. It would be nice if this setting could be run-time configurable, but at least in our specific case, this is not possible, as pxeboot is chainloaded through pxelinux. Sponsored by: Kumina bv
* - Removing some unneeded definitions of NULL(cruft related to 1970's C).avatar2011-07-106-29/+15
| | | | | | | | | | | | | | | | | | | | | | In C90, NULL is guaranteed to be declared in <stddef.h> and also in <string.h>. Though the correct way to define NULL in FreeBSD is to include <sys/_null.h>, other parts of libstand still require <string.h> to build; therefore, we keep <string.h> in stand.h and add a note about this; - Removing no longer used 'Prototype' definition. Quote from bde@: 'Cruft related to getting incomplete struct declarations within prototypes forward-declared before the structs. It doesn't mean "prototype" but only part of a prototype-related hack. No longer used.' - Replacing iaddr_t with uintptr_t; - Removing use of long double to determine alignment. Use a fixed 16 byte alignment instead; Reviewed by: bde Obtained from: DragonFlyBSD (partially) MFC after: 1 month
* style(9) cleanupkevlo2011-07-101-1/+1
|
* Fixing building bustage on 32 bits platforms when WARNS >= 2. Note thatavatar2011-07-082-5/+10
| | | | | | | | | this fix only applies to zalloc.c, the other part of libstand such like qdivrem.c still gives compilation warnings on sparc64 tinderbox builds; therefore, WARNS level isn't changed for now. Submitted by: Garrett Cooper <yanegomi@gmail.com> Reviewed by: bde
* Fixes to newer tftp code in libstand:rodrigc2011-06-241-51/+132
| | | | | | | | | | | | | | | | | | (1) Coding style changes. (2) If the server does not acknowledge any blocksize option, revert to the default blocksize of 512 bytes. (3) Send ACK if the first packet happens to be the last packet. (4) Do not accept blocksize greater than what was requested. (5) Drop any unwanted OACK received if a tftp transfer is already in progress. (6) Terminate incomplete transfers with a special no-error ERROR packet. Otherwise we rely on the tftp server to time out, which it does eventually, after re-sending the last packet several times and spamming the system log about it every time. This idea is borrowed from the PXE client, which does exactly that. Submitted by: Alexander Kabaev <kan@FreeBSD.org> Reviewed and Tested by: Santhanakrishnan Balraj <sbalraj at juniper dot net>
* Setting warnings without make universe considered harmful. Revert to WARNS=0imp2011-06-161-1/+1
| | | | until such time that the warnings at =2 are fixed for all platforms.
* Using the correct format string(%zu) for size_t type. This should fix 64avatar2011-06-161-1/+1
| | | | | | bits builds. Submitted by: Garrett Cooper <yanegomi@gmail.com>
* Unbreaking build on sparc64.avatar2011-06-161-3/+3
| | | | Submitted by: Garrett Cooper <yanegomi@gmail.com>
* Bring back following change which was undone in previous commit:rodrigc2011-06-151-4/+4
| | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r172854 | marius | 2007-10-21 10:03:18 -0700 (Sun, 21 Oct 2007) | 16 lines Changed paths: M /head/lib/libstand/tftp.c - Given that we tell the compiler that struct ip is packed and 32-bit aligned, GCC 4.2.1 also generates code for sendudp() that assumes this alignment. GCC 4.2.1 however doesn't 32-bit align wbuf, causing the loader to crash due to an unaligned access of wbuf in sendudp() when netbooting sparc64. Solve this by specifying wbuf as packed and 32-bit aligned, too. As for lastdata and readudp() this currently is no issue when compiled with GCC 4.2.1, though give lastdata the same treatment as wbuf for consistency and possibility of being affected in the future. [1] - Sprinkle const on a lookup table. ------------------------------------------------------------------------
* Increase WARNS level to 2.rodrigc2011-06-151-1/+1
|
OpenPOWER on IntegriCloud