summaryrefslogtreecommitdiffstats
path: root/sys/arch/armv7 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Fix Dale's email addresstb2021-04-023-6/+6
| | | | ok drahn
* remove uneeded includes in md armv7 filesjsg2021-03-2542-178/+42
| | | | based on include-what-you-use suggestions
* Node without a "status" property should be considered enabled as well.kettenis2021-03-161-3/+3
| | | | Same change made to arm64 a week ago.
* Make sure that switching the console from serial to framebuffer workskettenis2021-03-162-22/+25
| | | | | | for framebuffer nodes under / and /chosen. Same change made to arm64 last month.
* spellingjsg2021-03-1110-20/+20
|
* grow media a littlederaadt2021-03-111-2/+2
|
* Add some infrastructure in the PCI chipset tag for pci_probe_device_hook()patrick2021-02-252-2/+18
| | | | | | so that we can provide IOMMU-hooked bus DMA tags for each PCI device. ok kettenis@
* we don't have to cast to caddr_t when calling m_copydata anymore.dlg2021-02-251-2/+2
| | | | | | | | | | | | | | | | the first cut of this diff was made with coccinelle using this spatch: @rule@ type caddr_t; expression m, off, len, cp; @@ -m_copydata(m, off, len, (caddr_t)cp) +m_copydata(m, off, len, cp) i had fix it's opinionated idea of formatting by hand though, so i'm not sure it was worth it. ok deraadt@ bluhm@
* timecounting: use C99-style initialization for all timecounter structscheloha2021-02-233-6/+26
| | | | | | | | | | | | | | | | | | The timecounter struct is large and I think it may change in the future. Changing it later will be easier if we use C99-style initialization for all timecounter structs. It also makes reading the code a bit easier. For reasons I cannot explain, switching to C99-style initialization sometimes changes the hash of the resulting object file, even though the resulting struct should be the same. So there is a binary change here, but only sometimes. No behavior should change in either case. I can't compile-test this everywhere but I have been staring at the diff for days now and I'm relatively confident this will not break compilation. Fingers crossed. ok gnezdo@
* Enable clocks and adjust for removal of subnodes in upstream Linuxkettenis2021-02-141-2/+4
| | | | device trees.
* Enable clocks.kettenis2021-02-141-1/+4
|
* Raise match priority to beat syscon(4).kettenis2021-02-141-39/+81
| | | | | | | Use the right clock for the Cortex-A7 cores. Support CPU clocks and remove exclock_cpuspeed(). ok patrick@
* Recent device trees have the syscon-reboot and syscon-poweroff nodes askettenis2021-02-142-11/+22
| | | | | | | children of the node claimed by expower(4). That node also fained a "syscon" compatible in the process. Deal with these changes, ok patrick@
* Move exuart(4) to sys/dev/fdt so it can be shared between arm64 and armv7.patrick2021-02-053-1057/+1
| | | | ok kettenis@
* exuart(4) does not need to include exclockvar.h. The header seems to onlypatrick2021-02-041-2/+1
| | | | provide a function for the I2C clock frequency, used by exiic(4).
* Tedu exuartvar.h, which has not been needed since we switched to the "newpatrick2021-02-042-20/+1
| | | | way" of attaching the console.
* Add missing CVS tag.patrick2021-02-041-0/+1
|
* Add uhidpp(4), a driver for Logitech HID++ devices. Currently limited toanton2021-02-041-1/+2
| | | | | | | | | exposing battery sensors for HID++ 2.0 devices. Most of the code is derived from the hid-logitech-hidpp Linux driver. Thanks to Ville Valkonen <weezeldinga at gmail dot com> for testing. ok mglocker@
* Again allow COPTS= to come from the environment again, and don't lose thederaadt2021-01-281-4/+4
| | | | | SMALL_KERNEL specific variations. ok espie jsg
* introduce ujoy(4), a restricted subset of uhid(4) for gamecontrollers.thfr2021-01-231-1/+2
| | | | | | | | This includes ujoy_hid_is_collection() to work around limitations of hid_is_collection() until this can be combined without fallout. input, testing with 8bitdo controller, and ok brynet@ PS4 controller testing, fix for hid_is_collection, and ok mglocker@
* s/KHZ/kHz/ and reduce dmesg spam a bitkettenis2021-01-196-15/+15
| | | | ok tb@, deraadt@
* Remove some unused #defines and remove some commented-out variables.kettenis2021-01-191-6/+1
|
* Use daddr_t and not daddr32_t in boot media.krw2020-12-096-12/+12
| | | | | | | | | | At a minimum, amd64/i386 should now boot from 4TB GPT formatted disks. More daddr32_t terminations with extreme prejudice to follow. Tested by various, in snaps for a few days. ok deraadt@
* Give armv7 a <machine/cpufunc.h> header and use it to add a prototypekettenis2020-11-291-0/+16
| | | | | | for smc_call(). ok patrick@
* Re-work intr_barrier(9) on arm64 to remove layer violation. So far wepatrick2020-07-171-1/+2
| | | | | | | | | | | have stored the struct cpu_info * in the wrapper around the interrupt handler cookie, but since we can have a few layers inbetween, this does not seem very nice. Instead have each and every interrupt controller provide a barrier function. This means that intr_barrier(9) will in the end be executed by the interrupt controller that actually wired the pin to a core. And that's the only place where the information is stored. ok kettenis@
* Implement pci_intr_establish_cpu() on arm64 and armv7. The function pointerpatrick2020-07-142-12/+13
| | | | | | | | | | | | in the chipset tag for establishing interrupts now takes a struct cpu_info *. The normal pci_intr_establish() macro passes NULL as ci, which indicates that the primary CPU is to be used. The PCI controller drivers can then simply pass the ci on to our arm64/armv7 interrupt establish "framework". Prompted by dlg@ ok kettenis@
* Extend the interrupt API on arm64 and armv7 to be able to pass aroundpatrick2020-07-148-64/+129
| | | | | | | | | | | | | | | | | | | | | | | | a struct cpu_info *. From a driver point of view the fdt_intr_establish_* API now also exist same functions with a *_cpu suffix. Internally the "old" functions now call their *_cpu counterparts, passing NULL as ci. NULL will be interpreted as primary CPU in the interrupt controller code. The internal framework for interrupt controllers has been changed so that the establish methods provided by an interrupt controller function always takes a struct cpu_info *. Some drivers, like imxgpio(4) and rkgpio(4), only have a single interrupt line for multiple pins. On those we simply disallow trying to establish an interrupt on a non-primary CPU, returning NULL. Since we do not have MP yet on armv7, all armv7 interrupt controllers do return NULL if an attempt is made to establish an interrupt on a different CPU. That said, so far there's no way this can happen. If we ever gain MP support, this is a reminder that the interrupt controller drivers have to be adjusted. Prompted by dlg@ ok kettenis@
* Use the full 32 bits for the miscellaneous armv7 timecounters.naddy2020-07-121-2/+2
| | | | | | | | | Checked against * ARM Architecture Reference Manual (agtimer) * ARM Cortex-A9 MPCore Technical Reference Manual (amptimer) * OMAP35x Applications Processor Technical Reference Manual (gptimer) Artturi Alm had independently suggested this in the past.
* Change users of IFQ_SET_MAXLEN() and IFQ_IS_EMPTY() to use the "new" API.patrick2020-07-102-5/+5
| | | | ok dlg@ tobhe@
* Change users of IFQ_DEQUEUE(), IFQ_ENQUEUE() and IFQ_LEN() to use thepatrick2020-07-101-2/+2
| | | | | | "new" API. ok dlg@ tobhe@
* Add support for timeconting in userland.pirofti2020-07-063-4/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | This diff exposes parts of clock_gettime(2) and gettimeofday(2) to userland via libc eliberating processes from the need for a context switch everytime they want to count the passage of time. If a timecounter clock can be exposed to userland than it needs to set its tc_user member to a non-zero value. Tested with one or multiple counters per architecture. The timing data is shared through a pointer found in the new ELF auxiliary vector AUX_openbsd_timekeep containing timehands information that is frequently updated by the kernel. Timing differences between the last kernel update and the current time are adjusted in userland by the tc_get_timecount() function inside the MD usertc.c file. This permits a much more responsive environment, quite visible in browsers, office programs and gaming (apparently one is are able to fly in Minecraft now). Tested by robert@, sthen@, naddy@, kmos@, phessler@, and many others! OK from at least kettenis@, cheloha@, naddy@, sthen@
* match on "ti,am335-sdhci" used since linux 5.8-rc3jsg2020-07-051-3/+5
|
* Remove obsolete <machine/stdarg.h> header. Nowadays the varargvisa2020-06-301-4/+0
| | | | | | | | functionality is provided by <sys/stdarg.h> using compiler builtins. Tested in a ports bulk build on amd64 by naddy@ OK naddy@ mpi@
* Enable virtual consoles on armv7, the same way it is done on arm64.fcambus2020-06-231-3/+3
| | | | | | Tested on a Cubieboard2. OK patrick@
* Enable bwfm(4) on armv7 RAMDISK for SD/MMC and USB devices.fcambus2020-06-181-1/+3
| | | | OK patrick@
* use correct node when enabling phyjsg2020-06-021-3/+2
| | | | ok kettenis@
* introduce "cpu_rnd_messybits" for use instead of nanotime in dev/rnd.c.dlg2020-05-311-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | rnd.c uses nanotime to get access to some bits that change quickly between events that it can mix into the entropy pool. it doesn't use nanotime to get a monotonically increasing set or ordered and accurate timestamps, it just wants something with bits that change. there's been discussions for years about letting rnd use a clock that's super fast to read, but not necessarily accurate, but it wasn't until recently that i figured out it wasn't interested in time at all, so things like keeping a fast clock coherent between cpu cores or correct according to ntp is unecessary. this means we can just let rnd read the cycle counters on cpus and things will be fine. cpus with cycle counters that vary in their speed and arent kept consistent between cores may even be desirable in this context. so this is the first step in converting rnd.c to reading cycle counter. it copies the nanotime backend to each arch, and they can replace it with something MD as a second step later on. djm@ suggested rnd_messybytes, but we landed on cpu_rnd_messybits. thanks to visa for his eyes. ok deraadt@ visa@ deraadt@ says he will help handle any MD fallout that occurs.
* dev/rndvar.h no longer has statistical interfaces (removed during variousderaadt2020-05-291-2/+1
| | | | | | conversion steps). it only contains kernel prototypes for 4 interfaces, all of which legitimately belong in sys/systm.h, which are already included by all enqueue_randomness() users.
* increment version numbers, due to recent RB_GOODSEED and fchmod +T changesderaadt2020-05-261-2/+2
|
* change wsdisplay attribute type from long to uint32_tjsg2020-05-253-11/+11
| | | | | | | | miod explained it was initially a long as it was thought drivers may need to allocate storage but in practice they don't need more than 32 bits for an attribute. suggested and reviewed by miod@
* rename wsdisplay alloc_attr() to pack_attr()jsg2020-05-252-5/+5
| | | | | | | | Suggested by John Carmack. miod agrees a rename would make sense and explained it was initially thought drivers may need to allocate storage but in practice they don't need more than 32 bits for an attribute. ok mpi@
* Look at the openbsd,boothowto property and bring the bootarg parsingkettenis2020-05-231-26/+29
| | | | | | code in line with arm64. ok deraadt@
* Our check to see if the EFI services support Mtftp() doesn't workpatrick2020-05-182-5/+9
| | | | | | | | | | on U-Boot anymore, since we checked if the method is provided, but now U-Boot provides a simple stub that only returns EFI_UNSUPPORTED. A proper UEFI would throw EFI_INVALID_PARAMETER if we pass NULL as first parameter, but U-Boot doesn't. This way we can see if the method is actually provided and not just a stub. ok kettenis@
* Remove board ID support. 6.7 shipped with a kernel that doesn't needkettenis2020-05-174-34/+9
| | | | | | it anymore. jsg@
* The dwctwo(4) FDT glue is now identical on armv7 and arm64. Move it tokettenis2020-05-142-146/+1
| | | | | | /dev/fdt. ok patrick@, visa@
* Pass boothowto from the bootloader to the kernel by adding akettenis2020-05-103-6/+9
| | | | | | openbsd,boothowto property under /chosen. ok patrick@
* Enable a bunch of drivers needed for full Raspberry Pi 2/3 support.kettenis2020-04-292-4/+28
|
* Let the armv7 bus_dma layer and simplebus(4) implementation deal withkettenis2020-04-292-16/+4
| | | | | | | | | | | DMA remapping in the same way as arm64. This relies on the dma-ranges property in the device tree and allows us to get rid of the hack for the Raspberry Pi in the dwctwo(4) driver. Note that this does not include the hack in simplebus(4) that we have on arm64 since firmware that has the dma-ranges is in widespread use now. ok patrick@
* Add bcmclock(4) and bcmmbox(4). Fixes a hang because the clock for sdhc(4)kettenis2020-04-272-4/+8
| | | | can't be enabled.
* Remove reset hack; these days the U-Boot we ship for the CuBox-i iskettenis2020-04-271-10/+1
| | | | | | perfectly happy without it. ok patrick@
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.