Kernel v5.2+ on HiKey960?

Kernel v5.2+ on HiKey960?

[Jerome Forissier]

Hi,

Has anyone successfully run kernel v5.2 or later on a HiKey960 board?

For some reason, anything past v5.1 doesn't work for me and I could not
figure out why. The symptom is it never gets to the login prompt. The
root FS is a Buildroot-generated one, and prior to reaching the kernel
the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.

I tried replacing /init with a shell, in which case I can type a command
but whatever it is (even a simple "ls"), the command hangs on exit and I
never get back to the prompt.

Then I started bisecting, that was quite painful but I found several
problematic commits. I ended up reverting the following (in this order)
to be able to boot v5.4:

1. "arm64: vdso: Substitute gettimeofday() with C implementation"
2. "arm64: vdso: Explicitly add build-id option"
3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
    held"
4. "arm64: vdso: Remove stale files from old assembly implementation"

So the main thing appears to be the VDSO stuff, but if I do not also
revert the arch_timer commit I get a kernel panic:

[    4.657118] Run /init as init process
[    4.662380] Kernel panic - not syncing: Attempted to kill init!
               exitcode=0x00000004
[    4.670035] CPU: 7 PID: 1 Comm: init Not tainted 5.4.0-00003-
               g223b12c033fb #258
[    4.677338] Hardware name: HiKey960 (DT)
[    4.681253] Call trace:
[    4.683700]  dump_backtrace+0x0/0x148
[    4.687355]  show_stack+0x24/0x30
[    4.690664]  dump_stack+0xbc/0x100
[    4.694058]  panic+0x168/0x368
[    4.697105]  do_exit+0xa10/0xa28
[    4.700323]  do_group_exit+0x48/0xa8
[    4.703892]  get_signal+0xec/0x848
[    4.707287]  do_notify_resume+0x21c/0x480
[    4.711290]  work_pending+0x8/0x10
[    4.714689] SMP: stopping secondary CPUs
[    4.718607] Kernel Offset: disabled
[    4.722089] CPU features: 0x0002,21082004
[    4.726090] Memory Limit: none
[    4.729145] ---[ end Kernel panic - not syncing: Attempted to kill
               init! exitcode=0x00000004 ]---

Any idea what could be wrong with my setup?

Thanks,
-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Marc Zyngier]

Hi Jerome,

Adding Vincenzo (who was the last one to mess with the VDSO).

On 2019-12-03 15:43, Jerome Forissier wrote:
> Hi,
>
> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>
> For some reason, anything past v5.1 doesn't work for me and I could 
> not
> figure out why. The symptom is it never gets to the login prompt. The
> root FS is a Buildroot-generated one, and prior to reaching the 
> kernel
> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>
> I tried replacing /init with a shell, in which case I can type a 
> command
> but whatever it is (even a simple "ls"), the command hangs on exit 
> and I
> never get back to the prompt.
>
> Then I started bisecting, that was quite painful but I found several
> problematic commits. I ended up reverting the following (in this 
> order)
> to be able to boot v5.4:
>
> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
> 2. "arm64: vdso: Explicitly add build-id option"
> 3. "arm64: arch_timer: Ensure counter register reads occur with 
> seqlock
>     held"
> 4. "arm64: vdso: Remove stale files from old assembly implementation"
>
> So the main thing appears to be the VDSO stuff, but if I do not also
> revert the arch_timer commit I get a kernel panic:
>
> [    4.657118] Run /init as init process
> [    4.662380] Kernel panic - not syncing: Attempted to kill init!
>                exitcode=0x00000004
> [    4.670035] CPU: 7 PID: 1 Comm: init Not tainted 5.4.0-00003-
>                g223b12c033fb #258
> [    4.677338] Hardware name: HiKey960 (DT)
> [    4.681253] Call trace:
> [    4.683700]  dump_backtrace+0x0/0x148
> [    4.687355]  show_stack+0x24/0x30
> [    4.690664]  dump_stack+0xbc/0x100
> [    4.694058]  panic+0x168/0x368
> [    4.697105]  do_exit+0xa10/0xa28
> [    4.700323]  do_group_exit+0x48/0xa8
> [    4.703892]  get_signal+0xec/0x848
> [    4.707287]  do_notify_resume+0x21c/0x480
> [    4.711290]  work_pending+0x8/0x10
> [    4.714689] SMP: stopping secondary CPUs
> [    4.718607] Kernel Offset: disabled
> [    4.722089] CPU features: 0x0002,21082004
> [    4.726090] Memory Limit: none
> [    4.729145] ---[ end Kernel panic - not syncing: Attempted to kill
>                init! exitcode=0x00000004 ]---
>
> Any idea what could be wrong with my setup?

Posting the relevant sections of your kernel messages would be a good 
start.

The reversal of the timer patch seems like a red herring, but Vincenzo
should be able to help you there.

Thanks,

         M.
-- 
Who you jivin' with that Cosmik Debris?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

Hi Marc,

On 12/3/19 6:47 PM, Marc Zyngier wrote:
> Hi Jerome,
> 
> Adding Vincenzo (who was the last one to mess with the VDSO).
> 
> On 2019-12-03 15:43, Jerome Forissier wrote:
>> Hi,
>>
>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>
>> For some reason, anything past v5.1 doesn't work for me and I could not
>> figure out why. The symptom is it never gets to the login prompt. The
>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>
>> I tried replacing /init with a shell, in which case I can type a command
>> but whatever it is (even a simple "ls"), the command hangs on exit and I
>> never get back to the prompt.
>>
>> Then I started bisecting, that was quite painful but I found several
>> problematic commits. I ended up reverting the following (in this order)
>> to be able to boot v5.4:
>>
>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
>> 2. "arm64: vdso: Explicitly add build-id option"
>> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>>     held"
>> 4. "arm64: vdso: Remove stale files from old assembly implementation"
>>
>> So the main thing appears to be the VDSO stuff, but if I do not also
>> revert the arch_timer commit I get a kernel panic:
>>
>> [    4.657118] Run /init as init process
>> [    4.662380] Kernel panic - not syncing: Attempted to kill init!
>>                exitcode=0x00000004
>> [    4.670035] CPU: 7 PID: 1 Comm: init Not tainted 5.4.0-00003-
>>                g223b12c033fb #258
>> [    4.677338] Hardware name: HiKey960 (DT)
>> [    4.681253] Call trace:
>> [    4.683700]  dump_backtrace+0x0/0x148
>> [    4.687355]  show_stack+0x24/0x30
>> [    4.690664]  dump_stack+0xbc/0x100
>> [    4.694058]  panic+0x168/0x368
>> [    4.697105]  do_exit+0xa10/0xa28
>> [    4.700323]  do_group_exit+0x48/0xa8
>> [    4.703892]  get_signal+0xec/0x848
>> [    4.707287]  do_notify_resume+0x21c/0x480
>> [    4.711290]  work_pending+0x8/0x10
>> [    4.714689] SMP: stopping secondary CPUs
>> [    4.718607] Kernel Offset: disabled
>> [    4.722089] CPU features: 0x0002,21082004
>> [    4.726090] Memory Limit: none
>> [    4.729145] ---[ end Kernel panic - not syncing: Attempted to kill
>>                init! exitcode=0x00000004 ]---
>>
>> Any idea what could be wrong with my setup?
> 
> Posting the relevant sections of your kernel messages would be a good
> start.

Not sure what's relevant, so here are the full boot logs: v5.1 [1],
boots fine; v5.4 [2], hangs when launching /init (actually seems to be
stuck in some kind of active loop judging by the "THERMAL ALARM"
message); v5.4 + the above commits reverted [3], boots fine again
(please ignore the message "optee: PTA_CMD_GET_DEVICES invoke function
err: ffff0006" as well as the errors about /dev/tee*, they are unrelated
and are fixed in -next).

[1] https://pastebin.com/pj8tb4Qr
[2] https://pastebin.com/sQTMQ8wu
[3] https://pastebin.com/58YycSF4

Thanks,
-- 
Jerome

> 
> The reversal of the timer patch seems like a red herring, but Vincenzo
> should be able to help you there.
> 
> Thanks,
> 
>         M.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Marc Zyngier]

[switching email address]

Hi Jerome,

On 2019-12-04 09:01, Jerome Forissier wrote:
> Hi Marc,
>
> On 12/3/19 6:47 PM, Marc Zyngier wrote:
>> Hi Jerome,
>>
>> Adding Vincenzo (who was the last one to mess with the VDSO).
>>
>> On 2019-12-03 15:43, Jerome Forissier wrote:
>>> Hi,
>>>
>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 
>>> board?
>>>
>>> For some reason, anything past v5.1 doesn't work for me and I could 
>>> not
>>> figure out why. The symptom is it never gets to the login prompt. 
>>> The
>>> root FS is a Buildroot-generated one, and prior to reaching the 
>>> kernel
>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>>
>>> I tried replacing /init with a shell, in which case I can type a 
>>> command
>>> but whatever it is (even a simple "ls"), the command hangs on exit 
>>> and I
>>> never get back to the prompt.
>>>
>>> Then I started bisecting, that was quite painful but I found 
>>> several
>>> problematic commits. I ended up reverting the following (in this 
>>> order)
>>> to be able to boot v5.4:
>>>
>>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
>>> 2. "arm64: vdso: Explicitly add build-id option"
>>> 3. "arm64: arch_timer: Ensure counter register reads occur with 
>>> seqlock
>>>     held"
>>> 4. "arm64: vdso: Remove stale files from old assembly 
>>> implementation"
>>>
>>> So the main thing appears to be the VDSO stuff, but if I do not 
>>> also
>>> revert the arch_timer commit I get a kernel panic:
>>>
>>> [    4.657118] Run /init as init process
>>> [    4.662380] Kernel panic - not syncing: Attempted to kill init!
>>>                exitcode=0x00000004
>>> [    4.670035] CPU: 7 PID: 1 Comm: init Not tainted 5.4.0-00003-
>>>                g223b12c033fb #258
>>> [    4.677338] Hardware name: HiKey960 (DT)
>>> [    4.681253] Call trace:
>>> [    4.683700]  dump_backtrace+0x0/0x148
>>> [    4.687355]  show_stack+0x24/0x30
>>> [    4.690664]  dump_stack+0xbc/0x100
>>> [    4.694058]  panic+0x168/0x368
>>> [    4.697105]  do_exit+0xa10/0xa28
>>> [    4.700323]  do_group_exit+0x48/0xa8
>>> [    4.703892]  get_signal+0xec/0x848
>>> [    4.707287]  do_notify_resume+0x21c/0x480
>>> [    4.711290]  work_pending+0x8/0x10
>>> [    4.714689] SMP: stopping secondary CPUs
>>> [    4.718607] Kernel Offset: disabled
>>> [    4.722089] CPU features: 0x0002,21082004
>>> [    4.726090] Memory Limit: none
>>> [    4.729145] ---[ end Kernel panic - not syncing: Attempted to 
>>> kill
>>>                init! exitcode=0x00000004 ]---
>>>
>>> Any idea what could be wrong with my setup?
>>
>> Posting the relevant sections of your kernel messages would be a 
>> good
>> start.
>
> Not sure what's relevant, so here are the full boot logs: v5.1 [1],
> boots fine; v5.4 [2], hangs when launching /init (actually seems to 
> be
> stuck in some kind of active loop judging by the "THERMAL ALARM"
> message); v5.4 + the above commits reverted [3], boots fine again
> (please ignore the message "optee: PTA_CMD_GET_DEVICES invoke 
> function
> err: ffff0006" as well as the errors about /dev/tee*, they are 
> unrelated
> and are fixed in -next).
>
> [1] https://pastebin.com/pj8tb4Qr
> [2] https://pastebin.com/sQTMQ8wu
> [3] https://pastebin.com/58YycSF4

It is amusing that reverting the VDSO patches fixes anything, as your
HW is affected by ARM erratum 858921, for which we should *disable* the
VDSO altogether (the counter is not reliable and we have to workaround
it in the kernel anyway, hence no fast gettimeofday for you).

I bet that the conversion to the generic VDSO has resulted in a loss
of the VDSO disabling when only a secondary CPU is affected...

Can you please try the following hack for size? it is a terrible hack,
but it should give us an indication of whether my hunch is correct
or not. If this works, we'll look at the real solution. Otherwise, 
we'll
keep digging.

Thanks,

         M.

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 9a5464c625b4..dc63bb7e09bc 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -24,6 +24,7 @@
  #include <linux/sched/clock.h>
  #include <linux/sched_clock.h>
  #include <linux/acpi.h>
+#include <linux/timekeeper_internal.h>

  #include <asm/arch_timer.h>
  #include <asm/virt.h>
@@ -562,6 +563,7 @@ void arch_timer_enable_workaround(const struct 
arch_timer_erratum_workaround *wa
  	if (wa->read_cntvct_el0) {
  		clocksource_counter.archdata.vdso_direct = false;
  		vdso_default = false;
+		update_vsyscall_status(1);
  	}
  }

