Upgrading to Bullseye (troubleshooting Armbian 21.08.1)

[eClapton]

1 hour ago, ebin-dev said:

 

All you need to do is this (see my earlier message):

 

The easiest way to downgrade linux on emmc now would be to copy those files to /mnt/system (root directory of your emmc) - and then change root with  'chroot /mnt/system' and install the packages with 'dpkg -i *.deb'   (while your active system is on SD).

 

You may also need to refresh your bootloader on emmc - as described in this thread.

 

P.S.: It would appear that you have mounted your SD card (/dev/mmcblk1p1) to /mnt/system and not your emmc (/dev/mmcblk2p1). You need to boot off SD.

 

Not very sure :

 

root@helios64:~# cat /etc/mtab | grep mmcblk
/dev/mmcblk1p1 / ext4 rw,noatime,errors=remount-ro,commit=600 0 0
/dev/mmcblk1p1 /var/log.hdd ext4 rw,noatime,errors=remount-ro,commit=600 0 0
/dev/mmcblk2p1 /mnt/system ext4 rw,relatime 0 0

 

I think I've done right? Is /dev/mmcblk2p1 always emmc?? (I was confused, sorry)

 

Looking to your other post, about the bootloader, I like to be super cautious using dd, but gonna give it a try, as my files there are dated from august (I did the update last night):

 

root@helios64:~# ll /mnt/system/usr/lib/linux-u-boot-current-helios64_21.08.1_arm64/
total 8396
-rw-rw-r-- 1 root root  206844 ago  8 14:59 idbloader.bin
-rw-rw-r-- 1 root root 4194304 ago  8 14:59 trust.bin
-rw-rw-r-- 1 root root 4194304 ago  8 14:59 uboot.img

 

Do you agree?

 

Thank you

 

EDIT: I'm back in the box now, no need to replace boot files.  Just a check of the partition was needed : 

umount /mnt/system

fsck /dev/mmcblk2p1

 

And answered "y" to all questions.

Apparently emmc was corrupted before being marked read-only, which seems very dangerous...

Thank you again @ebin-dev for your answers and @TDCroPower for your small guide.

[piter75]

On 9/3/2021 at 9:17 AM, ebin-dev said:

So far there were at least two observations:

@alchemist observed a month ago, that several Armbian patches did not compile with newer kernels and he assumed that this may have be the reason.

@Igor states that someone may have pushed bad code upstream.

Armbian "current" (5.10.y) compiles without issues.

I second @Igor's opinion that a change somewhere in this diff broke the eMMC.

I tried reverting a few obvious parts of it, like the mmc driver changes, but without success.

 

However I did find that with the unit I have the issue happens only in hs400{,es} modes.

With those disabled my unit works fine and I can use nand-sata-install to transfer os from SD to eMMC successfully which is not possible with 5.10.60+ and hs400 enabled on eMMC.

 

If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:

Upgrade the kernel to 5.10.60, but don't reboot yet.

Run:

curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb
sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb
sudo reboot

 

If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.

There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)

Below you can find the comparison between hs400 and hs200 modes using iozone.

Spoiler

iozone tests with hs400 enabled

        Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    40288    43745    32990    33259    32947    44130
          102400     512    55587    55494   199986   200855   217646    55196
          102400   16384    55394    55543   244727   246050   245637    55338

 

iozone tests with hs400 disabled

        Command line used: iozone -e -I -a -s 100M -r 4k -r 512k -r 16M -i 0 -i 1 -i 2
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
          102400       4    30373    39757    30250    30432    30187    38770
          102400     512    55609    55545   124949   123053   124986    55854
          102400   16384    56063    55900   130689   132590   132463    54512

 

 

[ebin-dev]

1 hour ago, piter75 said:

If this workaround works I will disable hs400{,es} (again) in Armbian until the underlying issue is found.

There will be a performance penalty to that change but keep in mind that Helios64 was originally released with hs200 and only recently gained hs400 back ;-)

 

Hi Peter, thank you for the analysis. If someone confirms that hs200 mode is a temporary solution for linux kernels 60+ you could release an update with this fix.

So everyone will have the choice to stay with linux-5.10.43 for the time being or to upgrade to newer kernels .60+ with a performance penalty on emmc (but with a writable file system).

 

