Re: imx7d enable second core

[Andrey Smirnov <andrew.smirnov@gmail.com>]

On Thu, Jul 19, 2018 at 12:16 AM Giorgio Dal Molin
<giorgio.nicole@arcor.de> wrote:
>
> Hi Andrey,
>
> thank you for your answer,
>
> > On July 18, 2018 at 6:54 PM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
> >
> >
> > On Wed, Jul 18, 2018 at 12:28 AM Giorgio Dal Molin
> > <giorgio.nicole@arcor.de> wrote:
> > >
> > > Hi all,
> > >
> > > I'm currently working with the imx7d sabre board from NXP.
> > >
> > > I have now a running barebox bootloader and a booting kernel.
> > >
> > > My problem is now that, apparently, only one core is active:
> > >
> > > ...
> > > commandline: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: root=/dev/mmcblk0p2 rootdelay=1
> > > Starting kernel in secure mode
> >
> > AFAIK, this means that you are booting in secure mode and secure
> > monitor code, which also implements PSCI needed for SMP to work, will
> > _not_ be installed by Barebox. One way to fix this would be to set:
> >
> >  global.bootm.secure_state=nonsecure
> >
> > before booting Linux. Doing that I get:
> >
> > # lscpu -e
> > CPU SOCKET CORE ONLINE MAXMHZ   MINMHZ
> > 0   0      0    yes    996.0000 792.0000
> > 1   0      1    yes    996.0000 792.0000
> > #
> >
> > on my SabreSD board.
> >
> > Thanks,
> > Andrey Smirnov
> >
>
> yesterday I experimented a bit more with board + barebox + kernel
> and found the following procedure that (almost) works:
>
>  - enable the PSCI support in barebox and kernel;
>  - #define DEBUG in '<barebox>/arch/arm/cpu/psci.c' to have the command 'smc';
>  - boot up barebox on the board, call 'smc -n' and start the kernel:
>

Is there any particular reason you used a command meant for debugging
instead of "global.bootm.secure_state=nonsecure", which is available
without needing to do any source modification?

