prahal

Did you modify the governor and it's frequencies in armbian-config ? Else on reboot armbian boot scripts will reset to the armbian-config set value. In my case to avoid random successful boots because of timing I set the governor in /boot/armbianEnv.txt on the kernel command. This so I can better reproduce my bug and avoid success because the governor was set late on the boot sequence by the armbian scripts.

@BinaryWaves This looks like the uboot boot proceed so the kasrlseed command is like is told in https://github.com/armbian/build/pull/4352 , ignored if not supported by your uboot version. After "Starting kernel" you get "Give root password:". To me this means there was an error after the Linux kernel booted, probably the filesystem detected an error and you will have to login with the root password and fsck the filesystem manually. Reading the backlog it looks like you have the same state on the SD that you had with the emmc. As explained in the following post if you do not know the root password, pass "emergency" to the kernel command line. Though isn't the root password the one that you set at first boot (maybe it is with OMV installs only)? If not you should be able to find the default armbian root password on the forum.

If you have SD card you could install an image to the SD and chroot to the emmc install to diagnose (fsck, etc) I would have thought of a HDD filesystem repair but I do not think a Ctrl+D from a serial console could interrupt an fsck (but I never tried). Such an fsck can take a while. It could also be a mdadm raid resync or rebuild. You can check with cat /proc/mdstat When you said you borked your emmc install could you have pressed teh reset or poweroff button? That would point to an fsck/mdadm resync taking ages. What is your setup an mdadm raid? Which filesystem is your data on? I do not think the emmc OS filesystem is borked as Ctrl+D is enough to give you a working boot.

@n3o have you sorted out if the smartctl issue was due to the missing "-d sat" option? Do you have an ssh session to your helios64? As I told you could rebuild the bookworm smartmontools package for Bullseye if need be. It is a little bit involved though.

I believe your issue is that with the USB-C UGREEN 5 bay enclosure SMART data display in OMV times out after 4 minutes (and that you are afraid there could be corrupt files during transfer to the enclosure related to this issue). I don't know about such an issue (USB to SATA adapter be it RAID or not) taking more than 4 minutes to reply to a SMART data request. So I suggest you to login to the Helios64 (ssh) if you know how to do this and run smartctl on the UGREEN device smartctl -i </dev/...> where the device is /dev/sdc and /dev/sdd in the logs you posted (you could also use the more easily identifiable /dev/disk/by-id/<...device>. I see two unexpected things in the logs: usb 2-1.2: Product: Ugreen Storage Device (...) [ 242.742731] usb 2-1.2: reset SuperSpeed USB device number 4 using xhci-hcd [ 117.252293] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 117.252310] GPT:27344699391 != 27344764927 [ 117.252318] GPT:Alternate GPT header not at the end of the disk. [ 117.252321] GPT:27344699391 != 27344764927 [ 117.252325] GPT: Use GNU Parted to correct GPT errors. [ 117.252344] sdc: sdc1 the issue seems to be related to smartmontools https://forum.odroid.com/viewtopic.php?t=37153 "reset SuperSpeed USB device number 3 using xhci-hcd" - only if smartmontools are installed . (note he at first misspelled smartmontools as sysmontools it seems). Note he tells his UGREEN USB3-SATA adapter works but it could be your enclosure as a different controller than yours. Was your usb-c cable to the enclosure provided with the enclosure? A power issue with a weak cable could also cause such a reset (though your external power adapter to the enclose likely removes the power issue so it leaves the cable) ? Likely an issue with your enclosure and smartmontools. Might be that there is a workaround in smartmontools that could be automatically set up by OpenMediaVault. Or also could be that smartmontools could implement a workaround for your enclosure. The kernel can implement workarounds for nonstandard controllers, which might help avoid smartmontools confusing the enclosure controller (ie disable UAS). You might as well contact UGREEN and/or the smartmontools mailing list. The bridge chip for the USB SATA bridge seems to be JMicron "Gen1 SATA 6Gb/s Bridge" (USB idVendor=152d, idProduct=0576). Which seems supported for a long time https://linux-hardware.org/index.php?id=usb:152d-0576 (also in BSD https://bsd-hardware.info/?id=usb:152d-0576) The chip is told to be JMS576 https://www.smartmontools.org/ticket/1428 This chip had a fix post smartmontools 7.2 https://www.smartmontools.org/ticket/1428 (probably 7.3) . You can try if the workaround works by calling the device with: smartctl -d sat -i /dev/sdc Note the "-d sat". About kernel workaround, you might want to try to force usb-storage driver instead of UAS driver in /boot/armbianEnv.txt usbstoragequirks=152d:0576:u from https://forums.raspberrypi.com/viewtopic.php?t=338883#p2029597 With this tweak in the kernel logs, you should now have "UAS is blacklisted for this device, using usb-storage instead" About the GPT header error, I do not expect these to explain a slowdown during SMART retrieval (as this is not related to the partitions). EDIT: your Armbian 22.02.1 is bullseye which has smartmontools 7.2. Once you have checked that the issue is no more with "smartctl -d sata -i <device>" you will know the culprit. You can either rebuild the smartmontools package with the patch above for JMS576 or plan an upgrade to bookworm (smartmontools 7.3 has the fix per https://www.smartmontools.org/browser/tags/RELEASE_7_3/smartmontools/drivedb.h#L5936 ) . You cannot directly install the bookworm package on bullseye because it depends on bookworm libc6. But you may be able to rebuild the bookworm source package on bullseye (did not check from https://sources.debian.org/src/smartmontools/7.3-1/debian/control/ if any of the build dependencies are only available on bookworm though).

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"