-> sys/mutex.h -> sys/intr.h -> machine/intr.h -> footbridge/footbridge_intr.h
-> arm/cpu.h -> sys/cpu_data.h -> sys/sched.h -> sys/time.h -> sys/timevar.h
-> sys/systm.h -> sys/param.h -> uvm_param.h -> sys/resourcevar.h
Now sys/resourcevar.h needs a concrete definition of kmutex_t, and
although we started including sys/mutex.h we never got to include
machine/mutex.h which actually defines it, since the footbridge_intr.h
took us for a long ride. Take the easy way out and include
arm/mutex.h in footbridge_intr.h so that we get the definition we
need.
are machine-specific) from userland unless _KERNEL/_KMEMUSER and a
new _KERNTYPES variables is defined. The _KERNTYPES should be fixed
for many subsystems that should not be using it (rump)...
kernel on machines without arcofi(4) audio (i.e. all hp300 except HP425e).
I failed to pull all necessary changes for arcofi(4) from OpenBSD
and I should have tested 7.0_RC kernels on my HP382 too :-(
Should be pulled up to netbsd-7 and netbsd-7-0.
Bump version to denote user visible change.
XXX: recent visible changes (memsize probe, SRAM switch command)
were not denoted in versions
Tested on (real) X68030.
- Decode NetBSD's ci_feat_val[0-5]. The output order of the bits is the same as
linux. Before this commit, only ci_feat_val[0] was decoded.
- Linux defined feature words and some others are not decoded yet.
- procfs_getonecpufeatures() will be rewritten when all of linux entries are
decoded.
This code is still a mess, but at least it uses an interrupt-map so I can
use it to test whether interrupt-map handling in fdt_intr_ is working
properly.
Need to get some real documentation and redo this so it works. :(
request again (possibly because of compiler optimisations), by using
copies and barrier.
From XSA155:
The compiler can emit optimizations in the PV backend drivers which
can lead to double fetch vulnerabilities. Specifically the shared
memory between the frontend and backend can be fetched twice (during
which time the frontend can alter the contents) possibly leading to
arbitrary code execution in backend.
The mct on exynos uses an interrupt map so we add support now. Devices
represent their interrupts either through a combination of interrupt-parent
and interrupts properties, where the 'interrupts' property is an array of
one or more interrupt specifiers; or through a combination of an
interrupt-parent that points to an interrupt-map, where the interrupt-map
contains 2 or more entries consisting of an index, a pointer to an
interrupt-controller, and a specifier for that controller.
This code adds the ability to walk the interrupt-map and return a specifier.
Unfortunately, the addition requires changing the interface to the
interrupt-controllers' _establish and _intstr functions, so this check in
contains a rototill of the three existing fdt interrupt controllers to use
the new interface.
their implementation. Both functions don't take the passcode as
argument.
As wrmsr_locked() no longer writes the passcode to the msr the
erratum 721 on my Opteron 2356 really gets patched and cc1 no longer
crashes with SIGSEGV.
Add sysmmu to have something that calls through to the combiner's establish
routine. Debug the combiner with it.
At this point the combiner is mostly done, but the interrupt handler has not
been tested. This may never happen as we may never support any of the
devices that use the combiner for interrupts. (Or maybe mct)
modify exynos_gpio.c to support the new pinctrl model.
set up the new pinctrl model in exynos_pinctrl.c
Flesh out exynos_i2c.c and set it up to use the new pinctrl model. NOTE:
exynos_i2c.c is still incomplete. I need to figure out what to set the
prescaler and scaler to.
This is a complete, but untested, driver; except that it needs to be able
to configure gpios and, afaict, we don't yet have an fdtbus_gpio_* function
that will do that.
Written but untested. I'm still confused about how to handle two things:
1) at interrupt disestablishment, where do I get an interrupt number so
that I can disable the interrupt on the combiner?
2) How is interrupt multiplexing handled? I don't seem to have any sort of
interrupt dispatch routine that takes the 1 interrupt that reaches the
gic and turn it into one of eight combined interrupts to call the
established interrupt for the original uncombined interrupt source.
polarity into account. Tegra GPIO pin data includes pin polarity, but so
does a regulator-fixed node, so the end result was that the enable value
was being swapped twice. Change fregulator to use the raw APIs, and adapt
Tegra and Exynos GPIO drivers to support this flag.
This is a moderately tested working gpio driver for the Exynos based ODROID
XU4. To use this you have to edit the dtd file exynos54422-pinctrl.dtsi
and change the two occurances of 'gpz' to 'gpz0'. Otherewise it will crash
on a lookup failure.
It certainly could use a code review.
step N of N: get rid of baggage by removing whole files. What's left is in
approximately the same shape as when the FDT update started, that is mostly
broken. What's missing is most of the 76 devices recognized in the dtd. In
other words, This is barely the start of a port.
Next up, gpio then i2c, followed either by straightening out usb or getting
the sdhc driver to work -- both probably require getting the interrupt
combiner to work first. A large chunk of work is left to do on the clocks.
I barely got them attaching to fdt and didn't do anything to take advantage
of the information in the dtd.
None of the other existing drivers, such as they are, properly request gpios,
i2c or clocks, and, of course power domains are off the table.
There is a minimum conversion on the clock driver.
The USB driver needs reordering and is broken, but it was broken before.
Next up: tactical nuclear weapons
It is rather amazing that XU4 gets as far as it does, given how much of this
code simply doesn't work. Focusing now on getting everything converted to
FDT. Next up USB and clocks. After that nuke everything that's not needed
and start the port in earnest.
This is broken. exynos_gpio_bank_config and the call to it are wrong, and
the acquire function doesn't work.
But I'm in over my head and I need to discuss this:
There is a problem with the dtd: it doesn't have addresses for the individual
gpios. Do I add the addresses to it, or go back to the old version where I
have them hard coded in the driver.
There is a problem with creating the gpio device entries: I suspect I really
need to treat the pinctrl devices as busses and create the gpios as attached
to those busses, but I'm not familiar with how to do that in NetBSD. At the
minimum, a pointer to a similar situation would give me code to follow.
This is different than the usual bus attachment in that the gpios aren't
devices in the dtd (they don't have "compatible" properties) so they don't
get an attach routine called. An alternative to generating the bus
attachments might be to add "compatible" properties to the GPIO entries
in the dtd. so that they do get attached in the normal way.
If I'm going to modify the DTD, then it should be checked in, so a decision
on where to check them in would be nice, even if it does mean spreading them
all over because of license issues. (This DTD is GPL v2)
This is a mess and I don't understand why part of it works, but it passes
the basic test.
There has to be some better way to get the info that I'm grabbing from the
exynos_uarts[] array.
I'm not sure how to deal with VA != PA when the DTB contains physical rather
than virtual addresses. This is going to be an issue for all of the drivers.
The watchdog timer is the most trivial driver in exynos, from the POV of
converting to FDT, so go ahead and do it first. NOTE: There's a hack in
the driver that needs to eventually be fixed -- the clock frequency is
hardwired when it should be gotten from the clock in the device tree. I'll
come back and fix this when I'm more comfortable with the api.
I got away with not having the generic bus tags for getting minimum fdt to
work; but for real drivers have to actually have them. Make necessary
corrections.
This enables the use of FDT on the XU4 but doesn't add any drivers. However,
with this check in, XU4 becomes useless without a device tree blob from the
Linux tree, which isn't checked in anywhere.
This will work only if the patch to sysmon_wdog.c to convert it to
MODULE_CLASS_DRIVER is installed. Symptom of failure is a crash in
lockdebug because of an uninitialized mutex.
Now, on CPUs that support this feature, if the kernel tries to execute
an instruction located in userland, the CPU will trigger a page fault.
Tested on amd64 (Intel Core i5).
This adds the GPIO aliases that will be used for board-independent driver
lookup until we have FDT.
The idea here is that each pin used by any driver is given a name that
the driver knows that is independent of the gpio bank name. The mapping
from the alias to the actual gpio bank + pin number is done in this file
and a lookup function is added to exynos_gpio.c that allows a driver to
ask for a gpio pin by the alias name, blisssfully unaware that there is
an underlying GPIO bank name.
Once set up with all the drivers, it should then be possible to move to a
different vendor's board simply by modifying exynos_machdep.c
I can't bring myself to fully nuke from orbit, so there are really two
things in this checkin:
1) A major rewrite of exynos_gpio.c, based mostly on the Nvidia
tegra_gpio.c file. This is missing a major function that will be
added the first time a customer for it is integrated, which is meant to
select pins based on aliases, rather than pin bank names.
2) A small number of changes to other files that keep the tree compiling
and progressing as far as ever; except it is now 5422 specific and
will not boot on the other exynos socs, which I don't have hardware to
test.
The choice to remove functionality is always controversial, but since
we are doing a significant rewrite and I don't have either
documentation or hardware *and* none of the code really works now
anyway, I'm taking the stance that only tested functionality should be
added, and that we'll layer the other exynos socs on this once it
fully boots.
create config files that use evbarm/exynos rather than evbarm/odroid for
the machdep portion.
point ODROID-XU4 at those files
add evbarm/exynos/exyos_{start.S, machdep.c} and platform.h that are exynos
5422 specific. -- We'll edit in other exynos platforms once this one
fully works.
This boots the Odroid XU4 to the same point as using evbarm/odroid does, but
with some differences in gpio handling. Everything else should be semantically
equivalent.
at boot. Update the list of supported frequencies to match the list of dvfs
frequencies from the meson8b dts, capped at 1.5GHz. The highest available
frequency is changed from 1512MHz to 1536MHz.
The Odroid XU4 is booted in hypervisor mode, probably because it is trust
zone enabled. Before we can put it in supervisor we must explicitly remove
it from hypervisor.
This change is from Nick, who figured it out and adapted code from FreeBSD
to make the necessary change.
KASSERT() that we don't.
When calculating the load address for the interpreter (e.g. ld.elf_so),
we need to take into account wether the exec'd process will run with
topdown memory or bottom up. We can not use the current vmspace's flags
to test for that, as this happens too early. Luckily the execpack already
knows what the new state will be later, so instead of testing the current
vmspace, pass the info as additional argument to struct emul
e_vm_default_addr.
Fix all such functions and adopt all callers.
XN (eXecute Never) appropriately.
The XN logic is inconsistent and could do with changing to XN always set
and cleared for VM_PROT_EXECUTE (or the inverse) everywhere.
Fixes dmesg on NetBSD/dreamcast 7.0 (and probably NetBSD/hpcsh 7.0):
---
NetBSD 7.0 (GENERIC.201509250726Z)
SEGA Dreamcasttotal memory = 16384 KB
avail memory = 13668 KB
---
which was mangled when cpu_getmode() and cpu_setmodel() were introduced:
http://mail-index.netbsd.org/source-changes/2014/03/24/msg053273.html
Should be pulled up to netbsd-7 and netbsd-7-0.
