Jump to content

"Gave up waiting for root file system device."


TMA-1

Recommended Posts

Hello, I'm sort of an "educated noob" on Linux, meaning I understand about 1/2 of the postings in forums like this one.  :)

 

And I seem to have a problem.  I am using Armbian Buster on an Orange Pi One Plus.  After the most recent (to me) batch of updates, the machine will no longer boot.

 

The error is:  "Gave up waiting for root file system device."

 

This occurs after numerous instances of "Running /scripts/local-block", (which does not seem to exist), and is followed by "ALERT!  UUID=[valid UUID] does not exist.  Dropping to a shell!"

 

The "shell" it pro-ports to drop into is mythical, I assume because no keyboard driver has even been established.  The computer is completely unresponsive.  He's dead, Jim.

 

The only thing I can do is recover from backup, which dates back almost a year (I know, I know,...), so any re-application of updates now involves a basket  of 150 packages.  (I do not remember how recent the "killer" update may have been.)

 

I have recovered multiple times, trying this-and-that from old postings on the Net.  The lack of any more recent similar postings makes me think this problem is unique to me, but I don't know why.

 

There are no RAIDs involved.  I do not use encryption.  The UUIDs match across /boot/armbianEnv.txt, /etc/fstab, and the error message.

 

I have multiple instances of the Orange Pi hardware; they all exhibit the same problem.  Multiple uSD cards; same problem still.  And at least two different machine identities share this grief.  I simply cannot apply any updates since my backups were taken, without killing things.

 

What I CAN do is apply the updates, avoid restarting, and then make some kind of repair, if only I knew what that repair was!  The system runs fine until it's asked to shut down and restart.

 

Any guidance regarding where and how to look for a solution would be appreciated.

Link to comment
Share on other sites

Did you try with a fresh image to see if the issue persists?

Also simply telling on line in boot does not necessarily say anything about the real cause.

Attach serial console and put full boot log to a paste service of your choice.

Also make sure to increase boot verbosity if not done already. Check documentation on how to do that.

Link to comment
Share on other sites

Thank-you very much for the reply Werner.

 

If you mean "a fresh install" from distro, no, I haven't done that.  I'm trying to rescue the existing machines.  I have two separate machine identities (which do have a common ancestor, if we were to go back far enough), having their own backups each.  I have restored the two backups multiple times, tried something, applied updates, and then hit the brick wall in both cases, every time.

 

Getting a full boot log to a serial console is a great idea, and I've been working on doing that, but haven't quite figured it out yet.  I have verbosity=7 and console=both in /boot/armbianEnv.txt, and have a serial dongle, but have not yet gotten any traffic into a Putty session.  Obviously doing something wrong, and need to play with that more.

 

When I get back from travel this weekend I'll get back to doing that.

 

Thanks again for the compass heading.

Link to comment
Share on other sites

May be a question, but have you tried each of the three baud rates that getty is configured to use?  Those being 115200, 38400 and 9600?  I've had a few cases where for some reason the default baud rate was not being used and had to get putty to try the latter two baud rates to be able to get output from the board and be able to login and issue commands.

Link to comment
Share on other sites

(Still away).  I did try 115200 and 9600, but don't recall in what combination with other similar gotchas.  I'm sure it was something like that though,... just have to find the magic elixir that works, then I'll get back to the real problem.  Thanks for the support.

Link to comment
Share on other sites

Another thought. Have you bridged RX and TX together on the USB to RS232 board to make sure that the board is working?

Some of these boards have ab LED on the RX and TX lines. When you power-up your SoC board, do any or both of these LEDs blink?

Link to comment
Share on other sites

Okay I'm back.  And I got the logging to work.  For the record it was 115200 baud.  Thanks for thought to check the TTL-USB dongle Myron; I indeed did do that because it was one that I haven't proven in use before.  It was not the culprit, however.  We won't talk about what I was actually doing wrong.  (Oh, so THAT's what THOSE 3 lonely pins are!)

 

Here's hoping that the primary issue is as easy to solve.

 

The log from before I do updates (system booting fine), is here.

 

The log from after I do updates (and the system becomes a glorified brick), is here.

 

They look pretty similar to me up until a message on the "updated" system that something has tripped over a bad kernel command.  It's a little beyond my pay grade though.  I hope one of you gurus can hero it out.

Link to comment
Share on other sites

Yeh...  This one is also way above my pay grade.  I've had a manual kernel upgrade fail on me not that long ago and I resorted to building a brand new server image using the Armbian build framework and rescue my configurations from the bricked SD card into the new one.  This would be about a month ago. I've only very recently got this new-built system up to where it was before it became bricked.

Was it a simple apt update && apt upgrade that ended up bricking your system?  May be worth freezing kernel upgrades or getting a second SD card, cloning a working card into the other card so when an upgrade goes wrong, just take that card out and put in the cloned working card then suffer the headaches of trying to figure out what went wrong.

I'll admit that at this present moment in time I do not know how to start diagnosing this sort of problem.

 

Hopefully someone will see this thread have a AHA! moment and provide a solution or workaround.

Link to comment
Share on other sites

Odd. I have an OPI1+ here and running fine...

http://ix.io/3UQm

 

Did not test upgrade though, just fresh image.

 

Could you try the following: After upgrading via apt do NOT restart yet but to go armbian-config and go to System -> Install -> Install/Update bootloader

and then restart?

Link to comment
Share on other sites

Thanks Myron.  I do use 2 cards in rotation for speed, refreshing a card from the pre-updates image squirreled away on my PC when I want to try something.  Yes, it is just a simple apt update && apt upgrade that does it in.  Weird huh?

 

Werner,... tried it.  No appreciable difference I'm afraid.  The latest bootlog is here.


For information, the distribution image I started with was Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz

 

Then I probably did some installs and tailoring, but nothing that should spread any engine grease.  Now this current batch of upgrades, and "kaboom".

 

I could probably recreate the entire scenario from the initial install if desired.

Link to comment
Share on other sites

Hello,

 

first i want to say thanks to the Armbian team for all the hard work you put into it.

 

I have the same problem. Armbian (ubuntu) was running fine on my Orange Pi One Plus for 1 or 2 years. Doing apt update && apt upgrade from time to time without any problems. Some days ago after performing apt upgrade as usual after reboot it refused to boot.

First I flashed Armbian 22.02 Bullseye - no boot

Then I flashed Armbian 22.02 Focal and Jammy - no boot

Then I tried several version 21.*.* images from the archive

21.02.1 focal 5.10.12 - no boot
21.02.3 focal 5.10.21 - no boot

21.05.1 focal 5.10.34 - no boot

21.08.1 focal 5.10.60 - no boot

 

HDMI was connected. The Monitor had a signal but black screen and had several short flashes. After waiting long enough you could see the boot process stuck with the

"ALERT!  UUID=[valid UUID] does not exist.  Dropping to a shell!". Everytime I checked the UUID of SD-Card Partition and it was always the correct UUID.

 

Then i jumped to an older version.
20.11.10 focal 5.8.16 - boot OK

apt update && apt upgrade, reboot - no boot

flashed again.

apt update && apt upgrade, armbian-config > install/update bootloader, reboot - no boot

flashed again.
armbian-config > Freeze Kernel | apt update && apt upgrade, reboot - boot OK
So finding a version that boots up and freezing the kernel is the only thing that works for me right now.

I got USB to TTL working now. Verbosity=7 and console=serial. Here is the output for version 22.02 Focal
 

U-Boot SPL 2021.10-armbian (Feb 27 2022 - 08:51:38 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(debug):a04808c1-dirty
NOTICE:  BL31: Built : 08:51:29, Feb 27 2022
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc086c68, model: OrangePi One Plus
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
NOTICE:  PMIC: AXP805 detected
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9


U-Boot 2021.10-armbian (Feb 27 2022 - 08:51:38 +0000) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: OrangePi One Plus
DRAM:  1 GiB
MMC:   mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet found.
starting USB...
Bus usb@5101000: USB EHCI 1.00
Bus usb@5101400: USB OHCI 1.0
Bus usb@5311000: USB EHCI 1.00
Bus usb@5311400: USB OHCI 1.0
scanning bus usb@5101000 for devices... 1 USB Device(s) found
scanning bus usb@5101400 for devices... 1 USB Device(s) found
scanning bus usb@5311000 for devices... 1 USB Device(s) found
scanning bus usb@5311400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3202 bytes read in 6 ms (520.5 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
154 bytes read in 5 ms (29.3 KiB/s)
35349 bytes read in 12 ms (2.8 MiB/s)
4191 bytes read in 10 ms (409.2 KiB/s)
Applying kernel provided DT fixup script (sun50i-h6-fixup.scr)
## Executing script at 45000000
12462399 bytes read in 620 ms (19.2 MiB/s)
21735432 bytes read in 1078 ms (19.2 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41710000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    12462335 Bytes = 11.9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 4941d000, end 49fff8ff ... OK
   Loading Device Tree to 00000000493ac000, end 000000004941cfff ... OK

Starting kernel ...

U-Boot SPL 2021.10-armbian (Feb 27 2022 - 08:51:38 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.2(debug):a04808c1-dirty
NOTICE:  BL31: Built : 08:51:29, Feb 27 2022
NOTICE:  BL31: Detected Allwinner H6 SoC (1728)
NOTICE:  BL31: Found U-Boot DTB at 0xc086c68, model: OrangePi One Plus
INFO:    ARM GICv2 driver initialized
NOTICE:  PMIC: Probing AXP805
NOTICE:  PMIC: AXP805 detected
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9


U-Boot 2021.10-armbian (Feb 27 2022 - 08:51:38 +0000) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: OrangePi One Plus
DRAM:  1 GiB
MMC:   mmc@4020000: 0
Loading Environment from FAT... Unable to use mmc 0:1... In:    serial@5000000
Out:   serial@5000000
Err:   serial@5000000
Net:   No ethernet found.
starting USB...
Bus usb@5101000: USB EHCI 1.00
Bus usb@5101400: USB OHCI 1.0
Bus usb@5311000: USB EHCI 1.00
Bus usb@5311400: USB OHCI 1.0
scanning bus usb@5101000 for devices... 1 USB Device(s) found
scanning bus usb@5101400 for devices... 1 USB Device(s) found
scanning bus usb@5311000 for devices... 1 USB Device(s) found
scanning bus usb@5311400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3202 bytes read in 4 ms (781.3 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
156 bytes read in 3 ms (50.8 KiB/s)
35349 bytes read in 16 ms (2.1 MiB/s)
4191 bytes read in 8 ms (510.7 KiB/s)
Applying kernel provided DT fixup script (sun50i-h6-fixup.scr)
## Executing script at 45000000
12462399 bytes read in 628 ms (18.9 MiB/s)
21735432 bytes read in 1078 ms (19.2 MiB/s)
Moving Image from 0x40080000 to 0x40200000, end=41710000
## Loading init Ramdisk from Legacy Image at 4ff00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    12462335 Bytes = 11.9 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 4941d000, end 49fff8ff ... OK
   Loading Device Tree to 00000000493ac000, end 000000004941cfff ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.15.25-sunxi64 (root@be0d054872f0) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.02.1 SMP Sun Feb 27 09:24:04 UTC 2022
[    0.000000] Machine model: OrangePi One Plus
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] NUMA: NODE_DATA [mem 0x7fdce100-0x7fdcffff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
[    0.000000] cma: Reserved 128 MiB at 0x0000000076c00000
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.1
[    0.000000] percpu: Embedded 19 pages/cpu s36952 r8192 d32680 u77824
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258048
[    0.000000] Policy zone: DMA
[    0.000000] Kernel command line: root=UUID=a1483a27-5c10-4a32-b574-6102d8be806c rootwait rootfstype=ext4 console=ttyS0,115200 consoleblank=0 loglevel=7 ubootpart=3e3a004b-01 usb-storage.quirks=   cgroup_enable=memory swapaccount=1
[    0.000000] Unknown kernel command line parameters "ubootpart=3e3a004b-01 cgroup_enable=memory", will be passed to user space.
[    0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[    0.000000] printk: log_buf_len total cpu_extra contributions: 12288 bytes
[    0.000000] printk: log_buf_len min size: 16384 bytes
[    0.000000] printk: log_buf_len: 32768 bytes
[    0.000000] printk: early log buf free: 14208(86%)
[    0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 863104K/1048576K available (13440K kernel code, 1066K rwdata, 4128K rodata, 2496K init, 316K bss, 54400K reserved, 131072K cma-reserved)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] random: get_random_bytes called from start_kernel+0x4cc/0x6ac with crng_init=0
[    0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.000125] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[    0.000596] Console: colour dummy device 80x25
[    0.000686] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
[    0.000704] pid_max: default: 32768 minimum: 301
[    0.000786] LSM: Security Framework initializing
[    0.000820] Yama: becoming mindful.
[    0.000906] AppArmor: AppArmor initialized
[    0.000958] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.000975] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.002610] rcu: Hierarchical SRCU implementation.
[    0.003582] smp: Bringing up secondary CPUs ...
[    0.004371] Detected VIPT I-cache on CPU1
[    0.004441] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[    0.005071] Detected VIPT I-cache on CPU2
[    0.005112] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[    0.005674] Detected VIPT I-cache on CPU3
[    0.005711] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[    0.005779] smp: Brought up 1 node, 4 CPUs
[    0.005806] SMP: Total of 4 processors activated.
[    0.005814] CPU features: detected: 32-bit EL0 Support
[    0.005820] CPU features: detected: CRC32 instructions
[    0.018571] CPU: All CPU(s) started at EL2
[    0.018604] alternatives: patching kernel code
[    0.020006] devtmpfs: initialized
[    0.026504] Registered cp15_barrier emulation handler
[    0.026534] Registered setend emulation handler
[    0.026712] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.026735] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[    0.032733] pinctrl core: initialized pinctrl subsystem
[    0.033918] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.035501] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
[    0.035630] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.035762] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.035821] audit: initializing netlink subsys (disabled)
[    0.035965] audit: type=2000 audit(0.032:1): state=initialized audit_enabled=0 res=1
[    0.036520] thermal_sys: Registered thermal governor 'fair_share'
[    0.036526] thermal_sys: Registered thermal governor 'bang_bang'
[    0.036534] thermal_sys: Registered thermal governor 'step_wise'
[    0.036542] thermal_sys: Registered thermal governor 'user_space'
[    0.036974] cpuidle: using governor menu
[    0.037190] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[    0.037289] ASID allocator initialised with 65536 entries
[    0.037454] Serial: AMBA PL011 UART driver
[    0.048048] platform 6510000.tcon-top: Fixing up cyclic dependency with 6000000.hdmi
[    0.048414] platform 6515000.lcd-controller: Fixing up cyclic dependency with 6510000.tcon-top
[    0.049490] platform 7022000.pinctrl: Fixing up cyclic dependency with pmic@745 (7083000.rsb)
[    0.050315] platform connector: Fixing up cyclic dependency with 6000000.hdmi
[    0.057877] HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
[    0.057901] HugeTLB registered 32.0 MiB page size, pre-allocated 0 pages
[    0.057910] HugeTLB registered 2.00 MiB page size, pre-allocated 0 pages
[    0.057919] HugeTLB registered 64.0 KiB page size, pre-allocated 0 pages
[    0.059688] cryptd: max_cpu_qlen set to 1000
[    0.128274] raid6: neonx8   gen()  1586 MB/s
[    0.196344] raid6: neonx8   xor()  1186 MB/s
[    0.264439] raid6: neonx4   gen()  1624 MB/s
[    0.332510] raid6: neonx4   xor()  1175 MB/s
[    0.400603] raid6: neonx2   gen()  1535 MB/s
[    0.468670] raid6: neonx2   xor()  1078 MB/s
[    0.536767] raid6: neonx1   gen()  1338 MB/s
[    0.604840] raid6: neonx1   xor()   923 MB/s
[    0.672931] raid6: int64x8  gen()  1104 MB/s
[    0.740997] raid6: int64x8  xor()   580 MB/s
[    0.809078] raid6: int64x4  gen()  1226 MB/s
[    0.877157] raid6: int64x4  xor()   628 MB/s
[    0.945268] raid6: int64x2  gen()  1048 MB/s
[    1.013330] raid6: int64x2  xor()   555 MB/s
[    1.081431] raid6: int64x1  gen()   778 MB/s
[    1.149512] raid6: int64x1  xor()   405 MB/s
[    1.149521] raid6: using algorithm neonx4 gen() 1624 MB/s
[    1.149528] raid6: .... xor() 1175 MB/s, rmw enabled
[    1.149536] raid6: using neon recovery algorithm
[    1.150428] iommu: Default domain type: Translated
[    1.150442] iommu: DMA domain TLB invalidation policy: strict mode
[    1.150731] SCSI subsystem initialized
[    1.150943] usbcore: registered new interface driver usbfs
[    1.150987] usbcore: registered new interface driver hub
[    1.151023] usbcore: registered new device driver usb
[    1.151314] pps_core: LinuxPPS API ver. 1 registered
[    1.151324] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    1.151347] PTP clock support registered
[    1.151955] Advanced Linux Sound Architecture Driver Initialized.
[    1.152620] NetLabel: Initializing
[    1.152628] NetLabel:  domain hash size = 128
[    1.152635] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    1.152708] NetLabel:  unlabeled traffic allowed by default
[    1.153116] clocksource: Switched to clocksource arch_sys_counter
[    1.153306] VFS: Disk quotas dquot_6.6.0
[    1.153362] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    1.153968] AppArmor: AppArmor Filesystem Enabled
[    1.160675] NET: Registered PF_INET protocol family
[    1.160822] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)
[    1.161656] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
[    1.161689] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
[    1.161771] TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
[    1.161922] TCP: Hash tables configured (established 8192 bind 8192)
[    1.162040] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.162085] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[    1.162243] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    1.162758] Trying to unpack rootfs image as initramfs...
[    1.170259] hw perfevents: enabled with armv8_cortex_a53 PMU driver, 7 counters available
[    1.176112] Initialise system trusted keyrings
[    1.176178] Key type blacklist registered
[    1.176349] workingset: timestamp_bits=44 max_order=18 bucket_order=0
[    1.182178] zbud: loaded
[    1.183747] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    1.185999] integrity: Platform Keyring initialized
[    1.235129] xor: automatically using best checksumming function   32regs
[    1.235171] async_tx: api initialized (async)
[    1.235184] Key type asymmetric registered
[    1.235194] Asymmetric key parser 'x509' registered
[    1.235314] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 247)
[    1.235462] io scheduler mq-deadline registered
[    1.235472] io scheduler kyber registered
[    1.235671] io scheduler bfq registered
[    1.240114] sun50i-h6-r-pinctrl 7022000.pinctrl: initialized sunXi PIO driver
[    1.250738] Serial: 8250/16550 driver, 6 ports, IRQ sharing disabled
[    1.256402] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    1.260479] loop: module loaded
[    1.262675] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.262710] ehci-platform: EHCI generic platform driver
[    1.262853] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.262868] ohci-platform: OHCI generic platform driver
[    1.263284] usbcore: registered new interface driver usb-storage
[    1.263774] mousedev: PS/2 mouse device common for all mice
[    1.264673] sun6i-rtc 7000000.rtc: registered as rtc0
[    1.264694] sun6i-rtc 7000000.rtc: hctosys: unable to read the hardware clock
[    1.264810] sun6i-rtc 7000000.rtc: RTC enabled
[    1.264923] i2c_dev: i2c /dev entries driver
[    1.265651] sunxi-wdt 7020400.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[    1.267059] sdhci: Secure Digital Host Controller Interface driver
[    1.267079] sdhci: Copyright(c) Pierre Ossman
[    1.267106] Synopsys Designware Multimedia Card Interface Driver
[    1.267717] sdhci-pltfm: SDHCI platform and OF driver helper
[    1.267871] sun50i-h6-r-pinctrl 7022000.pinctrl: supply vcc-pl not found, using dummy regulator
[    1.268934] ledtrig-cpu: registered to indicate activity on CPUs
[    1.269466] sun8i-ce 1904000.crypto: Set mod clock to 300000000 (300 Mhz) from 24000000 (24 Mhz)
[    1.269737] sun8i-ce 1904000.crypto: will run requests pump with realtime priority
[    1.269871] sun8i-ce 1904000.crypto: will run requests pump with realtime priority
[    1.269967] sun8i-ce 1904000.crypto: will run requests pump with realtime priority
[    1.270060] sun8i-ce 1904000.crypto: will run requests pump with realtime priority
[    1.270149] sun8i-ce 1904000.crypto: Register cbc(aes)
[    1.270302] sun8i-ce 1904000.crypto: Register ecb(aes)
[    1.270414] sun8i-ce 1904000.crypto: Register cbc(des3_ede)
[    1.270530] sun8i-ce 1904000.crypto: Register ecb(des3_ede)
[    1.270637] sun8i-ce 1904000.crypto: Register md5
[    1.270746] sun8i-ce 1904000.crypto: Register sha1
[    1.270852] sun8i-ce 1904000.crypto: Register sha224
[    1.270979] sun8i-ce 1904000.crypto: Register sha256
[    1.271086] sun8i-ce 1904000.crypto: Register sha384
[    1.271195] sun8i-ce 1904000.crypto: Register sha512
[    1.271302] sun8i-ce 1904000.crypto: Register stdrng
[    1.272009] sun8i-ce 1904000.crypto: CryptoEngine Die ID 0
[    1.272503] hid: raw HID events driver (C) Jiri Kosina
[    1.272638] usbcore: registered new interface driver usbhid
[    1.272647] usbhid: USB HID core driver
[    1.273408] random: fast init done
[    1.274877] random: crng init done
[    1.275424] NET: Registered PF_INET6 protocol family
[    1.834931] Freeing initrd memory: 12168K
[    1.862467] Segment Routing with IPv6
[    1.862570] In-situ OAM (IOAM) with IPv6
[    1.862665] NET: Registered PF_PACKET protocol family
[    1.862776] 8021q: 802.1Q VLAN Support v1.8
[    1.862936] 9pnet: Installing 9P2000 support
[    1.863012] Key type dns_resolver registered
[    1.863422] registered taskstats version 1
[    1.863440] Loading compiled-in X.509 certificates
[    1.867300] Loaded X.509 cert 'Build time autogenerated kernel key: bcc3e2753dc7b0d253b541b07c1f0e6f1eedd00a'
[    1.870161] zswap: loaded using pool zstd/z3fold
[    1.870779] Key type ._fscrypt registered
[    1.870790] Key type .fscrypt registered
[    1.870798] Key type fscrypt-provisioning registered
[    1.871834] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, fsverity=no
[    1.885011] Key type encrypted registered
[    1.885049] AppArmor: AppArmor sha1 policy hashing enabled
[    1.885185] ima: No TPM chip found, activating TPM-bypass!
[    1.885221] ima: Allocated hash algorithm: sha1
[    1.885256] ima: No architecture policies found
[    1.885307] evm: Initialising EVM extended attributes:
[    1.885314] evm: security.selinux
[    1.885321] evm: security.SMACK64
[    1.885328] evm: security.SMACK64EXEC
[    1.885334] evm: security.SMACK64TRANSMUTE
[    1.885340] evm: security.SMACK64MMAP
[    1.885347] evm: security.apparmor
[    1.885353] evm: security.ima
[    1.885359] evm: security.capability
[    1.885365] evm: HMAC attrs: 0x1
[    1.896905] platform 1100000.mixer: Fixing up cyclic dependency with 6510000.tcon-top
[    1.897347] sun8i-mixer 1100000.mixer: Adding to iommu group 0
[    1.897942] sunxi-rsb 7083000.rsb: RSB running at 3000000 Hz
[    1.898314] axp20x-rsb sunxi-rsb-745: AXP20x variant AXP806 found
[    1.898766] axp20x-rsb sunxi-rsb-745: Failed to set masks in 0x40: -5
[    1.898781] axp20x-rsb sunxi-rsb-745: failed to add irq chip: -5
[    1.898792] axp20x-rsb: probe of sunxi-rsb-745 failed with error -5
[    1.903591] sun50i-h6-pinctrl 300b000.pinctrl: initialized sunXi PIO driver
[    1.903970] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-ph not found, using dummy regulator
[    1.904539] printk: console [ttyS0] disabled
[    1.904632] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 33, base_baud = 1500000) is a 16550A
[    3.312839] printk: console [ttyS0] enabled
[    3.318431] sun4i-drm display-engine: Adding to iommu group 0
[    3.343602] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff800008e05cf8)
[    3.351352] sun4i-drm display-engine: bound 6510000.tcon-top (ops 0xffff800008e09f20)
[    3.359462] sun4i-drm display-engine: bound 6515000.lcd-controller (ops 0xffff800008e00f08)
[    3.367876] sun8i-dw-hdmi 6000000.hdmi: supply hvcc not found, using dummy regulator
[    3.375980] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY)
[    3.386178] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver
[    3.394008] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff800008e05030)
[    3.401985] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[    3.409789] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes
[    3.418720] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes
[    3.419016] sun50i_cpufreq_nvmem: Using CPU speed bin speed0
[    3.432236] scpi_protocol scpi: SCP Protocol 0.0 Firmware 0.0.0 version
[    3.432347] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
[    3.439052] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
[    3.454533] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
[    3.461499] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
[    3.469968] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
[    3.477117] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 70
[    3.483993] sun50i-h6-pinctrl 300b000.pinctrl: pin-70 (300b000.pinctrl:70) status -517
[    3.493630] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
[    3.493847] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
[    3.500771] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
[    3.516247] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
[    3.524705] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
[    3.531860] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 70
[    3.538740] sun50i-h6-pinctrl 300b000.pinctrl: pin-70 (300b000.pinctrl:70) status -517
[    3.548350] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
[    3.548569] sun50i-h6-pinctrl 300b000.pinctrl: supply vcc-pf not found, using dummy regulator
[    3.555492] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
[    3.570967] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
[    3.579622] of_cfs_init
[    3.582197] of_cfs_init: OK
[    3.585193] ALSA device list:
[    3.588160]   No soundcards found.
[    3.592796] Freeing unused kernel memory: 2496K
[    3.617191] Run /init as init process
Loading, please wait...
Starting version 245.4-4ubuntu3.15
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=a1483a27-5c10-4a32-b574-6102d8be806c does not exist.  Dropping to a shell!


BusyBox v1.30.1 (Ubuntu 1:1.30.1-4ubuntu6.4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs) lsblk


I checked the UUID and it is correct.
 

The only error I can find is

1.898792] axp20x-rsb: probe of sunxi-rsb-745 failed with error -5

But that same error is displayed also with the working 20.11.10 focal 5.8.16 (kernel upgrades freezed) which is booting fine. So this should not be the problem. 

Hope that helps.
Kind regards grn

Link to comment
Share on other sites

8 GB SanDisk SDHC Card is the card i ran Armbian the last years without problems until the upgrade some days ago.

I also cross checked with a 64 GB SanDisk SDXC I Card with the same result(s).

The serial log in my previous post is from the 8 GB SanDisk SDHC Card.

 

I just flashed Armbian 22.02 Focal on the 64 GB SanDisk SDXC I Card. Same error. UUID is correct.

Pastebin 22.02 Focal 64 GB SanDisk SDXC I

Both SD cards boot Armbian 20.11.10 focal 5.8.16 just fine. Except of course you do an apt upgrade without freezing the kernel. Then both cards won't boot anymore. This behaviour directs me to the conclusion that both sd-cards are not faulty or "wrong". Of course it could be the case that both sd-cards are the culprit.

It bugs me that TMA-1 has the same error with a working Armbian installation after an apt upgrade in the same timeframe as I did.

