Heisath

Hi, I just tested this on my helios4 with linux kernel 5.15.80 uname -a: Linux helios4 5.15.80-mvebu #22.11.1 and both pwm controllers work just fine. Have you tried going back to make sure it is not a HW problem? Or tried swapping fans around? Also make sure your /dev devices symlink to the correct path: /dev/fan-j10 -> /sys/devices/platform/j10-pwm/hwmon/hwmon3 /dev/fan-j17 -> /sys/devices/platform/j17-pwm/hwmon/hwmon4 EDIT: I just did a fresh build from armbian master, 23.02.0-trunk. PWM on both channels working fine. uname -a Linux helios4 5.15.88-mvebu #trunk SMP Sat Jan 14 13:47:38 CET 2023 armv7l GNU/Linux So you'd need to provide more info on how you built your kernel version to get to this problem.

From the error messages I would expect it to be the card. I have a similar problem but mine is a worn out sd card slot, so I just boot from a different medium now.

Ok I will try to reproduce and look at the patch. Does anyone else experience the same? 5.15 has been out for a while.

Ok I checked this and there is no uboot config for 2019 uboot helios4 which has SATA support enabled. Not sure how to best go forth here.

Ok I'll look into it this afternoon.

ClearfogPro and Helios4 images are working ok. ClearfogBase I expect to do the same (not explicitly tested). @TheLinuxBug one improvement for the testing form would be a checkbox for "does not apply" on the feature section. My boards don't have wireless but no options really matches

Yeah that should be no problem. Just compare these two files: (Clearfog configuration) https://github.com/armbian/build/blob/master/config/sources/families/include/mvebu-clearfog.inc (Helios4 configuration) https://github.com/armbian/build/blob/master/config/sources/families/include/mvebu-helios4.inc Just provide a PR with added targets here https://github.com/armbian/build/blob/master/config/sources/families/include/mvebu-helios4.inc#L11 Test it by building locally and we'll have sata uboot on the next release.

Good to know. I am currently bringing mvebu-edge to 6.0.y, but that will take a bit more time.

PR is fine. Just adjust the config, test it and make PR. Even these small things help. As for why it is not in the kernel atm probably nobody added it

@Dee2022 yeah and a fix is already on the way - read the posts above yours

Need review and actual testing on HW https://github.com/armbian/build/pull/4275

Hey. Yeah I noticed this problem already, see https://github.com/armbian/build/pull/4261 Unfortunately I did not get around to fix it last weekend, working on it right now As for future proofing, unless someone has the energy to get the patches mainlined it will break from time to time...

Great - btw. why are you using this old uboot? Current armbian has uboot 2018 and linux kernel 5.15 where all this stuff works ootb. Download here: https://www.armbian.com/clearfog/ See sources here: https://github.com/armbian/build/blob/31ac6383e1ac7ebddd0813abc0f1f9632a9c9c40/config/sources/families/mvebu.conf#L18-L20 https://github.com/armbian/build/blob/31ac6383e1ac7ebddd0813abc0f1f9632a9c9c40/config/sources/families/include/mvebu-clearfog.inc#L7-L8

Yeah you need to UP eth1. You can even see this in your Arch listing, the lan ports are @eth1. Vs in your armbian listing eth1 is down so the dsa is unreachable. Example ip config via /etc/network/interfaces: # Loopback auto lo iface lo inet loopback # eth0 wan allow-hotplug eth0 iface eth0 inet manual # eth1 switch dsa port auto eth1 iface eth1 inet manual # eth2 sfp port allow-hotplug eth2 iface eth2 inet manual # lan ports (dsa) auto lan1 lan2 lan3 lan4 lan5 lan6 iface lan1 inet manual iface lan2 inet manual iface lan3 inet manual iface lan4 inet manual iface lan5 inet manual iface lan6 inet manual # bridge for local ports auto br0 iface br0 inet static bridge_ports eth2 lan1 lan2 lan3 lan4 lan5 lan6 address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.2 dns-nameservers 1.1.1.1 1.0.0.1 Clean armbian images are using network manager and should have working switched lan ports ootb.

Thanks

I'd guess this https://github.com/rpardini/armbian-git-shallow/blob/6398b50d9ab1fbf9856f93203e10221e97903148/shallow_kernel_tree.sh#L49 takes care of repetitive downloads.

The cpufreq patches have not made it to mainline and our patches cause the driver to misbehave (as stated earlier). You can try the 800- patch series from here https://github.com/armbian/build/tree/master/patch/kernel/archive/mvebu-4.19/disabled Maybe they work now - but I don't think so.

Replying for mvebu: clearfogbase: http://ix.io/3Yh0 clearfogpro: http://ix.io/3YgX helios4: http://ix.io/3Yh2 (all tested with full hardware, SFP, SATA, Wifi, Bridge; just tested debian bullseye_current_5.15.35)

I will run mvebu tests tomorrow. Sorry for not being available for the meeting, turns out, building a house is a pretty major thing...

No I do not think so. The hardware is nearly the same - base is just pro with removed devices.

Yeah it is totally possible. Generally just follow official debian upgrade instructions. Which come down to making sure you have a clean install (apt update, upgrade, autoremove, clean), then upgrading the apt.source (replacing buster with bullseye) then upgrading via apt update, apt full-upgrade etc. Need to fix conflicts along the way. https://linuxize.com/post/how-to-upgrade-debian-10-to-debian-11/ Also adjust armbian apt sources if neccessary.

https://github.com/armbian/build/pull/3498

Above seems like a general armbian problem, not ebin specific. @lanefu you did something https://armbian.atlassian.net/browse/AR-445 Maybe it is not enough?

Newest please - don't want to keep the old stuff around.

I think the uboot and atf should be built with aarch, the wtmi with gnueabi. See: https://gitlab.nic.cz/turris/mox-boot-builder