public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: u-boot@lists.denx.de
Subject: [U-Boot] scripts: RPi 2: only 1 out of 4 CPUs brought up
Date: Fri, 10 Jul 2015 23:16:49 -0700	[thread overview]
Message-ID: <87fv4v9q26.fsf@eliezer.anholt.net> (raw)
In-Reply-To: <55A09A00.6000707@wwwdotorg.org>

Stephen Warren <swarren@wwwdotorg.org> writes:

> On 06/30/2015 05:56 AM, Jonas Jensen wrote:
>> Hello,
>> 
>> I have found the following issue with RPi 2:
>> 
>> Only 1 CPU is brought up when the kernel is started from script (see [1]).
>> 
>> All 4 CPUs are brought up if started "manually" typing in environment
>> variables from said script (see [2]).
>
> I suspect it's a fluke that it works when you run things manually/slowly.
>
> I /think/ that before the binary FW starts U-Boot (or whatever it
> boots), it releases all 4 CPUs from reset, and CPU1..n all end up
> running a tiny piece of code ("SMP pen") that just loops doing nothing
> until some flag is set. All code that runs on CPU0 must be careful not
> to corrupt that code or the flag it uses. However, U-Boot (and I expect
> the upstream kernel) don't yet know about this, and hence
> sometimes/often corrupt that SMP pen, resulting in strange behaviour.
> I'm pretty sure I've seen all 4 CPUs start booting the Linux kernel in
> parallel before.
>
> In summary, I know there are issues in this area when using U-Boot. I
> don't know of any fix at present. Either U-Boot must hard-code some
> reserved memory regions, or perhaps the binary FW has some way of
> informing SW where the SMP pen region is, and U-Boot needs to learn how
> to find/interpret that information (and pass it to the kernel via
> /memreserve/ or similar in DT).
>
> Eric, did you find out any more details on the SMP pen mechanism since I
> last asked you about it?

Oh, I thought we were settled on this back in May -- the CPUs are
spinning in the low 8kb.  They are in that state by the time the
firmware has handed off to us.  I think it's modifying a /memreserve/
node for you to know where the pen is.

Hey, do you know what's going on with merging code?  I feel really stuck
here -- I've got a graphics driver, and a Pi2 implementation, and Andrea
has cpufreq, and we're still stuck on getting the firmware driver
merged.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150710/79b28754/attachment.sig>

  reply	other threads:[~2015-07-11  6:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-30 11:56 [U-Boot] scripts: RPi 2: only 1 out of 4 CPUs brought up Jonas Jensen
2015-07-11  4:22 ` Stephen Warren
2015-07-11  6:16   ` Eric Anholt [this message]
2015-07-14  4:49     ` Stephen Warren

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=87fv4v9q26.fsf@eliezer.anholt.net \
    --to=eric@anholt.net \
    --cc=u-boot@lists.denx.de \
    /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