These exist on the Raspberry Pi 3 and 4 and control and external IO
expander.
Reviewed by: manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25858
There are child nodes in the device tree, e.g. the Raspberry Pi firmware
GPIO device. Add support for this to be a bus so we can attach these
children.
Reviewed by: manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25848
The newer hardware revisions of the Raspberry Pi 4 removed the ability of
the VIA VL805 xhci controller to load its own firmware. Instead the
firmware must be installed at the appropriate time by the VideoCore
coprocessor.
Submitted by: Robert Crowston <crowston_protonmail.com>
Differential Revision: https://reviews.freebsd.org/D25261
The Raspberry Pi GPIO config and state messages incorrectly return with
the tag length set to 0. We then check this value to have the response
flag set. Work around this by setting the response flag when setting the
GPIO config or state and this value is zero.
Sponsored by: Innovate UK
Use the new Raspberry Pi firmware driver in the cpufreq driver. It is
intended all drivers that need to interact with the firmware will move to
use the firmware driver, this is the first.
Reviewed by: manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25609
It will be needed by other eaarly drivers.
While here make the dependency of the mailbox formal with MODULE_DEPEND.
Reviewed by: manu
Sponsored by: Innovate UK
The firmware driver uses the mailbox driver to communicate with the
firmware. Make this a more formal dependency.
Reviewed by: manu
Sponsored by: Innovate UK
This will be needed before a future GPIO controller driver is added
as the later enables regulators that leave the SDHCI controller disabled.
Reviewed by: manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25834
Module name (unlike of the of driver name) must be system wide unique.
Reported by: Mark Millard(bcm_pci), andrew(mvebu_gpio)
MFC with: r362954, r362385
Communicating with the Raspberry Pi firmware is currently handled by each
driver calling into the mbox driver, however the device tree is structured
such that they should be calling into a firmware driver.
Add a driver for this node with an interface to communicate to the firmware
via the mbox interface.
There is a sysctl to get the firmware revision. This is a unix date so can
be parsed with:
root@generic:~ # date -j -f '%s' sysctl -n dev.bcm2835_firmware.0.revision
Tue Nov 19 16:40:28 UTC 2019
Reviewed by: manu
Sponsored by: Innovate UK
Differential Revision: https://reviews.freebsd.org/D25572
This adds support for the Broadcom bcm2711 PCI express controller, found
on the Raspberry Pi 4 (aka the bcm2838 SoC). The driver has only been
developed against the soldered-on VIA XHCI controller and not tested
with other end points.
Submitted by: Robert Crowston <crowston_protonmail.com>
Differential Revision: https://reviews.freebsd.org/D25068
The Raspbery Pi computers do not properly implement PSCI. The canonical
way to reset them is to set a watchdog timer and allow it to expire.
Submitted by: Robert Crowston <crowston_protonmail.com>
Differential Revision: https://reviews.freebsd.org/D25268
The submitter notes that the bcm2835_cpufreq driver really just needs the
rpi4 compat string added to it; powerd subsequently works and the dev.cpu.0
sysctl values look sane and can be successfully manipulated.
Submitted by: James Mintram <me@jamesrm.com>
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D25349
r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren’t properly marked).
Use it in preparation for a general review of all nodes.
This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.
Mark all obvious cases as MPSAFE. All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT
Approved by: kib (mentor, blanket)
Commented by: kib, gallatin, melifaro
Differential Revision: https://reviews.freebsd.org/D23718
Raspberry Pi are all over the board, and the reality is that there's no harm
in including all of the definitions by default but plenty of harm in the
current situation. This change is safe because we match a definition by root
/compatible in the FDT, so there will be no false-positives because of it.
The main array of definitions grows, but it's only walked exactly once to
determine which we need to use.
As far as I can tell, these are an artifact of times when linker sets
couldn't be empty, otherwise the kernel build would fail due to unresolved
symbols. hselasky fixed this in r268138, and I've audited the kbd portions
to make sure nothing would blow up due to the empty linker set and
successfully compiled+ran a kernel with no keyboard support at all.
Kill them off now since they're no longer required.
MFC after: 1 week
I've opted for just duplicating the two entries needed for this, rather than
writing any other mechanism for maintaining two root compat entries to map
to one config, for simplicity. We'll eventually declare these legacy DTB
unsupported, but let's not do that yet while there's no real burden.
We use armv7/GENERIC for the RPI2 images. The original RPI2 is actually a
32-bit BCM2836, but v1.2 was upgraded to the 64-bit BCM2837. The project
continues to provide the RPI2 image as armv7, as it's the lowest common
denominator of the two. Historically, we've just kind of implicitly
acknowledged this by including some bcm2837 bits on a SOC_BCM2836 kernel
config -- this worked until r354875 added code that actually cared.
Acknowledge formally that BCM2837 is valid in arm32.
This name is inconsistent with the other BCM* SOC on !arm64 for two reasons:
1. It's a pre-existing option on arm64, and
2. the naming convention on arm/ should've arguably changed to include BRCM
#1 seems to be a convincing enough argument to maintain the existing name
for it.
Delay the attachment of children, when requested, until after interrutps are
running. This is often needed to allow children to run transactions on i2c or
spi busses. It's a common enough idiom that it will be useful to have its own
wrapper.
Reviewed by: ian
Differential Revision: https://reviews.freebsd.org/D21465
r354875 pushed VCBUS <-> ARMC translations to runtime determination, but
incorrectly mapped addresses for the BCM2836 -- SOC_BCM2835 and SOC_BCM2836
are actually mutually exclusive, so the BCM2836 config (GENERIC) would have
taken the latter path in the header and used 0x3f000000 as peripheral start.
Easily fixed -- split out the BCM2836 into its own memmap config and use
that instead if SOC_BCM2836 is included. With this, we get back to userland
again.
Reported by: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl>
Now that it works for the Raspberry Pi 4, we can discontinue our workarounds
that were put in place to at least get a bootable kernel for other testing.
According to the documentation I have, DREQ pacing should be required here.
The DREQ# hasn't changed since the BCM2835. As soon as we attempt to setup
DREQ, DMA stalls and there's no clear reason why as of yet. Setting this
back to NONE seems to work just as well, though it's yet to be determined if
this is a sustainable model in high-throughput scenarios.
We'll write the value we read back to ack pending interrupts, but we should
at least make it clear to ourselves that we only want to ack pending
transfer interrupts.
Later parts assume that this would've been done if interrupts are enabled,
but this is the only case in which that wouldn't have been true. This commit
also reorders operations such that we're done touching slot/slot->intmask
before we call back into the SDHCI framework and exit.
r354823 kicked DATA_END handling out of the DMA interrupt path "to make
things easy", but this was likely a mistake -- if we know we're done after
we've finished pending DMA operations, we should go ahead and acknowledge
it rather than waiting for the controller to finalize it. If it's not ready,
we'll simply re-enable interrupts and wait for it anyways, to be re-entered
in sdhci_data_intr.
Later parts assume that this would've been done if interrupts are enabled,
but this is the only case in which that wouldn't have been true. This commit
also reorders operations such that we're done touching slot/slot->intmask
before we call back into the SDHCI framework and exit.
It's unclear how this didn't get caught in my last iteration, but the fix is
easy- the interface is still compatible, it was just gratuituously renamed
to match my arbitrary definition of consistency... VCBUS, the BCM2835 name,
represents an address on the VideoCore CPU Bus.
In a similar fashion, while it is a physical address, the ARMC portion
represents that these are addresses as seen by the ARM CPU.
To make things even more fun, the BCM2711 peripheral documentation describes
not virtual address space vs. physical address space, but instead the 32-bit
address map vs. the address map in "Low Peripheral" mode. The latter of
these is what the *ARMC* macros translate to/from.
We could maintain the static conversions for the !AArch64 Raspberry Pis, but
I'm not sure it's worth it -- we'll traverse the platform list exactly once
(of which there are only two for armv7), then every conversion there-after
traverses the memory map listing of which there are at-most two entries for
these boards: sdram and peripheral space.
Detecting this at runtime is necessary for the AArch64 SOC, though, because
of the distinct IO windows being otherwise not discernible just from support
compiled into the kernel. We currently select the correct window based on
/compatible in the FDT.
We also use a similar mechanism to describe the DMA restrictions- the RPi 4
can have up to 4GB of RAM while the DMA controller and mailbox mechanism can
technically, kind of, only access the lowest 1GB. See the comment in
bcm2835_vcbus.h for a fun description/clarification of this.
Differential Revision: https://reviews.freebsd.org/D22301
This round of refactoring is mostly about streamlining the interrupt handler
to make it easier to verify and reason about operations taking place while
trying to bring FreeBSD up on the RPi4.
This allows easy and care-free scaling of NUM_DMA_SEGS with proper-ish
calculations to make sure we can actually handle the number of segments we'd
like to handle on average so that performance comparisons can be easily made
at different values if/once we can actually handle it. It also makes it
helps the untrained reader understand more quickly the reasoning behind the
choice of maxsize/maxsegs/maxsegsize.
This is just further simplification, very little functional change. In the
DMA interrupt handler, we *do* now acknowledge both DATA_AVAIL | SPACE_AVAIL
every time -- these operations are mutually exclusive, so while this is a
functional change, it's effectively a nop. Removing the 'mask' local allows
us to further simplify in a future change.
This simplifies the DMA interrupt handler quite a bit. The sdhci framework
will call platform_finish_transfer() if it's received SDHCI_INT_DATA_END, so
we can take care of any final cleanup there and simply not worry about the
possibility of it ending in the DMA interrupt path.
This is an exceptional case; generally found during controller errors.
A panic when we attempt to acess slot->curcmd->data is less ideal than
warning, and other verbiage will be emitted to indicate the exact error.
This was once set, but I removed it by the time I committed it because both
configurations use the same POWER_ID. This can be separated back out if the
situation changes.
DMA is currently disabled while I work out why it's broken, but this is
enough for upstream U-Boot + rpi-firmware + our rpi3-psci-monitor to boot
with the right config.
The RPi 4 is still not in a good "supported" state, as we have no
USB/PCI-E/Ethernet drivers, but if air-gapped pies only able to operate over
cereal is your thing, here's your guy.
Submitted by: Robert Crowston (with modifications)
On the RPi4, some of these IRQs are shared. Start moving toward a mode where
we accept that shared IRQs happen and simply ignore interrupts that are
seemingly for no reason.
I would like to be more verbose here, but my 30-minute assessment of the
current world order is that mapping a resource/rid to an actual IRQ number
(as found in FDT) data is not a simple matter. Determining if more than one
handler is attached to an IRQ is closer to feasible, but it's unclear which
way is the cleaner path. Beyond that, we're only really using it to be
slightly more verbose when something's going wrong, so for now just suppress
and drop a complaint-comment.
This was originally submitted (via freebsd-arm@) by Robert Crowston; the
additional verbosity was dropped by kevans@.
Submitted by: Robert Crowston <crowston@protonmail.com>