diff --git a/include/linux/timekeeper_internal.h 
b/include/linux/timekeeper_internal.h
index 84ff2844df2a..435c42f3567d 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -142,6 +142,7 @@ struct timekeeper {

  extern void update_vsyscall(struct timekeeper *tk);
  extern void update_vsyscall_tz(void);
+extern void update_vsyscall_status(u32 val);

  #else

@@ -151,6 +152,9 @@ static inline void update_vsyscall(struct 
timekeeper *tk)
  static inline void update_vsyscall_tz(void)
  {
  }
+static inline void update_vsyscall_status(u32)
+{
+}
  #endif

  #endif /* _LINUX_TIMEKEEPER_INTERNAL_H */
diff --git a/kernel/time/vsyscall.c b/kernel/time/vsyscall.c
index 5ee0f7709410..f5c048a65b72 100644
--- a/kernel/time/vsyscall.c
+++ b/kernel/time/vsyscall.c
@@ -128,3 +128,15 @@ void update_vsyscall_tz(void)

  	__arch_sync_vdso_data(vdata);
  }
+
+void update_vsyscall_status(u32 val)
+{
+	struct vdso_data *vdata = __arch_get_k_vdso_data();
+
+	vdso_write_begin(vdata);
+
+	vdata[CS_HRES_COARSE].clock_mode	= val;
+	vdata[CS_RAW].clock_mode		= val;
+
+	vdso_write_end(vdata);
+}

-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/4/19 11:18 AM, Marc Zyngier wrote:
> [switching email address]
> 
> Hi Jerome,
> 
> On 2019-12-04 09:01, Jerome Forissier wrote:
>> Hi Marc,
>>
>> On 12/3/19 6:47 PM, Marc Zyngier wrote:
>>> Hi Jerome,
>>>
>>> Adding Vincenzo (who was the last one to mess with the VDSO).
>>>
>>> On 2019-12-03 15:43, Jerome Forissier wrote:
>>>> Hi,
>>>>
>>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>>>
>>>> For some reason, anything past v5.1 doesn't work for me and I could not
>>>> figure out why. The symptom is it never gets to the login prompt. The
>>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>>>
>>>> I tried replacing /init with a shell, in which case I can type a
>>>> command
>>>> but whatever it is (even a simple "ls"), the command hangs on exit
>>>> and I
>>>> never get back to the prompt.
>>>>
>>>> Then I started bisecting, that was quite painful but I found several
>>>> problematic commits. I ended up reverting the following (in this order)
>>>> to be able to boot v5.4:
>>>>
>>>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
>>>> 2. "arm64: vdso: Explicitly add build-id option"
>>>> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>>>>     held"
>>>> 4. "arm64: vdso: Remove stale files from old assembly implementation"
>>>>
>>>> So the main thing appears to be the VDSO stuff, but if I do not also
>>>> revert the arch_timer commit I get a kernel panic:
>>>>
>>>> [    4.657118] Run /init as init process
>>>> [    4.662380] Kernel panic - not syncing: Attempted to kill init!
>>>>                exitcode=0x00000004
>>>> [    4.670035] CPU: 7 PID: 1 Comm: init Not tainted 5.4.0-00003-
>>>>                g223b12c033fb #258
>>>> [    4.677338] Hardware name: HiKey960 (DT)
>>>> [    4.681253] Call trace:
>>>> [    4.683700]  dump_backtrace+0x0/0x148
>>>> [    4.687355]  show_stack+0x24/0x30
>>>> [    4.690664]  dump_stack+0xbc/0x100
>>>> [    4.694058]  panic+0x168/0x368
>>>> [    4.697105]  do_exit+0xa10/0xa28
>>>> [    4.700323]  do_group_exit+0x48/0xa8
>>>> [    4.703892]  get_signal+0xec/0x848
>>>> [    4.707287]  do_notify_resume+0x21c/0x480
>>>> [    4.711290]  work_pending+0x8/0x10
>>>> [    4.714689] SMP: stopping secondary CPUs
>>>> [    4.718607] Kernel Offset: disabled
>>>> [    4.722089] CPU features: 0x0002,21082004
>>>> [    4.726090] Memory Limit: none
>>>> [    4.729145] ---[ end Kernel panic - not syncing: Attempted to kill
>>>>                init! exitcode=0x00000004 ]---
>>>>
>>>> Any idea what could be wrong with my setup?
>>>
>>> Posting the relevant sections of your kernel messages would be a good
>>> start.
>>
>> Not sure what's relevant, so here are the full boot logs: v5.1 [1],
>> boots fine; v5.4 [2], hangs when launching /init (actually seems to be
>> stuck in some kind of active loop judging by the "THERMAL ALARM"
>> message); v5.4 + the above commits reverted [3], boots fine again
>> (please ignore the message "optee: PTA_CMD_GET_DEVICES invoke function
>> err: ffff0006" as well as the errors about /dev/tee*, they are unrelated
>> and are fixed in -next).
>>
>> [1] https://pastebin.com/pj8tb4Qr
>> [2] https://pastebin.com/sQTMQ8wu
>> [3] https://pastebin.com/58YycSF4
> 
> It is amusing that reverting the VDSO patches fixes anything, as your
> HW is affected by ARM erratum 858921, for which we should *disable* the
> VDSO altogether (the counter is not reliable and we have to workaround
> it in the kernel anyway, hence no fast gettimeofday for you).
> 
> I bet that the conversion to the generic VDSO has resulted in a loss
> of the VDSO disabling when only a secondary CPU is affected...
> 
> Can you please try the following hack for size? it is a terrible hack,
> but it should give us an indication of whether my hunch is correct
> or not. If this works, we'll look at the real solution. Otherwise, we'll
> keep digging.

Nope, doesn't help unfortunately :-/
Boot log for v5.4 + this patch: https://pastebin.com/9RmVSNWE

-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Vincenzo Frascino]

Hi Jerome,

On 12/3/19 5:47 PM, Marc Zyngier wrote:
> Hi Jerome,
> 
> Adding Vincenzo (who was the last one to mess with the VDSO).

@Marc

Thanks for this, my filters completely missed Jerome's request, I might have a
look and tighten them ;)

[...]

@Jerome

Could you please provide your .config? Another question are you bringing it over
or regenerating it for each version of the kernel your are testing?

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

Hi Vincenzo,

On 12/4/19 1:49 PM, Vincenzo Frascino wrote:
> Hi Jerome,
> 
> On 12/3/19 5:47 PM, Marc Zyngier wrote:
>> Hi Jerome,
>>
>> Adding Vincenzo (who was the last one to mess with the VDSO).
> 
> @Marc
> 
> Thanks for this, my filters completely missed Jerome's request, I might have a
> look and tighten them ;)
> 
> [...]
> 
> @Jerome
> 
> Could you please provide your .config? 

.config for v5.4 [1], corresponds to boot log [2].

[1] https://pastebin.com/pWSYAshs
[2] https://pastebin.com/sQTMQ8wu


> Another question are you bringing it over
> or regenerating it for each version of the kernel your are testing?

I am regenerating it each time from arch/arm64/configs/defconfig and a
couple of local config fragments, using scripts/kconfig/merge_config.sh.

Thanks,
-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Catalin Marinas]

On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
> 
> For some reason, anything past v5.1 doesn't work for me and I could not
> figure out why. The symptom is it never gets to the login prompt. The
> root FS is a Buildroot-generated one, and prior to reaching the kernel
> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
> 
> I tried replacing /init with a shell, in which case I can type a command
> but whatever it is (even a simple "ls"), the command hangs on exit and I
> never get back to the prompt.
> 
> Then I started bisecting, that was quite painful but I found several
> problematic commits. I ended up reverting the following (in this order)
> to be able to boot v5.4:
> 
> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"

Commit 28b1a824a4f4, merged in 5.3

> 2. "arm64: vdso: Explicitly add build-id option"

Commit 7a0a93c51799, merged in 5.2

> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>     held"

Commit 75a19a0202db, merged in 5.2.

> 4. "arm64: vdso: Remove stale files from old assembly implementation"

Commit 37a5076098c1, merged in 5.4.

The above is a pretty random set of reverts that doesn't really help
pinpoint the issue.

Since 5.2 was the first kernel where the regression was noticed, could
you try reverting commit 75a19a0202db in 5.2 and try that specific
kernel version? If this doesn't solve the issue, it may be simpler to
bisect only between 5.1 and 5.2 rather than across multiple kernel
versions.

Thanks.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Vincenzo Frascino]

On 12/4/19 10:18 AM, Catalin Marinas wrote:
>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
> Commit 28b1a824a4f4, merged in 5.3
> 
>> 2. "arm64: vdso: Explicitly add build-id option"
> Commit 7a0a93c51799, merged in 5.2
> 
>> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>>     held"
> Commit 75a19a0202db, merged in 5.2.
> 
>> 4. "arm64: vdso: Remove stale files from old assembly implementation"
> Commit 37a5076098c1, merged in 5.4.
> 
> The above is a pretty random set of reverts that doesn't really help
> pinpoint the issue.
> 
> Since 5.2 was the first kernel where the regression was noticed, could
> you try reverting commit 75a19a0202db in 5.2 and try that specific
> kernel version? If this doesn't solve the issue, it may be simpler to
> bisect only between 5.1 and 5.2 rather than across multiple kernel
> versions.

I agree with Catalin here. The unified vDSO change is a 5.3+ change, should not
impact what you are seeing in 5.2.

Could you please as well provide some guidelines to reproduce your scenario
exactly? This would help in the debugging.

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/4/19 1:55 PM, Vincenzo Frascino wrote:
> On 12/4/19 10:18 AM, Catalin Marinas wrote:
>>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
>> Commit 28b1a824a4f4, merged in 5.3
>>
>>> 2. "arm64: vdso: Explicitly add build-id option"
>> Commit 7a0a93c51799, merged in 5.2
>>
>>> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>>>     held"
>> Commit 75a19a0202db, merged in 5.2.
>>
>>> 4. "arm64: vdso: Remove stale files from old assembly implementation"
>> Commit 37a5076098c1, merged in 5.4.
>>
>> The above is a pretty random set of reverts that doesn't really help
>> pinpoint the issue.
>>
>> Since 5.2 was the first kernel where the regression was noticed, could
>> you try reverting commit 75a19a0202db in 5.2 and try that specific
>> kernel version? If this doesn't solve the issue, it may be simpler to
>> bisect only between 5.1 and 5.2 rather than across multiple kernel
>> versions.
> 
> I agree with Catalin here. The unified vDSO change is a 5.3+ change, should not
> impact what you are seeing in 5.2.
> 
> Could you please as well provide some guidelines to reproduce your scenario
> exactly? This would help in the debugging.
> 

Do you have a HiKey960 board at your disposal? Well, you can build the
whole stuff I'm using by following the OP-TEE build instructions [1],
just use 'hikey960' for ${TARGET} in the description.

The scenario is simple: build, flash, power-cycle the board. That's it.
Default version boots fine (it's based on a v5.1 kernel), but checkout
Linux v5.4 instead and the login prompt never shows up on the UART console.

Note, if you just want to build the kernel Image you may simply run
"make linux" instead of "make".

[1]
https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution


Thanks,
-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Vincenzo Frascino]

