[Example] Support proposal for ROCK64

[tkaiser]

[Disclaimer on]

This is the try to play through some sort of an approval process contuining discussion from here and there -- maybe move @hmartin's last post to the latter thread? IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small. I would believe @Igorhas now every new Olimex device and TL Lim said he sent out 3 ROCK64 boards to various Armbian devs me being amongst... I think that's an opportunity to start to establish such a process now?

 

Since I've thought about this issue for a few days and came to no conclusion (Github issue or not or discussion in forum and so on) I'm now just naively start with a new thread regarding this RK3328 device and maybe we find out collectively how to define a process based on this?

[Disclaimer off]

 

Let me introduce ROCK64:

 

• RK3328 SoC: feature list
• ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks)
• Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit)
• 1GB, 2GB or 4GB PC-18666 LPDDR3
• eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper)
• socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter)
• 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever)
• RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)
• Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked)
• I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this)
• Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)

 

Pros:

• board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor)
• board vendor provides dev samples and documents problems devs might run into (see below)
• chip vendor actively supports mainline Linux and u-boot
• chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC)
• SDK/BSP not horribly outdated (RK relies currently on 4.4)
• almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces)
• No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook
• Icenowy already received a dev sample

 

Cons:

 

• new platform (Rockchip 64-bit) needing more initial work

 

Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)

 

My next steps planned:

 

• Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks)
• Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution)
• ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering)
• Present results to continue discussion

[tkaiser]

On 7.6.2017 at 6:02 PM, tkaiser said:

IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small.

 

That was the original purpose of this thread here. Gets still ignored.

 

Already wasted way too much hours regarding a phase out process to reduce the number of supported boards and especially 'update drama' but since the real problem (why do Armbian moronically supports new boards even if there's not a single reason -- see OPi Zero Plus 2 H5 or the Banana crap) doesn't get addressed it's just another round of wasted time.

 

Again: the purpose of this thread here was NOT go too much into ROCK64 technical details or already start development but weigh pros/cons and come to a conclusion AS COMMUNITY. A valid conclusion can also be: no support (at least not now since we need X, Y and Z from the vendor before we consider starting with this hardware).

[Igor]

On 7. 6. 2017 at 6:02 PM, tkaiser said:

IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small.

 

It could be done simply via (double) voting. Once (first) from developers perspective and once (second) from general public and where is the match (third) ... Questions which goes up - How often / when shall we repeat this? Will boards without any interest be ever back to the list? How many we will accept into next round / some initial state? Wanting to support (being elected in this voting) does not provide warranty that we will actually come to the full level. We might still ditch the board while trying to support it.

 

Right now we can come up with 5-10 boards which can be put on vote (and you can choose up to 3):

- Rock64

- Olimex A64

- Esspressobin

- Nanopi K2

- Bananapi M3

- Orangepi Win

- Orange 2G IOT

- Helios4

- 

-

 

We have strengthen moderator team and we can ask them to conduct regular board popularity contests? Somebody has to update those lists, the rest is more or less automatic.

 

I think 10 boards / round is o.k. and it's o.k. to put exotics, let's try again and failed boards too.  You already know that there will be no vote for those, at least from developers perspective

[Da Alchemist]

 From general public view I would suggest to freeze Developement of all Boards with BSP 3.XX.XX Kernel. New Boards should be only supported, when there is Mainline Support and Documentation Support by Vendors. There should be no Support of Boards with known Issues until they are solved by the Vendors. In this special Case, Rock64, this means that Developement should not start until DRAM/Gbe Issues are solved. No Support for TV-Boxes, as there is no Support by Vendors.

 

But I think voting is the Best Solution.

 

Regards

[zador.blood.stained]

2 hours ago, Igor said:

IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small.

 

What about this?

 

• New board appeared and it either is available already or it will be sold in the future
• Board passes the requirements checklist (documentation, no serious hardware design flaws, good software situation - like planning or ongoing mainlining, board samples can be obtained in sufficient quantity)
• Internal (team) voting and discussion to see who is personally interested in supporting this hardware, bringing it into the build system, testing, documenting and maintaining it in the future
• Making a decision: accepting, declining or postponing. New boards can be added to the "WIP" section

 

For the phasing out process:

• Supported board has significant hardware design flaws or software issues that can't be solved due to missing hardware samples or can't be solved by us at all
• Internal (team) voting and discussion to see who is personally interested in supporting the board in case of software issues
• End Of Support notice published with details for the reason and possibility in reverting this decision in case HW samples can be obtained
• Board is moved to the "EOS" section

[tkaiser]

2 hours ago, Igor said:

It could be done simply via (double) voting. Once (first) from developers perspective and once (second) from general public and where is the match (third) ... Questions which goes up - How often / when shall we repeat this?

 

I was not talking about votes/polls. I was talking about why we behave like idiots and start to support boards solely based on the fact that a hardware vendor sent us dev samples worth few bucks.

 

Again (!!!) two examples: https://forum.armbian.com/index.php?/topic/4378-nightly-images/&do=findComment&comment=33601 (why do we start with something like Orange Pi Zero Plus 2 H5, it makes absolutely no sense at all --> Armbian no, Android yes/don't care)

 

Again (!!!) my proposal is not to start as soon as someone sends us hardware but to open a new thread in not yet existing 'Board Bring Up Discussion' subforum. There the person who's interested in a specific device has to elaborate on why it would be a good idea to support the specific hardware or whether it's not (vendor behaviour being one of the potential reasons. If a vendor doesn't provide correct specs/schematics, advertises with wrong numbers, doesn't fix documentation mistakes even if told multiple times, sends out partially defective dev samples, doesn't document timely if he exchanged relevant hardware parts -- I'm talking about AP6212 vs. AP6212A here -- that's a good reason to avoid that hardware and document this at the same time so surprised users get the idea why developers consider dealing with a specific hardware not worth their time. That way we might even see some vendors improving over time if their irresponsible behaviour is documented again and again).

 

I'm still only talking about a group decision based on a real discussion when/whether to start working on a device or not. No polls/votes, especially no user polls! If tomorrow a hypothetical 'PicoPi Bullcrap' for $5 is announced immediately 1000 new users sign up here and vote for Armbian support. We already experienced in the past that the cheaper the device the cheaper some people behave.

 

If Armbian might start such a transparent discussion process and users feel they need to ignore developer reasoning then they can start a poll thread on their own asking for a specific new donate button. And then later they're able to vote for board support by donating the amount of cash they were talking about in the first place. That way it's also ensured that we won't start on 'PicoPi Bullcrap' ever since those people only buying as cheap as possible are also too cheap to donate a single Cent.

 

And again: Board bring up is fun, board support the more boring part consuming time, energy and resources. We should triple check whether devices are worth getting 'supported' status or not. That's why I already talked about .playground vs. .wip. Allows developers to focus on fun stuff without risking to waste later time on the boring part. But as we could see with OPi 2G-IoT that does not even work with .wip boards

 

[zador.blood.stained]

8 minutes ago, tkaiser said:

Again (!!!) my proposal is not to start as soon as someone sends us hardware but to open a new thread in not yet existing 'Board Bring Up Discussion' subforum.

This can be done in the "Private" subforum (IMO no outside interference before the final decision is a must, this thread is a good example), and then the thread can be moved to a visible subforum, either locked or open for discussion and for merging threads/posts related to this board in case it won't be supported.

[zador.blood.stained]

17 minutes ago, tkaiser said:

Again (!!!) two examples: https://forum.armbian.com/index.php?/topic/4378-nightly-images/&do=findComment&comment=33601 (why do we start with something like Orange Pi Zero Plus 2 H5, it makes absolutely no sense at all --> Armbian no, Android yes/don't care)

It can be locked/restricted as a CLI/server only target similar to H2+ Zero

[TonyMac32]

1 hour ago, zador.blood.stained said:

This can be done in the "Private" subforum (IMO no outside interference before the final decision is a must, this thread is a good example), and then the thread can be moved to a visible subforum, either locked or open for discussion and for merging threads/posts related to this board in case it won't be supported.

 

I agree.  If a board is really an obvious emergent problem, a statement can be agreed upon and stickied in a read-only board support forum and linked to whenever anyone asks why we don't support such-and-such board.  If something really changes, the situation could be re-evaluated.  That was actually my intention before finding this thread, while I recognized the example tag, I mistakenly thought it could serve both purposes.

[Bubba]

The way to change vendor behavior is thru $,  if there is no usable OS for the board a few people will buy a crap board

but they will not push others to buy it.

 

Now if the powers here select a board, build the OS and value added apps / options which the public wants then the public will purchase the board.

...Like the AP mode on the Zero..it makes no sense to me but by the posting here and orange.org it is a thing MANY want...so if Armbian offer a working solution for the AP mode those users would be happy..well util they used it and found the flaws.

In customer service telling someone they can not have something is worst than giving them something they WANT but is flawed in someway.

 

Yes there will be mistakes made, some boards may not be worth it, is no big deal.

 (if you are not making mistakes you are not really doing anything worth the time).

 

In another life.. I did Asterisk (VoIP) it's Open source, so the way to make money was to offer something others did not, that was "Asterisk@home" (which became trixbox / Freepbx / Nerdvittles ).

It was easy to install, to be up and running with a few clicks of the mouse (like here) and that fact bought in the noobs (non-tech) and every piece of junk computer they could drag out of the trash. We got "donations" by provide custom scripts / builds / added features . (for us our "Zero" was via chipset)

But we had to provide tech support for that crap to get the users to come and to donate both time and money.

[tkaiser]

1 hour ago, zador.blood.stained said:

This can be done in the "Private" subforum (IMO no outside interference before the final decision is a must, this thread is a good example)

Huh? So there's a reason to keep an inner circle or let's call it Elite? Why do people who want to discuss whether a specific hardware is worth the efforts to be supported needs a specific status?

 

The purpose of the Private subforum was to keep discussions that handle confidental stuff (eg. boards that are yet not released)... confidental.

 

I don't think it's a good idea to keep interested developers out. And again: The purpose of starting such a thread in 'Board Bring Up Discussion' can be just checking status quo. Vendor XY released a new board, so let's have a look what we can expect from hardware and vendor. If the vendor has shown multiple times in the past that he couldn't deliver most basic stuff (won't repeat it again and again), then simply let's collect that as a list known as 'things that need to be fixed first'. This way we also clearly communicate why it's not only about hardware but what we as developers need to do our work in the first place.

 

1 hour ago, zador.blood.stained said:

It can be locked/restricted as a CLI/server only target similar to H2+ Zero

 

I know what can be made. That's not the point. It's about how we as community decide what should happen. A few of us with commit rights to Armbian's repo found this H5 board in a package from Xunlong a while ago. What happened --> a .wip file appeared in the repo without prior discussion and in the meantime we have support threads that complain about Firefox not running nicely on this board (no wonder with 512 MB and arm64). To be clear: I always did the same in the past (adding boards on my own without prior discussion) but I think in the meantime that became the wrong approach since a lot of stuff has changed within the last year.

 

I'm constantly talking about how we can improve in this area. By establish a process or protocol that defines discussion first. Since then we would have talked about pros/cons and at the same time the public discussion here could have already helped people avoid buying the wrong devices. That's what I'm talking about all the time: A discussion happening with two goals: decision finding for us (is it worth the efforts/hassles/frustration?) and clearly communicating reasons to the outside (both board makers to be able to improve in the future and potential users to see what to expect or even better why). And even if result of the discussion is that we most probably never support the board in question (for reasons that are documented and accessible then) there may be reasons why we start to work on it anyway keeping it in .wip or .playground section forever (for example since it's the SoC bring up vehicle: if we want to support R40 boards in the future why not starting with the only one available now even if we refrain from supporting it since vendor behaviour is still so irresponsible/ignorant)

 

Of course this whole discussion is absolutely useless if some people with 'higher privileges' overrule this later and do what they want (that's the elite stuff I'm talking about that is also a great way to scare interested developers away)

 

But I'm getting tired babbling all the same BS again and again and give up now.

[zador.blood.stained]

27 minutes ago, tkaiser said:

Huh? So there's a reason to keep an inner circle or let's call it Elite?

Or let's call it "Developers".

 

27 minutes ago, tkaiser said:

Why do people who want to discuss whether a specific hardware is worth the efforts to be supported needs a specific status?

Because those people will have to dig through the documentation, schematics, repositories, sources and they will make things happen. Or not.

We can make a discussion public and open to anyone who is registered on this forum, but even if 5-10-20-100 people post there like "I really like this $5 board", "I would love Armbian to support this $10 board", "I'm really interested in seeing Armbian for this small and cheap board", this won't result in a single commit or pull request (from anyone outside of our group) that will change or improve things.

Then we are still down to the so-called "Developers" group, who not only may be interested in specific hardware, but can translate schematics, datasheets and vendor code drops into working board configurations, bugfixes and improvements. Or they may not be interested in this hardware at all, opposed to all users that already bought their new cheap "toy".

 

27 minutes ago, tkaiser said:

If the vendor has shown multiple times in the past that he couldn't deliver most basic stuff (won't repeat it again and again), then simply let's collect that as a list known as 'things that need to be fixed first'. This way we also clearly communicate why it's not only about hardware but what we as developers need to do our work in the first place.

I think everybody understands now that you want to throw away at least bananapim2ultra.wip, bananapim3.wip and possibly bananapim2.conf and bananapim2plus.conf. Since I don't own any of those feel free to create a thread and list the most significant HW and SW problems for each of the boards in question.

 

 

[zador.blood.stained]

1 hour ago, tkaiser said:

Why do people who want to discuss whether a specific hardware is worth the efforts to be supported needs a specific status?

Let's say we listened to the community (via an open discussion) and added a popular board - Orange Pi Zero.

Random MAC address issue on mainline kernel - most likely a result of one line missing in the Device Tree. How many people complained about this problem? How many people actually tried to solve this open (visible to everybody) problem? Tread was read 600 times, unfortunately no unique readers statistics are available.

Missing DVFS since kernel 4.11 - can be solved by copy-pasting some DT snippets with minimal adjustments and typing "git diff" with some file paths. How many people tried to solve this problem?

 

Also we added support for some H3 devices with a CSI connector, that requires a kernel patch to add processing of one GPIO value for CSI_EN line for some boards. How many people tried to solve this?

 

Edit: regarding Orange Pi Zero mainline image popularity - download count for 9 hours (not counting torrent downloads):

➜  ~  % grep 'orangepizero/nightly/Armbian' /var/log/nginx/access-dl.log | wc -l
65

 

[Igor]

2 hours ago, tkaiser said:

I was talking about why we behave like idiots and start to support boards solely based on the fact that a hardware vendor sent us dev samples worth few bucks.

 

I thing we got the point. Not sure if we really behave exactly that way, but yes, we need to change pattern and not jumping up when boards arrive. Agree on that. It's in our own good. No doubts about that.

 

2 hours ago, tkaiser said:

No polls/votes

On my proposal, developers has last word, but we still get valuable data when asking community what do they think - we can limit voting to old users with this much posts ... it's just a proposal.

 

I agree that the most cheap is also among most popular ones ... but those is hard to avoid - I am referring to Orangepi / Friendlyarm boards in general.

 

2 hours ago, tkaiser said:

And again: Board bring up is fun

It's fun but some pain always comes in the package. We can to cut it down and play smarter not harder 

Well - what about community supported boards - which does not need our approval? It should be in our interest to provide opportunity for anyone who want's to bring board into Armbian and benefit from anything what build script offers ... but we have to make clear that there is no support within the build process, at first login, don't provide downloads, ... etc. One good example are balbes150 creations, which we even think to merge in once, but it's some work ...

[TonyMac32]

3 minutes ago, tkaiser said:

Huh? So there's a reason to keep an inner circle or let's call it Elite? Why do people who want to discuss whether a specific hardware is worth the efforts to be supported needs a specific status?

 

The purpose of the Private subforum was to keep discussions that handle confidental stuff (eg. boards that are yet not released)... confidental.

 

I guess I should clarify my point then.  As I see it there are really 3/4 major devs here, who shoulder the majority of the work.  There are a handful of others who support specific devices from varying angles and levels of capability, like myself.  The use of a non-public subforum is not a "cloak and dagger" inner circle in this case, it's a simple measure to ensure some focused discussion about devices along the lines of vendor maturity, architecture, use case, dev workload, etc.  If there is to be official support on Armbian's part, at the very least the core team should agree to take on that work, and then a public statement of that discussion and reasons to back it (Not just a "nope, that board sucks and we hate it").  Given this project's advance notice of many devices, it would still fullfill the goal of educating those who might want to go out and jump on a brand new device (Tinker Board?  Some buyer's remorse over here).

 

