Sesse

To be clear, ftrace does show any tracing messages. It is a framework where an administrator can hook certain functions, for instance for performance debugging (using eBPF or perf). You do need Linux administrator skills to understand such systems, but you do not need any understanding of the underlying kernel code. The primary reason to want this in a standard kernel is that you would often want to do measurements on a production system, without having to go through the onerous process of compiling your own kernel and then having to reboot. For instance, when someone is complaining about a video system losing frames, or a 3D printer losing too many timeslices and aborting a print.

@JohnTheCoolingFan So, now that this has all been merged (thanks!), there's the thing I wanted to do in the first place before starting to shave this yak; is there any reason why the Armbian kernel images ship with ftrace off? Specifically, having access to `perf sched record` can be really nice for figuring out what's going on when something misses its timeslice. (I just ticked CONFIG_FTRACE=y and what seemed to be a sensible set of options to add kernel tracepoints, and that was seemingly enough to make perf happy 🙂 ) AFAIK ftrace has essentially zero runtime overhead when inactive (there's a nop prologue at the start of every tracable kernel function, and that's it), as long as CONFIG_HAVE_DYNAMIC_FTRACE=y is also set, so it shouldn't be a very risky option to enable in the default configs. I believe basically all desktop/server distribution kernels enable it since a long time, although I haven't checked.

I'm fine with this subject edit.

The CB1 is H616-based, but I'm not entirely sure what you're referring to apart from that. I would love to see your proposed edits before words are being put in my mouth 🙂 There was a typo in my patch that essentially caused the dependency to be ignored, I'm adding an updated version. From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: Steinar H. Gunderson <steinar+kernel@gunderson.no> Date: Mon, 4 Nov 2024 15:35:38 +0000 Subject: Fix broken allwinner,sram dependency on CB1 On BigTreeTech CB1, the thermal sensor has an allwinner,sram property pointing to <&syscon>. However, Armbian has an out-of-tree kernel patch that creates dependencies based on allwinner,sram properties, which assumes that they point to sram nodes exactly two levels below the syscon node (instead of the syscon itself). This manifests itself as the thermal sensor refusing to load with a nonsensical error message: [ 23.775976] platform 5070400.thermal-sensor: deferred probe pending: platform: wait for supplier Note that it does not say _which_ supplier it is waiting for (the message ends in a space and then no supplier). The patch was unproblematic in the 5.6 megous patch set, where it was introduced, and in 6.6, which is current for Armbian, but in 6.8, the sun8i-thermal driver got mainlined, with this extra property compared to the out-of-tree version we used before (since it wants to clear a special bit at 0x300000 instead of relying on the firmware to do so before kernel boot). Fix by being a bit more flexible when we walk up the tree, so that we always stop at the syscon node. Tested on a Sovol SV08, which is CB1-based. Signed-off-by: Steinar H. Gunderson <steinar+kernel@gunderson.no> --- drivers/of/property.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/of/property.c b/drivers/of/property.c index 6fcfcda9d..f00f2b129 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1368,12 +1368,13 @@ static struct device_node *parse_allwinner_sram(struct device_node *np, if (index > 0) return NULL; sram_node = of_parse_phandle(np, prop_name, 0); - sram_node = of_get_parent(sram_node); - sram_node = of_get_parent(sram_node); + while (sram_node && !of_node_name_eq(sram_node, "syscon")) { + sram_node = of_get_parent(sram_node); + } return sram_node; } static const struct supplier_bindings of_supplier_bindings[] = { -- Created with Armbian build tools https://github.com/armbian/build

Thanks for the pointers. Here is my patch (I tested it by dropping it into the right userpatches directory, compiling the kernel and then booting): From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001 From: Steinar H. Gunderson <steinar+kernel@gunderson.no> Date: Mon, 4 Nov 2024 15:35:38 +0000 Subject: Fix broken allwinner,sram dependency on CB1 On BigTreeTech CB1, the thermal sensor has an allwinner,sram property pointing to <&syscon>. However, Armbian has an out-of-tree kernel patch that creates dependencies based on allwinner,sram properties, which assumes that they point to sram nodes exactly two levels below the syscon node (instead of the syscon itself). This manifests itself as the thermal sensor refusing to load with a nonsensical error message: [ 23.775976] platform 5070400.thermal-sensor: deferred probe pending: platform: wait for supplier Note that it does not say _which_ supplier it is waiting for (the message ends in a space and then no supplier). The patch was unproblematic in the 5.6 megous patch set, where it was introduced, and in 6.6, which is current for Armbian, but in 6.8, the sun8i-thermal driver got mainlined, with this extra property compared to the out-of-tree version we used before (since it wants to clear a special bit at 0x300000 instead of relying on the firmware to do so before kernel boot). Fix by being a bit more flexible when we walk up the tree, so that we always stop at the syscon node. Tested on a Sovol SV08, which is CB1-based. Signed-off-by: Steinar H. Gunderson <steinar+kernel@gunderson.no> --- drivers/of/property.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/of/property.c b/drivers/of/property.c index 6fcfcda9d..f00f2b129 100644 --- a/drivers/of/property.c +++ b/drivers/of/property.c @@ -1368,12 +1368,13 @@ static struct device_node *parse_allwinner_sram(struct device_node *np, if (index > 0) return NULL; sram_node = of_parse_phandle(np, prop_name, 0); - sram_node = of_get_parent(sram_node); - sram_node = of_get_parent(sram_node); + while (sram_node && !of_node_is_type(sram_node, "syscon")) { + sram_node = of_get_parent(sram_node); + } return sram_node; } static const struct supplier_bindings of_supplier_bindings[] = { -- Created with Armbian build tools https://github.com/armbian/build I'm going to mark this as solved; I hope it can go upstream at some point. Note that I think the most sensible thing to do is still just to delete the patch in question, not to patch it further. But I don't understand 100% why it was added in the first place; maybe there is some reason that is still valid for some platform.

I think that if you don't want to just delete the patch (I don't think it makes much sense anymore), then maybe something like this, but I have no idea how to build a kernel from a worktree (i.e., without making a .patch by hand and running through the patch procedure): sram_node = of_parse_phandle(np, prop_name, 0); if (!of_node_is_type(sram_node, "syscon")) sram_node = of_get_parent(sram_node); if (!of_node_is_type(sram_node, "syscon")) sram_node = of_get_parent(sram_node); I.e., don't go walk the tree looking for the syscon node if we're already at it.

