On 2023-11-10, Anders Andersson <pipat...@gmail.com> wrote: > I'm running OpenBSD on my (recently EOL) APU4 and I'm wondering how > much of the "extra" hardware is expected to work on OpenBSD. > > 1) On the back of the board is a button "S1" and three status LEDs, > The documentation says they are handled by the AMD FCH south bridge. > Is there a way to control these in software from OpenBSD?
see gpio(4), gpioctl(8). you need to assign pins in rc.securelevel and can then control them after boot. while you're figuring out how to set it up in the first place, you might want to temporarily set kern.securelevel=-1 in sysctl.conf. > 2) There are 16 additional GPIO on a header, via the Nuvoton NCT5104D > chip on the LPC bus. I've seen a few patches circulating that mentions > gpio and the wbsio(4) driver but I could not figure out if anything > has been committed or not. AFAIK no: DESCRIPTION The wbsio driver provides support for the Winbond LPC Super I/O ICs. Only the hardware monitoring function is currently supported. > 3) There is a simple watchdog timer in the NCT5104D that can be > connected to the reset line. Would this be implemented? also AFAIK no. wbsio(4) has code to probe for the device these days so it's unlikely to be difficult for someone with an interest in such a thing to add support for watchdog and/or gpio. Look at other superio drivers which already have this functionality, in particular look at cvs history from when it was added. As far as device driver coding goes, adding GPIO/sensors/watchdog support to an existing driver for a device with an available datasheet is fairly straightforward and doesn't need deep coding skills. > Would this be implemented? I'm not sure > it's really useful, I assume there's an integrated watchdog in the > CPU. I don't think there's a watchdog in the cpu either. While I've used watchdogs in the past, my feeling is that they're not really a good fit for using with standard OpenBSD. OK so the machine reboots, but then what? You're probably going to hit an unclean filesystem (and if you're unlucky, it'll trigger during kernel relinking which takes place in the background - after watchdogd has started - which is both a time when it's more likely to happen as there's often memory pressure, and a time when filesystems are seeing more activity than usual). They seem better suited to a non-standard installation which avoids RW disk mounts. -- Please keep replies on the mailing list.