To test the fix for 824548 I tried to run an upstream kernel for kevin. I could build the kernel after disabling CONFIG_ARM64_LSE_ATOMICS, however the kernel does not boot. There are no messages on the console and console-ramoops only has messages from a v4.4 kernel.

A 4.18-rc2 kernel built with gcc boots on kevin. I previously ran upstream kernels built with clang on kevin, however I'm don't recall which exact version and if tweaks were required (unfortunately I lost the kernel git repo that might have had relevant branches).

I almost certainly tested v4.14 on kevin before posting https://lkml.org/lkml/2017/11/22/943 . The clang patches can be checked out with: git fetch cros refs/sandbox/mka/llvm/20171129/v4.14 && git checkout FETCH_HEAD
Apparently there are still a few patches needed for kevin support, since this kernel doesn't boot with gcc either.

v4.15 boots on kevin when built with gcc, but not with clang. To my best knowledge v4.15 should have all basic patches for clang support, except for this one:

commit 019cd46984d04703a39924178f503a98436ac0d7
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue Nov 21 13:40:17 2017 +0000

    crypto: arm64/aes-ce-cipher - move assembler code to .S file

I tried whether using older clang versions would fix the problem, but that didn't yield positive results (SDK versions I tried 2018.02.19.155117, 2017.11.30.224315, 2017.11.11.111647. Can be found at gs://chromiumos-sdk/${YYYY}/${MM}/aarch64-cros-linux-gnu-${VERSION}.tar.xz)

I also rolled back the kernel config options in third_party/chromiumos-overlay/eclass/cros-kernel to commit b019d971e33a (roughly the time of the above post to LKML), it didn't help either.

On the positive side it's not a general problem with arm64, I recently booted a v4.14 kernel built with clang on cheza.

For now I'm running out of ideas on what else to try short of using JTAG or similar, so it seems reasonable to at least document the findings so far.

For Chrome OS itself it's not a super-high priority to run clang built kernels on kevin, however for working on clang support in the upstream kernel a working arm64 platform is needed.
 

To test the fix for 824548 I tried to run an upstream kernel for kevin. I could build the kernel after disabling CONFIG_ARM64_LSE_ATOMICS, however the kernel does not boot. There are no messages on the console and console-ramoops only has messages from a v4.4 kernel.

A 4.18-rc2 kernel built with gcc boots on kevin. I previously ran upstream kernels built with clang on kevin, however I don't recall which exact version and if tweaks were required (unfortunately I lost the kernel git repo that might have had relevant branches).

I almost certainly tested v4.14 on kevin before posting https://lkml.org/lkml/2017/11/22/943 . The clang patches can be checked out with: git fetch cros refs/sandbox/mka/llvm/20171129/v4.14 && git checkout FETCH_HEAD
Apparently there are still a few patches needed for kevin support, since this kernel doesn't boot with gcc either.

v4.15 boots on kevin when built with gcc, but not with clang. To my best knowledge v4.15 should have all basic patches for clang support, except for this one:

commit 019cd46984d04703a39924178f503a98436ac0d7
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Tue Nov 21 13:40:17 2017 +0000

    crypto: arm64/aes-ce-cipher - move assembler code to .S file

I tried whether using older clang versions would fix the problem, but that didn't yield positive results (SDK versions I tried 2018.02.19.155117, 2017.11.30.224315, 2017.11.11.111647. Can be found at gs://chromiumos-sdk/${YYYY}/${MM}/aarch64-cros-linux-gnu-${VERSION}.tar.xz)

I also rolled back the kernel config options in third_party/chromiumos-overlay/eclass/cros-kernel to commit b019d971e33a (roughly the time of the above post to LKML), it didn't help either.

On the positive side it's not a general problem with arm64, I recently booted a v4.14 kernel built with clang on cheza.

For now I'm running out of ideas on what else to try short of using JTAG or similar, so it seems reasonable to at least document the findings so far.

For Chrome OS itself it's not a super-high priority to run clang built kernels on kevin, however for working on clang support in the upstream kernel a working arm64 platform is needed.
 

To test the fix for 824548 I tried to run an upstream kernel for kevin. I could build the kernel after disabling CONFIG_ARM64_LSE_ATOMICS, however the kernel does not boot. There are no messages on the console and console-ramoops only has messages from a v4.4 kernel.

A 4.18-rc2 kernel built with gcc boots on kevin, but not when built with clang, so I tried to go back to a known baseline. I almost certainly tested v4.14 on kevin before posting https://lkml.org/lkml/2017/11/22/943 . The corresponding tree can be checked out with: git fetch cros refs/sandbox/mka/llvm/20171129/v4.14 && git checkout FETCH_HEAD. As v4.18-rc2  it works with gcc, but not with clang.

In case a change in kernel config triggered a problem with clang I rolled back the kernel config options in third_party/chromiumos-overlay/eclass/cros-kernel to commit b019d971e33a (roughly the time of the above post to LKML), it didn't help though.

I experimented with older clang versions, but that didn't yield positive results eithers (SDK versions I tried 2018.02.19.155117, 2017.11.30.224315, 2017.11.11.111647. Can be found at gs://chromiumos-sdk/${YYYY}/${MM}/aarch64-cros-linux-gnu-${VERSION}.tar.xz)

On the positive side it's not a general problem with arm64 and newer upstream kernels, I recently booted a v4.14 kernel built with clang on cheza.

For now I'm running out of ideas on what else to try short of using JTAG or similar, so it seems reasonable to at least document the findings so far.

For Chrome OS itself it's not a super-high priority to run clang built kernels on kevin, however for working on clang support in the upstream kernel a working arm64 platform is needed.