[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

Hi Jerome,

On 04/12/2019 14:03, Jerome Forissier wrote:
[...]
> Do you have a HiKey960 board at your disposal? Well, you can build the
> whole stuff I'm using by following the OP-TEE build instructions [1],
> just use 'hikey960' for ${TARGET} in the description.
> 
> The scenario is simple: build, flash, power-cycle the board. That's it.
> Default version boots fine (it's based on a v5.1 kernel), but checkout
> Linux v5.4 instead and the login prompt never shows up on the UART console.
> 
> Note, if you just want to build the kernel Image you may simply run
> "make linux" instead of "make".
> 
> [1]
> https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution
> 

Thank you for the instructions, I managed to successfully boot the latest
mainline tree on the Hikey960. Full log in attachment.
And even the poweroff sequence looks fine to me.

Could you please try to follow the following steps and verify that it works for
you as well?

1. Download op-tee version 3.7.0.
2. Enter the linux directory and add the remote
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
3. Rebase the 3.7.0 branch kernel of linux master.
4. Build and Flash op-tee.

It should boot and have no issues on init. What I noticed is that the optee
provided kernel is not a 5.1 but a 5.1 plus some patches.

> 
> Thanks,
> 

-- 
Regards,
Vincenzo

[-- Attachment #2: Hikey960.txt --]
[-- Type: text/plain, Size: 45951 bytes --]

hikey960 boarid:5301 xloader use UART6
scsysstat_value[0].
clear reset source
last_keypoint0,reboot_type0
secdbg not DCU.
SecDbgVer exit

 xloader chipid is: 0x36600110, start at 404ms.
Build Date: Dec  6 2017, 15:31:59
[clock_init] ++
hikey960 [hikey960_clk_init]
hi3660 [clk_setup]
[clock_init] --
storage type is UFS
ufs retry: 6 count v_tx:0 v_rx:0
ufs set v_tx:0 v_rx:0
Hikey960[5301] no need avs_init.
ddr ft:0xf20332a3,mode:1 target:4
UceLdOk
density: 0x00080008,0x00080008,0x00080008,0x00080008,0x00080008,0x00080008,0x00080008,0x00080008 
ddr info 0x00000401 
400M
685M
1067M
C0R,V0x0000002e e:66
C3R,V0x00000030 e:66
C0R,V0x0000002f e:66
C2R,V0x00000030 e:66
C3R,V0x00000031 e:66
C0R,V0x00000030 e:66
C1R,V0x00000030 e:113
C2R,V0x00000031 e:66
C3R,V0x00000032 e:66
C0R,V0x00000031 e:66
C1R,V0x00000031 e:66
C2R,V0x00000032 e:66
C3R,V0x00000033 e:65
C0R,V0x00000032 e:65
C1R,V0x00000032 e:66
C2R,V0x00000033 e:65
C3R,V0x00000034 e:65
C0R,V0x00000033 e:65
C1R,V0x00000033 e:65
C2R,V0x00000034 e:65
C3R,V0x00000035 e:65
C2R,V0x0000002f e:113
C0R,V0x00000030 e:113
C1R,V0x0000002f e:66
C2R,V0x00000030 e:66
C3R,V0x00000030 e:66
C0R,V0x00000031 e:66
C1R,V0x00000030 e:66
C2R,V0x00000031 e:66
C3R,V0x00000031 e:66
C0R,V0x00000032 e:66
C1R,V0x00000031 e:66
C2R,V0x00000032 e:66
C3R,V0x00000032 e:65
C0R,V0x00000033 e:66
C1R,V0x00000032 e:65
C2R,V0x00000033 e:65
C3R,V0x00000033 e:65
C0R,V0x00000034 e:65
C1R,V0x00000033 e:65
C2R,V0x00000034 e:65
C3R,V0x00000034 e:65
1244M
1866M
C0R,V0x00000015 e:193
C0R,V0x00000016 e:193
C3R,V0x00000016 e:66
C0R,V0x00000017 e:66
C1R,V0x00000017 e:113
C3R,V0x00000017 e:66
C0R,V0x00000015 e:113
C1R,V0x00000015 e:66
C0R,V0x00000016 e:66
C1R,V0x00000016 e:66
C2R,V0x00000016 e:66
C3R,V0x00000016 e:66
C0R,V0x00000017 e:66
C1R,V0x00000017 e:66
C2R,V0x00000017 e:66
C3R,V0x00000017 e:66
pack0Idx0Dcc:1
pack1Idx0Dcc:1
pack2Idx0Dcc:1
pack3Idx0Dcc:3
iomcu_subsys_init
boot_c0 PROFILE 4
NOTICE:  BL2: v2.0(release):v2.0-507-g34efb683e322
NOTICE:  BL2: Built : 11:18:53, Dec  5 2019
NOTICE:  ufs: H**** device must set VS_DebugSaveConfigTime 0x10
NOTICE:  BL2: Booting BL31
NOTICE:  BL31: v2.0(release):v2.0-507-g34efb683e322
NOTICE:  BL31: Built : 11:18:53, Dec  5 2019
D/TC:0 0 add_phys_mem:576 TEE_SHMEM_START type NSEC_SHM 0x3ee00000 size 0x00200000
D/TC:0 0 add_phys_mem:576 TA_RAM_START type TA_RAM 0x3f200000 size 0x00e00000
D/TC:0 0 add_phys_mem:576 VCORE_UNPG_RW_PA type TEE_RAM_RW 0x3f05e000 size 0x001a2000
D/TC:0 0 add_phys_mem:576 VCORE_UNPG_RX_PA type TEE_RAM_RX 0x3f000000 size 0x0005e000
D/TC:0 0 add_phys_mem:576 ROUNDDOWN(0xFFF32000, CORE_MMU_PGDIR_SIZE) type IO_NSEC 0xffe00000 size 0x00200000
D/TC:0 0 verify_special_mem_areas:520 SDP memory [3e800000 3ec00000]
D/TC:0 0 verify_special_mem_areas:520 NSEC DDR memory [40000000 c0000000]
D/TC:0 0 verify_special_mem_areas:520 NSEC DDR memory [0 3e000000]
D/TC:0 0 add_va_space:615 type RES_VASPACE size 0x00a00000
D/TC:0 0 add_va_space:615 type SHM_VASPACE size 0x02000000
D/TC:0 0 dump_mmap_table:751 type IO_NSEC      va 0x3ae00000..0x3affffff pa 0xffe00000..0xffffffff size 0x00200000 (pgdir)
D/TC:0 0 dump_mmap_table:751 type TA_RAM       va 0x3b000000..0x3bdfffff pa 0x3f200000..0x3fffffff size 0x00e00000 (pgdir)
D/TC:0 0 dump_mmap_table:751 type SHM_VASPACE  va 0x3c000000..0x3dffffff pa 0x00000000..0x01ffffff size 0x02000000 (pgdir)
D/TC:0 0 dump_mmap_table:751 type RES_VASPACE  va 0x3e200000..0x3ebfffff pa 0x00000000..0x009fffff size 0x00a00000 (pgdir)
D/TC:0 0 dump_mmap_table:751 type NSEC_SHM     va 0x3ee00000..0x3effffff pa 0x3ee00000..0x3effffff size 0x00200000 (pgdir)
D/TC:0 0 dump_mmap_table:751 type TEE_RAM_RX   va 0x3f000000..0x3f05dfff pa 0x3f000000..0x3f05dfff size 0x0005e000 (smallpg)
D/TC:0 0 dump_mmap_table:751 type TEE_RAM_RW   va 0x3f05e000..0x3f1fffff pa 0x3f05e000..0x3f1fffff size 0x001a2000 (smallpg)
D/TC:0 0 core_mmu_entry_to_finer_grained:795 xlat tables used 1 / 5
D/TC:0 0 core_mmu_entry_to_finer_grained:795 xlat tables used 2 / 5
I/TC: 
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[0] with top at 0x3f0b2e38
D/TC:0 0 init_canaries:161 watch *0x3f0b2e3c
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[1] with top at 0x3f0b3678
D/TC:0 0 init_canaries:161 watch *0x3f0b367c
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[2] with top at 0x3f0b3eb8
D/TC:0 0 init_canaries:161 watch *0x3f0b3ebc
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[3] with top at 0x3f0b46f8
D/TC:0 0 init_canaries:161 watch *0x3f0b46fc
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[4] with top at 0x3f0b4f38
D/TC:0 0 init_canaries:161 watch *0x3f0b4f3c
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[5] with top at 0x3f0b5778
D/TC:0 0 init_canaries:161 watch *0x3f0b577c
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[6] with top at 0x3f0b5fb8
D/TC:0 0 init_canaries:161 watch *0x3f0b5fbc
D/TC:0 0 init_canaries:161 #Stack canaries for stack_tmp[7] with top at 0x3f0b67f8
D/TC:0 0 init_canaries:161 watch *0x3f0b67fc
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[0] with top at 0x3f09ce38
D/TC:0 0 init_canaries:162 watch *0x3f09ce3c
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[1] with top at 0x3f09da78
D/TC:0 0 init_canaries:162 watch *0x3f09da7c
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[2] with top at 0x3f09e6b8
D/TC:0 0 init_canaries:162 watch *0x3f09e6bc
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[3] with top at 0x3f09f2f8
D/TC:0 0 init_canaries:162 watch *0x3f09f2fc
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[4] with top at 0x3f09ff38
D/TC:0 0 init_canaries:162 watch *0x3f09ff3c
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[5] with top at 0x3f0a0b78
D/TC:0 0 init_canaries:162 watch *0x3f0a0b7c
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[6] with top at 0x3f0a17b8
D/TC:0 0 init_canaries:162 watch *0x3f0a17bc
D/TC:0 0 init_canaries:162 #Stack canaries for stack_abt[7] with top at 0x3f0a23f8
D/TC:0 0 init_canaries:162 watch *0x3f0a23fc
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[0] with top at 0x3f0a4438
D/TC:0 0 init_canaries:164 watch *0x3f0a443c
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[1] with top at 0x3f0a6478
D/TC:0 0 init_canaries:164 watch *0x3f0a647c
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[2] with top at 0x3f0a84b8
D/TC:0 0 init_canaries:164 watch *0x3f0a84bc
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[3] with top at 0x3f0aa4f8
D/TC:0 0 init_canaries:164 watch *0x3f0aa4fc
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[4] with top at 0x3f0ac538
D/TC:0 0 init_canaries:164 watch *0x3f0ac53c
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[5] with top at 0x3f0ae578
D/TC:0 0 init_canaries:164 watch *0x3f0ae57c
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[6] with top at 0x3f0b05b8
D/TC:0 0 init_canaries:164 watch *0x3f0b05bc
D/TC:0 0 init_canaries:164 #Stack canaries for stack_thread[7] with top at 0x3f0b25f8
D/TC:0 0 init_canaries:164 watch *0x3f0b25fc
I/TC: OP-TEE version: 3.7.0 (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #1 Thu  5 Dec 11:17:36 UTC 2019 aarch64
D/TC:0 0 check_ta_store:638 TA store: "early TA"
D/TC:0 0 check_ta_store:638 TA store: "Secure Storage TA"
D/TC:0 0 check_ta_store:638 TA store: "REE"
D/TC:0 0 early_ta_init:255 Early TA 023f8f1a-292a-432b-8fc4-de8471358067 size 22154 (compressed, uncompressed 38676)
D/TC:0 0 mobj_mapped_shm_init:447 Shared memory address range: 3c000000, 3e000000
I/TC: Initialized
D/TC:0 0 init_primary_helper:1109 Primary CPU switching to normal world boot
UEFI firmware (version Alpha built at 11:18:32 on Dec  5 2019)
3h3h3h3hPress ESCAPE for boot options .Android Fastboot mode - version 0.7.
Press RETURN or SPACE key to quit.
Welcome to GRUB!

GNU GRUB  version 2.02

/----------------------------------------------------------------------------\||||||||||||||||||||||||\----------------------------------------------------------------------------/     Use the ^ and v keys to select which entry is highlighted.          
      Press enter to boot the selected OS, `e' to edit the commands       
      before booting or `c' for a command-line. ESC to return previous    
      menu.                                                                
*GNU/Linux (eMMC) UART6 (v2 or newer board)                                  GNU/Linux (eMMC) UART5 (v1 board)                                           Fastboot                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                
   The highlighted entry will be executed automatically in 10s.                   The highlighted entry will be executed automatically in 9s.                    The highlighted entry will be executed automatically in 8s.                                                                                                                                                                               EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.4.0-11769-g38732e3435ff (vinfra01@e119884-lin) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #2 SMP PREEMPT Thu Dec 5 11:19:06 GMT 2019
[    0.000000] Machine model: HiKey960
[    0.000000] earlycon: pl11 at MMIO 0x00000000fff32000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] printk: debug: ignoring loglevel setting.
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: EFI v2.60 by EDK II
[    0.000000] efi:  MEMATTR=0xbe78aa98  MEMRESERVE=0xba6d6018 
[    0.000000] cma: Reserved 32 MiB at 0x00000000de000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x000000021fffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x21f7c8100-0x21f7c9fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000021fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000001abfffff]
[    0.000000]   node   0: [mem 0x000000001ad88000-0x0000000031ffffff]
[    0.000000]   node   0: [mem 0x0000000032101000-0x000000003dffffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x0000000089b7ffff]
[    0.000000]   node   0: [mem 0x0000000089cc0000-0x00000000ba48ffff]
[    0.000000]   node   0: [mem 0x00000000ba490000-0x00000000ba6cffff]
[    0.000000]   node   0: [mem 0x00000000ba6d0000-0x00000000ba6d7fff]
[    0.000000]   node   0: [mem 0x00000000ba6d8000-0x00000000ba6dbfff]
[    0.000000]   node   0: [mem 0x00000000ba6dc000-0x00000000bf69ffff]
[    0.000000]   node   0: [mem 0x00000000bf6a0000-0x00000000bf6dffff]
[    0.000000]   node   0: [mem 0x00000000bf6e0000-0x00000000bf6effff]
[    0.000000]   node   0: [mem 0x00000000bf6f0000-0x00000000bf73ffff]
[    0.000000]   node   0: [mem 0x00000000bf740000-0x00000000dfffffff]
[    0.000000]   node   0: [mem 0x0000000200000000-0x000000021fffffff]
[    0.000000] Zeroed struct page in unavailable ranges: 640 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000021fffffff]
[    0.000000] On node 0 totalpages: 1039415
[    0.000000]   DMA zone: 4096 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 253303 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 10235 pages used for memmap
[    0.000000]   DMA32 zone: 655040 pages, LIFO batch:63
[    0.000000]   Normal zone: 2048 pages used for memmap
[    0.000000]   Normal zone: 131072 pages, LIFO batch:31
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] percpu: Embedded 31 pages/cpu s86488 r8192 d32296 u126976
[    0.000000] pcpu-alloc: s86488 r8192 d32296 u126976 alloc=31*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1023036
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/Image console=tty0 console=ttyAMA6,115200n8 earlycon=pl011,0xfff32000 root=/dev/disk/by-partlabel/system rootwait rw ignore_loglevel efi=noruntime
[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0x3a000000-0x3e000000] (64MB)
[    0.000000] Memory: 3917816K/4157660K available (14780K kernel code, 2760K rwdata, 7604K rodata, 8000K init, 483K bss, 207076K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] ftrace: allocating 52542 entries in 206 pages
[    0.000000] ftrace: allocated 206 pages with 5 groups
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] random: get_random_bytes called from start_kernel+0x324/0x4b4 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 1.92MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1c570327e, max_idle_ns: 1763180809505 ns
[    0.000004] sched_clock: 56 bits at 1920kHz, resolution 520ns, wraps every 4398046510977ns
[    0.008496] clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58334160866034 ns
[    0.019110] Console: colour dummy device 80x25
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.4.0-11769-g38732e3435ff (vinfra01@e119884-lin) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #2 SMP PREEMPT Thu Dec 5 11:19:06 GMT 2019
[    0.000000] Machine model: HiKey960
[    0.000000] earlycon: pl11 at MMIO 0x00000000fff32000 (options '')
[    0.000000] printk: bootconsole [pl11] enabled
[    0.000000] printk: debug: ignoring loglevel setting.
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: EFI v2.60 by EDK II
[    0.000000] efi:  MEMATTR=0xbe78aa98  MEMRESERVE=0xba6d6018 
[    0.000000] cma: Reserved 32 MiB at 0x00000000de000000
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x000000021fffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x21f7c8100-0x21f7c9fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000]   DMA32    [mem 0x0000000040000000-0x00000000ffffffff]
[    0.000000]   Normal   [mem 0x0000000100000000-0x000000021fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000001abfffff]
[    0.000000]   node   0: [mem 0x000000001ad88000-0x0000000031ffffff]
[    0.000000]   node   0: [mem 0x0000000032101000-0x000000003dffffff]
[    0.000000]   node   0: [mem 0x0000000040000000-0x0000000089b7ffff]
[    0.000000]   node   0: [mem 0x0000000089cc0000-0x00000000ba48ffff]
[    0.000000]   node   0: [mem 0x00000000ba490000-0x00000000ba6cffff]
[    0.000000]   node   0: [mem 0x00000000ba6d0000-0x00000000ba6d7fff]
[    0.000000]   node   0: [mem 0x00000000ba6d8000-0x00000000ba6dbfff]
[    0.000000]   node   0: [mem 0x00000000ba6dc000-0x00000000bf69ffff]
[    0.000000]   node   0: [mem 0x00000000bf6a0000-0x00000000bf6dffff]
[    0.000000]   node   0: [mem 0x00000000bf6e0000-0x00000000bf6effff]
[    0.000000]   node   0: [mem 0x00000000bf6f0000-0x00000000bf73ffff]
[    0.000000]   node   0: [mem 0x00000000bf740000-0x00000000dfffffff]
[    0.000000]   node   0: [mem 0x0000000200000000-0x000000021fffffff]
[    0.000000] Zeroed struct page in unavailable ranges: 640 pages
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000021fffffff]
[    0.000000] On node 0 totalpages: 1039415
[    0.000000]   DMA zone: 4096 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 253303 pages, LIFO batch:63
[    0.000000]   DMA32 zone: 10235 pages used for memmap
[    0.000000]   DMA32 zone: 655040 pages, LIFO batch:63
[    0.000000]   Normal zone: 2048 pages used for memmap
[    0.000000]   Normal zone: 131072 pages, LIFO batch:31
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: Trusted OS migration not required
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] percpu: Embedded 31 pages/cpu s86488 r8192 d32296 u126976
[    0.000000] pcpu-alloc: s86488 r8192 d32296 u126976 alloc=31*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] Speculative Store Bypass Disable mitigation not required
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 1023036
[    0.000000] Policy zone: Normal
[    0.000000] Kernel command line: BOOT_IMAGE=/Image console=tty0 console=ttyAMA6,115200n8 earlycon=pl011,0xfff32000 root=/dev/disk/by-partlabel/system rootwait rw ignore_loglevel efi=noruntime
[    0.000000] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes, linear)
[    0.000000] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] software IO TLB: mapped [mem 0x3a000000-0x3e000000] (64MB)
[    0.000000] Memory: 3917816K/4157660K available (14780K kernel code, 2760K rwdata, 7604K rodata, 8000K init, 483K bss, 207076K reserved, 32768K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.000000] ftrace: allocating 52542 entries in 206 pages
[    0.000000] ftrace: allocated 206 pages with 5 groups
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu: 	RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=8.
[    0.000000] 	Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] random: get_random_bytes called from start_kernel+0x324/0x4b4 with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 1.92MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1c570327e, max_idle_ns: 1763180809505 ns
[    0.000004] sched_clock: 56 bits at 1920kHz, resolution 520ns, wraps every 4398046510977ns
[    0.008496] clocksource: arm,sp804: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58334160866034 ns
[    0.019110] Console: colour dummy device 80x25
[    0.512075] printk: console [tty0] enabled
[    0.516390] Calibrating delay loop (skipped), value calculated using timer frequency.. 3.84 BogoMIPS (lpj=7680)
[    0.526660] pid_max: default: 32768 minimum: 301
[    0.531435] LSM: Security Framework initializing
[    0.536207] Mount-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.543744] Mountpoint-cache hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    0.575803] ASID allocator initialised with 32768 entries
[    0.589330] rcu: Hierarchical SRCU implementation.
[    0.604102] EFI runtime services will be disabled.
[    0.617011] smp: Bringing up secondary CPUs ...
D/TC:1   generic_boot_cpu_on_handler:1148 cpu 1: a0 0x0
D/TC:1   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
D/TC:2   generic_boot_cpu_on_handler:1148 cpu 2: a0 0x0
D/TC:2   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
D/TC:3   generic_boot_cpu_on_handler:1148 cpu 3: a0 0x0
D/TC:3   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
D/TC:4   generic_boot_cpu_on_handler:1148 cpu 4: a0 0x0
D/TC:4   select_vector:915 SMCCC_ARCH_WORKAROUND_1 (0x80008000) available
D/TC:4   select_vector:916 SMC Workaround for CVE-2017-5715 used
D/TC:4   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
D/TC:5   generic_boot_cpu_on_handler:1148 cpu 5: a0 0x0
D/TC:5   select_vector:915 SMCCC_ARCH_WORKAROUND_1 (0x80008000) available
D/TC:5   select_vector:916 SMC Workaround for CVE-2017-5715 used
D/TC:5   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
D/TC:6   generic_boot_cpu_on_handler:1148 cpu 6: a0 0x0
D/TC:6   select_vector:915 SMCCC_ARCH_WORKAROUND_1 (0x80008000) available
D/TC:6   select_vector:916 SMC Workaround for CVE-2017-5715 used
D/TC:6   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
D/TC:7   generic_boot_cpu_on_handler:1148 cpu 7: a0 0x0
D/TC:7   select_vector:915 SMCCC_ARCH_WORKAROUND_1 (0x80008000) available
D/TC:7   select_vector:916 SMC Workaround for CVE-2017-5715 used
D/TC:7   init_secondary_helper:1133 Secondary CPU Switching to normal world boot
[    0.666075] Detected VIPT I-cache on CPU1
[    0.666170] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.709991] Detected VIPT I-cache on CPU2
[    0.710020] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[    0.754011] Detected VIPT I-cache on CPU3
[    0.754039] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[    0.811815] CPU features: detected: ARM erratum 858921
[    0.811830] Detected VIPT I-cache on CPU4
[    0.811847] arch_timer: Enabling local workaround for ARM erratum 858921
[    0.811857] arch_timer: CPU4: Trapping CNTVCT access
[    0.811863] CPU4: Booted secondary processor 0x0000000100 [0x410fd091]
[    0.866259] Detected VIPT I-cache on CPU5
[    0.866272] arch_timer: Enabling local workaround for ARM erratum 858921
[    0.866277] arch_timer: CPU5: Trapping CNTVCT access
[    0.866282] CPU5: Booted secondary processor 0x0000000101 [0x410fd091]
[    0.922314] Detected VIPT I-cache on CPU6
[    0.922326] arch_timer: Enabling local workaround for ARM erratum 858921
[    0.922331] arch_timer: CPU6: Trapping CNTVCT access
[    0.922336] CPU6: Booted secondary processor 0x0000000102 [0x410fd091]
[    0.978351] Detected VIPT I-cache on CPU7
[    0.978363] arch_timer: Enabling local workaround for ARM erratum 858921
[    0.978368] arch_timer: CPU7: Trapping CNTVCT access
[    0.978372] CPU7: Booted secondary processor 0x0000000103 [0x410fd091]
[    0.978430] smp: Brought up 1 node, 8 CPUs
[    1.109427] SMP: Total of 8 processors activated.
[    1.114183] CPU features: detected: 32-bit EL0 Support
[    1.119387] CPU features: detected: CRC32 instructions
[    1.134242] CPU: All CPU(s) started at EL2
[    1.138408] alternatives: patching kernel code
[    1.144385] devtmpfs: initialized
[    1.150795] KASLR disabled due to lack of seed
[    1.155455] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    1.165316] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[    1.173005] pinctrl core: initialized pinctrl subsystem
[    1.178908] DMI not present or invalid.
[    1.182961] NET: Registered protocol family 16
[    1.188201] DMA: preallocated 256 KiB pool for atomic allocations
[    1.194366] audit: initializing netlink subsys (disabled)
[    1.199898] audit: type=2000 audit(0.916:1): state=initialized audit_enabled=0 res=1
[    1.207744] cpuidle: using governor menu
[    1.211878] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    1.219403] Serial: AMBA PL011 UART driver
[    1.239797] hi3660-mbox e896b000.mailbox: Mailbox enabled
[    1.255305] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    1.262090] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    1.268862] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    1.275635] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    1.283969] cryptd: max_cpu_qlen set to 1000
[    1.290972] ACPI: Interpreter disabled.
[    1.295524] iommu: Default domain type: Translated 
[    1.300691] vgaarb: loaded
[    1.303577] SCSI subsystem initialized
[    1.307484] libata version 3.00 loaded.
[    1.311634] usbcore: registered new interface driver usbfs
[    1.317206] usbcore: registered new interface driver hub
[    1.322662] usbcore: registered new device driver usb
[    1.328068] pps_core: LinuxPPS API ver. 1 registered
[    1.333085] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    1.342322] PTP clock support registered
[    1.346334] EDAC MC: Ver: 3.0.0
[    1.349797] Registered efivars operations
[    1.354135] FPGA manager framework
[    1.357599] Advanced Linux Sound Architecture Driver Initialized.
[    1.364259] clocksource: Switched to clocksource arch_sys_counter
[    1.667756] VFS: Disk quotas dquot_6.6.0
[    1.671763] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.678804] pnp: PnP ACPI: disabled
[    1.684758] thermal_sys: Registered thermal governor 'step_wise'
[    1.684760] thermal_sys: Registered thermal governor 'power_allocator'
[    1.691057] NET: Registered protocol family 2
[    1.702272] tcp_listen_portaddr_hash hash table entries: 2048 (order: 3, 32768 bytes, linear)
[    1.710926] TCP established hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    1.719041] TCP bind hash table entries: 32768 (order: 7, 524288 bytes, linear)
[    1.726639] TCP: Hash tables configured (established 32768 bind 32768)
[    1.733289] UDP hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    1.740107] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes, linear)
[    1.747433] NET: Registered protocol family 1
[    1.752050] RPC: Registered named UNIX socket transport module.
[    1.758037] RPC: Registered udp transport module.
[    1.762790] RPC: Registered tcp transport module.
[    1.767542] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    1.774291] PCI: CLS 0 bytes, default 64
[    1.778347] Unpacking initramfs...
[    1.956804] Freeing initrd memory: 7040K
[    1.961480] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    1.969963] hw perfevents: enabled with armv8_cortex_a73 PMU driver, 7 counters available
[    1.978364] kvm [1]: IPA Size Limit: 40bits
[    1.983070] kvm [1]: vgic interrupt IRQ1
[    1.987166] kvm [1]: Hyp mode initialized successfully
[    2.026437] Initialise system trusted keyrings
[    2.031030] workingset: timestamp_bits=44 max_order=20 bucket_order=0
[    2.040401] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    2.046658] NFS: Registering the id_resolver key type
[    2.051802] Key type id_resolver registered
[    2.056027] Key type id_legacy registered
[    2.060082] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    2.066937] 9p: Installing v9fs 9p2000 file system support
[    2.081041] Key type asymmetric registered
[    2.085184] Asymmetric key parser 'x509' registered
[    2.090139] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[    2.097622] io scheduler mq-deadline registered
[    2.102201] io scheduler kyber registered
[    2.108547] pinctrl-single e896c000.pinmux: 124 pins, size 496
[    2.114538] pinctrl-single ff37e000.pinmux: 6 pins, size 24
[    2.120242] pinctrl-single ff3b6000.pinmux: 12 pins, size 48
[    2.126031] pinctrl-single ff3fd000.pinmux: 6 pins, size 24
[    2.131761] pinctrl-single fff11000.pinmux: 42 pins, size 168
[    2.137716] pinctrl-single e896c800.pinmux: 128 pins, size 512
[    2.143677] pinctrl-single ff3b6800.pinmux: 6 pins, size 24
[    2.149369] pinctrl-single ff3fd800.pinmux: 6 pins, size 24
[    2.155072] pinctrl-single ff37e800.pinmux: 6 pins, size 24
[    2.160792] pinctrl-single fff11800.pinmux: 47 pins, size 188
[    2.167521] pl061_gpio e8a0b000.gpio: PL061 GPIO chip registered
[    2.173702] pl061_gpio e8a0c000.gpio: PL061 GPIO chip registered
[    2.179871] pl061_gpio e8a0d000.gpio: PL061 GPIO chip registered
[    2.186038] pl061_gpio e8a0e000.gpio: PL061 GPIO chip registered
[    2.192205] pl061_gpio e8a0f000.gpio: PL061 GPIO chip registered
[    2.198369] pl061_gpio e8a10000.gpio: PL061 GPIO chip registered
[    2.204540] pl061_gpio e8a11000.gpio: PL061 GPIO chip registered
[    2.210703] pl061_gpio e8a12000.gpio: PL061 GPIO chip registered
[    2.216872] pl061_gpio e8a13000.gpio: PL061 GPIO chip registered
[    2.223038] pl061_gpio e8a14000.gpio: PL061 GPIO chip registered
[    2.229205] pl061_gpio e8a15000.gpio: PL061 GPIO chip registered
[    2.235368] pl061_gpio e8a16000.gpio: PL061 GPIO chip registered
[    2.241535] pl061_gpio e8a17000.gpio: PL061 GPIO chip registered
[    2.247698] pl061_gpio e8a18000.gpio: PL061 GPIO chip registered
[    2.253867] pl061_gpio e8a19000.gpio: PL061 GPIO chip registered
[    2.260030] pl061_gpio e8a1a000.gpio: PL061 GPIO chip registered
[    2.266192] pl061_gpio e8a1b000.gpio: PL061 GPIO chip registered
[    2.272355] pl061_gpio e8a1c000.gpio: PL061 GPIO chip registered
[    2.278524] pl061_gpio ff3b4000.gpio: PL061 GPIO chip registered
[    2.284688] pl061_gpio ff3b5000.gpio: PL061 GPIO chip registered
[    2.290856] pl061_gpio e8a1f000.gpio: PL061 GPIO chip registered
[    2.297030] pl061_gpio e8a20000.gpio: PL061 GPIO chip registered
[    2.303199] pl061_gpio fff0b000.gpio: PL061 GPIO chip registered
[    2.309368] pl061_gpio fff0c000.gpio: PL061 GPIO chip registered
[    2.315534] pl061_gpio fff0d000.gpio: PL061 GPIO chip registered
[    2.321702] pl061_gpio fff0e000.gpio: PL061 GPIO chip registered
[    2.327866] pl061_gpio fff0f000.gpio: PL061 GPIO chip registered
[    2.334034] pl061_gpio fff10000.gpio: PL061 GPIO chip registered
[    2.340201] pl061_gpio fff1d000.gpio: PL061 GPIO chip registered
[    2.385071] kirin-pcie f4000000.pcie: host bridge /soc/pcie@f4000000 ranges:
[    2.392211] kirin-pcie f4000000.pcie:      MEM 0x00f6000000..0x00f7ffffff -> 0x0000000000
[    3.404293] kirin-pcie f4000000.pcie: Link Fail
[    3.408937] kirin-pcie f4000000.pcie: PCI host bridge to bus 0000:00
[    3.415365] pci_bus 0000:00: root bus resource [bus 00-01]
[    3.420911] pci_bus 0000:00: root bus resource [mem 0xf6000000-0xf7ffffff] (bus address [0x00000000-0x01ffffff])
[    3.431224] pci 0000:00:00.0: [19e5:3660] type 01 class 0x060400
[    3.437329] pci 0000:00:00.0: reg 0x10: [mem 0xf6000000-0xf6ffffff]
[    3.443779] pci 0000:00:00.0: supports D1 D2
[    3.448094] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot
[    3.455734] pci_bus 0000:01: busn_res: can not insert [bus 01-ff] under [bus 00-01] (conflicts with (null) [bus 00-01])
[    3.467975] pci 0000:00:00.0: BAR 0: assigned [mem 0xf6000000-0xf6ffffff]
[    3.474844] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    3.480334] pcieport 0000:00:00.0: PME: Signaling with IRQ 66
[    3.486275] pcieport 0000:00:00.0: AER: enabled with IRQ 66
[    3.492448] EINJ: ACPI disabled.
[    3.498012] k3-dma fdf30000.dma: initialized
[    3.502364] k3-dma e804b000.dma-controller: dma-channel-mask doesn't exist, considering all as available.
[    3.512627] k3-dma e804b000.dma-controller: initialized
[    3.521100] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    3.528402] SuperH (H)SCI(F) driver initialized
[    3.533198] msm_serial: driver initialized
[    3.542080] loop: module loaded
[    3.546817] ufshcd-hisi ff3b0000.ufs: ufshcd_populate_vreg: Unable to find vdd-hba-supply regulator, assuming enabled
[    3.557557] ufshcd-hisi ff3b0000.ufs: ufshcd_populate_vreg: Unable to find vcc-supply regulator, assuming enabled
[    3.567934] ufshcd-hisi ff3b0000.ufs: ufshcd_populate_vreg: Unable to find vccq-supply regulator, assuming enabled
[    3.578397] ufshcd-hisi ff3b0000.ufs: ufshcd_populate_vreg: Unable to find vccq2-supply regulator, assuming enabled
[    3.616548] scsi host0: ufshcd
[    3.622597] libphy: Fixed MDIO Bus: probed
[    3.626849] tun: Universal TUN/TAP device driver, 1.6
[    3.632292] thunder_xcv, ver 1.0
[    3.635562] thunder_bgx, ver 1.0
[    3.638839] nicpf, ver 1.0
[    3.641833] hclge is initializing
[    3.645183] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version
[    3.652481] hns3: Copyright (c) 2017 Huawei Corporation.
[    3.657870] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[    3.663764] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[    3.669764] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[    3.676798] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.682444] igbvf: Intel(R) Gigabit Virtual Function Network Driver - version 2.4.0-k
[    3.690358] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.
[    3.696479] sky2: driver version 1.30
[    3.700466] usbcore: registered new interface driver asix
[    3.705937] usbcore: registered new interface driver ax88179_178a
[    3.712105] usbcore: registered new interface driver cdc_ether
[    3.718010] usbcore: registered new interface driver dm9601
[    3.723652] usbcore: registered new interface driver net1080
[    3.729380] usbcore: registered new interface driver cdc_subset
[    3.735371] usbcore: registered new interface driver zaurus
[    3.741021] usbcore: registered new interface driver cdc_ncm
[    3.746798] VFIO - User Level meta-driver version: 0.3
[    3.752683] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    3.759286] ehci-pci: EHCI PCI platform driver
[    3.763791] ehci-platform: EHCI generic platform driver
[    3.766672] ufshcd-hisi ff3b0000.ufs: ufshcd_print_pwr_info:[RX, TX]: gear=[1, 1], lane[1, 1], pwr[SLOWAUTO_MODE, SLOWAUTO_MODE], rate = 0
[    3.769122] ehci-orion: EHCI orion driver
[    3.785779] ehci-exynos: EHCI EXYNOS driver
[    3.790048] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    3.796304] ohci-pci: OHCI PCI platform driver
[    3.800810] ohci-platform: OHCI generic platform driver
[    3.806137] ohci-exynos: OHCI EXYNOS driver
[    3.810569] usbcore: registered new interface driver usb-storage
[    3.817795] rtc-pl031 fff04000.rtc: registered as rtc0
[    3.823263] i2c /dev entries driver
[    3.828721] sp805-wdt e8a06000.watchdog: registration successful
[    3.834871] sp805-wdt e8a07000.watchdog: registration successful
[    3.843066] sdhci: Secure Digital Host Controller Interface driver
[    3.849314] sdhci: Copyright(c) Pierre Ossman
[    3.853826] Synopsys Designware Multimedia Card Interface Driver
[    3.860111] dwmmc_k3 ff37f000.dwmmc1: fifo-depth property not found, using value of FIFOTH register as default
[    3.872273] dwmmc_k3 ff37f000.dwmmc1: IDMAC supports 64-bit address mode.
[    3.879151] dwmmc_k3 ff37f000.dwmmc1: Using internal DMA controller.
[    3.885573] dwmmc_k3 ff37f000.dwmmc1: Version ID is 270a
[    3.890946] dwmmc_k3 ff37f000.dwmmc1: DW MMC controller at irq 60,32 bit host data width,256 deep fifo
[    3.896552] ufs flash device must set VS_DebugSaveConfigTime 0x10
[    3.900424] dwmmc_k3 ff37f000.dwmmc1: Got CD GPIO
[    3.908975] ufshcd-hisi ff3b0000.ufs: ufshcd_print_pwr_info:[RX, TX]: gear=[3, 3], lane[2, 2], pwr[FAST MODE, FAST MODE], rate = 2
[    3.923410] ufshcd-hisi ff3b0000.ufs: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0
[    3.926306] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[    3.935852] scsi 0:0:0:49488: Well-known LUN    SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    3.954341] scsi 0:0:0:49476: Well-known LUN    SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    3.957596] dwmmc_k3 ff3ff000.dwmmc2: fifo-depth property not found, using value of FIFOTH register as default
[    3.965138] scsi 0:0:0:49456: Well-known LUN    SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    3.975319] dwmmc_k3 ff3ff000.dwmmc2: IDMAC supports 64-bit address mode.
[    3.984141] scsi 0:0:0:0: Direct-Access     SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    3.988377] dwmmc_k3 ff3ff000.dwmmc2: Using internal DMA controller.
[    4.002099] scsi 0:0:0:1: Direct-Access     SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    4.002966] dwmmc_k3 ff3ff000.dwmmc2: Version ID is 270a
[    4.004738] sd 0:0:0:0: [sda] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB)
[    4.004978] sd 0:0:0:0: [sda] Write Protect is off
[    4.004983] sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10
[    4.005458] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
[    4.005697] sd 0:0:0:0: [sda] Optimal transfer size 524288 bytes
[    4.013971] scsi 0:0:0:2: Direct-Access     SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    4.015784] sd 0:0:0:1: [sdb] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB)
[    4.016016] sd 0:0:0:1: [sdb] Write Protect is off
[    4.016018] sd 0:0:0:1: [sdb] Mode Sense: 00 32 00 10
[    4.016486] sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA
[    4.016510] dwmmc_k3 ff3ff000.dwmmc2: DW MMC controller at irq 61,32 bit host data width,256 deep fifo
[    4.016725] sd 0:0:0:1: [sdb] Optimal transfer size 524288 bytes
[    4.024578] sd 0:0:0:0: [sda] Attached SCSI disk
[    4.026346] scsi 0:0:0:3: Direct-Access     SKhynix  H28U62301AMR     H109 PQ: 0 ANSI: 6
[    4.028923] sdhci-pltfm: SDHCI platform and OF driver helper
[    4.029025] sd 0:0:0:2: [sdc] 2048 4096-byte logical blocks: (8.39 MB/8.00 MiB)
[    4.029451] sd 0:0:0:2: [sdc] Write Protect is off
[    4.029455] sd 0:0:0:2: [sdc] Mode Sense: 00 32 00 10
[    4.030062] sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA
[    4.030309] sd 0:0:0:2: [sdc] Optimal transfer size 524288 bytes
[    4.031037] sd 0:0:0:3: [sdd] 7805952 4096-byte logical blocks: (32.0 GB/29.8 GiB)
[    4.031281] sd 0:0:0:3: [sdd] Write Protect is off
[    4.031283] sd 0:0:0:3: [sdd] Mode Sense: 00 32 00 10
[    4.031768] sd 0:0:0:3: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA
[    4.032011] sd 0:0:0:3: [sdd] Optimal transfer size 524288 bytes
[    4.035416] sd 0:0:0:1: [sdb] Attached SCSI disk
[    4.053845] Alternate GPT is invalid, using primary GPT.
[    4.057359] ledtrig-cpu: registered to indicate activity on CPUs
[    4.064141]  sdc: sdc1
[    4.069358] usbcore: registered new interface driver usbhid
[    4.075250] sd 0:0:0:2: [sdc] Attached SCSI disk
[    4.078431] Alternate GPT is invalid, using primary GPT.
[    4.078443]  sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12
[    4.081545] random: fast init done
[    4.081808] sd 0:0:0:3: [sdd] Attached SCSI disk
[    4.082691] usbhid: USB HID core driver
[    4.083582] optee: probing for conduit method from DT.
D/TC:6   tee_entry_exchange_capabilities:101 Dynamic shared memory is enabled
[    4.239672] optee: revision 3.7 (a2fa5018)
[    4.246754] optee: dynamic shared memory is enabled
E/TC:7 0 std_smc_entry:186 Bad arg address 0x216fd8000
[    4.260609] optee: initialized driver
[    4.265141] drop_monitor: Initializing network drop monitor service
[    4.271550] NET: Registered protocol family 17
[    4.276099] 9pnet: Installing 9P2000 support
[    4.280432] Key type dns_resolver registered
[    4.285285] registered taskstats version 1
[    4.289429] Loading compiled-in X.509 certificates
[    4.297833] ffd74000.serial: ttyAMA3 at MMIO 0xffd74000 (irq = 21, base_baud = 0) is a PL011 rev2
[    4.307769] fdf01000.serial: ttyAMA4 at MMIO 0xfdf01000 (irq = 22, base_baud = 0) is a PL011 rev2
[    4.316773] serial serial0: tty port ttyAMA4 registered
[    4.322123] fff32000.serial: ttyAMA6 at MMIO 0xfff32000 (irq = 23, base_baud = 0) is a PL011 rev2
[    4.331100] printk: console [ttyAMA6] enabled
[    4.331100] printk: console [ttyAMA6] enabled
[    4.339851] printk: bootconsole [pl11] disabled
[    4.339851] printk: bootconsole [pl11] disabled
[    4.352122] ssp-pl022 ffd68000.spi: ARM PL022 driver, device ID: 0x00041022
[    4.359151] ssp-pl022 ffd68000.spi: mapped registers from 0x00000000ffd68000 to (____ptrval____)
[    4.367971] ssp-pl022 ffd68000.spi: setup for DMA on RX dma0chan0, TX dma0chan1
[    4.378890] ssp-pl022 ff3b3000.spi: ARM PL022 driver, device ID: 0x00041022
[    4.385974] ssp-pl022 ff3b3000.spi: mapped registers from 0x00000000ff3b3000 to (____ptrval____)
[    4.394798] ssp-pl022 ff3b3000.spi: setup for DMA on RX dma0chan2, TX dma0chan3
[    4.410303] dwmmc_k3 ff3ff000.dwmmc2: fifo-depth property not found, using value of FIFOTH register as default
[    4.422452] dwmmc_k3 ff3ff000.dwmmc2: IDMAC supports 64-bit address mode.
[    4.429247] dwmmc_k3 ff3ff000.dwmmc2: Using internal DMA controller.
[    4.435602] dwmmc_k3 ff3ff000.dwmmc2: Version ID is 270a
[    4.440927] dwmmc_k3 ff3ff000.dwmmc2: DW MMC controller at irq 61,32 bit host data width,128 deep fifo
[    4.450310] mmc_host mmc1: card is non-removable.
[    4.550640] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[    4.575758] input: keys as /devices/platform/keys/input/input0
[    4.582903] rtc-pl031 fff04000.rtc: setting system clock to 1970-01-01T00:47:55 UTC (2875)
[    4.591332] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[    4.601781] dwmmc_k3 ff3ff000.dwmmc2: card claims to support voltages below defined range
[    4.615853] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[    4.623670] ALSA device list:
[    4.626636]   No soundcards found.
[    4.630131] uart-pl011 fff32000.serial: no DMA platform data
[    4.639133] Freeing unused kernel memory: 8000K
[    4.648270] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0)
[    4.659694] mmc1: new SDIO card at address 0001
[    4.665124] wl18xx_driver wl18xx.0.auto: Direct firmware load for ti-connectivity/wl18xx-conf.bin failed with error -2
[    4.675826] wl18xx_driver wl18xx.0.auto: Falling back to sysfs fallback for: ti-connectivity/wl18xx-conf.bin
[    4.688683] Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Initializing random number generator... [    4.719720] random: dd: uninitialized urandom read (512 bytes read)
done.
Set permissions on /dev/tee*: OK
Set permissions on /dev/ion: OK
Create/set permissions on /data/tee: OK
Starting tee-supplicant: OK
Starting network: OK

Welcome to Buildroot, type root or test to login
buildroot login: root
# [   36.090307] wlan-en-regulator: disabling

# 
# 
# 
# poweroff
# Stopping network: OK
Stopping tee-supplicant: FAIL
Saving random seed... [   64.495319] random: dd: uninitialized urandom read (512 bytes read)
done.
Stopping klogd: OK
Stopping syslogd: OK
umount: devtmpfs busy - remounted read-only
umount: can't unmount /: Invalid argument
The system is going down NOW!
Sent SIGTERM to all processes
[   64.762395] wlcore: ERROR could not get configuration binary ti-connectivity/wl18xx-conf.bin: -11
[   64.771294] wlcore: WARNING falling back to default config
[   64.902806] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[   65.017389] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0)
[   65.126881] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
[   65.235118] mmc_host mmc1: Bus speed (slot 0) = 25000000Hz (slot req 25000000Hz, actual 25000000HZ div = 0)
[   65.499395] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
Sent SIGKILL to all processes
Requesting system poweroff
[   65.524203] wlcore: WARNING Detected unconfigured mac address in nvs, derive from fuse instead.
[   65.532927] wlcore: WARNING This default nvs file can be removed from the file system
[   65.541381] wlcore: loaded
[   66.519314] kvm: exiting hardware virtualization
[   66.527041] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   66.536002] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   66.544076] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   66.552100] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[   66.569688] reboot: Power down

