Re: gpio(4) support for APU2
On Tue, Jun 29, 2021 at 04:22:47AM +0100, Chris Narkiewicz wrote: > On Wed, Jan 29, 2020 at 10:47:28PM +0800, Nathanael Rensen wrote: > > The diff below adds gpio(4) support to wbsio(4) for Nuvoton NCT5104D > > (pcengines APU2). > > I'm resurrecting this thread. I was looking for GPIO support for APU2 > board and found this patch in archives. I solved the problem of controlling the LEDs in the APU2 using a daemon started from /etc/securelevel and then writing 1-char commands to it over a FIFO. I also created a pull request of that solution for PCEngines' apu_gpio_lib, as a code example, but they have not managed to prioritize it: https://github.com/pcengines/apu_gpio_lib/pull/4 / Raimo Niskanen > > Any chance of taking it in? > > Patch below: > > > It is based on Matt Dainty's diff posted to this list > > in November 2018: > > > > https://marc.info/?l=openbsd-tech=154134941027009=2 > > > > A key difference from Matt Dainty's original diff is the use of > > config_search() rather than config_found() to avoid problems with > > the lm78 driver mentioned in his post. > > > > Nathanael > > > > Index: sys/dev/isa/wbsioreg.h > > === > > RCS file: /cvs/src/sys/dev/isa/wbsioreg.h,v > > retrieving revision 1.5 > > diff -u -p -r1.5 wbsioreg.h > > --- sys/dev/isa/wbsioreg.h 17 Dec 2019 01:34:59 - 1.5 > > +++ sys/dev/isa/wbsioreg.h 29 Jan 2020 14:30:28 - > > @@ -30,8 +30,15 @@ > > > > /* Configuration Space Registers */ > > #define WBSIO_LDN 0x07/* Logical Device Number */ > > +#define WBSIO_MF 0x1c/* Multi Function Selection */ > > +#define WBSIO_MF_UARTD (1 << 2) > > +#define WBSIO_MF_UARTC (1 << 3) > > +#define WBSIO_MF_GP67 (1 << 4) > > #define WBSIO_ID 0x20/* Device ID */ > > #define WBSIO_REV 0x21/* Device Revision */ > > +#define WBSIO_CR27 0x27/* Global Option */ > > +#define WBSIO_SF 0x2f/* Strapping Function */ > > +#define WBSIO_LDN_EN 0x30/* Logical Device Enable */ > > > > #define WBSIO_ID_W83627HF 0x52 > > #define WBSIO_ID_W83627THF 0x82 > > @@ -52,8 +59,38 @@ > > #define WBSIO_ID_NCT6795D 0xd3 > > > > /* Logical Device Number (LDN) Assignments */ > > +#define WBSIO_LDN_GPIO10x07 > > +#define WBSIO_LDN_WDT 0x08 > > +#define WBSIO_LDN_GPIO20x09/* Not used */ > > #define WBSIO_LDN_HM 0x0b > > +#define WBSIO_LDN_GPIO30x0f > > > > /* Hardware Monitor Control Registers (LDN B) */ > > #define WBSIO_HM_ADDR_MSB 0x60/* Address [15:8] */ > > #define WBSIO_HM_ADDR_LSB 0x61/* Address [7:0] */ > > + > > +/* GPIO Control Registers (LDN 7) */ > > +/* GPIOn registers are offset by n*4 bytes */ > > +#define WBSIO_GPIO_IO 0xe0/* GPIO Direction */ > > +#define WBSIO_GPIO_DATA0xe1/* GPIO Data */ > > +#define WBSIO_GPIO_INVERT 0xe2/* GPIO Invert */ > > +#define WBSIO_GPIO_STATUS 0xe3/* GPIO Status */ > > +#define WBSIO_GPIO0_EN (1 << 0) > > +#define WBSIO_GPIO1_EN (1 << 1) > > +#define WBSIO_GPIO6_EN (1 << 6) > > +#define WBSIO_GPIO0_NPINS 8 > > +#define WBSIO_GPIO1_NPINS 8 > > +#define WBSIO_GPIO6_NPINS 1 > > +#define WBSIO_GPIO_NPINS (WBSIO_GPIO0_NPINS + WBSIO_GPIO1_NPINS + \ > > +WBSIO_GPIO6_NPINS) > > + > > +/* WDT Control Registers (LDN 8) */ > > +#define WBSIO_WDT_ENABLE 0x30 > > +#define WBSIO_WDT_CONTROL 0xf0 > > +#define WBSIO_WDT_COUNTER 0xf1 > > +#define WBSIO_WDT_MINUTE (1 << 3) > > +#define WBSIO_WDT_FAST (1 << 4) > > + > > +/* GPIO Control Registers (LDN F) */ > > +/* GPIOn register is offset by n bytes */ > > +#define WBSIO_GPIO_PP_OD 0xe0/* GPIO Push-Pull/Open Drain */ > > Index: sys/dev/isa/wbsio.c > > === > > RCS file: /cvs/src/sys/dev/isa/wbsio.c,v > > retrieving revision 1.11 > > diff -u -p -r1.11 wbsio.c > > --- sys/dev/isa/wbsio.c 17 Dec 2019 01:34:59 - 1.11 > > +++ sys/dev/isa/wbsio.c 29 Jan 2020 14:30:28 - > > @@ -23,11 +23,13 @@ > > #include > > #include > > #include > > +#include > > > > #include > > > > #inclu
Re: Clarify drand48() return values
On Sat, Dec 21, 2019 at 11:29:20PM +, Alexander Nasonov wrote:
> Ingo Schwarze wrote:
> > Looking at our code in lib/libc/stdlib/drand48.c, i conclude that
> > drand48(3) does return 0.0 with a probability of 2^-48.
>
> I looked at the code too and I have some comments.
>
> > More generally, the function returns a uniform distribution of
> > numbers from the set {2^-48 * n | n integer and 0 <= n < 2^48}.
>
> You don't need three ldexp calls to compose 2^-48 * n:
>
> uint64_t n = (uint64_t)xseed[2] << 32 | xseed[1] << 16 | xseed[0];
> return ldexp((double)n, -48);
>
> > Talking about loading bits into the mantissa and adjusting the
> > exponent feels mildly confusing, given that the distribution is
> > simply uniform over a fixed finite set. I'm not sending a patch
> > because i never looked at how floating point representation works
> > internally, so i would likely only make matters worse.
>
> Not sure if you wanted to patch the man page or the code.
>
> If the latter, take a binary representation of 1.0 and replace 52
> least significant bits with (pseudo)random bits then subtract 1.0.
>
> double d = 1.0;
> uint64_t u = 0;
> memcpy(, , sizeof(d));
> u |= n << 4; /* scale 48 bits to 52 bits, n is from the previous
> snippet */
> memcpy(, , sizeof(u));
> return d - 1.0;
>
> It will only work with IEEE 754 compliant doubles, though.
A very clear way to generate an equidistributed floating point number in
the range [0.0, 1.0) given a number n in the range [0, 2^48-1] is simply:
return n * 0x1.0p-48
Requiring only C99 and .
>
> --
> Alex
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sysupgrade: Allow to use another directory for the sets
-u -u -r1.10 sysupgrade.8
--- sysupgrade.83 Oct 2019 12:43:58 - 1.10
+++ sysupgrade.821 Nov 2019 09:07:33 -
@@ -24,6 +24,7 @@
.Nm
.Op Fl fkn
.Op Fl r | s
+.Op Fl d Ar directory
.Op Ar installurl
.Sh DESCRIPTION
.Nm
@@ -32,9 +33,7 @@
to the next release or a new snapshot if available.
.Pp
.Nm
-downloads the necessary files to
-.Pa /home/_sysupgrade ,
-verifies them with
+downloads the necessary files, verifies them with
.Xr signify 1 ,
and copies bsd.rd to
.Pa /bsd.upgrade .
@@ -43,8 +42,7 @@
by default then reboots the system.
The bootloader will automatically choose
.Pa /bsd.upgrade ,
-triggering a one-shot upgrade using the files in
-.Pa /home/_sysupgrade .
+triggering a one-shot upgrade using the downloaded files.
.Pp
The options are as follows:
.Bl -tag -width Ds
@@ -53,8 +51,7 @@
The default is to upgrade to latest snapshot only if available.
This option has no effect on releases.
.It Fl k
-Keep the files in
-.Pa /home/_sysupgrade .
+Keep the downloaded files.
By default they will be deleted after the upgrade.
.It Fl n
Fetch and verify the files and create
@@ -66,6 +63,12 @@
.It Fl s
Upgrade to a snapshot.
This is the default if the system is currently running a snapshot.
+.It Fl d Ar directory
+Choose the
+.Ar directory
+in which the sets will be downloaded.
+Default is
+.Pa /home/_sysupgrade .
.El
.Sh FILES
.Bl -tag -width "/auto_upgrade.conf" -compact
@@ -77,7 +80,7 @@
.Ox
mirror top-level URL for fetching an upgrade.
.It Pa /home/_sysupgrade
-Directory the upgrade is downloaded to.
+Default directory the upgrade is downloaded to.
.El
.Sh SEE ALSO
.Xr signify 1 ,
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.25
diff -u -u -r1.25 sysupgrade.sh
--- sysupgrade.sh 28 Sep 2019 17:30:07 - 1.25
+++ sysupgrade.sh 21 Nov 2019 09:07:44 -
@@ -25,7 +25,6 @@
export PATH=/usr/bin:/bin:/usr/sbin:/sbin
ARCH=$(uname -m)
-SETSDIR=/home/_sysupgrade
ug_err()
{
@@ -34,7 +33,7 @@
usage()
{
- ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
+ ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-d directory] [installurl]"
}
unpriv()
@@ -70,19 +69,24 @@
echo -n "$_c"
}
+SETSDIR=/home/_sysupgrade
RELEASE=false
SNAP=false
FORCE=false
KEEP=false
REBOOT=true
-while getopts fknrs arg; do
+while getopts fknrsd: arg; do
case ${arg} in
f) FORCE=true;;
k) KEEP=true;;
n) REBOOT=false;;
r) RELEASE=true;;
s) SNAP=true;;
+ d) SETSDIR=$(readlink -f ${OPTARG})
+ if [[ $? -ne 0 ]] || [[ ${SETSDIR} = / ]]; then
+ ug_err "${OPTARG}: bad parameter value for -d"
+ fi;;
*) usage;;
esac
done
@@ -119,6 +123,7 @@
URL=${MIRROR}/${NEXT_VERSION}/${ARCH}/
fi
+[[ -e ${SETSDIR} ]] || mkdir -p ${SETSDIR}
if [[ -e ${SETSDIR} ]]; then
eval $(stat -s ${SETSDIR})
[[ $st_uid -eq 0 ]] ||
@@ -127,8 +132,6 @@
ug_err "${SETSDIR} needs to be owned by root:wheel"
[[ $st_mode -eq 040755 ]] ||
ug_err "${SETSDIR} is not a directory with permissions 0755"
-else
- mkdir -p ${SETSDIR}
fi
cd ${SETSDIR}
@@ -185,7 +188,7 @@
cat <<__EOT >/auto_upgrade.conf
Location of sets = disk
-Pathname to the sets = /home/_sysupgrade/
+Pathname to the sets = ${SETSDIR}/
Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes
__EOT
@@ -193,7 +196,7 @@
if ! ${KEEP}; then
CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
cat <<__EOT > /etc/rc.firsttime
-rm -f /home/_sysupgrade/{${CLEAN}}
+rm -f ${SETSDIR}/{${CLEAN}}
__EOT
fi
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sysupgrade: Allow to use another directory for the sets
On Tue, Nov 19, 2019 at 09:00:33AM +, Stuart Henderson wrote: > On 2019/11/18 14:45, Raimo Niskanen wrote: > > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > > > > > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > > > > > A configuration parameter could be accomplished through an optional > > > > symlink > > > > /etc/_sysupgrade that the sysadmin can create to point at the > > > > installation's > > > > sysupgrade directory. The sysupgrade script would test -s > > > > /etc/_sysupgrade > > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > > > > > > > As it was said earlier, this doesn't solve the removal issue. With your > > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > > > > > > > This is actually not yet in my patch. I just want to, as a first step > > towards either of our solutions, patch to have the /home/_sysupgrade literal > > in only one place in the sysupgrade script, which would facilitate patching > > the sysupgrade script before calling it, as a poor man's solution. > > Plus, the script gets cleaner. > > > > The symlink suggestion is a future patch. > > > > But I think your suggestion to instead specify the parent directory of the > > _syspatch directory should be sufficient to remedy the removal issue both > > for your command line suggestion, as for this future patch symlink > > suggestion. > > > > It is a pity nobody else has responded to that prefix suggestion of yours! > > It does avoid the removal issue but it seems an awkward user interface to > pass the parent directory. Perhaps better to enforce that the path matches > */_sysupgrade, though this also doesn't feel quite right. Perhaps add > /_sysupgrade if it wasn't already present... > > > I think the feature itself is more important than if it is implemented > > with a command line argument or a symlink. > > > > Other than that. What do you or anyone else think about my argument that > > the location of the system upgrade download directory is an installation > > configuration that will not change between upgrades and hence it would be > > nice to not have to remember the command line argument for every future > > sysupgrade. > > Generally agree, but I'm not keen on a proliferation of tiny pseudo-config > files, and this feels maybe part of something bigger. A similar argument > could be made for the choice of release/stable vs snaps (-s / -r here, > -Dsnap in pkg_add) which could be in some kind of "system config" alongside > source URLs (base, packages, firmware), a list of sets, maybe some pkg_add > related things (whether to install debug packages?), ... In that case, in the current state of the matter, since there is no such common config file yet, and all other tols use command line arguments for similar features, we should use a command line argument here too, like Renaud Allard proposes. Until there is a suitable config file. Since the prefix solution is regarded as awkward, and we want go guard against clumsy admins using / as sysupgrade directory which would remove kernels from the updated installation, why not normalize the -d argument with readlink -f and simply check that it is not / . There are of course othere directories that are inappropriate to use, but the person doing the upgrade has to be trusted to some degree... And I see no reason to not at least apply my minimalistic patch suggestion that simply defines the upgrade directory in only one place in sysupgrade. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sysupgrade: Allow to use another directory for the sets
On Tue, Nov 19, 2019 at 09:00:33AM +, Stuart Henderson wrote: > On 2019/11/18 14:45, Raimo Niskanen wrote: > > On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > > > > > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > > > > > A configuration parameter could be accomplished through an optional > > > > symlink > > > > /etc/_sysupgrade that the sysadmin can create to point at the > > > > installation's > > > > sysupgrade directory. The sysupgrade script would test -s > > > > /etc/_sysupgrade > > > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > > > > > > > As it was said earlier, this doesn't solve the removal issue. With your > > > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > > > > > > > This is actually not yet in my patch. I just want to, as a first step > > towards either of our solutions, patch to have the /home/_sysupgrade literal > > in only one place in the sysupgrade script, which would facilitate patching > > the sysupgrade script before calling it, as a poor man's solution. > > Plus, the script gets cleaner. > > > > The symlink suggestion is a future patch. > > > > But I think your suggestion to instead specify the parent directory of the > > _syspatch directory should be sufficient to remedy the removal issue both > > for your command line suggestion, as for this future patch symlink > > suggestion. > > > > It is a pity nobody else has responded to that prefix suggestion of yours! > > It does avoid the removal issue but it seems an awkward user interface to > pass the parent directory. Perhaps better to enforce that the path matches Yes. > */_sysupgrade, though this also doesn't feel quite right. Perhaps add > /_sysupgrade if it wasn't already present... Or, since readlink -f normalizes the path one could simply check that the result is not / which should fix the important case. > > > I think the feature itself is more important than if it is implemented > > with a command line argument or a symlink. > > > > Other than that. What do you or anyone else think about my argument that > > the location of the system upgrade download directory is an installation > > configuration that will not change between upgrades and hence it would be > > nice to not have to remember the command line argument for every future > > sysupgrade. > > Generally agree, but I'm not keen on a proliferation of tiny pseudo-config > files, and this feels maybe part of something bigger. A similar argument > could be made for the choice of release/stable vs snaps (-s / -r here, > -Dsnap in pkg_add) which could be in some kind of "system config" alongside > source URLs (base, packages, firmware), a list of sets, maybe some pkg_add > related things (whether to install debug packages?), ... Agreed. /etc/installurl is now a tiny one item config file but was once a different file containing more items. Perhaps something to go back to? -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sysupgrade: Allow to use another directory for the sets
On Mon, Nov 18, 2019 at 01:23:27PM +0100, Renaud Allard wrote: > > > On 11/18/19 10:08 AM, Raimo Niskanen wrote: > > > A configuration parameter could be accomplished through an optional symlink > > /etc/_sysupgrade that the sysadmin can create to point at the installation's > > sysupgrade directory. The sysupgrade script would test -s /etc/_sysupgrade > > and if there is a symlink readlink -f /etc/_sysupgrade to get SETSDIR. > > > > As it was said earlier, this doesn't solve the removal issue. With your > patch, please try "ln -s /home/_sysupgrade / ; sysupgrade". > This is actually not yet in my patch. I just want to, as a first step towards either of our solutions, patch to have the /home/_sysupgrade literal in only one place in the sysupgrade script, which would facilitate patching the sysupgrade script before calling it, as a poor man's solution. Plus, the script gets cleaner. The symlink suggestion is a future patch. But I think your suggestion to instead specify the parent directory of the _syspatch directory should be sufficient to remedy the removal issue both for your command line suggestion, as for this future patch symlink suggestion. It is a pity nobody else has responded to that prefix suggestion of yours! I think the feature itself is more important than if it is implemented with a command line argument or a symlink. Other than that. What do you or anyone else think about my argument that the location of the system upgrade download directory is an installation configuration that will not change between upgrades and hence it would be nice to not have to remember the command line argument for every future sysupgrade. Best regards -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
Re: sysupgrade: Allow to use another directory for the sets
14 Nov 2019 09:29:15 -
> @@ -25,7 +25,6 @@ umask 0022
> export PATH=/usr/bin:/bin:/usr/sbin:/sbin
>
> ARCH=$(uname -m)
> -SETSDIR=/home/_sysupgrade
>
> ug_err()
> {
> @@ -34,7 +33,7 @@ ug_err()
>
> usage()
> {
> - ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
> + ug_err "usage: ${0##*/} [-fkn] [-r | -s] [-d directory] [installurl]"
> }
>
> unpriv()
> @@ -73,14 +72,18 @@ rmel() {
> echo -n "$_c"
> }
>
> +SETSDIR=/home/_sysupgrade
> RELEASE=false
> SNAP=false
> FORCE=false
> KEEP=false
> REBOOT=true
>
> -while getopts fknrs arg; do
> +while getopts d:fknrs arg; do
> case ${arg} in
> + d) SETSDIR=${OPTARG}/_sysupgrade
> + KEEP=true
> + ;;
> f) FORCE=true;;
> k) KEEP=true;;
> n) REBOOT=false;;
> @@ -195,7 +198,7 @@ ${KEEP} && > keep
>
> cat <<__EOT >/auto_upgrade.conf
> Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}
> Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> __EOT
> @@ -203,7 +206,7 @@ __EOT
> if ! ${KEEP}; then
> CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
> cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
> __EOT
> fi
>
--
/ Raimo Niskanen, Erlang/OTP, Ericsson AB