As for what to do with other things:  how about a ".community" list or something analogous?  This could handle those devices that are "same as except", or unproven vendors, TV boxes, etc.  Still available to build, however tagged as "unofficial/community support" until either defined standards are met or there is a consensus that the remaining items are worth ignoring (micro-USB supply perhaps, or inadequate thermal solution, headless only, that kind of thing).  It has its own traps and issues, but perhaps an idea.  

 

For releases, I agree some sort of release candidate system might need to be used, at present only people running nightlies or building themselves really test new kernels/etc, and that is a small group all things considered.  A more general audience may try out a release candidate if published and provide useful feedback.

[tkaiser]

1 hour ago, zador.blood.stained said:

Or let's call it "Developers".

 

I call it inner circle if only those who have access to the Private forum are allowed to join these discussions. Again: I propose a new subforum to discuss board bring up decisions. That's not meant for end users but for a developer starting with something as proposed in post #1 of this thread (that's why this thread title has the '[Example] in its name): an overview where we are, what's to expect, pros/cons. This is the most basic requirement for starting a thread. Then I looked through this thread again and found exactly one single post that was 'end user stuff', all the others were more or less focused on device discussion. Also @Kwiboojoined and IMO this is something Armbian forum should allow. Joining development efforts even if the end result is not Armbian but something else (at least that's my goal since the two years I joined now: stop people wasting their time moronically in vendor forums and let Armbian be a place of interchange and development)

 

If people misuse the 'Board Bring Up Discussion' subforum for stupid 'Hey, when is XY ready?!' threads or start to destroy such threads then posts have to be moved to somewhere else. Now that a few more people join moderator crew that shouldn't be that hard to achieve.

 

1 hour ago, zador.blood.stained said:

that you want to throw away at least bananapim2ultra.wip, bananapim3.wip and possibly bananapim2.conf and bananapim2plus.conf.

No, I just want that we start to behave differently in the future. And DOCUMENT decisions and what's missing to BE ABLE to support devices. This specific vendor suffers from one person obviously not able to get anything (eg. not merging this pull request, or doing brain damaged copy&paste jobs thinking this would be technical documentation) but if we start to discuss new boards and list the results of their stupid ignorance again and again maybe even they are able to improve.

 

1 hour ago, zador.blood.stained said:

Let's say we listened to the community (via an open discussion) and added a popular board - Orange Pi Zero

I remember differently. There was a lot of excitement about this board based on the announcement, then I started to add it without having the hardware, Igor got his sample the next day, confirmed he 'got Armbian running on it in no time' and days later we got also Wi-Fi working and everything else. It was us developers adding this board without questioning anything and I'm currently trying to prevent that happening ever again. Discussion first, results documented, then either start working on the hardware or not.

 

I think I got your point about users requesting something without contributing anything but as already said my idea is a different one: I want an open thread started by developers, ignoring user requests (at least in the beginning, thread disruptions can be moved into Free or device specific section where similar discussions happened anyway in the past), discussing development questions, hopefully attracting new/more developers and in the end we get a (maybe locked) thread documentating support status and reasons for the decisions made.

 

1 hour ago, Igor said:

developers has last word, but we still get valuable data when asking community what do they think - we can limit voting to old users with this much posts ...

 

We will get user feedback as we got it in the past already. Look at threads like the above 'Orange Pi Zero went to the market' (11 pages, tens of thousands views) or the one for NanoPi NEO/Air. Let board bring up discussion happen here, let users discuss over there, move inappropriate posts from here to there too (requires labeling this subforum 'developer discussion only' or something like that that does not sound that stupid. With a pinned thread explaining rules and purpose of these rules)

 

1 hour ago, Igor said:

Well - what about community supported boards - which does not need our approval? It should be in our interest to provide opportunity for anyone who want's to bring board into Armbian

 

This has to be possible as in the past. But at the same time there appears a .wip file or a pull request with such a thing gets accepted we must ensure that a thread is opened discussing what's going on. As already said multiple times: My concern is support status and communicating clearly to the outside why we don't want to support a board (yet). Even then working on boards must be possible but due to a negative result of board bring up decision boards might remain in .wip (or .playground) state for now or ever. But at least it's documented what's happening and users get the chance to learn from such decisions. To avoid specific devices, eg. don't buy OPi Zero Plus 2 H5 but H3 instead since the latter is suitable for specific use cases while the H5 variant simply will suck forever. Or to avoid specific vendors unless they change their behaviour (let users kick their ass until they improve).

[zador.blood.stained]

52 minutes ago, tkaiser said:

Again: I propose a new subforum to discuss board bring up decisions. That's not meant for end users but for a developer starting with something as proposed in post #1 of this thread (that's why this thread title has the '[Example] in its name): an overview where we are, what's to expect, pros/cons. This is the most basic requirement for starting a thread.

...

If people misuse the 'Board Bring Up Discussion' subforum for stupid 'Hey, when is XY ready?!' threads or start to destroy such threads then posts have to be moved to somewhere else. Now that a few more people join moderator crew that shouldn't be that hard to achieve.

So essentially the same, but relying on active moderation instead of access permissions to keep the discussion on topic.

 

52 minutes ago, tkaiser said:

I think I got your point about users requesting something without contributing anything but as already said my idea is a different one: I want an open thread started by developers, ignoring user requests (at least in the beginning, thread disruptions can be moved into Free or device specific section where similar discussions happened anyway in the past), discussing development questions, hopefully attracting new/more developers and in the end we get a (maybe locked) thread documentating support status and reasons for the decisions made.

Well, we tried to attract new developers even by offering board samples, and you can check how effective that was by looking at GH issues tagged as "task", so I don't expect the situation to change anytime soon (so public or private discussion wouldn't really matter since most of developers already have access to the "Private" subforum).

 

52 minutes ago, tkaiser said:

Then I looked through this thread again and found exactly one single post that was 'end user stuff', all the others were more or less focused on device discussion.

I looked through this thread again.

Pricing? Not really related to development.

Multimedia features (HW video acceleration, video output resolution, HDMI audio formats)? Again too early to discuss in the development related thread IMO.

 

I would rather see open-source SPL information and progress, u-boot defconfig mainlining progress for this board, ATF situation - then we will at least have a properly working u-boot. After that it's OK to move to the kernel development, and after that - userspace stuff and bug fixing, benchmarks, optimizations, etc. So definition of "development" is really subjective.

[tkaiser]

6 minutes ago, zador.blood.stained said:

So essentially the same, but relying on active moderation instead of access permissions to keep the discussion on topic.

Understood, it must be an inner circle. People like @TonyMac32or @Myywho found their way to here by joining open discussions (AFAIK) should be kept out.

 

8 minutes ago, zador.blood.stained said:

Well, we tried to attract new developers even by offering board samples, and you can check how effective that was

I remember differently. Xunlong offered board giveaways, we (the inner circle) discussed whether we want to organize a draw or try to attract more contributors. Some improvements were made but it's obvious that we don't get more contributors in return of hardware worth a few bucks. I still think it's a motivational problem and an 'inner circle' will prevent getting more people joining development efforts.

 

In the past IMO we also suffered from discussions here in the forum 'moderated' in an 'inner circle' style by at least one former moderator. IMO this is something we should avoid at all costs if we want more people joining the party.

 

18 minutes ago, zador.blood.stained said:

Pricing? Not really related to development.

Not for development but to estimate whether it's worth supporting a device. If price is too high we run in the same situation as with 'dev samples only' boards like Roseapple Pi. IMO that's pretty important and was covered by the sentence 'Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)' in post #1.

 

20 minutes ago, zador.blood.stained said:

Multimedia features (HW video acceleration, video output resolution, HDMI audio formats)?

Important if we want to discuss use cases. I'm biased (since I don't care at all about this Multimedia stuff) but I'm also aware that my use cases aren't those of the majority of people later using the device. That was 'RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth)' in post #1.

[zador.blood.stained]

15 minutes ago, tkaiser said:

Understood, it must be an inner circle. People like @TonyMac32or @Myywho found their way to here by joining open discussions (AFAIK) should be kept out.

OK, I don't follow Rockchip development much, in the Sunxi world the "inner circle" well represents the main developers who actively participate in discussions about the low level stuff.

 

15 minutes ago, tkaiser said:

Not for development but to estimate whether it's worth supporting a device.

...

Important if we want to discuss use cases. I'm biased (since I don't care at all about this Multimedia stuff) but I'm also aware that my use cases aren't those of the majority of people later using the device.

Then we still should split the discussions of use cases and hardware features from low level development - you can imagine using a board as a NAS or as a multimedia center but if dealing with DRAM configurations (different sizes and frequencies) is a pain in the butt, then I would think twice about adding support for the device at all until the situation improves.

[tkaiser]

29 minutes ago, zador.blood.stained said:

but if dealing with DRAM configurations (different sizes and frequencies) is a pain in the butt, then I would think twice about adding support for the device at all until the situation improves.

 

Absolutely! I would call this a show-stopper that can happen in early development situation and invalidates all 'in theory' considerations before. But IMO this shouldn't change a bit how we deal with board additions in the future.

 

Please remember situation with OPi Zero: we (some from the inner circle) were excited, added the board, improved settings like crazy. Later we discovered unfortunate Wi-Fi power management settings, then Wi-Fi here being somewhat crappy anyway. If there would have been a rather clean 'board bring up' thread such findings would have been documented (adjusting post #1 in the respective thread), board support rating would have been adjusted and post #1 of the thread could act as something like a landing page for the specific device (moderators pushing newbies to this 'page' for example).

[martinayotte]

2 hours ago, tkaiser said:

To avoid specific devices, eg. don't buy OPi Zero Plus 2 H5 but H3 instead since the latter is suitable for specific use cases while the H5 variant simply will suck forever.

Why H5 variant sucks ?

We first added the OPiPC2, then we added ZeroPlus2-H5 ... They are working fine.

Of course, the DRAM size is a limitation. We should also limit our expectations ...

[giri@nwrk.biz]

nevermind

[tkaiser]

53 minutes ago, martinayotte said:

Why H5 variant sucks ?

We first added the OPiPC2, then we added ZeroPlus2-H5 ... They are working fine.

Of course, the DRAM size is a limitation. We should also limit our expectations ...

 

Really, I can't stand it any more

 

It's about the stuff those of us from the inner circle don't seem to care about: Pricing and use cases!

 

Orange Pi Zero Plus 2 is sold for $18.90 (H3) or $19.90 (H5). Why spending the additional dollar? No idea but customers might think since 'more expensive == better' or '5 is more than 3'.

 

Feature set of this board:

1. no Ethernet (forget about those use cases with NAS in mind)
2. HDMI (so people will buy it since they think it would make up for something that can be used as a 'Desktop' -- that's the main difference to similar boards like OPi Zero or NanoPi NEO/Air --> no HDMI --> no multimedia/desktop use cases. Please forgot about those poor souls that are really trying to use shitty TV out on OPi Zero)
3. WiFi (great, at least some connectivity. Not that shitty like XR819 but still 1T1R/2.4GHz crap)
4. eMMC (no feature, just pleasing those who are confused about storage)
5. Camera header (just like NanoPi Air)

Now let's check software situation (totally different between H3 and H5 BTW!), then target audience and what works with H3 and H5:

• If you just want to do some GPIO stuff you're plain stupid if you choose this Zero Plus 2 BS compared to the real Zero -- you pay at least $10 too much.
• If you want to use camera this only works with H3 since CSI support is still missing in mainline kernel -- @martinayottecare to accept that 'stable' kernel for all these boards is 'legacy' which is not available for H5 since the H5 BSP is such a horrible pile of shit that no one right in his mind will touch this ever?
• If you want to use this board as desktop again it's only reasonable with the H3 variant for VARIOUS reasons: no video acceleration with mainline, no GPU acceleration with mainline, not enough RAM when running a 64-bit Linux (we know this over a year now!)

All of this is f*cking obvious if we start to look at this project from the outside and not only play 'developer sitting in the cellar and doing important stuff users don't understand anyway'. Use cases and pricing determine user expectations. I don't know why anyone would buy this OPi Zero Plus 2 (since if I want a boring Desktop Linux or a shitty retro gaming thingie then I would think first and get an OPi One or Lite instead). But at least the H3 variant is somewhat useable for the use cases it will be bought for. In contrast to the H5 variant which simply will suck.

 

It's plain stupid to support this board in Armbian and I finally give up now since it get's too boring to repeat the same stuff over and over again.

 

 

[giri@nwrk.biz]

On 20.6.2017 at 9:05 PM, tkaiser said:

Please forgot about those poor souls that are really trying to use shitty TV out on OPi Zero

 

I use my OPiZ as portable handheld gaming console. No problem with AV out on small screens. (I guess my soul is not that poor then)

[zador.blood.stained]

35 minutes ago, tkaiser said:

Orange Pi Zero Plus 2 is sold for $18.90 (H3) or $19.90 (H5). Why spending the additional dollar? No idea but customers might think since 'more expensive == better' or '5 is more than 3'.

Running tasks that benefit from Cortex-A53 cores (like OpenVPN if I remember correctly, using wireless, USB and OTG for the network interfaces)? Yes, this is not something obvious and it'd better have Ethernet instead of HDMI and CSI interfaces.

[tkaiser]

5 minutes ago, zador.blood.stained said:

Running tasks that benefit from Cortex-A53 cores (like OpenVPN if I remember correctly, using wireless, USB and OTG for the network interfaces)? Yes, this is not something obvious and it'd better have Ethernet instead of HDMI and CSI interfaces.

 

Ok, user perspective not wanted. Please forget about what I posted here. It's just me, I'm feeling stupid and most probably I am.

 

I understood that this H5 board is a great device for esoteric use cases and that we should not care a single second about misleading user expectations. Don't care about reasons or whether makes some sense at all, just start to work like an idiot if a hardware vendor throws dev samples worth a few bucks at you. Never ever think about what this might be useful for.

[Bubba]

Watch out or the next thing we will have is.....

 

"End-users talking to developers, manufacturers talking to consumers, dogs and cats living together, Mass Hysteria, human sacrifice"....
....Jonathan Peterson, Technical Consultant, IBM eBusiness Services
 

[Bubba]

I also do not get why the vendor would make a board like the zero h5, I got the h3 ..use it as a desktop..never...to slow and the H5 would not be any better.

 

The Zeros I got I am happy with (crappy wifi and all).

The end users will always push for the cheap way, you must SHOW them why it is better to purchase A over B, as TK has said over and over the end users can not have much say in what boards you support

if they did then all there would be is crappy, unusable boards with great sofware.

 

"A wise man can learn more from a foolish question than a fool can learn from a wise answer."
"A goal is not always meant to be reached, it often serves simply as something to aim at."
Bruce Lee
 

[giri@nwrk.biz]

2 minutes ago, Bubba said:

I also do not get why the vendor would make a board like the zero h5

 

The answer to this question is simple, because they can sell it

[TonyMac32]

Yes, it is a reflex that a hobbyist has, "to collect all the things".  Especially when one looks like it should be shinier than the others.  BSP's, true performance, driver catastrophes, kernel defilement doesn't show up in the advertisements for these devices.  It is not helped that the "flagship" SBC in most people's minds out there is the Pi 3, a micro-usb powered usb-hub throttled VPU-constrained machine with very poor resources.  Compared to that, anything with high clock numbers or extra "RAM Chips" looks like an amazing deal, people tend to take the community support over there for granted.

 

I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.

 

 

[Bubba]

45 minutes ago, TonyMac32 said:

I do like the Wiki idea, however in a less ambitious sense:  We should list, with no "rose-colored glasses", exactly what the pros and cons are of each board supported, discrepancies between hardware specification and advertised capability, and recommended use cases for each board.  For those use cases, I would personally require a definition of minimum requirements and recommended requirements per use case, and those would live on their own pages.

 Yes