From: Mark Rutland <mark.rutland@arm.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, akos.denke@arm.com,
luca.fancellu@arm.com, maz@kernel.org
Subject: Re: [BOOT-WRAPPER v2 10/10] Boot CPUs sequentially
Date: Thu, 22 Aug 2024 11:02:36 +0100 [thread overview]
Message-ID: <ZscMvEFWrPdlIC56@J2N7QTR9R3> (raw)
In-Reply-To: <20240821184923.2ff8d41e@donnerap.manchester.arm.com>
On Wed, Aug 21, 2024 at 06:49:23PM +0100, Andre Przywara wrote:
> On Mon, 12 Aug 2024 11:15:55 +0100
> Mark Rutland <mark.rutland@arm.com> wrote:
>
> > Currently the boot-wrapper initializes all CPUs in parallel. This means
> > that we cannot log errors as they happen, as this would mean multiple
> > CPUs concurrently writing to the UART, producing garbled output. To
> > produce meaningful output we have to special-case errors on the boot CPU
> > and hope CPUs have been configured consistently.
> >
> > To make it easier to handle errors, boot CPUs sequentially so that errors
> > can be logged as they happen. With this change it's pretty clear that
> > the cpu_init_bootmethod() abstraction isn't helpful, and so this is
> > removed with cpu_init_arch() directly initializing PSCI where necessary.
>
> Yeah, makes sense, though the change is a bit hard to follow in the diff
> below. But I convinced myself that it's correct. Just one small comment
> inside:
>
> > When things go well this looks like:
> >
> > | Boot-wrapper v0.2
> > | Entered at EL3
> > | Memory layout:
> > | [0000000080000000..0000000080001f90] => boot-wrapper
> > | [000000008000fff8..0000000080010000] => mbox
> > | [0000000080200000..0000000082cbaa00] => kernel
> > | [0000000088000000..0000000088002df1] => dtb
> > | CPU0: (MPIDR 0000000000000000) initializing...
> > | CPU0: Done
> > | CPU1: (MPIDR 0000000000000100) initializing...
> > | CPU1: Done
> > | CPU2: (MPIDR 0000000000000200) initializing...
> > | CPU2: Done
> > | CPU3: (MPIDR 0000000000000300) initializing...
> > | CPU3: Done
> > | CPU4: (MPIDR 0000000000010000) initializing...
> > | CPU4: Done
> > | CPU5: (MPIDR 0000000000010100) initializing...
> > | CPU5: Done
> > | CPU6: (MPIDR 0000000000010200) initializing...
> > | CPU6: Done
> > | CPU7: (MPIDR 0000000000010300) initializing...
> > | CPU7: Done
> > | All CPUs initialized. Entering kernel...
> > |
> > | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd0f0]
> > +static void cpu_init_self(unsigned int cpu)
> > +{
> > + print_string("CPU");
> > + print_uint_dec(cpu);
> > + print_string(": (MPIDR ");
> > + print_ulong_hex(read_mpidr());
> > + print_string(") initializing...\r\n");
>
> It feels like using two lines per core for something that rarely fails
> is a bit wasteful. Can we get rid of the EOL here, and just put the "Done"
> right behind it, in the same line? That reduces the noise on the terminal.
That'll interact poorly with logging errors, as the first will get
appended to the "initializing..." line.
Instead, I'll get rid of the "Done" line, so that the output ends up as:
| CPU0: (MPIDR 0000000000000000) initializing...
| CPU1: (MPIDR 0000000000000100) initializing...
| CPU2: (MPIDR 0000000000000200) initializing...
| CPU3: (MPIDR 0000000000000300) initializing...
| CPU4: (MPIDR 0000000000010000) initializing...
| CPU5: (MPIDR 0000000000010100) initializing...
| CPU6: (MPIDR 0000000000010200) initializing...
| CPU7: (MPIDR 0000000000010300) initializing...
| All CPUs initialized. Entering kernel...
... and if any error occurs it'll still be clear which CPU it belongs
to given the next line will either be the next CPU being announced or
the final "All CPUs initialized." message.
Mark.
prev parent reply other threads:[~2024-08-22 10:03 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 10:15 [BOOT-WRAPPER v2 00/10] Cleanup initialization Mark Rutland
2024-08-12 10:15 ` [BOOT-WRAPPER v2 01/10] aarch64: Remove redundant EL1 entry logic Mark Rutland
2024-08-12 17:37 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 02/10] aarch64: Implement cpu_init_arch() Mark Rutland
2024-08-13 17:13 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 03/10] aarch64: Always enter kernel via exception return Mark Rutland
2024-08-13 17:14 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 04/10] aarch32: Refactor inital entry Mark Rutland
2024-08-19 17:21 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 05/10] aarch32: Implement cpu_init_arch() Mark Rutland
2024-08-19 17:21 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 06/10] aarch32: Always enter kernel via exception return Mark Rutland
2024-08-19 17:22 ` Andre Przywara
2024-08-20 11:43 ` Mark Rutland
2024-08-20 12:59 ` Andre Przywara
2024-08-20 13:36 ` Mark Rutland
2024-08-20 13:50 ` Andre Przywara
2024-08-20 11:47 ` Mark Rutland
2024-08-20 12:23 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 07/10] Unify assembly setup paths Mark Rutland
2024-08-21 16:54 ` Andre Przywara
2024-08-22 9:50 ` Mark Rutland
2024-08-12 10:15 ` [BOOT-WRAPPER v2 08/10] Simplify spin logic Mark Rutland
2024-08-21 16:55 ` Andre Przywara
2024-08-22 9:54 ` Mark Rutland
2024-08-12 10:15 ` [BOOT-WRAPPER v2 09/10] Add printing functions Mark Rutland
2024-08-21 16:55 ` Andre Przywara
2024-08-12 10:15 ` [BOOT-WRAPPER v2 10/10] Boot CPUs sequentially Mark Rutland
2024-08-21 17:49 ` Andre Przywara
2024-08-22 10:02 ` Mark Rutland [this message]
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=ZscMvEFWrPdlIC56@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=akos.denke@arm.com \
--cc=andre.przywara@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=luca.fancellu@arm.com \
--cc=maz@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox