I have several Orange Pi One and Orange Pi PC boards (the original ones, H3-based). I have downloaded the latest Armbian release for them Armbian_5.91_Orangepipc_Debian_buster_next_4.19.59 and imaged several SD cards in Linux with dd. The cards are all class 10, some are Sandisk and some are Samsung. I am using a 2.5A power supply for the boards.

 

For all the boards and all the SD cards I get the same result. U-boot starts, gets to the point of loading the kernel, clears the screen then displays "Loading, please wait" then "Starting version 241" and stalls there. Nothing else happens no matter how long I wait. If I power the board off and then back on, the same thing happens.

 

This happens with 3 different boards (one Orange Pi One and 2 Orange Pi PCs), and 5 different SD cards. The SD cards are all 16GB, class 10, 3 are Sandisk and 2 are Samsung. Any combination of board+card gives me the same result.

 

The way the cards are written is with:

dd if=Armbian_5.91_Orangepipc_Debian_buster_next_4.19.59.img of=/dev/mmcblk0 bs=4M

I have used the same approach with Armbian for the Odroid-C2 with the corresponding version of Armbian, and that worked well.

 

If I connect any of the boards to the Linux PC via USB-TTL adapter and use a serial console, the boards freeze before loading the kernel. Here is the serial console output.

U-Boot SPL 2019.04-armbian (Jul 15 2019 - 17:15:48 +0200)
DRAM: 1024 MiB
Trying to boot from MMC1


U-Boot 2019.04-armbian (Jul 15 2019 - 17:15:48 +0200) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi PC
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0
Loading Environment from EXT4... ** File not found /boot/boot.env **

** Unable to read "/boot/boot.env" from mmc0:1 **
In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   phy interface0
eth0: ethernet@1c30000
230454 bytes read in 12 ms (18.3 MiB/s)
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
USB4:   USB EHCI 1.00
USB5:   USB OHCI 1.0
USB6:   USB EHCI 1.00
USB7:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 3 for devices... 2 USB Device(s) found
scanning bus 4 for devices... 2 USB Device(s) found
scanning bus 5 for devices... 1 USB Device(s) found
scanning bus 6 for devices... 1 USB Device(s) found
scanning bus 7 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
3798 bytes read in 2 ms (1.8 MiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
152 bytes read in 1 ms (148.4 KiB/s)
6746780 bytes read in 326 ms (19.7 MiB/s)
7494376 bytes read in 361 ms (19.8 MiB/s)
Found mainline kernel configuration
29890 bytes read in 6 ms (4.8 MiB/s)
4155 bytes read in 4 ms (1013.7 KiB/s)
Applying kernel provided DT fixup script (sun8i-h3-fixup.scr)
## Executing script at 44000000
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    6746716 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 43000000
   Booting using the fdt blob at 0x43000000
EHCI failed to shut down host controller.
   Loading Ramdisk to 49990000, end 49fff25c ... OK
   Loading Device Tree to 49920000, end 4998ffff ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Huh, I became suspicious that it may be a power problem when the kernel wouldn't load correctly with the serial monitor attached, so I changed the power supply from a 2.5A one to a 5A one, and now all boards boot correctly. Please ignore the above.

 

I didn't realize that these boards were quite so power hungry. It's funny because the CPU doesn't get even slightly warm while doing an update. I wonder where all that power is going.

17 minutes ago, stamasd said:

I didn't realize that these boards were quite so power hungry. It's funny because the CPU doesn't get even slightly warm while doing an update. I wonder where all that power is going.

No they are not power hungry

I got more than 5 boards on a USB-Multiloader. The One & PC are running very cool.
Maybe you also changed the USB-Cable against a better one?

I'm not using any USB cables for power. I use dedicated power supplies with barrel connectors. With a 2.5A power supply, the boards don't run. With a 5A supply, they do. But I agree they're running cool. So maybe my 2.5A power supply is faulty.

Just now, stamasd said:

I'm not using any USB cables for power. I use dedicated power supplies with barrel connectors.

I use the USB-A to Barrel cable for my OPi's - maybe it was a connector problem?

Don't think so, the connectors are snug on both power supplies, and the boards do start uboot but stall when the kernel kicks in. Maybe there's a momentary power demand increase that the smaller PS can't cope with and it stalls the kernel.

21 hours ago, stamasd said:

Here is the serial console output.

Change /boot/armbienEnv.txt to have both "verbosity=7" and "console=serial", you will get more details ...

On 11/10/2019 at 5:28 PM, stamasd said:

I'm not using any USB cables for power. I use dedicated power supplies with barrel connectors. With a 2.5A power supply, the boards don't run. With a 5A supply, they do. But I agree they're running cool. So maybe my 2.5A power supply is faulty.

A practical and easy-to-use solution would be grabbing an usb voltage tester. Ideally you plug it into the USB connector of your board to get an idea about the voltage drop across the SBC which is in my eyes more interesting than how much amps the board takes. A multimeter will do it as well of course