Neko May Posted February 1, 2020 Posted February 1, 2020 The Orange Pi Zero +2 H3 with USB hat will hard lock up on boot at "Starting Armbian Hardware Monitoring" when booting the latest (and at least one previous) available Buster (and Bullseye) images over HDMI console. Tested on multiple SD cards with the same result. (I will test with serial later, I do not have the time to remove it from the case at the moment; I figured I would post it now in case anyone had a chance to check before I could.)
technik007_cz Posted February 4, 2020 Posted February 4, 2020 There is no reason why it should not work. H3 works like a charm. Mostly it is bad usb cable or unsuitable power adapter. Or it could be unstable microsd card usb adapter. It is hard to say from this distance.
Neko May Posted February 5, 2020 Author Posted February 5, 2020 4 hours ago, technik007_cz said: There is no reason why it should not work. H3 works like a charm. Mostly it is bad usb cable or unsuitable power adapter. Or it could be unstable microsd card usb adapter. It is hard to say from this distance. USB cable is well tested and known working. Power supply is capable of 4A maximum and also well tested. Same with SD Cards and adapter, all very well tested. I'm aware of the maturity of H3 support but that does not preclude bugs. Anyway, I've now done exhaustive testing with the latest Buster image, ruling out any sort of hardware issues (including testing on a second board) and it consistently locks up on boot. Attempting to view kernel output over the serial port yields literally nothing; the "booting the kernel" message is displayed then nothing else (heartbeat LED flashes until lockup). The same behavior is encountered with or without the HDMI display attached.
Werner Posted February 5, 2020 Posted February 5, 2020 Quote the serial port yields literally nothing; add verbosity=7 to your /boot/armbianEnv.txt
Neko May Posted February 5, 2020 Author Posted February 5, 2020 Everything proceeds normally, then: [ 11.372152] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-11), device may have limited channels available [ 11.384297] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Mar 30 2016 11:30:56 version 7.45.77.h8.4 FWID 01-ee8a6268 [ 11.795217] EXT4-fs (zram0): mounted filesystem without journal. Opts: discard [ 11.802525] ext4 filesystem being mounted at /var/log supports timestamps until 2038 (0x7fffffff) [ 16.152485] EXT4-fs (mmcblk0p1): resizing filesystem from 299008 to 7712800 blocks Note the roughly 5 second pause before the resize operation, after which it immediately hardlocks. An attempt with a fresh, brand new SD card gave near identical results, instead freezing before printing the "resizing" line.
technik007_cz Posted February 5, 2020 Posted February 5, 2020 What is voltage in any of USB ports during resizing? Other distro eg Ubuntu Bionic works well?
Werner Posted February 5, 2020 Posted February 5, 2020 At the first boot the filesystem expands itself over the whole sd card which can take a few mintes or more depending on the actual speed and size of the sd card.
technik007_cz Posted February 5, 2020 Posted February 5, 2020 You think Neko May was not patient enough?
Werner Posted February 5, 2020 Posted February 5, 2020 I just want to virtually eliminate that trivial chance
Neko May Posted February 5, 2020 Author Posted February 5, 2020 I waited an hour. Add in that the screen cursor AND heartbeat LED stop blinking and it's clear something else has gone wrong.
Werner Posted February 5, 2020 Posted February 5, 2020 Probably yes...if you tested another sd card and PSU to eliminate those as cause, then no clue. Did your board work earlier or is it new? I do not have an Zero Plus 2 H3 myself so I cannot verify that it boots on a known to work sbc. Though I am pretty sure other users here have this board in their collection :).
Neko May Posted February 5, 2020 Author Posted February 5, 2020 2 hours ago, Werner said: Probably yes...if you tested another sd card and PSU to eliminate those as cause, then no clue. Did your board work earlier or is it new? I do not have an Zero Plus 2 H3 myself so I cannot verify that it boots on a known to work sbc. Though I am pretty sure other users here have this board in their collection :). Boards (I've tried on two) are new. All possible local causes eliminated.
5kft Posted February 5, 2020 Posted February 5, 2020 Unfortunately I don't have a Plus2 H3...but I've used other H3s and they've all been working great. Soooo...it is probably a long shot, but you could try mounting your SD card on your development PC, then change the maximum clock rate specified in /etc/default/cpufrequtils (MAX_SPEED) to 480000 in the card rootfs, then try booting again and see if that helps? Maybe there's there's a problem with clocking/power of these new boards...?
Igor Posted February 5, 2020 Posted February 5, 2020 13 minutes ago, 5kft said: I don't have a Plus2 H3 Works fine: http://ix.io/2aPh
5kft Posted February 5, 2020 Posted February 5, 2020 1 minute ago, Igor said: Works fine: http://ix.io/2aPh Indeed, but given that the board is clocking to 1.3GHz...: ### Boot system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:44:25: 1368MHz 0.38 41% 24% 12% 0% 3% 0% 30.4°C 0/8 16:44:26: 1368MHz 0.38 29% 3% 0% 1% 24% 0% 29.5°C 0/8 16:44:26: 1368MHz 0.38 23% 5% 0% 1% 16% 0% 29.2°C 0/8 16:44:26: 1368MHz 0.38 22% 5% 0% 0% 16% 0% 31.1°C 0/8 ...I'm wondering if these new Plus2 H3 boards don't properly switch the CPU to 1.3v. I.e., perhaps Xunlong stopped stuffing the "Q5 MOSFET" like their H5 version... If the CPU gets clocked to 1.3GHz+, and the core is still running at 1.1v, then that would explain the random freezes. (This is how I discovered this problem on the Plus2 H5s originally.) @Neko May, if you look at the underside of your H3 boards, is the red circled part present on them or missing? Again, it may be a long shot, but it's worth checking...
Neko May Posted February 6, 2020 Author Posted February 6, 2020 13 hours ago, 5kft said: Indeed, but given that the board is clocking to 1.3GHz...: ### Boot system health: Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 16:44:25: 1368MHz 0.38 41% 24% 12% 0% 3% 0% 30.4°C 0/8 16:44:26: 1368MHz 0.38 29% 3% 0% 1% 24% 0% 29.5°C 0/8 16:44:26: 1368MHz 0.38 23% 5% 0% 1% 16% 0% 29.2°C 0/8 16:44:26: 1368MHz 0.38 22% 5% 0% 0% 16% 0% 31.1°C 0/8 ...I'm wondering if these new Plus2 H3 boards don't properly switch the CPU to 1.3v. I.e., perhaps Xunlong stopped stuffing the "Q5 MOSFET" like their H5 version... If the CPU gets clocked to 1.3GHz+, and the core is still running at 1.1v, then that would explain the random freezes. (This is how I discovered this problem on the Plus2 H5s originally.) @Neko May, if you look at the underside of your H3 boards, is the red circled part present on them or missing? Again, it may be a long shot, but it's worth checking... It's present. Silkscreen on the board indicates it's a V1.0; it was ordered from their official AliExpress shop in December 2019.
Neko May Posted February 6, 2020 Author Posted February 6, 2020 14 hours ago, Igor said: Works fine: http://ix.io/2aPh This indicates it's a 19.x build, the current build available (and marked as supported) is 20.02
5kft Posted February 6, 2020 Posted February 6, 2020 7 minutes ago, Neko May said: It's present. Silkscreen on the board indicates it's a V1.0; it was ordered from their official AliExpress shop in December 2019. OK...interesting...it's a mystery then...
Heisath Posted February 6, 2020 Posted February 6, 2020 4 hours ago, Neko May said: This indicates it's a 19.x build, the current build available (and marked as supported) is 20.02 Please try a 19.x build. https://dl.armbian.com/orangepizeroplus2-h3/archive/ The 20.02 ones are only RC (release candidates), it is a bug / mistake that the general link points to them.
Neko May Posted February 6, 2020 Author Posted February 6, 2020 3 hours ago, count-doku said: Please try a 19.x build. https://dl.armbian.com/orangepizeroplus2-h3/archive/ The 20.02 ones are only RC (release candidates), it is a bug / mistake that the general link points to them. Alright, I will try tomorrow. (Though it should still be noted that the 20.02-RC appears to be nonfunctional!)
Neko May Posted February 12, 2020 Author Posted February 12, 2020 (edited) On 2/10/2020 at 7:44 AM, technik007_cz said: Al right, any news in this story? Ah, sorry, haven't checked the last 19 build yet, had some other stuff come in and got busy with that. (I did update the 20.02-RC Google Doc, though, with my results.) Armbian_19.11.6_Orangepizeroplus2-h3_bullseye_current_5.4.8.img is fine. Boots to login prompt, so it's a 20.02-RC issue. Edited February 12, 2020 by Neko May Updated 1
Recommended Posts