Update the Vendor Relations Team information to reflect that
incoming email is now handled by core@ and the Foundation.
Reviewed by: gjb
MFC after: 3 days
Specifically document that an incomplete ports tree is not supported.
Remove useless comment about sendmail.
Reviewed by: yuri.pankov@gmail.com
Approved by: cperciva (implicit)
MFC after: 1 week
X-MFC-With: r240252
current link points to a irrelevant catchall site.
PR: docs/171411
Submitted by: Mark Martinec <Mark.Martinec@ijs.si> (pr), me (patch)
Approved by: joel (mentor)
MFC after: 2 weeks
- Provide missing function that can do hashing of arbitrary sized buffer.
- Refetch lookup3.c and do only minimal edits to it, so that diff between
our jenkins_hash.c and lookup3.c is minimal.
- Add declarations for jenkins_hash(), jenkins_hash32() to sys/hash.h.
- Document these functions in hash(9)
Obtained from: http://burtleburtle.net/bob/c/lookup3.c
used with Terasic's DE-4 and other similar FPGA boards. This display
is 800x480 and includes a capacitive touch screen, multi-touch
gesture recognition, etc. This device driver depends on a Cambridge-
provided IP core that allows the MTL device to be hooked up to the
Altera Avalon SoC bus, and also provides a VGA-like text frame buffer.
Although it is compiled as a single device driver, it actually
implements a number of different device nodes exporting various
aspects of this multi-function device to userspace:
- Simple memory-mapped driver for the MTL 24-bit pixel frame buffer.
- Simple memory-mapped driver for the MTL control register set.
- Simple memory-mapped driver for the MTL text frame buffer.
- syscons attachment for the MTL text frame buffer.
This driver attaches directly to Nexus as is common for SoC device
drivers, and for the time being is considered BERI-specific, although
in principle it might be used with other hard and soft cores on
Altera FPGAs.
Control registers, including touchscreen input, are simply memory
mapped; in the future it would be desirable to hook up a more
conventional device node that can stream events, support kqueue(2)/
poll(2)/select(2), etc.
This is the first use of syscons on MIPS, as far as I can tell, and
there are some loose ends, such as an inability to use the hardware
cursor. More fundamentally, it appears that syscons(4) assumes that
either a host is PC-like (i386, amd64) *or* it must be using a
graphical frame buffer. While the MTL supports a graphical frame
buffer, using the text frame buffer is preferable for console use.
Fixing this issue in syscons(4) requires non-trivial changes, as the
text frame buffer support assumes that direct memory access can be
done to the text frame buffer without using bus accessor methods,
which is not the case on MIPS. As a workaround for this, we instead
double-buffer and pretend to be a graphical frame buffer exposing
text accessor methods, leading to some quirks in syscons behaviour.
Sponsored by: DARPA, AFRL
The driver attempts to support all documented parts, but has only been
tested with the 512Mbit part on the Terasic DE4 FPGA board. It should be
trivial to adapt the driver's attach routine to other embedded boards
using with any parts in the family.
Also import isfctl(8) which can be used to erase sections of the flash.
Sponsored by: DARPA, AFRL
which presents a UART-like interface over the Avalon bus that can be
addressed over JTAG. This IP core proves extremely useful, allowing us to
connect trivially to the FreeBSD console over JTAG for FPGA-embedded hard
and soft cores. As interrupts are optionally configured for this soft
core, we support both interrupt-driven and polled modes of operation,
which must be selected using device.hints. UART instances appear in /dev
as ttyu0, ttyu1, etc.
However, it also contains a number of quirks, which make it difficult to
tell when JTAG is connected, and some buffering issues. We work around
these as best we can, using various heuristics.
While the majority of this device driver is not only not BERI-specific,
but also not MIPS-specific, for now add its defines in the BERI files
list, as the console-level parts are aware of where the first JTAG UART
is mapped on Avalon, and contain MIPS-specific address translation, to
use before Newbus and device.hints are available.
Sponsored by: DARPA, AFRL
which can be synthesised in Altera FPGAs. An altera_sdcardc device
probes during the boot, and /dev/altera_sdcard devices come and go as
inserted and removed. The device driver attaches directly to the
Nexus, as is common for system-on-chip device drivers.
This IP core suffers a number of significant limitations, including a
lack of interrupt-driven I/O -- we must implement timer-driven polling,
only CSD 0 cards (up to 2G) are supported, there are serious memory
access issues that require the driver to verify writes to memory-mapped
buffers, undocumented alignment requirements, and erroneous error
returns. The driver must therefore work quite hard, despite a fairly
simple hardware-software interface. The IP core also supports at most
one outstanding I/O at a time, so is not a speed demon.
However, with the above workarounds, and subject to performance
problems, it works quite reliably in practice, and we can use it for
read-write mounts of root file systems, etc.
Sponsored by: DARPA, AFRL
CPU cores on Altera FPGAs. The device driver allows memory-mapped devices
on Altera's Avalon SoC bus to be exported to userspace via device nodes.
device.hints directories dictate device name, permissible access methods,
physical address and length, and I/O alignment. Devices can be accessed
using read(2)/write(2), but also memory mapped in userspace using mmap(2).
Devices attach directly to the Nexus, as is common for embedded device
drivers; in the future something more mature might be desirable. There is
currently no facility to support directing device-originated interrupts to
userspace.
In the future, this device driver may be renamed to socgen(4), as it can
in principle also be used with other system-on-chip (SoC) busses, such as
Axi on ASICs and FPGAs. However, we have only tested it on Avalon busses
with memory-mapped ROMs, frame buffers, etc.
Sponsored by: DARPA, AFRL
1) It is not useful to call "devfs_clear_cdevpriv()" from
"d_close" callbacks, hence for example read, write, ioctl and
so on might be sleeping at the time of "d_close" being called
and then then freed private data can still be accessed.
Examples: dtrace, linux_compat, ksyms (all fixed by this patch)
2) In sys/dev/drm* there are some cases in which memory will
be freed twice, if open fails, first by code in the open
routine, secondly by the cdevpriv destructor. Move registration
of the cdevpriv to the end of the drm open routines.
3) devfs_clear_cdevpriv() is not called if the "d_open" callback
registered cdevpriv data and the "d_open" callback function
returned an error. Fix this.
Discussed with: phk
MFC after: 2 weeks
r238211:
Support TARGET_ARCH=armv6 and TARGET_ARCH=armv6eb
This adds a new TARGET_ARCH for building on ARM
processors that support the ARMv6K multiprocessor
extensions. In particular, these processors have
better support for TLS and mutex operations.
This mostly touches a lot of Makefiles to extend
existing patterns for inferring CPUARCH from ARCH.
It also configures:
* GCC to default to arm1176jz-s
* GCC to predefine __FreeBSD_ARCH_armv6__
* gas to default to ARM_ARCH_V6K
* uname -p to return 'armv6'
* make so that MACHINE_ARCH defaults to 'armv6'
It also changes a number of headers to use
the compiler __ARM_ARCH_XXX__ macros to configure
processor-specific support routines.
Submitted by: Tim Kientzle <kientzle@freebsd.org>
- remove extra dynamic variable initializations;
- restore (4BSD) and implement (ULE) hogticks variable setting;
- make sched_rr_interval() more tolerant to options;
- restore (4BSD) and implement (ULE) kern.sched.quantum sysctl, a more
user-friendly wrapper for sched_slice;
- tune some sysctl descriptions;
- make some style fixes.
support for only the first port, but the CP2105 can have multiple ports.
Although this allowed the first port to mostly work on multi port devices,
there could be issues with this arrangement.
Update the man page to reflect support for both ports and the CP2105.
Many thanks to Silicon Labs (www.silabs.com) for providing a CP2105-EK
dev board for testing.
MFC after: 2 weeks