[ebin-dev]

13 hours ago, piter75 said:

If anyone wants to check if switching eMMC to hs200 mode works also on their unit, here is how:

Upgrade the kernel to 5.10.60, but don't reboot yet.

Run:

curl -o rk3399-kobol-helios64.dtb https://users.armbian.com/piter75/helios64/rk3399-kobol-helios64.dtb
sudo cp rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-kobol-helios64.dtb
sudo reboot

 

 

I can confirm that your temporary fix works on my system. To test it one just needs to fully upgrade emmc to the latest Armbian 21.08.1 release and apply the above fix before a reboot.

 

The system partition on emmc remains writable  - even with kernel 5.10.60 - but with the performance penalty.

(However, I switched back to kernel 5.10.43 again)

 

So - from my point of view you could provide an updated release including this temporary fix. Please keep us informed if the underlying issue is solved.

Thank you again !

[mrjpaxton]

On 8/27/2021 at 6:41 AM, Werner said:

Userspace upgrades (like Buster to Bullseye or Bionic to Focal) were never actively supported by Armbian.

Well, here's my issue. I'd like to explain it.

 

The problem was I wasn't even doing a full upgrade. I was just using "apt update; apt upgrade", and upgrading the system normally.

So if even a normal upgrade breaks the system, there's something seriously wrong here...

 

I don't know much about Debian's policies, but I do know a full distribution upgrade should only be done with "apt dist-upgrade" or "apt full-upgrade", and this policy wasn't respected. It would have been fine if the latest rockchip64 kernel image was held back before the upgrade, so that it had time to get bug fixes.

 

Also, the version numbering is confusing. The version for "linux-image-current-rockchip64" is set to "21.08.01", but that's not what version the kernel is. Shouldn't it be "5.10.60-rockchip64". That might have helped me avoid this problem altogether, so at least I'd know what version of the kernel I was about to install. In other words, I had no idea "21.08.01" had the broken kernel "5.10.60-rockchip64".

 

I know Armbian is different than Debian, but it really should play more nicely to what regular Debian users are used to, rather than deviating too much from it. It's one of the reasons why I chose Armbian! It is because I expected it 99% to work like Debian, except maybe for the fact that it uses a different kernel, DTD, maybe a BSP (base support package), U-Boot, and a few necessary patches.

 

But changing how core OS updates and upgrades work is just wrong to me.

 

A side note, I know U-Boot isn't GRUB, but it really would be nice to have support for multiple (backup) kernels like I'm used to on x86 with GRUB. It is different code, and a different arch, so I guess that makes sense though...

 

Still a shame. I will look around and see if the solutions work. Otherwise, I'll try to use my full rsync backup.

[mrjpaxton]

EDIT: Removed.

[ebin-dev]

9 hours ago, mrjpaxton said:

Otherwise, I'll try to use my full rsync backup.

 

Sorry - but it is difficult to help because the current state of your system is not known.

You could format your system partition on emmc, rsync your backup to it and refresh the bootloader on emmc as described earlier in this thread.

[lanefu]

14 hours ago, mrjpaxton said:

Also, the version numbering is confusing. The version for "linux-image-current-rockchip64" is set to "21.08.01", but that's not what version the kernel is. Shouldn't it be "5.10.60-rockchip64". That might have helped me avoid this problem altogether, so at least I'd know what version of the kernel I was about to install. In other words, I had no idea "21.08.01" had the broken kernel "5.10.60-rockchip64".

 

yeah unfortunately the kernel and armbian packages have effectively been a rolling release, but I hope we can switch them to be bound to a release in the future.    

one of the issues is we depend on aptly and it..needs help 

 

[Igor]

1 hour ago, lanefu said:

yeah unfortunately the kernel and armbian packages have effectively been a rolling release, but I hope we can switch them to be bound to a release in the future.  

If I understand this correctly, the question is about package naming, which we have some initiative to change. We are not going to make critical changes to the infrastructure just like that to actually gain very little and risk other problems. If OP has a desire to join the party, here is something going on:

 

 

16 hours ago, mrjpaxton said:

but it really should play more nicely

This is non standard, purpose driven hardware, which sits between embedded world and mainstream desktop. We have cried hard to make it as close to the mainstream world as possible. We could go further and add Grub, but it will only add another layer of troubles and we will loss more of our private money. And in any case - why? R&D is fuc* expensive especially if we receive practically no help. Nobody around can leave job and work on those ideas, since it would  pretty quickly end up on the street begging for food There are already several millions euros worth of tasks users have asked Armbian maintainers to finance for you. Doesn't make sense - not fun, just pain in exchange for nothing is a bad deal. If you have a need to change this, join those who thinks the same / similar. In the topic above. 

[lanefu]

3 minutes ago, Igor said:

If I understand this correctly, the question is about package naming, which we have some initiative to change. We are not going to make critical changes to the infrastructure just like that to actually gain very little and risk other problems. If OP has a desire to join the party, here is something going on:

I have slightly different approach to going's solution, but this would be compatible with it
 

 

[Igor]

1 minute ago, lanefu said:

I have slightly different approach to going's solution, but this would be compatible with it

Yes, but neither solutions helps in knowing that some particular upgrade was broken. We didn't know until users reported. And this one was pretty ugly, since mainstream versions usually doesn't breaks things on board specific features. I guess with ARM becoming more mainstream, more such unexpected troubles will bump out. At kernel.org, nobody will ever check things like that.

[lanefu]

3 minutes ago, Igor said:

Yes, but neither solutions helps in knowing that some particular upgrade was broken. We didn't know until users reported. And this one was pretty ugly, since mainstream versions usually doesn't breaks things on board specific features. I guess with ARM becoming more mainstream, more such unexpected troubles will bump out. At kernel.org, nobody will ever check things like that.

The critical difference is the user has to opt-in to upgrading releases.     the default behavior would not be people's shit by a routine `apt update`

[Igor]

27 minutes ago, lanefu said:

The critical difference is the user has to opt-in to upgrading releases.  

That is correct, but its not following KISS principle. We have to think on ourselves in 1st place since users mainly sees their problems only. It adds another dimensions into already complex world while changing little. You can see how many people actually tested RC images and reported? With some very special boards? None. So that kind of safety wouldn't change much. I see it as quite a lot of additional work, users will never pay for, for almost no gain. If someone will try to mention that "Debian on my desktop don't break", I will kick him into the butt over and over again, until he will perhaps read the FAQ and realise what is he asking for.

 

- stretch, buster, focal, stretch, ...

- minimal, normal

- xfce, mate, budgie, ...

- debian, ubuntu
- legay, current, edge

- stable, nightly

- v21.08, v21.11, v22.02, RC, ...

 

... is already insane to understand.

[lanefu]

10 minutes ago, Igor said:

That is correct, but its not following KISS principle. We have to think on ourselves in 1st place since users mainly sees their problems only. It adds another dimensions into already complex world while changing little. You can see how many people actually tested RC images and reported? With some very special boards? None. So that kind of safety wouldn't change much. I see it as quite a lot of additional work, users will never pay for, for almost no gain.

 

I strongly disagree.

[SIGSEGV]

@Igor, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)?

That way we can participate on the QA process and help raise flags when pre-released changes break the stable builds.

I understand that you do not have an Helios64 to test, and so as part of the community we should be able to help in that regard.

[lanefu]

2 minutes ago, SIGSEGV said:

, is there a way to have access and test pre-release images from the official Armbian build system (nightly images should be fine)?

That way we can participate on the QA process and help raise flags when pre-released

 

We have always published nighties.    Goto the download page find the device  then choose other downloads and scroll down to test builds.

[SIGSEGV]

Thanks @lanefu.

Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs.

 

Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.

[bunducafe]

Thanks @SIGSEGV for your post. I do very much appreciate it because at the end it comes down to exactly that: There are a few very keen developers and a bunch of users who like to use the software with their units - in that case the Helios64. But in return are not really willing to contribute.

 

To be a bit more subjectively: I would love to contribute and I do so once in a while if I stumble upon some problems I could solve myself. Mostly related to a running system with OMV and Armbian If it comes to testing kernels and debug I am out of the game because I did not even manage to get the console working. That's mainly because I am with MACs here at the office and I simply could not get the console running on none of my machines. So on this side I would consider myself a complete noob which makes debugging kind of impossible to me.

 

I might get a separate laptop with a non-mac unix system in the future just for this purpose. Meanwhile I am a bit far off in giving support on that kind of level unfotunately. That's also a reason why I am rather reading through the forum and usually not be one of the complainers as I know how much work the devs put in here and how good it usually works. A hickup from time to time is totally fine with me.

[ebin-dev]

5 hours ago, bunducafe said:

If it comes to testing kernels and debug I am out of the game because I did not even manage to get the console working. That's mainly because I am with MACs here at the office and I simply could not get the console running on none of my machines.

 

Really ?

If you are on macOS Big Sur all the drivers and apps are already there. If you need to access the serial console of your Helios64, just connect your mac to the USB-C port of your Helios64. A device such as  /dev/tty.usbserial-XXXXXXXX will be recognised by macOS. All you need to do then is to enter the following into the Terminal of your mac (X to be replaced):

 

screen /dev/tty.usbserial-XXXXXXXX 1500000 -L

 

Edit: If the 'screen' command on macOS does not show the output of the bootloader (scrambled characters) you could use the app serial. The only thing you need to configure is to set the serial speed manually to 1500000 bps.

 

If someone would like to contribute in kernel testing - the Armbian build system is very easy to install and use. All you need is an Ubuntu 21.04 (amd64) installation. All the rest is explained here. To compile your own kernel is then as simple as this:

./compile.sh BOARD=helios64 BRANCH=current KERNEL_ONLY=yes RELEASE=bullseye

 

[eClapton]

@bunducafe In my case its the same situation: if you connect the Helios64 to your Mac USB port, and write:

screen /dev/tty.usb

and then hit "Tab", should write the number for you. You then can continue typing.... but for me to doesn't work neither, the screen just stays white all the time.

Using Serial, though, works perfectly.

 

I'm willing to contribute testing also, and it's very clear for me, being a Linux user since RedHat 3.x days, that all this is a volunteer effort from developers, at their own will ... a bazaar, not a cathedral, in Raymond's  words, and so no one has the right to make any rant about bugs and problems.

It's just my humble opinion, of course.

 

I cannot, though, use my unit to test kernels, as I rely on it for backups. Its really a pity that Kobol can't go on with their operations. The quality of the wiki help... the packaging, the help given to customers... I was really very very surprised of this level of attention to detail.

 

I suppose you have contacted them to ask for some Helios64 board they may have in spare...?

My last question: can I use some virtualized (VBOX) computer to test the Armbian builds? Thats the only way I fear I can help right now.

 

Thanks to all for the hard work, and to all the rest, you users, have patience!.

 

Cheers. 

 

EDIT: coming back from the link I have found about VBOX. Yes it's possible to do. Gonna give it a try.

[lanefu]

23 hours ago, SIGSEGV said:

 

Thanks @lanefu.

Another idea would be a "test week" (or whatever period makes sense) - a time when the users can download pre-release/test images of the upcoming version/release and the maintainers give timely feedback about issues found in the test kernels and user space binaries. I know that Fedora follows a similar approach (I get the notifications from the Fedora Magazine) - the main objective is to catch breaking bugs.

 

Now, if the community doesn't participate - then all complaints can be considered rants. We have to participate to make sure our systems are running as smoothly as possible. Software development, QA, Trouble shooting are task that take time/effort, as @Igor has always pointed out, we need to get involved somehow in order to contribute back. In the end Armbian is a community project - if you can't/want to donate funds, donate time and effort instead.

 

 

We really need someone to manage the outreach and bug tracking for RC testing...  we've done some attempt of that in the past, but it's been hard to get the attention needed.... and even harder to manage the issues.

and also need another attempt at recruiting Maintainers/owners for specific devices that can perform tests and track issues... (and develop if they want  )

[ebin-dev]

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').

 

It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.

 

You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.

 

[alchemist]

On 9/9/2021 at 2:10 PM, ebin-dev said:

@piter75 commited the emmc fix into Armbian and built Armbian 21.08.2 which is already available through the Armbian mirrors (via 'apt update && apt upgrade').

 

It is save to upgrade your Buster or Bullseye installation to Armbian 21.08.2 - but emmc read speed will be about 50% what it used to be.

 

You can roll back to the previous linux 5.10.43 kernel if you don't like that - just install those files with 'dpkg -i *.deb'.

 

YEAH !

I can compile and boot linux-5.10.63, I only had to disable the rk3328 patches because some patches were rejected.

 

I booted from sdcard, updated the /boot folder, then rebooted from eMMC and I can again run and write on the eMMC :-)

 

 

EDIT: and upgraded to 5.10.64 this weekend without any issue

 

[jotapesse]

On 8/29/2021 at 2:54 PM, ebin-dev said:

@jotapesse The answer to your question is clearly: Do not yet use Armbian Bullseye repositories for updating your Debian Bullseye installation !

Thanks. Understood. Hopefully it will be sorted soon.

[prahal]

bisected eMMC breakage:
06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 is the first bad commit
 

commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Thu May 20 01:12:23 2021 +0300

    regulator: core: resolve supply for boot-on/always-on regulators
    
    commit 98e48cd9283dbac0e1445ee780889f10b3d1db6a upstream.
    
    For the boot-on/always-on regulators the set_machine_constrainst() is
    called before resolving rdev->supply. Thus the code would try to enable
    rdev before enabling supplying regulator. Enforce resolving supply
    regulator before enabling rdev.
    
    Fixes: aea6cb99703e ("regulator: resolve supply after creating regulator")
    Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
    Link: https://lore.kernel.org/r/20210519221224.2868496-1-dmitry.baryshkov@linaro.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

 drivers/regulator/core.c | 6 ++++++
 1 file changed, 6 insertions(+)

 

is https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/regulator/core.c?id=98e48cd9283dbac0e1445ee780889f10b3d1db6a
from thread https://lore.kernel.org/all/20210519221224.2868496-1-dmitry.baryshkov@linaro.org/

 

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 7b3de8b0b1ca..043b5f63b94a 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1422,6 +1422,12 @@ static int set_machine_constraints(struct regulator_dev *rdev)
         * and we have control then make sure it is enabled.
         */
        if (rdev->constraints->always_on || rdev->constraints->boot_on) {
+               /* If we want to enable this regulator, make sure that we know
+                * the supplying regulator.
+                */
+               if (rdev->supply_name && !rdev->supply)
+                       return -EPROBE_DEFER;
+
                if (rdev->supply) {
                        ret = regulator_enable(rdev->supply);
                        if (ret < 0) {

 

EDIT 1: this change to return EPROBE_DEFER if regulator has a supply name but no supply ready was intended to complete commit aea6cb99703e17019e025aa71643b4d3e0a24413 which  expects set_machine_constraints to return this eprobe_defer error to attempt to resolve the supply ( before attempting a second run of set_machine_constraints).

 

One still need to find out if aea6cb99703e17019e025aa71643b4d3e0a24413 fails to resolve the supply and thus does not make a second attempt to set_machine_constraints thus leaves the regulator disabled or else.

 

 

commit aea6cb99703e17019e025aa71643b4d3e0a24413
Author: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
Date:   Sat Sep 26 23:32:41 2020 +0200

    regulator: resolve supply after creating regulator
    
    When creating a new regulator its supply cannot create the sysfs link
    because the device is not yet published. Remove early supply resolving
    since it will be done later anyway. This makes the following error
    disappear and the symlinks get created instead.
    
      DCDC_REG1: supplied by VSYS
      VSYS: could not add device link regulator.3 err -2
    
    Note: It doesn't fix the problem for bypassed regulators, though.
    
    Fixes: 45389c47526d ("regulator: core: Add early supply resolution for regulators")
    Signed-off-by: Micha? Miros?aw <mirq-linux@rere.qmqm.pl>
    Link: https://lore.kernel.org/r/ba09e0a8617ffeeb25cb4affffe6f3149319cef8.1601155770.git.mirq-linux@rere.qmqm.pl
    Signed-off-by: Mark Brown <broonie@kernel.org>

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ff8e99ca0306..9f704a6c4802 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -5280,15 +5280,20 @@ regulator_register(const struct regulator_desc *regulator_desc,
        else if (regulator_desc->supply_name)
                rdev->supply_name = regulator_desc->supply_name;
 
-       /*
-        * Attempt to resolve the regulator supply, if specified,
-        * but don't return an error if we fail because we will try
-        * to resolve it again later as more regulators are added.
-        */
-       if (regulator_resolve_supply(rdev))
-               rdev_dbg(rdev, "unable to resolve supply\n");
-
        ret = set_machine_constraints(rdev, constraints);
+       if (ret == -EPROBE_DEFER) {
+               /* Regulator might be in bypass mode and so needs its supply
+                * to set the constraints */
+               /* FIXME: this currently triggers a chicken-and-egg problem
+                * when creating -SUPPLY symlink in sysfs to a regulator
+                * that is just being created */
+               ret = regulator_resolve_supply(rdev);
+               if (!ret)
+                       ret = set_machine_constraints(rdev, constraints);
+               else
+                       rdev_dbg(rdev, "unable to resolve supply early: %pe\n",
+                                ERR_PTR(ret));
+       }
        if (ret < 0)
                goto wash;

 

 

 

My logs for bad shows:

[    1.257297] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517
[    1.257446] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517
[    1.257588] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517
[    1.257728] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517
[    1.258114] reg-fixed-voltage pcie-power: Failed to register regulator: -517
[    1.258312] reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517
[    1.258451] reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517
[    1.258705] reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517
[    1.261721] reg-fixed-voltage usblan-power: Failed to register regulator: -517
[    2.158719] vdd_log: supplied by regulator-dummy
[    2.230749] rk808-regulator rk808-regulator: there is no dvs0 gpio
[    2.230781] rk808-regulator rk808-regulator: there is no dvs1 gpio
[    2.230792] rk808-regulator rk808-regulator: max buck steps per change: 4
[    2.240854] rk808 0-001b: failed to register 12 regulator
[    2.249848] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
[    2.253127] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!
[    2.423549] reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517
[    2.424263] reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517
[    2.424830] reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517
[    2.425443] reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517
[    2.556287] rk808-regulator rk808-regulator: there is no dvs0 gpio
[    2.556318] rk808-regulator rk808-regulator: there is no dvs1 gpio
[    2.556328] rk808-regulator rk808-regulator: max buck steps per change: 4

 

while for good:

[    2.172993] vdd_log: supplied by regulator-dummy
[    2.330040] rk808-regulator rk808-regulator: there is no dvs0 gpio
[    2.330071] rk808-regulator rk808-regulator: there is no dvs1 gpio
[    2.330081] rk808-regulator rk808-regulator: max buck steps per change: 4
[    2.347345] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
[    2.350525] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!

[ebin-dev]

6 hours ago, prahal said:

One still need to find out if aea6cb99703e17019e025aa71643b4d3e0a24413 fails to resolve the supply and thus does not make a second attempt to set_machine_constraints thus leaves the regulator disabled or else.

 

Thank you @prahalfor digging into this !! @aprayoga@piter75 Could the emmc issue be solved now with this input ?

[snakekick]

Hello, can sombody please explane the current status?

is it  secure to  make a apt update (and reboot) or is update now not possible or recomment 

[ebin-dev]

23 minutes ago, snakekick said:

Hello, can sombody please explane the current status?

is it  secure to  make a apt update (and reboot) or is update now not possible or recomment 

 

 

 

[giddy]

On 9/1/2021 at 4:08 PM, TDCroPower said:

It worked, I have my eMMC system back!

 

Here are all the steps in case someone else has the problem and wants to repair his eMMC image...

 

1. download a previous Helios64 image from here...
https://wiki.kobol.io/download/
2. install the image on a microSD e.g. for Windows and macOS there is Etcher...
https://www.balena.io/etcher/
3a. boot your Helios64 with the microSD and Jumper 10, see here...
https://wiki.kobol.io/helios64/troubleshoot/#how-to-force-boot-from-microsd
3b. Alternative: from the serial console press a key on the keyboard while u-boot start. You will get the u-boot prompt.

From this prompt write and press enter. Helios64 will boot from SD... (thx @prahal)

run bootcmd_mmc1

 

4. if you are logged in as root user (normal users must put a sudo in front of the commands) execute the following commands...

root@helios64:~# mkdir -p /mnt/system
root@helios64:~# mount /dev/mmcblk2p1 /mnt/system
root@helios64:~# cd /mnt/system/

5. The contents of the /mnt/system directory should now be filled with the contents of your eMMC....

root@helios64:/mnt/system# ll
total 80
lrwxrwxrwx   1 root root     7 Aug 30  2020 bin -> usr/bin
drwxr-xr-x   3 root root  4096 Sep  1 03:01 boot
drwxr-xr-x   2 root root  4096 Oct 15  2020 dev
drwxr-xr-x 110 root root 12288 Sep  1 03:01 etc
drwxr-xr-x   2 root root  4096 Sep 22  2020 export
drwxr-xr-x   5 root root  4096 Jun 10 04:12 home
lrwxrwxrwx   1 root root     7 Aug 30  2020 lib -> usr/lib
drwx------   5 root root  4096 Oct  5  2020 lost+found
drwxr-xr-x   4 root root  4096 Oct 15  2020 media
drwxr-xr-x   2 root root  4096 Feb  9  2021 mnt
drwxr-xr-x   4 root root  4096 Dec  2  2020 opt
dr-xr-xr-x   2 root root  4096 Oct 15  2020 proc
drwx------   7 root root  4096 Aug 31 23:36 root
drwxr-xr-x   2 root root  4096 Oct 15  2020 run
lrwxrwxrwx   1 root root     8 Aug 30  2020 sbin -> usr/sbin
drwxrwxr-x   2 root root  4096 Oct  5  2020 selinux
drwxr-xr-x   6 root root  4096 Jun 10 03:18 srv
dr-xr-xr-x   2 root root  4096 Oct 15  2020 sys
lrwxrwxrwx   1 root root    42 Sep  1 03:01 thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0
drwxrwxrwt   2 root root  4096 Oct 15  2020 tmp
drwxr-xr-x  12 root root  4096 Nov 27  2020 usr
drwxr-xr-x  14 root root  4096 Oct  6  2020 var

 

6. now download the 3 old packages...

root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-dtb-current-rockchip64_21.05.4_arm64.deb
root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-headers-current-rockchip64_21.05.4_arm64.deb
root@helios64:/mnt/system# wget http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.43-rockchip64/linux-image-current-rockchip64_21.05.4_arm64.deb

 

7. now changes the root directory...

root@helios64:/mnt/system# chroot /mnt/system
root@helios64:/# pwd
/
root@helios64:/# ll
total 50996
lrwxrwxrwx   1 root root        7 Aug 30  2020 bin -> usr/bin
drwxr-xr-x   3 root root     4096 Sep  1 14:56 boot
drwxr-xr-x   2 root root     4096 Sep  1 16:15 dev
drwxr-xr-x 110 root root    12288 Sep  1 03:01 etc
drwxr-xr-x   2 root root     4096 Sep 22  2020 export
drwxr-xr-x   5 root root     4096 Jun 10 04:12 home
lrwxrwxrwx   1 root root        7 Aug 30  2020 lib -> usr/lib
-rw-r--r--   1 root root   314304 Jul  8 19:32 linux-dtb-current-rockchip64_21.05.4_arm64.deb
-rw-r--r--   1 root root 11527696 Jul  8 19:32 linux-headers-current-rockchip64_21.05.4_arm64.deb
-rw-r--r--   1 root root 40290884 Jul  8 19:33 linux-image-current-rockchip64_21.05.4_arm64.deb
drwx------   5 root root     4096 Oct  5  2020 lost+found
drwxr-xr-x   4 root root     4096 Oct 15  2020 media
drwxr-xr-x   2 root root     4096 Feb  9  2021 mnt
drwxr-xr-x   4 root root     4096 Dec  2  2020 opt
dr-xr-xr-x   2 root root     4096 Oct 15  2020 proc
drwx------   7 root root     4096 Aug 31 23:36 root
drwxr-xr-x   2 root root     4096 Oct 15  2020 run
lrwxrwxrwx   1 root root        8 Aug 30  2020 sbin -> usr/sbin
drwxrwxr-x   2 root root     4096 Oct  5  2020 selinux
drwxr-xr-x   6 root root     4096 Jun 10 03:18 srv
dr-xr-xr-x   2 root root     4096 Oct 15  2020 sys
lrwxrwxrwx   1 root root       42 Sep  1 03:01 thermal_zone0 -> /sys/devices/virtual/thermal/thermal_zone0
drwxrwxrwt   2 root root     4096 Oct 15  2020 tmp
drwxr-xr-x  12 root root     4096 Nov 27  2020 usr
drwxr-xr-x  14 root root     4096 Oct  6  2020 var

 

8. now installs the downloaded packages...

root@helios64:/# dpkg -i *.deb
dpkg: warning: downgrading linux-dtb-current-rockchip64 from 21.08.1 to 21.05.4
(Reading database ... 62558 files and directories currently installed.)
Preparing to unpack linux-dtb-current-rockchip64_21.05.4_arm64.deb ...
Unpacking linux-dtb-current-rockchip64 (21.05.4) over (21.08.1) ...
Selecting previously unselected package linux-headers-current-rockchip64.
Preparing to unpack linux-headers-current-rockchip64_21.05.4_arm64.deb ...
Unpacking linux-headers-current-rockchip64 (21.05.4) ...
dpkg: warning: downgrading linux-image-current-rockchip64 from 21.08.1 to 21.05.4
Preparing to unpack linux-image-current-rockchip64_21.05.4_arm64.deb ...
update-initramfs: Deleting /boot/initrd.img-5.10.60-rockchip64
Removing obsolete file uInitrd-5.10.60-rockchip64
stat: cannot stat '/proc/1/root/.': No such file or directory
Unpacking linux-image-current-rockchip64 (21.05.4) over (21.08.1) ...
Setting up linux-dtb-current-rockchip64 (21.05.4) ...
Setting up linux-headers-current-rockchip64 (21.05.4) ...
Compiling headers - please wait ...
grep: /proc/cpuinfo: No such file or directory
grep: /proc/cpuinfo: No such file or directory
Setting up linux-image-current-rockchip64 (21.05.4) ...
update-initramfs: Generating /boot/initrd.img-5.10.43-rockchip64
W: Couldn't identify type of root file system for fsck hook
update-initramfs: Converting to u-boot format

 

9. reset the root change with exit and restart your helios64 with reboot...

root@helios64:/# exit
exit
root@helios64:/mnt/system# reboot

 

10. after a reboot you should now boot from the eMMC again...

root@192.168.180.5's password:
 _   _      _ _            __   _  _
| | | | ___| (_) ___  ___ / /_ | || |
| |_| |/ _ \ | |/ _ \/ __| '_ \| || |_
|  _  |  __/ | | (_) \__ \ (_) |__   _|
|_| |_|\___|_|_|\___/|___/\___/   |_|

Welcome to Armbian 21.08.1 Buster with Linux 5.10.43-rockchip64

No end-user support: built from trunk

System load:   74%           	Up time:       3 min
Memory usage:  34% of 3.77G  	IP:	       172.18.0.1 172.19.0.1 172.20.0.1 172.17.0.1 192.168.180.5
CPU temp:      66°C           	Usage of /:    87% of 15G

[ 0 security updates available, 3 updates total: apt upgrade ]
Last check: 2021-09-01 16:38

[ General system configuration (beta): armbian-config ]

Last login: Wed Sep  1 16:26:23 2021
root@helios64:~#
root@helios64:~# uname -a
Linux helios64 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 GNU/Linux
root@helios64:~#

 

11. if the eMMC was used you can see with mount...

root@helios64:~# mount | grep /dev/mmc
/dev/mmcblk2p1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/log type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/tmp type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/lib/openmediavault/rrd type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/spool type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/lib/rrdcached type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/lib/monit type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)
/dev/mmcblk2p1 on /var/folder2ram/var/cache/samba type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)

 

 

 

Nice thank you for instructions.

I had to run `mmc rescan` in uboot before I could run `run bootcmd_mmc1`
I kept getting error "could not set mode"

after `mmc rescan` `run bootcmd_mmc1` starts booting from sd card immediately.
 

[Flolm]

Hello,

 

Do you know if a new install (from scratch, no upgrade from Buster) with Bullseye image is stable on Helios64 ?

 

Thank you