[-- Attachment #3: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]

[-- Attachment #4: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/5/19 1:04 PM, Vincenzo Frascino wrote:
> Hi Jerome,
> 
> On 04/12/2019 14:03, Jerome Forissier wrote:
> [...]
>> Do you have a HiKey960 board at your disposal? Well, you can build the
>> whole stuff I'm using by following the OP-TEE build instructions [1],
>> just use 'hikey960' for ${TARGET} in the description.
>>
>> The scenario is simple: build, flash, power-cycle the board. That's it.
>> Default version boots fine (it's based on a v5.1 kernel), but checkout
>> Linux v5.4 instead and the login prompt never shows up on the UART console.
>>
>> Note, if you just want to build the kernel Image you may simply run
>> "make linux" instead of "make".
>>
>> [1]
>> https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution
>>
> 
> Thank you for the instructions, I managed to successfully boot the latest
> mainline tree on the Hikey960. Full log in attachment.
> And even the poweroff sequence looks fine to me.

Nice.

> Could you please try to follow the following steps and verify that it works for
> you as well?
> 
> 1. Download op-tee version 3.7.0.
> 2. Enter the linux directory and add the remote
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 3. Rebase the 3.7.0 branch kernel of linux master.
> 4. Build and Flash op-tee.
> 
> It should boot and have no issues on init.

[Unfortunately, it doesn't work for me. The board still hangs (or
rather, loops) on /init. I'm puzzled at this point... What could be
wrong with my setup? Do we have different board revisions maybe?

...]

Now that's embarrassing :-/ I decided to re-build everything once again,
but *without ccache* this time. Guess what? Kernel v5.4 boots fine :-O
and master too.

I used to trust ccache blindly, until I discovered a bug which has
caused me some trouble for quite some time [1]. After upgrading I
thought all would be good again, but apparently not... That is quite
annoying! :-/

Would you recommend against using ccache for kernel development?

Anyway, thank you guys for your valuable help. I feel ashamed for
wasting your time troubleshooting a non-bug... but at least it wasn't in
vain.

[1] https://github.com/ccache/ccache/issues/136

> What I noticed is that the optee
> provided kernel is not a 5.1 but a 5.1 plus some patches.

True, but nothing really important. A vanilla kernel is supposed to work
fine including most of the OP-TEE stuff (except for some very specific
"secure data path" code which depends on the presence of a special ION
heap).

Thanks,
-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Vincenzo Frascino]

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

Hi Jerome,

>> Thank you for the instructions, I managed to successfully boot the latest
>> mainline tree on the Hikey960. Full log in attachment.
>> And even the poweroff sequence looks fine to me.
> 
> Nice.
> 
>> Could you please try to follow the following steps and verify that it works for
>> you as well?
>>
>> 1. Download op-tee version 3.7.0.
>> 2. Enter the linux directory and add the remote
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> 3. Rebase the 3.7.0 branch kernel of linux master.
>> 4. Build and Flash op-tee.
>>
>> It should boot and have no issues on init.
> 
> [Unfortunately, it doesn't work for me. The board still hangs (or
> rather, loops) on /init. I'm puzzled at this point... What could be
> wrong with my setup? Do we have different board revisions maybe?
> 

So my board is an Hikey960 ver.B and I am running the latest UEFI firmware.

Some useful links:

[1] https://snapshots.linaro.org/reference-platform/components/uefi-staging/
[2]
https://github.com/96boards-hikey/tools-images-hikey960/blob/master/README-flash-uefi.md

> ...]
> 
> Now that's embarrassing :-/ I decided to re-build everything once again,
> but *without ccache* this time. Guess what? Kernel v5.4 boots fine :-O
> and master too.
> > I used to trust ccache blindly, until I discovered a bug which has
> caused me some trouble for quite some time [1]. After upgrading I
> thought all would be good again, but apparently not... That is quite
> annoying! :-/
> 
> Would you recommend against using ccache for kernel development?
>

