the extern declaration of __libc_atomic_init() and instead using a
new one added to src/lib/libc/include/extern.h
That file is outside src/common and src/sys so is unavailable to
kernel builds, so instead make a new include file in src/common
which the kernel can read which contains the needed extern decl
for __libc_atomic_init()
This seems to fix the evbarm builds (maybe others) - but it is
all MUCH TOO UGLY to keep. Someone please make a better fix,
even if that just means reverting rev 1.5 of
src/common/lib/libc/atomic/atomic_init_cas.c
and all of the changes here (the addition to libc/include/extern.h
should be harmless to keep).
Network devices can be found as Hardware or Messaging Device Paths,
see Sec 10.4.4 of UEFI Spec 2.10.
In addition to Hardware Device Path, try Messaging Device Path also.
This fixes PXE boot on implementations with the latter choice, e.g.,
Raspberry Pi 4 UEFI firmware.
Once boot device is exclusively opened for Simple Network Protocol,
further access via device path (efi_bootdp) is illegal.
For some implementations, boot device path gets corrupted by
exclusive open, and subsequent access by efi_device_path_depth(),
e.g., causes infinite recursion.
Fix PXE boot for QEMU/aarch64 with EDK2 on some Linux distributions.
Thanks yamaguchi@ for comments and tests.
most of these are like, eg
void foo(int[2]);
with either of these
void foo(int*) { ... }
void foo(int[]) { ... }
in some cases (such as stat or utimes* calls found in our header files),
we now match standard definition from opengroup.
found by GCC 12.
It should be Messaging, not Media Device Path. Taken from OpenBSD, for
which this code was originally written:
https://cvsweb.openbsd.org/src/sys/arch/amd64/stand/efiboot/efipxe.c#rev1.6
> Network-based device paths use Messaging and not Media types. Thus
> in reality the depth was always -1 which made the compare function
> a No-Op. Properly check the device path depth value and look for
> the Messaging type instead to find the correct NIC. This check
> never worked before and was uncovered by the last change.
>
> Regression noticed by bluhm@
Provide a single variable
CC_WNO_ADDRESS_OF_PACKED_MEMBER
with options for both clang and gcc, to replace
CLANG_NO_ADDR_OF_PACKED_MEMBER
CC_NO_ADDR_OF_PACKED_MEMBER
GCC_NO_ADDR_OF_PACKED_MEMBER
Using the convention CC_compilerflag, where compilerflag
is based on the full compiler flag name.
by creating an EFI RT pmap that can be activated / deactivated when
required.
Adds support for EFI RT to ARM_MMU_EXTENDED (ASID) 32-bit Arm machines.
On Arm64 the usage of pmapboot_enter is reduced and the mappings are
created much later in the boot process -- now in cpu_startup_hook.
Backward compatiblity for KVA mapped RT from old bootaa64.efi is
maintained.
Adding support to other platforms should be easier as a result.
Add support for the 'userconf' command at the boot prompt and in boot.cfg,
and for FDT based booting, pass the commands as a string list property
named "netbsd,userconf" on the /chosen node.
The "setup" command sets the 64-bit "OsIndications" variable to the value of
EFI_OS_INDICATIONS_BOOT_TO_FW_UI and requests a reboot. On firmware that
supports this, after reboot the user will be presented with the firmware
setup menu.
Add a new "gop" command that can query the list of available video modes.
With a mode number as argument (eg. "gop 16"), the new display mode will
be selected.
The "version" command prints the current display mode.
This harmonizes efiboot and the various x86 bootloaders to use shared
code for printing the banner. By friendly coincidence, it also adds
support for specifying 'banner=' in arm efiboot's boot.cfg, as on x86.
UEFI spec says that firmware should automatically add EFI_DISK_IO_PROTOCOL
for all produced EFI_BLOCK_IO_PROTOCOL interfaces. Unfortunately U-Boot
doesn't do this, so fallback to block I/O if disk I/O is not there.
Reading data through libsa file-systems ends up breaking block I/O
accesses into very small (512-byte or 2048-byte) accesses. This can be
very inefficient, and causes Ampere eMAG w/ BMC image direction to take
_minutes_ to load the install image and kernel. So slow in fact that
the default watchdog timeout will fire before it finishes.
So, when loading big files, optimistically read ahead up to 64KB of data.
Brings the time to boot the install ISO down to around 40 seconds -- still
not ideal but way better than before.
EFI_DISK_IO_PROTOCOL is a simplified interface to block devices. Use this
instead of EFI_BLOCK_IO_PROTOCOL for accessing block devices to simplify
the code -- we no longer need to worry about the underlying media's block
I/O size and alignment requirements.
access. For slow media (like ISO image redirection on Lenovo HR330A BMC)
this is needed because otherwise the default watchdog timeout fires before
we can finish loading the kernel from install media.
whenever efi_file_path() fails (due to broken firmware), in addition to
the case of ISO9660 (for which efi_file_path() succeeds but does not
work correctly).
ffs frontends to "ufs.c" now also define ufs_dinode_swap, ufs_indp_swap,
and FS_MAGIC (moved from ufs.c #if segments.) these are used to call
the right (32/64 bit) ffsv1/v2 version.
ufs.c 'struct file' gains f_swapped member. accessors for d_magic,
d_reclen, and d_ino are introduced (they need to be swapped.) sfter
reading an inode from disk, read_inode() may call ufs_dinode_swap().
indirect block number and caches may be swapped.
error handling in ffs_find_superblock() is cleaned up. (size is slightly
reduced on some ports with this part.)
defaults for new defines added to ufs.c. (XXX: we build ufs.c but i think
all the consumers don't use it, and we can stop building it.)
LFS support is not included.
add a cut-down copy of ffs_bswap.c from the kernel.
also enable bi-endian disklabel support in efiboot.
most ports build and sizes compared for platforms that don't enable this
code and all but one saw reduced code size. booted several platforms with
new boot code.
if raid disklabel or gpt is found, add this partition with
the offset/size adjusted by RF_PROTECTED_SECTORS. note
don't le32toh() the disklabel. if it was wrong-endian, then
getdisklabel() will have swapped it.
ok jmcneill thorpej.
riastradh