because the i386 pmap on which the new armv6 pmap is based had it, and in
r281707 pmap_lazyfix() was removed from the i386 pmap.
Discussed with: kib
Submitted by: Michal Meloun (via Svatopluk Kraus)
main ARMv6 target, the Raspberry Pi, doesn't support Thumb-2.
This as been tested with a Thumb-2 userland, however building one is
currently unsupported as there are known toolchain issues breaking some
binaries. Further work will also be needed to decide on the method of
selecting which instruction set to build for, and to benchmark both to
find how building everything as Thumb-2 will affect performance.
Relnotes: yes
Of note:
- This commit adds native FreeBSD/arm release build support without
requiring out-of-tree utilities.
- Part of this merge removes the WANDBOARD-{SOLO,DUAL,QUAD} kernel
configuration files, for which the IMX6 kernel configuration file
should be used instead.
- The resulting images have a 'freebsd' user (password 'freebsd'),
to allow ssh(1) access when console access is not available (VGA
or serial). The default 'root' user password is set to 'root'.
- The /etc/ttys file for arm images now enable both ttyv0 and ttyu0
by default.
Help from: many (boot testing, feedback, etc.)
Sponsored by: The FreeBSD Foundation
since it supports all of these board variants.
While here, remove the WANDBOARD-{QUAD,SOLO,DUAL} kernel
configuration files.
Discussed with: ian
Sponsored by: The FreeBSD Foundation
Offet for the power control register was specified incorrectly (it had
the same value as the prefetch control register.) This change corrects
the offset value to 0xF80, per the ARM PL310 documentation.
Submitted by: Steve Kiernan <stevek@juniper.net>
Obtained from: Juniper Networks, Inc.
available on the aml8726-m6 (and later) SoC which allows for
lower speeds.
Differential Revision: https://reviews.freebsd.org/D2433
Submitted by: John Wehle
each of the existing kernel configs. This gives a place to put config
that applies to the entire arch.
Add the ARM_NEW_PMAP option to std.armv6. This is working well in early
testing and it's time for wide exposure, but it's still nice to be able
to fall back to the old implementation for testing when a problem comes
along. Eventually the option and the old implementation will go away.
The opportunity now exists to move a whole lot of boilerplate from all the
arm kernel config files into std.arm*, but that's a commit for another day.
Use the BCM2835_MBOX_CHAN_PROP mbox channel to setup the framebuffer,
remove DMA code (its now done in bcm2835_mbox.c).
Also adjust the color palette when bcm2708_fb.fbswap is set. The
firmware used on RPi 2 uses this mode.
Tested on: RPi-B and RPi 2 with 16, 24 and 32bpp
Note: The 32bpp mode on RPi-B has the red and blue swapped, this
is a know problem (not a driver problem).
Use the BCM2835_MBOX_CHAN_PROP mbox channel to setup the framebuffer,
remove unused code and unnecessary includes.
Adjust the color palette when bcm2708_fb.fbswap is set on /chosen/bootargs
node of DTB. The firmware used on RPi 2 uses this mode.
Tested on: RPi-B and RPi 2 with 16, 24 and 32bpp
BCM2835_MBOX_CHAN_PROP channel. The old channel (BCM2835_MBOX_CHAN_FB)
seems deprecated on recent firmware versions and is causing a freeze on
RPi 2.
The actual changes in the framebuffer drivers will follow in subsequent
commits.
1) Advertise the actual min / max speeds the hardware is capable
of supporting given the reference clock used by the board.
2) Rather than attempting to extend the hardware's timeout register
in software (the hardware doesn't have sufficient bits to directly
support long timeouts), simply implement the same timeout approach
used in the SDXC driver.
3) Set the timeout for a linked command (e.g. STOP TRANSMISSION) based
on the previous multiblock read / write.
The changes have been smoke tested on both the ODROID-C1 and the VSATV102-M6
using the following cards:
* PQI 2GB microSD
* SanDisk 2GB microSD
* PQI 8GB SDHC (not a microSD so only tested on the ATV-102)
* PNY 8GB microSDHC
* SanDisk Ultra 32GB microSDHC
Submitted by: John Wehle
pages which pass a NULL virtual address. If the BUS_DMA_KEEP_PG_OFFSET
flag is set, use the physical address to compute the page offset
instead. The physical address should always be valid when adding
bounce pages and should contain the same page offset like the virtual
address.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
MFC after: 1 week
Reviewed by: jhb@