[PATCH] arch: arm64: dts: apple: Remove stdout-path

[PATCH] arch: arm64: dts: apple: Remove stdout-path

[Akihiko Odaki]

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.

Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
---
 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

Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

[Mark Kettenis]

> From: Akihiko Odaki <akihiko.odaki@daynix.com>
> 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.

> Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> ---
>  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
> 
> 
> 

Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

[Akihiko Odaki]

On 2022/12/01 23:25, Mark Kettenis wrote:
>> From: Akihiko Odaki <akihiko.odaki@daynix.com>
>> 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@daynix.com>
>> ---
>>   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
>>
>>
>>
> 

Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

[Hector Martin]

On 02/12/2022 00.19, Akihiko Odaki wrote:
> 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.

Except if the framebuffer is broken, or everything is broken and it
hangs on early boot, which happens all the time when I'm debugging using
the hypervisor. Or maybe I'm just SSHing in remotely and not physically
in front of the machine, which is also often the case. Or maybe I'm just
booting headless because I didn't feel like swapping around the HDMI cable.

> In contrary, if you boot the kernel without the hypervisor 
> feature and this change, you will completely lose the console.

How so? The console goes to both places with stdout-path set to serial0.
What it *does* change is where input is accepted prior to getty startup
(which is why u-boot specifically conditions this on keyboard presence,
modulo the USB issue - because if you *don't* have a keyboard then tty
keyboard input is useless). But if you're booting kernels without u-boot
along the way, you're probably doing it from the hypervisor or linux.py
anyway, especially if you plan to do something like "init=/bin/sh",
because without u-boot (+ optionally some EFI loader) there is no way of
editing command line arguments at boot time stand-alone.

However, while having stdout-path gives you both serial + tty output and
serial input, *not* having stdout-path kills serial entirely. It also
kills earlycon, and makes it so that you have to specify a bunch of
obscure arguments to get earlycon to work, instead of just a plain
"earlycon" argument which is much easier.

So for this to be considered at all, you would first need to propose a
m1n1 patch to re-add stdout-path in boots under the hypervisor and
(optionally?) on linux.py boots, so you don't regress tools that our
developers use every day.

But I still fail to see the benefit of this change. What scenario are
you envisioning that this would improve (something people actually do,
not a hypothetical)?

- Hector

Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

[Akihiko Odaki]

Hi,

Thank you for reviewing and detailed explanation.

I'm withdrawing this patch. As you pointed out it makes earlycon 
difficult, which is serious in development workflow. As a normal user 
will use U-Boot, which changes stdout-path if appropriate, this kind of 
change should be designed to make development easier, and this change 
does the opposite.

On 2022/12/02 0:46, Hector Martin wrote:
 > On 02/12/2022 00.19, Akihiko Odaki wrote:
 >> 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.
 >
 > Except if the framebuffer is broken, or everything is broken and it
 > hangs on early boot, which happens all the time when I'm debugging using
 > the hypervisor. Or maybe I'm just SSHing in remotely and not physically
 > in front of the machine, which is also often the case. Or maybe I'm just
 > booting headless because I didn't feel like swapping around the HDMI 
cable.

The user can change the kernel parameter in such a case. If you have 
already ran the kernel with this change, you should have learned that 
the console is tied to the framebuffer and keyboard and you need to 
supply the kernel parameter. It is easy to change the kernel parameter 
if you use m1n1 directly.

 >
 >> In contrary, if you boot the kernel without the hypervisor
 >> feature and this change, you will completely lose the console.
 >
 > How so? The console goes to both places with stdout-path set to serial0.
 > What it *does* change is where input is accepted prior to getty startup
 > (which is why u-boot specifically conditions this on keyboard presence,
 > modulo the USB issue - because if you *don't* have a keyboard then tty
 > keyboard input is useless). But if you're booting kernels without u-boot
 > along the way, you're probably doing it from the hypervisor or linux.py
 > anyway, especially if you plan to do something like "init=/bin/sh",
 > because without u-boot (+ optionally some EFI loader) there is no way of
 > editing command line arguments at boot time stand-alone.

Well, that is not exactly the behavior I saw. In my case, if stdout-path 
is pointed to serial, there is no output on the framebuffer, and it just 
printed "_".

It looks like the kernel only outputs to either of serial and 
framebuffer, not both.

 >
 > However, while having stdout-path gives you both serial + tty output and
 > serial input, *not* having stdout-path kills serial entirely. It also
 > kills earlycon, and makes it so that you have to specify a bunch of
 > obscure arguments to get earlycon to work, instead of just a plain
 > "earlycon" argument which is much easier.

This is a valid argument. I always struggle when I try earlycon first 
for a computer. stdout-path should be maintained if it is freeing 
developers from such trouble.

 >
 > So for this to be considered at all, you would first need to propose a
 > m1n1 patch to re-add stdout-path in boots under the hypervisor and
 > (optionally?) on linux.py boots, so you don't regress tools that our
 > developers use every day.
 >
 > But I still fail to see the benefit of this change. What scenario are
 > you envisioning that this would improve (something people actually do,
 > not a hypothetical)?
 >

What I experienced is that when I directly booted the kernel from m1n1 
without hypervisor, it showed no output to the display even though the 
same kernel worked with U-Boot. While I could tell it used wrong console 
by running the hypervisor, I wondered why it behaves differently without 
U-Boot, and found the aforementioned U-Boot change, coming up with this 
patch.

Regards,
Akihiko Odaki

 > - Hector

Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

[Hector Martin]

On 02/12/2022 01.38, Akihiko Odaki wrote:
>  >> In contrary, if you boot the kernel without the hypervisor
>  >> feature and this change, you will completely lose the console.
>  >
>  > How so? The console goes to both places with stdout-path set to serial0.
>  > What it *does* change is where input is accepted prior to getty startup
>  > (which is why u-boot specifically conditions this on keyboard presence,
>  > modulo the USB issue - because if you *don't* have a keyboard then tty
>  > keyboard input is useless). But if you're booting kernels without u-boot
>  > along the way, you're probably doing it from the hypervisor or linux.py
>  > anyway, especially if you plan to do something like "init=/bin/sh",
>  > because without u-boot (+ optionally some EFI loader) there is no way of
>  > editing command line arguments at boot time stand-alone.
> 
> Well, that is not exactly the behavior I saw. In my case, if stdout-path 
> is pointed to serial, there is no output on the framebuffer, and it just 
> printed "_".
> 
> It looks like the kernel only outputs to either of serial and 
> framebuffer, not both.

That is not what I've seen in all of my hypervisor runs since the dawn
of time. You get log output on both.

> What I experienced is that when I directly booted the kernel from m1n1 
> without hypervisor, it showed no output to the display even though the 
> same kernel worked with U-Boot. While I could tell it used wrong console 
> by running the hypervisor, I wondered why it behaves differently without 
> U-Boot, and found the aforementioned U-Boot change, coming up with this 
> patch.

Then it sounds like something else is different about our setups,
because I've booted the kernel from linux.py hundreds of times and I get
output on both. Looking through the console code, the VT console gets
added and enabled really early, and the subsequent serial console
registration later does not disable it.

Look for "console: colour dummy device 80x25". It should be immediately
followed by "printk: console [tty0] enabled", and this should all come
well before the ttySAC0 serial stuff shows up.

- Hector

Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path

[Akihiko Odaki]

On 2022/12/02 2:46, Hector Martin wrote:
> On 02/12/2022 01.38, Akihiko Odaki wrote:
>>   >> In contrary, if you boot the kernel without the hypervisor
>>   >> feature and this change, you will completely lose the console.
>>   >
>>   > How so? The console goes to both places with stdout-path set to serial0.
>>   > What it *does* change is where input is accepted prior to getty startup
>>   > (which is why u-boot specifically conditions this on keyboard presence,
>>   > modulo the USB issue - because if you *don't* have a keyboard then tty
>>   > keyboard input is useless). But if you're booting kernels without u-boot
>>   > along the way, you're probably doing it from the hypervisor or linux.py
>>   > anyway, especially if you plan to do something like "init=/bin/sh",
>>   > because without u-boot (+ optionally some EFI loader) there is no way of
>>   > editing command line arguments at boot time stand-alone.
>>
>> Well, that is not exactly the behavior I saw. In my case, if stdout-path
>> is pointed to serial, there is no output on the framebuffer, and it just
>> printed "_".
>>
>> It looks like the kernel only outputs to either of serial and
>> framebuffer, not both.
> 
> That is not what I've seen in all of my hypervisor runs since the dawn
> of time. You get log output on both.
> 
>> What I experienced is that when I directly booted the kernel from m1n1
>> without hypervisor, it showed no output to the display even though the
>> same kernel worked with U-Boot. While I could tell it used wrong console
>> by running the hypervisor, I wondered why it behaves differently without
>> U-Boot, and found the aforementioned U-Boot change, coming up with this
>> patch.
> 
> Then it sounds like something else is different about our setups,
> because I've booted the kernel from linux.py hundreds of times and I get
> output on both. Looking through the console code, the VT console gets
> added and enabled really early, and the subsequent serial console
> registration later does not disable it.
> 
> Look for "console: colour dummy device 80x25". It should be immediately
> followed by "printk: console [tty0] enabled", and this should all come
> well before the ttySAC0 serial stuff shows up.
> 
> - Hector

I think I understand the situation now. By "console", I was meaning the 
input and output of init, but I failed to clarify that and you thought 
it referring to kernel message output. I saw no messages earlier than 
init because my kernel command line has loglevel=3.

Regards,
Akihiko Odaki