Changes in compilers / warnings/errors caused this to stop compiling.
Delete the write-only code.
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D36532
Summary:
This switch is based off of the AR8327/AR8337 external switch/PHY.
However unlike the AR8327/AR8337 it itself doesn't have any PHYs;
instead an external PHY connects to it using the PSGMII port.
Differential Revision: https://reviews.freebsd.org/D34112
Reviewed by: manu
This code is inspired by the ar40xx code in openwrt, which itself
is based on the Qualcomm QCA-SSDK. Both of these sources are, amusingly,
BSD licenced - and thus I have included some of the comments in the
hardware workaround paths to document some of the magic numbers.
This adds support for the IPQ4018/IPQ4019 MDIO bus. This is used to
talk to external PHYs and switches. (There's an internal switch
in the IPQ4018/IPQ4019 as well, but it's accessible via MMIO/AXI.)
Differential Revision: https://reviews.freebsd.org/D34110
Reviewed by: manu
This adds some very simple DWC3 glue for the IPQ4018/IPQ4019.
Other chipsets introduce reset line iteration, some further
clock line iteration and some customisations; I'll look at adding
those later.
This is enough to finally bring up USB 3.0 on my IPQ4018 ASUS
RT-58U router.
This adds the USB 2.0 and 3.0 PHY support for the IPQ4018/IPQ4019.
All it really needs to do is gate the relevant clocks on/off in the
right order with the right delays.
The Qualcomm TCSR is some top level glue between multiple IP blocks,
both for doing configuration of said IP blocks, some IPC between
them (mostly between multiple execution environments - eg trustzone
and non-TZ), and interrupt status bits for them.
However, for the IPQ4018/IPQ4019, it only is used as a small subset
of IP block configuration. As for what it actually gets used as
for other Qualcomm chipsets? Well, that'll have to wait.
It's a bit of a mess in linux and openwrt. See, every different
SoC support branch ends up with some different TCSR code for it.
So instead, I'm going to land a single TCSR driver that I'm going
to use for the IPQ4018/IPQ4019. When I add the next chipset, I'll
figure out how to organise things so there's a single TCSR driver
that works for multiple platforms.
The Qualcomm Universal Peripherals Engine (QUP) is a unified SPI and I2C
peripheral that ships with a variety of Qualcomm SoCs.
It supports three transfer modes - single PIO, block PIO and DMA.
This driver only supports the single PIO mode, which is enough to
bootstrap the rest of the SPI NAND/NOR support and means I can do
things like read the Wifi calibration data from NOR. It has some
hardware support code for the other transfer modes as well as
some support for split transfers (ie, transfers with no read or
write phase), but I haven't yet implemented those.
This driver is based on four sources - the linux driver, the u-boot
driver, some initial work done for APQ8064 by mmel@, and the APQ8064
Technical Reference Manual which is surprisingly free and open to
read. The linux and u-boot drivers approach a variety of things
completely differently, from how PIO is done, the hardware support
for re-ordering bytes in a transfer word and how the CS lines
are used.
Tested:
* IPQ4018, SPI to NAND/NOR flash, PIO only
Summary: I've tested this with cpufreq_dt, SPI and USB. They all seem to work fine.
Test Plan: * IPQ4018, boot
Subscribers: imp, andrew
Differential Revision: https://reviews.freebsd.org/D33665
These clock nodes are used by the IPQ4018/IPQ4019 and derivatives.
They're also used by other 32 and 64 bit qualcomm parts; so it's
best to put these nodes here in a single qcom_clk driver and add
to it as we grow new Qualcomm SoC support.
Tested:
* IPQ4018, boot
Differential Revision: https://reviews.freebsd.org/D33665
The qualcomm TLMM (top level mode manager) is their gpio/pinmux hardware
controller.
Although the pinmux is generic enough to use for the IPQ/APQ series
chips, I'm directly calling the IPQ4018 routines to expedite bring-up.
Notably, I'm not yet implementing the interrupt support - it's not
required at this stage of bring-up.
Differential Revision: https://reviews.freebsd.org/D33554
* add the extres stuff into the build, I'm going to end up leveraging
all of it
* include the qcom-gcc-ipq4018 driver which currently implements the hwreset
side of the API.
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
This implements the "reset controller" side of the clock/reset controller.
It's a simple array of registers and bits to set.
The register table itself comes from Linux; the rest of the code is a
reimplementation.
It doesn't yet implement or expose the clock side - I have a lot of
reverse engineering to do before that!
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
Obtained from: Linux (registers)
This code implements the "kpssv2" flavour of CPU regulator/clock gating
in Linux. It's used by at least the ipq4018/4019 to power on and off
CPU cores.
This is based on the Linux implementation - the register definitions
and values are from Linux and I've reverse engineered the sequencing
requirements.
The MP bring-up is:
* set cold boot address via an SCM call - this is the address used
by the bootloader/TZ firmware to jump to when the CPUs boot
* power down the LDO feeding the CPU core and wait for it to settle
* program in the right set of LDO and power tree configuration for
the CPU regulator to power up the core. Unfortunately these are
magic numbers that I've not found documented anywhere.
* (I think) power up the shared L2 cache connect if it isn't.
* Clamp the power into the core down; put the core into reset
* Unclamp the power rail; release reset; and then set the core to boot.
The MP core will then boot the bootloader/TZ firmware and then
will wait until an incoming interrupt kicks it to start @ mpentry.
Tested:
* IPQ4019, 4 CPUs
Release APs
CPU(3) applied BP hardening: not necessary
CPU(1) applied BP hardening: not necessary
CPU(2) applied BP hardening: not necessary
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
This is a very simple implementation of Qualcomm's SCM API.
It is just the structure/field definitions and the atomic SCM
call which doesn't use the structs yet - it uses the field
definitions inside registers.
I've tested that setting the cold boot address via the atomic
API is fine - Linux does the same thing. But not all SCM calls
can be done via the legacy API.
This is a reimplementation based on the Linux qualcomm SCM legacy
code and definitions.
Tested:
* Qualcomm IPQ4018 AP, as part of other changes for doing SMP bring-up
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
Summary:
This is enough to allow this ASUS router to reboot successfully.
I tried the watchdog path and although it fires, it isn't rebooting!
It's just hanging, likely somewhere in TZ.
This is the MVP required to initialise and consume random data from
the QCA PRNG hardware found on the IPQ401x.
Test Plan: * ASUS RT-AC58U router, IPQ4019
Subscribers: imp, andrew
Differential Revision: https://reviews.freebsd.org/D32723
This is enough to allow this ASUS router to reboot successfully.
I tried the watchdog path and although it fires, it isn't rebooting!
It's just hanging, likely somewhere in TZ.
Tested:
* ASUS RT-AC58U router, IPQ4019
Reviewed by: andrew, manu, imp
Differential Revision: https://reviews.freebsd.org/D32723
This is for the Qualcomm Atheros quad-core ARMv7 SoC with built-in
2x2 2GHz and 5GHz ath10k devices.
It's enough (with an upcoming set of config files) to netboot
on an ASUS router I have here and get to a single core mountroot
prompt.
