Please note that only a subset of CPU0 registers are exported. CPU1
registers are not touched.
Obtained from: ARMADA38X Functional Specifications
Sponsored by: Rubicon Communications, LLC (Netgate)
With ip fragment reassembly implemented, it makes sense to allow
larger nfs reads. Note due to loader heap size limit, we do not want
to set too large maximum read size. Also we do not change default read size.
Reviewed by: bcr, allanjude
Differential Revision: https://reviews.freebsd.org/D10754
The current read from network is working from up to down - we have some
protocol needing the data from the network, so we build the buffer space
for that protocol, add the extra space for headers and pass this buffer
down to be filled by nif get call in hope, we have guessed the incoming
packet size right. Amazingly enough this approach mostly does work, but
not always...
So, this update does work from down to up - we allocate buffer (based
on MTU or frame size info), fill it up, and pass on for upper layers.
The obvious problem is that when we should free the buffer - if at all.
In the current implementation the upper layer will free the packet on error
or when the packet is no longer needed.
While working on the issue, the additional issue did pop up - the bios
implementation does not have generic get/put interface but is using pxe
udpsend/udpreceive instead. So the udp calls are gone and undi interface
is implemented instead. Which in turn means slight other changes as we
do not need to have duplicated pxe implementation and can just use dev_net.
To align packet content, the actual read from nic is using shifted buffer by
ETHER_ALIGN (2).
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D10232
Don't use DHCP 150 option to decide which protocol use to netboot. When
root-path includes ip address - go thru NFS, if ip address not exists in
root-path - go thru TFTP from server which ip address is in next-server. But
there is one limitation - only one tftp server in network to provide loader and
everything else. Does enybody use more than only one?
Submitted by: kczekirda
Sponsored by: Oktawave
MFC after: 3 weeks
Relnote: Yes
Differential Revision: https://reviews.freebsd.org/D8740
This code base on lpc code. Ralink RT1310 is oem from 5V Technologies.
RT1310 is ARM926EJS(arm5t).
Tested:
* Buffalo WZR2-G300N
Submitted by: Hiroki Mori <yamori813@yahoo.co.jp>
Reviewed by: mizhka
Differential Revision: https://reviews.freebsd.org/D7238
From user report, the errors are seen:
error 1
error 1
gptzfsboot: error 1 lba 4294967288
gptzfsboot: error 1 lba 1
gptzfsboot: no ZFS pools located, can't boot
The first two errors above are from issuing INT13 EAX=0x4800, meaning we
need to check if EDD is available and use EAX=0x800 if not.
For an workaround I'm using the similar idea as in biosdisk.c - first probe
ah=8h, then check if we have EDD.
Note we would like to see the correct disk size info, but we *may*
get away with anything >64MB, so we could at least test 2 zfs pool labels
on whole disk setup and not to freak out the INT13 interface.
If we get away with initial disk probing, then we have partition sizes from
the partition table and we should be able to complete the disk probing.
Note: this update does not provide full fix to all errors, but we get
the drvsize() errors removed.
Reported by: Michael W. Lucas
Reviewed by: julian
Differential Revision: https://reviews.freebsd.org/D10591
The current reboot command in efi/loader/main.c is passing extra data with
ResetSystem, however, UEFI spec 2.6, page 265 does state:
"ResetData is only valid if ResetStatus is something other than EFI_SUCCESS
unless the ResetType is EfiResetPlatformSpecific where a minimum amount of
ResetData is always required."
Therefore we should use DataSize 0 and ResetData NULL - those are two last
arguments for the call.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10562
patm(4) devices.
Maintaining an address family and framework has real costs when we make
infrastructure improvements. In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).
With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.
Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021. Improvements to the code in FreeBSD 11 are
certainly welcome.
Reviewed by: philip
Approved by: harti
As the uboot disk interface is using common/disk.c API, we also
should use disk_ioctl() call, this will give us chance to read partition
sizes and have feature parity with UEFI and BIOS implementations.
This does also fix arm boot issue on some systems, reported/tested by Ian,
thanks.
Reported by: ian
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D10421
The work to make it possible to avoid bcache via using F_NORA modifier did
miss the fact that not all loader platforms are using the bcache, and so
it is possible the modifier is not cleared, as bcache strategy function is
not used.
For fix, we make sure the checks are dont with masked flag.
This patch does fix boot for platforms which do not use bcache.
Reported by: emaste
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10422
The smallest device we can have in the pool is 64MB, since we are trying to
walk all four labels to find the most up to date uberblock, this limit will
also give us good method to check if we even should attempt to probe.
Enforcing the check also will make sure we are not getting wrapped while
calculating the label offset.
Also, after label check, we should verify if we actually got any UB or not.
PR: 218473
Reported by: Masachika ISHIZUKA
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10381
numbers with Chacha20. Keep the API, though, as that is what the
other *BSD's have done.
Use the boot-time entropy stash (if present) to bootstrap the
in-kernel entropy source.
Reviewed by: delphij,rwatson
Approved by: so(delphij)
MFC after: 2 months
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D10048
The current multiboot loader code doesn't clean the metadata added to the
kernel after the bi_load64 dry run, which breaks accounting of the required
memory for the metadata.
This issue didn't show itself before because all the metadata items where small
(8bytes), but after r316343 there's a big blob in the metadata, which triggers
this. Fix it by cleaning the metadata added to the kernel after the bi_load64
dry run. Also add a comment describing the memory layout when booting using
multiboot (Xen Dom0).
This unbreaks booting a FreeBSD/Xen Dom0 after r316343.
MFC after: 3 weeks
Sponsored by: Citrix Systems R&D
With the zfs probe cleanup, the mistake did slip in the probe code;
instead of reading the pool GUID for the actual boot device (partition),
we read GUID for first found pool from the boot disk.
This will break the case when there are both zfs pool and ufs on the boot
disk, and the ufs is used for boot, not zfs.
Reviewed by: smh
Differential Revision: https://reviews.freebsd.org/D10359
This update does add the code to pass partition size to vdev_probe() via
simple callback. Tested via tinderbox build, but not yet with actual boot.
The code can be improved still, but to verify the idea to read media
block size and amedia size has to be confirmed first.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D10302
The work to implement zfs reader to inspect all pool label copies did
miss the userboot, this update does correct this issue.
Since userboot is already using common/disk.c API (disk_open() etc),
the fix is quite simple - we only need to make sure the userdisk_iocl()
will call disk_ioctl(). In addition, the diskioctl callback does return
int, not pointer.
Note, the review request is actually addressing the sparc and userboot,
but as testing the fix for sparc will take some more time, I am posting the
userboot fix now.
This patch is part of the implementation presented in review:
https://reviews.freebsd.org/D10302
Once we have the sparc part tested, we will have the complete fix
for the issue.
Reviewed by: imp
GNU GCC does does recognise it as a valid option and we already
use -mgeneral-regs-only that has the desired effect.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D10306
The current zfs reader is only checking first label from each device, however,
we do have 4 labels on device and we should check all 4 to be protected
against disk failures and incomplete label updates.
The difficulty is about the fact that 2 label copies are in front of the
pool data, and 2 are at the end, which means, we have to know the size of
the pool data area.
Since we have now the mechanism from common/disk.c to use the partition
information, it does help us in this task; however, there are still some
corner cases.
Namely, if the pool is created without partition, directly on the disk,
and firmware will give us the wrong size for the disk, we only can check
the first two label copies.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10203
While we have mechanisms in place to protect ourselves against the read
behind the disk end, there is still one corner case. As the GPT
partition table has backup table at the end of the disk, and we yet
do not know the size of the disk (if the wrong size is provided by the
firmware/bios), we need to limit the reads to avoid read ahead in such case.
Note: this update does add constant into stand.h, so the incremental build
will need to get local stand.h updated first.
Reviewed by: allanjude
Differential Revision: https://reviews.freebsd.org/D10187
The description tells it all, as an side note, I am using uint8_t instead of
u_char as the partition table data really is handled as byte stream, not
char array.
Reviewed by: allanjude, imp
Differential Revision: https://reviews.freebsd.org/D10180
passed in from u-boot across the call to self_reloc and any other early-init
code, and restore them before calling main().
The self_reloc() routine uses r0 and r1 (and calling it uses lr), and
depending on what values get left in them, main() would intermittantly lock
up trying to interpret them as argc and argv values. This problem affected
the self-relocatable ubldr.bin but not ubldr (the elf version).
This patch adds a general mechanism for providing encryption keys to the
kernel from the boot loader. This is intended to enable GELI support at
boot time, providing a better mechanism for passing keys to the kernel
than environment variables. It is designed to be extensible to other
applications, and can easily handle multiple encrypted volumes with
different keys.
This mechanism is currently used by the pending GELI EFI work.
Additionally, this mechanism can potentially be used to interface with
GRUB, opening up options for coreboot+GRUB configurations with completely
encrypted disks.
Another benefit over the existing system is that it does not require
re-deriving the user key from the password at each boot stage.
Most of this patch was written by Eric McCorkle. It was extended by
Allan Jude with a number of minor enhancements and extending the keybuf
feature into boot2.
GELI user keys are now derived once, in boot2, then passed to the loader,
which reuses the key, then passes it to the kernel, where the GELI module
destroys the keybuf after decrypting the volumes.
Submitted by: Eric McCorkle <eric@metricspace.net> (Original Version)
Reviewed by: oshogbo (earlier version), cem (earlier version)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9575
Make sure sensitive memory is properly cleared when finished with it
Reviewed by: Eric McCorkle <eric@metricspace.net>
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D9798
We have parallel NFSv2 and NFSv3 reader implementations, only configurable at
build time, defaulting to v3. Remove v2.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10206
The current efi_zfs_probe() is overcomplicated and can be made
simpler. Still we need to pick up the device handle for our boot
disk first, because the ESP does not have to be the first partition on the
disk.
Once we do have the handle for boot disk, we probe that disk with
pointer for pool GUID.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10198
While testing 32bit UEFI OVMF (which has bug about how the disk size
is presented), I did witness the errors from blkio->ReadBlocks().
It became apparent we can not entirely trust UEFI interfaces either,
so additional checks are needed.
So we use disk_ioctl(DIOCGMEDIASIZE) for disks, with fallback of
Media->LastBlock for other media.
In addition, we need to check if there is media present.
+ small fixes for error printout, and avoiding multiple blk * 512.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10197
doesn't help clang, but buys us another 32 bytes for gcc 4.2.1. It
also eliminates a warning from gcc 6.3.0 that says inlining this would
be unhelpful.
This is being done to make it easier to change in the future--this action might be
needed sooner rather than later because of gcc 6.3.0 bailing, stating that there
is negative free space left (deficit) in the boot2 bootloader.
MFC after: 2 months
Sponsored by: Dell EMC Isilon
self_reloc.c doesn't initialize `rel` in all cases in the C code, however, the value
might be initialized properly on the stack in the assembly code.
For right now (because this doesn't seem to be breaking anything and my initializing
the stack value could break something since it's called from assembly code) disable
the warning for self_reloc.c. More investigation should be done to determine the
appropriate response to this warning (either intialize the value or find a smarter
way to deal with the warning).
A long MFC timeout is being set for this change to allow a better solution for the
issue to be developed in that time period.
MFC after: 2 months
Reported by: Jenkins (FreeBSD-head-amd64-gcc job)
Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
With some file system the ls is unable to display file types.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10066
Move the time related function into time.c, keep the same logic as libefi.
Reviewed by: allanjude
Approved by: allanjude (mentor)
Differential Revision: https://reviews.freebsd.org/D10058
`-Wno-missing-variable-declarations` is a clang-specific flag,
so gcc (not 4.2.1, in particular 6.3.0 in my case) dies when
it's passed the flag.
X-MFC with: r304321
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
This is a better pattern to follow when creating the bootloaders and doing
the relevant space checks to make sure that the sizes aren't exceeded (and
thus, copy-pasting is a bit less error prone).
MFC after: 3 days
Sponsored by: Dell EMC Isilon
This variable has been unused since its inception in r40106.
MFC after: 3 days
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
zfssubr.c already defines this statically. Besides, zfsimpl.c defined it, but
didn't use it.
This fixes a -Wredundant-decls warning.
MFC after: 3 days
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
This fixes several -Wshadow warnings introduced in r192194, but now errors
with gcc 6.3.0.
MFC after: 3 days
Reported by: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
This fixes a -Wempty-body warning with gcc 6.3.0 when PART_DEBUG is undefined.
MFC after: 3 days
Reported by: Jenkins (FreeBSD-head-amd64-gcc job)
Tested with: amd64-gcc-6.3.0 (devel/amd64-xtoolchain-gcc)
Sponsored by: Dell EMC Isilon
