From: "bartvanderlaan" <bartvanderlaan@gmail.com>
To: meta-freescale@lists.yoctoproject.org
Subject: IMX7D bring up of second core
Date: Tue, 29 Sep 2020 23:14:01 -0700 [thread overview]
Message-ID: <n2r8.1601446441509595295.VPK3@lists.yoctoproject.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 4572 bytes --]
Hi,
I have recently started working on a project that is based on linux-fslc. The target board is a Technexion pico imx7d.
Hopefully I have come to the right place to ask this question and this post provides enough information to paint a complete picture.
I have trouble bringing up the 2nd core of the SoC and have tried to narrow this down. I'm comparing behaviour to a rescue image from Technexion (I have two pico-pi boards) which boots both processors in SVC.
Board with project image:
>
> [ 0.007136] CPU: Testing write buffer coherency: ok
> [ 0.008708] CPU0: update cpu_capacity 1024
> [ 0.008738] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [ 0.011558] Setting up static identity map for 0x80100000 - 0x80100078
> [ 0.012194] rcu: Hierarchical SRCU implementation.
> [ 0.013650] smp: Bringing up secondary CPUs ...
> [ 0.016375] smp: Brought up 1 node, 1 CPU
> [ 0.016405] SMP: Total of 1 processors activated (48.00 BogoMIPS).
> [ 0.016427] CPU: All CPU(s) started in SVC mode.
>
Board with rescue image:
>
> CPU: Testing write buffer coherency: ok
> CPU0: update cpu_capacity 1024
> CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> Setting up static identity map for 0x80100000 - 0x80100058
> CPU1: update cpu_capacity 1024
> CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> Brought up 2 CPUs
> SMP: Total of 2 processors activated (32.00 BogoMIPS).
> CPU: All CPU(s) started in SVC mode.
>
Things I have tried:
- 5.0.7-fslc and 5.4.20-fslc.
- Remove CONFIG_ARMV7_BOOT_SEC_DEFAULT in u-boot-fslc, which does boot both processors in HYP mode resulting in some other issues. I don't know much about the differences between secure, non-secure and hypervisor mode and could not find a defenitive answer online which and if a certain mode is mandatory for the 2nd core.
- Debug the boot process in secure mode with pr_info:
SMP is actually trying to get cpu1 up but is failing when invoking callbacks.
Looking at the call below to cpu_up for cpu 1, it returns an error code -38 although the return value is not used in with an error handler.
github.com ( https://github.com/Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/smp.c#L578 ) Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/smp.c#L578 ( https://github.com/Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/smp.c#L578 )
Copy
* idle_threads_init();
* cpuhp_threads_init();
*
* pr_info( "Bringing up secondary CPUs ...\n" );
*
* /* FIXME: This should be done in userspace --RR */
* for_each_present_cpu(cpu) {
* if (num_online_cpus() >= setup_max_cpus)
* break ;
* if (!cpu_online(cpu))
* cpu_up(cpu);
* }
*
* num_nodes = num_online_nodes();
* num_cpus = num_online_cpus();
* pr_info( "Brought up %d node%s, %d CPU%s\n" ,
* num_nodes, (num_nodes > 1 ? "s" : "" ),
* num_cpus, (num_cpus > 1 ? "s" : "" ));
*
* /* Any cleanup work */
* smp_cpus_done(setup_max_cpus);
This traces all the way back to the moment the callback is invoked for CPUHP_BRINGUP_CPU (cpuhp_state #85 ) where ret = cb(cpu) get’s the value -38, which if I’m not mistaken means ENOSYS.
github.com ( https://github.com/Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/cpu.c#L168 ) Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/cpu.c#L168 ( https://github.com/Freescale/linux-fslc/blob/c7a0e482a175b632bfd5522bc6d5bfe7785ee9a9/kernel/cpu.c#L168 )
Copy
*
* return -EAGAIN;
* }
*
* if (!step->multi_instance) {
* WARN_ON_ONCE(lastp && *lastp);
* cb = bringup ? step->startup.single : step->teardown.single;
* if (!cb)
* return 0 ;
* trace_cpuhp_enter(cpu, st->target, state, cb);
* ret = cb(cpu);
* trace_cpuhp_exit(cpu, st->state, state, ret);
* return ret;
* }
* cbm = bringup ? step->startup.multi : step->teardown.multi;
* if (!cbm)
* return 0 ;
*
* /* Single invocation for instance add/remove */
* if (node) {
* WARN_ON_ONCE(lastp && *lastp);
The callback invocations for this list below did pass without this error just before that for cpu1:
1; CPUHP_CREATE_THREADS
2; CPUHP_PERF_PREPARE
35; CPUHP_WORKQUEUE_PREP
37; CPUHP_HRTIMERS_PREPARE
40; CPUHP_SMPCFD_PREPARE
41; CPUHP_RELAY_PREPARE
44; CPUHP_RCUTREE_PREP
62; CPUHP_TIMERS_PREPARE
Hopefully someone will see my post and share some experience in the matter, or point me to a place where this question might best be answered.
Best regards,
Bart van der Laan
[-- Attachment #2: Type: text/html, Size: 21331 bytes --]
next reply other threads:[~2020-09-30 6:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 6:14 bartvanderlaan [this message]
2020-09-30 11:50 ` [meta-freescale] IMX7D bring up of second core Otavio Salvador
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=n2r8.1601446441509595295.VPK3@lists.yoctoproject.org \
--to=bartvanderlaan@gmail.com \
--cc=meta-freescale@lists.yoctoproject.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).