I never use ccache for kernel development.

> Anyway, thank you guys for your valuable help. I feel ashamed for
> wasting your time troubleshooting a non-bug... but at least it wasn't in
> vain.
>

Nothing to be embarrassed of, I am curious as well now to know what is going on
with your setup :)

> [1] https://github.com/ccache/ccache/issues/136
> 
>> What I noticed is that the optee
>> provided kernel is not a 5.1 but a 5.1 plus some patches.
> 
> True, but nothing really important. A vanilla kernel is supposed to work
> fine including most of the OP-TEE stuff (except for some very specific
> "secure data path" code which depends on the presence of a special ION
> heap).
> 

Ok, I thought it was worth mentioning.

> Thanks,
> 

-- 
Regards,
Vincenzo

[-- Attachment #2: pEpkey.asc --]
[-- Type: application/pgp-keys, Size: 14291 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

Hi Catalin,

On 12/4/19 11:18 AM, Catalin Marinas wrote:
> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>
>> For some reason, anything past v5.1 doesn't work for me and I could not
>> figure out why. The symptom is it never gets to the login prompt. The
>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>
>> I tried replacing /init with a shell, in which case I can type a command
>> but whatever it is (even a simple "ls"), the command hangs on exit and I
>> never get back to the prompt.
>>
>> Then I started bisecting, that was quite painful but I found several
>> problematic commits. I ended up reverting the following (in this order)
>> to be able to boot v5.4:
>>
>> 1. "arm64: vdso: Substitute gettimeofday() with C implementation"
> 
> Commit 28b1a824a4f4, merged in 5.3
> 
>> 2. "arm64: vdso: Explicitly add build-id option"
> 
> Commit 7a0a93c51799, merged in 5.2
> 
>> 3. "arm64: arch_timer: Ensure counter register reads occur with seqlock
>>     held"
> 
> Commit 75a19a0202db, merged in 5.2.
> 
>> 4. "arm64: vdso: Remove stale files from old assembly implementation"
> 
> Commit 37a5076098c1, merged in 5.4.
> 
> The above is a pretty random set of reverts that doesn't really help
> pinpoint the issue.
> 
> Since 5.2 was the first kernel where the regression was noticed, could
> you try reverting commit 75a19a0202db in 5.2 and try that specific
> kernel version?

Ends up with a kernel panic [1].

> If this doesn't solve the issue, it may be simpler to
> bisect only between 5.1 and 5.2 rather than across multiple kernel
> versions.

75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
[2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
dealing with multiple problems. As I said, the set of reverts above is
the best I could figure out, and believe me I spent several days trying
to troubleshoot this :-/ (that being said, I know nothing about the VDSO
or the arch timer so I could not try anything meaningful other than
reverting some commits).

[1] https://pastebin.com/U4iHLrc8
[2] https://pastebin.com/bLgzJYwE

-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Catalin Marinas]

On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
> On 12/4/19 11:18 AM, Catalin Marinas wrote:
> > On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
> >> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
> >>
> >> For some reason, anything past v5.1 doesn't work for me and I could not
> >> figure out why. The symptom is it never gets to the login prompt. The
> >> root FS is a Buildroot-generated one, and prior to reaching the kernel
> >> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
> >>
> >> I tried replacing /init with a shell, in which case I can type a command
> >> but whatever it is (even a simple "ls"), the command hangs on exit and I
> >> never get back to the prompt.
> >>
> >> Then I started bisecting, that was quite painful but I found several
> >> problematic commits. I ended up reverting the following (in this order)
> >> to be able to boot v5.4:
[...]
> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
> dealing with multiple problems. As I said, the set of reverts above is
> the best I could figure out, and believe me I spent several days trying
> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
> or the arch timer so I could not try anything meaningful other than
> reverting some commits).

Thanks. There could as well be multiple issues. Since commit
75a19a0202db is cc stable, could you please apply it on top of 5.1 and
see if it fails? I don't have a HiKey960 at hand to try this.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/4/19 3:28 PM, Catalin Marinas wrote:
> On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
>> On 12/4/19 11:18 AM, Catalin Marinas wrote:
>>> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
>>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>>>
>>>> For some reason, anything past v5.1 doesn't work for me and I could not
>>>> figure out why. The symptom is it never gets to the login prompt. The
>>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>>>
>>>> I tried replacing /init with a shell, in which case I can type a command
>>>> but whatever it is (even a simple "ls"), the command hangs on exit and I
>>>> never get back to the prompt.
>>>>
>>>> Then I started bisecting, that was quite painful but I found several
>>>> problematic commits. I ended up reverting the following (in this order)
>>>> to be able to boot v5.4:
> [...]
>> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
>> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
>> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
>> dealing with multiple problems. As I said, the set of reverts above is
>> the best I could figure out, and believe me I spent several days trying
>> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
>> or the arch timer so I could not try anything meaningful other than
>> reverting some commits).
> 
> Thanks. There could as well be multiple issues. Since commit
> 75a19a0202db is cc stable, could you please apply it on top of 5.1 and
> see if it fails? I don't have a HiKey960 at hand to try this.
> 

