jmarcelino

Following @tkaiser's guidance I've battered the hell out of the poor H3 on my Pi One with benchmarks. Again for those not following the saga this is using the old switching .fex since apparently my Pi One - unlike some others - is actually switching to the correct voltages. So I started a sysbench --test=cpu --cpu-max-prime=100000 run --num-threads=4 in one session, left it for a while and then started another session to run the cpufreq-ljt-stress-test concurrently. I did this using the "performance" governor with scaling_max_freq set first to 1104000 and then 648000 (which stays at the lower voltage) This is the OPi monitor result: I don't see evidence of thermal throttling. I also measured temperatures with a probe over the CPU using my Fluke 17B and saw around 44C when running just sysbench+stress test at the lowest core speed going up to 50C when running same at highest core speed. To liven up things a bit I also run cpuburn-a7 on top of both other tests which quickly brought temperature to 65C. This is where the SoC temperature peaks up on the OPi graph, the internal SoC temperature reported by OPi was actually close to 80C - this was a "throw everything at the SoC" kind of moment but still all 4 cores kept operating. Running tests at scaling_max_freq 648000 also revealed no issues. So I'm satisfied that at least my Pi One is solid using the old switching .fex. I hope we can find out what's going on with other Pi Ones which don't like this, for now it means I'll have to keep patching the .fex to work on mine... I'm also now intrigued to try allowing 1200Mhz and perhaps increase the DRAM speed to the "listed" value. On the back of the schematics being available and the problems understood I'm going to order a few more OPi Ones and look forward to testing those. Like tkaiser I'm very much looking to use these as headless controllers.

Yes of course, use the photo as you please. Thanks for all your help so far, I'm learning a lot too. Just measured the 1V2C test point and seeing it at 1.11 V @ 648 Mhz and switch to 1.31 V for higher speeds and under load - this is of course with the old .fex. TP1 point is showing very similar values, just very slightly lower (less than 0.002V difference)

@tkaiser Thanks so much for your guidance! Really appreciate it - I may owe you a few beers if you're around Nuremberg :-) I will follow the steps you suggested this afternoon and report back. This morning I was looking around the board for test points and noticed that while there's lots of mentions of the regulator being a SY8113, the chip on my One didn't match the markings on the datasheet (top mark should be MLxyz, mine is WC5V1) After a bit of smd marking detective work I found out that the regulator on my board is actually an AX3833: http://www.micro-bridge.com/data/Axelite/AX3833.pdf At first glance they seem very similar in specs so maybe 100% compatible, but I wonder if this could explain the differences in operation. Could you check which chip yours' has? Here's a photo of mine:

Continuing my Pi One testing, I tried the very latest image and still had no success so I kept experimenting with the orangepione.fex I've now tracked down my problem to @tkaiser's patch attempting "to fix potential overvolting and overheating" For some reason my Pi One needs the older settings of: pmu_level0 = 11300 pmu_level1 = 1100 and LV1_volt = 1300 LV2_volt = 1100 If I use the new 1270 values it never boots sucessfully and crashes with the random errors I've documented previously. Even with the latest image replacing the values on the 4 lines above in the .fex makes my Pi One work again. I've even run the cpufreq-ljt-stress-test script successfully afterwards (output below) I've also run cpuburn-a7 for a while and recorded ~ 60C using a thermal probe directly on top of the CPU which doesn't seem too concerning. This is without a heatsink. I understand there were concerns about overvoltage/overtemperature which led to adopting the lower values and some (several?) of you are running with those - on the latest image - just fine on your Pi Ones, but for some reason my Pi One doesn't work with them while it's perfectly happy with the previous values. Is there anything I can do to test this out further? For example I probe the voltages if you can point me to test points to look at.

So I reverted config/orangepione.fex back to 80e7d5a while keeping the rest of the tree up to date and my Orange Pi One is now happy again, booting correctly, has network. Boot log: http://pastebin.com/AdfaAUYe I'll see if I can narrow it further.

Thanks Zador, Unfortunately removing it didn't help, but you're right about the consistent location of the errors, the problems seem to start around: Do these values seem correct to you? This is using the latest build of the https://github.com/igorpecovnik/libtree. I've also now tried a third, different brand and slower (Class 4) μSD card - hdparm removed - and the problem still persists but again slightly different output: http://pastebin.com/8wKpnwXz I'll keep trying, maybe the next step is going back, reverting some of the patches to see which one caused these problems.

Thanks for all the tips. I checked the microSD card using F3 to make sure - it found no problems. In fact the same card has no problems in the Feb 14 build of Armbian, I can just flash the old image and it works perfectly. I'm aware of the fakes but this is a Sandisk Ultra 32Gb UHS-I U1 from a reputable company. I also checked the script.bin and it is linking correctly to /boot/bin/orangepione.bin I'm attaching three full logs since it crashes for apparently random reasons, the first two terminate with "unable to handle kernel paging request at address" errors while another starts throwing lots of MMC errors - but as I explained the SD card tests perfectly. I then flashed this same card immediately after the tests with the old Feb 14 build and the Orange Pi One booted without a hickup. Just to make sure I then repeated the same with another - brand new - SanDisk Ultra SD card with exactly the same result. http://pastebin.com/3aBd6xrY http://pastebin.com/K8vWQcXs http://pastebin.com/Z8jymkbP Not sure if it matters but I'm powering the Orange Pi One via the 5V and GND pins (1 and 3) on the 40 pin connector from a 3A power supply. I'm happy to test out any other ideas as I'm keen to get this working. Cheers

I think this setting is already in the tree? My latest build has this already. Thanks, just did that. Appreciate your help and patience while I learn the ropes.. I'm now seeing that the board is "crashing" in different ways, on one run I got this: on another it seemed worse: I'm guessing these are related to the voltage/speed changes?

Hi all, I'm very new to Armbian, actually got interested due to the Orange Pi One. Looks like a cool project I compiled a Jessie build on Feb 14 which was working well on the One board and after reading the latest messages decided to try a newer build. However both the image on the site ( Jessie ) and compiled from github (with all the latest commits) don't seem to boot. Serial console just shows the below and hangs before showing a login prompt. Ethernet also never comes up. After reverting to the Feb 14 image everything works well again. Any ideas or something I can try? I understand things are still shifting around but some of the replies above make me think this should be working on the One board at the moment. Cheers