* imx7d dual core boot
@ 2020-03-26 10:21 Giorgio
2020-03-27 5:56 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-03-26 10:21 UTC (permalink / raw)
To: barebox
Hi,
I'm having problems booting a linux kernel image on an imx7d.
What I want is to boot in nonsecure mode and that the kernel enables the
second core with the PSCI.
What I see is that barebox crashes within the call to __mmu_cache_on()
in the file arch/arm/cpu/sm.c:
int armv7_secure_monitor_install(void)
{
...
if (mmuon) {
/*
* If the MMU was already turned on in secure mode, enable it in
* non-secure mode aswell
*/
__mmu_cache_on();
}
...
As a workaround, if I comment the call to __mmu_cache_on(), the system
boots properly with 2 cores:
Loading ARM Linux zImage '/mnt/boot/kernel.img'
Loading devicetree from '/mnt/boot/devtree.dtb'
commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
Starting kernel in nonsecure mode
[ 0.000000] 000: Booting Linux on physical CPU 0x0
[ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
[ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] 000: CPU: div instructions available: patching division code
[ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
t[ 0.000000] 000: Memory policy: Data cache writealloc
[ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
[ 0.000000] 000: psci: probing for conduit method from DT.
[ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
[ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
[ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] 000: psci: SMC Calling Convention v1.0
[ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
[ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
[ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
[ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
[ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
[ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
[ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
[ 0.000000] 000: Tasks RCU enabled.
[ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
[ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
[ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
[ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
[ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
[ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
[ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
[ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[ 0.001597] 000: Console: colour dummy device 80x30
[ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
[ 0.001650] 000: pid_max: default: 32768 minimum: 301
[ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.002631] 000: CPU: Testing write buffer coherency: ok
[ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
[ 0.079972] 000: rcu: Hierarchical SRCU implementation.
[ 0.160105] 000: smp: Bringing up secondary CPUs ...
[ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
[ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
[ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
[ 0.281170] 000: devtmpfs: initialized
[ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
giorgio
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-03-26 10:21 imx7d dual core boot Giorgio
@ 2020-03-27 5:56 ` Ahmad Fatoum
2020-03-27 8:27 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-03-27 5:56 UTC (permalink / raw)
To: Giorgio, barebox
Hello,
On 3/26/20 11:21 AM, Giorgio wrote:
> Hi,
>
> I'm having problems booting a linux kernel image on an imx7d.
>
> What I want is to boot in nonsecure mode and that the kernel enables the
> second core with the PSCI.
>
> What I see is that barebox crashes within the call to __mmu_cache_on()
> in the file arch/arm/cpu/sm.c:
The kind of crash may be useful info. Can you copy the whole boot log?
>
> int armv7_secure_monitor_install(void)
> {
> ...
> if (mmuon) {
> /*
> * If the MMU was already turned on in secure mode, enable it in
> * non-secure mode aswell
> */
> __mmu_cache_on();
> }
> ...
>
>
> As a workaround, if I comment the call to __mmu_cache_on(), the system
> boots properly with 2 cores:
>
> Loading ARM Linux zImage '/mnt/boot/kernel.img'
> Loading devicetree from '/mnt/boot/devtree.dtb'
> commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
> Starting kernel in nonsecure mode
> [ 0.000000] 000: Booting Linux on physical CPU 0x0
> [ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
> [ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
> [ 0.000000] 000: CPU: div instructions available: patching division code
> [ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> t[ 0.000000] 000: Memory policy: Data cache writealloc
> [ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
> [ 0.000000] 000: psci: probing for conduit method from DT.
> [ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
> [ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
> [ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
> [ 0.000000] 000: psci: SMC Calling Convention v1.0
> [ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
> [ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
> [ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
> [ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
> [ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
> [ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
> [ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
> [ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
> [ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
> [ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
> [ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
> [ 0.000000] 000: Tasks RCU enabled.
> [ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
> [ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
> [ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
> [ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
> [ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
> [ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
> [ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
> [ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
> [ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
> [ 0.001597] 000: Console: colour dummy device 80x30
> [ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
> [ 0.001650] 000: pid_max: default: 32768 minimum: 301
> [ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
> [ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
> [ 0.002631] 000: CPU: Testing write buffer coherency: ok
> [ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
> [ 0.079972] 000: rcu: Hierarchical SRCU implementation.
> [ 0.160105] 000: smp: Bringing up secondary CPUs ...
> [ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
> [ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
> [ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
> [ 0.281170] 000: devtmpfs: initialized
> [ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
>
>
> giorgio
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-03-27 5:56 ` Ahmad Fatoum
@ 2020-03-27 8:27 ` Giorgio
2020-03-27 10:01 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-03-27 8:27 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi,
maybe 'crash' was not the best word to describe the effect I see;
the bootloader just stops running, never returns from the call
to __mmu_cache_on(), there's no debug messages or stack dumps;
in this case the kernel image is not started.
I think on my arch / soc __mmu_cache_on() calls some asm coded function
defined in arch/arm/cpu/cache-armv7.S (v7_mmu_cache_on) and one
of the opcodes there crashes the cpu directly. Maybe I should try to
dump the core state (registers, ...) on the console just before jumping
to v7_mmu_cache_on.
giorgio
On 3/27/20 6:56 AM, Ahmad Fatoum wrote:
> Hello,
>
> On 3/26/20 11:21 AM, Giorgio wrote:
>> Hi,
>>
>> I'm having problems booting a linux kernel image on an imx7d.
>>
>> What I want is to boot in nonsecure mode and that the kernel enables the
>> second core with the PSCI.
>>
>> What I see is that barebox crashes within the call to __mmu_cache_on()
>> in the file arch/arm/cpu/sm.c:
>
> The kind of crash may be useful info. Can you copy the whole boot log?
>
>>
>> int armv7_secure_monitor_install(void)
>> {
>> ...
>> if (mmuon) {
>> /*
>> * If the MMU was already turned on in secure mode, enable it in
>> * non-secure mode aswell
>> */
>> __mmu_cache_on();
>> }
>> ...
>>
>>
>> As a workaround, if I comment the call to __mmu_cache_on(), the system
>> boots properly with 2 cores:
>>
>> Loading ARM Linux zImage '/mnt/boot/kernel.img'
>> Loading devicetree from '/mnt/boot/devtree.dtb'
>> commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>> Starting kernel in nonsecure mode
>> [ 0.000000] 000: Booting Linux on physical CPU 0x0
>> [ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
>> [ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>> [ 0.000000] 000: CPU: div instructions available: patching division code
>> [ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>> t[ 0.000000] 000: Memory policy: Data cache writealloc
>> [ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
>> [ 0.000000] 000: psci: probing for conduit method from DT.
>> [ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
>> [ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
>> [ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
>> [ 0.000000] 000: psci: SMC Calling Convention v1.0
>> [ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
>> [ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
>> [ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>> [ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
>> [ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
>> [ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
>> [ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
>> [ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>> [ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
>> [ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
>> [ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
>> [ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
>> [ 0.000000] 000: Tasks RCU enabled.
>> [ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>> [ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>> [ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
>> [ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
>> [ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
>> [ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
>> [ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
>> [ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
>> [ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>> [ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
>> [ 0.001597] 000: Console: colour dummy device 80x30
>> [ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
>> [ 0.001650] 000: pid_max: default: 32768 minimum: 301
>> [ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>> [ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>> [ 0.002631] 000: CPU: Testing write buffer coherency: ok
>> [ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
>> [ 0.079972] 000: rcu: Hierarchical SRCU implementation.
>> [ 0.160105] 000: smp: Bringing up secondary CPUs ...
>> [ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
>> [ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
>> [ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
>> [ 0.281170] 000: devtmpfs: initialized
>> [ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
>>
>>
>> giorgio
>>
>> _______________________________________________
>> barebox mailing list
>> barebox@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/barebox
>>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-03-27 8:27 ` Giorgio
@ 2020-03-27 10:01 ` Ahmad Fatoum
2020-03-30 14:33 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-03-27 10:01 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hello,
On 3/27/20 9:27 AM, Giorgio wrote:
> Hi,
>
> maybe 'crash' was not the best word to describe the effect I see;
>
> the bootloader just stops running, never returns from the call
> to __mmu_cache_on(), there's no debug messages or stack dumps;
> in this case the kernel image is not started.
>
> I think on my arch / soc __mmu_cache_on() calls some asm coded function
> defined in arch/arm/cpu/cache-armv7.S (v7_mmu_cache_on) and one
> of the opcodes there crashes the cpu directly. Maybe I should try to
> dump the core state (registers, ...) on the console just before jumping
> to v7_mmu_cache_on.
AFAIU, non-secure barebox keeps reusing the secure monitor barebox till
it boots the kernel. The secure monitor already had translation tables
set up and active and non-secure barebox reuses those.
Given that this should've worked once, could you run a git-bisect and
see when it broke?
If you make bnet the default target, only board interaction you need
for bisecting should be the power cycle when you do a git bisect bad.
This is most likely the fastest way to find what broke it.
Cheers
Ahmad
>
> giorgio
>
> On 3/27/20 6:56 AM, Ahmad Fatoum wrote:
>> Hello,
>>
>> On 3/26/20 11:21 AM, Giorgio wrote:
>>> Hi,
>>>
>>> I'm having problems booting a linux kernel image on an imx7d.
>>>
>>> What I want is to boot in nonsecure mode and that the kernel enables the
>>> second core with the PSCI.
>>>
>>> What I see is that barebox crashes within the call to __mmu_cache_on()
>>> in the file arch/arm/cpu/sm.c:
>>
>> The kind of crash may be useful info. Can you copy the whole boot log?
>>
>>>
>>> int armv7_secure_monitor_install(void)
>>> {
>>> ...
>>> if (mmuon) {
>>> /*
>>> * If the MMU was already turned on in secure mode, enable it in
>>> * non-secure mode aswell
>>> */
>>> __mmu_cache_on();
>>> }
>>> ...
>>>
>>>
>>> As a workaround, if I comment the call to __mmu_cache_on(), the system
>>> boots properly with 2 cores:
>>>
>>> Loading ARM Linux zImage '/mnt/boot/kernel.img'
>>> Loading devicetree from '/mnt/boot/devtree.dtb'
>>> commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>> Starting kernel in nonsecure mode
>>> [ 0.000000] 000: Booting Linux on physical CPU 0x0
>>> [ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
>>> [ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>> [ 0.000000] 000: CPU: div instructions available: patching division code
>>> [ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>> t[ 0.000000] 000: Memory policy: Data cache writealloc
>>> [ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
>>> [ 0.000000] 000: psci: probing for conduit method from DT.
>>> [ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
>>> [ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
>>> [ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
>>> [ 0.000000] 000: psci: SMC Calling Convention v1.0
>>> [ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
>>> [ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
>>> [ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>> [ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
>>> [ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
>>> [ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
>>> [ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
>>> [ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>> [ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
>>> [ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
>>> [ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
>>> [ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
>>> [ 0.000000] 000: Tasks RCU enabled.
>>> [ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>>> [ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>>> [ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
>>> [ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
>>> [ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
>>> [ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
>>> [ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
>>> [ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
>>> [ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>>> [ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
>>> [ 0.001597] 000: Console: colour dummy device 80x30
>>> [ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
>>> [ 0.001650] 000: pid_max: default: 32768 minimum: 301
>>> [ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>> [ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>> [ 0.002631] 000: CPU: Testing write buffer coherency: ok
>>> [ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
>>> [ 0.079972] 000: rcu: Hierarchical SRCU implementation.
>>> [ 0.160105] 000: smp: Bringing up secondary CPUs ...
>>> [ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
>>> [ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
>>> [ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
>>> [ 0.281170] 000: devtmpfs: initialized
>>> [ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
>>>
>>>
>>> giorgio
>>>
>>> _______________________________________________
>>> barebox mailing list
>>> barebox@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/barebox
>>>
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-03-27 10:01 ` Ahmad Fatoum
@ 2020-03-30 14:33 ` Giorgio
2020-04-03 13:01 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-03-30 14:33 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi Ahmad,
I think I've found the problem with my imx7d:
in your commit id ae0a375ba71ba9b9a70cb7eda177445fcfbf586d:
ARM: cache-armv7: remove duplicate domain initialization
...
you removed the two asm lines:
movne r1, #-1
mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
from arch/arm/cpu/cache-armv7.S
If I add them back then the imx7d does not hang anymore and
the kernel is able to boot and power up the second core as
expected.
I have just one last question: what is the reason for the
'mov r12, lr' at the beginning of v7_mmu_cache_on ?
giorgio
On 3/27/20 11:01 AM, Ahmad Fatoum wrote:
> Hello,
>
> On 3/27/20 9:27 AM, Giorgio wrote:
>> Hi,
>>
>> maybe 'crash' was not the best word to describe the effect I see;
>>
>> the bootloader just stops running, never returns from the call
>> to __mmu_cache_on(), there's no debug messages or stack dumps;
>> in this case the kernel image is not started.
>>
>> I think on my arch / soc __mmu_cache_on() calls some asm coded function
>> defined in arch/arm/cpu/cache-armv7.S (v7_mmu_cache_on) and one
>> of the opcodes there crashes the cpu directly. Maybe I should try to
>> dump the core state (registers, ...) on the console just before jumping
>> to v7_mmu_cache_on.
>
> AFAIU, non-secure barebox keeps reusing the secure monitor barebox till
> it boots the kernel. The secure monitor already had translation tables
> set up and active and non-secure barebox reuses those.
>
> Given that this should've worked once, could you run a git-bisect and
> see when it broke?
>
> If you make bnet the default target, only board interaction you need
> for bisecting should be the power cycle when you do a git bisect bad.
>
> This is most likely the fastest way to find what broke it.
>
> Cheers
> Ahmad
>
>>
>> giorgio
>>
>> On 3/27/20 6:56 AM, Ahmad Fatoum wrote:
>>> Hello,
>>>
>>> On 3/26/20 11:21 AM, Giorgio wrote:
>>>> Hi,
>>>>
>>>> I'm having problems booting a linux kernel image on an imx7d.
>>>>
>>>> What I want is to boot in nonsecure mode and that the kernel enables the
>>>> second core with the PSCI.
>>>>
>>>> What I see is that barebox crashes within the call to __mmu_cache_on()
>>>> in the file arch/arm/cpu/sm.c:
>>>
>>> The kind of crash may be useful info. Can you copy the whole boot log?
>>>
>>>>
>>>> int armv7_secure_monitor_install(void)
>>>> {
>>>> ...
>>>> if (mmuon) {
>>>> /*
>>>> * If the MMU was already turned on in secure mode, enable it in
>>>> * non-secure mode aswell
>>>> */
>>>> __mmu_cache_on();
>>>> }
>>>> ...
>>>>
>>>>
>>>> As a workaround, if I comment the call to __mmu_cache_on(), the system
>>>> boots properly with 2 cores:
>>>>
>>>> Loading ARM Linux zImage '/mnt/boot/kernel.img'
>>>> Loading devicetree from '/mnt/boot/devtree.dtb'
>>>> commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>>> Starting kernel in nonsecure mode
>>>> [ 0.000000] 000: Booting Linux on physical CPU 0x0
>>>> [ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
>>>> [ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>>> [ 0.000000] 000: CPU: div instructions available: patching division code
>>>> [ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>>> t[ 0.000000] 000: Memory policy: Data cache writealloc
>>>> [ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
>>>> [ 0.000000] 000: psci: probing for conduit method from DT.
>>>> [ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
>>>> [ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
>>>> [ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
>>>> [ 0.000000] 000: psci: SMC Calling Convention v1.0
>>>> [ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
>>>> [ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
>>>> [ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>>> [ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
>>>> [ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
>>>> [ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
>>>> [ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
>>>> [ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>>> [ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
>>>> [ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
>>>> [ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
>>>> [ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
>>>> [ 0.000000] 000: Tasks RCU enabled.
>>>> [ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>>>> [ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>>>> [ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
>>>> [ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
>>>> [ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
>>>> [ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
>>>> [ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
>>>> [ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
>>>> [ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>>>> [ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
>>>> [ 0.001597] 000: Console: colour dummy device 80x30
>>>> [ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
>>>> [ 0.001650] 000: pid_max: default: 32768 minimum: 301
>>>> [ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>>> [ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>>> [ 0.002631] 000: CPU: Testing write buffer coherency: ok
>>>> [ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
>>>> [ 0.079972] 000: rcu: Hierarchical SRCU implementation.
>>>> [ 0.160105] 000: smp: Bringing up secondary CPUs ...
>>>> [ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
>>>> [ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
>>>> [ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
>>>> [ 0.281170] 000: devtmpfs: initialized
>>>> [ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
>>>>
>>>>
>>>> giorgio
>>>>
>>>> _______________________________________________
>>>> barebox mailing list
>>>> barebox@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/barebox
>>>>
>>>
>>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-03-30 14:33 ` Giorgio
@ 2020-04-03 13:01 ` Ahmad Fatoum
2020-04-03 13:47 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-04-03 13:01 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hello Giorgio,
On 3/30/20 4:33 PM, Giorgio wrote:
> Hi Ahmad,
>
> I think I've found the problem with my imx7d:
> in your commit id ae0a375ba71ba9b9a70cb7eda177445fcfbf586d:
>
> ARM: cache-armv7: remove duplicate domain initialization
> ...
>
> you removed the two asm lines:
>
> movne r1, #-1
> mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
>
> from arch/arm/cpu/cache-armv7.S
Thanks for bisecting this.
The patch you ended up at is stopping barebox from runnning in manager domain.
This is necessary to avoid speculative execution on memory mapped IO regions.
With manager domain, you can access/execute everything.
Without, you will have to clear the eXecute Never bit for regions you need to execute.
It's cleared by default for the SDRAM banks and for the barebox text section.
SRAM or BootROM that's jumped into after MMU setup need to be explicitly marked
as executable.
That said, I am not sure why it breaks..
I've got myself an i.MX7D and will take a look the coming days
where it goes wrong. If you have new info/patches to share in the
meanwhile, please do. :)
> If I add them back then the imx7d does not hang anymore and
> the kernel is able to boot and power up the second core as
> expected.
>
> I have just one last question: what is the reason for the
> 'mov r12, lr' at the beginning of v7_mmu_cache_on ?
It looks like a left-over.
837795895801e6c3 ("ARM __mmu_cache_*: Do not clobber registers")
made it obsolete.
Cheers
Ahmad
>
> giorgio
>
> On 3/27/20 11:01 AM, Ahmad Fatoum wrote:
>> Hello,
>>
>> On 3/27/20 9:27 AM, Giorgio wrote:
>>> Hi,
>>>
>>> maybe 'crash' was not the best word to describe the effect I see;
>>>
>>> the bootloader just stops running, never returns from the call
>>> to __mmu_cache_on(), there's no debug messages or stack dumps;
>>> in this case the kernel image is not started.
>>>
>>> I think on my arch / soc __mmu_cache_on() calls some asm coded function
>>> defined in arch/arm/cpu/cache-armv7.S (v7_mmu_cache_on) and one
>>> of the opcodes there crashes the cpu directly. Maybe I should try to
>>> dump the core state (registers, ...) on the console just before jumping
>>> to v7_mmu_cache_on.
>>
>> AFAIU, non-secure barebox keeps reusing the secure monitor barebox till
>> it boots the kernel. The secure monitor already had translation tables
>> set up and active and non-secure barebox reuses those.
>>
>> Given that this should've worked once, could you run a git-bisect and
>> see when it broke?
>>
>> If you make bnet the default target, only board interaction you need
>> for bisecting should be the power cycle when you do a git bisect bad.
>>
>> This is most likely the fastest way to find what broke it.
>>
>> Cheers
>> Ahmad
>>
>>>
>>> giorgio
>>>
>>> On 3/27/20 6:56 AM, Ahmad Fatoum wrote:
>>>> Hello,
>>>>
>>>> On 3/26/20 11:21 AM, Giorgio wrote:
>>>>> Hi,
>>>>>
>>>>> I'm having problems booting a linux kernel image on an imx7d.
>>>>>
>>>>> What I want is to boot in nonsecure mode and that the kernel enables the
>>>>> second core with the PSCI.
>>>>>
>>>>> What I see is that barebox crashes within the call to __mmu_cache_on()
>>>>> in the file arch/arm/cpu/sm.c:
>>>>
>>>> The kind of crash may be useful info. Can you copy the whole boot log?
>>>>
>>>>>
>>>>> int armv7_secure_monitor_install(void)
>>>>> {
>>>>> ...
>>>>> if (mmuon) {
>>>>> /*
>>>>> * If the MMU was already turned on in secure mode, enable it in
>>>>> * non-secure mode aswell
>>>>> */
>>>>> __mmu_cache_on();
>>>>> }
>>>>> ...
>>>>>
>>>>>
>>>>> As a workaround, if I comment the call to __mmu_cache_on(), the system
>>>>> boots properly with 2 cores:
>>>>>
>>>>> Loading ARM Linux zImage '/mnt/boot/kernel.img'
>>>>> Loading devicetree from '/mnt/boot/devtree.dtb'
>>>>> commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>>>> Starting kernel in nonsecure mode
>>>>> [ 0.000000] 000: Booting Linux on physical CPU 0x0
>>>>> [ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
>>>>> [ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>>>> [ 0.000000] 000: CPU: div instructions available: patching division code
>>>>> [ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>>>> t[ 0.000000] 000: Memory policy: Data cache writealloc
>>>>> [ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
>>>>> [ 0.000000] 000: psci: probing for conduit method from DT.
>>>>> [ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
>>>>> [ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
>>>>> [ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
>>>>> [ 0.000000] 000: psci: SMC Calling Convention v1.0
>>>>> [ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
>>>>> [ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
>>>>> [ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>>>> [ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
>>>>> [ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
>>>>> [ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
>>>>> [ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
>>>>> [ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>>>> [ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
>>>>> [ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
>>>>> [ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
>>>>> [ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
>>>>> [ 0.000000] 000: Tasks RCU enabled.
>>>>> [ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>>>>> [ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>>>>> [ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
>>>>> [ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
>>>>> [ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
>>>>> [ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
>>>>> [ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
>>>>> [ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
>>>>> [ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>>>>> [ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
>>>>> [ 0.001597] 000: Console: colour dummy device 80x30
>>>>> [ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
>>>>> [ 0.001650] 000: pid_max: default: 32768 minimum: 301
>>>>> [ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>>>> [ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>>>> [ 0.002631] 000: CPU: Testing write buffer coherency: ok
>>>>> [ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
>>>>> [ 0.079972] 000: rcu: Hierarchical SRCU implementation.
>>>>> [ 0.160105] 000: smp: Bringing up secondary CPUs ...
>>>>> [ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
>>>>> [ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
>>>>> [ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
>>>>> [ 0.281170] 000: devtmpfs: initialized
>>>>> [ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
>>>>>
>>>>>
>>>>> giorgio
>>>>>
>>>>> _______________________________________________
>>>>> barebox mailing list
>>>>> barebox@lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/barebox
>>>>>
>>>>
>>>
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-03 13:01 ` Ahmad Fatoum
@ 2020-04-03 13:47 ` Giorgio
2020-04-06 6:16 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-04-03 13:47 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi Ahmad,
thank you for the detailed explanations, I'll have a look
at the armv7 ref. manual for more background.
I wanted just to note, the problem is specifically linked
to enabling the MMU:
in arch/arm/cpu/cache-armv7.S:
orrne r0, r0, #1 @ MMU enabled
...
mcr p15, 0, r0, c1, c0, 0 @ load control register
without the 'orrne ...' the imx7 does not hang.
giorgio
On 4/3/20 3:01 PM, Ahmad Fatoum wrote:
> Hello Giorgio,
>
> On 3/30/20 4:33 PM, Giorgio wrote:
>> Hi Ahmad,
>>
>> I think I've found the problem with my imx7d:
>> in your commit id ae0a375ba71ba9b9a70cb7eda177445fcfbf586d:
>>
>> ARM: cache-armv7: remove duplicate domain initialization
>> ...
>>
>> you removed the two asm lines:
>>
>> movne r1, #-1
>> mcrne p15, 0, r1, c3, c0, 0 @ load domain access control
>>
>> from arch/arm/cpu/cache-armv7.S
>
> Thanks for bisecting this.
> The patch you ended up at is stopping barebox from runnning in manager domain.
> This is necessary to avoid speculative execution on memory mapped IO regions.
> With manager domain, you can access/execute everything.
> Without, you will have to clear the eXecute Never bit for regions you need to execute.
> It's cleared by default for the SDRAM banks and for the barebox text section.
> SRAM or BootROM that's jumped into after MMU setup need to be explicitly marked
> as executable.
>
> That said, I am not sure why it breaks..
>
> I've got myself an i.MX7D and will take a look the coming days
> where it goes wrong. If you have new info/patches to share in the
> meanwhile, please do. :)
>
>> If I add them back then the imx7d does not hang anymore and
>> the kernel is able to boot and power up the second core as
>> expected.
>>
>> I have just one last question: what is the reason for the
>> 'mov r12, lr' at the beginning of v7_mmu_cache_on ?
>
> It looks like a left-over.
> 837795895801e6c3 ("ARM __mmu_cache_*: Do not clobber registers")
> made it obsolete.
>
> Cheers
> Ahmad
>
>>
>> giorgio
>>
>> On 3/27/20 11:01 AM, Ahmad Fatoum wrote:
>>> Hello,
>>>
>>> On 3/27/20 9:27 AM, Giorgio wrote:
>>>> Hi,
>>>>
>>>> maybe 'crash' was not the best word to describe the effect I see;
>>>>
>>>> the bootloader just stops running, never returns from the call
>>>> to __mmu_cache_on(), there's no debug messages or stack dumps;
>>>> in this case the kernel image is not started.
>>>>
>>>> I think on my arch / soc __mmu_cache_on() calls some asm coded function
>>>> defined in arch/arm/cpu/cache-armv7.S (v7_mmu_cache_on) and one
>>>> of the opcodes there crashes the cpu directly. Maybe I should try to
>>>> dump the core state (registers, ...) on the console just before jumping
>>>> to v7_mmu_cache_on.
>>>
>>> AFAIU, non-secure barebox keeps reusing the secure monitor barebox till
>>> it boots the kernel. The secure monitor already had translation tables
>>> set up and active and non-secure barebox reuses those.
>>>
>>> Given that this should've worked once, could you run a git-bisect and
>>> see when it broke?
>>>
>>> If you make bnet the default target, only board interaction you need
>>> for bisecting should be the power cycle when you do a git bisect bad.
>>>
>>> This is most likely the fastest way to find what broke it.
>>>
>>> Cheers
>>> Ahmad
>>>
>>>>
>>>> giorgio
>>>>
>>>> On 3/27/20 6:56 AM, Ahmad Fatoum wrote:
>>>>> Hello,
>>>>>
>>>>> On 3/26/20 11:21 AM, Giorgio wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm having problems booting a linux kernel image on an imx7d.
>>>>>>
>>>>>> What I want is to boot in nonsecure mode and that the kernel enables the
>>>>>> second core with the PSCI.
>>>>>>
>>>>>> What I see is that barebox crashes within the call to __mmu_cache_on()
>>>>>> in the file arch/arm/cpu/sm.c:
>>>>>
>>>>> The kind of crash may be useful info. Can you copy the whole boot log?
>>>>>
>>>>>>
>>>>>> int armv7_secure_monitor_install(void)
>>>>>> {
>>>>>> ...
>>>>>> if (mmuon) {
>>>>>> /*
>>>>>> * If the MMU was already turned on in secure mode, enable it in
>>>>>> * non-secure mode aswell
>>>>>> */
>>>>>> __mmu_cache_on();
>>>>>> }
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> As a workaround, if I comment the call to __mmu_cache_on(), the system
>>>>>> boots properly with 2 cores:
>>>>>>
>>>>>> Loading ARM Linux zImage '/mnt/boot/kernel.img'
>>>>>> Loading devicetree from '/mnt/boot/devtree.dtb'
>>>>>> commandline: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>>>>> Starting kernel in nonsecure mode
>>>>>> [ 0.000000] 000: Booting Linux on physical CPU 0x0
>>>>>> [ 0.000000] 000: Linux version 5.4.24-rt15-dirty (giorgio@BVblfs) (gcc version 9.2.1 20200110 (OSELAS.Toolchain 9.2.1)) #1 SMP PREEMPT_RT Fri Mar 13 17:25:51 CET 2020
>>>>>> [ 0.000000] 000: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
>>>>>> [ 0.000000] 000: CPU: div instructions available: patching division code
>>>>>> [ 0.000000] 000: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
>>>>>> t[ 0.000000] 000: Memory policy: Data cache writealloc
>>>>>> [ 0.000000] 000: cma: Reserved 64 MiB at 0xfa000000
>>>>>> [ 0.000000] 000: psci: probing for conduit method from DT.
>>>>>> [ 0.000000] 000: psci: PSCIv1.0 detected in firmware.
>>>>>> [ 0.000000] 000: psci: Using standard PSCI v0.2 function IDs
>>>>>> [ 0.000000] 000: psci: MIGRATE_INFO_TYPE not supported.
>>>>>> [ 0.000000] 000: psci: SMC Calling Convention v1.0
>>>>>> [ 0.000000] 000: percpu: Embedded 9 pages/cpu s15008 r0 d21856 u36864
>>>>>> [ 0.000000] 000: Built 1 zonelists, mobility grouping on. Total pages: 522751
>>>>>> [ 0.000000] 000: Kernel command line: console=ttymxc5,115200n8 ip=::::gdm:eth0:off root=PARTUUID=37199a57-ec72-41f9-ab27-445329d1bd77 rootwait
>>>>>> [ 0.000000] 000: Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
>>>>>> [ 0.000000] 000: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
>>>>>> [ 0.000000] 000: mem auto-init: stack:off, heap alloc:off, heap free:off
>>>>>> [ 0.000000] 000: Memory: 1997464K/2097148K available (9216K kernel code, 430K rwdata, 3100K rodata, 1024K init, 733K bss, 34148K reserved, 65536K cma-reserved, 1244448K highmem)
>>>>>> [ 0.000000] 000: SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
>>>>>> [ 0.000000] 000: rcu: Preemptible hierarchical RCU implementation.
>>>>>> [ 0.000000] 000: rcu: RCU priority boosting: priority 1 delay 500 ms.
>>>>>> [ 0.000000] 000: rcu: RCU_SOFTIRQ processing moved to rcuc kthreads.
>>>>>> [ 0.000000] 000: No expedited grace period (rcu_normal_after_boot).
>>>>>> [ 0.000000] 000: Tasks RCU enabled.
>>>>>> [ 0.000000] 000: rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
>>>>>> [ 0.000000] 000: NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
>>>>>> [ 0.000000] 000: rcu: Offload RCU callbacks from CPUs: (none).
>>>>>> [ 0.000000] 000: arch_timer: cp15 timer(s) running at 8.00MHz (virt).
>>>>>> [ 0.000000] 000: clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 440795202120 ns
>>>>>> [ 0.000001] 000: sched_clock: 56 bits at 8MHz, resolution 125ns, wraps every 2199023255500ns
>>>>>> [ 0.000013] 000: Switching to timer-based delay loop, resolution 125ns
>>>>>> [ 0.000426] 000: Switching to timer-based delay loop, resolution 41ns
>>>>>> [ 0.000438] 000: sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
>>>>>> [ 0.000450] 000: clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
>>>>>> [ 0.001597] 000: Console: colour dummy device 80x30
>>>>>> [ 0.001642] 000: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000)
>>>>>> [ 0.001650] 000: pid_max: default: 32768 minimum: 301
>>>>>> [ 0.001788] 000: Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>>>>> [ 0.001807] 000: Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
>>>>>> [ 0.002631] 000: CPU: Testing write buffer coherency: ok
>>>>>> [ 0.059991] 000: Setting up static identity map for 0x80100000 - 0x80100060
>>>>>> [ 0.079972] 000: rcu: Hierarchical SRCU implementation.
>>>>>> [ 0.160105] 000: smp: Bringing up secondary CPUs ...
>>>>>> [ 0.280687] 000: smp: Brought up 1 node, 2 CPUs
>>>>>> [ 0.280697] 000: SMP: Total of 2 processors activated (96.00 BogoMIPS).
>>>>>> [ 0.280705] 000: CPU: All CPU(s) started in SVC mode.
>>>>>> [ 0.281170] 000: devtmpfs: initialized
>>>>>> [ 0.290961] 000: random: get_random_u32 called from bucket_table_alloc+0x58/0x14c with crng_init=0
>>>>>>
>>>>>>
>>>>>> giorgio
>>>>>>
>>>>>> _______________________________________________
>>>>>> barebox mailing list
>>>>>> barebox@lists.infradead.org
>>>>>> http://lists.infradead.org/mailman/listinfo/barebox
>>>>>>
>>>>>
>>>>
>>>
>>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-03 13:47 ` Giorgio
@ 2020-04-06 6:16 ` Ahmad Fatoum
2020-04-06 6:29 ` Ahmad Fatoum
2020-04-06 15:15 ` Giorgio
0 siblings, 2 replies; 18+ messages in thread
From: Ahmad Fatoum @ 2020-04-06 6:16 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hello Giorgio,
On 4/3/20 3:47 PM, Giorgio wrote:
> Hi Ahmad,
>
> thank you for the detailed explanations, I'll have a look
> at the armv7 ref. manual for more background.
>
> I wanted just to note, the problem is specifically linked
> to enabling the MMU:
>
> in arch/arm/cpu/cache-armv7.S:
>
>
> orrne r0, r0, #1 @ MMU enabled
> ...
> mcr p15, 0, r0, c1, c0, 0 @ load control register
>
> without the 'orrne ...' the imx7 does not hang.
I can't reproduce this exact problem. My setup:
- i.MX7D sabresd board,
- imx_v7_defconfig
- check out of upstream/next, commit 5931fe40 ("Merge branch 'for-next/zii' into next")
- revert of commit 8b2104d ("driver: Call of_clk_set_defaults for each probed device")
- nv bootm.secure_state=nonsecure
With this, I didn't observe any barebox hangs[1] while preparing a Linux net boot.
What's your setup?
[1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
"unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-06 6:16 ` Ahmad Fatoum
@ 2020-04-06 6:29 ` Ahmad Fatoum
2020-04-06 15:15 ` Giorgio
1 sibling, 0 replies; 18+ messages in thread
From: Ahmad Fatoum @ 2020-04-06 6:29 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hi,
On 4/6/20 8:16 AM, Ahmad Fatoum wrote:
> [1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
> "unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
Turning off ARM_PSCI_CPUIDLE did the trick. Seems barebox PSCI implementation can't
cope with this yet. Kernel log still says /cpus/cpu@0: unsupported enable-method property: psci
but powering up the second CPU worked. Boots to shell now.
Cheers
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-06 6:16 ` Ahmad Fatoum
2020-04-06 6:29 ` Ahmad Fatoum
@ 2020-04-06 15:15 ` Giorgio
2020-04-06 18:44 ` Ahmad Fatoum
1 sibling, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-04-06 15:15 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi Ahmad,
I've also tried the arm_v7_defconfig + my board specific code but it does not
solve the problem.
The setup I'm using to build barebox just include support for my board; in my
board code, under arch/arm/boards/kontron-samx7, I've nothing special, just
a custom init script in the environment.
To trigger the code that makes barebox hang I use now the command
'smc -n': it calls armv7_secure_monitor_install() and then __mmu_cache_on()
that finally jumps to 'v7_mmu_cache_on'.
Searching in the Armv7-A ref. man. here:
https://static.docs.arm.com/ddi0406/cd/DDI0406C_d_armv7ar_arm.pdf
at B4.1.43 (page B4 - 1554) I found that the reset value of this cp15 reg.
is UNKNOWN and I can also verify this. Moreover the reg. must also be
banked: there is a copy in secure mode and one in nonsecure mode.
My test consists in reading the register just before and just after
the call to arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res):
static u32 read_dacr(void)
{
unsigned int reg;
asm volatile ("mrc p15, 0, %0, c3, c0, 0\n" : "=r"(reg));
return reg;
}
...
int __armv7_secure_monitor_install(void)
{
...
printf("%s: 1) dacr: 0x%08x\n",__func__,read_dacr());
/* Initialize the secure monitor */
arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res);
/* We're in nonsecure mode now */
printf("%s: 2) dacr: 0x%08x\n",__func__,read_dacr());
return 0;
}
and here is what I get:
samx7: / smc -n
__armv7_secure_monitor_install: 1) dacr: 0x00000001
__armv7_secure_monitor_install: 2) dacr: 0xdbf7afaa
If I write a 0x1 or a 0x3 to DACR just before enabling the MMU in
nonsecure mode then barebox does not hang.
giorgio
On 2020-04-06 08:16, Ahmad Fatoum wrote:
> Hello Giorgio,
>
> On 4/3/20 3:47 PM, Giorgio wrote:
>> Hi Ahmad,
>>
>> thank you for the detailed explanations, I'll have a look
>> at the armv7 ref. manual for more background.
>>
>> I wanted just to note, the problem is specifically linked
>> to enabling the MMU:
>>
>> in arch/arm/cpu/cache-armv7.S:
>>
>>
>> orrne r0, r0, #1 @ MMU enabled
>> ...
>> mcr p15, 0, r0, c1, c0, 0 @ load control register
>>
>> without the 'orrne ...' the imx7 does not hang.
>
> I can't reproduce this exact problem. My setup:
>
> - i.MX7D sabresd board,
> - imx_v7_defconfig
> - check out of upstream/next, commit 5931fe40 ("Merge branch 'for-next/zii' into next")
> - revert of commit 8b2104d ("driver: Call of_clk_set_defaults for each probed device")
> - nv bootm.secure_state=nonsecure
>
> With this, I didn't observe any barebox hangs[1] while preparing a Linux net boot.
> What's your setup?
>
> [1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
> "unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-06 15:15 ` Giorgio
@ 2020-04-06 18:44 ` Ahmad Fatoum
2020-04-07 7:46 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-04-06 18:44 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hello Giorgio,
On 4/6/20 5:15 PM, Giorgio wrote:
> Searching in the Armv7-A ref. man. here:
>
> https://static.docs.arm.com/ddi0406/cd/DDI0406C_d_armv7ar_arm.pdf
>
> at B4.1.43 (page B4 - 1554) I found that the reset value of this cp15 reg.
> is UNKNOWN and I can also verify this. Moreover the reg. must also be
> banked: there is a copy in secure mode and one in nonsecure mode.
> My test consists in reading the register just before and just after
> the call to arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res):
>
> static u32 read_dacr(void)
> {
> unsigned int reg;
>
> asm volatile ("mrc p15, 0, %0, c3, c0, 0\n" : "=r"(reg));
> return reg;
> }
>
> ...
>
> int __armv7_secure_monitor_install(void)
> {
> ...
> printf("%s: 1) dacr: 0x%08x\n",__func__,read_dacr());
>
> /* Initialize the secure monitor */
> arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res);
>
> /* We're in nonsecure mode now */
>
> printf("%s: 2) dacr: 0x%08x\n",__func__,read_dacr());
>
> return 0;
> }
>
> and here is what I get:
>
> samx7: / smc -n
> __armv7_secure_monitor_install: 1) dacr: 0x00000001
> __armv7_secure_monitor_install: 2) dacr: 0xdbf7afaa
>
> If I write a 0x1 or a 0x3 to DACR just before enabling the MMU in
> nonsecure mode then barebox does not hang.
Oh! seems i have been lucky so far:
__armv7_secure_monitor_install: 1) dacr: 0x00000001
__armv7_secure_monitor_install: 2) dacr: 0xa133ad17
Yes, we will want to call set_domain(DOMAIN_CLIENT)
somewhere, maybe just before set_ttbr?
Do you want to send a patch?
(Your other i.MX7 patches are welcome as well :-)
Cheers and thanks for debugging this
Ahmad
>
> giorgio
>
> On 2020-04-06 08:16, Ahmad Fatoum wrote:
>> Hello Giorgio,
>>
>> On 4/3/20 3:47 PM, Giorgio wrote:
>>> Hi Ahmad,
>>>
>>> thank you for the detailed explanations, I'll have a look
>>> at the armv7 ref. manual for more background.
>>>
>>> I wanted just to note, the problem is specifically linked
>>> to enabling the MMU:
>>>
>>> in arch/arm/cpu/cache-armv7.S:
>>>
>>>
>>> orrne r0, r0, #1 @ MMU enabled
>>> ...
>>> mcr p15, 0, r0, c1, c0, 0 @ load control register
>>>
>>> without the 'orrne ...' the imx7 does not hang.
>>
>> I can't reproduce this exact problem. My setup:
>>
>> - i.MX7D sabresd board,
>> - imx_v7_defconfig
>> - check out of upstream/next, commit 5931fe40 ("Merge branch 'for-next/zii' into next")
>> - revert of commit 8b2104d ("driver: Call of_clk_set_defaults for each probed device")
>> - nv bootm.secure_state=nonsecure
>>
>> With this, I didn't observe any barebox hangs[1] while preparing a Linux net boot.
>> What's your setup?
>>
>> [1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
>> "unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-06 18:44 ` Ahmad Fatoum
@ 2020-04-07 7:46 ` Giorgio
2020-04-07 8:23 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-04-07 7:46 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi,
OK, my current fix follows also the same logic as for the values
of 'vbar' and 'ttb' in armv7_secure_monitor_install(). I've also
found the 'set_domain(v)' in mmu.h, don't need to write a new one.
I'll send a patch for this.
What do you mean with the 'other i.MX7 patches' ?
I've also noticed that some asm() statements in sm.c lack the 'volatile'
attribute.
giorgio
On 4/6/20 8:44 PM, Ahmad Fatoum wrote:
> Hello Giorgio,
>
> On 4/6/20 5:15 PM, Giorgio wrote:
>> Searching in the Armv7-A ref. man. here:
>>
>> https://static.docs.arm.com/ddi0406/cd/DDI0406C_d_armv7ar_arm.pdf
>>
>> at B4.1.43 (page B4 - 1554) I found that the reset value of this cp15 reg.
>> is UNKNOWN and I can also verify this. Moreover the reg. must also be
>> banked: there is a copy in secure mode and one in nonsecure mode.
>> My test consists in reading the register just before and just after
>> the call to arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res):
>>
>> static u32 read_dacr(void)
>> {
>> unsigned int reg;
>>
>> asm volatile ("mrc p15, 0, %0, c3, c0, 0\n" : "=r"(reg));
>> return reg;
>> }
>>
>> ...
>>
>> int __armv7_secure_monitor_install(void)
>> {
>> ...
>> printf("%s: 1) dacr: 0x%08x\n",__func__,read_dacr());
>>
>> /* Initialize the secure monitor */
>> arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res);
>>
>> /* We're in nonsecure mode now */
>>
>> printf("%s: 2) dacr: 0x%08x\n",__func__,read_dacr());
>>
>> return 0;
>> }
>>
>> and here is what I get:
>>
>> samx7: / smc -n
>> __armv7_secure_monitor_install: 1) dacr: 0x00000001
>> __armv7_secure_monitor_install: 2) dacr: 0xdbf7afaa
>>
>> If I write a 0x1 or a 0x3 to DACR just before enabling the MMU in
>> nonsecure mode then barebox does not hang.
>
> Oh! seems i have been lucky so far:
>
> __armv7_secure_monitor_install: 1) dacr: 0x00000001
> __armv7_secure_monitor_install: 2) dacr: 0xa133ad17
>
> Yes, we will want to call set_domain(DOMAIN_CLIENT)
> somewhere, maybe just before set_ttbr?
>
> Do you want to send a patch?
> (Your other i.MX7 patches are welcome as well :-)
>
> Cheers and thanks for debugging this
> Ahmad
>
>>
>> giorgio
>>
>> On 2020-04-06 08:16, Ahmad Fatoum wrote:
>>> Hello Giorgio,
>>>
>>> On 4/3/20 3:47 PM, Giorgio wrote:
>>>> Hi Ahmad,
>>>>
>>>> thank you for the detailed explanations, I'll have a look
>>>> at the armv7 ref. manual for more background.
>>>>
>>>> I wanted just to note, the problem is specifically linked
>>>> to enabling the MMU:
>>>>
>>>> in arch/arm/cpu/cache-armv7.S:
>>>>
>>>>
>>>> orrne r0, r0, #1 @ MMU enabled
>>>> ...
>>>> mcr p15, 0, r0, c1, c0, 0 @ load control register
>>>>
>>>> without the 'orrne ...' the imx7 does not hang.
>>>
>>> I can't reproduce this exact problem. My setup:
>>>
>>> - i.MX7D sabresd board,
>>> - imx_v7_defconfig
>>> - check out of upstream/next, commit 5931fe40 ("Merge branch 'for-next/zii' into next")
>>> - revert of commit 8b2104d ("driver: Call of_clk_set_defaults for each probed device")
>>> - nv bootm.secure_state=nonsecure
>>>
>>> With this, I didn't observe any barebox hangs[1] while preparing a Linux net boot.
>>> What's your setup?
>>>
>>> [1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
>>> "unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
>>>
>>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-07 7:46 ` Giorgio
@ 2020-04-07 8:23 ` Ahmad Fatoum
2020-04-07 12:28 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-04-07 8:23 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hello Giorgio,
On 4/7/20 9:46 AM, Giorgio wrote:
> Hi,
>
> OK, my current fix follows also the same logic as for the values
> of 'vbar' and 'ttb' in armv7_secure_monitor_install(). I've also
> found the 'set_domain(v)' in mmu.h, don't need to write a new one.
>
> I'll send a patch for this.
Great. Even better than hardcoding the CLIENT_DOMAIN.
> What do you mean with the 'other i.MX7 patches' ?
Didn't you add support for some i.MX7 spi flash image format?
> I've also noticed that some asm() statements in sm.c lack the 'volatile'
> attribute.
Are they strictly necessary? My understanding is that we need
asm volatile on no output operands, but side effects.
All asm statements in the file either lack side effects
(the reads) or have no output operands (the writes).
That said, I don't mind making them all volatile just
to be a little extra sure..
Cheers,
Ahmad
>
> giorgio
>
> On 4/6/20 8:44 PM, Ahmad Fatoum wrote:
>> Hello Giorgio,
>>
>> On 4/6/20 5:15 PM, Giorgio wrote:
>>> Searching in the Armv7-A ref. man. here:
>>>
>>> https://static.docs.arm.com/ddi0406/cd/DDI0406C_d_armv7ar_arm.pdf
>>>
>>> at B4.1.43 (page B4 - 1554) I found that the reset value of this cp15 reg.
>>> is UNKNOWN and I can also verify this. Moreover the reg. must also be
>>> banked: there is a copy in secure mode and one in nonsecure mode.
>>> My test consists in reading the register just before and just after
>>> the call to arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res):
>>>
>>> static u32 read_dacr(void)
>>> {
>>> unsigned int reg;
>>>
>>> asm volatile ("mrc p15, 0, %0, c3, c0, 0\n" : "=r"(reg));
>>> return reg;
>>> }
>>>
>>> ...
>>>
>>> int __armv7_secure_monitor_install(void)
>>> {
>>> ...
>>> printf("%s: 1) dacr: 0x%08x\n",__func__,read_dacr());
>>>
>>> /* Initialize the secure monitor */
>>> arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res);
>>>
>>> /* We're in nonsecure mode now */
>>>
>>> printf("%s: 2) dacr: 0x%08x\n",__func__,read_dacr());
>>>
>>> return 0;
>>> }
>>>
>>> and here is what I get:
>>>
>>> samx7: / smc -n
>>> __armv7_secure_monitor_install: 1) dacr: 0x00000001
>>> __armv7_secure_monitor_install: 2) dacr: 0xdbf7afaa
>>>
>>> If I write a 0x1 or a 0x3 to DACR just before enabling the MMU in
>>> nonsecure mode then barebox does not hang.
>>
>> Oh! seems i have been lucky so far:
>>
>> __armv7_secure_monitor_install: 1) dacr: 0x00000001
>> __armv7_secure_monitor_install: 2) dacr: 0xa133ad17
>>
>> Yes, we will want to call set_domain(DOMAIN_CLIENT)
>> somewhere, maybe just before set_ttbr?
>>
>> Do you want to send a patch?
>> (Your other i.MX7 patches are welcome as well :-)
>>
>> Cheers and thanks for debugging this
>> Ahmad
>>
>>>
>>> giorgio
>>>
>>> On 2020-04-06 08:16, Ahmad Fatoum wrote:
>>>> Hello Giorgio,
>>>>
>>>> On 4/3/20 3:47 PM, Giorgio wrote:
>>>>> Hi Ahmad,
>>>>>
>>>>> thank you for the detailed explanations, I'll have a look
>>>>> at the armv7 ref. manual for more background.
>>>>>
>>>>> I wanted just to note, the problem is specifically linked
>>>>> to enabling the MMU:
>>>>>
>>>>> in arch/arm/cpu/cache-armv7.S:
>>>>>
>>>>>
>>>>> orrne r0, r0, #1 @ MMU enabled
>>>>> ...
>>>>> mcr p15, 0, r0, c1, c0, 0 @ load control register
>>>>>
>>>>> without the 'orrne ...' the imx7 does not hang.
>>>>
>>>> I can't reproduce this exact problem. My setup:
>>>>
>>>> - i.MX7D sabresd board,
>>>> - imx_v7_defconfig
>>>> - check out of upstream/next, commit 5931fe40 ("Merge branch 'for-next/zii' into next")
>>>> - revert of commit 8b2104d ("driver: Call of_clk_set_defaults for each probed device")
>>>> - nv bootm.secure_state=nonsecure
>>>>
>>>> With this, I didn't observe any barebox hangs[1] while preparing a Linux net boot.
>>>> What's your setup?
>>>>
>>>> [1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
>>>> "unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
>>>>
>>>
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-07 8:23 ` Ahmad Fatoum
@ 2020-04-07 12:28 ` Giorgio
2020-04-07 13:43 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-04-07 12:28 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi,
On 4/7/20 10:23 AM, Ahmad Fatoum wrote:
> Hello Giorgio,
>
> On 4/7/20 9:46 AM, Giorgio wrote:
>> Hi,
>>
>> OK, my current fix follows also the same logic as for the values
>> of 'vbar' and 'ttb' in armv7_secure_monitor_install(). I've also
>> found the 'set_domain(v)' in mmu.h, don't need to write a new one.
>>
>> I'll send a patch for this.
>
> Great. Even better than hardcoding the CLIENT_DOMAIN.
>
OK.
To read the current value of DACR, in secure mode, we need a
get_domain(). I would add it to mmu.h, beside the set_domain().
>> What do you mean with the 'other i.MX7 patches' ?
>
> Didn't you add support for some i.MX7 spi flash image format?
>
That was an evil hack actually, just to verify why the normal barebox image
didn't worked. To really support booting barebox from the qspi flash
I think we need more *structural* changes to the way barebox starts.
For this I need *at least* some suggestions from someone that really knows
in detail how barebox works and how an image is built, like you or Sascha...
Maybe what can be committed is the dts block in imx7s.dtsi for the qspi that
enables using the flash as normal runtime mass storage. This should be not
so dangerous because the qspi becomes only active when its status is also enabled.
>> I've also noticed that some asm() statements in sm.c lack the 'volatile'
>> attribute.
>
> Are they strictly necessary? My understanding is that we need
> asm volatile on no output operands, but side effects.
>
> All asm statements in the file either lack side effects
> (the reads) or have no output operands (the writes).
>
> That said, I don't mind making them all volatile just
> to be a little extra sure..
>
I think for the current code in sm.c we don't strictly need the volatiles,
I noticed problems in debug code like this:
static u32 read_dacr(void)
{
unsigned int reg;
// without volatile:
asm ("mrc p15, 0, %0, c3, c0, 0\n" : "=r"(reg));
return reg;
}
...
printf("%s: 1) dacr: 0x%08x\n", __func__, read_dacr());
/* Initialize the secure monitor */
arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res);
/* We're in nonsecure mode now */
printf("%s: 2) dacr: 0x%08x\n", __func__, read_dacr());
Here the compiler could think he can call read_dacr() only once,
cache the result in a register and use its value two times. I verified
that for the previous debug code the volatile attribute makes a
difference.
giorgio
> Cheers,
> Ahmad
>
>>
>> giorgio
>>
>> On 4/6/20 8:44 PM, Ahmad Fatoum wrote:
>>> Hello Giorgio,
>>>
>>> On 4/6/20 5:15 PM, Giorgio wrote:
>>>> Searching in the Armv7-A ref. man. here:
>>>>
>>>> https://static.docs.arm.com/ddi0406/cd/DDI0406C_d_armv7ar_arm.pdf
>>>>
>>>> at B4.1.43 (page B4 - 1554) I found that the reset value of this cp15 reg.
>>>> is UNKNOWN and I can also verify this. Moreover the reg. must also be
>>>> banked: there is a copy in secure mode and one in nonsecure mode.
>>>> My test consists in reading the register just before and just after
>>>> the call to arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res):
>>>>
>>>> static u32 read_dacr(void)
>>>> {
>>>> unsigned int reg;
>>>>
>>>> asm volatile ("mrc p15, 0, %0, c3, c0, 0\n" : "=r"(reg));
>>>> return reg;
>>>> }
>>>>
>>>> ...
>>>>
>>>> int __armv7_secure_monitor_install(void)
>>>> {
>>>> ...
>>>> printf("%s: 1) dacr: 0x%08x\n",__func__,read_dacr());
>>>>
>>>> /* Initialize the secure monitor */
>>>> arm_smccc_smc(0, 0, 0, 0, 0, 0, 0, 0, &res);
>>>>
>>>> /* We're in nonsecure mode now */
>>>>
>>>> printf("%s: 2) dacr: 0x%08x\n",__func__,read_dacr());
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> and here is what I get:
>>>>
>>>> samx7: / smc -n
>>>> __armv7_secure_monitor_install: 1) dacr: 0x00000001
>>>> __armv7_secure_monitor_install: 2) dacr: 0xdbf7afaa
>>>>
>>>> If I write a 0x1 or a 0x3 to DACR just before enabling the MMU in
>>>> nonsecure mode then barebox does not hang.
>>>
>>> Oh! seems i have been lucky so far:
>>>
>>> __armv7_secure_monitor_install: 1) dacr: 0x00000001
>>> __armv7_secure_monitor_install: 2) dacr: 0xa133ad17
>>>
>>> Yes, we will want to call set_domain(DOMAIN_CLIENT)
>>> somewhere, maybe just before set_ttbr?
>>>
>>> Do you want to send a patch?
>>> (Your other i.MX7 patches are welcome as well :-)
>>>
>>> Cheers and thanks for debugging this
>>> Ahmad
>>>
>>>>
>>>> giorgio
>>>>
>>>> On 2020-04-06 08:16, Ahmad Fatoum wrote:
>>>>> Hello Giorgio,
>>>>>
>>>>> On 4/3/20 3:47 PM, Giorgio wrote:
>>>>>> Hi Ahmad,
>>>>>>
>>>>>> thank you for the detailed explanations, I'll have a look
>>>>>> at the armv7 ref. manual for more background.
>>>>>>
>>>>>> I wanted just to note, the problem is specifically linked
>>>>>> to enabling the MMU:
>>>>>>
>>>>>> in arch/arm/cpu/cache-armv7.S:
>>>>>>
>>>>>>
>>>>>> orrne r0, r0, #1 @ MMU enabled
>>>>>> ...
>>>>>> mcr p15, 0, r0, c1, c0, 0 @ load control register
>>>>>>
>>>>>> without the 'orrne ...' the imx7 does not hang.
>>>>>
>>>>> I can't reproduce this exact problem. My setup:
>>>>>
>>>>> - i.MX7D sabresd board,
>>>>> - imx_v7_defconfig
>>>>> - check out of upstream/next, commit 5931fe40 ("Merge branch 'for-next/zii' into next")
>>>>> - revert of commit 8b2104d ("driver: Call of_clk_set_defaults for each probed device")
>>>>> - nv bootm.secure_state=nonsecure
>>>>>
>>>>> With this, I didn't observe any barebox hangs[1] while preparing a Linux net boot.
>>>>> What's your setup?
>>>>>
>>>>> [1]: Linux still hangs due to what I assume to be a psci issue, kernel log says
>>>>> "unsupported enable-method property: psci" before getting stuck durcing SDHCI probe
>>>>>
>>>>
>>>
>>
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-07 12:28 ` Giorgio
@ 2020-04-07 13:43 ` Ahmad Fatoum
2020-04-13 22:30 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-04-07 13:43 UTC (permalink / raw)
To: Giorgio; +Cc: barebox
Hello,
On 4/7/20 2:28 PM, Giorgio wrote:
>> Great. Even better than hardcoding the CLIENT_DOMAIN.
>>
> OK.
>
> To read the current value of DACR, in secure mode, we need a
> get_domain(). I would add it to mmu.h, beside the set_domain().
sounds good.
>>> What do you mean with the 'other i.MX7 patches' ?
>>
>> Didn't you add support for some i.MX7 spi flash image format?
>>
>
> That was an evil hack actually, just to verify why the normal barebox image
> didn't worked. To really support booting barebox from the qspi flash
> I think we need more *structural* changes to the way barebox starts.
> For this I need *at least* some suggestions from someone that really knows
> in detail how barebox works and how an image is built, like you or Sascha...
scripts/imx/imx-image.c is what's building the i.MX images. It receives
the imxcfg specific to a board as argument. If you have extra configuration
for the QSPI, you'll probably need to extend that, either with a new option
or maybe by adding new directives to the existing imxcfg format.
What other changes do you think will be necessary?
> Maybe what can be committed is the dts block in imx7s.dtsi for the qspi that
> enables using the flash as normal runtime mass storage. This should be not
> so dangerous because the qspi becomes only active when its status is also enabled.
Funny that no one so far has been bothered to add it upstream ^^.
You can add it to barebox arch/arm/dts/imx7s.dtsi, but as you might want to access
it from Linux as well, you should consider posting a patch to add the qspi
node to the upstream imx7s.dtsi.
Shortly after landing in a Linux -rc, Sascha will import it along with other
changes to barebox dts/ and we can drop the node then from arch/arm/dts again.
>>> I've also noticed that some asm() statements in sm.c lack the 'volatile'
>>> attribute.
>>
>> Are they strictly necessary? My understanding is that we need
>> asm volatile on no output operands, but side effects.
> I think for the current code in sm.c we don't strictly need the volatiles,
> I noticed problems in debug code like this:
> Here the compiler could think he can call read_dacr() only once,
> cache the result in a register and use its value two times. I verified
> that for the previous debug code the volatile attribute makes a
> difference.
Interesting. As arm_smccc_smc expands to an external function and barebox
does no Link-Time Optimization, I'd have though arm_smccc_smc to be a barrier
and everything would be reloaded afterwards.
That it's not, sounds quite broken..
Cheers
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-07 13:43 ` Ahmad Fatoum
@ 2020-04-13 22:30 ` Giorgio
2020-04-14 7:59 ` Sascha Hauer
0 siblings, 1 reply; 18+ messages in thread
From: Giorgio @ 2020-04-13 22:30 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox
Hi Ahmad,
On 4/7/20 3:43 PM, Ahmad Fatoum wrote:
> Hello,
>
> On 4/7/20 2:28 PM, Giorgio wrote:
>>> Great. Even better than hardcoding the CLIENT_DOMAIN.
>>>
>> OK.
>>
>> To read the current value of DACR, in secure mode, we need a
>> get_domain(). I would add it to mmu.h, beside the set_domain().
>
> sounds good.
>
>>>> What do you mean with the 'other i.MX7 patches' ?
>>>
>>> Didn't you add support for some i.MX7 spi flash image format?
>>>
>>
>> That was an evil hack actually, just to verify why the normal barebox image
>> didn't worked. To really support booting barebox from the qspi flash
>> I think we need more *structural* changes to the way barebox starts.
>> For this I need *at least* some suggestions from someone that really knows
>> in detail how barebox works and how an image is built, like you or Sascha...
>
> scripts/imx/imx-image.c is what's building the i.MX images. It receives
> the imxcfg specific to a board as argument. If you have extra configuration
> for the QSPI, you'll probably need to extend that, either with a new option
> or maybe by adding new directives to the existing imxcfg format.
>
thank you for the suggestions, I already knew about the imx-image tool even
if not in detail; to add support for the QSPI boot we must for sure extend
the code there somehow.
> What other changes do you think will be necessary?
>
I have currently have a qspi-patched barebox image on my QSPI flash that the imx7d
is able to boot, but only due to an evil hack I only made to see if it was
the last problem I had.
According to the imx7d ref. manual (Rev. 1, 01/2018), at page 1233, the boot ROM
reads out the content of the QSPI flash and expects, at offset 0x00 (watch out here,
the ref. manual says actually offset 0x400 but it's an error), the QuadSPI Configuration
Parameters, a 512 bytes long binary table with HW parameters describing the flash.
Without this table the soc won't boot.
The problem is here that barebox already uses this offset range with other informations,
in particular the first 32bits (at offset 0x00) contain the asm opcode of a branch:
without this branch barebox will not boot up and this is my 'most evil hack': I let the
regular 'make' generate its barebox image, then replace the first 512 bytes with my
QuadSPI Configuration Parameters and then replace the first 32bits with the original branch
opcode.
Here the command lines I'm using:
make -j O=/tmp/bbuild/samx7 kontron-samx7_defconfig && make -j O=/tmp/bbuild/samx7
( dd if=/tmp/bbuild/samx7/barebox-flash-image bs=1 count=4 && dd if=arch/arm/boards/kontron-samx7/qspi_flash_header.bin bs=1 count=1020 skip=4 && dd if=/tmp/bbuild/samx7/barebox-flash-image bs=1 skip=1k ) > /tmp/bbuild/samx7/barebox-qspi-image
This hack only works because the 32bits I overwrite are not so important, as it seems.
Maybe you can say if it's possible, in case of a QSPI barebox image, to avoid the need
for the branch opcode at offset 0x00.
>> Maybe what can be committed is the dts block in imx7s.dtsi for the qspi that
>> enables using the flash as normal runtime mass storage. This should be not
>> so dangerous because the qspi becomes only active when its status is also enabled.
>
> Funny that no one so far has been bothered to add it upstream ^^.
> You can add it to barebox arch/arm/dts/imx7s.dtsi, but as you might want to access
> it from Linux as well, you should consider posting a patch to add the qspi
> node to the upstream imx7s.dtsi.
> Shortly after landing in a Linux -rc, Sascha will import it along with other
> changes to barebox dts/ and we can drop the node then from arch/arm/dts again.
>
yes, you are right here, I'll see if I find the proper mailing list for a patch.
>>>> I've also noticed that some asm() statements in sm.c lack the 'volatile'
>>>> attribute.
>>>
>>> Are they strictly necessary? My understanding is that we need
>>> asm volatile on no output operands, but side effects.
>
>> I think for the current code in sm.c we don't strictly need the volatiles,
>> I noticed problems in debug code like this:
>
>> Here the compiler could think he can call read_dacr() only once,
>> cache the result in a register and use its value two times. I verified
>> that for the previous debug code the volatile attribute makes a
>> difference.
>
> Interesting. As arm_smccc_smc expands to an external function and barebox
> does no Link-Time Optimization, I'd have though arm_smccc_smc to be a barrier
> and everything would be reloaded afterwards.
>
> That it's not, sounds quite broken..
>
> Cheers
> Ahmad
>
best regards,
giorgio
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-13 22:30 ` Giorgio
@ 2020-04-14 7:59 ` Sascha Hauer
2020-04-14 13:05 ` Giorgio
0 siblings, 1 reply; 18+ messages in thread
From: Sascha Hauer @ 2020-04-14 7:59 UTC (permalink / raw)
To: Giorgio; +Cc: barebox, Ahmad Fatoum
On Tue, Apr 14, 2020 at 12:30:40AM +0200, Giorgio wrote:
> Hi Ahmad,
>
> On 4/7/20 3:43 PM, Ahmad Fatoum wrote:
> > Hello,
> >
> > On 4/7/20 2:28 PM, Giorgio wrote:
> >>> Great. Even better than hardcoding the CLIENT_DOMAIN.
> >>>
> >> OK.
> >>
> >> To read the current value of DACR, in secure mode, we need a
> >> get_domain(). I would add it to mmu.h, beside the set_domain().
> >
> > sounds good.
> >
> >>>> What do you mean with the 'other i.MX7 patches' ?
> >>>
> >>> Didn't you add support for some i.MX7 spi flash image format?
> >>>
> >>
> >> That was an evil hack actually, just to verify why the normal barebox image
> >> didn't worked. To really support booting barebox from the qspi flash
> >> I think we need more *structural* changes to the way barebox starts.
> >> For this I need *at least* some suggestions from someone that really knows
> >> in detail how barebox works and how an image is built, like you or Sascha...
> >
> > scripts/imx/imx-image.c is what's building the i.MX images. It receives
> > the imxcfg specific to a board as argument. If you have extra configuration
> > for the QSPI, you'll probably need to extend that, either with a new option
> > or maybe by adding new directives to the existing imxcfg format.
> >
>
> thank you for the suggestions, I already knew about the imx-image tool even
> if not in detail; to add support for the QSPI boot we must for sure extend
> the code there somehow.
>
> > What other changes do you think will be necessary?
> >
> I have currently have a qspi-patched barebox image on my QSPI flash that the imx7d
> is able to boot, but only due to an evil hack I only made to see if it was
> the last problem I had.
> According to the imx7d ref. manual (Rev. 1, 01/2018), at page 1233, the boot ROM
> reads out the content of the QSPI flash and expects, at offset 0x00 (watch out here,
> the ref. manual says actually offset 0x400 but it's an error), the QuadSPI Configuration
> Parameters, a 512 bytes long binary table with HW parameters describing the flash.
> Without this table the soc won't boot.
> The problem is here that barebox already uses this offset range with other informations,
> in particular the first 32bits (at offset 0x00) contain the asm opcode of a branch:
This branch shouldn't be necessary to boot from ROM. Normally we set the
entry point of the image to the image start + 0x1000 which is the
address of the first instruction of the binary.
The branch instruction at offset 0x0 in the image is only meant for
starting the image second stage: You can jump directly to the start of
the image without caring where the real start is.
I don't know why the instruction at 0x0 is necessary in your case. I
also don't know how booting with QSPI works. Other boot devices are
actively read from by the CPU, the QSPI controller probably has a
feature to map QSPI NOR contents into the physical address space of the
CPU. Maybe the ROM uses this feature and maybe this causes differences
to the boot flow from other devices.
What have you specified as loadaddr and dcdofs in you flash header
configuration file?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: imx7d dual core boot
2020-04-14 7:59 ` Sascha Hauer
@ 2020-04-14 13:05 ` Giorgio
0 siblings, 0 replies; 18+ messages in thread
From: Giorgio @ 2020-04-14 13:05 UTC (permalink / raw)
To: Sascha Hauer; +Cc: barebox, Ahmad Fatoum
Hi Sascha,
thank you for your help, your last suggestion was the last missing
bit in my qspi setup.
I had the following wrong parameter in my flash header file:
loadaddr 0x80000000
following your hint I changed it to:
loadaddr 0x80001000
and now I don't need my evil hack with the branch opcode anymore,
I just replace the first 512 bytes with the QuadSPI Configuration Parameters
and the resulting modified image just works.
If you are interested I can have a look at the imx-image tool to see how this last
special step could also be properly implemented, as Ahmad suggested.
giorgio
On 2020-04-14 09:59, Sascha Hauer wrote:
> On Tue, Apr 14, 2020 at 12:30:40AM +0200, Giorgio wrote:
>> Hi Ahmad,
>>
>> On 4/7/20 3:43 PM, Ahmad Fatoum wrote:
>>> Hello,
>>>
>>> On 4/7/20 2:28 PM, Giorgio wrote:
>>>>> Great. Even better than hardcoding the CLIENT_DOMAIN.
>>>>>
>>>> OK.
>>>>
>>>> To read the current value of DACR, in secure mode, we need a
>>>> get_domain(). I would add it to mmu.h, beside the set_domain().
>>>
>>> sounds good.
>>>
>>>>>> What do you mean with the 'other i.MX7 patches' ?
>>>>>
>>>>> Didn't you add support for some i.MX7 spi flash image format?
>>>>>
>>>>
>>>> That was an evil hack actually, just to verify why the normal barebox image
>>>> didn't worked. To really support booting barebox from the qspi flash
>>>> I think we need more *structural* changes to the way barebox starts.
>>>> For this I need *at least* some suggestions from someone that really knows
>>>> in detail how barebox works and how an image is built, like you or Sascha...
>>>
>>> scripts/imx/imx-image.c is what's building the i.MX images. It receives
>>> the imxcfg specific to a board as argument. If you have extra configuration
>>> for the QSPI, you'll probably need to extend that, either with a new option
>>> or maybe by adding new directives to the existing imxcfg format.
>>>
>>
>> thank you for the suggestions, I already knew about the imx-image tool even
>> if not in detail; to add support for the QSPI boot we must for sure extend
>> the code there somehow.
>>
>>> What other changes do you think will be necessary?
>>>
>> I have currently have a qspi-patched barebox image on my QSPI flash that the imx7d
>> is able to boot, but only due to an evil hack I only made to see if it was
>> the last problem I had.
>> According to the imx7d ref. manual (Rev. 1, 01/2018), at page 1233, the boot ROM
>> reads out the content of the QSPI flash and expects, at offset 0x00 (watch out here,
>> the ref. manual says actually offset 0x400 but it's an error), the QuadSPI Configuration
>> Parameters, a 512 bytes long binary table with HW parameters describing the flash.
>> Without this table the soc won't boot.
>> The problem is here that barebox already uses this offset range with other informations,
>> in particular the first 32bits (at offset 0x00) contain the asm opcode of a branch:
>
> This branch shouldn't be necessary to boot from ROM. Normally we set the
> entry point of the image to the image start + 0x1000 which is the
> address of the first instruction of the binary.
>
> The branch instruction at offset 0x0 in the image is only meant for
> starting the image second stage: You can jump directly to the start of
> the image without caring where the real start is.
>
> I don't know why the instruction at 0x0 is necessary in your case. I
> also don't know how booting with QSPI works. Other boot devices are
> actively read from by the CPU, the QSPI controller probably has a
> feature to map QSPI NOR contents into the physical address space of the
> CPU. Maybe the ROM uses this feature and maybe this causes differences
> to the boot flow from other devices.
>
> What have you specified as loadaddr and dcdofs in you flash header
> configuration file?
>
> Sascha
>
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-04-14 13:05 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-26 10:21 imx7d dual core boot Giorgio
2020-03-27 5:56 ` Ahmad Fatoum
2020-03-27 8:27 ` Giorgio
2020-03-27 10:01 ` Ahmad Fatoum
2020-03-30 14:33 ` Giorgio
2020-04-03 13:01 ` Ahmad Fatoum
2020-04-03 13:47 ` Giorgio
2020-04-06 6:16 ` Ahmad Fatoum
2020-04-06 6:29 ` Ahmad Fatoum
2020-04-06 15:15 ` Giorgio
2020-04-06 18:44 ` Ahmad Fatoum
2020-04-07 7:46 ` Giorgio
2020-04-07 8:23 ` Ahmad Fatoum
2020-04-07 12:28 ` Giorgio
2020-04-07 13:43 ` Ahmad Fatoum
2020-04-13 22:30 ` Giorgio
2020-04-14 7:59 ` Sascha Hauer
2020-04-14 13:05 ` Giorgio
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox