prahal

Yes. BUILD_ONLY was necessary for the old armbian master branch. But it might not be anymore since with armbian-next build framework one passes "kernel" to compile.sh to tell it to build only the kernel. One can also pass "uboot", "kernel-patch", etc but they are not yet documented on the Armbian site. I guess hs200 is fine. In fact from what I saw all rk3399 boards had to revert to hs200 upstream and in Armbian. I believe that the test base was large enough to sort out if any issue was left over. But I am still on SD. https://github.com/armbian/build/issues/4761 < the DDR blob is required to have a "stable" memory (though I still get crashes though I always had, I cannot reproduce the error in the test case anymore. Just random kernel errors). I made a patch to keep most of mainline u-boot with only the Rockchip DDR blob but never sent it. Still chasing other bugs.

@ebin-dev I believe you mean the SD boot works fine. I am still unable to get emmc to write to work (though I run edge kernel).

For a few months, Armbian uses the new build system but the documentation has not been updated. Ie docker is autodetected and you pass a command to "./compile.sh" (ie "kernel" to build the kernel, "kernel-patch" to create a custom kernel patch then build the kernel, "u-boot" to build u-boot): ./compile.sh kernel BOARD=helios64 BRANCH=edge RELEASE=bookworm BUILD_ONLY="kernel" KERNEL_CONFIGURE=no BUILD_KSRC=no I had kept BUILD_ONLY="kernel" but it should not be needed anymore. Note I build for the "edge", you might want to leave the branch to the default that is "current". About the upgrade as helios64 is CSC (community supported) its kernel, u-boot, and board-specific packages can only be built locally and then installed so no streamlined upgrade process anymore. Though the other packages seem to follow the Debian release upgrade process. Mind if you upgrade the u-boot (and flash it to emmc), you want to tweak the helios64 u-boot build setup per: https://github.com/armbian/build/issues/4761#issuecomment-1646211095 this is to avoid the fact that currently u-boot ddr initialization is not correct for the helios64 LPDDR4 (at least we get random memory errors with plain u-boot and not when we restore the rockchip64 ddr initialization blob)

@iamdrqthanks for the feedback. So it is a "panel dsi code that is bit-to-bit compatible with the rockchip kernel" which is not aimed at ever being upstreamed? But isn't it opening the door to diverging from upstream definitely? I mean if the board definitions start to rely on such drivers that are not even proposed upstream because it is against their approved design, these boards will be harder and harder to upstream. I do not know Armbian policy. I am just used to Debian whose policy is to only accept patches to adapt programs to the distribution and patches that could eventually end up upstreamed. I am interested in understanding the policy of Armbian regarding such eternal divergences. If such patches are deemed good, then after replacing p->desc->bus_format by &p->desc->bus_format (well really bus_flags , though then the OF bus-format property should be renamed too to avoid confusion), a warning triggers: drivers/gpu/drm/panel/panel-simple-dsi.c: In function 'panel_simple_get_modes': drivers/gpu/drm/panel/panel-simple-dsi.c:310:66: warning: passing argument 3 of 'of_get_drm_display_mode' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 310 | ret = of_get_drm_display_mode(panel->dev->of_node, mode, &p->desc->bus_format, | ^~~~~~~~~~~~~~~~~~~~ In file included from ./include/drm/drm_crtc.h:32, from drivers/gpu/drm/panel/panel-simple-dsi.c:13: ./include/drm/drm_modes.h:509:66: note: expected 'u32 *' {aka 'unsigned int *'} but argument is of type 'const u32 *' {aka 'const unsigned int *'} 509 | struct drm_display_mode *dmode, u32 *bus_flags, | ~~~~~^~~~~~~~~

I found what a likely duplicate out-of-tree driver after investigating a warning from the kernel build: CC [M] drivers/gpu/drm/panel/panel-simple-dsi.o drivers/gpu/drm/panel/panel-simple-dsi.c: In function 'panel_simple_get_modes': drivers/gpu/drm/panel/panel-simple-dsi.c:310:73: warning: passing argument 3 of 'of_get_drm_display_mode' makes pointer from integer without a cast [-Wint-conversion] 310 | ret = of_get_drm_display_mode(panel->dev->of_node, mode, p->desc->bus_format, | ~~~~~~~^~~~~~~~of_get_drm_display_mode~~~~ | | | u32 {aka unsigned int} In file included from ./include/drm/drm_crtc.h:32, from drivers/gpu/drm/panel/panel-simple-dsi.c:13: ./include/drm/drm_modes.h:509:66: note: expected 'u32 *' {aka 'unsigned int *'} but argument is of type 'u32' {aka 'unsigned int'} 509 | struct drm_display_mode *dmode, u32 *bus_flags, | ~~~~~^~~~~~~~~ This code cannot work as is and a fix would be to add the missing ampersand before the p->desc->bus_format. Still other warning surface when this is fixed. This driver calls of_get_drm_display_mode against bus_format while panel-simple does against bus_flags (it also has bus_format but it passes it as an argument to drm_display_info_set_bus_formats). So it might well be that the driver would pass the wrong arguments. It has no documentation for its DTS parameters so it is hard to tell if bus_format should be set as bus_flags from the panel-simple documentation or if its user will end up sending bus_format as a bus_flags. There is already a dsi driver in upstream drivers/gpu/drm/panel/panel-simple.c (panel-dsi-simple while this one is panel-simple-dsi). So I wonder if there is a use in shipping two drivers for the same purpose. And there are no dts users of this out-of-tree driver panel-simple-dsi. The discussion about its introduction is in: https://github.com/armbian/build/pull/3140 It is told in the commit log to be a port of a rockchip kernel 4.4 driver, but panel-simple has dsi probe since v3.14. I am puzzled rockchip forked panel-simple instead of expanding it. Rockchip.DRM.Panel.Porting.Guide.pdf has no mention of the bus_format dts parameter so maybe this code path was never used and the buggy code affects no users. (a few dts parameters in the rockchip code are also not documented in this PDF). @iamdrq you are the author of this driver. Was there code missing in the dis support of panel-simple.c for dsi support, ie is panel-simple-dsi necessary? Was the aim to have a version of the panel dsi code that is bit-to-bit compatible with the rockchip kernel, so no porting was necessary? If features were missing could we bake them into the panel-simple.c driver (so they could be tested and one day be upstreamed)?

@Jens J. I believe you are after ./compile.sh kernel-patch which replaces CREATE_PATCHES=yes

@jmphilippe your issue is likely for which the workaround was working for 5.16-based kernel but not 6.3 sadly.

This was not fixed. Testing thoroughly on 6.3 the write path I can reproduce the cqhci errors. I don't understand why commits 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 and aea6cb99703e17019e025aa71643b4d3e0a24413 broke hs400 support on rk3399 (but as anybody disabled hs400 on rk339 at least nobody notice anymore).

If you turn out to need to compile u-boot you could build it without docker by just removing docker from the command I gave you (but you should be on a supported Armbian build distribution which is told to be Ubuntu Jammy - though I guess this is just the officially supported platform and a few others are fine too, cf https://docs.armbian.com/Developer-Guide_Build-Preparation/). But using the docker build target is not supposed to be difficult, you just have to install docker the run the command from https://docs.armbian.com/Developer-Guide_Building-with-Docker/ I gave you.

Yes, can be that the reason: it's possible keep poweron mechanical motor and turnoff and turnon electronic board as well as it's possible poweroff mechanical motor and keep turnon electronic board (this last case happen when put a pc in standby mode).... are You sure that kernel keep the power before reboot and helios64 U-Boot before turning off and after turning on hdd? As far as I remind the turn SATA power rails off then on sequence is U-Boot only. As U-Boot is not run on poweroff this sequence is not run on poweroff (poweroff managed by the kernel only).

I do not understand. Can you be more explicit?

sorry I meant dmesg | grep "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA" I cannot edit the post anymore.

the u-boot will be newer, but on the helios64-specific bits, nothing changed.

Did you ask for help? I believe the OMV wireguard plugin is not at fault as it does not mess with the kernel package. I guess that somehow your kernel 6 upgrade was incomplete and you rebooted. This breakage is recoverable but requires some time. OMV update web UI has to give the SUCCESS output else there might have been an issue. Best to verify no upgrade are left by refreshing the update package list ( I tend to upgrade via ssh, via "apt upgrade").

Yes. But there is no point (it will not fix the HDD noise and park issue).

no you cannot with armbian. At best you can keep a current and an edge kernel at once. This as the kernel packages have no version in their name (so the new linux-image-current-rockchip64 will overwrite the old one, but you can have linux-image-current-rockchip64 and linux-image-edge-rockchip64 installed at once). Note that when you have more than one kernel installed on an SD card you can easily switch from one to another by replacing the dtb, uImage and Image symbolic links in /boot on the SD card (if on eMMC you could do so from an SD card image you boot on to the eMMC /boot folder). For example in SD card /boot when you have: phn@helios64:~$ ls -l /boot/Image lrwxrwxrwx 1 root root 25 26 f?vr. 06:47 /boot/Image -> vmlinuz-6.1.11-rockchip64 phn@helios64:~$ ls -l /boot/uInitrd lrwxrwxrwx 1 root root 25 30 avril 20:15 /boot/uInitrd -> uInitrd-6.1.11-rockchip64 phn@helios64:~$ ls -l /boot/dtb lrwxrwxrwx 1 root root 21 26 f?vr. 06:18 /boot/dtb -> dtb-6.1.11-rockchip64 and also have: ls -ld /boot/*-5.15.93-rockchip64 -rw-r--r-- 1 root root 231898 18 f?vr. 00:48 /boot/config-5.15.93-rockchip64 drwxr-xr-x 6 root root 4096 26 f?vr. 06:15 /boot/dtb-5.15.93-rockchip64 -rw-r--r-- 1 root root 18699324 26 f?vr. 06:34 /boot/initrd.img-5.15.93-rockchip64 -rw-r--r-- 1 root root 6396749 18 f?vr. 00:48 /boot/System.map-5.15.93-rockchip64 -rw-r--r-- 1 root root 18699388 26 f?vr. 06:34 /boot/uInitrd-5.15.93-rockchip64 -rw-r--r-- 1 root root 30609920 18 f?vr. 00:48 /boot/vmlinuz-5.15.93-rockchip64 you can: cd /boot ln -sf vmlinuz-5.15.93-rockchip64 Image ln -sf uInitrd-5.15.93-rockchip64 uInitrd ln -sf dtb-5.15.93-rockchip64 dtb this is to boot on kernel 5.15.93 instead of the previous 6.1.11.

@n3o note that I did not tell you to upgrade the u-boot. I told you a fix in U-boot would be the proper fix. But this patch does not exist. I only told you how to update it as you asked.

I myself run bullseye with an edge kernel, u-boot, and armbian-bsp (in fact everything that was build by the now obsolete KERNEL_ONLY=yes option to compile.sh. Now replaced by BUILD_ONLY="u-boot,kernel,armbian-config,armbian-zsh,plymouth-theme-armbian,armbian-firmware,armbian-bsp". There could be a sysfs or device path rename that breaks armbian scripts. At one time we had the fan path that changed. But this is with kernel packages. u-boot one only matters to the kernel. That is the location and name of the dtb in /boot matters, though I have not heard of anything changing in that regard for a long while (not an u-boot issue per se but more an armbian u-boot configuration issue). So if one day you have an issue due to a mismatch between u-boot, armbian configuration and script, and the kernel you can pretty easily revert (though it requires learning to rewrite the u-boot). You can extract the steps from the armbian script that does the job when you run the armbian tool /usr/sbin/nand-sata-install: /usr/lib/u-boot/platform_install.sh mostly its write_uboot_platform function: if [[ -f $1/rksd_loader.img ]]; then dd if=$1/rksd_loader.img of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1; else if [[ -f $1/u-boot.itb ]]; then dd if=$1/idbloader.img of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1; dd if=$1/u-boot.itb of=$2 seek=16384 conv=notrunc status=none > /dev/null 2>&1; else if [[ -f $1/uboot.img ]]; then dd if=$1/idbloader.bin of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1; dd if=$1/uboot.img of=$2 seek=16384 conv=notrunc status=none > /dev/null 2>&1; dd if=$1/trust.bin of=$2 seek=24576 conv=notrunc status=none > /dev/null 2>&1; else echo "Unsupported u-boot processing configuration!"; exit 1; fi; fi; fi where $2 is the device file where you want to install U-Boot. nand-install-script get it via: partition="$(sudo blkid | tr -d '":' | grep "$(sed -e 's/^.*root=//' -e 's/ .*$//' < /proc/cmdline)" | awk '{print $1}')"; echo "${partition::-2}" which is the device where your kernel has its root partition setup. But if you want to restore u-boot on eMMC from an SD card image this will give you /dev/mmcblk0 (which is the SD card) instead of /dev/mmcblk1 (the eMMC ). So as this script does the command to write the u-boot from the command line will depend on the format of the u-boot in the package. For linux-u-boot-helios64-edge 23.02.0-trunk: ls /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 idbloader.img u-boot.itb that is /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 contains u-boot.itb so the command are: dd if=$1/idbloader.img of=$2 seek=64 conv=notrunc status=none > /dev/null 2>&1; dd if=$1/u-boot.itb of=$2 seek=16384 conv=notrunc status=none > /dev/null 2>&1; with $1 equals /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 and $2 equals the target device file to write u-boot to (here for emmc /dev/mmcblk1 and for the SD card /dv/mmcblk0). Which gives to write to the eMMC when rescuing from an SD card on helios64: dd if=/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/idbloader.img of=/dev/mmcblk0 seek=64 conv=notrunc status=none dd if=/usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/u-boot.itb of=/dev/mmcblk0 seek=16384 conv=notrunc status=none If you want to write to the SD card you could even write the u-boot from a PC via an SD card reader. You will then have to get the u-boot binaries from your deb package (a deb package is a compressed tar archive) and on your PC replace the of=/dev/mmcblk0 by the device file your card reader exhibits the SD card as.

lastest linux-u-boot-helios64-edge published was 22.02.1. I built linux-u-boot-helios64-edge 23.02.0-trunk locally by cloning Armbian build repository https://github.com/armbian/build/: git clone https://github.com/armbian/build.git cd build ./compile.sh docker BOARD=helios64 BRANCH=edge BUILD_ONLY="u-boot" RELEASE=bullseye KERNEL_CONFIGURE=no That is I build inside a docker container (as I am on Debian which is not an officially supported build host. If you want to also compile the kernel add ",kernel" to BUILD_ONLY, see https://docs.armbian.com/Developer-Guide_Build-Options/ You will then have your packages in the build/output/debs/ directory. Copy them to your helios64 and install with "dpkg -i <deb>".

This is shell agnostic but you miss the program name "grep" after the pipe so you should: dmesg | grep "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA" or as dmesg is a ring buffer and early message could end up lost): journalctl -k -b | grep "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA"

@liberodark I had HDD not detected twice (on SATA connector the previous one was working before). Unplugging and then replugging the hard drive multiple times ended up working. I read that someone (I do not have the link at hand but likely on the Armbian forum) had this fixed by cleaning the connectors of the SATA harness (on the HDD side) with alcohol. Maybe alcohol is not required, and simply rubbing the connectors with a cloth is sufficient (it could even be on the HDD connector's side). I did not tried the alcohol on my side as simply replugging a few times did the trick. I put pressure while plugging the HDD in. It may not be necessary to put pressure while plugging but if cleaning the connectors does not help it might be that the SATA data socket does not fit perfectly with the HDD SATA data plug. Hard to tell without further testing. Try with care and if it still does not work tell it here.

I tried a more extensive test with all armbian (and the above regulator ones above) patches removed (patches removed for an unrelated test) and the test failed CQHCI. I still have to try the extensive test with devm patch applied and also with the above patchset fixed to apply to armbian kernel 6.1.12. The read test works: dd if=/dev/mmcblk1 of=/dev/null bs=16M iflag=direct 931+1 enregistrements lus 931+1 enregistrements écrits 15634268160 octets (16 GB, 15 GiB) copiés, 65,3501 s, 239 MB/s but with emmc part1 mounted on /mnt, the write test fails: sudo dd if=/dev/sda of=/mnt/test2.dat bs=16M count=500 oflag=direct dd: erreur d'écriture dans '/mnt/test2.dat': Erreur d'entrée/sortie 1+0 enregistrements lus 0+0 enregistrements écrits 0 octet copié, 0,856469 s, 0,0 kB/s with error: [ 2240.820878] mmc1: running CQE recovery [ 2240.824858] ------------[ cut here ]------------ [ 2240.825339] mmc1: cqhci: spurious TCN for tag 12 (...)

@n3o I use ssh to check Power-Off_Retract_Count about the Odroid shutdown script I do not know if '--idle-unload' is needed. But the script already works. The only issue is that it does not run in U-Boot space (on U-Boot reset) or even when the kernel crashes. SO I believe this is only a bandaid. A proper fix should be made in the helios64 U-Boot code. About the U-boot. No U-Boot is not updated on a kernel upgrade (U-Boot is like the BIOS). It is not even updated when you upgrade the u-boot package linux-u-boot-helios64-current (or linux-u-boot-helios64-edge if runnign armbian edge). You have to run armbian-config, choose "System", then "Install" then finally "5 Install /Update the bootloader on SD/eMMC" (or short, run nand-sata-install and choose "5 Install /Update the bootloader on SD/eMMC") and even then if you run Armbian on an SD card it will update the U-Boot on the SD card but not on the eMMC. And I believe Helios64 boots on the eMMC U-Boot even if an SD card is installed (you can add a jumper on the board to switch to SD card boot but it is not the default), so the previous U-Boot update command will have no effect on user with an SD card root. To me in such case you have to run in (valid for in a Bourne shell) (you have to replace the placeholders!): source /usr/lib/u-boot/platform_install.sh write_uboot_platform <your uboot directory> <your emmc device file> You can find the emmc device by: dmesg | "mmc.*: SDHCI controller on fe330000.mmc \[fe330000.mmc\] using ADMA" if you see mmc1 then the eMMC device will be /dev/mmcblk1 to get the u-boot directory, first find you u-boot debian package: dpkg -l "linux-u-boot-helios64*" Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais) ||/ Nom Version Architecture Description +++-==========================-=============-============-================================= ii linux-u-boot-helios64-edge 23.02.0-trunk arm64 Uboot loader 2022.07 in the result you see linux-u-boot-helios64-edge, then run "dpkg -L <your u-boot debian package name>: dpkg -L linux-u-boot-helios64-edge | grep /usr/lib/linux-u-boot- /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/idbloader.img /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64/u-boot.itb then you know your u-boot directory name is /usr/lib/linux-u-boot-edge-helios64_23.02.0-trunk_arm64 which gives for an edge u-boot for armbian 23.02.0 install with an emmc on /dev/mmcblk1: write_uboot_platform /usr/lib/linux-u-boot-current-helios64_23.02.0-trunk_arm64 /dev/mmcblk1 you can replace the write_uboot-platform call with its commands you can read in /usr/lib/u-boot/platform_install.sh but they vary. Last about the U-Boot version I believe you can only get the currently installed version from the serial console log when the box startup. Maybe you could read the storage blocks where U-boot is stored but this is hard to guide through. For the above setup, it would give : sudo strings /dev/mmcblk1 |grep "U-Boot" U-Boot TPL 2022.07-armbian (Feb 15 2023 - 11:06:06) U-Boot SPL 2022.07-armbian (Feb 15 2023 - 11:06:06 +0000) U-Boot FIT image for U-Boot with bl31 (TF-A) U-Boot (64-bit) %U-Boot (...) which will give U-Boot version 2022-07-armbian (the date is new because it is an U-Boot install of a local build Armbian build). Note you should terminate the above command before it completes else it will read the whole storage which can take a while (this with Ctrl+C). About the HDD noise. Do you really get it on poweroff? Here it only happens on power on from reboot. Poweroff does not call into U-Boot. So maybe the issue is with your parking head timer removal being at fault or something specific you did. And nothing in code could help with that be it kernel or U-Boot. That is if you prevent the head from being parked by the kernel before it turns the power off then this might be a case where Retract Count will happen and only a custom script like the Odroid one could help you workaround the issue with your tweaking. I find "HDD noise and Power-Off_Retract_Count" being independent really weird. But I noticed it (but only in a specific process ... maybe it was not exactly the *same noise* in that it indeed make a similar noise but maybe the head had more time to park. As told above I was able to reproduce it though with a very specific process told above but not always (as I added in an edit of the above post I can not always reproduce so maybe you missed it). Also, I believe the Retract Count increasing only happening on power on from reboot is due to the power being kept on by the kernel on the HDD on reboot and the helios64 U-Boot code turning them off before turning first rails A HDD on then rails B HDD on. Maybe Retract Count only happens because the head has no time to park before being turned on. Though that is unlikely as both rails A HDDs and rails B HDDs get their retract count increase while rail B has a bigger delay before being started up (but maybe this delay is still too short, this requires work to find out). Also, the head should be parked on poweron from reboot per kernel somehow does not trigger this parking on reboot and the U-Boot helios64 code turns their power off on boot (thus the HW triggered head parking on no power). I believe parking the head on the off case is not safe (the kernel can crash and then the head will not be parked whatever the script of kernel code). This has to be done before turning their power off in the U-Boot (per the helios64 has to turn only one rail on before the other it has to turn at least one off at boot. Maybe it could turn off only one instead of turning both off then turn one on and then the other, but that will still increase the Retract Count for the HDD on the rail it turned off which is not great). About a recording of the noise I cannot do it right now but I will try when time permits. But I believe the noise only depends on the hardware involved but there will always be noise. It turns out I have a mix of WD30EFRX and WD60EFZX so the noise should be pretty close to yours. I will still provide mine if and when time permits. Could you also share a recording of the noise you get? Note that USB HDD does not need handling with helios64. They are already turned off when needed. The only issue is with PCIe SATA HDD on helios64. Because U-Boot turns them off on startup. If they are already off (because one poweroff the helios64) that is not an issue as they are already off and parked. Only when reboot they are not turned off and then the HDD park with their firmware because their power has been turned off by U-Boot to keep enough power to turn the HDD on (which make me believe a simple fix would be not to turn off then on the rails in case of reboot because ... well the HDD are already on, no need to take into account that we do not have enough power to turn them all on at once by powering rails 1 then rails B). I start to believe you made a tweak with wdidle that is wrong for the hardware (or at least not supported by Linux kernel) because you get the noise on poweroff. So someway you are preventing the kernel to park the head on poweroff thus it is logical that you get an HW head parking triggered by no power to the HDDs. Having this wdidle setting supported is not a downstream issue (Armbian), this is an upstream feature request. Armbian could develop it if they can. This could even be rejected by upstream as an unsupported configuration. Hard to tell. But it would definitely not be a bug. You cannot mix any combination of hardware settings. These even have to be supported by the other hardware on the HW platform. I believe if you make the same tweak you did with wdidle to USB enclose the same noise and parking head issue will arise. But this is due to the setting, not a bug in the kernel or U-boot I guess. Can you reproduce the HDD noise on poweroff without any wdidle tweak?

It turns out I only had one of the above patch applied: Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0001-regulator-devres-Add-devm_regulator_bulk_get_exclusi.patch info Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0002-regulator-core-fix-unbalanced-of-node-refcount-in-re.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0003-regulator-core-use-kfree_const-to-free-space-conditi.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0004-regulator-core-fix-use_count-leakage-when-handling-b.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0005-regulator-core-fix-module-refcount-leak-in-set_suppl.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0006-regulator-core-fix-resource-leak-in-regulator_regist.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0007-regulator-core-Use-different-devices-for-resource-al.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0008-regulator-core-Fix-resolve-supply-lookup-issue.patch failed wrn Displaying message: * [\e[33mu\e[0m][\e[32mc\e[0m] p-0009-regulator-core-fix-deadlock-on-regulator-enable.patch failed wrn and one that is unrelated. So I would say that armbian edge should do for hs400es on rk3399. Though if I remove: assigned-clock-rates = <150000000>; from the dts (which falls back to rk3399.dtsi value which is 200000000) I get the old error:

Made a test case that reproduces the issue: $ cat test-pkg_resources.py import pkg_resources print(pkg_resources.parse_version("2.3")) $ for i in $(seq 1 100);do python3 test-pkg_resources.py ;done 2.3 2.3 2.3 double free or corruption (out) Abandon (core dumped) 2.3 The kernel error I had where from failure to allocate (but as those errors stack trace shows it is a failure to allocate memory of a high order (big chunks) for the core dump generation).