I will now try the same image that TMA-1 uses as a base "Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz" and see if it boots and how it behaves on both cards.

Link to comment
Share on other sites

That is disappointing.  Like grn, my setup has been running for 1 or 2 years.  I am using 3 instances of board, (1 of which was traditionally "spare"), 3 uSD cards, and a well-proven and beefy PSU.  I have cross-checked the PSU and the connecting USB cord.  All work fine in other scenarios, as do their substitutes.

 

The problem only occurs after I apply the updates.

 

It seemed that depending on what distribution image was started from, something got applied in the apt update and apt upgrade process that threw a marble into the gearing.

 

So I too downloaded Armbian_22.02.1_Orangepioneplus_focal_current_5.15.25.img.xz experimentally from the Net today, and it surprised me by triggering the problem straight away!

 

Would not boot, claiming the UUID is incorrect.

 

Armbian_22.02.1_Orangepioneplus_bullseye_current_5.15.25.img.xz did the same thing.  The cancer, whatever it is, is spreading.  Or I'm going insane, or both.

 

Now I don't know what to think.  When logic fails, challenge the assumptions.

  • Is there any chance that differences exist in older OPi1+'s vs. newer ones?
  • Is there any chance that "fresh" downloads of the OS are somehow getting different images?
  • Could it somehow be related to the process of taking the ~.img.xz file onto the SD card?  (I think "No", because that wouldn't explain the update sinking things.)

Clutching at straws now,...

Link to comment
Share on other sites

1 hour ago, TMA-1 said:

Is there any chance that differences exist in older OPi1+'s vs. newer ones?

Unlikely but not impossible. Xulong is AFAIK not known to change components without hardware revision (Orange Pi Zero is an example here). Of course there is always minimal deviation with things like resistors (come with +/- 20% by default for example) but these variability is usually compensated from the circuit design itself.

1 hour ago, TMA-1 said:

Is there any chance that "fresh" downloads of the OS are somehow getting different images?

If the images have the same version number impossible. They have a checksum that can be validated. For the mentioned image above for example the sha256sum is e866af71bb063ddd7ad36074650b2944a2a3abc50decf1600c88157ab9964223

Even nightly images are numbered. For general changes to the source code you can follow our repository where all images are made from: https://github.com/armbian/build

1 hour ago, TMA-1 said:

Could it somehow be related to the process of taking the ~.img.xz file onto the SD card?  (I think "No", because that wouldn't explain the update sinking things.)

If you use one of the recommended tools to write your sd card (USBimager or balenaEtcher) then no, they handle both the decompression on-the-fly and verifying each block written.

 

For now I could change everything you can including PSU, cable, even connector, try powering via GPIO or microUSB instead of the recommended DC barrel jack, grab a brand new sdcard, no insanely hugh since some boards don't like that. For my tests I used both 32GB and 64GB sandisk extreme U3 A2 cards and work just fine.

 

Even if all these measures do not help do not give up since I was in a similar situation not so far in the past.

I though my beloved NanoPi R4S was fried since I could not get it boot up again even with a previously known-to-be-good sd w/ image. I was desperate. However for some reason I still do not get (and probably never will lol) a few month later I just gave it another shot and I was thankful I did not throw it in the bin like I did with my Neo3 since it booted straight up. No idea why but I was very happy. Maybe it needed a long cooldown :lol:

Link to comment
Share on other sites

Long cool-downs do seem to work sometimes, through one mechanism or another.  I have one cardboard box I call The Burnouts Box.  Things that appear beyond immediate hope go in there when the heart is reluctant to scrap them out entirely.

 

And things have come back from The Burnouts Box a few times, when my knowledge and skills have increased, or sometimes as you said, by just giving it another try at a later time.

 

Unfortunately in this case, I cannot believe there are so many spontaneous parallel hardware failures which only show up after updates.

 

There are 4 complete independent layouts in play, counting grn's.  That much coincidence is a poor bet imho, though they did give away the top $100,000 prize on Wheel of Fortune three days in a row recently.  :)   Anyway, thank-you all for your time and attention.

 

For the time being I am running my Pi-Hole and TorrentSlave as they are, and just avoiding The Killer Update.

 

Something will change,... eventually.

Link to comment
Share on other sites

My Orange Pi One Plus is version 2.1

Comparing dtb files of older Armbian versions that boot fine to dtb files of newer armbian versions that won't boot. The most obvious difference is that the working ones seem to use i2c for regulators and the not working ones use rsb for regulators.

After the "Killer Upgrade" the corresponding dtb file has changed from i2c to rsb. 

Reading this thread https://forum.armbian.com/topic/19846-orange-pi3-lts/page/4/ where the OP could boot the image but others could not boot that same image on the same versioned SBC.

 

In that thread jernej wrote: "Reason why OrangePi image has I2C and Armbian RSB is that switch from I2C to RSB happened with kernel 5.13 and OrangePi uses kernel 5.10, which predates this. If OrangePi releases image with newer kernel, it will most likely use RSB too. The only important differences could be in regulator settings (subnodes to axp), those are important settings to copy."

But later (end page 7, page8) they fix it with a patch "r_i2c" when building the image.


https://github.com/afaulkner420/build-opi3-lts/blob/master/patch/kernel/archive/sunxi-5.15/999-rollback-rsb.patch
 

In the process they suspected it to be that the OP (who could boot) had a PSU that was rated 5.25 V and all others had 5.0 V PSUs. But in the end they all could boot with their PSUs after the r_i2c patch was applied.

 

I tried to apply that patch to the sunxi-50i-h6-orangepi-one-plus.dtb (search and replace) but it did not work. I am quite not sure how to apply it the right way.

At this point I think it would be good if @Werner could upload his sunxi-50i-h6-orangepi-one-plus.dtb for comparison and testing. If boot fails too with this one I will buy a new supa fast SD-Card. If this won't help i will buy a new PSU. I am doubtful about the PSU because CPU stress tests run fine without any errors.

I tested 4 or 5 different PSUs with 2 USB-DC cables from orangepi shop and 1 USB OTG Cable. USB OTG had a bit less power draw than with USB-DC-cables but stress tests where running fine in all variations.

 

A paste of armbianmonitor -U on Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34 https://pastebin.com/Y7PtWE9r In Werner's paste you have a lot rsb related entries. At the end, section Interrupts, Werner's paste has

 

1283 49: 215 0 0 0 GICv2 140 Level sunxi-rsb 

which is not present in the older version. Where it is

1474 46: 918 0 0 0 GICv2 139 Level mv64xxx_i2c

instead.

 

Kind regards
 

Link to comment
Share on other sites

Alright. That makes no sense. As I tested all current Images several times. SHA256 sums got checked.

At this point I will compile some images and look how that goes. I guess this will also fail. So my last resort is the Version/Revision of the OpiOne+ you use.

I can imagine that TMA-1 has the same revision 2.1 as my board and you may have another revision.

I know different revision should not be the problem in most cases/boards.


However at this point I give up for now.

 

Thanks for the help.

Kind regards

Link to comment
Share on other sites

For the record my instances are 2.1 as well.

 

I don't completely follow what you've done grn, but it sounds like you've established that the same starting images have been used.  By the process of elimination,...

 

On 4/13/2022 at 1:38 AM, Werner said:

For my tests I used both 32GB and 64GB sandisk extreme U3 A2 cards and work just fine.

 

But I just checked my cards and 1 of the 3 I've been using is a U3 as well.  They're all 16GB though.  That shouldn't make a difference,...

 

Whatever this is, it's over my head. 

Link to comment
Share on other sites

I find it interesting that it's failing in the middle of the initramfs scripts, rather than while loading the kernel.  u-boot loaded the initramfs, but it's the linux kernel that can't find its root partition

 

Another thing to take interest in is that the bootloader isn't part of the image.  TMA-1 and grn aren't working.  I see "U-Boot 2021.10-armbian (Feb 27 2022 - 08:51:38 +0000) Allwinner Technology" and "U-Boot 2021.04-armbian (May 06 2021 - 18:28:08 +0000) Allwinner Technology".  What's Werner (with a functional board) using?

Link to comment
Share on other sites

Werner's u-boot is 2021.10
877 ii linux-u-boot-orangepioneplus-current 22.02.1 arm64 Uboot loader 2021.10

U-Boot 2021.04 boot ok with i2c - vcc-5v are set in boot process

U-Boot 2021.10 boot ok with rsb for werner  vcc-5v are set in boot process / no boot with rsb for TMA-1 & grn - vcc-5v are not set in boot process

 

u-boot 2021.10 TMA-1 & grn same errors
...
[ 2.082594] axp20x-rsb sunxi-rsb-745: AXP20x variant AXP806 found
[ 2.083042] axp20x-rsb sunxi-rsb-745: Failed to set masks in 0x40: -5
[ 2.083067] axp20x-rsb sunxi-rsb-745: failed to add irq chip: -5
[ 2.083084] axp20x-rsb: probe of sunxi-rsb-745 failed with error -5
...
 u-boot 2021.10 Werner
 243  [    1.898304] axp20x-rsb sunxi-rsb-745: AXP20x variant AXP806 found
 244  [    1.899335] input: axp20x-pek as /devices/platform/soc/7083000.rsb/sunxi-rsb-745/axp221-pek/input/input0
 245  [    1.900104] vdd-cpu: supplied by vcc-5v
 246  [    1.900510] vdd-gpu: supplied by vcc-5v
 247  [    1.900626] vdd-sys: Bringing 900000uV into 960000-960000uV
 248  [    1.900680] vdd-sys: supplied by vcc-5v


in this case no voltages get set like in Werner's fine boot. In old u-boot with i2c voltages get set fine for TMA-1 and me though. (search for vcc-5v in u-boot 2021.04 pastebins voltages get set for cpu, gpu, etc..)

 

In u-boot 2021.10 voltages don't get set in TMA-1's and my case. Searching for vcc gives 0 results.

 

u-boot 2021.04 axp found, voltages get set
...
[ 4.672875] input: axp20x-pek as /devices/platform/soc/7081400.i2c/i2c-1/1-0036/axp221-pek/input/input0
...
[ 4.888408] vdd-cpu: supplied by vcc-5v
...
[ 4.937073] vdd-gpu: supplied by vcc-5v
...
[    4.999341] vdd-sys: supplied by vcc-5v
[    5.093139] vcc-dram: supplied by vcc-5v
[    5.103622] vcc-pl: supplied by vcc-5v
[    5.113706] vcc-ac200: Bringing 700000uV into 3300000-3300000uV
...

 

If the boot would fail after voltages get set successfuly then I would suspect the psu.

My OrangePiOne+ has an AXP805 chip. As far as I can read here the AXP805 gets handled as AXP806. At least for OpenBSD.
https://www.mail-archive.com/arm@openbsd.org/msg02346.html 

 

>       { "x-powers,axp221", "AXP221", axp221_regdata, axp221_sensdata },
>       { "x-powers,axp223", "AXP223", axp221_regdata, axp221_sensdata },
>       { "x-powers,axp803", "AXP803", axp803_regdata, axp803_sensdata },
> +     { "x-powers,axp805", "AXP805", axp806_regdata },
>       { "x-powers,axp806", "AXP806", axp806_regdata },
>       { "x-powers,axp809", "AXP809", axp809_regdata, axp221_sensdata }

 

All OpiOne+ pictures I could find had an AXP805.

 

searching for "Failed to set masks in 0x40: -5" does not bring that many results but one with at least the exact matching error. In that case it is an AXP808 "talked to" at the right register but with the wrong value.
https://lkml.iu.edu/hypermail/linux/kernel/1702.2/00795.html

 

This brings me further away from a bad psu/sdcard causing this.

Kind regards

Link to comment
Share on other sites

Thank-you grn for all your hard work.

 

I'm going to show my linux noob colors again (as stated at the top of this thread), and admit that I only "half follow" what is obviously a well-researched and well-presented analysis.

 

If I'm hearing this all correctly, it sounds like whether or not you get torpedoed by "killer updates" depends on what version of u-boot you have.

 

On 4/16/2022 at 5:51 PM, ManoftheSea said:

Another thing to take interest in is that the bootloader isn't part of the image.

 

Total noob question:  If it's not part of the distribution image, where does the u-boot (I'm not even sure what that is) come from?

 

Not to get ahead of myself, but my bottom line question would be:  How would one go about fixing it?

 

Best wishes.

Link to comment
Share on other sites

Well, I guess I do have to correct something I stated, and turn it into a question.  Does the u-boot package, built and distributed as part of Armbian, flash the u-boot bootloader to the boot sequence?  On some boards, I believe it does not.  I'm not familiar with whether the allwinner family does or not.

 

IF the u-boot isn't flashed except upon user interaction, then the version of the package werner posted isn't definitive as to the version of u-boot. 

 

IF it's an old version of u-boot that works, the fix would be to flash an old version from archives, right?

Link to comment
Share on other sites

No problem. I'am also not that deep into that stuff. Trial and erroring my way through. Just trying to get an understanding of what exactly is causing this.

 

(Das) U-Boot is an open-source, primary boot loader used in embedded devices to package the instructions to boot the device's operating system kernel. It is available for a number of computer architectures, including 68k, ARM, Blackfin, MicroBlaze, MIPS, Nios, SuperH, PPC, RISC-V and x86. Some compare it loose to the BIOS. https://en.wikipedia.org/wiki/Das_U-Boot

 

Quote

Does the u-boot package, built and distributed as part of Armbian, flash the u-boot bootloader to the boot sequence?

 

I struggle a bit to interpret your question the right way. I guess, because orangepi has no built in Bootloader/BIOS u-boot is mandatory and the first thing to happen when powering an orangepi sbc.

 

U-boot is part of the armbian-image (that is downloaded from the armbian website). We just have an older version of u-boot because we use an older armbian-image to be able to boot armbian. Which makes sense.

I don't think it is the u-boot-version that causes trouble. The most obvious change (I can see) is the switch from i2c bus to rsb bus in newer armbian versions. (linux-dtb-current-sunxi64, maybe armbian-firmware too)

 

Freezing the Armbian kernel via armbian-config 4 packages get set on hold for apt

xxx@orangepioneplus:~$ apt-mark showhold
armbian-firmware
linux-dtb-current-sunxi64
linux-image-current-sunxi64
linux-u-boot-orangepioneplus-current

These 4 packages seem interdependent. so just holding back u-boot for updates won't work.

 

Set linux-u-boot-orangepioneplus-current on hold; apt upgrade > no boot

Set linux-u-boot-orangepioneplus-current AND linux-dtb-current-sunxi64 on hold; apt upgrade > no boot

Set linux-u-boot-orangepioneplus-current AND linux-dtb-current-sunxi64 AND armbian-firmware on hold; apt upgrade > no boot

-------------

 

old (i2c) sunxi_power.c probe for axp805 snippet from random git (lost link)

...
static int axp805_probe(void)
{
    int ret;
    uint8_t val;
    ret = axp_i2c_write(AXP805_ADDR, 0xff, 0x0);
    if (ret) {
        ERROR("PMIC: Cannot put AXP805 to master mode.\n");
        return -EPERM;
    }
    ret = axp_i2c_read(AXP805_ADDR, AXP805_ID, &val);
    if (!ret && ((val & 0xcf) == 0x40))
        NOTICE("PMIC: AXP805 detected\n");
    else if (ret) {
        ERROR("PMIC: Cannot communicate with AXP805.\n");
        return -EPERM;
    } else {
        ERROR("PMIC: Non-AXP805 chip attached at AXP805's address.\n");
        return -EINVAL;
    }
    return 0;
}
...

 

I can't read C code that well. I assume it checks for AXP805 at 0x40 or does a test write in 0x40. Question stays, why AXP805 is detected fine via i2c but fails for TMA-1 and me via rsb but succeeds for Werner via i2c & rsb? If the board, psu, cable or sd-card is faulty why does it work flawlessly with i2c? Why would i2c have so much more tolerance?

 

Compiling: searching the build folder you only find 2 files named sunxi_power.c 
one in folder sun50i_h6

one in folder sun50i_a64

both folders also contain a file named platform.mk

 

cat build/cache/sources/arm-trusted-firmware-sunxi-mainline/v2.2/plat/allwinner/sun50i_a64/platform.mk

#
# Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#

# The differences between the platform are covered by the include files.
include plat/allwinner/common/allwinner-common.mk

PLAT_BL_COMMON_SOURCES	+=	drivers/allwinner/sunxi_rsb.c

 

cat build/cache/sources/arm-trusted-firmware-sunxi-mainline/v2.2/plat/allwinner/sun50i_h6/platform.mk

#
# Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#

# The differences between the platform are covered by the include files.
include plat/allwinner/common/allwinner-common.mk

PLAT_BL_COMMON_SOURCES	+=	drivers/mentor/i2c/mi2cv.c

 

sun50i_a64 points to the driver sunxi_rsb.c

but sun50i_h6 points to the driver mi2cv.c

 

Examining the sunxi_power.c files you can see the one in the sun50i_h6 folder has no entries and no includes to rsb or the sunxi_rsb.h driver. Only i2c related entries..

In contrast examining the sunxi_power.c in the sun50i_a64 folder it includes the sunxi_rsb.h driver, has rsb entries and two i2c related entries.

 

cat build/cache/sources/arm-trusted-firmware-sunxi-mainline/v2.2/plat/allwinner/sun50i_h6/sunxi_power.c                                                                
/*                                                                                                                                                                                           
 * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.                                                                                                               
 * Copyright (c) 2018, Icenowy Zheng <icenowy@aosc.io>                                                                                                                                       
 *                                                                                                                                                                                           
 * SPDX-License-Identifier: BSD-3-Clause                                                                                                                                                     
 */                                                                                                                                                                                          
                                                                                                                                                                                             
#include <errno.h>                                                                                                                                                                           
#include <string.h>

#include <arch_helpers.h>
#include <common/debug.h>
#include <drivers/delay_timer.h>
#include <drivers/mentor/mi2cv.h>
#include <lib/mmio.h>

#include <sunxi_def.h>
#include <sunxi_mmap.h>
#include <sunxi_private.h>

#define AXP805_ADDR     0x36
#define AXP805_ID       0x03

enum pmic_type {
        NO_PMIC,
        AXP805,
};

enum pmic_type pmic;

int axp_i2c_read(uint8_t chip, uint8_t reg, uint8_t *val)
{
        int ret;

        ret = i2c_write(chip, 0, 0, &reg, 1);
        if (ret)
                return ret;

        return i2c_read(chip, 0, 0, val, 1);
}

int axp_i2c_write(uint8_t chip, uint8_t reg, uint8_t val)
{
        return i2c_write(chip, reg, 1, &val, 1);
}

static int axp805_probe(void)
{
        int ret;
        uint8_t val;

        ret = axp_i2c_write(AXP805_ADDR, 0xff, 0x0);
        if (ret) {
                ERROR("PMIC: Cannot put AXP805 to master mode.\n");
                return -EPERM;
        }

        ret = axp_i2c_read(AXP805_ADDR, AXP805_ID, &val);

        if (!ret && ((val & 0xcf) == 0x40))
                NOTICE("PMIC: AXP805 detected\n");
        else if (ret) {
                ERROR("PMIC: Cannot communicate with AXP805.\n");
                return -EPERM;
        } else {
                ERROR("PMIC: Non-AXP805 chip attached at AXP805's address.\n");
                return -EINVAL;
        }

        return 0;
}

int sunxi_pmic_setup(uint16_t socid, const void *fdt)
{
        int ret;

        sunxi_init_platform_r_twi(SUNXI_SOC_H6, false);
        /* initialise mi2cv driver */
        i2c_init((void *)SUNXI_R_I2C_BASE);

        NOTICE("PMIC: Probing AXP805\n");
        pmic = AXP805;

        ret = axp805_probe();
        if (ret)
                pmic = NO_PMIC;
        else
                pmic = AXP805;

        return 0;
}

void __dead2 sunxi_power_down(void)
{
        uint8_t val;

        switch (pmic) {
        case AXP805:
                /* Re-initialise after rich OS might have used it. */
                sunxi_init_platform_r_twi(SUNXI_SOC_H6, false);
                /* initialise mi2cv driver */
                i2c_init((void *)SUNXI_R_I2C_BASE);
                axp_i2c_read(AXP805_ADDR, 0x32, &val);
                axp_i2c_write(AXP805_ADDR, 0x32, val | 0x80);
                break;
        default:
                break;
        }

        udelay(1000);
        ERROR("PSCI: Cannot communicate with PMIC, halting\n");
        wfi();
        panic();
}

 

cat build/cache/sources/arm-trusted-firmware-sunxi-mainline/v2.2/plat/allwinner/sun50i_a64/sunxi_power.c

/*
 * Copyright (c) 2017-2018, ARM Limited and Contributors. All rights reserved.
 * Copyright (c) 2018, Icenowy Zheng <icenowy@aosc.io>
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

#include <errno.h>

#include <libfdt.h>

#include <platform_def.h>

#include <arch_helpers.h>
#include <common/debug.h>
#include <drivers/allwinner/sunxi_rsb.h>
#include <drivers/delay_timer.h>
#include <lib/mmio.h>

#include <sunxi_def.h>
#include <sunxi_mmap.h>
#include <sunxi_private.h>

static enum pmic_type {
	GENERIC_H5,
	GENERIC_A64,
	REF_DESIGN_H5,	/* regulators controlled by GPIO pins on port L */
	AXP803_RSB,	/* PMIC connected via RSB on most A64 boards */
} pmic;

