Helios64 u-boot does not build anymore after we bumped to 2022.07

[prahal]

On 5/17/2023 at 4:04 PM, n3o said:

it's possible add an option to keep stored on sd kernel 5.15.93 in case of issues?

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.

[prahal]

13 minutes ago, n3o said:

Can I use U-boot 23.02.0 both with kernel 5.19.53 that 6.2.0?

 

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

[prahal]

On 5/17/2023 at 4:04 PM, n3o said:

Some month ago I have installed from open media vault wireguard plugin, but I don't know why the installation break after update to linux kernel 6 and I must reinstall all from begin . I have make a backup of microsd image a week ago, but I don't want repeat the fail

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

[prahal]

26 minutes ago, n3o said:

change something from linux-u-boot-helios64-current 23.02.0-trunk to linux-u-boot-helios64-edge 23.02.0-trunk

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

[prahal]

On 5/18/2023 at 6:40 PM, n3o said:

 

I don't know use docker, can You compile u-boot only?

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.

[ebin-dev]

@prahal@balbes150 I just gave it a try and built a complete bookworm image (Armbian_23.08.0-trunk_Helios64_bookworm_current_6.1.49.img and corresponding linux 6.1.49 deb packages). The bookworm image boots without any issues. Thank you very much for your contributions!

 

Now there should be an upgrade path from Debian bullseye to bookworm once linux is upgraded to 6.1.49. If that does not complete successfully I will set up the whole system starting from the fresh bookworm image.

 

git clone https://github.com/armbian/build.git

cd build

./compile.sh BOARD=helios64 BRANCH=current  RELEASE=bookworm KERNEL_CONFIGURE=no

 

P.S.: There is a more recent update on armbian.com/helios64

Edited September 7, 2023 by ebin-dev

[prahal]

On 8/12/2023 at 11:14 PM, ebin-dev said:

Now there should be an upgrade path from Debian bullseye to bookworm once linux is upgraded to 6.1.45. If that does not complete successfully I will set up the whole system starting from the fresh bookworm image.

 

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)

[prahal]

On 8/12/2023 at 11:14 PM, ebin-dev said:

The bookworm image boots without any issues.

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

[ebin-dev]

12 hours ago, prahal said:

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

 

