Jump to content

"Gave up waiting for root file system device."

TMA-1

By TMA-1
in Allwinner sunxi

 Share

Recommended Posts

TMA-1

TMA-1

Posted
  • Author
Posted

Yeah, I'm afraid I don't have the skills or the time to even begin to digest that code scroll.  Neither do I hold out much hope that a 3A supply will help.  I am running 3A into a powered hub (among other combinations I've tried), and it still falls flat on its face 100% of the time.

 

I seem to be hearing that "it's just broken".  Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz , plus updates, equals "kaboom".  This is a pity, since I feel that my renewal and redeployment of the affected boxes I'm using was "relatively recent" in terms of what should still be supported.

 

This leaves me with 2 choices,... re-do the machines yet again (starting with a more current distribution), or forget about doing updates.  If there's another choice a neophyte can implement, I'm all ears.  In the mean time, no more updates for me.

 

My thanks to all those who chimed in to help and commiserate.  Best Regards, all.

0
grn

grn

Posted
Posted (edited)

I tried the brand new automated builds. The error persists.

 

I also tried to apply the rsb rollback patch from the orange pi 3 lts thread via ./compile.sh CREATE_PATCHES=yes and then altering sun50i-h6-orangepi.dtsi.

But it won't work. Boot is stuck forever at "Starting kernel ..." with verbosity=7 and console=serial

 

  

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi

index ee1919b80..15f4d7de9 100644

--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi

+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi

@@ -129,12 +129,12 @@ &r_pio {

 	vcc-pm-supply = <&reg_bldo3>;

 };

 

-&r_rsb {

+&r_i2c {

 	status = "okay";

 

-	axp805: pmic@745 {

+	axp805: pmic@36 {

 		compatible = "x-powers,axp805", "x-powers,axp806";

-		reg = <0x745>;

+		reg = <0x36>;

 		interrupt-parent = <&r_intc>;

 		interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_LOW>;

 		interrupt-controller;

 

Considering my last post. I set the build environment for the orange pi lite 2 wich has an Allwinner H6 and an AXP805 just like the orange pi one plus.

Build settings: Full OS image for flashing > Do not change the kernel configuration > orangepilite2 > current > Debian 11 Bullseye > Image with console interface (server) > Minimal image with console interface (Same settings for the orange pi one plus build)

 

~/build/cache/sources/arm-trusted-firmware-sunxi-mainline/v2.2/     is the folder that is created/downloaded for the orange pi one plus build

~/build/cache/sources/arm-trusted-firmware-sunxi-mainline/af220ebbe467aa580e6b9ba554676f78ffec930f/     is the folder that is created/downloaded for the orange pi lite 2
 

Edit: the v2.2 folder is also created/downloaded for the orange pi 3 and the orange pi 3 lts. (Both H6 and AXP805) Wich may explain why there are the same issues for (at least) the orange pi 3 lts in this thread where the OPs solution was the rollback from rsb to i2c. It makes sense that a user there has the exact same rsb related errors like TMA and me.

 

Comparing the folders and files for that two boards there seem to be missing files for the orange pi one plus build. The sunxi_power.c and platform.mk files are also different. Where the orange pi one plus files seem to be configured for i2c while the orange pi lite 2 files are configured for rsb.

 

tree is only for 3 specific folders that seem important to me considering rsb and axp805

  

orange pi one plus

~/build/cache/sources/arm-trusted-firmware-sunxi-mainline/v2.2/

drivers/allwinner
└── drivers/allwinner/sunxi_rsb.c

0 directories, 1 file
include/drivers/allwinner
└── include/drivers/allwinner/sunxi_rsb.h

0 directories, 1 file
plat/allwinner/sun50i_h6
├── plat/allwinner/sun50i_h6/include
│   ├── plat/allwinner/sun50i_h6/include/core_off_arisc.h
│   ├── plat/allwinner/sun50i_h6/include/sunxi_cpucfg.h
│   └── plat/allwinner/sun50i_h6/include/sunxi_mmap.h
├── plat/allwinner/sun50i_h6/platform.mk
└── plat/allwinner/sun50i_h6/sunxi_power.c

1 directory, 5 files
-------------------------------------------------------------------

orange pi lite 2

~/build/cache/sources/arm-trusted-firmware-sunxi-mainline/af220ebbe467aa580e6b9ba554676f78ffec930f

drivers/allwinner
├── drivers/allwinner/axp
│   ├── drivers/allwinner/axp/axp803.c
│   ├── drivers/allwinner/axp/axp805.c
│   └── drivers/allwinner/axp/common.c
├── drivers/allwinner/sunxi_msgbox.c
└── drivers/allwinner/sunxi_rsb.c

1 directory, 5 files
include/drivers/allwinner
├── include/drivers/allwinner/axp.h
└── include/drivers/allwinner/sunxi_rsb.h

0 directories, 2 files
plat/allwinner/sun50i_h6
├── plat/allwinner/sun50i_h6/include
│   ├── plat/allwinner/sun50i_h6/include/sunxi_ccu.h
│   ├── plat/allwinner/sun50i_h6/include/sunxi_cpucfg.h
│   ├── plat/allwinner/sun50i_h6/include/sunxi_mmap.h
│   ├── plat/allwinner/sun50i_h6/include/sunxi_mmap.h.orig
│   └── plat/allwinner/sun50i_h6/include/sunxi_spc.h
├── plat/allwinner/sun50i_h6/platform.mk
├── plat/allwinner/sun50i_h6/sunxi_idle_states.c
└── plat/allwinner/sun50i_h6/sunxi_power.c

1 directory, 8 files

 

As you can see orange pi one plus is missing the folder drivers/allwinner/axp wich is present in the orange pi lite 2 folder structure with files axp803.c axp805.c common.c that seem important. It is also missing the file include/drivers/allwinner/axp.h

 

For better overview here are the diffs

 

Tree diff: https://editor.mergely.com/gidNXnIs/
sunxi_power.c diff: https://editor.mergely.com/zZr8SxMc/

platform.mk diff: https://editor.mergely.com/3RSP9HmS/
 

Before that comparison I tried a bit to edit platform.mk and sunxi_power.c and build but got errors thrown. I may try it again with putting the missing axp folder and files. I doubt it will be successful. 

 

This still won't explain why Werner's opi1+ can boot. But to me it still seems that the opi1+ build is misconfigured with a mixture of i2c config plus missing rsb/axp related files.

 

I'am waiting for my USB-Voltmeter to arrive and may buy a sdxc card next month.

Kind regards

Edited by grn
checked folders for orange pi 3 and orange pi 3 lts
0
grn

grn

Posted
Posted

Thanks alot @nnb1972. This is at least good news to keep my sanity.

 

So my supposition that the Opi1+-PCB design or hardware may vary was not that wrong. But it is odd that this happens within the same revision (v2.1) of the PCB.

 

My Opi1+ sticker states: 2019042800100097

 

I will retry kernel 5.17 and test if it may boot sometimes as well.

 

Kind regards

0
nnb1972

nnb1972

Posted
Posted

Kernel 5.17.x booting

 

Sometimes I see:
 

  Reveal hidden contents

But more often:
 

  Reveal hidden contents

 

0
grn

grn

Posted
Posted

I tried about 30 times to boot kernel 5.17.x with micro-USB-cable and USB-DC-cable. Boot always fails.

  

[    1.501549] sunxi-rsb 7083000.rsb: RSB running at 3000000 Hz
[    1.501922] axp20x-rsb sunxi-rsb-745: AXP20x variant AXP806 found
[    1.502439] axp20x-rsb sunxi-rsb-745: Failed to set masks in 0x41: -5
[    1.502455] axp20x-rsb sunxi-rsb-745: failed to add irq chip: -5
[    1.502465] axp20x-rsb: probe of sunxi-rsb-745 failed with error -5
[    1.507487] sun50i-h6-pinctrl 300b000.pinctrl: initialized sunXi PIO driver
[    1.507899] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-ph not found, using dummy regulator

 

So either somebody with enough knowledge finds out what exactly is causing this and how to mitigate it or somebody is able to make a working rsb to i2c rollback patch.

Kind regards

0
gleam2003

gleam2003

Posted
Posted

I compile linux in buildroot with all armbian patch (5.10, 5.15) and try with different uboot and atf and I have the same problem.

Also I use the libreelec/lakka patch with buildroot and the board boot always without issue with linux kernel 5.10.109. (uboot+atf+crust)

0
grn

grn

Posted
Posted

Booting an older Armbian Focal image that works on my opi1+

  

apt update

apt remove linux-dtb-current-sunxi64 ( removes folder /boot/dtb-5.8.16-sunxi64 ) ( with a freezed up to date Armbian it would remove dtb-5.10.4-sunxi64 )

apt install linux-dtb-legacy-sunxi64 ( creates folder /boot/dtb-5.4.88-sunxi64 and links dtb to it )
apt upgrade

reboot

 

It boots kernel 5.15.43 but freezes a few seconds after it reaches the login credentials screen. (Typing fast I can login and run a command unitl it freezes) This is the only time a kernel newer than 5.10.4 is booting up on my opi1+.

 

  Reveal hidden contents

 

Boot does not work when I copy the files from dtb-5.8.16 to dtb-5.4.88 nor linking dtb to dtb-5.8.16 instead of dtb-5.4.88. In both cases it always hangs at Starting kernel ... I quite don't understand the dynamics for dtb "replacement" etc..

0
gleam2003

gleam2003

Posted
Posted (edited)

I build legacy kernel 5.10.121 and system boot fine. Kernel 5.10.121 use i2c.

 

I try to edit dtb and replace rsb wit i2c but system doesn't boot at all (on current kernel)

 

I don't understand why orangepi 3 lts use i2c and we can't use the same with this board

Edited by gleam2003
0
SergeIO

SergeIO

Posted
Posted

I have the same problem with Orange Pi One Plus.
Orangepioneplus_2.1.0_debian_buster_server_linux5.4.65.img is working fine.
Armbian_22.05.4_Orangepioneplus_bullseye_current_5.15.48.img (same SD card) doesn't boot with error:
Gave up waiting for boot file system device.  Common problems:

 - Boot args (cat /proc/cmdline)

  - Check rootdelay= (did the system wait long enough?)

 - Missing modules (cat /proc/modules; ls /drv)

ALERT! UUID=30a338a3-3c0d-4e45-b77b-5869b7a95606 does not exist.   Dropping to a shell!

(initramfs)

0
TMA-1

TMA-1

Posted
  • Author
Posted

Just got back from a short period off-line.  Excited to see there may be a "patch". 

 

Unfortunately my neophyte Linux skills and non-existent Github ones don't point me at anything I know how to use at the link above.  Has anyone tried it?  Does it work?

0
TMA-1

TMA-1

Posted
  • Author
Posted

Thanks for the compass heading grn.

 

While building an Armbian image looks like a good learning project for me and I may do it just for the experience some day, the truth is all this time I've been trying to avoid deploying a fresh image to my existing SBC.  I was hoping to somehow modify the existing configuration to "not break" when updates were applied.  I guess that's a pipe dream and I should get off my butt and re-deploy Armbian, one way or another.

 

My thanks and regards to all who chimed in on this saga.

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