#define AXP803_HW_ADDR	0x3a3
#define AXP803_RT_ADDR	0x2d

/*
 * On boards without a proper PMIC we struggle to turn off the system properly.
 * Try to turn off as much off the system as we can, to reduce power
 * consumption. This should be entered with only one core running and SMP
 * disabled.
 * This function only cares about peripherals.
 */
void sunxi_turn_off_soc(uint16_t socid)
{
	int i;

	/** Turn off most peripherals, most importantly DRAM users. **/
	/* Keep DRAM controller running for now. */
	mmio_clrbits_32(SUNXI_CCU_BASE + 0x2c0, ~BIT_32(14));
	mmio_clrbits_32(SUNXI_CCU_BASE + 0x60, ~BIT_32(14));
	/* Contains msgbox (bit 21) and spinlock (bit 22) */
	mmio_write_32(SUNXI_CCU_BASE + 0x2c4, 0);
	mmio_write_32(SUNXI_CCU_BASE + 0x64, 0);
	mmio_write_32(SUNXI_CCU_BASE + 0x2c8, 0);
	/* Keep PIO controller running for now. */
	mmio_clrbits_32(SUNXI_CCU_BASE + 0x68, ~(BIT_32(5)));
	mmio_write_32(SUNXI_CCU_BASE + 0x2d0, 0);
	/* Contains UART0 (bit 16) */
	mmio_write_32(SUNXI_CCU_BASE + 0x2d8, 0);
	mmio_write_32(SUNXI_CCU_BASE + 0x6c, 0);
	mmio_write_32(SUNXI_CCU_BASE + 0x70, 0);

	/** Turn off DRAM controller. **/
	mmio_clrbits_32(SUNXI_CCU_BASE + 0x2c0, BIT_32(14));
	mmio_clrbits_32(SUNXI_CCU_BASE + 0x60, BIT_32(14));

	/** Migrate CPU and bus clocks away from the PLLs. **/
	/* AHB1: use OSC24M/1, APB1 = AHB1 / 2 */
	mmio_write_32(SUNXI_CCU_BASE + 0x54, 0x1000);
	/* APB2: use OSC24M */
	mmio_write_32(SUNXI_CCU_BASE + 0x58, 0x1000000);
	/* AHB2: use AHB1 clock */
	mmio_write_32(SUNXI_CCU_BASE + 0x5c, 0);
	/* CPU: use OSC24M */
	mmio_write_32(SUNXI_CCU_BASE + 0x50, 0x10000);#include <drivers/allwinner/sunxi_rsb.h>

	/** Turn off PLLs. **/
	for (i = 0; i < 6; i++)
		mmio_clrbits_32(SUNXI_CCU_BASE + i * 8, BIT(31));
	switch (socid) {
	case SUNXI_SOC_H5:
		mmio_clrbits_32(SUNXI_CCU_BASE + 0x44, BIT(31));
		break;
	case SUNXI_SOC_A64:
		mmio_clrbits_32(SUNXI_CCU_BASE + 0x2c, BIT(31));
		mmio_clrbits_32(SUNXI_CCU_BASE + 0x4c, BIT(31));
		break;
	}
}

static int rsb_init(void)
{
	int ret;

	ret = rsb_init_controller();
	if (ret)
		return ret;

	/* Start with 400 KHz to issue the I2C->RSB switch command. */
	ret = rsb_set_bus_speed(SUNXI_OSC24M_CLK_IN_HZ, 400000);
	if (ret)
		return ret;

	/*
	 * Initiate an I2C transaction to write 0x7c into register 0x3e,
	 * switching the PMIC to RSB mode.
	 */
	ret = rsb_set_device_mode(0x7c3e00);
	if (ret)
		return ret;

	/* Now in RSB mode, switch to the recommended 3 MHz. */
	ret = rsb_set_bus_speed(SUNXI_OSC24M_CLK_IN_HZ, 3000000);
	if (ret)
		return ret;

	/* Associate the 8-bit runtime address with the 12-bit bus address. */
	return rsb_assign_runtime_address(AXP803_HW_ADDR,
					  AXP803_RT_ADDR);
}

static int axp_write(uint8_t reg, uint8_t val)
{
	return rsb_write(AXP803_RT_ADDR, reg, val);
}

static int axp_clrsetbits(uint8_t reg, uint8_t clr_mask, uint8_t set_mask)
{
	uint8_t regval;
	int ret;

	ret = rsb_read(AXP803_RT_ADDR, reg);
	if (ret < 0)
		return ret;

	regval = (ret & ~clr_mask) | set_mask;

	return rsb_write(AXP803_RT_ADDR, reg, regval);
}