Fails indeed (panic): https://pastebin.com/F0jpktii

-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Will Deacon]

On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
> On 12/4/19 3:28 PM, Catalin Marinas wrote:
> > On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
> >> On 12/4/19 11:18 AM, Catalin Marinas wrote:
> >>> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
> >>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
> >>>>
> >>>> For some reason, anything past v5.1 doesn't work for me and I could not
> >>>> figure out why. The symptom is it never gets to the login prompt. The
> >>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
> >>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
> >>>>
> >>>> I tried replacing /init with a shell, in which case I can type a command
> >>>> but whatever it is (even a simple "ls"), the command hangs on exit and I
> >>>> never get back to the prompt.
> >>>>
> >>>> Then I started bisecting, that was quite painful but I found several
> >>>> problematic commits. I ended up reverting the following (in this order)
> >>>> to be able to boot v5.4:
> > [...]
> >> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
> >> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
> >> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
> >> dealing with multiple problems. As I said, the set of reverts above is
> >> the best I could figure out, and believe me I spent several days trying
> >> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
> >> or the arch timer so I could not try anything meaningful other than
> >> reverting some commits).
> > 
> > Thanks. There could as well be multiple issues. Since commit
> > 75a19a0202db is cc stable, could you please apply it on top of 5.1 and
> > see if it fails? I don't have a HiKey960 at hand to try this.
> > 
> 
> Fails indeed (panic): https://pastebin.com/F0jpktii

Interesting. I followed your instructions and my board boots fine even
after applying that patch, but then I see the following on shutdown:

