Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path
From: Akihiko Odaki
Date: Thu Dec 01 2022 - 10:19:32 EST
On 2022/12/01 23:25, Mark Kettenis wrote:
From: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx>
Date: Thu, 1 Dec 2022 19:36:51 +0900
u-boot overrides stdout-path so that it points to /chosen/framebuffer
with some condition.
arm: apple: Point stdout-path to framebuffer when keyboard present
Unless you have a spare Apple Silicon machine, getting access to
the serial port on Apple Silicon machines requires special
hardware. Given that most machines come with a built-in screen
the framebuffer is likely to be the most convenient output device
for most users. While U-Boot will output to both serial and
framebuffer, OSes might not. Therefore set stdout-path to point
at /chosen/framebuffer when a keyboard is connected to the machine.
https://github.com/AsahiLinux/u-boot/commit/a609353e82fd757b7635d18ed6a0828fff657d59
Perhaps it made sense to specify serial0 as stdout-path when the
framebuffer and keyboard support was inmature, but today it is
preferrable to use /chosen/framebuffer instead of serial0 for the
console in the most cases as the u-boot change states.
Remove stdout-path to allow the kernel to choose the appropriate
console. For Linux, it will be VT, which will be eventually backed by
the framebuffer, if it is enabled. Otherwise, it will fall back to the
serial.
U-Boot still relies on serial being the default. It will not touch
stdout-out when running under the m1n1 hypervisor for example. The
m1n1 hypervisor emulates the serial port hardware and developers rely
on this quite heavily. Also, U-boot will only switch to the
framebuffer if a keyboard is connected. This is currently disabled in
the builds for Asahi Linux because the type-A USB ports are not
supported yet in U-Boot. But the plan is to fix that eventually.
So as far as I am concerted NAK.
Hi, Thanks for reviewing.
As far as I know, U-Boot relies on serial being the default only to let
the booted kernel use serial when running under the m1n1 hypervisor. It
is true that this change regresses the situation in this particular
case, but I think it is an exceptional case. m1n1 hypervisor is for
development use so we can think of two scenarios:
1. debugging the booted kernel
2. debugging U-Boot
For scenario 1, it is unlikely to involve U-Boot because while U-Boot is
useful to load the kernel from the disk, the kernel will be usually
transferred from another computer during development. In such
configuration, m1n1 will directly boots the kernel. For scenario 2, this
change should not matter as U-Boot will output to both of serial and
framebuffer according to the U-Boot change I mentioned in the previous
email.
So I think we should think more about the case when the kernel is booted
from m1n1. When using its hypervisor feature, it is more likely that you
want console on serial and and that is the opposite of this change.
However, it is still possible to get the console on framebuffer with
keyboard. In contrary, if you boot the kernel without the hypervisor
feature and this change, you will completely lose the console.
For the USB Type-A port problem, it does not matter if U-Boot supports
them because U-Boot will output to both of serial and framebuffer as I
mentioned earlier. I think it rather illustrates the situation when this
change is useful: for such a configuration, if the booted system can use
framebuffer and keyboard, it should, even if U-Boot cannot.
I came up with this patch when I stumbled upon your U-Boot change so I
appreciate if you tell whether there is something I miss or misunderstand.
Regards,
Akihiko Odaki
Signed-off-by: Akihiko Odaki <akihiko.odaki@xxxxxxxxxx>
---
arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi | 2 --
arch/arm64/boot/dts/apple/t600x-j375.dtsi | 2 --
arch/arm64/boot/dts/apple/t8103-jxxx.dtsi | 2 --
arch/arm64/boot/dts/apple/t8112-jxxx.dtsi | 2 --
4 files changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi b/arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi
index 5547f5e7ac5a..14b6bf234f82 100644
--- a/arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi
+++ b/arch/arm64/boot/dts/apple/t600x-j314-j316.dtsi
@@ -30,8 +30,6 @@ chosen {
#size-cells = <2>;
ranges;
- stdout-path = "serial0";
-
framebuffer0: framebuffer@0 {
compatible = "apple,simple-framebuffer", "simple-framebuffer";
reg = <0 0 0 0>; /* To be filled by loader */
diff --git a/arch/arm64/boot/dts/apple/t600x-j375.dtsi b/arch/arm64/boot/dts/apple/t600x-j375.dtsi
index 7c207b1df949..22e96b436bf2 100644
--- a/arch/arm64/boot/dts/apple/t600x-j375.dtsi
+++ b/arch/arm64/boot/dts/apple/t600x-j375.dtsi
@@ -28,8 +28,6 @@ chosen {
#size-cells = <2>;
ranges;
- stdout-path = "serial0";
-
framebuffer0: framebuffer@0 {
compatible = "apple,simple-framebuffer", "simple-framebuffer";
reg = <0 0 0 0>; /* To be filled by loader */
diff --git a/arch/arm64/boot/dts/apple/t8103-jxxx.dtsi b/arch/arm64/boot/dts/apple/t8103-jxxx.dtsi
index 3c5da0e5a41d..d2483f618d44 100644
--- a/arch/arm64/boot/dts/apple/t8103-jxxx.dtsi
+++ b/arch/arm64/boot/dts/apple/t8103-jxxx.dtsi
@@ -27,8 +27,6 @@ chosen {
#size-cells = <2>;
ranges;
- stdout-path = "serial0";
-
framebuffer0: framebuffer@0 {
compatible = "apple,simple-framebuffer", "simple-framebuffer";
reg = <0 0 0 0>; /* To be filled by loader */
diff --git a/arch/arm64/boot/dts/apple/t8112-jxxx.dtsi b/arch/arm64/boot/dts/apple/t8112-jxxx.dtsi
index b6b815d93c3e..af4153dcb55d 100644
--- a/arch/arm64/boot/dts/apple/t8112-jxxx.dtsi
+++ b/arch/arm64/boot/dts/apple/t8112-jxxx.dtsi
@@ -22,8 +22,6 @@ chosen {
#size-cells = <2>;
ranges;
- stdout-path = "serial0";
-
framebuffer0: framebuffer@0 {
compatible = "apple,simple-framebuffer", "simple-framebuffer";
reg = <0 0 0 0>; /* To be filled by loader */
--
2.38.1