From: "Andrew F. Davis" <afd@ti.com> To: Tony Lindgren <tony@atomide.com>, Tero Kristo <t-kristo@ti.com> Cc: Keerthy <j-keerthy@ti.com>, Russell King <rmk+kernel@armlinux.org.uk>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot Date: Tue, 14 Mar 2017 11:02:02 -0500 [thread overview] Message-ID: <d0fe191f-66f8-b72d-0a2a-00815e663a8d@ti.com> (raw) In-Reply-To: <20170314151725.GC20572@atomide.com> On 03/14/2017 10:17 AM, Tony Lindgren wrote: > * Tero Kristo <t-kristo@ti.com> [170314 00:32]: >> On 13/03/17 22:52, Tony Lindgren wrote: >>> Additionally we also need to fix the hot-unplug code to properly park CPU1 >>> to the bootrom loop so it's not affected by SDRAM changes done by kexec >>> booting kernel. >> >> Imo, we are doing too much bandaid hackery for this issue now. How much do >> we care if the older kernels don't work properly with kexec? I know I don't >> care a bit myself. It means you just need to do 1 cold-boot for the system >> to fix it. > > Well kexec is a standard Linux feature and it is currently working and > at least I care. > > And if the CPU1 start-up address is programmed to be in the currently > booting kernel's area by something else, it's almost certainly totally > broken. > I disagree, the core can be parked correctly and still have the boot-to address point to anywhere. There are two registers in play here, one sets the target jump-to address, the other lets it out of the parking loop. To know we are not parked we need to check the parking release register, the jump-to address is completely irrelevant as a check for proper parking. > Note that this still does not remove the need to park CPU1 properly to > bootrom loop. > I agree, and if we always park the the core correctly every time then there is no reason to do all these checks and resets, we just boot as normal. If the core is not parked correctly then the system is messed up and should be cold-booted, we have no way to know whether that core is off running in space wreaking stuff. I cannot think of any reliable test, for now the focus should be figuring out why we have escaped cores in the first place. In my testing, core1 always ends up looping in omap4_cpu_die(), the loop in this function doesn't check for the boot-to address register, just the core release register. I'm not sure how this works at all, if even in the same kernel, when trying to bring this core back up it will ignore our set boot-to address and return to the caller of this function. Maybe the kernel is able to cope with that, but it does not seem to be the intended wakeup path. I'll do some testing and see if this will help in omap4_cpu_die(): if (boot_cpu == smp_processor_id()) { /* * OK, proper wakeup, we're done */ + + boot_address = readl_relaxed(base + OMAP_AUX_CORE_BOOT_1); + boot_address(); + break; } Andrew
WARNING: multiple messages have this Message-ID (diff)
From: afd@ti.com (Andrew F. Davis) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot Date: Tue, 14 Mar 2017 11:02:02 -0500 [thread overview] Message-ID: <d0fe191f-66f8-b72d-0a2a-00815e663a8d@ti.com> (raw) In-Reply-To: <20170314151725.GC20572@atomide.com> On 03/14/2017 10:17 AM, Tony Lindgren wrote: > * Tero Kristo <t-kristo@ti.com> [170314 00:32]: >> On 13/03/17 22:52, Tony Lindgren wrote: >>> Additionally we also need to fix the hot-unplug code to properly park CPU1 >>> to the bootrom loop so it's not affected by SDRAM changes done by kexec >>> booting kernel. >> >> Imo, we are doing too much bandaid hackery for this issue now. How much do >> we care if the older kernels don't work properly with kexec? I know I don't >> care a bit myself. It means you just need to do 1 cold-boot for the system >> to fix it. > > Well kexec is a standard Linux feature and it is currently working and > at least I care. > > And if the CPU1 start-up address is programmed to be in the currently > booting kernel's area by something else, it's almost certainly totally > broken. > I disagree, the core can be parked correctly and still have the boot-to address point to anywhere. There are two registers in play here, one sets the target jump-to address, the other lets it out of the parking loop. To know we are not parked we need to check the parking release register, the jump-to address is completely irrelevant as a check for proper parking. > Note that this still does not remove the need to park CPU1 properly to > bootrom loop. > I agree, and if we always park the the core correctly every time then there is no reason to do all these checks and resets, we just boot as normal. If the core is not parked correctly then the system is messed up and should be cold-booted, we have no way to know whether that core is off running in space wreaking stuff. I cannot think of any reliable test, for now the focus should be figuring out why we have escaped cores in the first place. In my testing, core1 always ends up looping in omap4_cpu_die(), the loop in this function doesn't check for the boot-to address register, just the core release register. I'm not sure how this works at all, if even in the same kernel, when trying to bring this core back up it will ignore our set boot-to address and return to the caller of this function. Maybe the kernel is able to cope with that, but it does not seem to be the intended wakeup path. I'll do some testing and see if this will help in omap4_cpu_die(): if (boot_cpu == smp_processor_id()) { /* * OK, proper wakeup, we're done */ + + boot_address = readl_relaxed(base + OMAP_AUX_CORE_BOOT_1); + boot_address(); + break; } Andrew
next prev parent reply other threads:[~2017-03-14 16:02 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-13 20:52 [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot Tony Lindgren 2017-03-13 20:52 ` Tony Lindgren 2017-03-13 21:28 ` Andrew F. Davis 2017-03-13 21:28 ` Andrew F. Davis 2017-03-13 21:47 ` Tony Lindgren 2017-03-13 21:47 ` Tony Lindgren 2017-03-14 7:30 ` Tero Kristo 2017-03-14 7:30 ` Tero Kristo 2017-03-14 15:17 ` Tony Lindgren 2017-03-14 15:17 ` Tony Lindgren 2017-03-14 16:02 ` Andrew F. Davis [this message] 2017-03-14 16:02 ` Andrew F. Davis 2017-03-14 16:41 ` Tony Lindgren 2017-03-14 16:41 ` Tony Lindgren 2017-03-14 17:57 ` Andrew F. Davis 2017-03-14 17:57 ` Andrew F. Davis 2017-03-14 18:14 ` Tony Lindgren 2017-03-14 18:14 ` Tony Lindgren 2017-03-15 17:22 ` Tony Lindgren 2017-03-15 17:22 ` Tony Lindgren 2017-03-16 15:29 ` Tony Lindgren 2017-03-16 15:29 ` Tony Lindgren 2017-03-17 9:24 ` Russell King - ARM Linux 2017-03-17 9:24 ` Russell King - ARM Linux 2017-03-17 13:57 ` Tony Lindgren 2017-03-17 13:57 ` Tony Lindgren 2017-03-17 16:25 ` Andrew F. Davis 2017-03-17 16:25 ` Andrew F. Davis 2017-03-22 17:57 ` Tony Lindgren 2017-03-22 17:57 ` Tony Lindgren -- strict thread matches above, loose matches on Subject: below -- 2017-02-13 21:50 [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 " Tony Lindgren 2017-02-13 21:50 ` Tony Lindgren 2017-02-14 19:36 ` Tony Lindgren 2017-02-14 19:36 ` Tony Lindgren 2017-02-15 18:39 ` Tony Lindgren 2017-02-15 18:39 ` Tony Lindgren 2017-02-15 19:12 ` Tony Lindgren 2017-02-15 19:12 ` Tony Lindgren 2017-02-15 22:13 ` Andrew F. Davis 2017-02-15 22:13 ` Andrew F. Davis 2017-02-15 22:27 ` Tony Lindgren 2017-02-15 22:27 ` Tony Lindgren 2017-02-16 16:10 ` Tony Lindgren 2017-02-16 16:10 ` Tony Lindgren 2017-02-16 16:21 ` Tony Lindgren 2017-02-16 16:21 ` Tony Lindgren 2017-02-16 16:29 ` Andrew F. Davis 2017-02-16 16:29 ` Andrew F. Davis 2017-02-16 16:54 ` Tony Lindgren 2017-02-16 16:54 ` Tony Lindgren 2017-02-16 19:07 ` Tony Lindgren 2017-02-16 19:07 ` Tony Lindgren 2017-02-17 15:55 ` Tony Lindgren 2017-02-17 15:55 ` Tony Lindgren 2017-02-17 20:27 ` Andrew F. Davis 2017-02-17 20:27 ` Andrew F. Davis 2017-02-17 21:09 ` Tony Lindgren 2017-02-17 21:09 ` Tony Lindgren
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=d0fe191f-66f8-b72d-0a2a-00815e663a8d@ti.com \ --to=afd@ti.com \ --cc=j-keerthy@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=rmk+kernel@armlinux.org.uk \ --cc=t-kristo@ti.com \ --cc=tony@atomide.com \ /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: linkBe 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.