| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix booting with >4GB RAM on PowerMac G5 hardware
===
From Nathan Whitehorn:
Open Firmware runs in virtual mode on the Powermac G5. This runs inside
the
kernel page table, which preserves all address translations made by OF
before
the kernel starts; as a result, the kernel address space is a strict
superset of
OF's.
Where this explodes is if OF uses an unmapped SLB entry. The SLB
fault handler
runs in real mode and refers to the PCPU pointer in SPRG0,
which blows up the
kernel. Having a value of SPRG0 that works for the kernel is
less fatal than
preserving OF's value in this case.
===
The result of this is seemingly random panics from
NULL dereferences, or hangs
immediately upon boot. By not restoring SPRG0 for
Open Firmware entry the
kernel PCPU pointer is preserved and SLB faults
are successful, resulting in a
stable kernel.
PR: 205458
|
|
|
|
|
| |
Use this in place of kobj_error_method to disable BUS_RESCAN() on
PCI drivers that do not use the "standard" scanning algorithm.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the PCI-PCI bridge driver to save a reference to the child
device in its softc.
Note that this required moving the "pci" device creation out of
acpi_pcib_attach(). Instead, acpi_pcib_attach() is renamed to
acpi_pcib_fetch_prt() as it's sole action now is to fetch the PCI
interrupt routing table.
Differential Revision: https://reviews.freebsd.org/D6021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rescanning a PCI bus uses the following steps:
- Fetch the current set of child devices and save it in the 'devlist'
array.
- Allocate a parallel array 'unchanged' initalized with NULL pointers.
- Scan the bus checking each slot (and each function on slots with a
multifunction device).
- If a valid function is found, look for a matching device in the 'devlist'
array. If a device is found, save the pointer in the 'unchanged' array.
If a device is not found, add a new device.
- After the scan has finished, walk the 'devlist' array deleting any
devices that do not have a matching pointer in the 'unchanged' array.
- Finally, fetch an updated set of child devices and explicitly attach any
devices that are not present in the 'unchanged' array.
This builds on the previous changes to move subclass data management into
pci_alloc_devinfo(), pci_child_added(), and bus_child_deleted().
Subclasses of the PCI bus use custom rescan logic explicitly override the
rescan method to disable rescans.
Differential Revision: https://reviews.freebsd.org/D6018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ACPI and OFW PCI bus drivers as well as CardBus override this to
allocate the larger ivars to hold additional info beyond the stock PCI ivars.
This removes the need to pass the size to functions like pci_add_iov_child()
and pci_read_device() simplifying IOV and bus rescanning implementations.
As a result of this and earlier changes, the ACPI PCI bus driver no longer
needs its own device_attach and pci_create_iov_child methods but can use
the methods in the stock PCI bus driver instead.
Differential Revision: https://reviews.freebsd.org/D5891
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of providing a wrapper around device_delete_child() that the PCI
bus and child bus drivers must call explicitly, move the bulk of the logic
from pci_delete_child() into a bus_child_deleted() method
(pci_child_deleted()). This allows PCI devices to be safely deleted via
device_delete_child().
- Add a bus_child_deleted method to the ACPI PCI bus which clears the
device_t associated with the corresponding ACPI handle in addition to
the normal PCI bus cleanup.
- Change cardbus_detach_card to call device_delete_children() and move
CardBus-specific delete logic into a new cardbus_child_deleted() method.
- Use device_delete_child() instead of pci_delete_child() in the SRIOV code.
- Add a bus_child_deleted method to the OpenFirmware PCI bus drivers which
frees the OpenFirmware device info for each PCI device.
Reviewed by: imp
Tested on: amd64 (CardBus and PCI-e hotplug)
Differential Revision: https://reviews.freebsd.org/D5831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On some architectures, u_long isn't large enough for resource definitions.
Particularly, powerpc and arm allow 36-bit (or larger) physical addresses, but
type `long' is only 32-bit. This extends rman's resources to uintmax_t. With
this change, any resource can feasibly be placed anywhere in physical memory
(within the constraints of the driver).
Why uintmax_t and not something machine dependent, or uint64_t? Though it's
possible for uintmax_t to grow, it's highly unlikely it will become 128-bit on
32-bit architectures. 64-bit architectures should have plenty of RAM to absorb
the increase on resource sizes if and when this occurs, and the number of
resources on memory-constrained systems should be sufficiently small as to not
pose a drastic overhead. That being said, uintmax_t was chosen for source
clarity. If it's specified as uint64_t, all printf()-like calls would either
need casts to uintmax_t, or be littered with PRI*64 macros. Casts to uintmax_t
aren't horrible, but it would also bake into the API for
resource_list_print_type() either a hidden assumption that entries get cast to
uintmax_t for printing, or these calls would need the PRI*64 macros. Since
source code is meant to be read more often than written, I chose the clearest
path of simply using uintmax_t.
Tested on a PowerPC p5020-based board, which places all device resources in
0xfxxxxxxxx, and has 8GB RAM.
Regression tested on qemu-system-i386
Regression tested on qemu-system-mips (malta profile)
Tested PAE and devinfo on virtualbox (live CD)
Special thanks to bz for his testing on ARM.
Reviewed By: bz, jhb (previous)
Relnotes: Yes
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D4544
|
|
|
|
|
|
|
| |
include it explicitly when <vm/pmap.h> is already included.
Reviewed by: alc, kib
Differential Revision: https://reviews.freebsd.org/D5373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will allow for code that uses the old fdt_get_range and fdt_regsize
functions to find a range, map it, access, then unmap to replace this, up
to and including the map, with a call to OF_decode_addr.
As this function should only be used in the early boot code the unmap is
mostly do document we no longer need the mapping as it's a no-op, at least
on arm.
Reviewed by: jhibbits
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D5258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Migrate to using the semi-opaque type rman_res_t to specify rman resources. For
now, this is still compatible with u_long.
This is step one in migrating rman to use uintmax_t for resources instead of
u_long.
Going forward, this could feasibly be used to specify architecture-specific
definitions of resource ranges, rather than baking a specific integer type into
the API.
This change has been broken out to facilitate MFC'ing drivers back to 10 without
breaking ABI.
Reviewed By: jhb
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5075
|
|
|
|
| |
device to the RTAS driver, where it belongs.
|
|
|
|
|
| |
setfault() when testing for faults. This should also help the compiler
do the right thing with this complicated-to-optimize function.
|
|
|
|
|
|
|
|
|
| |
Summary:
With some additional changes for AIM, that could also support much
larger physmem sizes. Given that 32-bit AIM is more or less obsolete, though,
it's not worth it at this time.
Differential Revision: https://reviews.freebsd.org/D4345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into a new function that other platforms can share.
This creates a new ofw_reg_to_paddr() function (in a new ofw_subr.c file)
that contains most of the existing ppc implementation, mostly unchanged.
The ppc code now calls the new MI code from the MD code, then creates a
ppc-specific bus_space mapping from the results. The new arm implementation
does the same in an arm-specific way.
This also moves the declaration of OF_decode_addr() from ofw_machdep.h to
openfirm.h, except on sparc64 which uses a different function signature.
This will help all FDT platforms to set up early console access using
OF_decode_addr().
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
OF_getprop() to get encode-int encoded values from the OF tree. This is
a no-op at present, since all existing PowerPC ports are big-endian, but
it is a correctness improvement and will be required if we have a
little-endian kernel at some future point.
Where it is totally impossible for the code ever to be used on a
little-endian system (much of powerpc/powermac, for instance), I have not
necessarily made the appropriate changes.
MFC after: 1 month
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the system has more than a single PCI domain, the bus numbers
are not unique, thus they cannot be used for "pci" device numbering.
Change bus numbers to -1 (i.e. to-be-determined automatically)
wherever the code did not care about domains.
Reviewed by: jhb
Obtained from: Semihalf
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D3406
|
|
|
|
|
|
|
| |
FDT_DTB_STATIC is defined in opt_platform.h, and fdt_static_dtb is in
fdt_common.h, so include those files.
Sponsored by: Alex Perez/Inertial Computing
|
|
|
|
| |
by using extra argument, so caller will know that.
|
| |
|
|
|
|
|
|
| |
executables. The goal here, not yet accomplished, is to let the e500 kernel
run under QEMU by setting KERNBASE to something that fits in low memory and
then having the kernel relocate itself at runtime.
|
|
|
|
|
|
|
|
|
|
| |
This port failed to gain traction and probably only a couple Wii consoles
ran FreeBSD all the way to single user mode with an md(4). IPC
support was never implemented, so it was impossible to use any peripheral
Any further development, if any, will happen at https://github.com/rpaulo/wii.
Discussed with: nathanw (a long time ago), jhibbits
|
| |
|
|
|
|
| |
lets the kernel boot on RTAS-based systems by being kexec'ed from Linux.
|
|
|
|
|
|
| |
in ofw_mem_regions(). This function is actually MI and should move to
dev/ofw at some point in the near future so that ARM and MIPS can use the
same code.
|
|
|
|
|
|
| |
non-relocatable lis @ha, ori @l dance and hoping they are below 4 GB.
MFC after: 2 months
|
|
|
|
| |
MFC after: 2 months
|
| |
|
|
|
|
|
|
|
|
| |
the Open Firmware, as provided by petitboot, for example. Note that this is
not quite complete, since RTAS instantiation still depends on callable
firmware.
MFC after: 2 weeks
|
|
|
|
|
|
|
| |
architectures.
Differential Revision: https://reviews.freebsd.org/D1307
Reviewed by: jhibbits
|
|
|
|
|
|
| |
child node, not the parent node.
Pointed out by: jhibbits@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
node's interrupts=<...> property creating resource list entries with a
single common implementation. This change makes ofw_bus_intr_to_rl() the
one true copy of that code and removes the copies of it from other places.
This also adds handling of the interrupts-extended property, which allows
specifying multiple interrupts for a node where each interrupt can have a
separate interrupt-parent. The bindings for this state that the property
cells contain an xref phandle to the interrupt parent followed by whatever
interrupt info that parent normally expects. This leads to having a
variable number of icells per interrupt in the property. For example you
could have <&intc1 1 &intc2 26 9 0 &intc3 9 4>.
Differential Revision: https://reviews.freebsd.org/D803
|
|
|
|
|
|
| |
that provides the inverse translation, OF_xref_from_node().
Discussed with: nwhitehorn
|
|
|
|
|
|
| |
PR: 186701
Submitted by: Takanori Sawada <tak.swd at gmail.com>
MFC after: 2 weeks
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
strings and include arbitrary information (IRQ line/domain/sense). When the
ofw_bus_map_intr() API was introduced, it assumed that, as on most systems,
these were either 1 cell, containing an interrupt line, or 2, containing
a line number plus a sense code. It turns out a non-negligible number of
ARM systems use 3 (or even 4!) cells for interrupts, so make this more
general.
|
|
|
|
| |
can be used on the others (cpcht and psim), but that has not been tested.
|
|
|
|
| |
internally instead of requiring the caller to allocate it.
|
|
|
|
|
| |
the OF interrupt map API to return sense information to the caller and
the PowerPC Open Firmware PCI base driver to use it to program the PIC.
|
|
|
|
| |
broken systems that require SPRG state to be preserved.
|
| |
|
|
|
|
|
| |
paranoia, so kill it. In particular, changes to SPRG0 are dangerous, since
that is where the PCPU pointer is kept.
|
|
|
|
|
|
|
|
|
|
| |
Open Firmware-centric:
- Keep the static list of regions in platform.c instead of ofw_machdep.c
- Move various merging and sorting operations to platform.c as well
- Move apple_hacks code out of ofw_machdep.c and into platform_powermac.c,
where it belongs
- Move CHRP-specific dynamic-reconfiguration memory parsing into
platform_chrp.c instead of pretending it is shared code
|
|
|
|
| |
by the system. This might give a hint why a pSeries system is not booting.
|
|
|
|
|
|
|
|
| |
preserve any existing fault buffer. RTAS calls are meant to be safe from
interrupt context (and are indeed used there to implement the xics PIC
drvier). Without this, calling into RTAS in interrupt context would have
the effect of clearing any existing onfault state of the interrupted
thread, potentially leading to a panic.
|
|
|
|
|
|
|
|
|
|
|
| |
It turned out that on pSeries machines the call into OF modified the trap
vectors and this made further behaviour unpredictable.
With this commit I'm now able to boot multi user on a network booted
environment on my IntelliStation 285. This is a POWER5+ machine.
Discussed with: nwhitehorn
MFC after: 1 week
|
|
|
|
|
|
|
|
|
|
| |
On some machines (G5 with lots of RAM), entering OF sometimes causes the
machine to hang. Once the machine is booted, currently the only entry point
into OF is through resetting the framebuffer on mode switch on these machines.
Disabling this allows the machine to stay up at the expense of less usable
consoles after X is started.
MFC after: Never, this is only a hack
|
|
|
|
|
|
|
| |
a variant PCI bus instead of trying to shoehorn it into the PCI host bridge
adapter. Besides matching better the architecture on other platforms, this
also allows systems with multiple partitionable endpoints per PCI host
bridge to work correctly.
|
|
|
|
|
|
|
|
| |
assumed that the MDIO bus was a direct child of the Ethernet interface. It
may not be and indeed on many device trees is not. While here, add proper
locking for MII transactions, which may be on a bus shared by several MACs.
Hardware donated by: Benjamin Perrault
|
|
|
|
|
| |
devices. To this end, make PCI device detection rely on the device_type
field rather than name, as per the standard.
|
|
|
|
|
|
|
| |
presence of mac-io devices in the tree, which uniquely identifies Apple
hardware.
MFC after: 6 weeks
|