Copy stable/11@r303970 to releng/11.0 as part of the 11.0-RELEASE
cycle.

Prune svn:mergeinfo from the new branch, and rename it to RC1.

Update __FreeBSD_version.

Use the quarterly branch for the default FreeBSD.conf pkg(8) repo and
the dvd1.iso packages population.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Go back to using uintptr_t, because code that actually compiles is
infinitely less buggy than code that is theoretically correct in some
alternate universe.

The uintfptr_t type is apparently a freebsd invention, and exists only when
compiling the kernel. It's a little hard to say for sure, since it doesn't
seem to be documented anywhere except in email advice to unsuspecting and
overly-trusting souls, who then get to wear the pointy hat for blindly
following advice without investigating or testing it first.

Cast using uintfptr_t and eliminate the cast to uint64_t which is uneeded
because rounding down cannot increase the number of bits needed to express
the result.

I had no idea there was such a thing as uintfptr_t.

Requested by: bde

Cast pointer through uintptr_t on the way to uint64_t to squelch a warning.

Use 64-bit math when finding a block of ram to hold the kernel. This fixes
a problem on 32-bit systems which have ram occupying the end of the physical
address space -- for example, a block of ram at 0x80000000 with a size of
0x80000000 was overflowing 32 bit math and ending up with a calculated size
of zero.

This is a fix for one of the two problems mentioned in the PR. Something
similar will need to be done on the kernel side before the PR is closed.

PR: 201614

Fix bug in the ubldr introduced in the rev.283035. The new code
fails to properly consider memory regions when the loader is
located below of those regions or engulfs their lower limit. This
results in "not enough RAM to load kernel" panic, which is totally
bogus. On top of that, there are some variables that can be left
unitialized in those cases, which might cause it fail with memory
access violation instead of panic while trying to load kernel to
a wrong or non-existing address of memory.

Augment the code to properly deal with the loader being below or
at the lower bound of the memory region in question. Also, don't
leave ununitialized variables behind.

Reviewed by: ian

An ARM kernel can be loaded at any 2MB boundary, make ubldr aware of that.

Previously, ubldr would use the virtual addresses in the elf headers by
masking off the high bits and assuming the result was a physical address
where the kernel should be loaded. That would sometimes discard
significant bits of the physical address, but the effects of that were
undone by archsw copy code that would find a large block of memory and
apply an offset to the source/dest copy addresses. The result was that
things were loaded at a different physical address than requested by the
higher code layers, but that worked because other adjustments were applied
later (such as when jumping to the entry point). Very confusing, and
somewhat fragile.

Now the archsw copy routines are just simple copies, and instead
archsw.arch_loadaddr is implemented to choose a load address. The new
routine uses some of the code from the old offset-translation routine to
find the largest block of ram, but it excludes ubldr itself from that
range, and also excludes If ubldr splits the largest block of ram in
two, the kernel is loaded into the bottom of whichever resulting block is
larger.

As part of eliminating ubldr itself from the ram ranges, export the heap
start/end addresses in a pair of new global variables.

This change means that the virtual addresses in the arm kernel elf headers
now have no meaning at all, except for the entry point address. There is
an implicit assumption that the entry point is in the first text page, and
that the address in the the header can be turned into an offset by masking
it with PAGE_MASK. In the future we can link all arm kernels at a virtual
address of 0xC0000000 with no need to use any low-order part of the
address to influence where in ram the kernel gets loaded.

Clarify an error message. The addresses here are
really offsets within the primary mapped memory block
(which may not start at address zero).

Determine kernel load address dynamically from u-boot memory map.

The generic ELF loading code maps the kernel into low memory
by subtracting KERN_BASE. So the copyin/copyout/readin functions
are always called with low addresses. This code finds the largest
DRAM block from the U-Boot memory map and adds that base to
the addresses.

In particular, this fixes ubldr on AM3358, which has DRAM
mapped to 0x80000000 at power-on.

style(9) & style.Makefile(9)

Reviewed by: raj

Eliminate artificial increasing of 'netdev_opens' counter in loader's net_open().

This was introduced as a workaround long time ago for some Alpha firmware
(which is now gone), and actually prevented net_close() to ever be
called.

Certain firmwares (U-Boot) need local shutdown operations to be performed on a
network controller upon transaction end: such platform-specific hooks are
supposed to be called via netif_close() (from within net_close()).

This change effectively reverts the following CVS commit:

sys/boot/common/dev_net.c

revision 1.7
date: 2000/05/13 15:40:46; author: dfr; state: Exp; lines: +2 -1
Only probe network settings on the first open of the network device.
The alpha firmware takes a seriously long time to open the network device
the first time.

Also suppress excessive output while netbooting via loader, unless debugging.

While there, make sys/boot/uboot more style(9) compliant.

Reviewed by: imp
Approved by: cognet (mentor)

MFp4 (e500):

Add support for U-Boot. This uses the U-Boot API as developed by
Rafal and which is (will be) part of U-Boot 1.3.2 and later.

Credits to: raj@