00:38 <apritzel> aggi: sure, but without BL31 you won't have SMP, that's why you need to sacrifice EL2/HYP for the kernel, and let it launch in EL1

00:39 <apritzel> aggi: you won't lose much these days anyway, since KVM is gone from the ARM32 kernel for a while now

00:41 <apritzel> aggi: are you sure you have your arm kernel configured correctly? You have to manually select some drivers (pinctrl & clock, for a start) for those ARMv8 SoCs

00:47 <aggi> apritzel: good, you didn't miss the log;

00:47 <apritzel> aggi: oh, btw, your link above doesn't work ...

00:48 <aggi> meanwhile tested, with and without BL31, with and without CONFIG_ARMV8_SWITCH_TO_EL1; no luck

00:49 <apritzel> aggi: also: any particular reason you want to have an ARM kernel? You could go with an ARM userland, if you need to, but still use an arm64 kernel

00:50 <aggi> too, could verify the correct code paths are hit in bootm.c;

00:50 <aggi> apritzel: yes, many reasons; 1) i already got some pine64 boards here, 2) i want to test some specific toolchain for aarch32

00:51 <apritzel> so you can just launch an arm64 kernel, and give it an off-the-shelf aarch32 userland

00:51 <apritzel> that should work out of the box, given that your kernel has COMPAT enabled

00:58 <aggi> apritzel: ok. this would be good enough. is this slower than an aarch32 kernel?

00:59 <aggi> and, the kernel didn't launch with EL1, not sure why. the same kconfig/version does launch as aarch64; didn't at least see any printk (zImage decompression, and the usual dmesg printk, nothing)

01:00 <aggi> depending on the testcase, the system is locked after switch_to_el1 (no reset, only lock-up), or the system crashes (without switch_to_el1) when the aarch32 kernel launches

01:01 <aggi> apritzel: this is the u-boot output when EL1 isn't switched to https://dpaste.org/ZAxE

01:02 <aggi> with switch_to_el1 the system is locked/crashed without any output/reset, "Starting Kernel ...." and then nothing anymore

01:03 <aggi> apritzel: anyway, if COMPAT doesn't have any side-effects such as performance degradation, then aarch32 with COMPAT kernel is sufficient.

01:05 <apritzel> aggi: very little side effects, and does not require any hacking or code changes

01:12 <aggi> awesome! thanks for your help apritzel. if there is anything i could help with, i'm idling on oftc. i'll drop a short notice once i tested compat mode.

01:13 <apritzel> aggi: cool, thanks! many people are quite happy with that combination, apparently, but would like to hear your verdict on it

01:15 <apritzel> and regardless: getting a real arm32 kernel launched sounds like an interesting challenge, and be it just for trying (and possibly fixing U-Boot)

01:22 <aggi> tried. however, i was up to some other task: downgrading to gcc-4.7.4 and fix kernel headers of v5.10LTS which require nasty C11 _Generic feature; and gcc-4.7.4 doesn't support aarch64 (which is a minor annoyance to compile an aarch64 kernel with yet another cross-compiler toolchain required)

01:22 <aggi> and, i am not sure if the pine64 boards designated for aarch64 kernels would hit some other bugs with aarch32 kernels

01:23 <aggi> which, didn't launch as desired anyway.

01:25 <aggi> apritzel: and i noticed you got pine64 repos on github, by coincidence there is some other findings related, which isn't sunxi specific. if there was any other channel?

01:26 <apritzel> aggi: you could just take some distro kernel, they support the A64 SoC quite well these days

01:27 <apritzel> aggi: those pine64 repos are ancient, I should probably just remove them

01:27 <aggi> the _mainline_ integration status of some other pine64 boards was horrible (4.4SLTS in particular), because i wanted to review the patchset (ayufan) required; as said this is off-topic here.

01:31 <apritzel> 4.4? that didn't have any A64 support, IIRC

01:31 <apritzel> anyway, you can use github or query me directly here on OFTC

01:33 <aggi> i reject some GCC version bump required with kernel 5.10LTS (C11 features, in particular _Generic macro); anyway, i removed those from v5.10LTS already so i can keep the legacy gnu compiler for aarch32.

01:35 <apritzel> why would you do that? 4.7 is really ancient, and there were *many* improvements since then

01:36 <aggi> long term, ideally, i could replace gcc and llvm/clang with any other C90/99 compiler; that's the idea, and support for aarch32 is more common

01:37 <aggi> why? C90/99 compliance, and some other C compilers are known to be 10x faster compiling than gcc or clang; which is suitable for some embedded system and my source-based workflow

01:38 <apritzel> given the effort it took to make the kernel compile with clang (and the GCCisms that clang had to learn on the way), I'd say: good luck ...

01:39 <aggi> last known kernel was v2.6 compiled with tinycc, i know :(

01:40 <aggi> at least, gcc-4.7 avoids some problems with cross-compilation and bootstrapping, because it doesn't require a c++ compiler, and gcc-4.7 can be used to bootstrap any later version

01:40 <aggi> only disadvantage: missing aarch64 support

01:42 <apritzel> mmh, but it's 2022 now, isn't it? ;-)

01:44 <aggi> linux was rather conservative, for a very long time, with -std=gnu89

01:44 <apritzel> aggi: distro's provide cross compilers out of their repos now, and there are quite some binary toolchains around (bootlin, kernel.org)

01:44 <aggi> the aggressive version bumps began with kernel 4.19, again kernel 5.8, and recently another one 5.15

01:45 <aggi> apritzel: i am using gentoo-crossdev and compile from source *only*

01:45 <aggi> by coincidence, on tiny pine64 boards

01:45 <apritzel> aggi: sorry to hear that :-D

01:46 <apritzel> I put some instructions on my github to build mainline cross-compilers

01:46 <aggi> i refined the process, and some specific pine64 boards are very fast

17:36 <pcBob> Hello, can someone help me figure out how to apply USB functionality patch (https://patchwork.kernel.org/project/linux-usb/list/?series=264487&archive=both) for Allwinner F1C100s to my local linux 5.11 for Buildroot?

18:31 <ZenWalker> https://gitlab.com/mobian1/issues/-/issues/389

18:31 <ZenWalker> important issue, is not possible to suspend pinephone if microSD card is inserted (since kernel 5.14 I think)

19:55 <plaes> ~

21:14 <apritzel> aggi: for when you read this: I think the U-Boot code is fine, I get my own "looks like a kernel" code to run in AArch32 SVC (on a Pine64)

21:15 <apritzel> aggi: it's just the typical ARM "black screen" problem: the early code is not very chatty

21:16 <apritzel> with earlyprintk I see at least "C:0x400090A0-0x40A70200->0x41E5EC00-0x428C5D60"

21:22 <apritzel> so that means that some 32-bit kernel code is executing (the early relocation), it just gets lost somewhere in the decompression process later