willmore

Igor, yes, I think the issue is the 'how to communicate this better' problem. I understand your situation and I appreciate all of your work. Let me add my perspective and the motivation that lead me to ask my question. In this thread we see that there is a desire to have a working Linux distro for the Opi Zero 3. Armbian is a great starting point--plain Debian would work as well, but Armbian has some SBC specific customizations that make it more appropriate--so that's what people tend to use. Someone pointed out there was a mostly working version available. They and others have been working for months to try to improve it. I think all of this is a simple distillation of facts and it's in dispute. Where there seems to be some issue is motivations. I don't know the person who made the original port--"leeboby" on github. I don't know what their long term intention is. Maybe they are interested in their port becoming official and taking over an official Armbian maintainer role. Maybe it's just a 'fire and forget' effort they did for some reason. I don't know. But the people here would clearly like to move towards some kind of more official board support under the Armbian umbrella. To that end, the question was asked if there could be a board specific sub-forum created for this clearly unsupported board so that conversations about an unsupported board wouldn't 1) pollute the general unsupported board forum 2) make it clear that it was unsupported (to manage peoples expectations) 3) make it easier for people to find information on the effort to get this board supported by Armbian. Having a sub-forum would help provide a sense of community and help develop interest in the effort. *with hope* a maintainer would be attracted to or developed by this community. As you point out, this is a completely volunteer effort. I see people in this thread (before the split) who are showing interest in doing volunteer work. I though I reasonably could expect a community manager to encourage the development of a community--in this case by creating a sub-forum for the board under the unmaintained board/sun-xi forum. So, the question I though was being asked is "can this effort find a space to work?" What you heard was "support this board!" Your reply was "we aren't going to support that board without a maintainer". What I heard was "we have no interest in assisting in your effort to support this board". So, let me ask a better question now that I hope we all have a better shared understanding of the context of the question. Is there a place in these forums for efforts to create support for currently unsupported boards to work? It would need to be such that it's very clear to anyone participating that *the board is not supported and might never be supported by Armbian and that it's simply a community effort to try to reach that goal*. I hope that addresses your concerns with people trying to abuse Armbian for support of other peoples ports. If the answer is no, that's fine, this is your forum and it's up to you to decide how you wish it to be used. I simply wanted the proper question to be asked so that we all knew what was being asked. I just hope there's a way to collect community base interest and effort and channel it into something that makes Armbian better. Thank you for all of your work and specifically the time you've taken to address this question of mine.

I'm trying to wrap my head around saying that there's no point in making a subforum for this board in the "Community Maintained/Unmaintained" forum for a board that is not maintained by the Armbian team. Am I misunderstanding the meaning of Unmaintained or Community Maintained? Is "Unmaintained" read as "no longer maintained/abandoned"? Implying that it was once maintained but no longer is?

I was holding it wrong, that was an H5 board. FFS..... raw=1, etc. slow board.

My OPiOnePlus is raw=0, bin=0 (unknown). Am I holding it wrong?

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!

Here you go, sir. armbianmonitor -u output

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 my board that's off. Does anyone know if this is normal? Info: The board is in a lightly vented case and there is no HS on the SoC. There is light cross airflow in the area. Armbian version is "Welcome to Debian Buster with Armbian Linux 5.3.0-sunxi64" with current software updates. If there is more information I can provide, I would be glad to report it. Thank you for your time.

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

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.

PC2: http://sprunge.us/jVAH

This should help SSD performance, no? Oww, I want to try this!

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 you can detect cheating with this.

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.....

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): 9.2395/0.00 1296: execution time (avg/stddev): 7.1300/0.00 1536: execution time (avg/stddev): 6.0117/0.00 1656: execution time (avg/stddev): 5.5794/0.01 1680: execution time (avg/stddev): 5.4853/0.00 1752: execution time (avg/stddev): 5.2694/0.01 num-threads=1 100: execution time (avg/stddev): 369.1851/0.00 250: execution time (avg/stddev): 146.8992/0.00 500: execution time (avg/stddev): 73.3360/0.00 1000: execution time (avg/stddev): 36.6221/0.00 1296: execution time (avg/stddev): 28.2551/0.00 1536: execution time (avg/stddev): 24.4123/0.00 1656: execution time (avg/stddev): 22.0989/0.00 1680: execution time (avg/stddev): 21.7828/0.00 1752: execution time (avg/stddev): 21.3559/0.00

I think the question becomes "where does the OpiZ get power? If it's over the micro-USB, then it's looking dangerous.

Okay, half a decade ago.

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 these sources and edit the relevant wiki.

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.

That's always been the case, hasn't it?

There is the Odroid XU4. There are probably others.

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.

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?

ShallI update and retest?

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.

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 https://dl.armbian.com/orangepione/ directory doesn't seem to have anything new in it.