Continually Reboots

[ArmBoy1988]

Was using my Orange Pi 5 and it rebooted on it's own.  After that, it continually reboots.  Been running fine for months.

 

Tried restarting a few times.  Tried swapping SD cards.  It looks like the power supply is OK, although I'll try swapping with another.  I had just backed up the SD Card too.  I'll try re-imaging an SD card, but I'm thinking the SD card may not be the issue.

 

I hooked up my UART and captured output.  At the end of each loop, it looks like it's saying "Starting Kernel" and then restarting.  Captured output follows.

 

Any ideas, suggestions or comments on what's happening.  I'm thinking it's probably a hardware issue.  I purchased on Amazon.  Can't find out how long the warranty/if it's still under warranty.

 

  DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
LPDDR4X, 2112MHz

CH2 RX Vref:27.5%, TX Vref:19.8%,20.8%
CH3 RX Vref:30.1%, TX
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 156out
U-Boot SPL board init
U-Boot SPL 2017.09 (Jun 30 2023 - 19unknown raw ID 0 0 0
unrecognized JEDEC id bytes: 00, 00, 00
TTrying fit image at 0x4000 sector
## Verified-boot: 0
## Check## Checking uboot 0x00200000 ... sha256(bab9643a63...) + OK
##  atf-3 0x000f0000 ... sha256(da90adf3a4...) + OK
Jumping to U-B.622 ms

INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():vrt detected.
INFO:    ARM GICv3 driver initialized in EL3
INFOams[0].freq_mhz= 2112MHz
INFO:    dfs DDR fsp_params[1].freq_mhz= 528MHz
INFO:    dfs DDR fsp_params[2].freq_mhz= 1068MHz
INFINFO:    BL31: Initialising Exception Handling Framework
INFO:  initializing runtime service opteed_fast
INFO:    BL31: Prepar 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.09 (Jun 30 202CR: M/C/I
Using default environment

mmc@fe2c0000: 0, mmc@fe2Bootdev(atags): mmc 0
MMC0: Legacy, 52Mhz
PartType: EFI
DM: vCLK: (sync kernel. arm: enter 1008000 KHz, init 1008000 KHz, kerpll 1188000 KHz
  npll 24000 KHz
  ppll 1100000 KHz
  aclk_ceer_root 396000 KHz
  aclk_center_low_root 500000 KHz
  aclk_toot 396000 KHz
Net:   No ethernet found.
Hit key to stop autobo-Boot script /boot.scr
reading /boot.scr
3476 bytes read in 1 ded from mmc 0
reading /armbianEnv.txt
212 bytes read in 2 ms 15248365 bytes read in 1223 ms (11.9 MiB/s)
reading /Image
34638336 bytes read in 2777 ms (11.9 MiB/s)
reading /dtb/rockch234611 bytes read in 30 ms (7.5 MiB/s)
** Unable to read file /OK
## Flattened Device Tree blob at 0x0a100000
   Booting usin000000000a1a1fff
Adding bank: 0x00200000 - 0xf0000000 (size: 0xize: 0x03a00000)
Adding bank: 0x4f0000000 - 0x500000000 (size: Total: 4379.611 ms

Starting kernel ...

  DDR V1.11 f1474cf52f cym 23/05/09-11:02:36
LPDDR4X, 2112MHz
cher ID:0x6
CH0 RX Vref:28.5%, TX Vref:20.8%,20.8%
CH1 RX Vref:2
CH2 RX Vref:27.5%, TX Vref:20.8%,19.8%
CH3 RX Vref:29.3%, TX
change to F1: 528MHz
change to F2: 1068MHz
change to F3: 156out
U-Boot SPL board init
U-Boot SPL 2017.09 (Jun 30 2023 - 19Trying fit image at 0x4000 sector
## Verified-boot: 0
## Check## Checking uboot 0x00200000 ... sha256(bab9643a63...) + OK
## .902 ms

INFO:    Preloader serial: 2
NOTICE:  BL31: v2.3():vINFO:    ddr: stride-en 4CH
INFO:    GICv3 without legacy suppo:    system boots from cpu-hwid-0
INFO:    idle_st=0x21fff, pd_ams[0].freq_mhz= 2112MHz
INFO:    dfs DDR fsp_params[1].freq_mhINFO:    BL31: Initialising Exception Handling Framework
INFO:

U-Boot 2017.09 (Jun 30 2023 - 19:08:39 +0200)

Model: OranCR: M/C/I
Using default environment

mmc@fe2c0000: 0, mmc@fe2Bootdev(atags): mmc 0
MMC0: Legacy, 52Mhz
PartType: EFI
DM: vCLK: (sync kernel. arm: enter 1008000 KHz, init 1008000 KHz, kerot 396000 KHz
Net:   No ethernet found.
Hit key to stop autoboms (3.3 MiB/s)
## Executing script at 00500000
Boot script loa15248365 bytes read in 1223 ms (11.9 MiB/s)
reading /Image
34638336 bytes read in 2776 ms (11.9 MiB/s)
reading /dtb/rockch234611 bytes read in 29 ms (7.7 MiB/s)
** Unable to read file /p compressed)
   Data Size:    15248301 Bytes = 14.5 MiB
   LoOK
## Flattened Device Tree blob at 0x0a100000
   Booting usinefe00000)
Adding bank: 0x100000000 - 0x3fc000000 (size: 0x2fc00ize: 0x03a00000)
Adding bank: 0x4f0000000 - 0x500000000 (size: Total: 4378.924 ms

Starting kernel ...

 

[Werner]

Change everything to known-good

- sdcard

- PSU

- cables (!)

- Armbian image

 

If the behavior does not change the board is probably broken.

[eselarm]

Do as Werner says I think, although setting

verbosity=7

in armbianEnv.txt will likely show you where it fails

[ArmBoy1988]

Good news, I guess.

 

I tried the verbosity=7 to see if extra info would be useful.  No extra info.  However, on multiple "loops", sometimes it was going past the "starting kernel" line.

 

I have several OPi 5s so I tried the power supply from another one and it successfully booted!!!  Yay!  I was thinking it had to be some hardware issue.  This, the PSU, is much better than the board being bad.

 

I bought the power supply on Amazon:

 

https://www.amazon.ca/gp/product/B0BMGJNSVS

 

So, I'll try to get warranty and otherwise buy another.

 

Thanks for your comments, help and interest.

[Werner]

Fact is the Opi5, just like many other SBCs actually prefer being fed with slight over-voltage to compensate for losses across wiring and connectors.

 

This is why, for example, the official PSU from RaspberryPi is labeled with 5.1 volts output and the official PSU from Orangepi, even though labaled as 5V actually outputs around 5.2 volts.

The reason is that with such low voltages losses as mentioned across wiring and connectors become significant and the voltage will drop even further on load spikes.

 

 

A while ago I did some measurements on my opi5 so I could experience and see the voltage drops by myself. For that I measured both output voltage at the PSU, which was 5.2 volts, and at on of the  USB-A ports of the OPi5 which were at around 5.1 volts while the board being idle. 0.1 volts loss across wires, connectors and the PCB just for being powered on and doing nothing.

Putting a heavy load on the board and the voltage dropped to something between 4.8 and 4.9 volts across everything except PSU which kept its voltage constant. At least my meter could not detect a drop higher than 10mV.

 

Now thing about having a bad/crappy PSU. It is VERY likely that the voltage also breaks down directly at the source which adds up across the already mentioned losses. And boom, your board throws all kinds of issues which are hard to explain. Just because of undervoltage.

 

 

 

[eselarm]

13 hours ago, ArmBoy1988 said:

I tried the verbosity=7 to see if extra info would be useful.  No extra info.  However, on multiple "loops", sometimes it was going past the "starting kernel" line.

 

I have several OPi 5s so I tried the power supply from another one and it successfully booted!!!  Yay!  I was thinking it had to be some hardware issue.  This, the PSU, is much better than the board being bad.

My Rock3A was getting a bit further, so I could benefit from verbosity=7, although it got into trouble somewhere related to NPU (could not draw any conclusion from that anyway).

I am looking for an extra RK3588 (not RK3588S) board, maybe OPi5, many options, need more study what is most effective w.r.t. 12V off-grid powering.

 

After I looked into schematics of Rock3A it got more clear to me how I need and want powering. The Rock3A has on-board 5V 8A DC/DC converter, so as suggested somewhere, one can solder some power wires to a DIY USB-C male connector and connect those to something between 9V-20V. So no 'thin wire' problem at least. I should have looked at it before, as now extra RPI5 PSU is not needed now (but good as laptop/tablet charger etc).