That`s right - I am running bookworm off SD, since my bullseye system is still present on emmc.

 

The effect of omitting the "BUILD_ONLY" option in the compile instruction is simply that everything is being compiled from sources such that the bookworm image is compiled too. And 'current' was used, since bookworm was designed to operate with that version of linux.

 

A short test using 'hdparm -tT /dev/mmcblk1' #emmc indicates that emmc access speed with linux 6.1.45 is around 120MB/s (hs200), about half of what it used to be with linux 5.10.43 (220 MB/s = hs400).

 

I can live with that, but before I copy the bookworm system from sd to emmc, could you please confirm that linux 6.1.xx can safely be used to read and write emmc using the slower hs200 mode ?

 

P.S.: Regarding u-boot: before I became aware of your warning I already flashed the u-boot binaries to emmc using the blobs that came with the fresh bookworm image. emmc was still bootable and I did not oberve any issues. To be on the safe side, I reverted back to the original blobs present in my original bullseye image.

Edited August 20, 2023 by ebin-dev

[prahal]

On 8/20/2023 at 12:16 PM, ebin-dev said:

The effect of omitting the "BUILD_ONLY" option in the compile instruction is simply that everything is being compiled from sources such that the bookworm image is compiled too. And 'current' was used, since bookworm was designed to operate with that version of linux.

 

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.

 

On 8/20/2023 at 12:16 PM, ebin-dev said:

A short test using 'hdparm -tT /dev/mmcblk1' #emmc indicates that emmc access speed with linux 6.1.45 is around 120MB/s (hs200), about half of what it used to be with linux 5.10.43 (220 MB/s = hs400).

 

I can live with that, but before I copy the bookworm system from sd to emmc, could you please confirm that linux 6.1.xx can safely be used to read and write emmc using the slower hs200 mode ?

 

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.

 

On 8/20/2023 at 12:16 PM, ebin-dev said:

P.S.: Regarding u-boot: before I became aware of your warning I already flashed the u-boot binaries to emmc using the blobs that came with the fresh bookworm image. emmc was still bootable and I did not oberve any issues. To be on the safe side, I reverted back to the original blobs present in my original bullseye image.

 

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.

Edited October 13, 2023 by prahal

[BinaryWaves]

@prahal It's been a while since I checked in here. I recently moved and my system has been running stable over:

 

OS: Armbian (23.8.1) aarch64 
Kernel: 6.1.50-current-rockchip64 

 

But have an odd issue with samba and at one point I think I borked my emmc install and the boot freaks out whenever I attempt to boot. Boot will get to kernel load or I think where its trying to figure out boot partition stuff then it will hang and have the fans blasting full speed until I can connect my laptop to it over the serial console and run Crtrl+D to advance to skip the maintenance. I am not adept enough to handle this entirely but I might give it another go here seeing as there was a build for bookworm! I would love to try and upgrade and redo my helios again with an updated image and fix the issues ive been having.

 

@prahal thank you for your work and keeping my beloved home nas alive <3 Please message me if there is anything I can do to help your efforts

 

Edit: I am performing a backup of my NAS now. I will attempt to perform and document my upgrade process sometime this week or weekend at the latest

Edited October 15, 2023 by BinaryWaves

[ebin-dev]

@prahal Thank you for the hints !

 

The helios64 bookworm image 23.05.4 with kernel 6.1.36 includes the mainline driver r8152 and I have tested it with both LAN interfaces 1G and 2.5G - it is stable and performs nicely.

However, I could  not find any matching header files for download for that kernel version: they are necessary for the dkms used on my system. Would you know a source for them (version 6.1.36) ?

 

Unfortunately later linux versions include a regression (dwc3 usb issue) so we lose access to our USB devices i.e. using linux 6.1.50 ...

 

Compiling current kernels and temporarily patching them to get rid of the dwc3 usb issue works, but I have the impression that I am using the wrong branch, since there are so many issues with the existing patches for rockchip64 (armbian VERSION file:  23.08.1-trunk): 74 patches to be rebased etc.

 

Is there any better starting point than "23.08.1-trunk-6.1.xx" for building helios64 kernels ?

Edited October 16, 2023 by ebin-dev

[prahal]

17 hours ago, BinaryWaves said:

But have an odd issue with samba and at one point I think I borked my emmc install and the boot freaks out whenever I attempt to boot. Boot will get to kernel load or I think where its trying to figure out boot partition stuff then it will hang and have the fans blasting full speed until I can connect my laptop to it over the serial console and run Crtrl+D to advance to skip the maintenance.

 

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.

[BinaryWaves]

@prahal

 

Okayyyy, I'm back again. So I suspect essentially the boot record is messed up and confirmed it a little more. I powered down and pulled my drives out (except for an m.2 ssd thats on the board and wasn't on in the hotswap bay.

 

I had set the eMMC bypass jumped and forgot why so I popped the back plate off and took the jumper off and booted. Aaaand then I remembered -- because something happened and essentially without it the jumper it attempts to load the eMMC partition by default. But whatever the issue is that causes the maintenance thing is messed up and will not accept a root password for maintenance and Ctrl+D to bypass does not work, it just reloads the prompt and after a few times it rebooted itself. I reapplied the jumper and ran it again to get the serial dump but it got stuck in a boot too and wouldn't come up. See the attached files for the boot logs, hopefully they might be of use. (The stuff above the U-boot line happens on the unjmpered boot too I just didnt grab it in the log the first time)

 

Since it wouldn't boot for some reason and I was torching it anyway I went ahead and flashed the bookworm build to my sd and booted it up again (with jumper still in place to bypass eMMC). It like briefly came up to the root thing but then it continued half a second later through the normal first boot process and let me set root password / time / first user. I stopped here to write this and am currently sitting at the root@helios64:~# prompt.

 

I will try to go through system updates and armbian config stuff and report back, wish me luck

 

boot_emmc-bypass-to-sdcard.log boot-no-jumper.log

[BinaryWaves]

Side question. Since I can't boot without the jumper in place, would there by any harm in booting with it on and then removing it carefully with the system on? I kinda hope I could do the Helios instructions to re-overwrite the emmc.

[BinaryWaves]

Update 1: Did system updates and after taking the suggestion to reboot it, it kicked the fans up to max during boot like it always does (wish it didnt but as i understand some desk fans start like this as well because its better to start them on max electricity and then step down if im not mistaken?) but then it calmed them down and went through to boot without a problem! OMG thats amazing, theres been a like a half a dozen times that I've woken up in the morning and had to break out my laptop because we lost power and the helios fans were just blasting as it sat hung up on the boot part.

 

I'm glad that isn't a problem anymore with this new bookworm build but I think it still might be messed up if I remove the jumper.

 

I was looking into ZFS this time around but it requires disks to be spun up 100% and higher power consumption :\ Bitrot protection would be nice.

 

Edit update:

Okay, I should clarify for technicalities. the System update I did was via armbian-config (install firmware updates). After the initial reboot I did an apt update and saw i had a libc6 to update. I updated through apt update. then I checked again and there were 40 packages to install still? I went back to armbian-config and ran the firmware update again and it only installed 1 of the packages (some libpam package). So then I did another apt upgrade. It completed and I suspected I would have to reboot so I logged out and then back in as the motd prompt tells me if I need to do a reboot. It said I should reboot for the dbus package so I did.

 

When I rebooted I got a kernel panic! I hard powered down via the front power button then powered back up and no panic this time... back to login prompt. I went in to armbian-config and set the CPU governor's upper bound to 1608MHz instead of 1800MHz. I had done this on previous installs and it seems to be more stable this way as the board tends to freak out it if hits peak CPU? not sure exactly what happens but I'm sure this will not be some magic bullet.

 

---

 

Current state:

After setting the governor I went to software and ran "Headers_install" to install kernel headers, and then "Full" / Install full firmware package. No reboot prompts. I need to make an image backup of the current image state.

 

I previously ran OMV, but I just learned it isn't compatible with Debian 12... soooo juuuuustt great but fuck it i'd rather have the os updates and service patches and deal with having to set things up manually. this is the way

 

Since I learned OMV was not compatible, I was definitely keen on preserving the sdcard a bit and installed log2ram. OMV used a more custom folder2ram but log2ram is more actively maintained it feels like and I can add folders anyway.

 

Rebooted again as per log2ram install and no kernel panic so seems stable.

 

Will report back after setting up MergerFS and SnapRAID tomorrow.

Edited October 20, 2023 by BinaryWaves

[BinaryWaves]

Apologies for late reply.

 

So I had set the cpu governor but after the upgrades I noticed that it got reverted to default (full range 400Mhz - 1.8Ghz, for helios64). It has been surprisingly stable with bookworm, no instability issues or kernel panics really at all!

 

I got mergerfs + snapraid running through the CLI and have my share exported over samba and nfs. So far so good!

 

I was still a little bit concerned about a kernel upgrade borking the whole thing given past experience and after the system was up to date I froze the kernel upgrades in armbian-config, I can unfreeze later but just to be safe in the short term idk.

 

I installed docker via softy and have loaded up a few containers and reading storage from the attached ssd m.2 drive on the mobo, all seems good there!

 

I ran jellyfin and disabling transcoding and only using direct streaming, didn't have a huge impact on the system it seemed which is perfect! When it downloaded media files it definitely kicked the CPU load a bit over 4.0 (4 cores, so over 4 is high right?). There was a weird error where the contianer crashed during this and I thought it had kernel panicked but it was something to do with the container, i am not sure -- docker normally does not spit out an error message to console as it did for that. I am not using swarm mode on the helios but you can set a cpu limit under a deploy setting in compose and run it with a --compatibility flag which will translate it. I set the limit to 1.0 (thinking 25% max cpu capacity in my head, i am not sure how this works out tbh). It works pretty well to keep container constrained and not overwhelm the rk3399. I would like to take advantage of the gpu but apparently there are issues with ffmpeg and rockchip cpus for hardware encoding and other features? Looking into this more.

 

So it seems my only issue at the moment is the eMMC boot thing which i am kind of at a catch 22 for...

[BinaryWaves]

Update: 

 

No system update but now something happened and it wont boot

 

Getting this in there serial output:

Unknown command 'kaslrseed' - try 'help'

 

There was a commit regarding this file and rockchip here:

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

 

 

Is this a regression bug? And is this comment fatal or just some warning message?

 

Sigh I think this build is still progress though

 

updated-boot-log.log

[prahal]

On 10/26/2023 at 5:17 AM, BinaryWaves said:

Unknown command 'kaslrseed' - try 'help'

@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.

Edited October 27, 2023 by prahal

[prahal]

On 10/24/2023 at 7:26 AM, BinaryWaves said:

had set the cpu governor but after the upgrades I noticed that it got reverted to default (full range 400Mhz - 1.8Ghz,

 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.

[prahal]

On 10/20/2023 at 9:21 AM, BinaryWaves said:

it kicked the fans up to max during boot like it always does (wish it didnt but as i understand some desk fans start like this as well because its better to start them on max electricity and then step down if im not mistaken?)

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)

[prahal]

On 10/20/2023 at 8:40 AM, BinaryWaves said:

Side question. Since I can't boot without the jumper in place, would there by any harm in booting with it on and then removing it carefully with the system on? I kinda hope I could do the Helios instructions to re-overwrite the emmc.

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

Edited October 27, 2023 by prahal

[prahal]

On 10/20/2023 at 8:35 AM, BinaryWaves said:

whatever the issue is that causes the maintenance thing is messed up and will not accept a root password for maintenance and Ctrl+D to bypass does not work, it just reloads the prompt

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)

Edited October 27, 2023 by prahal

[prahal]

On 10/20/2023 at 9:21 AM, BinaryWaves said:

theres been a like a half a dozen times that I've woken up in the morning and had to break out my laptop because we lost power and the helios fans were just blasting as it sat hung up on the boot part.

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.

[ebin-dev]

On 8/20/2023 at 12:58 AM, prahal said:

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

 

In order to migrate to bookworm the tests on SD worked fine (after the dwc3 usb issue was solved) but the trouble began after it was transferred from sd to emmc. I used armbian-config for that and I was about to loose my data ...

 

My starting point was the Armbian 23.05 - 6.1.36 Image and I am using linux 6.1.60 now, since the header files were missing in the Armbian Image I had to compile them myself. As far as I understand, this is the new Armbian policy ...

 

Just formatting the emmc partition and to rsync the data from sd to emmc using a backup script worked for me (fstab needs adaptation and some folders have to be recreatad in /var/log with proper access rights i.e. cups, nginx, mysql ...). There are no read/write errors and I am using bookworm on emmc now for about a week now. In fact it is reliable. Also the network operates amazingly fast.

 

The only remaining issue is: while the heartbeat LED starts to operate, the red LEDs on the front panel briefly light up (sata1 to sata5, bus rescan) and the fans spin up for a few seconds , then turn to normal operation.

 

Could this be u-boot related ? Would you have an idea ? (see the parallel thread)

 

Edited October 28, 2023 by ebin-dev

[prahal]

15 hours ago, ebin-dev said:

since the header files were missing in the Armbian Image I had to compile them myself. As far as I understand, this is the new Armbian policy ...

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

[prahal]

16 hours ago, ebin-dev said:

There are no read/write errors and I am using bookworm on emmc now for about a week now. In fact it is reliable.

@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.

[prahal]

18 hours ago, ebin-dev said:

migrate to bookworm the tests on SD worked fine (after the dwc3 usb issue was solved) but the trouble began after it was transferred from sd to emmc. I used armbian-config for that and I was about to loose my data ...

@ebin-dev I do not understand what went wrong. Could you detail the issues ?

 

On my side I also rstnc but the other way around, from emmc to SD, to have an exact copy of the emmc install. To be able to reproduce the issues I had (kernel crashes, that might be related to raid 10 high transfert rate on the rk3399 and pci-SATA bridge).

[ebin-dev]

@prahal I transferred the system from sd to emmc using armbian-config and once the system booted from emmc I had kernel crashes. And booting from sd was really slow after that. In fact I had to set up the entire system again from scratch.

 

The second try was as described in my previous post (rsync sd to formatted emmc with excludes). 

 

I would assume that the bootloader on sd was overwritten and I have no idea what went wrong with the emmc. I use it 24/7 now (bookworm 12.2 with linux 6.1.60 on emmc).

 

Would you like to look at the remaining glitch that I observe with linux 6.1.60 during boot (using a spare sd with bookworm on it) ? The sata bus is rescanned during boot and the red sata 1-5 LEDs flash one after the other at the time when the heartbeat LED starts to blink. This was not the case with linux 6.1.36.

dmesg.txt

Edited October 28, 2023 by ebin-dev

[ebin-dev]

@prahal Regarding the remaining glitch (red sata LEDs flash one after the other during boot): I observe it too with linux 6.6-rc7.

To exclude that this is u-boot related: which version of u-boot do you use (on sd/emmc) ? (A stock image ?)

 

Edit: My system also had the "free() invalid pointer" issue and I repaired it by flashing a new bootloader (linux-u-boot-edge-helios64_22.02.1_arm64 , as discussed here).

Edited November 2, 2023 by ebin-dev