Jump to content

prahal

  • Posts

    17
  • Joined

  • Last visited

Reputation Activity

  1. Like
    prahal got a reaction from TDCroPower in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    @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.
  2. Like
    prahal got a reaction from fraz0815 in Nanopc-T4 - New kernel 22.02 generates issues on mmc2 and makes system not properly working   
    @fraz0815 
    Could you try to revert those kernel commits :
    06653ebc0ad2e0b7d799cd71a5c2933ed2fb7a66
    and probably also aea6cb99703e17019e025aa71643b4d3e0a24413 (both commits are related).
     
      see
     
     
    Those commits are proper fixes but trigger the emmc hs400 breakage on helios64 rockchip 3399 .
  3. Like
    prahal got a reaction from Cariboux in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    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.
     
     
    The red is fine it is color for deb file type.
     
     
     
     
     
    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.
  4. Like
    prahal got a reaction from Cariboux in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    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 !
  5. Like
    prahal got a reaction from Cariboux in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    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.
  6. Like
    prahal got a reaction from hartraft in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    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!
  7. Like
    prahal got a reaction from TDCroPower in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    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!
  8. Like
    prahal got a reaction from Willy Moto in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    For step 3 there is a way out of tweaking Jumper 10 if you want to boot force boot on SD.
    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:
    run bootcmd_mmc1 and press enter. Helios64 will boot from SD.
    To force boot from eMMC instead of SD, do the opposite:
    run bootcmd_mmc0  
    This saved me from opening the box.
  9. Like
    prahal got a reaction from meymarce in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    For step 3 there is a way out of tweaking Jumper 10 if you want to boot force boot on SD.
    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:
    run bootcmd_mmc1 and press enter. Helios64 will boot from SD.
    To force boot from eMMC instead of SD, do the opposite:
    run bootcmd_mmc0  
    This saved me from opening the box.
  10. Like
    prahal got a reaction from TDCroPower in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    For step 3 there is a way out of tweaking Jumper 10 if you want to boot force boot on SD.
    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:
    run bootcmd_mmc1 and press enter. Helios64 will boot from SD.
    To force boot from eMMC instead of SD, do the opposite:
    run bootcmd_mmc0  
    This saved me from opening the box.
×
×
  • Create New...