This is needed for efifb.
arm and ricv pmap (the two arch with arm64 that uses subr_devmap) have very
different implementation so for now only add this for arm64.
Tested with efifb on Pine64 with a few other patches.
Reviewed by: cognet
Differential Revision: https://reviews.freebsd.org/D15294
The values for tx/rx delays differs accross the different DTS.
Mainline Linux set it to 0x24/0x18
Mostly-Vendor u-boot (the one maintained and developped) to 0x18/0x18
Mostly-Vendor linux (the one maintained and developped) to 0x26/0x11
By experience only 0x18/0x18 works so until the issue is resolved rely on
the bootloader settings.
The property are named {t,r}x_delay and not {t,r}-delay.
The upper bits of the register are a mask of which bits is allowed
to be written, set it otherwise we write nothing.
OF_getencprop returns <0 = for an error.
Pointy Hat: myself
Reported by: jmcneill (delay and mask bits)
This provides stub implementations of arm64 Linux vdso and machdep,
ptrace, and futex sufficient for executing an arm64 Linux 'hello world'
binary.
Reviewed by: andrew
Sponsored by: Turing Robotic Industries
Differential Revision: https://reviews.freebsd.org/D15832
This controller have a special mode for RX to help with smbus-like transfer
when the controller will automatically send the slave address, register address
and read the data. Use it when possible.
The same mode for TX is describe is the datasheet but is broken and have been
since ~10 years of presence of this controller in RockChip SoCs.
Attach this driver early at we need it to communicate with the PMIC early in the
boot.
Do not hook it to the kernel build for now.
Add driver for the designware ethernet controller found in some RockChip SoCs.
The driver still rely on a lot of things setup by the bootloader like clocks
and phy mode.
But since netbooting is the only/easiest way to boot rockchip board at the
moment add the driver so other people can test/dev on thoses boards.
This was omitted in r334112 and r334996 which cause the PLL to not correctly
reparent, leaving the armclk to be derived from the APLL instead of the NPLL.
The arm core clock is now correctly set to 600Mhz via the assigned-clock present
in the DTB.
RockChip PLL have two modes controlled by a register, a "slow mode" (the
default one) where the frequency is derived from the 24Mhz oscillator on the
board, and a "normal" one when the pll take it's input from the real PLL output.
Default the mode to normal for all the PLLs.
This is the only node we are interested in so do not waste time to test
creating device that will be either unused or fail as most of the nodes
don't have a compatible string.
Parent needs to be the same frequency as the armclk, not twice the freq.
The real divider is incremented by one so write it with - 1
The rate can be at index 0
Pointy Hat To: myself
breakpoint instruction, however this would lose information that may be
useful for debugging.
These are now handled in a similar way to other exceptions, however it
won't exit out of the exception handler until it is known if we can
handle these exceptions in a useful way.
Sponsored by: DARPA, AFRL
With the introduction of pmap_switch(), the DSB instruction on the
address map switch is not necessary executed, which is fixed by
changing the unlock store to release. Also remove comment which
documented pre-pmap_switch() code.
Reviewed by: andrew
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
This is defined as Device-nGnRnE in the UEFI spec (UEFI 2.4, section
2.3.6.1). This is the VM_MEMATTR_DEVICE type in FreeBSD.
Reported by: tuexen
Sponsored by: DARPA, AFRL
We should only call pmap_fault in the kernel when accessing a userspace
address. As this should always happen through specific functions that set
a fault handler we can use this to limit calls to pmap_fault to when this
is set.
This should help with NULL pointer dereferences when we are unable to sleep
so we fall into the correct case.
Sponsored by: DARPA, AFRL
lists in the EFI memory map. As such we need to reduce the mappings to
restrict them to not be the full 1G block. For now reduce this to a 2M
block, however this may be further restricted to be 4k page aligned as
other SoCs may require.
This allows ThunderX2 to boot reliably to userspace without performing
any speculative memory accesses to invalid physical memory.
This is a recommit of r334035 now that we can access the EFI Runtime data
through the DMAP region.
Tested by: tuexen
Sponsored by: DARPA, AFRL
the DMAP region on arm64.
We already have the needed information to build these tables, we just need
to extract it. This significantly simplifies the code.
Obtained from: ABT Systems Ltd
Sponsored by: Turing Robotic Industries
set. This memory must not be mapped by the operating system other than
under control of the device driver.
Obtained from: ABT Systems Ltd
Sponsored by: Turing Robotic Industries
The core clock (armclk) on RockChip SoC is special.
It can derive it's clock from many PLLs but RockChip recommand to do it
from "apll" on old SoC and "npll" on new SoC. The reason for choosing npll
is that it's have less jitter and is more close to the arm core on the SoC.
r333314 added the core clock as a composite clock but due to it's specials
property we need to deal with it differently.
A new rk_clk_armclk type is added for this and it supports only the "npll"
as we don't run on old RockChip SoC that only have the "apll".
It will always reparent to "npll" and set the frequency according to a rate
table that is known to be good.
For now we set the "npll" to the desired frequency and just set the core clk
divider to 1 as its parent it just used for the core clk.
Its absence meant that GEOM direct dispatch was disabled (the service
routines check the current thread's stack usage to determine whether
to hand off the request to a dedicated thread), and this change is
sufficient to enable direct dispatch by default.
Reviewed by: allanjude
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D15527
lists in the EFI memory map. As such we need to reduce the mappings to
restrict them to not be the full 1G block. For now reduce this to a 2M
block, however this may be further restricted to be 4k page aligned as
other SoCs may require.
This allows ThunderX2 to boot reliably to userspace without performing
any speculative memory accesses to invalid physical memory.
Sponsored by: DARPA, AFRL
On some arm64 boards we need to access memory in ACPI tables that is not
mapped in the DMAP region. To handle this create the needed mappings in
pmap_mapbios in the KVA space.
Submitted by: Michal Stanek (mst@semihalf.com)
Sponsored by: Cavium
Differential Revision: https://reviews.freebsd.org/D15059
The main advantage of this is to allow us to exclude memory from being
used by the kernel. This may be from the memreserve property, or ranges
marked as no-map under the reserved-memory node.
More work is still needed to remove the physmap array. This is still used
for creating the DMAP region, however other patches need to be committed
before we can remove this.
Obtained from: ABT Systems Ltd
Sponsored by: Turing Robotic Industries
This turns on support for kernel dump encryption and compression, and
netdump. arm and mips platforms are omitted for now, since they are more
constrained and don't benefit as much from these features.
Reviewed by: cem, manu, rgrimes
Tested by: manu (arm64)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D15465
