Jump to content

Upgrading to Bullseye (troubleshooting Armbian 21.08.1)

ebin-dev

By ebin-dev
in Rockchip

 Share

Recommended Posts

jotapesse

jotapesse

Posted
Posted

Hi everyone! Thank you for all the updates on this. I have now fully upgraded my Helios64 with a ZFS pool from Armbian 21.08.2 Buster to Armbian 21.08.2 Bullseye (full Debian and Armbian repos). All good, no issues. As currently I'm just using the emmc to boot with system installed on sata1, the emmc speed impact is negligble in my case - but hopefully this will be sorted in the near future.

0
mend0za

mend0za

Posted
Posted
  On 10/1/2021 at 3:31 PM, griefman said:
Did anyone try 21.08.2? Is it worth upgrading already?
I made an upgrade buster -> bullseye yesterday on Pine64 . It just works .

Upgrade needed only if you need some updated software from Bullseye . As for me trigger was mpd (my Pine64 board used mostly as audio player / receiver ) .

Sent from my M2007J20CG using Tapatalk

0
Cariboux

Cariboux

Posted
Posted

Hello everyone,

 

I am currently trying to repair my Helios64.


I exposed my problem in this topic : 

A member ( @IcerJo ) said that this problem could be related to this topic. So I read the posts of this topic looking for a solution.

 

