From nobody Fri Sep 23 21:39:14 2022 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MZ5C3307Mz4d1Fr for ; Fri, 23 Sep 2022 21:39:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MZ5C23n0Wz3d7d for ; Fri, 23 Sep 2022 21:39:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id 129so1217644vsi.10 for ; Fri, 23 Sep 2022 14:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=wvUAgOJ3DZ5fX82UOrsxQxhcIa4eLar2JfJ4DoJ/w8A=; b=5c80lypERYMwAEHfu4PrUt+i2Gpx5PJQjVKVXxo0pyQ4+si2Ojtib9vvQzj7+WOAXA SUWY3Ivv+UYZbYK3EYp2S4VlVThQ905PVr55K9yZ3angwPLyok1Sjm2Ko6+sBd6lPUvd dK00/fgyF3vbpdw58/zKrzqWWgtuh+nOUGWOPUbjTwMhe0mrTSPCzyYd8gAl7t0OjJCz 6GfPDkhFzXQlyvm3lzy2rAuu7AhIgk/UOGdGMmFPCRdSj/+z7hgcXBYzpd4dRU9H+DvV nhGjEuA9m+s+PusRpuob0g+KO/6Jn+s0i+DZjtBgdc9XLayPFYCgSfsA4dp6Ok107Pwg BaZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=wvUAgOJ3DZ5fX82UOrsxQxhcIa4eLar2JfJ4DoJ/w8A=; b=p559tcS2Lh3PV4RsBYJy2QLFQXbSsYX3COv5CBw+b8LKyyzhz6vc4SiHx3K0jfJbrQ Yz/JE1NClFLQ6CY6SejhtQU1zQsFgESpfYhbdoIKN6zd03YH6PiBaDQ+b1IACtDRSYVi 78vKUAqaA0J5F7xTCiNPqtp1qH+5mpIYPnZSDYhudaGy/FeeHahd3cs4+UqEqJtDCv9u H7mLwM5d7IbR6XOlOTITAMIinGxTUqfUo6VQwn7UYmFgJQ7Uo9ZM9GauENUD+jgQIDY5 nYYe65QArZ5l4xZ8se6s7XsrqIrFNqTFBU6GwwEZBqKOYZNZN6XSDeKTmrTpjL1X4OXE oHeQ== X-Gm-Message-State: ACrzQf2Pf6Yo/xZ2+nOXRO9tm+r54tE0iFHiqYyyVPSwi2Ns0zG2WFKB 3i6QKY5qU3n3qp159QJkP21pUHCtwmQEkitIvG4MEw== X-Google-Smtp-Source: AMsMyM7OdNubeI9sVsLflmNrJ2RrvYx6jklLYn6wknK5LXGHZXwNopxlEokPl8JRkv5RGft21vDTy/PbGWYIbfAqMFQ= X-Received: by 2002:a67:3c7:0:b0:39b:45c2:6875 with SMTP id 190-20020a6703c7000000b0039b45c26875mr4107822vsd.6.1663969165782; Fri, 23 Sep 2022 14:39:25 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 References: <202208270418.27R4IkeL078154@gitrepo.freebsd.org> <0fccddc3-126d-f7b6-3b69-5fc1cbdb2775@FreeBSD.org> In-Reply-To: <0fccddc3-126d-f7b6-3b69-5fc1cbdb2775@FreeBSD.org> From: Warner Losh Date: Fri, 23 Sep 2022 15:39:14 -0600 Message-ID: Subject: Re: git: df065f699f1f - main - stand: More sensible defaults when ConOut is missing To: John Baldwin Cc: Warner Losh , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000000b48d705e95f03f3" X-Rspamd-Queue-Id: 4MZ5C23n0Wz3d7d X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=5c80lypE; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e33) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e33:from]; MLMMJ_DEST(0.00)[dev-commits-src-main@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-main@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000000b48d705e95f03f3 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 23, 2022 at 3:29 PM John Baldwin wrote: > On 8/26/22 9:18 PM, Warner Losh wrote: > > The branch main has been updated by imp: > > > > URL: > https://cgit.FreeBSD.org/src/commit/?id=df065f699f1ff819bb9607c44a6754275ab335ed > > > > commit df065f699f1ff819bb9607c44a6754275ab335ed > > Author: Warner Losh > > AuthorDate: 2022-08-26 21:46:33 +0000 > > Commit: Warner Losh > > CommitDate: 2022-08-27 04:17:56 +0000 > > > > stand: More sensible defaults when ConOut is missing > > > > When ConOut is missing, we used to default to serial. Except we did > it > > in the worst way possible by just setting the howto bits and not > > updating the console setting, which lead to weird behavior where > we'd > > get some things on the video port, others on serial. > > > > Instead, set console to "efi,comconsole" for this case. Also set > > RB_MULTIPLE always (so we get dual consoles from the kernel) and or > in > > RB_SERIAL when we can't find GOPs that suggest the precense of a > video > > console. This will put output in the most places and have a sensible > > default for 'primary' console. > > > > Sponsored by: Netflix > > Reviewed by: emaste, manu > > Differential Revision: https://reviews.freebsd.org/D36299 > > One possibly surprising result of this is that I did not get dual console > output on my rpi after this. (Curiously this only affected my arm64 image > but not my armv7 image.) Loader output goes to both, but kernel output is > only on the video console (which I don't normally use for my pi). (Also, > none of the ANSI escape sequences used by the loader work on the pi's video > console, so once the menu starts it just looks like raw ANSI code garbage > until the kernel starts booting.) > > Not sure if this warrants UPDATING as the effect is that the serial console > seems to stop working? The lack of working dual console output is perhaps > the only real bug. Not sure what is up there. > We don't do the ANSI interpretation correctly on arm for reasons that I don't recall. It may be just not defining TERM_EMU on arm. That's a separate issue, one that might be easy to fix. It is true that this change went from 'We don't know, so use both' to ' Oh, there might be a video thing, use only that'. I'm not completely happy with this, but was talked into it. What does u-boot/rpi provide for ConIn? >FWIW, using 'console="comconsole,efi"' did not work as a workaround. Same >results (used the video console only for the kernel). Had to use >'console="comconsole"' in /boot/loader.conf. That's definitely a bug as well. comconsole on arm EFI is special as well, but not that special. The loader gets to set the console, and it tells the kernel through some rather byzantine hints what to use. One can also set the console a little more directly with hw.uart.console which tells the kernel, when configuring a serial console, which one to use. You can also use boot_serial=yes boot_dual=no in the environment. The whole interface / handoff has been a series of historical hacks that have not layered well at all... Warner --0000000000000b48d705e95f03f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Sep 23, 2022 at 3:29 PM John = Baldwin <jhb@freebsd.org> wrot= e:
On 8/26/22 9:= 18 PM, Warner Losh wrote:
> The branch main has been updated by imp:
>
> URL: https://= cgit.FreeBSD.org/src/commit/?id=3Ddf065f699f1ff819bb9607c44a6754275ab335ed<= /a>
>
> commit df065f699f1ff819bb9607c44a6754275ab335ed
> Author:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> AuthorDate: 2022-08-26 21:46:33 +0000
> Commit:=C2=A0 =C2=A0 =C2=A0Warner Losh <imp@FreeBSD.org>
> CommitDate: 2022-08-27 04:17:56 +0000
>
>=C2=A0 =C2=A0 =C2=A0 stand: More sensible defaults when ConOut is missi= ng
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 When ConOut is missing, we used to default to seri= al. Except we did it
>=C2=A0 =C2=A0 =C2=A0 in the worst way possible by just setting the howt= o bits and not
>=C2=A0 =C2=A0 =C2=A0 updating the console setting, which lead to weird = behavior where we'd
>=C2=A0 =C2=A0 =C2=A0 get some things on the video port, others on seria= l.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Instead, set console to "efi,comconsole"= for this case. Also set
>=C2=A0 =C2=A0 =C2=A0 RB_MULTIPLE always (so we get dual consoles from t= he kernel) and or in
>=C2=A0 =C2=A0 =C2=A0 RB_SERIAL when we can't find GOPs that suggest= the precense of a video
>=C2=A0 =C2=A0 =C2=A0 console. This will put output in the most places a= nd have a sensible
>=C2=A0 =C2=A0 =C2=A0 default for 'primary' console.
>=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 Sponsored by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Netflix
>=C2=A0 =C2=A0 =C2=A0 Reviewed by:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 emaste, manu
>=C2=A0 =C2=A0 =C2=A0 Differential Revision:=C2=A0 https://revi= ews.freebsd.org/D36299

One possibly surprising result of this is that I did not get dual console output on my rpi after this.=C2=A0 (Curiously this only affected my arm64 i= mage
but not my armv7 image.)=C2=A0 Loader output goes to both, but kernel outpu= t is
only on the video console (which I don't normally use for my pi).=C2=A0= (Also,
none of the ANSI escape sequences used by the loader work on the pi's v= ideo
console, so once the menu starts it just looks like raw ANSI code garbage until the kernel starts booting.)

Not sure if this warrants UPDATING as the effect is that the serial console=
seems to stop working?=C2=A0 The lack of working dual console output is per= haps
the only real bug.=C2=A0 Not sure what is up there.
We don't do the ANSI interpretation=C2=A0correctly on arm = for reasons that I
don't recall. It may be just not defining = TERM_EMU on arm. That's a separate
issue, one that might be e= asy to fix.

It is true that this change went from = 'We don't know, so use both' to ' Oh, there
might= be a video thing, use only that'. I'm not completely happy with th= is, but
was talked into it.

What does u-= boot/rpi provide for ConIn?

>FWIW, using 'c= onsole=3D"comconsole,efi"' did not work as a workaround.=C2= =A0 Same
>results (used the video console only for the kernel).=C2= =A0 Had to use
>'console=3D"comconsole"' in /boot/l= oader.conf.

That's definitely a bug as well. comcons= ole on arm EFI is special as well, but not
that special.

The loader gets to set the console, and it tells the kerne= l through some rather byzantine
hints what to use. One can also s= et the console a little more directly with hw.uart.console
which = tells the kernel, when configuring a serial console, which one to use. You = can also
use boot_serial=3Dyes boot_dual=3Dno in the environment.=

The whole interface / handoff has been a series o= f historical hacks that have not layered
well at all...

Warner
--0000000000000b48d705e95f03f3--