bcm2835_mbox_fb_init sets configuration so SET_VIRTUAL_OFFSET should be used
instead of GET_VIRTUAL_OFFSET
Submitted by: Sylvain Garrigues <sylvain@sylvaingarrigues.com>
VideoCore reports garbage in viewport geometry fields unless
viewport was set previously by earlier stage boot loader. So
when booting FreeBSD kernel directly from VideoCore's start.elf
framebuffer intialization fails due to invalid vxres, vyres
values. Make sure we request viewport to be equal to physical
resolution
Submitted by: Sylvain Garrigues <sylvain@sylvaingarrigues.com>
- Pre-buffer audio data to VideoCore so there are no audible glitches when
driver is too late to provide samples
- Start actual playback when there is some prebuffered audio,
it fixes audible noisy click in the beginning of playback
- Use #defines instead of hardcoded values where appropriate
- Fix copy-pasted comment
PR: 208678
a child of it. This is done in conformity with Linux dts files and
as preparation for rework of BCM2836 interrupt controller for INTRNG.
Reviewed by: gonzo
Differential Revision: https://reviews.freebsd.org/D5807
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).
(Thanks to jilles@ for providing the vital clue about the kernel linker.)
intr_pic_init_secondary. Replace them with a direct call. On BCM2836
and ARMADA XP we need to add this function, but it can be empty.
Reviewed by: ian, imp
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5460
slightly wrong on the others. We should just check if mp_ncpus is set to
more than one CPU as we may wish to run on a single core even when SMP is
available.
Reviewed by: ian
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5458
Only L2 PIPT cache is supported for __ARM_ARCH >= 6.
In fact, this is just a pure proclamation as this option is used
only in armv4 specific files now.
(1) The channel mask is get from "brcm,dma-channel-mask" property of
dma node, and if not provided, from "broadcom,channels" property.
(2) Consequently, sdhci driver does not allocate any specific channel.
(3) Use CS_RESET bit for initial channel reset.
Differential Revision: https://reviews.freebsd.org/D4303
Some applications (e.g. Kodi) use tvservice APIs to manage HDMI
modes, power state, EDID etc. directly through VideoCore. After
these manipulations VideoCore may loose its state and needs to be
resynced with ARM. Under Linux this problem is worked around using
fbset utility that recreates framebuffer. Since there is no fbset
utility in FreeBSD we provide sysctl for userland apps to get system
back into normal mode.
interrupt status register to process shared interrupts only if the bit
is active and only on core to which they are routed.
Reviewed by: imp, loos
Approved by: kib (mentor)
Differential Revision: https://reviews.freebsd.org/D3723
- Add bcm2835_mbox_property for generic property request, it accepts
pointer to prepared property chan message and its size, forwards
it to MBOX and copies result back
- Make all bcm2835_mbox_XXX functions that use property channel go
through bcm2835_mbox_property path. Do not accept device_t as
an argument, it's not required: all DMA operatiosn should go
through mbox device, and all API consumers should report errors
on their side.
receives video memory address from VideoCore through property mailbox
channel. Older versions of firmware (and the one that is currently part
of sysutils/u-boot-rpi and sysutils/u-boot-rpi2) returned real physical
address, newer one returns VideoCore bus address, so we need to convert
it to actual physical address. this version works with both older and
newer interface.
missed. In other words, if a new request for an IPI is sent while the
previous request is being handled but the IPI is not cleared yet, the
clearing of the previous IPI request also clears the new one and the
handling is missed.
There are only three MP interrupt controllers in ARM now. Two of them are
fixed by this change, the third one is correct, probably only just by
accident. The fix is minimalistic as new interrupt framework is awaited.
It was debugged on RPi2 where missing IPI handling together with SCHED_ULE
led to situation in which tdq_ipipending was not cleared and so IPI_PREEMPT
was stopped to be sent. Various odditys were found related to slow system
response time like various events timed out, and slow console response.
Submitted by: Svatopluk Kraus <onwahe@gmail.com>
Reviewed by: loos, kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D3722
Use the BCM2835_MBOX_CHAN_PROP mbox channel to setup the framebuffer,
remove DMA code (its now done in bcm2835_mbox.c).
Also adjust the color palette when bcm2708_fb.fbswap is set. The
firmware used on RPi 2 uses this mode.
Tested on: RPi-B and RPi 2 with 16, 24 and 32bpp
Note: The 32bpp mode on RPi-B has the red and blue swapped, this
is a know problem (not a driver problem).
Use the BCM2835_MBOX_CHAN_PROP mbox channel to setup the framebuffer,
remove unused code and unnecessary includes.
Adjust the color palette when bcm2708_fb.fbswap is set on /chosen/bootargs
node of DTB. The firmware used on RPi 2 uses this mode.
Tested on: RPi-B and RPi 2 with 16, 24 and 32bpp
BCM2835_MBOX_CHAN_PROP channel. The old channel (BCM2835_MBOX_CHAN_FB)
seems deprecated on recent firmware versions and is causing a freeze on
RPi 2.
The actual changes in the framebuffer drivers will follow in subsequent
commits.
the Raspberry Pi B we support most of the devices are already supported,
however the base address has changed.
A few items are not working, or missing. The main ones are:
* DMA doesn't work in the sdhci driver.
* Enabling vchiq halts the boot, may be interrupt related.
* There is no U-Boot port yet so the DTB is embedded in the kernel.
The last point will make it difficult to boot FreeBSD, however there is
support for the Raspberry Pi 2 in the U-Boot git repo. As I have not tested
this it is left as an open task to create a port to build.
X-MFC: When the above issues are fixed
Sponsored by: ABT Systems Ltd
to get the default frequency of the sdhci device.
While here use a u_int to hold the frequency as it may be too large to fit
in a 32-bit signed integer. This is the case when we have a 250MHz clock.
been done by U-Boot. This allows the USB to work when we load the kernel
directly.
No dma sync is performed after these operations as the data we read/write
is not used by the cpu after the calls to the maimbox driver.
Differential Revision: https://reviews.freebsd.org/D1940
Reviewed by: imp, Michal Meloun (meloun AT miracle.cz)
MFC after: 1 Week
Sponsored by: ABT Systems Ltd
With this commit any of the GPIO pins can now be programmed to act as an
interrupt source for GPIO devices (i.e. limited to devices directly
attached to gpiobus - at least for now).
Differential Revision: https://reviews.freebsd.org/D1000
Allocate all four, we will use them soon.
Simplificate the allocation of memory and interrupt resources with a single
bus_alloc_resources() call instead of doing them separately.
Destroy the mutex in case of errors.
With this change, it is now possible to verify the pin function and level
of reserved pins (but not set them).
The use of reserved pins on Raspberry pi can lead to short circuits and
real damage to the SoC.
While here, remove duplicated code, make use of OF_getencprop_alloc()
instead of using fixed sized variables and reduce the dmesg spam by
printing reserved pin ranges (when possible) instead of printing each pin
in the range.
This doesn't actually change any behavior, because it just allows a 16-bit
read of the command register to return the correct value, and nothing
actually does a 16-bit read of that register.
sdhci controllers, such as the one on a Raspberry Pi, mishandle the signal
timing in high speed signaling mode, but run just fine in standard mode
with the bus running at frequencies between 25-50MHz (which shouldn't work).
This is the solution adopted by U-Boot and other OSes (linux and *BSD)
for the timeouts on Raspberry Pi boards with certain SD cards. Some
research shows that this quirk is also used on a few other boards, so the
fix is a generic quirk instead of being in the RPi-specific driver code.
This change is based on information discovered by Michal Meloun.
The driver inherently does dma in 512 byte chunks, but it's possible that
such a buffer can span two physically discontiguous pages (such as when
a userland program does IO on the raw /dev/mmcsdN devices). Now the driver
can handle a buffer that's split across two pages.
It could in theory handle any number of segments now, but as long as IO is
being done in 512 byte blocks it will never need more than two.
requires that each 512 byte IO be in a single contiguous buffer, but if a
buffer crosses a page boundary and the physical pages aren't contiguous
you can get an EFBIG failure (too many segments).
The driver really should handle multiple segment IO, but before adding that
I wanted to make sure that it's handling failure properly while the failure
is easily recreatable.
raft of new warnings that appear to be on by default in clang 3.5.0.
Fix RPI-B build issues with new clang not liking the ability to pass
arbitrary flags to as, since some flags are more arbitrary (and thus
verboten) than others.
These warnings should be actually fixed in the code, but this is a
band-aide to get things (almost) building again.
macro wasn't needed and was being used with swapped arguments which always
give the same result (0) defeating the overflow check.
On initialization, do not use bcm_mbox_intr() to read the pending messages,
with the new semaphore based implementation this will lead to semaphore
being incremented on the channels that contain pending data and will make
the first read for that channel return stale data.
This fixes the hang that happens on boot while initializing the cpufreq on
Raspberry Pi.
can't do a timeout bigger than 15 seconds. The code wasn't checking for
this and because bitmasking was involved the requested timeout was
basically adjusted modulo-16. That led to things like a 128 second
timeout actually being a 9 second timeout, which accidentally worked fine
until watchdogd was changed to only pet the dog once every 10 seconds.
that expose new bugs with HS mode.
When the old code could not do the proper card detection it would boot with
lower defaults (and no HS mode) and this makes some HS cards boots.
Now, with the card always identified as HS capable, the sdhci controller
tries to run the card at HS speeds and makes the boot always fail.
Disable the HS mode for now (which still can be enabled with the tunable)
until it is properly fixed.
MFC with: r273264
Requested by: many
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
used for kernel devices it is used by i2c(8).
This fix the 'error: Device not configured' when i2c(8) tries to reset the
controller, as an example:
# i2c -r
Resetting I2C controller on /dev/iic0: error: Device not configured
For now use conservative settings for default i2c speeds.
MFC after: 1 week
EWOULDBLOCK.
Do not print any message at errors. The errors are properly sent to upper
layers which should be able to deal with it, including printing the errors
when they need to.
The error message was quite annoying while scanning the i2c bus.
MFC after: 1 week
This fix a race where the threads waiting for the bus would wake up early
and still see bus as busy.
While here, give a better description to wmesg for the two use cases we
have (bus and io waiting).
MFC after: 1 week
lose the contents of consecutive writes (that happens within two SD card
clock cycles).
This fixes the causes of instability during the SD card detection and
identification on Raspberry Pi (which happens at 400 kHz and so was much
more vulnerable to this issue).
Remove the previous workaround which clearly can't provide the same effect.
MFC after: 1 week
Relnotes: yes
(7-bit device address << 1), always leaving the room for the read/write bit.
This commit convert ti_i2c and revert r259127 on bcm2835_bsc to make them
compatible with 8-bit addresses. Previous to this commit an i2c device
would have different addresses depending on the controller it was attached
to (by example, when compared to any iicbb(4) based i2c controller), which
was a pretty annoying behavior.
Also, update the PMIC i2c address on beaglebone* DTS files to match the new
address scheme.
Now the userland utilities need to do the correct slave address shifting
(but it is going to work with any i2c controller on the system).
Discussed with: ian
MFC after: 2 weeks
platform code, it is expected these will be merged in the future when the
ARM code is more complete.
Until more boards can be tested only use this with the Raspberry Pi and
rrename the functions on the other SoCs.
Reviewed by: ian@
and the functionality it provided into arm/exception.S. Rename the main
irq handling routine from arm_handler_execute() to arm_irq_handler() to
make it more congruent with how other exception handlers are named, and
also update its signature to reflect what has long been reality: it is
passed just a trapframe pointer, no interrupt number argument.
appropriate for each of the 'foo' in the tree. This will allow us to
compile them together (although symbol conflicts prevent us from doing
that today, this just fixes the file name collision).
implementation in arm/machdep.c. Most arm platforms either don't need to
do anything, or just need to call the standard eventtimer init routines.
A generic implementation that does that is now provided via weak linkage.
Any platform that needs to do something different can provide a its own
implementation to override the generic one.
change the gpio children can be described as directly connected to the GPIO
controller without the need of describing the OFW GPIO bus itself on the
DTS file.
With this commit the OFW GPIO bus is fully functional on BBB and RPi.
GPIO controllers which want to use the OFW GPIO bus will need similar
changes.
Approved by: adrian (mentor, implicit)
a sub-node of nexus (ofwbus) rather than direct attach under nexus. This
fixes FDT on x86 and will make coexistence with ACPI on ARM systems easier.
SPARC is unchanged.
Reviewed by: imp, ian
to check the status property in their probe routines.
Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.
Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
rely only on checking the device unit to indentify the BSC unit we are
attaching to. Make use of the device base address to identify our BSC unit.
Approved by: adrian (mentor)
fdtbus in most cases. This brings ARM and MIPS more in line with existing
Open Firmware platforms like sparc64 and powerpc, as well as preventing
double-enumeration of the OF tree on embedded PowerPC (first through nexus,
then through fdtbus).
This change is also designed to simplify resource management on FDT platforms
by letting there exist a platform-defined root bus resource_activate() call
instead of replying on fdtbus to do the right thing through fdt_bs_tag.
The OFW_BUS_MAP_INTR() and OFW_BUS_CONFIG_INTR() kobj methods are also
available to implement for similar purposes.
Discussed on: -arm, -mips
Tested by: zbb, brooks, imp, and others
MFC after: 6 weeks
static device mappings, rather than as the first of the initializations
that a platform can hook into. This allows a platform to allocate KVA
from the top of the address space downwards for things like static device
mapping, and return the final "last usable address" result after that and
other early init work is done.
Because some platforms were doing work in initarm_lastaddr() that needs to
be done early, add a new initarm_early_init() routine and move the early
init code to that routine on those platforms.
Rename platform_devmap_init() to initarm_devmap_init() to match all the
other init routines called from initarm() that are designed to be
implemented by platform code.
Add a comment block that explains when these routines are called and the
type of work expected to be done in each of them.
new devmap.[ch] files. Emphasize the MD nature of these things by using
the prefix arm_devmap_ on the function and type names (already a few of
these things found their way into MI code, hopefully it will be harder to
do by accident in the future).
The only remaining user was the code that allocates bounce pages for armv4
busdma. It's not clear why bounce pages would need uncached memory, but
if that ever changes, kmem_alloc_attr() would be the way to get it.
really need it. That would be almost everywhere it was included. Add
it in a couple files that really do need it and were previously getting
it by accident via another header.
included by vm/pmap.h, which is a prerequisite for arm/machine/pmap.h
so there's no reason to ever include it directly.
Thanks to alc@ for pointing this out.
