TonyMac32

The V3s is very much centered around video processing, for cameras and such. That said, it has far more I/O capability than the Broadcom SoC's used on Raspberry Pi, and the ARM core is the master of the SoC, not the video hardware. https://github.com/petit-miner/Blueberry-PI I just ordered some boards to build one of these to experiment with, need to get the components on order, I apparently managed to squeak my PCB order in just before Chinese New Year shut everything down.

I can't make any definitive statements on this as yet, but my guess is either the delays are different between board revisions, [ 1.706658] rk_gmac-dwmac ff540000.ethernet: TX delay(0x26). [ 1.706673] rk_gmac-dwmac ff540000.ethernet: RX delay(0x11). or there is an IRQ issue... [ 1.786766] eth%d: PHY ID 001cc916 at 0 IRQ POLL (stmmac-0:00) active [ 1.786778] eth%d: PHY ID 001cc916 at 1 IRQ POLL (stmmac-0:01) I'm about to go to bed, so I can't do more debugging from my side tonight, hopefully someone else can pick this up who has the board...

So the Rock64 is the server? As for SSH, it takes very little bandwidth. Do you have any special software installed that might be interfering? Also please post the armbianmonitor -u link, that might be helpful.

Well, the question then becomes, which Rock64 is it? I don't know that all of the devs have the newer (or newest) one. Can you do an iperf test to see if your network connection is the issue?

Doubtful, it is powered via USB instead of with a barrel jack. Does your SSD have current requirements listed on it? SBC's honestly don't even conform to USB 2.0 current capacity of 500mA, let alone USB 3.0's 900 mA.

https://www.mccdaq.com/DAQ-HAT.aspx I've reached out about whether or not they know if the software works with non-RasPi boards. I'm not dropping $99 to test it personally, if it fails then what? But, looks like a nice setup if mated with a proper board. The other option of course is to build one myself, but then it becomes a question of software, which would take far longer than the hardware itself.

Agreed. I think the logs are a good call, if we have SoC sub forums in "community forums" we can allow more or less anything appropriate.

That was part of the reason I asked to split the hardware hackery from the general discussion, since it has relevance to SBC's but not specifically to Armbian a lot of the time, and takes up space. That's kind of my thought. Look at formula 1 racing and see the ways they cheat, it's human nature I think, when any kind of restriction is in place, it is a challenge to overcome. Increased control results in an increased effort to defeat it, which needs more control, until things fall apart.

That's a separate issue, but it lies in the reality vs. what we would like to see be true. The simple reality is you can't force people into line without draconian policy/rules/etc that will choke off the community in general. Now, if it were possible, I would say, along some reorganization lines as Igor posted, that we have a "select your board" drop down requirements for the Support subforum, and if we can go even further, sort them appropriately by that tag. Then it gets easier, we only have spammers posting in whatever the first board on that list is. ;-) Well, the forum is the part people see above ground, a lot of its issues relate to the roots, so it's bound to get complicated. For example, WIP/CSC's having downloadable images on armbian.com results in user questions, which increases our support traffic for boards we obviously don't find interesting enough to support directly. Ignoring them is somewhat effective, but like I said above, making a single part of the forum a "gated community" with curated/controlled input should make it so stuff like that can be ignored with a documented reason, without necessarily causing any collateral damage. And of course keeping boards to a minimum or at least defining what the core boards are should help as well. My thoughts on this fall more into the perception and the actual scale of the project. The act of imposing regulation and setting a bar is viewed as pretentious or exclusionary by the human psyche in general. That's not necessarily a bad thing, however it's being introduced into a space that was previously open to admittedly "too free" of discussion. Is it possible to sort posts automatically by tag and then by age? At that point, a fully filled out questionnaire (with a check so that http://Idontfillout.form won't be accepted ;-) ) would receive a tag that puts it at the top of the non-pinned pile, and above anything that skipped a step. That simple feedback of basically demoting the content instead of downright blocking it should passively take care of the issue, and if someone gets noisy a mod can point out their stuff is under all the properly filled threads because it wasn't done correctly. I'd guess there'd have to be some sort of qualifier based on age for when that sorting stops, otherwise the first improperly filled out post would be on page 12 or some nonsense.

I don't know of any issue they would pose Sent from my Pixel using Tapatalk

Yeah, it becomes a problem when we get a hurricane that is a 10 or 25 year phenomenon:. "OMG global warming", and then the same people say "So what if Michigan is an icicle? That's just weather". Both sides practice this fallacy, and both sound stupid doing it, it is destructive to science itself, not to mention making world leaders look stupid. Sent from my Pixel using Tapatalk

Agreed. Which opens up a kernel question, so buckle up. ;-)

Well now. Mali400 and 450 should not be enabled on the RK3399.

I'm not familiar with the requirements to make that happen, personally, if you can provide a PR against the build system I will test/merge it. (Or obviously if anyone else reads this and knows the solution)

Don't speak of The Program That Must Not Be Named. That's doable, with the understanding that TV boxes don't fit. lol which RK3399? True, but the primary ones so we can at least get some reviews in place, and get a sense of how big a chunk of the pie any individual is taking on.

Irrelevant. If someone doesn't recognize the main contributors without such a tag already they'll be too dense to figure it out even with that extra help. It's a tracking tool, far more effective than guessing. The entire point is, if the board number is reduced to both vendors and users who give a damn, then we can focus more completely on the task at hand, the quality and consistency of the thing. Board hierarchy would go like this: Is a community member willing to "own" it? y/n Does the vendor support it on their side? y/n Does the vendor help Armbian in some way (either with the board or generally)? y/n Ignore them, I've seen an uptick in the Amlogic and Rockchip forums of community helping each other. Necessity is the mother of all invention. See if it is a legit build system problem, if not, politely say "sorry I can't really help, that looks like a use-case issue" or something similar, and move on. Or simply ignore it. The problem I'm seeing develop here is 150% typical for engineering/software/technical sales types: They expect the user to know too much, and get grouchy when they don't. Asking questions is almost never done in malice, don't act as though it's a criminal act. Someone saying they got ignored on the forums is infinitely better than someone saying "I asked a question on the Armbian forums and that Tido guy called me an idiot and said I was wasting his time" (example only, but you get the point). Rules are good, but ignoring unless you have the time is more effective. Making people fill out a questionnaire before posting a question is also bad, but until now I hadn't seen enough of a reason to complain about it. Ignore them. It's honestly quite simple. They get noisy toss the rules at them, and we live peacefully. Any of us answering questions is entirely voluntary, including Igor. Treat it as such. That was my plan in any case. I need one for my personal projects anyway.

I will be receiving a board, the S805X is to the S905X what the H2+ is to the H3, I don't see any concerns with the SoC support itself. It will take some time to determine if it fits in with the existing Meson64 devices cleanly enough to support or not, and how clean the board itself is, stay tuned. The fate of boards like this one rests entirely on how easy they are to support. Thanks to Libre Computer and Bay Libre the Meson64 platform is extremely well supported in mainline and are usually trivial to support. I'm willing to adopt it as long as this continues to be true.

Uuugh. Sent from my Pixel using Tapatalk

OK, so the Armbian Dev build option reflects my current running kernel, for anyone looking to test.

I see some structural challenges here. One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out). If we take this route, then the forum has to be as open as possible to general user complaints. Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings". We also need to find a good way to appeal to a more diverse user base, application wise. People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing) @JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu) So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users. from those users, some programmers/maintainers/mods/etc will show up. The issue is the age old one of humanity: Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute. I think we do need to approach the "slimming down" of our boards a bit more carefully. This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect. If we are not overwhelmed, we make better things, the community benefits. If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board) We need to add a "maintainers" list or something similar, this is for one simple reason: boards with no maintainer need to be put on probation. A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers" I would propose we not make images for those boards available on the download page, allow people to build them if they want. That alone filters who would be asking questions. So, for boards: Each board entry should include 2 additional fields: Maintained-by (Member or members) Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards? I include technical support here) So Tinker Board and Le Potato would look like: supported-by: tonymac32 vendor-supported: yes (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money) For Member-contrubtors: boards hosting documentation etc So Igor (sorry if I massively under-represent: Build Script Author (obviously multiple people can have each tag) Web Admin Build Hosting Family-Allwinner Family-Freescale Documenter etc I can expand on this later in a specific thread since it covers a wide topic matter.

Overlays were never rolled out on legacy I think, if we do roll them out what I'd recommend is making the switch to naming "rk3288-tinker.dtb", so that it won't break any older installs where u-boot is looking for "miniarm", because the dtb needs updated to have sane device tree support as we do it on other boards. That is what I had to roll out on Next when I added overlays there. Sent from my Pixel using Tapatalk

Switching to Asus is possible, but it will require some patching to make sure their fairly unique coding style doesn't break any other RK3288 board/box/etc. While I understand we're not required to keep things nice for other boards, I'd rather not leave a wake of destruction either. I'll take a look at it hopefully tonight. (I'm not being overly critical of ASUS, it's their kernel for their device, they don't really need to give a damn about other people's hardware, so they can hack to their heart's content) Sent from my Pixel using Tapatalk

@Heimdall is this a new install you're working on? If so I'd recommend going with the newest images, 4.19 LTS kernel.

The issue here is, there is a pin compatibility problem from what I can see. The C2 has the 40-pin header wired physically differently in terms of I2S. The "Le Potato" board looks to have the right pins in the right place, as does the Tinker Board, and the Tritium series. I'm sure there are others, but I haven't gotten into all of the GPIO's yet, the document I shared is for my own use, but I'm happy to share it. It doesn't have anything special in it, other than having all the baords in one place, in theory, so you don't have to scour the internet and figure out the various vendor formats to document it. And I go through the datasheets and look at alternate functions of the GPIO.

Hello @petit_miner, How is the status of your hardware? Is it good enough to be built for evaluation? I want to do something similar, and have some V3s's laying about because of it that need a home.