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@
into the kernel, which is used mostly on early development stages.
On RPI(2) the DTB is loaded and modified by firmware and then handed to
kernel via U-Boot and ubldr.
The RPI firmware adds (or modify) a few valuable data to the in memory
DTB, like:
- System memory;
- Ethernet MAC address;
- framebuffer settings;
- Board serial and revision;
- clock-frequency for most of devices.
Each TX queue can hold one packet (yes, if_emac can send only two(!)
packets at a time).
Even with this change the very limited FIFO buffer (3 KiB for TX and 13 KiB
for RX) fill up too quick to sustain higher throughput.
For the TCP case it turns out that TX isn't the limiting factor, but the RX
side is (the FIFO fill up and starts to discard packets, so the sender has
to slow down).
Do not strip the ethernet CRC until we read all data from FIFO, otherwise
the CRC bytes would be left in FIFO causing the failure of next packet
(wrong packet header).
When this error happens the receiver has to be disabled and the RX FIFO
flushed, discarding valid packets.
With this fix if_emac behaves a lot better.
There are a few differences between the two. On arm we need to provide a
list of addresses we may be mapping before we have initialised the virtual
memory subsystem, however on arm64 we allocate a small (2MiB for a 4k
granule) range to be used for such purposes.
Differential Revision: https://reviews.freebsd.org/D2249
Sponsored by: The FreeBSD Foundation
