summaryrefslogtreecommitdiffstats
path: root/sys/arch/octeon (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Check outcome of loadrandom() on octeonvisa2020-05-262-11/+26
| | | | | | | | | | If loadrandom() succeeds, set RB_GOODRANDOM in boothowto. To enable fchmod(), disk_open() has to mount the filesystem in writable mode. This is tricky because the filesystem might be unclean. Hence the code has to use MNT_FORCE. Input and OK deraadt@
* Rework kernel loading with octboot(4)visa2020-05-263-47/+61
| | | | | | | | Load the kernel image from the filesystem upfront in rdboot and pass the loaded image to octboot(4)'s kexec call in a memory buffer. As a result, octboot(4) does not rely on a mounted filesystem. OK deraadt@
* that dependency change breaks something else. sigh.deraadt2020-05-251-3/+3
|
* Pass boothowto from the bootloader to the kernel on octeon.visa2020-05-252-13/+35
| | | | OK deraadt@
* Mix board information into the entropy pool.visa2020-05-251-1/+14
| | | | | | The data are static but they introduce differences between systems. OK deraadt@
* The dependencies were insufficient.deraadt2020-05-251-3/+3
|
* The dwctwo(4) FDT glue is now identical on armv7 and arm64. Move it tokettenis2020-05-141-2/+1
| | | | | | /dev/fdt. ok patrick@, visa@
* Fix some of the more esoteric bus_space functions. Thekettenis2020-04-141-7/+8
| | | | | | | | | | bus_space_read_region_n, bus_space_write_region_n and bus_space_set_region_n functions were all broken. Same fix as arm64; Thanks to patrick@ for noting that mips64 had the same code. ok visa@
* Update my email address.pirofti2020-04-061-2/+2
|
* wire up pppac(4) to some majors on each arch.dlg2020-01-231-1/+2
| | | | | | | | i was lazy and just put them at the end of the existing set. fyi, i think major 51 is free on all archs if anyone is looking for another one. ok claudio@
* Import dt(4) a driver and framework for Dynamic Profiling.mpi2020-01-211-2/+3
| | | | | | | | | | | The design is fairly simple: events, in the form of descriptors on a ring, are being produced in any kernel context and being consumed by a userland process reading /dev/dt. Code and hooks are all guarded under '#if NDT > 0' so this commit shouldn't introduce any change as long as dt(4) is disable in GENERIC. ok kettenis@, visa@, jasper@, deraadt@
* Convert various boolean_t/TRUE/FALSE to int/1/0 in mips64 memory code.visa2019-12-202-9/+9
| | | | OK mpi@
* Add fido(4), a HID driver for FIDO/U2F security keysreyk2019-12-172-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | While FIDO/U2F keys were already supported by the generic uhid(4) driver, this driver adds the first step to tighten the security of FIDO/U2F access. Specifically, users don't need read/write access to all USB/HID devices anymore and the driver also improves integration with pledge(2) and unveil(2): It is pledge-friendly because it doesn't require any ioctls to discover the device and unveil-friendly because it uses a single /dev/fido/* directory for its device nodes. It also allows to support FIDO/U2F in firefox without further weakening the "sandbox" of the browser. Firefox does not have a proper privsep design and many operations, such as U2F access, are handled directly by the main process. This means that the browser's "fat" main process needs direct read/write access to all USB HID devices, at least on other operating systems. With fido(4) we can support security keys in Firefox under OpenBSD without such a compromise. With this change, libfido2 stops using the ioctl to query the device vendor/product and just assumes "OpenBSD" "fido(4)" instead. The ioctl is still supported but there was no benefit in obtaining the vendor product or name; it also allows to use libfido2 under pledge. With feedback from deraadt@ and many others OK kettenis@ djm@ and jmc@ for the manpage bits
* this hexdump tie-in is incorrect, disable for nowderaadt2019-12-011-2/+2
|
* Implement a hexdump command in the boot loader. This helps tobluhm2019-11-281-1/+4
| | | | | | inspect the memory layout that the firmware has created. It is especially useful for UEFI debugging. OK deraadt@ kettenis@
* Retguard will start using sections named ".openbsd.randomdata.retguard.*"guenther2019-11-091-2/+9
| | | | | | | | | | | | | and not just ".openbsd.randomdata.retguard". Accept both in the kernel ldscripts so that they're placed together between the __retguard_{start,end} symbols. Similarly, match not just ".openbsd.randomdata" but also ".openbsd.randomdata.*" to pick up other random (pun intended) items. While here, stub in those retguard bits into all the ldscripts. ok deraadt@
* The compiler -pg option implies -fno-ret-protector, as we want to disableguenther2019-11-071-3/+3
| | | | | | | | | | | retguard and similar when profiling. However, that missed all the .S files, as ${PROF} wasn't added when ${NORMAL_S} was converted from direct invocation of ${AS} to instead use ${CC}. Similarly, mcount.o still had retguards as it cannot be built with -pg. So: pass ${PROF} when compiling .S files, and compile "no profiling" files with -fno-ret-protector on archs with retguard. feedback and ok mpi@ mortimer@
* Add ogx(4), a driver for the OCTEON III network processor.visa2019-11-047-3/+2711
| | | | | | | | | | | This network driver covers higher-end models of the OCTEON III family. They have a modified design whose interface is not compatible with the lower-end models or earlier chip generations. The code is still a work in progress. However, it is capable enough to make the SGMII port functional on the CN7360. No objection from deraadt@
* Reduce BOOTRANDOM_MAX to 256. naddy pointed out there's no point havingderaadt2019-11-011-2/+2
| | | | | it larger than RC4STATE. A long discussion ensued. In conclusion all entropy inputs are either satisfactory enough, or just as shitty at 512.
* Use arc4 to bit-spread the 512-byte random buffer over the .openbsd.randomdataderaadt2019-10-292-4/+4
| | | | | | | | | section, which has grown a fair bit with the introduction of retguard. Mortimer discovered the repeated 512-byte sequence as retguard keys, and this resolves the issue. (Chacha does not fit on the media, so 1.5K early drop RC4 is hopefully sufficient in our KARL link universe) Version crank the bootblocks. sysupgrade -s will install new bootblocks. ok djm mortimer
* octmmc(4): msleep(9) -> msleep_nsec(9); ok visa@ kn@cheloha2019-10-071-4/+4
|
* Configure USB port power control if the power GPIO is defined in fdt.visa2019-09-291-5/+31
|
* Add option to configure GPIO output select.visa2019-09-292-5/+26
|
* rename the 'cn30xx' drivers to just 'oct', because digits inside devicesderaadt2019-09-288-38/+38
| | | | drivers is gross. discussed with visa.
* Enable eephy(4) on octeon.visa2019-09-242-2/+4
| | | | OK deraadt@
* Remove unused register dump lists.visa2019-09-221-59/+1
|
* Simplify stat register access.visa2019-09-222-7/+5
|
* Ignore non-host ports silently.visa2019-09-221-5/+2
|
* Remove an unused function.visa2019-09-202-16/+2
|
* Pass interface number as an explicit parameter to avoid decoding.visa2019-09-201-5/+5
|
* Attach packet interfaces to octpip to use fdt.visa2019-09-155-37/+12
|
* Add a driver for the packet input processing unit. For now, the purposevisa2019-09-152-1/+97
| | | | of this piece of code is to facilitate the use of fdt.
* Add the pip unit into the fdt blob.visa2019-09-152-9/+95
|
* Enable nvme(4) on octeon.visa2019-09-073-3/+12
|
* Add a driver for the PCIe controller found on OCTEON II and OCTEON III.visa2019-09-077-6/+902
|
* Implement splassert() on mips64.visa2019-09-051-1/+17
|
* Adjust interrupt priority levels on mips64 so that prioritiesvisa2019-09-051-23/+20
| | | | | | of soft interrupts are lower than priorities of hard interrupts. This allows the delivery of hard interrupts while soft interrupts are masked.
* Remove DST/TIMEZONE options(4) from kernel configs; ok jca@ deraadt@cheloha2019-09-042-6/+2
|
* Make it clearer where message "spurious interrupt" comes from.visa2019-09-013-8/+11
|
* Ensure that a posted write completes when re-enabling interruptsvisa2019-08-041-3/+7
| | | | or sending an IPI.
* Remove the old, unfinished octeon bootloader.visa2019-08-049-715/+0
|
* Revise the way how the octeon bootloader is built. The originalvisa2019-08-043-18/+36
| | | | | | approach was not right, and there is still room for improvement. OK deraadt@
* Fix fd leak that broke disk_close().visa2019-08-011-1/+2
|
* Fix kmem access on octeon. Currently, mem_layout lists segments thatvisa2019-07-311-1/+7
| | | | | | | were free after the kernel was loaded. The memory occupied by the kernel image is not included. To let libkvm access the image through /dev/kmem, return true from is_memory_range() if the physical address is within the kernel.
* Link octeon bootloader to the build.visa2019-07-283-10/+11
| | | | OK deraadt@
* Add a dedicated ramdisk entry for the octeon bootloader to reducevisa2019-07-281-2/+2
| | | | | | the size of the "boot" file. OK deraadt@
* With the DWC2 reset in place, dwctwo(4) should be safe to usevisa2019-07-281-3/+3
| | | | in the bootloader.
* Put DWC2 controller into reset mode on (pseudo-)shutdown to makevisa2019-07-281-1/+38
| | | | kernel handover safer.
* Fix trimming of newline.visa2019-07-281-2/+5
|
* Disable for now.visa2019-07-171-3/+3
|
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.