• Content Count

  • Joined

  • Last visited

Everything posted by willmore

  1. I was holding it wrong, that was an H5 board. FFS..... raw=1, etc. slow board.
  2. My OPiOnePlus is raw=0, bin=0 (unknown). Am I holding it wrong?
  3. My temp responds very well to added cooling. I placed the boxed SBC next to a small fan and the temperature dropped by 20C. So it may just be a board specific cooling issue. I'll look into adding a heatsink and find a better source of improved airflow. Thanks, megi, and Igor!
  4. Here you go, sir. armbianmonitor -u output
  5. I have an Orange Pi One Plus with the H6 chip in it and I'm quite happy with how well it's supported by Armbian. I haven't really had any problems with it. I do have one question, though. I'm using armbianmonitor to "-m" monitor the machine and I notice that the temps are always pretty hot. Even at idle (480MHz) it still shows 72C. That seems higher than I would have expected. Is this normal, expected behavior? I understand that the SoC thermal monitoring code in the kernel is pretty new and therefore might not be perfect, yet. So, I thought I'd ask. Because it may just be
  6. Data for the Odroid-C2 for 2 threads to fill out the table @tkaiser. 100: execution time (avg/stddev): 196.7230/0.01 250: execution time (avg/stddev): 76.9758/0.01 500: execution time (avg/stddev): 37.5997/0.00 1000: execution time (avg/stddev): 18.3120/0.00 1296: execution time (avg/stddev): 14.3056/0.00 1536: execution time (avg/stddev): 12.0588/0.00 1656: execution time (avg/stddev): 11.1768/0.00 1680: execution time (avg/stddev): 11.0148/0.00 1752: execution time (avg/stddev): 10.5501/0.00
  7. As a user and not a dev, I'd like to add that I'd much prefer that a distro be stable than faster-and-unstable. For an experienced user, I know I can fiddle with these values and characterize the abilities of *my* particular boards if I want to take the time. For an unexperienced user, an increased chance--howerver small--of the software making my hardware unstable is unacceptable as I'm likely already chasing a bunch of problems of my own creation--the aforementioned SD and power problems being primary amongst them. That's my long way of saying, please choose 624.
  8. This should help SSD performance, no? Oww, I want to try this!
  9. Back when the clock speed cheating was first detected, I had been doing just the kind of bencharking that detected it. I approached a vendor in the area with my results--looking to find out why there was a performance plateau at 1.5GHz. That was one of the things that triggered the investigation into the issue which lead to revelation that the firmware was lying. There's some data there that might be of interest historically. Nothing that matters to this thread, really. The method that you've shown in this thread is similar to what I was doing back then and I'm confident that y
  10. Ahh, yes, for a clock speed surrogate, you'd want exactly a task like that--something that doesn't stress the CPU too much that power and thermal issues com into play. You'd also want to avoid anything with alot of memory usage as that will be inelastic with CPU speed. Yeah, the clock speed issue for the S905. I remember that well. Maybe some day I can release the info I have on how that was detected.....
  11. Someone said my name? Sorry it took me a while to run this, but they offer a 100MHz clock speed and that takes a very long time to run--especially with one thread. I have a high degree of confidence that there is no throttling as IIRC, I tested this setup with cpuburn and got no throttling. I can't imagine this being more demanding than that! Here's the data: num-threads=4 100: execution time (avg/stddev): 99.4764/0.02 250: execution time (avg/stddev): 37.7647/0.01 500: execution time (avg/stddev): 18.6581/0.00 1000: execution time (avg/stddev):
  12. I think the question becomes "where does the OpiZ get power? If it's over the micro-USB, then it's looking dangerous.
  13. The decision to remove BogoMIPS measurements in ARM was made a decade or so ago. It was made in the open on the linux arm mailing list. You're welcome to search the archives and reread the discussion. If you take issue with any of it, you are free to try to reopen the issue. I would suggest that such a pursuit will not be productive. In the context of Armbian, read the forum here, read the appropriate linxu-* mailing list, and join the IRC channel. All of these decisions are discussed there. Are they distilled into some convenient Wifi? No, but anyone is free to read all of
  14. From a 3.14.29 kernel: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=240000) ARM doesn't use a busy wait loop, so the BogoMIPS calculation was abandoned a very long time ago. The value you see now is only a placeholder for old scripts and programs that expect to find it for whatever their reasons.
  15. Thanks for pulling in the fix. I'm glad I could help even if it's just me stumbling in the dark and running into things.
  16. Okay, I put the changes back in and rebooted. It works just fine. I haven't verified functionality of SPI, though. Kernel log says: [ 9.546118] spidev spi0.0: probing from DT So, it looks like it's working. Need to me do anything else?
  17. Taking out the last four line fixed it. DTB format changes or something, maybe? Let me know if you want any more testing, I'm here to help if I can be of use.
  18. Okay, one of them--that I was using for SPI testing--has: verbosity=7 console=both disp_mode=1920x1080p60 rootdev=UUID=1ab2a8dc-160b-474b-ab35-ba43e08d90ef rootfstype=ext4 overlay_prefix=sun8i-h3 overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_max_freq=100000000 The second Orange Pi One has the same config. I'm going to pull the spi overlay and see if that changes anything. I have an up to date Orange Pi PC which is H3 based and it rebooted fine after the recent update. Would that be sufficient? If not, can you point me to one you would like me to test? The htt
  19. I just updated two Orange Pi One boards and rebooted them to get to the new kernel only to have them boot loop. I know, development, not supported. I'm not asking for a solution, I'm just alerting people to the situation so they can avoid messing up their boxes. Console log attached if you're curious. orangepione.txt
  20. Understood. I wasn't worried about the breakage as it's easily fixed and--as you said--this is an experimental build. But I did think it was a good time to improve my understanding of the boot process.