> ...
> Hit any key to stop autoboot:    4
> imx7: / tftp karm
> eth0: No MAC address set. Using random address 1a:4e:1f:63:ea:77
> eth0: 1000Mbps full duplex link detected
> T       [#################################################################]
> imx7: / tftp darm
>         [#################################################################]
> imx7: / smc -n
> imx7: / boot
>
> Loading ARM Linux zImage 'karm'
> Loading devicetree from 'darm'
> commandline: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: root=/dev/mmcblk0p2 rootdelay=1
> Starting kernel in secure mode
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.17.8-dirty (giorgio@BV_blfs) (gcc version 8.1.0 (OSELAS.Toolchain-2018.02.0)) #2 SMP Thu Jul 19 08:13:42 CEST 2018
> [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [    0.000000] CPU: div instructions available: patching division code
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [    0.000000] OF: fdt: Machine model: Freescale i.MX7 SabreSD Board
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] cma: Reserved 64 MiB at 0xba000000
> [    0.000000] psci: probing for conduit method from DT.
> [    0.000000] psci: psci_get_version: called.
> [    0.000000] psci: PSCIv1.0 detected in firmware.
> [    0.000000] psci: Using standard PSCI v0.2 function IDs
> [    0.000000] psci: MIGRATE_INFO_TYPE not supported.
> [    0.000000] psci: SMC Calling Convention v1.0
> [    0.000000] percpu: Embedded 14 pages/cpu @(ptrval) s36392 r0 d20952 u57344
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 260608
> [    0.000000] Kernel command line: console=ttymxc0,115200n8 ip=11.0.0.4::11.0.0.2:255.0.0.0::eth0: root=/dev/mmcblk0p2 rootdelay=1 video=mxsfb0:dev=hdmi,1024x768M@60
> [    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> [    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> [    0.000000] Memory: 950776K/1048576K available (10240K kernel code, 473K rwdata, 2216K rodata, 1024K init, 7790K bss, 32264K reserved, 65536K cma-reserved, 196196K highmem)
> [    0.000000] Virtual kernel memory layout:
> [    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
> [    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
> [    0.000000]     vmalloc : 0xf0800000 - 0xff800000   ( 240 MB)
> [    0.000000]     lowmem  : 0xc0000000 - 0xf0000000   ( 768 MB)
> [    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
> [    0.000000]       .text : 0x(ptrval) - 0x(ptrval)   (11232 kB)
> [    0.000000]       .init : 0x(ptrval) - 0x(ptrval)   (1024 kB)
> [    0.000000]       .data : 0x(ptrval) - 0x(ptrval)   ( 474 kB)
> [    0.000000]        .bss : 0x(ptrval) - 0x(ptrval)   (7791 kB)
> [    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [    0.000000] Running RCU self tests
> [    0.000000] Hierarchical RCU implementation.
> [    0.000000]  RCU event tracing is enabled.
> [    0.000000]  RCU lockdep checking is enabled.
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000]  Offload RCU callbacks from CPUs: (none).
> [    0.000000] arch_timer: cp15 timer(s) running at 8.00MHz (virt).
> [    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
> [    0.000008] sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
> [    0.000032] Switching to timer-based delay loop, resolution 125ns
> [    0.000546] Switching to timer-based delay loop, resolution 41ns
> [    0.000575] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
> [    0.000602] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
> [    0.002000] Console: colour dummy device 80x30
> [    0.002032] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
> [    0.002051] ... MAX_LOCKDEP_SUBCLASSES:  8
> [    0.002069] ... MAX_LOCK_DEPTH:          48
> [    0.002087] ... MAX_LOCKDEP_KEYS:        8191
> [    0.002104] ... CLASSHASH_SIZE:          4096
> [    0.002122] ... MAX_LOCKDEP_ENTRIES:     32768
> [    0.002140] ... MAX_LOCKDEP_CHAINS:      65536
> [    0.002158] ... CHAINHASH_SIZE:          32768
> [    0.002176]  memory used by lock dependency info: 4655 kB
> [    0.002194]  per task-struct memory footprint: 1536 bytes
> [    0.002247] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
> [    0.002281] pid_max: default: 32768 minimum: 301
> [    0.002609] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.002641] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [    0.004422] CPU: Testing write buffer coherency: ok
> [    0.005337] CPU0: update cpu_capacity 1024
> [    0.005364] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.006831] Setting up static identity map for 0x80100000 - 0x80100060
> [    0.007259] Hierarchical SRCU implementation.
> [    0.008927] smp: Bringing up secondary CPUs ...
> [    0.010632] psci: psci_cpu_on: called. cpuid: 0x00000001
> [    0.010993] CPU1: update cpu_capacity 1024
> [    0.011005] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> [    0.011622] smp: Brought up 1 node, 2 CPUs
> [    0.011663] SMP: Total of 2 processors activated (96.00 BogoMIPS).
> [    0.011682] CPU: All CPU(s) started in SVC mode.
> [    0.013716] devtmpfs: initialized
> ...
>
>
> this way the kernel smp is able to start up the second core.
> The problem that remains with this setup is that the CAAM crypto
> coprocessor in the imx7 does not work anymore:
>
> ...
> [    5.265081] mmc1: SDHCI controller on 30b50000.usdhc [30b50000.usdhc] using ADMA
> [    5.308453] mmc2: SDHCI controller on 30b60000.usdhc [30b60000.usdhc] using ADMA
> [    5.320799] caam 30900000.caam: Entropy delay = 3200
> [    5.352668] caam 30900000.caam: failed to acquire DECO 0
> [    5.358008] caam 30900000.caam: failed to instantiate RNG
> [    5.366479] usbcore: registered new interface driver usbhid
> [    5.372081] usbhid: USB HID core driver
> ...

I've never used CAAM, so I am not sure what's going on, but my
educated guess would that this might have to do with TrustZone
permissions.

>
> This is probably due to the 'secure mode' in which the kernel is now booting
> but I need a bit more background knowledge about the PSCI in general to really
> understand what's going on here.

You kernel was booting in 'secure mode' before, now it actually boots
in 'nonsecure', but because you installed the monitor through a
backdoor that log line still prints 'secure'.

Thanks,
Andrey Smirnov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox