Re: pluart(4): change baud rate
On Mon, Jun 20, 2022 at 07:07:14PM +0200, Anton Lindqvist wrote:
> On Mon, Jun 20, 2022 at 02:42:52PM +, Visa Hankala wrote:
> > On Sun, Jun 19, 2022 at 03:06:47PM +0200, Anton Lindqvist wrote:
> > > This allows the pluart baud rate to be changed. There's one potential
> > > pitfall with this change as users will have the wrong baud rate in their
> > > /etc/ttys if not installed after revision 1.11 of dev/ic/pluart.c which
> > > landed today. This will make the serial console unusable until the
> > > expected baud rate in /etc/ttys is changed to 115200.
> >
> > An upgrade note would be good.
>
> I can prepare something for current.html.
>
> > > Comments? OK?
> > >
> > > diff --git sys/dev/fdt/pluart_fdt.c sys/dev/fdt/pluart_fdt.c
> > > index 969018eccdc..ac2467bdf47 100644
> > > --- sys/dev/fdt/pluart_fdt.c
> > > +++ sys/dev/fdt/pluart_fdt.c
> > > @@ -27,6 +27,7 @@
> > >
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > int pluart_fdt_match(struct device *, void *, void *);
> > > @@ -70,8 +71,12 @@ pluart_fdt_attach(struct device *parent, struct device
> > > *self, void *aux)
> > > return;
> > > }
> > >
> > > - if (OF_is_compatible(faa->fa_node, "arm,sbsa-uart"))
> > > + if (OF_is_compatible(faa->fa_node, "arm,sbsa-uart")) {
> > > sc->sc_hwflags |= COM_HW_SBSA;
> > > + } else {
> > > + clock_enable_all(faa->fa_node);
> > > + sc->sc_clkfreq = clock_get_frequency(faa->fa_node, "uartclk");
> > > + }
> > >
> > > periphid = OF_getpropint(faa->fa_node, "arm,primecell-periphid", 0);
> > > if (periphid != 0)
> > > diff --git sys/dev/ic/pluart.c sys/dev/ic/pluart.c
> > > index 40e2b1976fb..aa4301e8fb0 100644
> > > --- sys/dev/ic/pluart.c
> > > +++ sys/dev/ic/pluart.c
> > > @@ -71,9 +71,9 @@
> > > #define UART_ILPR0x20/* IrDA low-power
> > > counter register */
> > > #define UART_ILPR_ILPDVSR((x) & 0xf) /* IrDA low-power
> > > divisor */
> > > #define UART_IBRD0x24/* Integer baud rate
> > > register */
> > > -#define UART_IBRD_DIVINT ((x) & 0xff)/* Integer baud rate divisor */
> > > +#define UART_IBRD_DIVINT(x) ((x) & 0xff)/* Integer baud rate
> > > divisor */
> >
> > This mask should be 0x.
>
> Thanks, fixed.
>
> > > #define UART_FBRD0x28/* Fractional baud rate
> > > register */
> > > -#define UART_FBRD_DIVFRAC((x) & 0x3f)/* Fractional baud rate
> > > divisor */
> > > +#define UART_FBRD_DIVFRAC(x) ((x) & 0x3f)/* Fractional baud rate
> > > divisor */
> > > #define UART_LCR_H 0x2c/* Line control
> > > register */
> > > #define UART_LCR_H_BRK (1 << 0)/* Send break */
> > > #define UART_LCR_H_PEN (1 << 1)/* Parity enable */
> > > @@ -338,7 +338,9 @@ pluart_param(struct tty *tp, struct termios *t)
> > > /* lower dtr */
> > > }
> > >
> > > - if (ospeed != 0) {
> > > + if (ospeed != 0 && sc->sc_clkfreq != 0 && tp->t_ospeed != ospeed) {
> > > + int div, lcr;
> > > +
> > > while (ISSET(tp->t_state, TS_BUSY)) {
> > > ++sc->sc_halt;
> > > error = ttysleep(tp, >t_outq,
> > > @@ -349,7 +351,40 @@ pluart_param(struct tty *tp, struct termios *t)
> > > return (error);
> > > }
> > > }
> > > - /* set speed */
> > > +
> > > + /*
> > > + * Writes to IBRD and FBRD are made effective first when LCR_H
> > > + * is written.
> > > + */
> > > + lcr = bus_space_read_4(sc->sc_iot, sc->sc_ioh, UART_LCR_H);
> > > +
> > > + /* The UART must be disabled while changing the baud rate. */
> > > + bus_space_write_4(sc->sc_iot, sc->sc_ioh, UART_CR, 0);
> >
> > I think this should save original CR for restoring later, and set CR
> > with UARTEN masked out.
> >
> > cr = bus_space_read_4(sc->sc_iot, sc->sc_ioh, UART_CR);
> > bus_space_write_4(sc->sc_iot, sc->sc_ioh, UART_CR,
> > cr & ~UART_CR_UARTEN);
> >
> > The PL011 manual says that reserved bits in CR should not be modified.
> >
> > > +
> > > + /*
> > > + * The baud rate divisor is expressed relative to the UART clock
> > > + * frequency where IBRD represents the quotient using 16 bits
> > > + * and FBRD the remainder using 6 bits. The PL011 specification
> > > + * provides the following formula:
> > > + *
> > > + * uartclk/(16 * baudrate)
> > > + *
> > > + * The formula can be estimated by scaling it with the
> > > + * precision 64 (2^6) and letting the resulting upper 16 bits
> > > + * represents the quotient and the lower 6 bits the remainder:
> > > + *
> > > + * 64 * uartclk/(16 * baudrate) = 4 * uartclk/baudrate
> > > + */
> > > +
Re: [PATCH] Fix typo in ed(1) manpage
Hi Jason, Jason McIntyre wrote on Sun, Jun 19, 2022 at 06:51:26AM +0100: > On Sat, Jun 18, 2022 at 11:17:43PM +, S M wrote: >> Sending a separate patch as this is unrelated to my previous e-mail. > fixed, thanks. Thanks. > i note that the same text is present in regress/usr.bin/diff/t11.1 and > t11.2. i know that will not matter, but noting here in case someone > thinks that should be updated too. I think it's better to leave those two files as they are because /usr/src/regress/usr.bin/diff/Makefile says: # t11: rev 1.3 and 1.36 of usr.bin/ed/ed.1. So fixing typos in there is more likely to cause confusion than to help anything. These are just random files to test diff(1) and patch(1), so their content hardly matters, but since the Makefile documents where the content comes from, that comment should better remain accurate. Yours, Ingo >> diff --git bin/ed/ed.1 bin/ed/ed.1 >> index f5fc5be2e76..3ed865e0a05 100644 >> --- bin/ed/ed.1 >> +++ bin/ed/ed.1 >> @@ -537,7 +537,7 @@ is a positive number, causes only the >> match to be replaced. >> It is an error if no substitutions are performed on any of the addressed >> lines. >> -The current address is set the last line affected. >> +The current address is set to the last line affected. >> .Pp >> .Ar re >> and
Re: match recent Intel CPUs in fw_update(8)
On Tue, Jun 21, 2022 at 09:29:13AM +0200, Sebastien Marie wrote:
> On Tue, Jun 21, 2022 at 02:58:46PM +1000, Jonathan Gray wrote:
> > Intel CPUs used to have strings like
> > cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class)
> > 1.20 GHz
> > cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
> > recent CPUs use
> > cpu0: 11th Gen Intel(R) Core(TM) i5-1130G7 @ 1.10GHz, 30009.37 MHz, 06-8c-01
> > cpu0: 12th Gen Intel(R) Core(TM) i5-12400, 4390.71 MHz, 06-97-02
> > cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
> >
> > Index: patterns.c
> > ===
> > RCS file: /cvs/src/usr.sbin/fw_update/patterns.c,v
> > retrieving revision 1.3
> > diff -u -p -r1.3 patterns.c
> > --- patterns.c 10 Mar 2022 07:12:13 - 1.3
> > +++ patterns.c 21 Jun 2022 04:31:24 -
> > @@ -94,7 +94,7 @@ main(void)
> > printf("%s\n", "bwfm");
> > printf("%s\n", "bwi");
> > printf("%s\n", "intel");
> > - printf("%s\n", "intel ^cpu0: Intel");
> > + printf("%s\n", "intel ^cpu0:*Intel(R)");
> > printf("%s\n", "inteldrm");
> > print_devices("inteldrm", i915_devices, nitems(i915_devices));
> > printf("%s\n", "ipw");
> >
>
> If I properly understood the way patterns file is used in fw_update, having a
> '*' in the middle of the searched string could be hasardous and will result
> in
> possible false positive (installing a firmware whereas not need).
>
> With the pattern "intel ^cpu0:*Intel(R)", the search is done using:
>
> _d="intel"
> _m="^cpu0:*Intel(R)"
> _nl=$(echo) # newline: \n
>
> [ "$_m" ] || _m="${_nl}${_d}[0-9] at " # no change
> [ "$_m" = "${_m#^}" ] || _m="${_nl}${_m#^}" # changed to
> _m="\ncpu0:*Intel(R)"
>
> if [[ ${_dmesgtail} = *$_m* ]] ; then
> echo "$_d"
> fi
>
> The final searched string (glob) is "*\ncpu0:*Intel(R)*".
>
> It means that if the dmesg contains "\ncpu0:" and "Intel(R)" (in this order,
> but
> not necessary on the same line) it will match.
>
> On dmesglog, I found only few candidates for "Intel(R)" string not on a
> "cpuX:"
> line:
>
> bios0: Intel(R) Client Systems NUC8i5BEH
> ugen0 at uhub2 port 2 "Intel Corporation Intel(R) Centrino(R)
> Wireless-N + WiMAX 6150" rev 2.00/0.00 addr 3
> ugen0 at uhub2 port 6 "Intel(R) Corporation Intel(R) Centrino(R)
> Advanced-N + WiMAX 6250" rev 2.00/0.00 addr 4
> uhidev0 at uhub2 port 1 configuration 1 interface 0 "Intel Corporation
> Intel(R) Sensor Solution" rev 2.00/0.01 addr 3
>
> the bios0 entry is *before* cpu0, so it will not match. But the others
> entries
> will match (assuming the dmesg contains a cpu0: line, which somehow expected).
>
> Below an alternative diff to match the Intel cpu without using '*':
But then even more cases are required
cpu0: Genuine Intel(R) CPU @ 600MHz, 600.10 MHz
cpu0: Genuine Intel(R) CPU @ 1.00GHz, 1000.13 MHz, 06-26-01
cpu0: Genuine Intel(R) CPU L2400 @ 1.66GHz ("GenuineIntel" 686-class) 1.67 GHz,
06-0e-08
(we don't have microcode for these)
cpu0: Mobile Intel(R) Pentium(R) III CPU - M 1000MHz ("GenuineIntel" 686-class)
1 GHz
cpu0: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz ("GenuineIntel" 686-class) 2
GHz
cpu0: Mobile Genuine Intel(R) processor 1400MHz ("GenuineIntel" 686-class)
test chips seem to use "Genuine Intel(R) CPU "
>
> diff 5177244f5c04ec0ff6b9b724b540740d62d2dcfa /home/semarie/repos/openbsd/src
> blob - d7cbab70c1654d8dc6ca067cea55b440fd70d426
> file + usr.sbin/fw_update/patterns.c
> --- usr.sbin/fw_update/patterns.c
> +++ usr.sbin/fw_update/patterns.c
> @@ -95,6 +95,7 @@ main(void)
> printf("%s\n", "bwi");
> printf("%s\n", "intel");
> printf("%s\n", "intel ^cpu0: Intel");
> + printf("%s\n", "intel ^cpu0: [0-9][0-9]th Gen Intel");
> printf("%s\n", "inteldrm");
> print_devices("inteldrm", i915_devices, nitems(i915_devices));
> printf("%s\n", "ipw");
>
> Comments ?
> --
> Sebastien Marie
>
>
Re: match recent Intel CPUs in fw_update(8)
On Tue, Jun 21, 2022 at 02:58:46PM +1000, Jonathan Gray wrote:
> Intel CPUs used to have strings like
> cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20
> GHz
> cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
> recent CPUs use
> cpu0: 11th Gen Intel(R) Core(TM) i5-1130G7 @ 1.10GHz, 30009.37 MHz, 06-8c-01
> cpu0: 12th Gen Intel(R) Core(TM) i5-12400, 4390.71 MHz, 06-97-02
> cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
>
> Index: patterns.c
> ===
> RCS file: /cvs/src/usr.sbin/fw_update/patterns.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 patterns.c
> --- patterns.c10 Mar 2022 07:12:13 - 1.3
> +++ patterns.c21 Jun 2022 04:31:24 -
> @@ -94,7 +94,7 @@ main(void)
> printf("%s\n", "bwfm");
> printf("%s\n", "bwi");
> printf("%s\n", "intel");
> - printf("%s\n", "intel ^cpu0: Intel");
> + printf("%s\n", "intel ^cpu0:*Intel(R)");
> printf("%s\n", "inteldrm");
> print_devices("inteldrm", i915_devices, nitems(i915_devices));
> printf("%s\n", "ipw");
>
If I properly understood the way patterns file is used in fw_update, having a
'*' in the middle of the searched string could be hasardous and will result in
possible false positive (installing a firmware whereas not need).
With the pattern "intel ^cpu0:*Intel(R)", the search is done using:
_d="intel"
_m="^cpu0:*Intel(R)"
_nl=$(echo) # newline: \n
[ "$_m" ] || _m="${_nl}${_d}[0-9] at " # no change
[ "$_m" = "${_m#^}" ] || _m="${_nl}${_m#^}" # changed to
_m="\ncpu0:*Intel(R)"
if [[ ${_dmesgtail} = *$_m* ]] ; then
echo "$_d"
fi
The final searched string (glob) is "*\ncpu0:*Intel(R)*".
It means that if the dmesg contains "\ncpu0:" and "Intel(R)" (in this order,
but
not necessary on the same line) it will match.
On dmesglog, I found only few candidates for "Intel(R)" string not on a "cpuX:"
line:
bios0: Intel(R) Client Systems NUC8i5BEH
ugen0 at uhub2 port 2 "Intel Corporation Intel(R) Centrino(R)
Wireless-N + WiMAX 6150" rev 2.00/0.00 addr 3
ugen0 at uhub2 port 6 "Intel(R) Corporation Intel(R) Centrino(R)
Advanced-N + WiMAX 6250" rev 2.00/0.00 addr 4
uhidev0 at uhub2 port 1 configuration 1 interface 0 "Intel Corporation
Intel(R) Sensor Solution" rev 2.00/0.01 addr 3
the bios0 entry is *before* cpu0, so it will not match. But the others entries
will match (assuming the dmesg contains a cpu0: line, which somehow expected).
Below an alternative diff to match the Intel cpu without using '*':
diff 5177244f5c04ec0ff6b9b724b540740d62d2dcfa /home/semarie/repos/openbsd/src
blob - d7cbab70c1654d8dc6ca067cea55b440fd70d426
file + usr.sbin/fw_update/patterns.c
--- usr.sbin/fw_update/patterns.c
+++ usr.sbin/fw_update/patterns.c
@@ -95,6 +95,7 @@ main(void)
printf("%s\n", "bwi");
printf("%s\n", "intel");
printf("%s\n", "intel ^cpu0: Intel");
+ printf("%s\n", "intel ^cpu0: [0-9][0-9]th Gen Intel");
printf("%s\n", "inteldrm");
print_devices("inteldrm", i915_devices, nitems(i915_devices));
printf("%s\n", "ipw");
Comments ?
--
Sebastien Marie
Re: netstart(8): don't lie
ah, i missed the "existing interface" part. so i think it's ok. jmc On 21 June 2022 07:41:22 BST, Stuart Henderson wrote: >On 2022/06/21 07:15, Jason McIntyre wrote: >> On Tue, Jun 21, 2022 at 07:07:25AM +0100, Stuart Henderson wrote: >> > any comments? does it need a "does not clear things" caveat? ok? >> > >> >> maybe instead of thinking about it as a caveat, we should just say what >> happens if you run the script on an interface that is already running? > >that's sort-of already in my diff with "apply the configuration from >hostname.if", it could go into more details but then it gets messier. >basically it's "doesn't clear any existing configuration except for an >existing IPv4 address unless all the v4 addresses in the file have the >'alias' flag". > > >> > Index: netstart.8 >> > === >> > RCS file: /cvs/src/share/man/man8/netstart.8,v >> > retrieving revision 1.25 >> > diff -u -p -r1.25 netstart.8 >> > --- netstart.8 29 Nov 2020 20:14:06 - 1.25 >> > +++ netstart.8 21 Jun 2022 06:05:51 - >> > @@ -43,8 +43,7 @@ it performs network initialization. >> > .Pp >> > The >> > .Nm >> > -script can also be used to start newly created bridges or interfaces, >> > -or reset existing interfaces to their default state. >> > +script can also be used to start newly created bridges or interfaces. >> > The behaviour of this script is (or can be) controlled to some >> > extent by variables defined in >> > .Xr rc.conf 8 , >> > @@ -91,8 +90,9 @@ and >> > After the system is completely initialized, it is possible to start a >> > newly created interface or >> > .Xr bridge 4 , >> > -or reset an existing interface to its default state, by invoking >> > -the following, where >> > +or apply the configuration from a >> > +.Xr hostname.if 5 >> > +file to an existing interface, by invoking the following, where >> > .Ar foo0 >> > is the interface or bridge name: >> > .Pp >> > >> >
Re: allow HW_USERMEM64 in sysctl pledge
On 2022/06/21 16:39, Jonathan Gray wrote: > chromium loads vulkan when going to chrome://gpu > on Intel Mesa uses HW_USERMEM64 > > chrome(44801): pledge sysctl 2: 6 20 > chrome[44801]: pledge "", syscall 202 ok with me, it's read-only and low-risk for the new functionality it allows to other programmes using pledge sysctl already, and there seems no reason not to have it when HW_PHYSMEM64 is available. > Index: sys/kern/kern_pledge.c > === > RCS file: /cvs/src/sys/kern/kern_pledge.c,v > retrieving revision 1.281 > diff -u -p -r1.281 kern_pledge.c > --- sys/kern/kern_pledge.c25 Mar 2022 17:40:59 - 1.281 > +++ sys/kern/kern_pledge.c21 Jun 2022 06:23:09 - > @@ -977,6 +977,7 @@ pledge_sysctl(struct proc *p, int miblen > case HW_PHYSMEM64: /* hw.physmem */ > case HW_NCPU: /* hw.ncpu */ > case HW_NCPUONLINE: /* hw.ncpuonline */ > + case HW_USERMEM64: /* hw.usermem */ > return (0); > } > break; >
Re: netstart(8): don't lie
On 2022/06/21 07:15, Jason McIntyre wrote: > On Tue, Jun 21, 2022 at 07:07:25AM +0100, Stuart Henderson wrote: > > any comments? does it need a "does not clear things" caveat? ok? > > > > maybe instead of thinking about it as a caveat, we should just say what > happens if you run the script on an interface that is already running? that's sort-of already in my diff with "apply the configuration from hostname.if", it could go into more details but then it gets messier. basically it's "doesn't clear any existing configuration except for an existing IPv4 address unless all the v4 addresses in the file have the 'alias' flag". > > Index: netstart.8 > > === > > RCS file: /cvs/src/share/man/man8/netstart.8,v > > retrieving revision 1.25 > > diff -u -p -r1.25 netstart.8 > > --- netstart.8 29 Nov 2020 20:14:06 - 1.25 > > +++ netstart.8 21 Jun 2022 06:05:51 - > > @@ -43,8 +43,7 @@ it performs network initialization. > > .Pp > > The > > .Nm > > -script can also be used to start newly created bridges or interfaces, > > -or reset existing interfaces to their default state. > > +script can also be used to start newly created bridges or interfaces. > > The behaviour of this script is (or can be) controlled to some > > extent by variables defined in > > .Xr rc.conf 8 , > > @@ -91,8 +90,9 @@ and > > After the system is completely initialized, it is possible to start a > > newly created interface or > > .Xr bridge 4 , > > -or reset an existing interface to its default state, by invoking > > -the following, where > > +or apply the configuration from a > > +.Xr hostname.if 5 > > +file to an existing interface, by invoking the following, where > > .Ar foo0 > > is the interface or bridge name: > > .Pp > > >
allow HW_USERMEM64 in sysctl pledge
chromium loads vulkan when going to chrome://gpu on Intel Mesa uses HW_USERMEM64 chrome(44801): pledge sysctl 2: 6 20 chrome[44801]: pledge "", syscall 202 Index: sys/kern/kern_pledge.c === RCS file: /cvs/src/sys/kern/kern_pledge.c,v retrieving revision 1.281 diff -u -p -r1.281 kern_pledge.c --- sys/kern/kern_pledge.c 25 Mar 2022 17:40:59 - 1.281 +++ sys/kern/kern_pledge.c 21 Jun 2022 06:23:09 - @@ -977,6 +977,7 @@ pledge_sysctl(struct proc *p, int miblen case HW_PHYSMEM64: /* hw.physmem */ case HW_NCPU: /* hw.ncpu */ case HW_NCPUONLINE: /* hw.ncpuonline */ + case HW_USERMEM64: /* hw.usermem */ return (0); } break;
Re: netstart(8): don't lie
On Tue, Jun 21, 2022 at 07:07:25AM +0100, Stuart Henderson wrote: > any comments? does it need a "does not clear things" caveat? ok? > maybe instead of thinking about it as a caveat, we should just say what happens if you run the script on an interface that is already running? jmc > Index: netstart.8 > === > RCS file: /cvs/src/share/man/man8/netstart.8,v > retrieving revision 1.25 > diff -u -p -r1.25 netstart.8 > --- netstart.829 Nov 2020 20:14:06 - 1.25 > +++ netstart.821 Jun 2022 06:05:51 - > @@ -43,8 +43,7 @@ it performs network initialization. > .Pp > The > .Nm > -script can also be used to start newly created bridges or interfaces, > -or reset existing interfaces to their default state. > +script can also be used to start newly created bridges or interfaces. > The behaviour of this script is (or can be) controlled to some > extent by variables defined in > .Xr rc.conf 8 , > @@ -91,8 +90,9 @@ and > After the system is completely initialized, it is possible to start a > newly created interface or > .Xr bridge 4 , > -or reset an existing interface to its default state, by invoking > -the following, where > +or apply the configuration from a > +.Xr hostname.if 5 > +file to an existing interface, by invoking the following, where > .Ar foo0 > is the interface or bridge name: > .Pp >
netstart(8): don't lie
any comments? does it need a "does not clear things" caveat? ok? Index: netstart.8 === RCS file: /cvs/src/share/man/man8/netstart.8,v retrieving revision 1.25 diff -u -p -r1.25 netstart.8 --- netstart.8 29 Nov 2020 20:14:06 - 1.25 +++ netstart.8 21 Jun 2022 06:05:51 - @@ -43,8 +43,7 @@ it performs network initialization. .Pp The .Nm -script can also be used to start newly created bridges or interfaces, -or reset existing interfaces to their default state. +script can also be used to start newly created bridges or interfaces. The behaviour of this script is (or can be) controlled to some extent by variables defined in .Xr rc.conf 8 , @@ -91,8 +90,9 @@ and After the system is completely initialized, it is possible to start a newly created interface or .Xr bridge 4 , -or reset an existing interface to its default state, by invoking -the following, where +or apply the configuration from a +.Xr hostname.if 5 +file to an existing interface, by invoking the following, where .Ar foo0 is the interface or bridge name: .Pp
