From nobody Tue Aug 16 16:52:00 2022 X-Original-To: hackers@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 4M6cd936X5z4Yrc8 for ; Tue, 16 Aug 2022 16:52:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 4M6cd85Nk7z3h73 for ; Tue, 16 Aug 2022 16:52:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2f.google.com with SMTP id v128so10701027vsb.10 for ; Tue, 16 Aug 2022 09:52:12 -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; bh=PojUpjcedcMu4ZChsEqfJrGFb5KGMnNGtMnsiIjG/ws=; b=1kbXIpyYo0n7N3qP9ZlgrcEZcSgBkvZKLkdb3/urVO10UBOhmtJh8L8FFlJVwqgexx iH8s0wVfL1P4MseEYk0dxpw55tqPB5dUaf3DGYlp7QgV7sl7IuwVIrTBn1C3/NCox4lb Mm2yUyHBumJgk9H8lrFH80eA9t3uVzuXkyPk8SclSTgtLkFwY4lqLaEd+8z8kyAtElQk bwEwOcq2CF6NsZPP1UV5s3eqSAPVn0FDX15pqJHzjtUHuvyVN6G0hLNRsvH2LXG+4gZA Vhxi3mN9x+jclko4V6wYaN71WQ1UC40z06Fusv/02tTCCkQ2W7cZG/dG8UCca49tUlmi A2aw== 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; bh=PojUpjcedcMu4ZChsEqfJrGFb5KGMnNGtMnsiIjG/ws=; b=0HnyFEGU+44a5ufhzfjDeJdDXJWMhutZNqWpkTGouYu0dB1t+IkGcHoxqkocmSq96T f9fgeGyIZItzO4aa09AHQOvDwg5BiFLnOPaO076Kp0cNI7U0JaHdceE5C4bB8GQZrTm+ tLC8q7bHYkdT4ZubH62qzGCwobogyF0R7o85vgPu7Co+WaVz60yc48XOfDwtRexMM+Dv LJ1Cy4fqMV44z0o+NqMWtidwLvhJQ9LdcGPHhVTSlwSMCDvO+QJ+IF4WZ25ChGRi/yhg YbQaY/HTZFjaYBXQiBYl4smp3J9p/R692M6nqabCdCBzxCRXLsZDxrJeXHDT1thQxZtC Qn4w== X-Gm-Message-State: ACgBeo3xoRBoA3hPTJzV0YBh7iDLs7wsMtPWwnBfRb+FacwabAShblAt oXu5tj9hY8uYIzlYRlgKPaM+jO7uMKLyA92VCudxLA== X-Google-Smtp-Source: AA6agR79dahLfmCIZk7Jg1CixWxaRwIVyKvP5KxxHgov+KfpoQfPLutTQugLZYTfUneYNxXl45VcXDi/tx/rSH4NAHo= X-Received: by 2002:a67:ac45:0:b0:388:a1ff:7e89 with SMTP id n5-20020a67ac45000000b00388a1ff7e89mr9373642vsh.42.1660668731788; Tue, 16 Aug 2022 09:52:11 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Tue, 16 Aug 2022 10:52:00 -0600 Message-ID: Subject: Re: different console settings for loader[.efi] and kernel To: Andriy Gapon Cc: "freebsd-hackers@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000d9246c05e65e91f7" X-Rspamd-Queue-Id: 4M6cd85Nk7z3h73 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=1kbXIpyY; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2f) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; 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]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[hackers@freebsd.org]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2f:from]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; PREVIOUSLY_DELIVERED(0.00)[hackers@freebsd.org]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[bsdimp.com]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com] X-ThisMailContainsUnwantedMimeParts: N --000000000000d9246c05e65e91f7 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 16, 2022 at 12:52 AM Andriy Gapon wrote: > > It seems that console variable in loader.conf affects both the OS/kernel > and the loader itself. Is there a way to have different console > settings between those? > Yes. > Let me explain. I have a system that I access in several different > ways: via its physical serial console, via IPMI / iKVM, and sometimes > via its physical video console. > console is set to "comconsole, efi". > The system uses EFI boot. > The BIOS is configured to "redirect" video console to serial and to stop > the redirection once an OS starts. > > The setup works fine before the loader (e.g., for entering BIOS > settings) and it works fine once the kernel starts. > But while in the loader, every character printed gets doubled on the > serial console. I guess that this is because the loader prints it to > both the serial output and the EFI output while the BIOS still redirects > the EFI output to the serial. > Yes. You've told it to have two consoles, and when they are the same hardware you'll get that doubling. > I would like to solve that double printing while keeping both the serial > console and the video / EFI console usable. > Double printing is trivial to fix: Don't add 'comconsole' to the consoles. EFI loader uses the generic console facilities. So when it's doing redirect, just set it to EFI. > So, one way would be for the loader to use only the EFI console and let > the BIOS redirect take care of the serial. > console=efi does exactly that on my systems. > I guess that another way would be for the loader to announce itself as > an "OS" (whatever that technically means), so that the BIOS stops its > redirection. > Now, having said that, there's one issue with EFI. EFI specifies the UID which the boot loader can't decode into an address, and the current kernel doesn't verify the address is correct, nor can it use this UID to do cninit (because ACPI isn't brought up enough to find the address yet). In those cases, you'll need to use an additional environment variable from the loader: hw.uart.console="io:1016,br:115200" this sets the port to 0x3f8 for the kernel, but the loader won't do anything with it. The kernel will. Warner --000000000000d9246c05e65e91f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 16, 2022 at 12:52 AM Andr= iy Gapon <avg@freebsd.org> wro= te:

It seems that console variable in loader.conf affects both the OS/kernel and the loader itself.=C2=A0 Is there a way to have different console
settings between those?

Yes.
= =C2=A0
Let me explain.=C2=A0 I have a system that I access in several different ways: via its physical serial console, via IPMI / iKVM, and sometimes
via its physical video console.
console is set to "comconsole, efi".
The system uses EFI boot.
The BIOS is configured to "redirect" video console to serial and = to stop
the redirection once an OS starts.

The setup works fine before the loader (e.g., for entering BIOS
settings) and it works fine once the kernel starts.
But while in the loader, every character printed gets doubled on the
serial console.=C2=A0 I guess that this is because the loader prints it to =
both the serial output and the EFI output while the BIOS still redirects the EFI output to the serial.

Yes. You&= #39;ve told it to have two consoles, and when they are the same hardware
you'll get that doubling.
=C2=A0
I would like to solve that double printing while keeping both the serial console and the video / EFI console usable.

=
Double printing is trivial to fix: Don't add 'comconsole' = to the consoles. EFI loader
uses the generic console facilities. = So when it's doing redirect, just set it to EFI.
=C2=A0
=
So, one way would be for the loader to use only the EFI console and let the BIOS redirect take care of the serial.

<= div>console=3Defi does exactly that on my systems.
=C2=A0
I guess that another way would be for the loader to announce itself as
an "OS" (whatever that technically means), so that the BIOS stops= its
redirection.

Now, having said that, the= re's one issue with EFI. EFI specifies the UID
which the boot= loader can't decode into an address, and the current kernel
= doesn't verify the address is correct, nor can it use this UID to do cn= init
(because ACPI isn't brought up enough to find the addres= s yet). In those cases,
you'll need to use an additional envi= ronment variable from the loader:

hw.uart.console= =3D"io:1016,br:115200"

this sets the por= t to 0x3f8 for the kernel, but the loader won't do anything with it.
The kernel will.

Warner
--000000000000d9246c05e65e91f7--