I removed the patch, and the resulting kernel booted and found its thermal zones. So I think the basic issue is that the patch just is doing of_get_parent() twice without checking that this makes sense. sesse@amalie:~$ uname -a Linux amalie 6.11.2-edge-sunxi64 #2 SMP Fri Oct 4 14:38:57 UTC 2024 aarch64 GNU/Linux sesse@amalie:~$ ls -l /sys/class/thermal/ total 0 lrwxrwxrwx 1 root root 0 Nov 3 20:28 cooling_device0 -> ../../devices/virtual/thermal/cooling_device0 lrwxrwxrwx 1 root root 0 Nov 3 20:25 thermal_zone0 -> ../../devices/virtual/thermal/thermal_zone0 lrwxrwxrwx 1 root root 0 Nov 3 20:25 thermal_zone1 -> ../../devices/virtual/thermal/thermal_zone1 lrwxrwxrwx 1 root root 0 Nov 3 20:25 thermal_zone2 -> ../../devices/virtual/thermal/thermal_zone2 lrwxrwxrwx 1 root root 0 Nov 3 20:25 thermal_zone3 -> ../../devices/virtual/thermal/thermal_zone3

I don't get it; isn't the problem the SRAM provider, not the configured trip limits? What am I supposed to look for here?

Maybe simply patches.megous/of-property-fw_devlink-Support-allwinner-sram-links.patch needs to go? There's nothing like it in the upstream 6.11 kernel, and it seems broken for the case where the DT links to <&syscon> directly instead of to a child of a child of it.

Could you be a bit more specific? Which part of the DTS is this? I'm looking through the difference in drivers, and seemingly the upstream driver has this snippet in the commit message: which explains why it has that “allwinner,sram” dependency (and why it silently refuses to load if I take it out). Specifically, the driver has a “.needs_sram” in the kernel. https://patches.linaro.org/project/linux-pm/patch/20240219153639.179814-6-andre.przywara@arm.com/ So why that handle isn't satisfied… I have no idea. (I'm definitely not well-versed in device trees.)

Yes, I tried (albeit without Docker, just regular cross-compiling), and it failed with https://paste.armbian.com/niyisiciqa . It seems there's some confusion somewhere as of whether the image is supposed to be compressed or not (I think maybe Arm does decompression somehow in U-Boot?), so vmlinux versus vmlinuz. I tried looking briefly into it, but figured it was easier just to wait it out on the board. 🙂

For fun, I hacked the DTB by removing this line (which is the only relevant thing that seems to be different between the 6.6 and 6.11 DTs): ths: thermal-sensor@5070400 { …more lines here… - allwinner,sram = <&syscon>; …more lines here… } After that, the driver loaded just fine (no kernel message, /sys/bus/platform/devices/5070400.thermal-sensor/waiting_for_supplier contains 0), but there are still no thermal zones in /sys/class/thermal. It seems that what really changed between 6.6 and 6.11 is that the h616 thermal drivers got upstreamed, so most of the Armbian patches have been obsoleted, but I guess in the process, something broke for the CB1.

Following up from another thread: I compiled an edge kernel (6.11.2-edge-sunxi64) for my Sovol SV08, in part because I'd like ftrace support (for perf sched). It comes up, except there is no /class/thermal/thermal_zone0/ (which Klipper demands to work, perhaps sensibly enough). dmesg says: [ 23.775976] platform 5070400.thermal-sensor: deferred probe pending: platform: wait for supplier It's a bit strange, since my understanding is that the full error message should be “wait for supplier XYZ”, i.e., some specific supplier. This was built with ./compile.sh kernel BOARD=bigtreetech-cb1 BRANCH=edge KERNEL_GIT=shallow and then a hack to use only -j2 (or the device will run out of memory during build). I installed both linux-image-edge-sunxi64 and linux-dtb-edge-sunxi64. The version is 4.11.0-trunk_arm64__6.11.2-S7aa2-D29ea-P5d78-C6b40H5c21-HK01ba-Vc222-Ba3b7-R448a (that's a mouthful). I modified the kernel config, but only to enable ftrace; I didn't mess with thermal or any other driver. armbianmonitor -u: https://paste.armbian.com/gokinaxefa

I installed the latest Armbian U-Boot, and lo and behold, the Ethernet came up! [ 14.058967] sunxi-gmac 5030000.ethernet end0: end0: Type(7) PHY ID 00441400 at 0 IRQ poll (5030000.ethernet-0:00) For posterity, this is what I did: sudo apt install linux-u-boot-bigtreetech-cb1-current sudo FORCE_UBOOT_UPDATE=yes bash -x /var/lib/dpkg/info/linux-u-boot-bigtreetech-cb1-current.postinst So I'm going to mark this as resolved. Next up is the thermal zone in that edge kernel, but I should probably do that in a separate topic…

Also: I don't use any updated U-Boot, just the one that came already installed with the BTT image. So I guess there's no special PHY init from there; I could probably get another eMMC card and flash the official Armbian image to check if that works? (That would take a week or two in the mail, though.)