register r8. We continue to write the bootinfo block at the same
hardwired address, because the kernel still expects it there.
It is expected that future kernels use register r8 to get to the
bootinfo block and don't depend on the hardwired address anymore.
Bump the loader version once again due to the interface change.
only care if it's network or not at this time. If we're loaded from
the network, we set currdev (=loaddev) so that the kernel is loaded
from the network as well. In all other cases we initialize to disk.
This makes netbooting more convenient and can easily be enhanced to
do more elaborate checking.
Most significantly (from an interfacing point of view) is the
support for the FPSWA pointer passing. Even though that was added
4 months ago, it's probably not a bad idea to bump the version
number to reflect this.
o Query the state field of the protocol mode to determine whether
we need to start and/or initialize the protocol. When we're
loaded across the network, the protocol has already been started
and is already initialized. When no networking has happened yet,
we have to start and initialize the protocol ourselves.
o After initialization, we have to set the receive filters. Not
doing this results in a deaf interface. We set the unicast and
broadcast filters. Multicast may not be supported. This specific
change fixes the problem we had that we could not netboot if
the loader was started from the EFI shell.
o To help future debugging, add a function that dumps the current
mode of the interface. It's conditional on EFINET_DEBUG.
o To help in runtime problems, emit a diagnostic message when we
could not initialize the protocol properly.
an efi_devdesc structure. When we're netbooting, f->f_devdata holds
the address of the network socket variable. Dereferencing this caused
some very unpredictable behaviour, including proper functioning.
So, as a sanity check, we first make sure f->f_dev points to our
own devsw. If not, the open will fail before we use f->f_devdata.
This solves the netboot hangs I invariably got whenever I used the
latest toolchain to compile the EFI loader.
layer to signal transmission of the packet. This resolves the
problem I'm seeing that an immediate call to net->Receive
after calling net->Transmit returns EFI_DEVICE_ERROR. This
condition seems to be sufficiently persistent that BOOTP and
RARP fail.
o While here, unify all functions to have 'nif' defined. Some
have it as arguments. The others now have them as locals. We
now always get the protocol interface by using the 'nif' var.
The current status of netbooting is that even though we now reliably
have BOOTP working (again), opening a file (ie loading a kernel)
across the network causes the loader to hang. I'm working on that now.
o Make <stdint.h> a symbolic link to <sys/stdint.h>.
o Move most of <sys/inttypes.h> into <sys/stdint.h>, as per C99.
o Remove <sys/inttypes.h>.
o Adjust includes in sys/types.h and boot/efi/include/ia64/efibind.h
to reflect new location of integer types in <sys/stdint.h>.
o Remove previously symbolicly linked <inttypes.h>, instead create a
new file.
o Add MD headers <machine/_inttypes.h> from NetBSD.
o Include <sys/stdint.h> in <inttypes.h>, as required by C99; and
include <machine/_inttypes.h> in <inttypes.h>, to fill in the
remaining requirements for <inttypes.h>.
o Add additional integer types in <machine/ansi.h> and
<machine/limits.h> which are included via <sys/stdint.h>.
Partially obtain from: NetBSD
Tested on: alpha, i386
Discussed on: freebsd-standards@bostonradio.org
Reviewed by: bde, fenner, obrien, wollman
(I'll be we know which compiler and platform they developed this on...)
Minimally change them to C89 comments to make GCC happy. (this is kinda funny
as the file has piece derived from FreeBDS 3.2)
Also fix FreeBSD id style.
page of the image to load section headers and if we let the text section
start at zero, it corrupts the section table when its loaded. With this
change, the loader gets as far as the 'ok' prompt.
