is the physical memory size so may be larger than a u_long can hold, e.g.
on ARM with LPAE we could see an address space of up to 40 bits. On ARM
u_long is only 32 bits so the memory size will be truncated, possibly to
zero.
Reported by: bz
Sponsored by: ABT Systems Ltd
Summary:
As part of the migration of rman_res_t to be typed to uintmax_t, memory ranges
must be clamped appropriately for the bus, to prevent completely bogus addresses
from being used.
This is extracted from D4544.
Reviewed By: cem
Sponsored by: Alex Perez/Inertial Computing
Differential Revision: https://reviews.freebsd.org/D5134
Use u_long instead of uint32_t variables to avoid overflow
in case of PA space bigger than 32-bit.
Obtained from: Semihalf
Submitted by: Michal Stanek <mst@semihalf.com>
Sponsored by: Annapurna Labs
Approved by: cognet (mentor)
Reviewed by: andrew, br, wma
Differential revision: https://reviews.freebsd.org/D5393
This simplifies checking for default resource range for bus_alloc_resource(),
and improves readability.
This is part of, and related to, the migration of rman_res_t from u_long to
uintmax_t.
Discussed with: jhb
Suggested by: marcel
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
ucontext_t available. Our code even has XXX comment about this.
Add a bit of compliance by moving struct __ucontext definition into
sys/_ucontext.h and including it into signal.h and sys/ucontext.h.
Several machine/ucontext.h headers were changed to use namespace-safe
types (like uint64_t->__uint64_t) to not depend on sys/types.h.
struct __stack_t from sys/signal.h is made always visible in private
namespace to satisfy sys/_ucontext.h requirements.
Apparently mips _types.h pollutes global namespace with f_register_t
type definition. This commit does not try to fix the issue.
PR: 207079
Reported and tested by: Ting-Wei Lan <lantw44@gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
pmap_unmapdev respectively) so that resources are properly managed.
This is work originally done by kan@. Stanislav picked it up as part
of his Mediatek SoC work.
Tested:
* Carambola2, AR933x SoC
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: kan
Differential Revision: https://reviews.freebsd.org/D5184
This was originall done by kan@.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: kan
Differential Revision: https://reviews.freebsd.org/D5184
This is a prelude to intr-ng support for MIPS boards that need it -
notably the CI20 port from kan@ that's upcoming, but also work that
Stanislav is doing for the Mediatek platforms.
This is the initial platform dependent bits in include/intr.h, some
#defines for the nexus code for the intrng initialisation/runtime
bits, some changed naming (which I'll fix later to be the same, much
like what I did for ARM intr-ng) in exception.S, and the first cut
at a PIC.
Stanislav and I refactored out the common code for intrng support,
so the mips intrng definitions are quite small (sys/mips/include/intr.h.)
This is all work done by kan@, which stanislav has been cherry picking
into common code for his mediatek chipset work.
Tested:
* Carambola2 - no regressions (not intr-ng though!)
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: kan (original author)
Differential Revision: https://reviews.freebsd.org/D5182
clearing hazards.
This revision makes currently known MIPS32 Release 2 and Release 3 CPUs use
the EHB instruction when clearing hazards. So far the MIPS 74K and MIPS1004K
(somewhat) were already using the EHB. Now we add more r2 and r3 CPUs to
this list.
Also, for the cases of MIPS coherent processing systems (currently 1004K,
1074K, interAptiv and proAptiv) - define proper CCA attributes.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D5078
This revision does the following renames:
CPU_MIPS24KC -> CPU_MIPS24K
CPU_MIPS74KC -> CPU_MIPS74K
CPU_MIPS1004KC -> CPU_MIPS1004K
It also adds the following new CPU_MIPSxxx options:
CPU_MIPS24KE, CPU_MIPS34K, CPU_MIPS1074K, CPU_INTERAPTIV, CPU_PROAPTIV
CPU_MIPSxxxxKC is limiting and possibly misleading as it implies the
MIPSxxxxK CPU has no FPU.
It would be better if the CPUs are named after their standard functionalities
only and the presence or absence of FPU can then be controlled via the
CPU_HAVEFPU option.
I will send out another dependent revision that moves MIPS 32 r2 and r3
CPUs to use the EHB instruction for clearing hazards instead of NOP/SSNOP.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D5077
Use driver settable callbacks for handling of:
- core post reset
- reading actual port speed
Typically, OTG enabled EHCI cores wants setting of USBMODE register,
but this register is not defined in EHCI specification and different
cores can have it on different offset.
Also, for cores with TT extension, actual port speed must be determinable.
But again, EHCI specification not covers this so this patch provides
function for two most common variant of speed bits layout.
Reviewed by: hselasky
Differential Revision: https://reviews.freebsd.org/D5088
POSIX requires these members to be of type void * rather than the
char * inherited from 4BSD. NetBSD and OpenBSD both changed their
fields to void * back in 1998. No new build failures were reported
via an exp-run.
PR: 206503 (exp-run)
Reviewed by: kib
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D5092
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
providing compiled-in static environment data that is used instead of any
data passed in from a boot loader.
Previously 'env' worked only on i386 and arm xscale systems, because it
required the MD startup code to examine the global envmode variable and
decide whether to use static_env or an environment obtained from the boot
loader, and set the global kern_envp accordingly. Most startup code wasn't
doing so. Making things even more complex, some mips startup code uses an
alternate scheme that involves calling init_static_kenv() to pass an empty
buffer and its size, then uses a series of kern_setenv() calls to populate
that buffer.
Now all MD startup code calls init_static_kenv(), and that routine provides
a single point where envmode is checked and the decision is made whether to
use the compiled-in static_kenv or the values provided by the MD code.
The routine also continues to serve its original purpose for mips; if a
non-zero buffer size is passed the routine installs the empty buffer ready
to accept kern_setenv() values. Now if the size is zero, the provided buffer
full of existing env data is installed. A NULL pointer can be passed if the
boot loader provides no env data; this allows the static env to be installed
if envmode is set to do so.
Most of the work here is a near-mechanical change to call the init function
instead of directly setting kern_envp. A notable exception is in xen/pv.c;
that code was originally installing a buffer full of preformatted env data
along with its non-zero size (like mips code does), which would have allowed
kern_setenv() calls to wipe out the preformatted data. Now it passes a zero
for the size so that the buffer of data it installs is treated as
non-writeable.
These are all works in progress. Notably - no wifi support just yet!
I've booted the MT7620 on a TP-Link Archer C2 via tftpboot.
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
* Add in chipset awareness to the obio bus layout (ie, which devices are
where);
* Add in some USB OTG changes to be aware of the newer stuff;
* Add in a configurable primary console - some chips use the normal UART,
some use UARTLITE.
Tested (by Stanislav);
* RT3050 (NFS)
* RT5350 (NFS, MFS)
* MT7620 (USB)
Submitted by: Stanislav Galabov <sgalabov@gmail.com>
