TMA-1 Posted April 7, 2022 Posted April 7, 2022 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. 0 Quote
Werner Posted April 7, 2022 Posted April 7, 2022 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. 0 Quote
TMA-1 Posted April 8, 2022 Author Posted April 8, 2022 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. 0 Quote
Myron Posted April 9, 2022 Posted April 9, 2022 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. 0 Quote
Werner Posted April 9, 2022 Posted April 9, 2022 Allwinner SoCs usually use 115200 baud, AML too IIRC. Rockchip SoCs 1500000 baud 0 Quote
TMA-1 Posted April 9, 2022 Author Posted April 9, 2022 (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. 0 Quote
Myron Posted April 10, 2022 Posted April 10, 2022 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? 0 Quote
TMA-1 Posted April 11, 2022 Author Posted April 11, 2022 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. 0 Quote
Myron Posted April 11, 2022 Posted April 11, 2022 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. 0 Quote
Werner Posted April 11, 2022 Posted April 11, 2022 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? 0 Quote
TMA-1 Posted April 11, 2022 Author Posted April 11, 2022 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. 0 Quote
TMA-1 Posted April 11, 2022 Author Posted April 11, 2022 Okay, as long as I have it all set up, I tried it. stock Orange Pi One Plus deploy Armbian_21.05.1_Orangepioneplus_buster_current_5.10.34.img.xz (reboot--works) apt update apt upgrade attempt reboot Splat. 0 Quote
grn Posted April 12, 2022 Posted April 12, 2022 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 0 Quote
Werner Posted April 12, 2022 Posted April 12, 2022 Have you tried with a different sd card? "Wrong" cards sometimes can cause issues. 0 Quote
grn Posted April 12, 2022 Posted April 12, 2022 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. 0 Quote
Werner Posted April 12, 2022 Posted April 12, 2022 Either your sd cards, power supply, cable or board are defective. I just wrote a freshly downloaded on a sd and it booted right up: https://paste.debian.net/hidden/99d85a08/ Armbian_22.02.1_Orangepioneplus_focal_current_5.15.25.img.xz 0 Quote
TMA-1 Posted April 13, 2022 Author Posted April 13, 2022 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,... 0 Quote
Werner Posted April 13, 2022 Posted April 13, 2022 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 0 Quote
TMA-1 Posted April 13, 2022 Author Posted April 13, 2022 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. 0 Quote
grn Posted April 15, 2022 Posted April 15, 2022 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 0 Quote
Werner Posted April 16, 2022 Posted April 16, 2022 Grab the image Armbian_22.02.1_Orangepioneplus_focal_current_5.15.25.img.xz with the sha256sum e866af71bb063ddd7ad36074650b2944a2a3abc50decf1600c88157ab9964223 and you have the dtb. 0 Quote
grn Posted April 16, 2022 Posted April 16, 2022 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 0 Quote
TMA-1 Posted April 16, 2022 Author Posted April 16, 2022 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. 0 Quote
ManoftheSea Posted April 16, 2022 Posted April 16, 2022 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? 0 Quote
Werner Posted April 17, 2022 Posted April 17, 2022 On 4/12/2022 at 10:52 AM, Werner said: https://paste.debian.net/hidden/99d85a08/ Version is probably somewhere in the logs 0 Quote
grn Posted April 18, 2022 Posted April 18, 2022 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 0 Quote
TMA-1 Posted April 20, 2022 Author Posted April 20, 2022 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. 0 Quote
ManoftheSea Posted April 20, 2022 Posted April 20, 2022 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? 0 Quote
grn Posted April 22, 2022 Posted April 22, 2022 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, ®, 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 0 Quote
Recommended Posts
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.