prahal

@ebin-dev well sorry I meant that emmc write with hs400 mode reenabked with a local patch is still broken. But indeed all rk3399 boards reverted to hs200 in kernel, Helios 64 first included the workaround (down to hs200) in Armbian 21.08.2. The first armbian helios64 kernel to ship the broken kernel was with the 5.10.60 Linux kernel. Emmc was and is stable in hs200 mode, my writing issue is with hs400 post 5.10.60.

@ebin-dev the armbian policy did not change, the status of the helios64 port did. It is now community maintained meaning the board packages are not provided by armbian (I believe if someone step up as maintainer, meaning he tests the armbian releases, helios64 armbian builds would be reumed).

Are you sure it was not hung after "Start kernel Give root password:" ? This is not uboot but the OS (probably feck failed and the OS booted in single use mode). Maybe the armbian fan script could be improved to lower the fan speed when entering single user mode. The only case when full fan speed could not be tweaked is when bootingbor shutting down with the default armbian fan config max speed at max and the kernel crashes. If the filesystems are not critical, to workaround the single user mode full fan speed waiting for you to fsck the filesystem, you could set fsck to attempt to repair all filesystem errors on its own with "fsck.repair=yes" https://www.systutorials.com/how-to-force-a-fsck-during-next-rebooting-of-linux/ I do so on a few boxes as either way, when I feck manually I reply yes to all questions ... but I have nothing that critical.

Ctrl+d is not supposed to boot without password. Just to boot with the default runlevel when you are in single user mode. Single user mode is the default runlevel when fsck failed or such bot errors. If you do not know the root password you can pass "emergency" to the kernel (or even more brute force "init=/bin/bash"). To pass this to the kernel you can halt the uboot boot, then enter: setenv extraboardargs "emergency" Then enter "boot". (Or "run bootcmd_mmc0/1 to force bootimg the Linux kernel from emmc or ad as I explained here Note the jumper is to force the helios64 to load uboot from either emmc or sd. From either of these uboot boots you can after you halter this uboot boot start the OS including the kernel from either emmc or sd via the above "run bootcmd_mmc0/1"). Booting u-boot and the OS from the same media is not hardcoded. Still you have to remove the jumper for the emmc to be visible from u-boot/OS. So you cannot do all possible combinations of jumper and uboot prompts. Note that you can also add the emergency or "init=/bin/bash" to the kernel commandd line by writinyto the OS partition /boot/armbianEnv.txt (for an SD card just moun tit on another computer and for the emmc you may be able to mount the emmc via usb-c via the P13 jumper iè recovery mode https://wiki.kobol.io/helios64/jumper/#usb-consolerecovery-mode-p13 but I never tried, it is told to enabled flashing, maybe one cannot mount)

It is perfectly fine but I believe you have to stop u-boot boot in between your jumper changes or at least that is what I do. To stop u-boot you press a key durimg uboot boot (I believe just before it detect the storages, better press the key multiple times during uboot boot). You press the key on the serial console. Then remove the jumper and enter "boot" on uboot prompt (I might be mistaken though I believe "boot" does the job, else search for "run bootcmd_mmc1" or "run bootcmd_mmc0" on the armbian forum, I believe in ubooc0 is the emmc and mmc1 is the sf card). This so the jumper is removed before the Linux kernel probe the hardware. You might be able to remove the jumper after boot and do the drive probes later with kpartx but I never tried. Also you can remove the jumper after uboot prompts and still boot to SD card then fsck and mount the emmc OS partition and then chroot to it and do whatever you want as if it was the current OS (note that before chroot you have to bind mount /dev, /sys and /prox from the current root partition to the emmc mount point, else any programs will not work).

This a user modifiable setting, though I trust the Kobold team choice to setup the armbian fan config to set the fan full speed at boot and shutdown. If you have nothing critical and nothing that gets hot in the helios64, you could lower the max speed in the config file (sorry I forgot it's location or if it can be tweaked by an arm Ian program)

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").