Jump to content

prahal

Members
  • Posts

    105
  • Joined

  • Last visited

Reputation Activity

  1. Like
    prahal got a reaction from TDCroPower in Helios64 - Armbian 23.08 Bookworm issues (solved)   
    @TDCroPower I use "apt-mark hold <package>" and then on "apt upgrade" I get the package marked as hold told:
    The following packages have been kept back: linux-dtb-edge-rockchip64 linux-headers-edge-rockchip64 linux-image-edge-rockchip64 The following packages will be upgraded: openmediavault-compose still "apt list --upgradable" tells the on-hold packages as upgradable.
    I mean "apt-mark showhold" is the way to tell which packages will be kept on upgrade.
     
    For the second question, why on your second box you do not have linux-dtb-* and linux-image-* on hold, I can only guess from the armbian-config code (ie /usr/lib/armbian-config/jobs.sh and search for "Freeze") that armbian-config only Freeze the installed packages with the name including the BRANCH value from "grep BRANCH /etc/armbian-release".
    I believe if you have linux-dtb-edge-rockchip64 installed with BRANCH=current in /etc/armboan-release then armbian-config will fail to mark the package with "edge" instead of "current" in its name as on hold.
  2. Like
    prahal got a reaction from manman in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    Thanks a lot for the testing work.
    I am uneasy about sending this push request upstream, maybe only in armbian at first.
    The proper fix could end up being inverting the pulldown default value for the initial commit https://github.com/torvalds/linux/commit/8b5c2b45b8f0a11c9072da0f7baf9ee986d3151e in mainline.
     
        As was done for rk3588 boards:  "arm64: dts: rockchip: Fix eMMC Data Strobe PD on rk3588" https://github.com/torvalds/linux/commit/37f3d6108730713c411827ab4af764909f4dfc78 "
    With comment:
    JEDEC standard JESD84-B51 defines the eMMC Data Strobe line, which is currently used only in HS400 mode, as a device->host clock signal that "is used only in read operation. The Data Strobe is always High-Z (not driven by the device and pulled down by RDS) or Driven Low in write operation, except during CRC status response." RDS is a pull-down resistor specified in the 10K-100K ohm range. Thus per the standard, the Data Strobe is always pulled to ground (by the eMMC and/or RDS) during write operations. Evidently, the eMMC host controller in the RK3588 considers an active voltage on the eMMC-DS line during a write to be an error. The default (i.e. hardware reset, and Rockchip BSP) behavior for the RK3588 is to activate the eMMC-DS pin's builtin pull-down. As a result, many RK3588 board designers do not bother adding a dedicated RDS resistor, instead relying on the RK3588's internal bias. The current devicetree, however, disables this bias (`pcfg_pull_none`), breaking HS400-mode writes for boards without a dedicated RDS, but with an eMMC chip that chooses to High-Z (instead of drive-low) the eMMC-DS line. (The Turing RK1 is one such board.) Fix this by changing the bias in the (common) emmc_data_strobe case to reflect the expected hardware/BSP behavior. This is unlikely to cause regressions elsewhere: the pull-down is only relevant for High-Z eMMCs, and if this is redundant with a (dedicated) RDS resistor, the effective result is only a lower resistance to ground -- where the range of tolerance is quite high. If it does, it's better fixed in the specific devicetrees
     
    But that would requires board designers or the author of the above rk3588 commit to confirm the same is done on most rk3399 boards.
  3. Like
    prahal got a reaction from hartraft in Upgrading to Bullseye (troubleshooting Armbian 21.08.1)   
    @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"
  4. Like
    prahal got a reaction from ebin-dev in Helios64 u-boot does not build anymore after we bumped to 2022.07   
    PR https://github.com/armbian/build/pull/4480
  5. Like
    prahal got a reaction from iav in Helios64 u-boot does not build anymore after we bumped to 2022.07   
    PR https://github.com/armbian/build/pull/4480
  6. Like
    prahal got a reaction from Igor in Helios64 u-boot does not build anymore after we bumped to 2022.07   
    PR https://github.com/armbian/build/pull/4480
  7. 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.
  8. 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 .
  9. 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.
  10. 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 !
  11. 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.
  12. 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!
  13. 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!
  14. 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.
  15. 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.
  16. 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...

Important Information

Terms of Use - Privacy Policy - Guidelines