07:32 <knuxify> i'm trying to re-add support for the exynos 4212, any large changes since... (checks notes)... circa 2017 i should be aware of? :p

07:33 <knuxify> more seriously though - i'm attempting to mainline my galaxy tab 3 8.0, which uses the exynos 4212, but i'm currently stuck - i've managed to get the system to boot and show logs via uart, but it seems to experience mysterious crashes when it loads the initramfs

07:34 <knuxify> here's the log from one of those crashes: https://pastebin.com/4XKXkZVr

07:35 <knuxify> i've reverted all the exynos 4212 removal commits i could find, but that didn't fix anything. i'm mostly just wondering if this could be related to something more common in the exynos4212 or if the fault's somewhere within my dts etc. my understanding of the platform is still quite primitive

07:38 <knuxify> (the reason why i say "mysterious crashes" is because the crash reason differs on every boot - sometimes it throws "BUG: FP instruction issued in kernel mode with FP unit disabled", sometimes it's "Unable to handle kernel NULL pointer dereference at virtual address 0000000" and sometimes it prints nothing at all - but what the crashes that print something have in common is that they all seem to error out during initramfs unpacking)

07:43 <knuxify> could entirely be an issue with how i make my boot.img - although the values match up with downstream, so i'm not sure what exactly it could be - but i don't think it is, especially given that if it was just trying to load an empty chunk of memory it'd say that it couldn't find the initramfs, not crash with kernel panics

07:43 <knuxify> (ok, if it didn't have anything to boot from, it *would* panic, but not crash!)

09:33 <krzk> knuxify: ugh, Exynos4212 you say... it's possible to bring it back but won't be easy. First, please start with v5.16, not with next. Second, several mach-exynos parts were moved to drivers/soc/samsung. You need to adjust your reverts to apply to new path and new drivers.

09:35 <krzk> Third, dts files are being refactored significantly in last 4 years. exynos4.dtsi changed, thus you need to modify exynos4212.dtsi in similar way how 4210 and 4412 were.

09:36 <krzk> I see you try 5.15, so ignore my first comment about 5.16. 5.15 is good.

09:37 <krzk> You should use earlycon in cmdline. You can also try init=/bin/sh to avoid bring-up of several optional modules and drivers.

09:40 <krzk> knuxify: The NULL pointer stacktrace could point you to place of failure (there is a chance). Other errors look like you have there more serious problem, maybe cache controller is not properly configured (although it is brought up), maybe CPU or bus frequencies are wrong, although it seems cpufreq was not yet configured when the erro happened.

09:42 <krzk> knuxify: did you read the comment related to that FP error ? To try CONFIG_DEBUG_ATOMIC_SLEEP?

09:43 <krzk> knuxify: be sure also that sizes of kernel/ramdisk/dtb are not too big for your u-boot loading addresses/ranges.

09:49 <krzk> You build your kernel with hard-float compiler, so be sure that you actually build it correctly... In general this will be difficult to debug because you run it under Android which does a lot of its own weirdness. Everything we debug is only regular Linux. So regular GCC (Debian, Ubuntu, gnueabi, not hard-float), exynos defconfig (plus eventually debugging options) and regular Linux OS (or boot to

09:49 <krzk> /bin/sh).

09:49 <krzk> If you want to debug Android stuff - no clue. It's never good to solve two problems at the same time...

09:52 <knuxify> i'm not using android, that's just the parameters the bootloader (s-boot 4.0 in this case) provides - this is running pure linux (with build tools/toolchain and initramfs postmarketOS to be exact)

09:54 <knuxify> *from postmarketOS

09:54 <knuxify> anyways, i'll try what you mentioned, and go over the code more carefully - thanks for the tips

16:03 <knuxify> alright, cleaned up my changes and rebased against v5.16: https://github.com/knuxify/tab3-8.0-mainline/tree/exynos4212-reintroduce

16:06 <knuxify> (not including my tab3 dts - that's wip and pushed here: https://github.com/knuxify/tab3-8.0-mainline/tree/v5.16-exynos)

16:06 <knuxify> unfortunately, the issues persist regardless

16:10 <knuxify> in any case, the fp error is rare; i usually get "Unable to handle kernel NULL pointer dereference at virtual address 00000000" and such. here's a different log, this time with a more recent build: https://pastebin.com/1AKBYwWh

16:11 <knuxify> (few changes of note - i disabled initramfs support for this test run altogether, hoping i'd be able to skip it (which didn't help at all). also temporarily commented out all the s5m8769 stuff in my dts)

16:13 <knuxify> i did some grepping around the kernel source to find any 4412-specific stuff that might've needed to be applied to the 4212, but couldn't find anything, and the few things i found (like line 199/200 in arch/arm/mach-exynos/platsmp.c) don't seem to fix my issues