#define axp_clrbits(reg, clr_mask) axp_clrsetbits(reg, clr_mask, 0)
#define axp_setbits(reg, set_mask) axp_clrsetbits(reg, 0, set_mask)

static bool should_enable_regulator(const void *fdt, int node)
{
	if (fdt_getprop(fdt, node, "phandle", NULL) != NULL)
		return true;
	if (fdt_getprop(fdt, node, "regulator-always-on", NULL) != NULL)
		return true;
	return false;
}

/*
 * Retrieve the voltage from a given regulator DTB node.
 * Both the regulator-{min,max}-microvolt properties must be present and
 * have the same value. Return that value in millivolts.
 */
static int fdt_get_regulator_millivolt(const void *fdt, int node)
{
	const fdt32_t *prop;
	uint32_t min_volt;

	prop = fdt_getprop(fdt, node, "regulator-min-microvolt", NULL);
	if (prop == NULL)
		return -EINVAL;
	min_volt = fdt32_to_cpu(*prop);

	prop = fdt_getprop(fdt, node, "regulator-max-microvolt", NULL);
	if (prop == NULL)
		return -EINVAL;

	if (fdt32_to_cpu(*prop) != min_volt)
		return -EINVAL;

	return min_volt / 1000;
}

#define NO_SPLIT 0xff

static const struct axp_regulator {
	char *dt_name;
	uint16_t min_volt;
	uint16_t max_volt;
	uint16_t step;
	unsigned char split;
	unsigned char volt_reg;
	unsigned char switch_reg;
	unsigned char switch_bit;
} regulators[] = {
	{"dcdc1", 1600, 3400, 100, NO_SPLIT, 0x20, 0x10, 0},
	{"dcdc5",  800, 1840,  10,       32, 0x24, 0x10, 4},
	{"dcdc6",  600, 1520,  10,       50, 0x25, 0x10, 5},
	{"dldo1",  700, 3300, 100, NO_SPLIT, 0x15, 0x12, 3},
	{"dldo2",  700, 4200, 100,       27, 0x16, 0x12, 4},
	{"dldo3",  700, 3300, 100, NO_SPLIT, 0x17, 0x12, 5},
	{"fldo1",  700, 1450,  50, NO_SPLIT, 0x1c, 0x13, 2},
	{}
};

static int setup_regulator(const void *fdt, int node,
			   const struct axp_regulator *reg)
{
	int mvolt;
	uint8_t regval;

	if (!should_enable_regulator(fdt, node))
		return -ENOENT;

	mvolt = fdt_get_regulator_millivolt(fdt, node);
	if (mvolt < reg->min_volt || mvolt > reg->max_volt)
		return -EINVAL;

	regval = (mvolt / reg->step) - (reg->min_volt / reg->step);
	if (regval > reg->split)
		regval = ((regval - reg->split) / 2) + reg->split;

	axp_write(reg->volt_reg, regval);
	if (reg->switch_reg < 0xff)
		axp_setbits(reg->switch_reg, BIT(reg->switch_bit));

	INFO("PMIC: AXP803: %s voltage: %d.%03dV\n", reg->dt_name,
	     mvolt / 1000, mvolt % 1000);

	return 0;
}

static void setup_axp803_rails(const void *fdt)
{
	int node;
	bool dc1sw = false;

	/* locate the PMIC DT node, bail out if not found */
	node = fdt_node_offset_by_compatible(fdt, -1, "x-powers,axp803");
	if (node < 0) {
		WARN("BL31: PMIC: Cannot find AXP803 DT node, skipping initial setup.\n");
		return;
	}

	if (fdt_getprop(fdt, node, "x-powers,drive-vbus-en", NULL)) {
		axp_clrbits(0x8f, BIT(4));
		axp_setbits(0x30, BIT(2));
		INFO("PMIC: AXP803: Enabling DRIVEVBUS\n");
	}

	/* descend into the "regulators" subnode */
	node = fdt_subnode_offset(fdt, node, "regulators");
	if (node < 0) {
		WARN("BL31: PMIC: Cannot find regulators subnode, skipping initial setup.\n");
		return;
	}

	/* iterate over all regulators to find used ones */
	for (node = fdt_first_subnode(fdt, node);
	     node >= 0;
	     node = fdt_next_subnode(fdt, node)) {
		const struct axp_regulator *reg;
		const char *name;
		int length;

		/* We only care if it's always on or referenced. */
		if (!should_enable_regulator(fdt, node))
			continue;

		name = fdt_get_name(fdt, node, &length);
		for (reg = regulators; reg->dt_name; reg++) {
			if (!strncmp(name, reg->dt_name, length)) {
				setup_regulator(fdt, node, reg);
				break;
			}
		}

		if (!strncmp(name, "dc1sw", length)) {
			/* Delay DC1SW enablement to avoid overheating. */
			dc1sw = true;
			continue;
		}
	}
	/*
	 * If DLDO2 is enabled after DC1SW, the PMIC overheats and shuts
	 * down. So always enable DC1SW as the very last regulator.
	 */
	if (dc1sw) {
		INFO("PMIC: AXP803: Enabling DC1SW\n");
		axp_setbits(0x12, BIT(7));
	}
}

int sunxi_pmic_setup(uint16_t socid, const void *fdt)
{
	int ret;

	switch (socid) {
	case SUNXI_SOC_H5:
		pmic = REF_DESIGN_H5;
		NOTICE("BL31: PMIC: Defaulting to PortL GPIO according to H5 reference design.\n");
		break;
	case SUNXI_SOC_A64:
		pmic = GENERIC_A64;
		ret = sunxi_init_platform_r_twi(socid, true);
		if (ret)
			return ret;

		ret = rsb_init();
		if (ret)
			return ret;

		pmic = AXP803_RSB;
		NOTICE("BL31: PMIC: Detected AXP803 on RSB.\n");

		if (fdt)
			setup_axp803_rails(fdt);

		break;
	default:
		NOTICE("BL31: PMIC: No support for Allwinner %x SoC.\n", socid);
		return -ENODEV;
	}
	return 0;
}

void __dead2 sunxi_power_down(void)
{
	switch (pmic) {
	case GENERIC_H5:
		/* Turn off as many peripherals and clocks as we can. */
		sunxi_turn_off_soc(SUNXI_SOC_H5);
		/* Turn off the pin controller now. */
		mmio_write_32(SUNXI_CCU_BASE + 0x68, 0);
		break;
	case GENERIC_A64:
		/* Turn off as many peripherals and clocks as we can. */
		sunxi_turn_off_soc(SUNXI_SOC_A64);
		/* Turn off the pin controller now. */
		mmio_write_32(SUNXI_CCU_BASE + 0x68, 0);
		break;
	case REF_DESIGN_H5:
		sunxi_turn_off_soc(SUNXI_SOC_H5);

		/*
		 * Switch PL pins to power off the board:
		 * - PL5 (VCC_IO) -> high
		 * - PL8 (PWR-STB = CPU power supply) -> low
		 * - PL9 (PWR-DRAM) ->low
		 * - PL10 (power LED) -> low
		 * Note: Clearing PL8 will reset the board, so keep it up.
		 */
		sunxi_set_gpio_out('L', 5, 1);
		sunxi_set_gpio_out('L', 9, 0);
		sunxi_set_gpio_out('L', 10, 0);

		/* Turn off pin controller now. */
		mmio_write_32(SUNXI_CCU_BASE + 0x68, 0);

		break;
	case AXP803_RSB:
		/* (Re-)init RSB in case the rich OS has disabled it. */
		sunxi_init_platform_r_twi(SUNXI_SOC_A64, true);
		rsb_init();

		/* Set "power disable control" bit */
		axp_setbits(0x32, BIT(7));
		break;
	default:
		break;
	}

	udelay(1000);
	ERROR("PSCI: Cannot turn off system, halting.\n");
	wfi();
	panic();
}

 

Of course the a64 sunxi_power.c would not work because of different hardware adresses, etc..

I thought i might replace the i2c driver line in the platform.mk with the rsb driver line and replace the sunxi_power.c in the sun50i_h6 folder with this one: https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/allwinner/sun50i_h6/sunxi_power.c

But using the armbian compile tool it overwrites those files in the process with the default i2c files.

 

How could i modify those files so that they dont get overwritten in the process? 

 

https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/allwinner/sun50i_h6/sunxi_power.c

/*
 * Copyright (c) 2017-2019, ARM Limited and Contributors. All rights reserved.
 * Copyright (c) 2018, Icenowy Zheng <icenowy@aosc.io>
 *
 * SPDX-License-Identifier: BSD-3-Clause
 */

#include <errno.h>

#include <common/debug.h>
#include <drivers/allwinner/axp.h>
#include <drivers/allwinner/sunxi_rsb.h>
#include <lib/mmio.h>

#include <sunxi_cpucfg.h>
#include <sunxi_def.h>
#include <sunxi_mmap.h>
#include <sunxi_private.h>

#define AXP805_HW_ADDR	0x745
#define AXP805_RT_ADDR	0x3a

static enum pmic_type {
	UNKNOWN,
	AXP805,
} pmic;

int axp_read(uint8_t reg)
{
	return rsb_read(AXP805_RT_ADDR, reg);
}

int axp_write(uint8_t reg, uint8_t val)
{
	return rsb_write(AXP805_RT_ADDR, reg, val);
}

static int rsb_init(void)
{
	int ret;

	ret = rsb_init_controller();
	if (ret)
		return ret;

	/* Switch to the recommended 3 MHz bus clock. */
	ret = rsb_set_bus_speed(SUNXI_OSC24M_CLK_IN_HZ, 3000000);
	if (ret)
		return ret;

	/* Initiate an I2C transaction to switch the PMIC to RSB mode. */
	ret = rsb_set_device_mode(AXP20X_MODE_RSB << 16 | AXP20X_MODE_REG << 8);
	if (ret)
		return ret;

	/* Associate the 8-bit runtime address with the 12-bit bus address. */
	ret = rsb_assign_runtime_address(AXP805_HW_ADDR, AXP805_RT_ADDR);
	if (ret)
		return ret;

	return axp_check_id();
}

int sunxi_pmic_setup(uint16_t socid, const void *fdt)
{
	int ret;

	INFO("PMIC: Probing AXP805 on RSB\n");

	ret = sunxi_init_platform_r_twi(socid, true);
	if (ret)
		return ret;

	ret = rsb_init();
	if (ret)
		return ret;

	/* Switch the AXP805 to master/single-PMIC mode. */
	ret = axp_write(0xff, 0x0);
	if (ret)
		return ret;

	pmic = AXP805;
	axp_setup_regulators(fdt);

	/* Switch the PMIC back to I2C mode. */
	ret = axp_write(AXP20X_MODE_REG, AXP20X_MODE_I2C);
	if (ret)
		return ret;

	return 0;
}

void sunxi_power_down(void)
{
	switch (pmic) {
	case AXP805:
		/* (Re-)init RSB in case the rich OS has disabled it. */
		sunxi_init_platform_r_twi(SUNXI_SOC_H6, true);
		rsb_init();
		axp_power_off();
		break;
	default:
		break;
	}
}

void sunxi_cpu_power_off_self(void)
{
	u_register_t mpidr = read_mpidr();
	unsigned int core  = MPIDR_AFFLVL0_VAL(mpidr);

	/* Enable the CPUIDLE hardware (only really needs to be done once). */
	mmio_write_32(SUNXI_CPUIDLE_EN_REG, 0x16aa0000);
	mmio_write_32(SUNXI_CPUIDLE_EN_REG, 0xaa160001);

	/* Trigger power off for this core. */
	mmio_write_32(SUNXI_CORE_CLOSE_REG, BIT_32(core));
}

 

Iam still pretty sure that the sunxi_power.c for h6 is configured for i2c while the dtb is configured for rsb and thus you get the "axp20x-rsb sunxi-rsb-745: Failed to set masks in 0x40: -5" error.


So or so this goes way over my head too. For now I have ordered a 5V/3A PSU. Just in case. If that does not solve the error I will get a Sandisk Extreme U3 A2 SD card. If the error persists I guess then I have a faulty board that works flawless with i2c.


Kind regards

Link to comment
Share on other sites

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.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines