The hardware random number generator of the RPi4 differs slightly
from the version found on the RPi3.
This commit extends the existing bcm2835_rng driver to function on the RPi4.
Submitted by: James Mintram <me at jamesrm dot com>
Reviewed by: markm, cem, delphij
Approved by: csprng(cem, markm)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22493
Previously the spi_ranges_cnt stored the table size in bytes
instead of the number of elements. Fix that.
Reviewed by: mmel
Submitted by: Zyta Szpak <zr@semihalf.com>
Obtained from: Semihalf
Sponsored by: Marvell
According to Armada 8k documentation, the interrupt cause register
(at offset 0x14) is RW0C. Update the configuration in attach and
the mvebu_gpio_isrc_eoi() to follow the description.
Reviewed by: mmel
Obtained from: Semihalf
Sponsored by: Marvell
Differential Revision: https://reviews.freebsd.org/D29013
This macro returns true if a provided virtual address is contained
in the kernel's clean submap.
In CHERI kernels, the buffer cache and transient I/O map are allocated
as separate regions. Abstracting this check reduces the diff relative
to FreeBSD. It is perhaps slightly more readable as well.
Reviewed by: kib
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D28710
This is all code only run on ARMv4 and ARMv5. Support for these have
been dropped from FreeBSD.
Differential Revision: https://reviews.freebsd.org/D28314
A struct recource already contains the bus_space_tag_t and
bus_space_handle_t. There is no neec to read them and store them again
in the drivers softc. Remove them and use the struct resource directly
with bus_read_* and bus_write_*.
Reviewed by: mmel
Differential Revision: https://reviews.freebsd.org/D28339
These have probe functions that can only match device tree files that
have been removed because the boards they describe are unsupported.
Reviewed by: imp, manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28366
In the driver init routine the CPU clock frequency
value is obtained from a dedicated register. Until now
only part of the values were handled by the mv_ap806_clock
driver. Fix that by adding missing cases.
Submitted by: Zyta Szpak <zr@semihalf.com>
MFC after: 1 week
Obtained from: Semihalf
Sponsored by: Marvell
This reverts commit aa37baf3d7.
The reverted commit was motivated by a problem observed on stable/12,
but it turns out that a better solution was committed in r348309 but not
MFCed. So, revert this change since it is unnecessary and not really
correct: it assumes that the order in which module metadata records is
defined determines their order in the output linker set. While this
seems to hold in my testing, it is not guaranteed.
Reported by: cem
Discussed with: imp
MFC after: 3 days
PNP info definitions currently have an unfortunate requirement in that
they must follow the associated module definition in the module metadata
linker set. Otherwise devmatch can segfault while processing the linker
hints file since kldxref maintains the order in the linker set.
A number of drivers violate this requirement. In some cases this can
cause devmatch(8) to segfault when processing the linker hints file.
Work around the problem for now simply by adjusting the drivers.
Reviewed by: imp
MFC after: 1 week
Sponsored by: Rubicon Communications, LLC ("Netgate")
Differential Revision: https://reviews.freebsd.org/D28260
Use a machdep.nirq tunable intead of compile-time constant NIRQ
as a value for maximum number of interrupts. It allows keep a system
footprint small by default with an option to increase the limit
for large systems like server-grade ARM64
Reviewd by: mhorne
Differential Revision: https://reviews.freebsd.org/D27844
Submitted by: Klara, Inc.
Sponsored by: Ampere Computing
This is the superset of the nooptions found in the -DEBUG kernels.
Reviewed by: emaste, manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D28152
Add 64-bit address support to Cadence CGEM Ethernet driver for use in
other SoCs such as the Zynq UltraScale+ and SiFive HighFive Unleashed.
Reviewed by: philip, 0mp (manpages)
Differential Revision: https://reviews.freebsd.org/D24304
This imposes a fairly severe limitation on space available for mmap that
was not noticed prior to commit. Unfixed mmap will only map from
[data + MAXSIZE, end of user VA space], bringing the amount of usable space
down way too low for non-trivial link jobs (for instance).
Reported by: mmel
It will be used by the upcoming HID-over-i2C implementation. Should be
no-op, except hid.ko module dependency is to be added to affected drivers.
Reviewed by: hselasky, manu
Differential revision: https://reviews.freebsd.org/D27867
The fix in bd03acedb8 worked for 32-bit
ops, and for 64-bit ops for bit arguments of 0 - 95, but then was broken
for operations on the high 32 bits after that.
Reviewed by: markj, mmel
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D27897
Upon exit from the debugger, checking the return code of kdb_trap()
allows one to retry the fatal page fault. This matches what is done on
all other architectures.
Reviewed by: jhb (earlier version)
Differential Revision: https://reviews.freebsd.org/D27535
An 8MB max stack size is quite limiting in today's world, and in-fact is
the *default* stack size for almost every other arch (including mips).
Raise the default to 4MB (should be pretty reasonable) and the max to 64MB.
NetBSD made a similar move back in 2015 and raised MAXDSIZ to 1856 at the
same time, so let's just roll that in as well. They later lowered it, but
eventually raised it back to 1856 in order to build rust.
This was noticed while looking at qemu-bsd-user's default stack sizes and
growth behavior (or lack thereof).
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D27218
Remove the exynos SoC support, this haven't been updated in a while,
isn't present in GENERIC and nobody is motivated to resurect it.
Differential Revision: https://reviews.freebsd.org/D24444
The ARM PMU may use single per-core interrupt or may use multiple generic
interrupts, one per core. In this case, special attention must be paid to
the correct identification of the physical location of the core, its order
in the external database (FDT) and the associated cpuid.
Also keep in mind that a SoC can have multiple different PMUs
(usually one per cluster)
This can be handy if gdb's stack unwinder fails, for example because of
a bug in kgdb's trap frame unwinder.
PR: 251463
Submitted by: Dmitry Salychev <dsl@mcusim.org>
MFC after: 1 week
As of r365978, minidumps include a copy of dump_avail[]. This is an
array of vm_paddr_t ranges. libkvm walks the array assuming that
sizeof(vm_paddr_t) is equal to the platform "word size", but that's not
correct on some platforms. For instance, i386 uses a 64-bit vm_paddr_t.
Fix the problem by always dumping 64-bit addresses. On platforms where
vm_paddr_t is 32 bits wide, namely arm and mips (sometimes), translate
dump_avail[] to an array of uint64_t ranges. With this change, libkvm
no longer needs to maintain a notion of the target word size, so get rid
of it.
This is a no-op on platforms where sizeof(vm_paddr_t) == 8.
Reviewed by: alc, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D27082
Add a new hw.aw_mmc.debug sysctl to help debugging the driver.
Bit 0 will debug card changes (removal, insertion, power up/down)
Bit 1 will debug ios changes
Bit 2 will debug interrupts received
Bit 3 will debug commands sent
MPIDR represents physical locality of given core and it should be used as
the only viable/robust connection between cpuid (which have zero relation to
cores topology) and external description (for example in FDT). It can be
used for determining which interrupt is associated to given per-CPU PMU
or by scheduler for determining big/little core or cluster topology.
MFC after: 3 weeks