[   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
[   83.033392] Modules linked in:
[   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3
[   83.045319] Hardware name: HiKey960 (DT)
[   83.049238] pstate: 00000085 (nzcv daIf -PAN -UAO)
[   83.054026] pc : tick_handle_oneshot_broadcast+0x1c8/0x1e8
[   83.059509] lr : tick_handle_oneshot_broadcast+0x15c/0x1e8
[   83.064990] sp : ffff000010003b40
[   83.068298] x29: ffff000010003b40 x28: ffff0000116de0e4 
[   83.073607] x27: ffff0000118e85c0 x26: ffff0000116d7a00 
[   83.078916] x25: 0000001342080d5f x24: ffff00001198e2f0 
[   83.084225] x23: ffff0000116ddf40 x22: ffff00001198e2c0 
[   83.089533] x21: 0000000000000000 x20: 7fffffffffffffff 
[   83.094842] x19: ffff00001198e280 x18: 0000000000000010 
[   83.100151] x17: 0000000000000000 x16: 0000000000000000 
[   83.105459] x15: 0000000000000000 x14: 0000000000000000 
[   83.110768] x13: ffff000010e544d0 x12: ffff000010e544c8 
[   83.116077] x11: 0720072007200720 x10: 0000000000000040 
[   83.121384] x9 : ffff000011705bd0 x8 : ffff000011705bc8 
[   83.126693] x7 : ffff8000bf0002a0 x6 : 0000000000000004 
[   83.132002] x5 : 0000000000000000 x4 : 0000000000000001 
[   83.137310] x3 : 0000000000000000 x2 : 0000000000000100 
[   83.142619] x1 : ffff0000116ddf40 x0 : 0000000000000000 
[   83.147929] Call trace:
[   83.150372]  tick_handle_oneshot_broadcast+0x1c8/0x1e8
[   83.155512]  sp804_timer_interrupt+0x3c/0x50
[   83.159782]  __handle_irq_event_percpu+0x78/0x2c8
[   83.164482]  handle_irq_event_percpu+0x40/0x98
[   83.168922]  handle_irq_event+0x50/0x80
[   83.172755]  handle_fasteoi_irq+0xc0/0x178
[   83.176847]  generic_handle_irq+0x34/0x50
[   83.180852]  __handle_domain_irq+0x6c/0xc0
[   83.184947]  gic_handle_irq+0x58/0xa8
[   83.188605]  el1_irq+0xb8/0x180
[   83.191740]  __do_softirq+0xa8/0x3a0
[   83.195314]  irq_exit+0xc0/0xd0
[   83.198450]  __handle_domain_irq+0x70/0xc0
[   83.202541]  gic_handle_irq+0x58/0xa8
[   83.206198]  el1_irq+0xb8/0x180
[   83.209339]  _raw_spin_unlock_irq+0x28/0x60
[   83.213520]  do_exit+0xf0/0xa28
[   83.216661]  __se_sys_reboot+0x16c/0x248
[   83.220581]  __arm64_sys_reboot+0x24/0x30
[   83.224590]  el0_svc_common.constprop.0+0x88/0xf8
[   83.229290]  el0_svc_handler+0x34/0x90
[   83.233035]  el0_svc+0x8/0xc
[   83.235909] ---[ end trace 70f495d614c1efd2 ]---

which is unexpected.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/4/19 6:57 PM, Will Deacon wrote:
> On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
>> On 12/4/19 3:28 PM, Catalin Marinas wrote:
>>> On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
>>>> On 12/4/19 11:18 AM, Catalin Marinas wrote:
>>>>> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
>>>>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>>>>>
>>>>>> For some reason, anything past v5.1 doesn't work for me and I could not
>>>>>> figure out why. The symptom is it never gets to the login prompt. The
>>>>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>>>>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>>>>>
>>>>>> I tried replacing /init with a shell, in which case I can type a command
>>>>>> but whatever it is (even a simple "ls"), the command hangs on exit and I
>>>>>> never get back to the prompt.
>>>>>>
>>>>>> Then I started bisecting, that was quite painful but I found several
>>>>>> problematic commits. I ended up reverting the following (in this order)
>>>>>> to be able to boot v5.4:
>>> [...]
>>>> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
>>>> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
>>>> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
>>>> dealing with multiple problems. As I said, the set of reverts above is
>>>> the best I could figure out, and believe me I spent several days trying
>>>> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
>>>> or the arch timer so I could not try anything meaningful other than
>>>> reverting some commits).
>>>
>>> Thanks. There could as well be multiple issues. Since commit
>>> 75a19a0202db is cc stable, could you please apply it on top of 5.1 and
>>> see if it fails? I don't have a HiKey960 at hand to try this.
>>>
>>
>> Fails indeed (panic): https://pastebin.com/F0jpktii
> 
> Interesting. I followed your instructions and my board boots fine even
> after applying that patch, but then I see the following on shutdown:
> 
> [   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
> [   83.033392] Modules linked in:
> [   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3

That is not v5.1 plus one commit, is it?

> [   83.045319] Hardware name: HiKey960 (DT)
> [   83.049238] pstate: 00000085 (nzcv daIf -PAN -UAO)
> [   83.054026] pc : tick_handle_oneshot_broadcast+0x1c8/0x1e8
> [   83.059509] lr : tick_handle_oneshot_broadcast+0x15c/0x1e8
> [   83.064990] sp : ffff000010003b40
> [   83.068298] x29: ffff000010003b40 x28: ffff0000116de0e4 
> [   83.073607] x27: ffff0000118e85c0 x26: ffff0000116d7a00 
> [   83.078916] x25: 0000001342080d5f x24: ffff00001198e2f0 
> [   83.084225] x23: ffff0000116ddf40 x22: ffff00001198e2c0 
> [   83.089533] x21: 0000000000000000 x20: 7fffffffffffffff 
> [   83.094842] x19: ffff00001198e280 x18: 0000000000000010 
> [   83.100151] x17: 0000000000000000 x16: 0000000000000000 
> [   83.105459] x15: 0000000000000000 x14: 0000000000000000 
> [   83.110768] x13: ffff000010e544d0 x12: ffff000010e544c8 
> [   83.116077] x11: 0720072007200720 x10: 0000000000000040 
> [   83.121384] x9 : ffff000011705bd0 x8 : ffff000011705bc8 
> [   83.126693] x7 : ffff8000bf0002a0 x6 : 0000000000000004 
> [   83.132002] x5 : 0000000000000000 x4 : 0000000000000001 
> [   83.137310] x3 : 0000000000000000 x2 : 0000000000000100 
> [   83.142619] x1 : ffff0000116ddf40 x0 : 0000000000000000 
> [   83.147929] Call trace:
> [   83.150372]  tick_handle_oneshot_broadcast+0x1c8/0x1e8
> [   83.155512]  sp804_timer_interrupt+0x3c/0x50
> [   83.159782]  __handle_irq_event_percpu+0x78/0x2c8
> [   83.164482]  handle_irq_event_percpu+0x40/0x98
> [   83.168922]  handle_irq_event+0x50/0x80
> [   83.172755]  handle_fasteoi_irq+0xc0/0x178
> [   83.176847]  generic_handle_irq+0x34/0x50
> [   83.180852]  __handle_domain_irq+0x6c/0xc0
> [   83.184947]  gic_handle_irq+0x58/0xa8
> [   83.188605]  el1_irq+0xb8/0x180
> [   83.191740]  __do_softirq+0xa8/0x3a0
> [   83.195314]  irq_exit+0xc0/0xd0
> [   83.198450]  __handle_domain_irq+0x70/0xc0
> [   83.202541]  gic_handle_irq+0x58/0xa8
> [   83.206198]  el1_irq+0xb8/0x180
> [   83.209339]  _raw_spin_unlock_irq+0x28/0x60
> [   83.213520]  do_exit+0xf0/0xa28
> [   83.216661]  __se_sys_reboot+0x16c/0x248
> [   83.220581]  __arm64_sys_reboot+0x24/0x30
> [   83.224590]  el0_svc_common.constprop.0+0x88/0xf8
> [   83.229290]  el0_svc_handler+0x34/0x90
> [   83.233035]  el0_svc+0x8/0xc
> [   83.235909] ---[ end trace 70f495d614c1efd2 ]---
> 
> which is unexpected.
> 
> Will
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Will Deacon]

On Thu, Dec 05, 2019 at 08:26:48AM +0100, Jerome Forissier wrote:
> On 12/4/19 6:57 PM, Will Deacon wrote:
> > On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
> >> On 12/4/19 3:28 PM, Catalin Marinas wrote:
> >>> On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
> >>>> On 12/4/19 11:18 AM, Catalin Marinas wrote:
> >>>>> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
> >>>>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
> >>>>>>
> >>>>>> For some reason, anything past v5.1 doesn't work for me and I could not
> >>>>>> figure out why. The symptom is it never gets to the login prompt. The
> >>>>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
> >>>>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
> >>>>>>
> >>>>>> I tried replacing /init with a shell, in which case I can type a command
> >>>>>> but whatever it is (even a simple "ls"), the command hangs on exit and I
> >>>>>> never get back to the prompt.
> >>>>>>
> >>>>>> Then I started bisecting, that was quite painful but I found several
> >>>>>> problematic commits. I ended up reverting the following (in this order)
> >>>>>> to be able to boot v5.4:
> >>> [...]
> >>>> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
> >>>> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
> >>>> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
> >>>> dealing with multiple problems. As I said, the set of reverts above is
> >>>> the best I could figure out, and believe me I spent several days trying
> >>>> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
> >>>> or the arch timer so I could not try anything meaningful other than
> >>>> reverting some commits).
> >>>
> >>> Thanks. There could as well be multiple issues. Since commit
> >>> 75a19a0202db is cc stable, could you please apply it on top of 5.1 and
> >>> see if it fails? I don't have a HiKey960 at hand to try this.
> >>>
> >>
> >> Fails indeed (panic): https://pastebin.com/F0jpktii
> > 
> > Interesting. I followed your instructions and my board boots fine even
> > after applying that patch, but then I see the following on shutdown:
> > 
> > [   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
> > [   83.033392] Modules linked in:
> > [   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3
> 
> That is not v5.1 plus one commit, is it?

No, and I wasn't claiming that it was. I followed the instructions you
pointed us to [1] and cherry-picked 75a19a0202db on top. If there's
something different that I need to do in order to reproduce the problem,
then please holler. My experience with Hikey960 has been 100% "bloody awful"
so I don't have a good setup for simply building and running a kernel on it.

I also had to hack some of the EDK2 code in there to get it to compile, so
it continues to live up to expectations.

My hunch is that we're somehow ending up in the vDSO code but with the A73
workaround for erratum 858921 enabled. This shouldn't ever happen because
the syscall fallback will be enabled in this case, so I'm also thinking that
the SP804 clocksource is confusing things somehow. If we end up trapping to
the kernel with the seqlock held then I could see userspace getting stuck in
an infinite loop. Since I've been unable to reproduce the failure, could you
see if it persists even with CONFIG_ARM64_ERRATUM_858921=n?

Will

[1] https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/5/19 9:57 AM, Will Deacon wrote:
> On Thu, Dec 05, 2019 at 08:26:48AM +0100, Jerome Forissier wrote:
>> On 12/4/19 6:57 PM, Will Deacon wrote:
>>> On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
>>>> On 12/4/19 3:28 PM, Catalin Marinas wrote:
>>>>> On Wed, Dec 04, 2019 at 02:15:48PM +0100, Jerome Forissier wrote:
>>>>>> On 12/4/19 11:18 AM, Catalin Marinas wrote:
>>>>>>> On Tue, Dec 03, 2019 at 04:43:22PM +0100, Jerome Forissier wrote:
>>>>>>>> Has anyone successfully run kernel v5.2 or later on a HiKey960 board?
>>>>>>>>
>>>>>>>> For some reason, anything past v5.1 doesn't work for me and I could not
>>>>>>>> figure out why. The symptom is it never gets to the login prompt. The
>>>>>>>> root FS is a Buildroot-generated one, and prior to reaching the kernel
>>>>>>>> the board runs TF-A, OP-TEE, UEFI (edk2) and Grub.
>>>>>>>>
>>>>>>>> I tried replacing /init with a shell, in which case I can type a command
>>>>>>>> but whatever it is (even a simple "ls"), the command hangs on exit and I
>>>>>>>> never get back to the prompt.
>>>>>>>>
>>>>>>>> Then I started bisecting, that was quite painful but I found several
>>>>>>>> problematic commits. I ended up reverting the following (in this order)
>>>>>>>> to be able to boot v5.4:
>>>>> [...]
>>>>>> 75a19a0202db is the first bad commit. Its parent: commit 2f1d4e24d91b
>>>>>> ("firmware: arm_sdei: Prohibit probing in '_sdei_handler'") boots fine
>>>>>> [2]. Since reverting 75a19a0202db in v5.2 does not work, I suspect we're
>>>>>> dealing with multiple problems. As I said, the set of reverts above is
>>>>>> the best I could figure out, and believe me I spent several days trying
>>>>>> to troubleshoot this :-/ (that being said, I know nothing about the VDSO
>>>>>> or the arch timer so I could not try anything meaningful other than
>>>>>> reverting some commits).
>>>>>
>>>>> Thanks. There could as well be multiple issues. Since commit
>>>>> 75a19a0202db is cc stable, could you please apply it on top of 5.1 and
>>>>> see if it fails? I don't have a HiKey960 at hand to try this.
>>>>>
>>>>
>>>> Fails indeed (panic): https://pastebin.com/F0jpktii
>>>
>>> Interesting. I followed your instructions and my board boots fine even
>>> after applying that patch, but then I see the following on shutdown:
>>>
>>> [   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
>>> [   83.033392] Modules linked in:
>>> [   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3
>>
>> That is not v5.1 plus one commit, is it?
> 
> No, and I wasn't claiming that it was. 

;-) My apologies, I was confused.

> I followed the instructions you pointed us to [1] and cherry-picked 75a19a0202db> on top. If there's something different that I need to do in order to
reproduce> the problem, then please holler.
> My experience with Hikey960 has been 100% "bloody awful"
> so I don't have a good setup for simply building and running a kernel on it.
> 
> I also had to hack some of the EDK2 code in there to get it to compile, so
> it continues to live up to expectations.

What error did you encounter? Is it this one by chance?

 error: ‘__builtin_strncpy’ output truncated [...]

I just noticed GCC 9.x shows this, while GCC 8.x doesn't. So it depends
on what distribution you are using. I will need to do something to
address this problem.

Thanks,
-- 
Jerome

> 
> My hunch is that we're somehow ending up in the vDSO code but with the A73
> workaround for erratum 858921 enabled. This shouldn't ever happen because
> the syscall fallback will be enabled in this case, so I'm also thinking that
> the SP804 clocksource is confusing things somehow. If we end up trapping to
> the kernel with the seqlock held then I could see userspace getting stuck in
> an infinite loop. Since I've been unable to reproduce the failure, could you
> see if it persists even with CONFIG_ARM64_ERRATUM_858921=n?
> 
> Will
> 
> [1] https://optee.readthedocs.io/en/latest/building/gits/build.html#get-and-build-the-solution
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Will Deacon]

On Thu, Dec 05, 2019 at 03:54:10PM +0100, Jerome Forissier wrote:
> On 12/5/19 9:57 AM, Will Deacon wrote:
> > On Thu, Dec 05, 2019 at 08:26:48AM +0100, Jerome Forissier wrote:
> >> On 12/4/19 6:57 PM, Will Deacon wrote:
> >>> On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
> >>>> Fails indeed (panic): https://pastebin.com/F0jpktii
> >>>
> >>> Interesting. I followed your instructions and my board boots fine even
> >>> after applying that patch, but then I see the following on shutdown:
> >>>
> >>> [   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
> >>> [   83.033392] Modules linked in:
> >>> [   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3
> >>
> >> That is not v5.1 plus one commit, is it?
> > 
> > No, and I wasn't claiming that it was. 
> 
> ;-) My apologies, I was confused.
> 
> > I followed the instructions you pointed us to [1] and cherry-picked 75a19a0202db> on top. If there's something different that I need to do in order to
> reproduce> the problem, then please holler.
> > My experience with Hikey960 has been 100% "bloody awful"
> > so I don't have a good setup for simply building and running a kernel on it.
> > 
> > I also had to hack some of the EDK2 code in there to get it to compile, so
> > it continues to live up to expectations.
> 
> What error did you encounter? Is it this one by chance?
> 
>  error: ‘__builtin_strncpy’ output truncated [...]
> 
> I just noticed GCC 9.x shows this, while GCC 8.x doesn't. So it depends
> on what distribution you are using. I will need to do something to
> address this problem.

I just bodged it with a strcpy(), but that's probably not the right fix.

That aside, I'm perplexed that I can't reproduce the exact problem you're
seeing. Are you doing anything other than thos instructions you provided?
(e.g. different .config, command line, userspace)

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/6/19 5:09 PM, Will Deacon wrote:
> On Thu, Dec 05, 2019 at 03:54:10PM +0100, Jerome Forissier wrote:
>> On 12/5/19 9:57 AM, Will Deacon wrote:
>>> On Thu, Dec 05, 2019 at 08:26:48AM +0100, Jerome Forissier wrote:
>>>> On 12/4/19 6:57 PM, Will Deacon wrote:
>>>>> On Wed, Dec 04, 2019 at 03:58:57PM +0100, Jerome Forissier wrote:
>>>>>> Fails indeed (panic): https://pastebin.com/F0jpktii
>>>>>
>>>>> Interesting. I followed your instructions and my board boots fine even
>>>>> after applying that patch, but then I see the following on shutdown:
>>>>>
>>>>> [   83.022955] WARNING: CPU: 0 PID: 1995 at kernel/time/tick-broadcast.c:647 tick_handle_oneshot_broadcast+0x1c8/0x1e8
>>>>> [   83.033392] Modules linked in:
>>>>> [   83.036447] CPU: 0 PID: 1995 Comm: init Tainted: G S                5.1.0-253105-g2b41f6584d59 #3
>>>>
>>>> That is not v5.1 plus one commit, is it?
>>>
>>> No, and I wasn't claiming that it was. 
>>
>> ;-) My apologies, I was confused.
>>
>>> I followed the instructions you pointed us to [1] and cherry-picked 75a19a0202db> on top. If there's something different that I need to do in order to
>> reproduce> the problem, then please holler.
>>> My experience with Hikey960 has been 100% "bloody awful"
>>> so I don't have a good setup for simply building and running a kernel on it.
>>>
>>> I also had to hack some of the EDK2 code in there to get it to compile, so
>>> it continues to live up to expectations.
>>
>> What error did you encounter? Is it this one by chance?
>>
>>  error: ‘__builtin_strncpy’ output truncated [...]
>>
>> I just noticed GCC 9.x shows this, while GCC 8.x doesn't. So it depends
>> on what distribution you are using. I will need to do something to
>> address this problem.
> 
> I just bodged it with a strcpy(), but that's probably not the right fix.
> 
> That aside, I'm perplexed that I can't reproduce the exact problem you're
> seeing. Are you doing anything other than thos instructions you provided?
> (e.g. different .config, command line, userspace)

As I replied to Vincenzo, it is not a kernel issue, the culprit is
ccache. To reproduce, you can do the following:

1. Clear the cache: ccache -C
2. Build kernel v5.1 with ccache enabled, then clean the build tree
3. Checkout and build v5.4, still with ccache enabled
4. Boot this kernel: it will hang.

Now if you check the SHA1 hashes of arch/arm64/kernel/vdso/vdso.o in
various scenarios:

- v5.4, no ccache:
b82810f6e9495eb8e787e82b4080654ce4afc30a
- v5.4, with ccache, built from a clean cache:
b82810f6e9495eb8e787e82b4080654ce4afc30a
- v5.1, no ccache:
8c09a2f25969e2bf74799d6b3fb52d0fbc3d58a8
- v5.4, with ccache, after building v5.1 (step 3 above):
8c09a2f25969e2bf74799d6b3fb52d0fbc3d58a8

As you can see, ccache introduces the vdso.o file from an older v5.1
build into a v5.4 kernel. No surprise it won't behave as expected :-/

The problematic thing seems to be the .incbin directive in vdso.S, but
TBH I still don't understand why since I am using ccache v3.7.6 which is
supposed to have fixed this bug... [1]

[1]
https://github.com/ccache/ccache/blob/master/doc/NEWS.adoc#ccache-333

-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Vincenzo Frascino]

Hi Jerome,

On 12/10/19 4:20 PM, Jerome Forissier wrote:
> Now if you check the SHA1 hashes of arch/arm64/kernel/vdso/vdso.o in
> various scenarios:
> 
> - v5.4, no ccache:
> b82810f6e9495eb8e787e82b4080654ce4afc30a
> - v5.4, with ccache, built from a clean cache:
> b82810f6e9495eb8e787e82b4080654ce4afc30a
> - v5.1, no ccache:
> 8c09a2f25969e2bf74799d6b3fb52d0fbc3d58a8
> - v5.4, with ccache, after building v5.1 (step 3 above):
> 8c09a2f25969e2bf74799d6b3fb52d0fbc3d58a8

This clearly explains the issue and why you were suspecting the vdso library.
Happy that you figured it out.

-- 
Regards,
Vincenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Kernel v5.2+ on HiKey960?

[Jerome Forissier]

On 12/10/19 5:26 PM, Vincenzo Frascino wrote:
> Hi Jerome,
> 
> On 12/10/19 4:20 PM, Jerome Forissier wrote:
>> Now if you check the SHA1 hashes of arch/arm64/kernel/vdso/vdso.o in
>> various scenarios:
>>
>> - v5.4, no ccache:
>> b82810f6e9495eb8e787e82b4080654ce4afc30a
>> - v5.4, with ccache, built from a clean cache:
>> b82810f6e9495eb8e787e82b4080654ce4afc30a
>> - v5.1, no ccache:
>> 8c09a2f25969e2bf74799d6b3fb52d0fbc3d58a8
>> - v5.4, with ccache, after building v5.1 (step 3 above):
>> 8c09a2f25969e2bf74799d6b3fb52d0fbc3d58a8
> 
> This clearly explains the issue and why you were suspecting the vdso library.
> Happy that you figured it out.
> 

Yeah. To put an end to this thread, and for the record, let me add that
the ccache issue is triggered by CCACHE_UNIFY=1. If "unify" mode is not
set (the default), there is no problem. I have filed a bug report with
ccache [1].

[1] https://github.com/ccache/ccache/issues/497

-- 
Jerome

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel