All of lore.kernel.org
 help / color / mirror / Atom feed
From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: Hector Martin <marcan@marcan.st>,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, asahi@lists.linux.dev,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	alyssa@rosenzweig.io, sven@svenpeter.dev
Subject: Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path
Date: Fri, 2 Dec 2022 03:14:41 +0900	[thread overview]
Message-ID: <18c884cb-dd73-09eb-65da-604cf45cb1b4@daynix.com> (raw)
In-Reply-To: <647b6572-e5d1-d243-283e-616cef15a1f5@marcan.st>

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

WARNING: multiple messages have this Message-ID (diff)
From: Akihiko Odaki <akihiko.odaki@daynix.com>
To: Hector Martin <marcan@marcan.st>,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, asahi@lists.linux.dev,
	krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org,
	alyssa@rosenzweig.io, sven@svenpeter.dev
Subject: Re: [PATCH] arch: arm64: dts: apple: Remove stdout-path
Date: Fri, 2 Dec 2022 03:14:41 +0900	[thread overview]
Message-ID: <18c884cb-dd73-09eb-65da-604cf45cb1b4@daynix.com> (raw)
In-Reply-To: <647b6572-e5d1-d243-283e-616cef15a1f5@marcan.st>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-01 18:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-01 10:36 [PATCH] arch: arm64: dts: apple: Remove stdout-path Akihiko Odaki
2022-12-01 10:36 ` Akihiko Odaki
2022-12-01 10:36 ` Akihiko Odaki
2022-12-01 14:25 ` Mark Kettenis
2022-12-01 14:25   ` Mark Kettenis
2022-12-01 15:19   ` Akihiko Odaki
2022-12-01 15:19     ` Akihiko Odaki
2022-12-01 15:46     ` Hector Martin
2022-12-01 15:46       ` Hector Martin
2022-12-01 16:38       ` Akihiko Odaki
2022-12-01 16:38         ` Akihiko Odaki
2022-12-01 17:46         ` Hector Martin
2022-12-01 17:46           ` Hector Martin
2022-12-01 18:14           ` Akihiko Odaki [this message]
2022-12-01 18:14             ` Akihiko Odaki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18c884cb-dd73-09eb-65da-604cf45cb1b4@daynix.com \
    --to=akihiko.odaki@daynix.com \
    --cc=alyssa@rosenzweig.io \
    --cc=asahi@lists.linux.dev \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.kettenis@xs4all.nl \
    --cc=robh+dt@kernel.org \
    --cc=sven@svenpeter.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.