stamasd Posted November 10, 2019 Posted November 10, 2019 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.
stamasd Posted November 10, 2019 Author Posted November 10, 2019 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.
guidol Posted November 10, 2019 Posted November 10, 2019 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?
stamasd Posted November 10, 2019 Author Posted November 10, 2019 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.
guidol Posted November 10, 2019 Posted November 10, 2019 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? 1
stamasd Posted November 10, 2019 Author Posted November 10, 2019 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.
martinayotte Posted November 11, 2019 Posted November 11, 2019 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 ... 1
Werner Posted November 12, 2019 Posted November 12, 2019 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
Recommended Posts