I removed the hard drives from my NAS (to avoid a false manipulation) and I opened it (to be able to force the boot from the microSD with the jumper cab P10). Then I followed the instructions of the @TDCroPower message (here : 

 

Unfortunately, it didn't work. My NAS refuses to boot from the eMMC (fail at step 10 of the @TDCroPower message). Note that I tried 2 times these instructions: first with the Armbian_21.08.2_Helios64_buster_current_5.10.63 image. Then with the Armbian_21.05.1_Helios64_buster_current_5.10.35 image. My current version is: Armbian 21.08.3 Buster with Linux 5.10.63-rockchip64 and my NAS can only boot from the MicroSD card. Moreover, I can only communicate with it through the usb−usb-c cable, via picocom. SSH doesn’t work (I have an error message " WARNING: remote host identification has changed! "...).

 

Concerning the boot from the eMMC, I understood that it was maybe necessary to refresh the bootloader on eMMC. I didn’t understand very well the procedure to follow to make such thing. I went to armbian-config > System > Install > 5 - Install/Update the bootloader on SD/eMMC, then I rebooted... but nothing. Here is what picocom returns when I try to boot from the eMMC: 

 

  Reveal hidden contents

 

I'm a little bit lost. I don't understand much about it. Does anyone have a clue for me? Whether the NAS runs on eMMC or MicroSD doesn't really matter to me. I just want to be able to get a working NAS and recover the data from my hard drives (previously configured with OpenMediaVault). 

 

Thank you very much, everyone.

0
prahal

prahal

Posted
Posted
  On 10/13/2021 at 8:21 PM, Cariboux said:

I removed the hard drives from my NAS (to avoid a false manipulation) and I opened it (to be able to force the boot from the microSD with the jumper cab P10). Then I followed the instructions of the @TDCroPower message (here :

 

Unfortunately, it didn't work. My NAS refuses to boot from the eMMC (fail at step 10 of the @TDCroPower message). Note that I tried 2 times these instructions: first with the Armbian_21.08.2_Helios64_buster_current_5.10.63 image. Then with the Armbian_21.05.1_Helios64_buster_current_5.10.35 image. My current version is: Armbian 21.08.3 Buster with Linux 5.10.63-rockchip64 and my NAS can only boot from the MicroSD card. Moreover, I can only communicate with it through the usb−usb-c cable, via picocom. SSH doesn’t work (I have an error message " WARNING: remote host identification has changed! "...).

 

 

Expand  

 

If you boot from sdcard while your previous system was on eMMC the ssh identification is different. If you want to connect to the sd card rescue system:

ssh -o "UserKnownHostsFile /dev/null" -o StrictHostKeyChecking=no -o  "PasswordAuthentication yes" root@helios64

I mean if your system is on eMMC and you boot from a sd card rescue system you have to tell ssh to ignore the host (and force password auth because the sd card system will not have public kay auth set up).

 

about the failure at step 10 ... you should remove the sd card before boot (and your jumper mod) to boot from eMMC and all should be fine.

Mind the process you followed did not tell to set the jumper 10 because it tells to switch boot media via u-boot prompt a command "run bootcmd_mmc1" for sd and "run bootcmd_mmc0" for eMMC. Doing both jumper 10 and u-boot bootcmd_mmc1 is undefined. Simply do one or the other not both.

 

Cheers

0
Cariboux

Cariboux

Posted
Posted
  On 10/14/2021 at 11:32 AM, prahal said:

about the failure at step 10 ... you should remove the sd card before boot (and your jumper mod) to boot from eMMC and all should be fine.

Mind the process you followed did not tell to set the jumper 10 because it tells to switch boot media via u-boot prompt a command "run bootcmd_mmc1" for sd and "run bootcmd_mmc0" for eMMC. Doing both jumper 10 and u-boot bootcmd_mmc1 is undefined. Simply do one or the other not both.

 

Cheers

Expand  

 

Hi @prahal, thank you for helping me !

 

So, I have remove the jumper cap and the MicroSD card, but the boot from eMMC doesn’t work. 

This is what I have when I try to start from eMMC : 

  Reveal hidden contents

 

... and the kernel never start. (The System activity LED of the Front Panel is blue still. It’s not blinking.)

 

When I boot from the MicroSD card (with the command « run bootcmd_mmc1 »), it’s working. 

 

 When I boot from the MicroSD card, at the step 5 of the @TDCroPower’s message (https://forum.armbian.com/topic/18855-upgrading-to-bullseye-troubleshooting-armbian-21081/?do=findComment&comment=128305 ), I see this (I don’t know if it’s normal, especialy what is in red) : 

  Reveal hidden contents

 

( Maybe I have made a mistake because when I have do the step 6 of @TDCroPower’s message, I only « wget » 3 packages of this link : http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.63-rockchip64/ : linux-dtb-current-rockchip64_21.08.2_arm64.deb , linux-headers-current-rockchip64_21.08.2_arm64.deb and linux-image-current-rockchip64_21.08.2_arm64.deb. I didn’t « wget » the 3 packages « 21.05.9 ».

(But, when i have try the downgrading with the Armbian_21.05.1_Helios64_buster_current_5.10.35 image on my MicroSD, i have « wget » all the three packages of http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.35-rockchip64/ . But it was not working neither....) )

 

0
prahal

prahal

Posted
Posted
  On 10/15/2021 at 1:20 PM, Cariboux said:

This is what I have when I try to start from eMMC : 

  Reveal hidden contents

 

... and the kernel never start. (The System activity LED of the Front Panel is blue still. It’s not blinking.)

Expand  

 

check that eMMC boot/armbianEnv.txt contains:
verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=a79a14c0-3cf4-4fb9-a6c6-838571351371
rootfstype=ext4
overlays=dwc3-0-host
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u

 

Note rootdev=UUID= will be different. You can check your by running 

sudo blkid

from the sdcard os.

 

I believe yours is fine so you could also: 

fsck /dev/mmcblk2p1

when booting from sdcard (booting kernel that has the emmc fix only ! your log shows 5.10.63 armbian 22.08.2 so your are fine. But double check before fscking).

Fscking will tell you if the filesystem is fine (readable/mountable by for one u-boot itself to start the kernel).

 

My mmcblk2p1 boot/armbianEnv.txt content was wrong as I ran fsck when my emmc was unstable (this was a bad idea). Thus u-boot was unable to start the system. Restoring armbianENv.txt fixed my boot.

 

  On 10/15/2021 at 1:20 PM, Cariboux said:

When I boot from the MicroSD card (with the command « run bootcmd_mmc1 »), it’s working. 

 

 When I boot from the MicroSD card, at the step 5 of the @TDCroPower’s message (https://forum.armbian.com/topic/18855-upgrading-to-bullseye-troubleshooting-armbian-21081/?do=findComment&comment=128305 ), I see this (I don’t know if it’s normal, especialy what is in red) : 

  Reveal hidden contents
Expand  

 

The red is fine it is color for deb file type.

 

 

 

  On 10/15/2021 at 1:20 PM, Cariboux said:

( Maybe I have made a mistake because when I have do the step 6 of @TDCroPower’s message, I only « wget » 3 packages of this link : http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.63-rockchip64/ : linux-dtb-current-rockchip64_21.08.2_arm64.deb , linux-headers-current-rockchip64_21.08.2_arm64.deb and linux-image-current-rockchip64_21.08.2_arm64.deb. I didn’t « wget » the 3 packages « 21.05.9 ».

(But, when i have try the downgrading with the Armbian_21.05.1_Helios64_buster_current_5.10.35 image on my MicroSD, i have « wget » all the three packages of http://armbian.hosthatch.com/apt/pool/main/l/linux-5.10.35-rockchip64/ . But it was not working neither....) )

Expand  

 

 

just  a note. The steps were to download from : 

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

not 5.10.63 ... but 5.10.63 will be fine too per

 ie 21.08.2 has the emmc fix.

1
Cariboux

Cariboux

Posted
Posted
  On 10/16/2021 at 8:27 PM, prahal said:

check that eMMC boot/armbianEnv.txt contains:
verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=a79a14c0-3cf4-4fb9-a6c6-838571351371
rootfstype=ext4
overlays=dwc3-0-host
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u

Expand  

 

I booted from the MicroSD (command « run bootcmd_mmc1 »). The command « sudo vim /boot/armbianEnv.txt » shows : 

  Reveal hidden contents

 

So, I added (with vim) the line « overlays=dwc3-0-host ». 

 

When I enter « sudo blkid », I have this : 

  Reveal hidden contents

 

I entered « fsck /dev/mmcblk2p1 » and it showed this : 

  Reveal hidden contents

 

I turned off the NAS, removed the MicroSD, turned on.... and... it’s not working...

What did I miss ? Do I have to change the « rootdev=UUID » in boot/armbianEnv.txt ? Remplacing the actual UUID of the MicroSD by the UUID of the eMMC ? 

(Note : now, if the MicroSD is in the NAS, this one boot automatically with no need of the command « run bootcmd_mmc1 »)

0
ebin-dev

ebin-dev

Posted
  • Author
Posted
  On 10/21/2021 at 11:41 AM, Cariboux said:

What did I miss ? Do I have to change the « rootdev=UUID » in boot/armbianEnv.txt ?

Expand  

 

On emmc (/dev/mmcblk2p1) you just need to replace the root UUID in /etc/fstab and in /boot/armbianEnv.txt to match the UUID of your emmc (e4e3bcd6-3f03-4362-bbe0-f1654138c5d8). Then reboot without microsd in the slot...

1
Cariboux

Cariboux

Posted
Posted
  On 10/21/2021 at 4:47 PM, ebin-dev said:

On emmc (/dev/mmcblk2p1) you just need to replace the root UUID in /etc/fstab and in /boot/armbianEnv.txt to match the UUID of your emmc (e4e3bcd6-3f03-4362-bbe0-f1654138c5d8). Then reboot without microsd in the slot...

Expand  

 

I am deeply sorry to ask such a beginner's question, but : how can I do that ? I mean : I know how to edit (with « sudo vim ») /etc/fstab and /boot/armbianEnv.txt, but I don’t know how to « reach » theses files in the eMMC (/dev/mmcblk2p1)...  

0
Werner

Werner

Posted
Posted

mount your eMMC to some random folder. mkdir ~/mount && mount /dev/mmcblk2p1 ~/mount && cd ~/mount

1
prahal

prahal

Posted
Posted

Beware ! Do not change your sdcard /boot/armbianEnv.txt. Only the one of the emmc ! thus /mnt/boot/armbianEnv.txt if you mount /dev/mmcblk2p1 to /mnt .

As I understood you checked the  /boot/armbianEnv.txt  of the Sdcard which is not right. If you boot from the sdcard then this one is correct, do not change it.

But check your emmc one is not corrupted. Thus /mnt/boot/armbianEnv.txt and compare with the one I gave.

 

As fsck showed your emmc partition was corrupted and fixed by fsck. Try to run 

fsck /dev/mmcblk2p1

as second time and paste output just to be confident it is now ok.

 

Then when yoiu boot without sdcard try to force u-boot to boot from emmc. 

run bootcmd_mmc0

from u-boot prompt.

 

Cheers. There are not many option for a failed boot. But check emmc not sdcard files.

From your lsblk output : 

rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8

 

0
Cariboux

Cariboux

Posted
Posted
  On 10/22/2021 at 1:43 PM, prahal said:

Beware ! Do not change your sdcard /boot/armbianEnv.txt. Only the one of the emmc ! thus /mnt/boot/armbianEnv.txt if you mount /dev/mmcblk2p1 to /mnt .

As I understood you checked the  /boot/armbianEnv.txt  of the Sdcard which is not right. If you boot from the sdcard then this one is correct, do not change it.

But check your emmc one is not corrupted. Thus /mnt/boot/armbianEnv.txt and compare with the one I gave.

Expand  

 

You are right ! : I made the mistake of editing the /boot/armbianEnv.txt of the SDcard. (I didn’t touch the UUID but I added this line « overlays=dwc3-0-host ».)

 

So, I followed what @Werner wrote (« mkdir ~/mount && mount /dev/mmcblk2p1 ~/mount && cd ~/mount ») and this is what I see with « root@helios64:~/mount# sudo vim /boot/armbianEnv.txt » : 

  Reveal hidden contents

 

 

« root@helios64:~/mount# sudo vim /mnt/boot/armbianEnv.txt » gives this (!) : 

  Reveal hidden contents

(Yes, it’s empty !)

 

 

« root@helios64:~/mount# sudo vim /etc/fstab » gives this : 

  Reveal hidden contents

 

 

And « root@helios64:~/mount# fsck /dev/mmcblk2p1 », that (...) : 

  Reveal hidden contents

 

 

0
ebin-dev

ebin-dev

Posted
  • Author
Posted
  On 10/22/2021 at 2:19 PM, Cariboux said:

« root@helios64:~/mount# sudo vim /mnt/boot/armbianEnv.txt » gives this (!) : 

  Reveal hidden contents

(Yes, it’s empty !)

Expand  

 

If you followed the example given by werner it should be mounted to /mount ...

Try this: sudo vim /mount/boot/armbianEnv.txt

0
prahal

prahal

Posted
Posted

If it is empty then you now know why u-boot fails to boot the kernl.

Mine was filled with garbage due to the FS corruption (due to the emmc bug)

 

Fill the emmc armbianEnv.txt with: 

echo 'verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8
rootfstype=ext4
overlays=dwc3-0-host
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u' > /mount/boot/armbianEnv.txt

and reboot. You are done !

1
Cariboux

Cariboux

Posted
Posted
  On 10/22/2021 at 4:35 PM, prahal said:

If it is empty then you now know why u-boot fails to boot the kernl.

Mine was filled with garbage due to the FS corruption (due to the emmc bug)

 

Fill the emmc armbianEnv.txt with: 

echo 'verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8
rootfstype=ext4
overlays=dwc3-0-host
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u' > /mount/boot/armbianEnv.txt

and reboot. You are done !

Expand  

 

I just tried it and it doesn't work (« "/mount/boot/armbianEnv.txt" E212: Can't open file for writing », with VIM). 

 

Then, I was struck by a doubt... So, I checked if armbianEnv.txt exists (in my eMMC). I have mount my eMMC as @Werner said (here). Then, I tried this : 

  Reveal hidden contents

As you can see, it seems that there is nothing except « system » in /mnt. No armbianEnv.txt here. 

 

But I have find armbianEnv.txt in /boot. Look : 

  Reveal hidden contents

So, I have edited this armbianEnv.txt here (with copy-paste of that ). 

 

I have checked the UUID in /etc/fstab (here). « root@helios64:/etc# sudo vim fstab » : 

  Reveal hidden contents

 

Then... I turned off the NAS..... removed the MicroSD.... restart.... and..... 

 

... It doesn't work !!! Same problem as usual : 

  Reveal hidden contents

(kernel never start.)

 

 

After that, I restarted with the MicroSD... as usual... and I see that (!) : 

  Reveal hidden contents

 

What I put in purple color is new for the situation. I guess I found my OMV installation, more or less !

0
Cariboux

Cariboux

Posted
Posted
  On 10/22/2021 at 6:28 PM, Cariboux said:

What I put in purple color is new for the situation. I guess I found my OMV installation, more or less !

Expand  

 

Confirmation : I’m able to connect to my OpenMediaVault with web browser. It’s here ! Thank god you, guys ! 

So, what do I do next ? Update OMV (and Armbian, via the Update Management of OMV) ? Or fix the eMMC boot problem ? 

0
prahal

prahal

Posted
Posted

You should settle the dust down. First check where you mount /dev/mmcblk2p1. Do you: 

mount /dev/mmcblk2p1 /mnt

or 

mount /dev/mmcblk2p1 /mount

?

Because the content of the emmc will show up in the above command right directory. It will not be in /mount  or /mnt if you did not made it so in the mount command.

 

Second give use the emmc boot/armbianEnv.txt because it could be  you set the sdcard armbianEnv.txt to boot with sdcard kernel and "rootdev" (ie boot partition) as emmc. Thus it works but you have to let the sdcard for the boot which is fragile.

It ought ot contains: 

verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=e4e3bcd6-3f03-4362-bbe0-f1654138c5d8
rootfstype=ext4
overlays=dwc3-0-host
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x231a:u

only. "echo" and "> /mount/boot/armbianEnv.txt" where only there so you could paste the full command and have it write the armbianEnv.txt in /mount/boot for you. If you write them down in armbianEnv.txt it kills boot.

 

Then feel free to update. I currenty run OMV with buster and armbian up to date on my helios64.

1
Trillien

Trillien

Posted
Posted
  On 9/16/2021 at 1:08 AM, prahal said:

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!
Expand  

 

Hi,

as I read this post, I'm not certain whether this rk808 regulator issue is solved yet.

For info, I'm currently running: 

kobol@helios64:~$ uname -a
Linux helios64 5.10.63-rockchip64 #21.08.2 SMP PREEMPT Wed Sep 8 10:57:23 UTC 2021 aarch64 GNU/Linux

 

and I have these logs (similar than @prahal for bad): 

kobol@helios64:~$ journalctl -b | grep regulator
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage pcie-power: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc3v3-sys-s3: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc3v0-sd: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc5v0-usb: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage usblan-power: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: vdd_log: supplied by regulator-dummy
Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs0 gpio
Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs1 gpio
Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: max buck steps per change: 4
Oct 30 14:47:58 helios64 kernel: rk808 0-001b: failed to register 12 regulator
Oct 30 14:47:58 helios64 kernel: fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
Oct 30 14:47:58 helios64 kernel: fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!
Oct 30 14:47:58 helios64 kernel: rockchip-saradc ff100000.saradc: failed to get regulator, -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc1v8-sys-s0: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage vcc0v9-s3: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-0v9-s0: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: reg-fixed-voltage avdd-1v8-s0: Failed to register regulator: -517
Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs0 gpio
Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: there is no dvs1 gpio
Oct 30 14:47:58 helios64 kernel: rk808-regulator rk808-regulator: max buck steps per change: 4
Oct 30 14:47:58 helios64 kernel: lm75 2-004c: supply vs not found, using dummy regulator
Oct 30 14:47:58 helios64 systemd[1]: Starting fan speed regulator...
Oct 30 14:47:59 helios64 systemd[1]: Started fan speed regulator.

 

Does there already exist a fix for such up-to-date kernel?

Regards,

0
Cariboux

Cariboux

Posted
Posted

Hello everyone,

 

Since the last time, I have good news and bad news.

 

I'll start with the good news : My NAS boots by itself, without the MicroSD card. (The problem was indeed on the side of the armbianEnv.txt file. The good one, I mean...) 

Without your help ( @prahal , @ebin-dev , @Werner , @IcerJo), I would never have managed to get out of it. Thank you so much, all of you! (I have made a small donation to the Armbian forum as a material thank you to the community.)

 

Now, for the bad news (sorry guys... :unsure: ) : My device is still not working properly. When I do " apt upgrade ", I get the following error message :

  Reveal hidden contents

 


On OpenMediaVault, when I make a change in the settings and go for the validation (" The configuration has been changed. You must apply the changes in order for them to take effect. "), the procedure fails and I get this error message :

  Reveal hidden contents

 

 

Does anyone have any idea what is going on this time? 

0
Victor B.

Victor B.

Posted
Posted

I upgraded with no problems. Honestly happy to see the stuff with Mesa moving along - you have a desktop with OpenGL acceleration out of the box. Thinking of trying some Retro gaming on it out of curiosity. Still looking out for transcoding or even just decoding.

0
TDCroPower

TDCroPower

Posted
Posted

On the actual topic.

 

Has anyone been able to upgrade an OMV 5 installation from Buster to Bullseye?
OMV 5 seems to use pam_tally2 and this is no longer supported in the current version of libpam-modules 1.4.0-9.
You are supposed to change this, but I read at OMV that the change was/will be implemented in OMV 6.

 

Is it possible to work around this without upgrading to OMV6 or do I have to get in with an OMV 5 -> OMV 6 upgrade first and then bullseye?
Unfortunately OMV 6 is only in release candidate 1 status.

962728318_Bildschirmfoto2022-04-02um23_47_09.thumb.png.c2fdce8d13c399a9eec65f0d7aff8f29.png

 

edit:

the attempt to edit the files used by OMV 5 with pam_tally2 with pam_faillock.so unfortunately did not work, because OMV 5 still searches for the pam_tally2 and thus a login in the WebInterface is not possible afterwards.

0
prahal

prahal

Posted
Posted

@TDCroPower OMV release are tied to a specific Debian release OMV 5 is buster only, OMV6 bullseye. OMV 6 should be pretty stable, a rc is close to release. As for the upgrade from google I get

https://forum.openmediavault.org/index.php?thread/40927-omv-5-omv-6-upgrade/&postID=288759#post288759 and https://www.openmediavault.org/?p=3010

votdev:
OMV5 systems with version 5.6.18 or later can be upgraded via the command line tool omv-release-upgrade. Please note that this migration path has not yet been tested with many systems.

 

I cannot tell for certain but I believe  omv-release-upgrade also upgrades Debian from buster to bullseye.

1
prahal

prahal

Posted
Posted
  On 9/16/2021 at 7:53 AM, ebin-dev said:
  On 9/16/2021 at 1:08 AM, 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.

Expand  

 

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

Expand  

 

@ebin-dev @piter75

I believe the upstream fix https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=8a866d527ac0441c0eb14a991fa11358b476b11d will do the job (in 6.1-rc1 so to be expected in Armbian edge if you want to try EMMC anew when it lands). This is likely the same issue as before the bad commit I pointed at the code only called set_machine_constraints once.  Still, requires testing (I saw that a lot of rk339 boards removed hs400 in Armbian, maybe that will fix them all).

  

regulator: core: Resolve supply name earlier to prevent double-init
Previously, an unresolved regulator supply reference upon calling
regulator_register on an always-on or boot-on regulator caused
set_machine_constraints to be called twice.

This in turn may initialize the regulator twice, leading to voltage
glitches that are timing-dependent. A simple, unrelated configuration
change may be enough to hide this problem, only to be surfaced by
chance.

One such example is the SD-Card voltage regulator in a NanoPI R4S that
would not initialize reliably unless the registration flow was just
complex enough to allow the regulator to properly reset between calls.

Fix this by re-arranging regulator_register, trying resolve the
regulator's supply early enough that set_machine_constraints does not
need to be called twice.

Signed-off-by: Christian Kohlschütter <christian@kohlschutter.com>
Link: https://lore.kernel.org/r/20220818124646.6005-1-christian@kohlschutter.com
Signed-off-by: Mark Brown <broonie@kernel.org>

 

Note that this fix reintroduce the less critical bug that was fixed by the bad commit I pinpointed namely sysfs entries issues; This was also fixed in 6.1-rc1 by commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/regulator/core.c?id=520fb178212d1dd545ed0ed231df09111b30ab7e "regulator: core: Fix regulator supply registration with sysfs"

1
prahal

prahal

Posted
Posted

@piter75@ebin-dev Feel free to confirm the rockchip emmc phy pulldown dts indeed fixes emmc write in hs400es mode (I believe on most rk3399 boards, not only helios64).

Likely on kernel up and above 6.1 (for the regulator fixes).

 

Thanks to @RussianNeuroMancer I found:

arm64: dts: rockchip: add enable-strobe-pulldown to emmc phy on nanopi4 https://github.com/torvalds/linux/commit/463be3cb357dab7d7e4d8dcc7c15c642e10c5bef

and:

phy: rockchip: set pulldown for strobe line in dts https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e

which might be related to this emmc issue (as noted in the mainline patch in the rockchip kernel this emmc pulldown setting is always enabled while in mainline it is disabled by default).


This patch was introduced in 5.11 which might explain why even with the regulator issue fixed (the one I found by regression testing) with kernel above 5.11 I still had hs400 failing on me.

 

With this emmc_phy pulldown setting in the dts I can now write to the emmc in hs400es mode !

means one have to add "rockchip,enable-strobe-pulldown;" in the emmc_phy node for most boards

  

---
 arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
index 69d76dea35d0..3c1965660fbd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-kobol-helios64.dts
@@ -436,10 +436,11 @@ &cpu_b0 {
 &cpu_b1 {
        cpu-supply = <&vdd_cpu_b>;
 };
 
 &emmc_phy {
+       rockchip,enable-strobe-pulldown;
        status = "okay";
 };
 
 &gmac {
        assigned-clocks = <&cru SCLK_RMII_SRC>;
@@ -965,13 +966,12 @@ &saradc {
 
 &sdhci {
        assigned-clock-rates = <150000000>;
        bus-width = <8>;
        mmc-hs200-1_8v;
-       // hs400 is broken on Helios64 since 5.10.60
-       // mmc-hs400-1_8v;
-       // mmc-hs400-enhanced-strobe;
+       mmc-hs400-1_8v;
+       mmc-hs400-enhanced-strobe;
        supports-emmc;
        non-removable;
        disable-wp;
        status = "okay";
        vqmmc-supply = <&vcc1v8_sys_s0>;
--

 

 

 

There is also the regulator fix.

Back then I bisected the first bad commit 06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66 which seems to have been a backport of the master branch to commit https://github.com/torvalds/linux/commit/98e48cd9283dbac0e1445ee780889f10b3d1db6a "regulator: core: resolve supply for boot-on/always-on regulators" introduced in 5.13.

I am pretty confident the regulator issues were fixed at least in linux 6.1.

 

Note that the emmc phy pulldown code was not backported to 5.10.y (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/phy/rockchip/phy-rockchip-emmc.c?h=linux-5.10.y)

So I believe it was first included in 5.11.

 

I no longer have the following CQE errors when writing to emmc in hs400es mode: 

[   18.985162] mmc1: running CQE recovery
[   18.988056] ------------[ cut here ]------------
[   18.988500] mmc1: cqhci: spurious TCN for tag 12
[   18.989019] WARNING: CPU: 0 PID: 269 at drivers/mmc/host/cqhci-core.c:787 cqhci_irq+0x4b4/0x640
[   18.989838] Modules linked in: quota_v2 quota_tree r8152 snd_soc_hdmi_codec ftdi_sio usbserial snd_soc_rockchip_i2s leds_pwm snd_soc_rockchip_pcm snd_soc_core snd_pcm_dmaengine snd_pcm pwm_fan gpio_charger snd_timer panfrost gpu_sched snd hantro_vpu(C) soundcore rockchip_vdec(C) v4l2_h264 rockchip_rga rockchip_iep videobuf2_dma_contig videobuf2_vmalloc videobuf2_dma_sg v4l2_mem2mem sg videobuf2_memops videobuf2_v4l2 videobuf2_common fusb302 videodev tcpm typec mc gpio_beeper cpufreq_dt nfsd dm_mod auth_rpcgss nfs_acl lockd grace ledtrig_netdev sunrpc lm75 ip_tables x_tables autofs4 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear raid10 uas realtek md_mod dwmac_rk stmmac_platform stmmac pcs_xpcs adc_keys
[   18.995876] CPU: 0 PID: 269 Comm: kworker/0:1H Tainted: G         C        5.15.29-rockchip64 #trunk.0010
[   18.996740] Hardware name: Helios64 (DT)
[   18.997104] Workqueue: kblockd blk_mq_run_work_fn
[   18.997555] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   18.998182] pc : cqhci_irq+0x4b4/0x640
[   18.998537] lr : cqhci_irq+0x4b4/0x640
[   18.998880] sp : ffff800008003d10
[   18.999179] x29: ffff800008003d10 x28: ffff0000012b8e80 x27: ffff000004c2d580
[   18.999819] x26: ffff00000652fc98 x25: ffff8000094d0888 x24: ffff800009c975e8
[   19.000462] x23: ffff8000094f49c8 x22: 0000000000000002 x21: ffff000004c2d000
[   19.001107] x20: 000000000000000c x19: ffff00000652fc80 x18: 0000000000000010
[   19.001754] x17: ffff8000ee03c000 x16: ffff800008004000 x15: 00000000000002f6
[   19.002400] x14: ffff800008003a20 x13: 00000000ffffffea x12: ffff800009abfbc8
[   19.003047] x11: 0000000000000003 x10: ffff800009aa7b88 x9 : ffff800009aa7be0
[   19.003694] x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001
[   19.004338] x5 : ffff8000ee03c000 x4 : 0000000000000000 x3 : 0000000000010004
[   19.004980] x2 : 0000000000010003 x1 : f94ce7e57b395a00 x0 : 0000000000000000
[   19.005623] Call trace:
[   19.005852]  cqhci_irq+0x4b4/0x640
[   19.006169]  sdhci_arasan_cqhci_irq+0x5c/0x88
[   19.006564]  sdhci_irq+0xcc/0x10c0
[   19.006876]  __handle_irq_event_percpu+0x60/0x250
[   19.007302]  handle_irq_event_percpu+0x38/0x90
[   19.007705]  handle_irq_event+0x48/0xe8
[   19.008058]  handle_fasteoi_irq+0xb8/0x148
[   19.008430]  handle_domain_irq+0x90/0xd8
[   19.008788]  gic_handle_irq+0xb8/0x138
[   19.009131]  call_on_irq_stack+0x28/0x50
[   19.009492]  do_interrupt_handler+0x58/0x68
[   19.009874]  el1_interrupt+0x30/0x78
[   19.010202]  el1h_64_irq_handler+0x18/0x28
[   19.010575]  el1h_64_irq+0x74/0x78
[   19.010889]  preempt_count_sub+0x34/0xc0
[   19.011251]  _raw_spin_unlock_irqrestore+0x20/0x40
[   19.011686]  sdhci_cqe_enable+0x130/0x228
[   19.012060]  sdhci_arasan_cqe_enable+0x94/0xb8
[   19.012465]  cqhci_request+0xd0/0x650
[   19.012808]  mmc_cqe_start_req+0xb4/0x198
[   19.013177]  mmc_blk_mq_issue_rq+0x494/0x9a8
[   19.013567]  mmc_mq_queue_rq+0x114/0x2b0
[   19.013928]  blk_mq_dispatch_rq_list+0x120/0x7e8
[   19.014355]  __blk_mq_sched_dispatch_requests+0xc4/0x1e0
[   19.014835]  blk_mq_sched_dispatch_requests+0x3c/0x78
[   19.015291]  __blk_mq_run_hw_queue+0x64/0xa0
[   19.015678]  blk_mq_run_work_fn+0x20/0x30
[   19.016042]  process_one_work+0x20c/0x4c8
[   19.016407]  worker_thread+0x48/0x478
[   19.016739]  kthread+0x138/0x150
[   19.017033]  ret_from_fork+0x10/0x20
[   19.017358] ---[ end trace 70e1eee6af816777 ]---
[   19.020419] mmc1: running CQE recovery
[   19.025922] mmc1: running CQE recovery
[   19.028135] blk_update_request: I/O error, dev mmcblk1, sector 1605640 op 0x1:(WRITE) flags 0x800 phys_seg 57 prio class 0
[   19.029190] Buffer I/O error on dev mmcblk1p1, logical block 196609, lost sync page write
[   19.029989] EXT4-fs error (device mmcblk1p1): ext4_check_bdev_write_error:218: comm sed: Error while async write back metadata
[   19.030191] Aborting journal on device mmcblk1p1-8.
[   19.032803] EXT4-fs (mmcblk1p1): Remounting filesystem read-only
[   19.033426] EXT4-fs error (device mmcblk1p1) in __ext4_new_inode:1136: Journal has aborted

 

 

Feel free to submit this patch to Armbian github or even to the mainline helios64 dts on your side.

0
prahal

prahal

Posted
Posted (edited)
  On 12/15/2023 at 8:44 AM, ebin-dev said:

I will test if linux 6.6 will write to emmc with hs400 speeds with those amendments to the device tree. 

Expand  

6.6 might be unstable, you could try the armbian repo 6.2 , that is linux-image-edge-rockchip64,  linux-headers-edge-rockchip64 and linux-dtb-edge-rockchip64 at version 23.11.1 (mind if you have both current and edge kernel there are issues when a current upgrade is push while you have a edge version previously installed, this is an armbian packaging issue though. BUt for the matter of testing it is fine).

Then ssh to the helios64 and edit the current dts with "armbian-config > System > Dtc"

emmc_phy settings are in the  "phy@f780" node (the default editor is nano, you can search with Ctrl+W).

Add " 

rockchip,enable-strobe-pulldown;

" under this node

then under the mmc@fe330000 node add:
  

mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;

confirm and reboot.

 

It could be that the pulldown setting is enough even before linux 6.1 (there were other core regulator fixes, but the most important one was added in 6.1), so you could try with lower kernel version.


  

root@helios64:~# hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
 Timing cached reads:   1888 MB in  2.00 seconds = 944.72 MB/sec
 Timing buffered disk reads: 552 MB in  3.00 seconds = 183.86 MB/sec

Note that EMMC on 6.6.7 /dev/mmcblk0 and SD /dev/mmcblk1


  

hdparm -tT /dev/mmcblk1

/dev/mmcblk1:
 Timing cached reads:   1858 MB in  2.00 seconds = 930.17 MB/sec
 Timing buffered disk reads: 128 MB in  3.10 seconds =  41.34 MB/sec

 

Edited by prahal
add stats
0

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept