| #
fea0c645 |
| 23-Jan-2025 |
brad <brad@NetBSD.org> |
A driver for the DS28E17 1-Wire to I2C bridge chip.
This chip acts like a 1-Wire slave device and provides a iic(4) master at the end of the 1-Wire bus. More or less it is the polar opposite of the
A driver for the DS28E17 1-Wire to I2C bridge chip.
This chip acts like a 1-Wire slave device and provides a iic(4) master at the end of the 1-Wire bus. More or less it is the polar opposite of the DS2482 [ds2482ow(4)] chip.
This device couples well with ds2482ow(4) and can be used to provide a I2C bus at very great lengths from the controlling computer.
All features of the chip are supported, except for 1-Wire overdrive support, which requires more work from the onewire(4) infrastructure.
The chip does not support Read without Stop. Attempts to do this will get turned into a Read with Stop and one will have to hope for the best. The chip also does not support zero length I2C reads or zero length I2C writes. This has the side effect of making the default mode, a zero length I2C write, for i2scan(8) return false positives. The alternative mode that i2cscan(8) can use, the single byte read, should work as expected.
The chip has automatic support for end devices that do I2C clock stretching.
It was noticed that this chip does not work with the gpioow(4) driver. That might be an interesting thing to debug if one has a good logic analyzer on hand. While the presence pulse is detected, the gpioow(4) driver is not able to complete the initial ROM enumeration. The DS28E17 works flawlessly when driven by a DS2482 [ds2482ow(4)] driver chip. Poke me if you want any more details.
The chip is pretty inexpensive and only requires a single cap to get it hooked up. However, the package it comes in is only a 16-QFN package, so it could provide to be hard to solider onto a board for some. There are side tabs, so it was possible with a very small iron and lots of flux. There is a slightly expensive breakout board sold by Mikroe that probably works well -> https://www.mikroe.com/1-wire-i2c-click
show more ...
|
| #
8d3fa1ac |
| 20-Jan-2025 |
maya <maya@NetBSD.org> |
Add ncm(4) a driver for USB Network Control Model
Seen on my Google Pixel 8, which implements ncm instead of urndis.
|
| #
93180daf |
| 04-Nov-2024 |
brad <brad@NetBSD.org> |
Add a driver for the Maxim DS2482-100 and DS2482-800 I2C to 1-Wire bridge.
This chip provides a I2C device that then has 1 or 8 1-Wire busses on the other side. The 1-Wire buses show up as onewire(
Add a driver for the Maxim DS2482-100 and DS2482-800 I2C to 1-Wire bridge.
This chip provides a I2C device that then has 1 or 8 1-Wire busses on the other side. The 1-Wire buses show up as onewire(4) buses in the NetBSD.
The chip can be used in situations where:
* You have a I2C bus extended a long distance, say with a LTC4311 active terminator / extender or one of the differential I2C extenders and you would like to have a 1-Wire device on the far end and it isn't possible to add wiring to get to the far end.
* You are either out of GPIO pins or the GPIO pins are not reliable enough to use gpioow(4), but you do have working I2C.
The DS2482 does all of the 1-Wire signals in hardware and provides for a couple of pullup options for the 1-Wire devices.
All of the functions of the DS2482-100 and -800 are supported except for overdrive speed support. To do this will likely require some API changes to onewire(4).
Breakout boards exist for the DS2482 for both variants, but they appear to be more expensive than expected. The chip itself is quiet cheap and wasn't all that hard to SMD solder to a board. No other components are really needed.
There are other members in the same family, the DS2482-101, DS2484 and DS2485. The DS2482-101 has a sleep pin, but from the datasheet appears to program the same as the -100 variant. The DS2484 has a slightly different way to set configuration information and probably won't quite work with the driver, but isn't far off. The DS2485 is very different and would require a new driver to function.
show more ...
|
| #
375351f4 |
| 26-Aug-2024 |
riastradh <riastradh@NetBSD.org> |
acpivmgenid(4): New driver for virtual machine generation ID.
Added to amd64/ALL and i386/ALL kernel configurations, and made available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: A
acpivmgenid(4): New driver for virtual machine generation ID.
Added to amd64/ALL and i386/ALL kernel configurations, and made available as a loadable module acpivmgenid.kmod on x86, for now.
TBD: Add to all ACPI-supporting GENERIC kernels.
PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM fork
show more ...
|
| #
0a864b32 |
| 18-Jul-2024 |
rin <rin@NetBSD.org> |
modules: Build `ipl` module only if MKIPFILTER is enabled
|
| #
8f43f9fe |
| 20-May-2024 |
pgoyette <pgoyette@NetBSD.org> |
Oooppss remove some local change that was accidentally committed
|
| #
210acb05 |
| 20-May-2024 |
pgoyette <pgoyette@NetBSD.org> |
Don't build the compat_110 module yet - there's no release_110 with which we can be compatable.
|
| #
67daa9c8 |
| 20-May-2024 |
riastradh <riastradh@NetBSD.org> |
sys/modules: Don't make compat_110.
Eventually we'll need this but it doesn't make sense until 11.0 is released.
|
| #
381b1356 |
| 19-May-2024 |
christos <christos@NetBSD.org> |
version dup3
|
| #
3dc92541 |
| 09-May-2024 |
pho <pho@NetBSD.org> |
port-arm/58194: Resurrect vmt(4) from bitrot
On this architecture vmt(4) used to search for a node "/hypervisor" in the FDT and probed the VMware hypervisor call only when the node was found. Howeve
port-arm/58194: Resurrect vmt(4) from bitrot
On this architecture vmt(4) used to search for a node "/hypervisor" in the FDT and probed the VMware hypervisor call only when the node was found. However, things appear to have changed and VMware no longer provides the FDT node.
Since vmt(4) doesn't actually need to read anything from FDT, and the hypervisor call logically resides in virtual CPUs themselves, it would be better to attach it directly to cpu, just like how it's probed on x86.
show more ...
|
| #
2dda1941 |
| 02-Apr-2024 |
riastradh <riastradh@NetBSD.org> |
bsd.own.mk: Enable MKLSJIT on aarch64.
Make sure there's only one copy of the conditional, in bsd.own.mk; just make sys/modules/Makefile conditional on MKSLJIT so we don't have to keep these in sync
bsd.own.mk: Enable MKLSJIT on aarch64.
Make sure there's only one copy of the conditional, in bsd.own.mk; just make sys/modules/Makefile conditional on MKSLJIT so we don't have to keep these in sync.
As a workaround for PR 58106, tweak the conditional definition of SLJIT_CACHE_FLUSH to use cpu_icache_sync_range only in _HARDKERNEL, and use __builtin___clear_cache in userland and in rump kernels.
PR 58103: bpfjit.kmod is not built on aarch64
show more ...
|
| #
40cfbdd6 |
| 21-Mar-2024 |
riastradh <riastradh@NetBSD.org> |
acpihed(4): New driver for PNP0C33 to notify apei(4).
PNP0C33 denotes the ACPI Hardware Error Device, which exists only to be a vector for event notifications.
PR kern/58046
|
| #
4b159fe5 |
| 20-Mar-2024 |
riastradh <riastradh@NetBSD.org> |
apei(4): New driver for ACPI Platform Error Interfaces.
For now it is wired up only in x86 ALL kernels, and built as a module for x86 and Arm. Once it gets a little more testing on machines with AP
apei(4): New driver for ACPI Platform Error Interfaces.
For now it is wired up only in x86 ALL kernels, and built as a module for x86 and Arm. Once it gets a little more testing on machines with APEI, I would like to flip it on by default.
PR kern/58046
show more ...
|
| #
cec94d4f |
| 09-Mar-2024 |
mrg <mrg@NetBSD.org> |
skip this subdir for "make includes".
it's excessively slow and does nothing (nor should it.)
|
| #
dd048da8 |
| 26-Dec-2023 |
pgoyette <pgoyette@NetBSD.org> |
Unhook radeondrm module from the build; it doesn't work, and it's just tempting someone to try it. Leave the files around in case someone wants to pursue making this work.
Should address kern/57793
Unhook radeondrm module from the build; it doesn't work, and it's just tempting someone to try it. Leave the files around in case someone wants to pursue making this work.
Should address kern/57793
XXX Related modules from the same legacy era should probably be XXX removed, too, but so far only radeondrm has been reported XXX as an issue. Kep an eye out for sisdrm, savagedrm, tdfxdrm, XXX and r128drm.
show more ...
|
| #
670e7745 |
| 27-Aug-2023 |
kardel <kardel@NetBSD.org> |
make owtemp a module
|
| #
2c4d4878 |
| 09-Aug-2023 |
andvar <andvar@NetBSD.org> |
viadrmums(4): build legacy VIA DRM UMS driver module for amd64.
This driver is not built-in by default, thus loadable module can help (un)lucky owners of 64-bit capable VIA (Nano/Eden) systems or ea
viadrmums(4): build legacy VIA DRM UMS driver module for amd64.
This driver is not built-in by default, thus loadable module can help (un)lucky owners of 64-bit capable VIA (Nano/Eden) systems or early AMD/Intel systems with some VIA chipsets, which include VIA integrated graphics. I also boldly added product IDs for few later models from VX8xx/VX9xx chipsets without 3D support (DX9_0) to "expand" the driver support to more systems. Tested successfully basic functionality on VX800, and partially successfully on VX900 (on VX900 Xorg failed to initialize due to openchrome related issues, viadrmums attaches and it is by used the driver). Didn't test on VX855, I don't have one.
Pull up to netbsd-10 is needed.
show more ...
|
| #
75b842b8 |
| 07-May-2023 |
skrll <skrll@NetBSD.org> |
RISC-V support that works on QEMU with a single hart.
Thanks for Simon Burge for plic(4).
|
| #
7b522c96 |
| 13-Apr-2023 |
riastradh <riastradh@NetBSD.org> |
sys/modules/Makefile: Use MACHINE_CPU, not MACHINE_ARCH, for aarch64.
This way it covers both little-endian and big-endian.
|
| #
d5970c6d |
| 11-Apr-2023 |
riastradh <riastradh@NetBSD.org> |
aarch64: Build drm modules.
|
| #
189762b3 |
| 19-Dec-2022 |
pgoyette <pgoyette@NetBSD.org> |
Create compat_100 module infrastructure now that we have branched for NetBSD-10
|
| #
50bb9ed1 |
| 03-Dec-2022 |
brad <brad@NetBSD.org> |
Split the BMP280 / BME280 driver into common code and create I2C and SPI attachments.
|
| #
068b504f |
| 21-Nov-2022 |
brad <brad@NetBSD.org> |
A driver for the Bosch BMP280 / BME280 temperature, humidity and atmospheric pressure sensor. This is an inexpensive to moderately expensive chip available from a large number of places. The driver
A driver for the Bosch BMP280 / BME280 temperature, humidity and atmospheric pressure sensor. This is an inexpensive to moderately expensive chip available from a large number of places. The driver supports all aspects of the two chips, except for the repeating read mode which would allow for sub-second queries, such as fall detection or perhaps even as an altimeter. This driver also only supports the I2C interface and not the SPI interface.
The BME280, the one with humidity, is not fully tested at this point, awaiting upon a breakout board and may not show proper humidity.
show more ...
|
| #
50bf6d2d |
| 17-Nov-2022 |
brad <brad@NetBSD.org> |
A driver for the Aosong AHT20 temperature and humidity sensor. While slow for an I2C sensor it is inexpensive and should work well enough in most indoor conditions. All features of the chip are sup
A driver for the Aosong AHT20 temperature and humidity sensor. While slow for an I2C sensor it is inexpensive and should work well enough in most indoor conditions. All features of the chip are supported.
show more ...
|
| #
6e81fb1e |
| 07-Sep-2022 |
martin <martin@NetBSD.org> |
Move emuxki from i386/amd64 specific modules to attachment specific modules (effectively disabling it for the build for now, as it needs setlist fixes and breaks the build).
|