chwe Posted January 26, 2018 Posted January 26, 2018 Armbians board support philosophy leads sometimes to frustration. Cause this topic came up from time to time in various threads. The aim of this thread is to summarize all those discussions and have them 'in one thread'. Current situation: There's no strict rule what is needed for getting 'armbian support' neither to drop support for a specific board. 49 boards are supported, 8 are WIP and 13 are deprecated. Supported SoCs: i.MX6, A20, A33, A64, H2+/H3, H5, ARMADA 388, RK3288, S805, S905x, Exynos 5422, WIP SoCs: ARMADA 3720, RK3328, S5P6818, S905, Opinions: I'm sure, I don't catch all opinions here, but instead of merging from various threads the comments I try to summarize some of those ideas. I'm sure that I will miss some points, and everyone I mention here is free to correct me and I will edit my post to represent you correctly. @TonyMac32: config templates (what kernel options/etc are common as possible across all Armbian kernels/etc). "freezing" would be preferable to "dropping". This project provides more than enough information to recompile kernels and add modules/make small changes/etc "matrix of what works" @tkaiser (hard to summarize.. ): reduce the number of boards and increase the support level focus on interesting boards for different use cases clear structure and focus of the project, more explanation why and when a board is supported @Igor We need to define very well what support is and throw out more deprecated boards for our own good. We are not busy solo because of too many board support count - new boards actually added little problems - but overall project expansions, lack of resources, rules, organization troubles .. @botfap standardised Armbian functionality about 10 major boards with minor variations & "community" supported boards Others might be also on this list, but I didn't have all opinions in mind and since they are spread in various threads I forgot where they are (that's a major reason why this thread comes up). So please don't be upset if I didn't mention you personally. I hope, we can keep this thread 'as clean as possible' means answers like: "don't drop/add support for board xy, I use 10 of them at home..." that's not the place for this. "I think this too" is also a waste answer... There will be a overlap to other topics like the: Improve 'Support over Forum' situation Web page(s) redesign Various board bring up threads an overlap is ok, but if it drifts mostly to another topic I'll move these posts to the topics which I think they belong. In case there are things I wrote which are obviously wrong, let me know I'll correct it as soon as possible. btw: I'm not happy with the title, therefore I'm open for a better one but the main focus should be on the topic and not on the name of this thread.
zador.blood.stained Posted January 26, 2018 Posted January 26, 2018 My opinion (regarding project aims): - View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project. - Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues. - Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15. - We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. - Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run. On 26.01.2018 at 10:39 PM, chwe said: @tkaiser (hard to summarize.. ): focus on interesting boards for different use cases The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10. Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper. A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device. Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc. 3
chwe Posted January 26, 2018 Author Posted January 26, 2018 11 minutes ago, zador.blood.stained said: The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10. From what I understand, he thought more about a cheap - middle class - upper class board for each use case (e.g. nas, IoT whatever). As I said, it's hard to summarize the opinions and I hope that the mentioned people spoke on their own to clarify their opinions. my opinion: armbian is a 'base plate' so that everyone can build his own house on top of it. armbian tries to catch fixes to improve the support situation for the hardware a boardmaker provides could it help to use more 'post install scripts' keeping armbian more 'generic'/predictable and pack the 'fancy features' on those scripts/'user patches'? People can apply those scripts and we summarize somewhere which scripts works on which boards. Somehow similar to the OMV builds. 34 minutes ago, zador.blood.stained said: People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues. Mali = good multimedia performance seems to be burned in beginners head... We aren't good in explaining what's needed for a good 'Kodi device'... I hope that we can address some of those issues with the new web page. The more boards we support, the more people with various expectations what should work will came up. IMO it's important to explain people what they can expect from this project. Another question which I have. Older kernels/BSP kernels: beside things like hardware accelerated video decoding, Mali & CSI/DSI support are there other use cases where people benefit from them? I know that not every SoC is on the same level in case of mainline but (I suppose) those BSP kernels needs a lot of 'house keeping' is it worth the effort? Does it make armbian more unpredictable?
TonyMac32 Posted January 27, 2018 Posted January 27, 2018 1 hour ago, chwe said: We aren't good in explaining what's needed for a good 'Kodi device'... I hope that we can address some of those issues with the new web page. Kodi can't explain it either, so they also wind up handling all sorts of questions about ridiculous hardware. 1 hour ago, chwe said: Older kernels/BSP kernels: beside things like hardware accelerated video decoding, Mali & CSI/DSI support are there other use cases where people benefit from them? That's really it in a lot of cases, but sometimes it goes deeper, for example the RK3328 doesn't even have HDMI out on mainline (I keep meaning to patch our build, I found patches to add it) Some boards don't have frequency scaling/etc. 2 hours ago, zador.blood.stained said: - View Armbian as a base, reasonably minimal OS images. I agree with this. I think most people will understand apt and if not the community contributors who aren't coders can write little how-to's as far as newbies with SBC's are concerned. I see it as a benefit to move the burden of this from the developers trying to make the images fool-proof to the advanced users providing guidance. I recognize this depends on people stepping up, there are only so many @Tido's and @chwe's available. ;-) As @chwe properly summarized, I think a template for board support would be handy. Not that it was terribly hard to figure out, but I made a few mistakes along the way anyhow... Perhaps a kernel config including all the "Armbian-generic" options per kernel (yes, crappy to do with a ton of kernels. Probably start with mainline and work backward) I haven't looked at nand-sata-install in terms of how it's written, however some of @tkaiser's feedback suggests it's a tool that has experienced significant "scope creep". Would it be beneficial to instead make a script per board and make it part of the bsp? Are there other tools where this would be advisable?
zador.blood.stained Posted January 27, 2018 Posted January 27, 2018 12 hours ago, chwe said: Mali = good multimedia performance seems to be burned in beginners head... Maybe people make parallels to the "graphics drivers on x86/x64 desktop on older Windows versions" situation: no vendor GPU drivers = bad performance, installed vendor GPU drivers = good performance. 12 hours ago, chwe said: We aren't good in explaining what's needed for a good 'Kodi device'... A 'good Kodi device' is a device supported by Kodi developers, and if such device doesn't exist it can't be our problem given resources that we have. 8 hours ago, TonyMac32 said: I haven't looked at nand-sata-install in terms of how it's written, however some of @tkaiser's feedback suggests it's a tool that has experienced significant "scope creep". Would it be beneficial to instead make a script per board and make it part of the bsp? Are there other tools where this would be advisable? IMO it should be generic with platform-specific hooks (like for writing u-boot to SPI or eMMC special partitions) and without support for legacy sunxi NAND. 8 hours ago, TonyMac32 said: As @chwe properly summarized, I think a template for board support would be handy. Not that it was terribly hard to figure out, but I made a few mistakes along the way anyhow... Perhaps a kernel config including all the "Armbian-generic" options per kernel (yes, crappy to do with a ton of kernels. Probably start with mainline and work backward) Unfortunately AFAIK there is no good way for merging/splitting/comparing kernel configs for different kernel versions. We can start by making a list of options and menus that should be enabled or disabled.
TonyMac32 Posted January 27, 2018 Posted January 27, 2018 6 hours ago, zador.blood.stained said: IMO it should be generic with platform-specific hooks I like that as well, I wasn't sure how far we would want to go along those lines. 6 hours ago, zador.blood.stained said: Unfortunately AFAIK there is no good way for merging/splitting/comparing kernel configs for different kernel versions. We can start by making a list of options and menus that should be enabled or disabled That's what I figured, and was more or less what I was thinking.
chwe Posted January 27, 2018 Author Posted January 27, 2018 8 hours ago, zador.blood.stained said: 20 hours ago, chwe said: Mali = good multimedia performance seems to be burned in beginners head... Maybe people make parallels to the "graphics drivers on x86/x64 desktop on older Windows versions" situation: no vendor GPU drivers = bad performance, installed vendor GPU drivers = good performance. Can we summarize this data somehow (could be part of a faq in future - in case the new website has something like this). E.g. explaining the difference between mali and hardware accelerated video-decoding (should be a easy task) and more important which board/SoC has working hardware accelerated video-decoding (kernel, Codecs & performance you can expect). I've neither enough boards nor a HDMI screen to test this (to be honest, I'm really not interested in hw acc. video-decoding stuff... ). But there's a lot of interest in this field and it should avoid 'stupid questions' about this topic. 8 hours ago, zador.blood.stained said: A 'good Kodi device' is a device supported by Kodi developers, and if such device doesn't exist it can't be our problem given resources that we have. IMO armbians focus isn't on multimedia and I'm happy that we aren't. Nevertheless it makes sense to point this out clearly. It's IMO better to say that you aren't able to fulfill all expectations than let them 'run into the wall'. Would it make sense that the *generic armbian* has no HW acc. decoding but in the buildscript there's a option to activate (where possible) it? My main idea behind this - people know that 'default' armbian does not provide HW acc. decoding and if you're interested in this feature it's your homework to pick up a board where armbian provides this feature. 9 hours ago, zador.blood.stained said: IMO it should be generic with platform-specific hooks (like for writing u-boot to SPI or eMMC special partitions) and without support for legacy sunxi NAND. If I had it right in mind there was an idea to boot a 'minimal linux' to do this. So that there's no 'copying on a living system' to make sure data-integrity is given. Would it make sense to consider this as soon as this script is rewritten? A more general question. For getting 'full armbian support', would it make sense to define that for minimum X (X<1 in case someone drops out from the project or hasn't the time at the moment) of the maintainers have this board physically at home? Not only a pre-production sample but also the version which is sold to the customers. Doesn't mean that you have to test every build before deploying but in case something breaks someone (experienced enough to use proper powering, sd-card, networking etc.) can confirm/deny it.
zador.blood.stained Posted January 27, 2018 Posted January 27, 2018 23 minutes ago, chwe said: E.g. explaining the difference between mali and hardware accelerated video-decoding (should be a easy task) Already exists, at least for Allwinner devices: https://linux-sunxi.org/Media_IP_cores 23 minutes ago, chwe said: I'm really not interested in hw acc. video-decoding stuff... ). I'm not interested in this too, and this can be also explained: want a multimedia device - buy an Amlogic based TV box that comes with working Android, good power supply and IR remote. Want a DIY IoT device - buy whatever you want but forget about good multimedia performance and support for popular video formats. 23 minutes ago, chwe said: IMO armbians focus isn't on multimedia and I'm happy that we aren't. Nevertheless it makes sense to point this out clearly. It's IMO better to say that you aren't able to fulfill all expectations than let them 'run into the wall'. One of the problems is that we don't have a focus, project-wide goals, etc. If there was a developer with enough free time interested in multimedia we could have different results than we have now. 23 minutes ago, chwe said: For getting 'full armbian support', would it make sense to define that for minimum X (X<1 in case someone drops out from the project or hasn't the time at the moment) of the maintainers have this board physically at home? Not only a pre-production sample but also the version which is sold to the customers. This would need to have a lot of exceptions or clarifications. I.e. there are a lot of different revisions of Lime2 board, some of them have different Ethernet PHYs which requires different TX/RX delays or even a different driver. Another example - new revision of Clearfog Base (which is a pretty expensive device) has PCIe support on M.2 slot that requires extra software configuration to activate and test. I'm not even talking about Cuboxes and Hummingboards which can have different base and carrier combinations.
chwe Posted January 27, 2018 Author Posted January 27, 2018 8 minutes ago, zador.blood.stained said: 31 minutes ago, chwe said: E.g. explaining the difference between mali and hardware accelerated video-decoding (should be a easy task) Already exists, at least for Allwinner devices: https://linux-sunxi.org/Media_IP_cores That's the perfect example for: 10 hours ago, zador.blood.stained said: We aren't good in explaining what's needed for a good 'Kodi device'... replace 'Kodi' with *random feature*. The knowledge is here, experienced users/developers (and people with a hight google-fu) know where you find it but we as armbian project aren't good in providing this information for beginners. In case we wanna be more *beginners friendly* we have to provide this information in a 'beginners friendly' way. 17 minutes ago, zador.blood.stained said: One of the problems is that we don't have a focus, project-wide goals, etc. If there was a developer with enough free time interested in multimedia we could have different results than we have now. I hope that this thread could help to define such goals. And if a developer with this interests join the team - great. But wouldn't in make sense to provide him a 'clear base' means that he don't have to deal with various implementations or at least document what's done/ not done. 31 minutes ago, zador.blood.stained said: This would need to have a lot of exceptions or clarifications. I.e. there are a lot of different revisions of Lime2 board, some of them have different Ethernet PHYs which requires different TX/RX delays or even a different driver. Another example - new revision of Clearfog Base (which is a pretty expensive device) has PCIe support on M.2 slot that requires extra software configuration to activate and test. I'm not even talking about Cuboxes and Hummingboards which can have different base and carrier combinations. If a boardmaker is interested in 'full armbian' support, it should be his interest to provide the samples (or a dev is interested enough to buy it by himself). Doesn't mean: I give you X dev samples and you guarantee full armbian support. It's more a 'without enough dev samples' there's no possibility for 'full support'. I guess people who buy boards like the Clearfogs are 'a bit more experienced' - means that they can fix (partly) things on their own. The majority of the armbian users have boards with a price <100$. This group is 'less experienced' and struggle more often with bringing things up and running. I think it's important to provide them the information what armbian provides and what we don't provide. As long as a SoC/SBC isn't able to deliver the aims of armbian (which still need to be defined) the board is taged as .wip... As soon as the aims are defined, @TonyMac32s "matrix of what works" table would make sense.
zador.blood.stained Posted January 27, 2018 Posted January 27, 2018 15 minutes ago, chwe said: If a boardmaker is interested in 'full armbian' support, it should be his interest to provide the samples (or a dev is interested enough to buy it by himself). It's not a problem for a cheap and/or large quantity device, but (if we come back to the interest since open-source development is often driven by personal interests of participating developers) the most interesting devices usually are the niche ones, often made in a BTO queue (examples: Pinebook, Helios4, Pine64 cluster board), where if board makers start to throw free samples left and right they would be out of business pretty quick if they don't sell anything else. And often (i.e. with A64 based devices) the initial software state can be described as "bad" and development is relatively slow, so manufacturers would have to make investment in free samples that may not pay back (i.e. A64 mainline development is already overshadowed by the release of AW H6 SoC and Rockchip alternatives in similar or better to A64 price-features-performance brackets).
Igor Posted January 28, 2018 Posted January 28, 2018 IMO, minimizing complexity and subsequently saving energy should be a recurrent activity. Its so simple to get lost in a pile of code, projects and tasks. Few of people, including myself, are too involved and sometimes is getting too much. I don’t want to get depressed or disabled by stress, so more tasks should be redistributed or cut. It's not just about board support count. When a board can come to a support list: - if there are not a lot of problems and most of the stuff already work. At least: network, (HDMI), thermal protection, to run as a server. - if there is at least one stable kernel, - if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support - [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1 - what else? From this perspective, H3 NEXT images should now get a support status. Should they? Shell we merge forums into one? Its yet another decision to make? Should I just do it or shell we spent "long hours on meetings"? BTW. There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative. Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? There are many uncertainties and it’s a hit and miss game per se. Or rather push here and there – only our initiative is anyway not enough – and move the board among supported, when we have enough "ifs" on the table? In essence is all about a kernel, not boards. I would rather start talking from there, always. And what @zador.blood.stained already exposed - there is usually a personal motive to work on some board or type of problems and we have to consider that, when doing some plans or talking and organising the work around the project, but certain things, those which might not require a lot of time and energy, could be agreed upon. On 26. 1. 2018 at 9:38 PM, zador.blood.stained said: project aims Reasonable minimal OS images, exactly. Perhaps we have to look on this more from the user side. But we face a big variety, from »I am new to Linux« down to kernel hackers. Well, first ones take a lot of time and ask stupid questions, while others don’t ask much, but when they do, sometimes is not possible to answer – because of quantity, complexity or we simply don’t know the answers. On 26. 1. 2018 at 9:38 PM, zador.blood.stained said: Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15. Cleaning is a very good idea but its some work. On 26. 1. 2018 at 9:38 PM, zador.blood.stained said: - We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. - Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run. 2 Yes, this is a good description, but how users see this? Each Linux distribution is nothing but a mix of just some packages. Some only mix and add a stamp, others do big changes. Nevertheless, how big changes are, we have to tell people, where we can help and for what we ask people that is better to use a Google or ask elsewhere. This makes me think to do some changes to a forum (at once) and remove »Common issues« since they are nothing but a generic Debian/Ubuntu problems (which should not be our problem) and merge them with »Peer to peer«. There we add a sticky where and how to search. Also move all nontechnical stuff from »General chit chat« as well. I hardly catch up on topics and can't moderate forum content. If this is too much for current moderator team, it should expand. New WEB is under construction and the person who is doing the actual work - from UX and design perspective - is doing this on biased limited input. Old WEB, the way it looks now, is a patch over patch over patch. Affiliate Amazon links are added value content, but since it’s tied to a kernel only, it might not show up completely correctly. This problem is being considered in the new database design. Current WEB is not a representation of what I or what we wanted to show. That’s the reason something is going on in this field. A basic logical concept of WEB is already standing, without any content. It's possible to add direct comments and check actual navigations - currently, only me and Tido were added comments and if anyone wants to participate in the process, send me a PM and we will ger credentials. Currently, we have a basic frame, UX is getting better and database/web management is designing from scratch. On 26. 1. 2018 at 10:43 PM, chwe said: Mali = good multimedia performance seems to be burned in beginners head... It's a stereotype which won't just go away. We can only send those who come up with such questions to the place where all those common things, like power supply, SD cards, ... essentially to the "Getting started"/"welcome to forum" and simply stating that Armbian is a generic Linux distribution and we don’t cover such special cases. KODI might work, but most likely won't and you better look after a special multimedia distributions like Openelec, Librelec, … In any case, users must be aware how to find such information from a very first page. Such questions are considered in a UX redesign over and over again. 2
Tido Posted January 28, 2018 Posted January 28, 2018 1 hour ago, Igor said: I hardly catch up on topics and can't moderate forum content. You don't have to follow and answer everything - be picky - every user of the forum can decide whether or not to answer to some post or not. 1 hour ago, Igor said: Also move all nontechnical stuff from »General chit chat« as well. I think I don't understand what you mean by that. 1 hour ago, Igor said: is doing this on biased limited input it is limited but we brought in what was written in the thread before. 1 hour ago, Igor said: There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative. Would be nice to get some feedback what others think about it.
TonyMac32 Posted January 28, 2018 Posted January 28, 2018 40 minutes ago, Tido said: 2 hours ago, Igor said: There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative. Would be nice to get some feedback what others think about it. Perhaps IRC as well, It's usually 00:30 here when any of you are waking up, and after the day job and time with family, you are all asleep again. ;-)
chwe Posted January 29, 2018 Author Posted January 29, 2018 2 hours ago, Igor said: Few of people, including myself, are too involved and sometimes is getting too much. I don’t want to get depressed or disabled by stress, so more tasks should be redistributed or cut. It's not just about board support count. Keep in mind that 'not everything is perfect' doesn't mean that 'everything is shit'. I hope by some more 'definition' what armbian is (and what not), we can reduce the load a little bit. 2 hours ago, Igor said: - if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support - [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. I think I said this more than once... If there's no (or only minor) interest from a developer and nobody from the community want to test things which are made for *random board*, I see no reason to keep support. Maybe this 'motivates' the owners of those boards to 'step in' and help with easy tasks (like testing basic function). When not, @TonyMac32s approach, "freezing", seems to be a good idea. It's like when your mom doesn't wash your clothes anymore.. As soon as it gets smelly and you have a date with the new girl you met recently, you will take care that your clothes are washed (even if it needs some personal contribution to this 'process')... 3 hours ago, Igor said: Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? Support proposals are IMO needed when we talk about a new SoCs. I'm quite sure this will happen soon with the H6 SoC - it has some nice features, seems to be cheap and the software situation from the vendors are messy... Can't wait to see more: "when do you support *random H6* board? Why is mPCI not workig??" threads... IMO when no dev has the board (or has it, but no time/interest/motivation to bring it up) a board should be marked as CSC. WIP should be for the boards where 'kernel is not ready' or board is a bit tricky to handle. Interesting boards (from a dev point of view) like the helios, clearfog, espressoBin can be WIP for a long time (when they are not ready). Those boards are IMO nothing for an *beginner*, an experienced user can deal with WIP and a beginner will learn it the hard way but is warned if the board is tagged WIP. 3 hours ago, Igor said: It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? one example 'gone wrong' is no statistical evidence that the process is wrong.. Those board bring up/ support proposal threads is actually the first one I read as soon as I'm interested in a board. You get a 'status update' you see who's interested in this board too and you see the progress... Even for a board like the OPi 2g-IoT which is more or less dead, the few people interested in it report from time to time their efforts and success there (this was before it was called 'board bring up' but it has more or less the same function). 3 hours ago, Igor said: From this perspective, H3 NEXT images should now get a support status. Should they? Shell we merge forums into one? Its yet another decision to make? Should I just do it or shell we spent "long hours on meetings"? IMO, merge it. Waiting until everyone is fine will be a 'never ending story'. Fact is, more and more 'normal support' questions came up in the 'development' area, people 'learn' that it is OK to ask questions and now it's somehow common. The only reason I see for waiting is if you're not overloaded with other work and you don't want more stress when a load of newbies start to find bugs (or things they think it is a bug.. ). Btw. there's some rumor that CSI for H3 in on the way for mainline (seem's to be not much difference in V3s and H3 for it). So, more or less every hardware feature of the H3 is supported by mainline and we could start to talk about drop/freeze support for the BSP kernel for H3. If someone is interested in hardware accelerated video decoding contribute and bring Cedrus up and running, otherwise live with a freezed armbian and in case you're interested in 'Multimedia/Kodi' Libreelec/Openelec/H3droid might be something you should consider... btw. @TonyMac32s annotation threads is something I really appreciate! It shows 'the next tasks' for a board/SoC people see what his focus is. Does it help that people contribute if you do this public? Or is it more 'people wait and stress you until you're ready'?
TonyMac32 Posted January 29, 2018 Posted January 29, 2018 6 minutes ago, chwe said: It shows 'the next tasks' for a board/SoC people see what his focus is. Does it help that people contribute if you do this public? Or is it more 'people wait and stress you until you're ready'? I started doing that for a few reasons, one was professionally we always had a status cover sheet for project activity, a summary of activities todo and complete and a "gate review" scoring project maturity from 0 to 100% based on key requirements (automotive stuff, so customer approval, validation testing, IMDS, PPAP, etc) The other reason I took to doing this way was being a noob in the world of phone ROM flashing, the threads I always liked the most kept a running status in the OP with the latest links. Otherwise you have to search around for something that's been referred to 100 million times so text search is terrible, only to find the project dies a year ago and people have just been asking questions every 3 days since then, mostly to cry about it not working out. I think it's helpful more than not for a few reasons, one is keeping myself organized, the other is, a new user will hopefully look at the OP, then a lot of questions can be avoided. If they don't and ask a "dumb" question, I can simply point them at the OP. I have had a few people provide help. Botfap with the HDMI hotplug that I think is relevant to any 4.x kernel HDMI situation, I've gotten some feedback now and then mentioning that things needed it, etc. And some people do just leave well enough alone until something is said, like with audio, I got a question every few months about it, with the post there has been some typical and positive interaction.
zador.blood.stained Posted January 29, 2018 Posted January 29, 2018 12 hours ago, Igor said: Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? I think it's rather simple: - if the board satisfies the "to be supported" criteria (enough samples, no serious design flaws, good BSP or based on already supported platform) then it gets the WIP status, - if the board was added by a community contributor, if there is no interest in making stable/supported releases then it gets the CSC status, - anything else gets the WIP status that can be later changes to CSC. 12 hours ago, Igor said: From this perspective, H3 NEXT images should now get a support status. Should they? IMO not yet, unfortunately, due to DVFS/THS and display drivers pending rework. 12 hours ago, Igor said: Shell we merge forums into one? IMO no since we will be supporting 2 fundamentally different branches, they need to be split, but H2/H3 mainline can be moved from development to the tech support section. 10 hours ago, Tido said: You don't have to follow and answer everything - be picky - every user of the forum can decide whether or not to answer to some post or not. Exactly. Let people with not so smart or already (many times) answered questions do their homework and find the "Search" button and the "Getting started" section.
zador.blood.stained Posted January 29, 2018 Posted January 29, 2018 19 hours ago, Igor said: - [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Mainline u-boot and kernel (and some other projects) have "MAINTAINERS" files (example) to track who is responsible for specific files and directories in the repository and so who should ACK or NAK any changes that are about to be merged there, so we could have something similar - at least GitHub name + file/dir path + status and a list of things that can be added without unneeded discussions (i.e. activate kernel config options related to third party hardware support, make a repository-wide refactoring/rework which involves adding/renaming/removing variables, etc.).
chwe Posted February 1, 2018 Author Posted February 1, 2018 I try to sum up this discussion: There's a mismatch between community interest and developers interest (comparison with DL statistics). Developers are more interested in niche products (mostly more expensive, often only a few boards at hand for active development) User expectations (mostly multimedia) can't be achieved Website is under development and should help to get a step in the direction to explain what armbian is & help to make it more 'beginners friendly' There is some frustration on devs side about user expectation and contribution to the project @zador.blood.stained definiton of WIP and CSC seems to be fine. A definition for WIP --> Supported is missing (or I missed it.. ) 4. seems to be the most important point. Update bricks SBC (software side), users are frustrated and Devs are even more frustrated cause no contribution but a lot expectations. So how can we get rid of this situation. Questions I have: Can we roll out updates 'board for board'? Somehow a more conservative update approach. Means standard Armbian is on 'stable branch' and there is a 'tester branch' (not kernel depended). As soon as a update is planed there's a call for testers thread where a dev explain what changed and people who want to contribute as testers can change to the 'testers branch' testing the basic functions of the update (does it boot, does *random features* still work etc.). The user reports via script which basic functions he tested (e.g. Boot y/N, USB, HDMI, thermal etc.) and if they work or not (I think this is better to collect the information than to do it via forum). Enough response means the board gets the update, not enough response means freezed until someone does the tests needed. This should decrease the number of boards/board-kernel combinations where nobody is interested to contribute. I don't know how much effort it needs to implement something like this so comments on this idea are welcome Contribution proposals: A Dev describes something which does not work anymore or which be implemented in Armbian but he has no time/interest in doing it. Describing the Idea behind, the goals and when known, where to start (this can be documentation, part of armbian, part of the buildscript etc.). People which are interested can pick up such a project, start to working on it and get some guidance from the dev or community. I think in the beginning this needs more time that the contribution is worth but it increases the people contribute to Armbian. Hopefully some of them contribute then for a longer time on various parts of Armbian cause they start to understand more and more the project.
zador.blood.stained Posted February 1, 2018 Posted February 1, 2018 21 minutes ago, chwe said: There is some frustration on devs side about user expectation and contribution to the project For me frustration comes from this: - legacy / backwards compatibility that prevents making advancements or fixes - trying to make "one fits all use cases out of the box" images - too much stuff to maintain - lack of communication/understanding of some issues, i.e regarding base firmware package contents (example of the results) Wrong user expectations come from existing problems - web pages contents, extra (IMO excessive) branding, overall project positioning 1
Tido Posted February 1, 2018 Posted February 1, 2018 1 hour ago, chwe said: Describing the Idea behind, the goals and when known, where to start (this can be documentation, part of armbian, part of the buildscript etc.). People which are interested can pick up such a project, start to working on it and get some guidance from the dev or community. I like that, @Igor would it be a good idea to have a section in the forum 'low hanging fruits' for everybody who likes to contribute ? 1 hour ago, chwe said: Armbian is on 'stable branch' I have a dream :-) this idea is quite old - and somewhere in the forum @zador.blood.stained or @Igor explained why it doesn't work with our rolling release. 53 minutes ago, zador.blood.stained said: legacy / backwards compatibility I guess you would have to have a discussion on Skype or such between the Devs to define a new way forward..
TonyMac32 Posted February 2, 2018 Posted February 2, 2018 5 hours ago, chwe said: Means standard Armbian is on 'stable branch' and there is a 'tester branch' (not kernel depended) I like this, but it does mean something like multiple branches being used. Then people who use the build system can use the stable branch without being (too) worried. 5 hours ago, zador.blood.stained said: trying to make "one fits all use cases out of the box" images - too much stuff to maintain This is possibly a law of nature: "Jack of all trades, master of none" 4 hours ago, Tido said: would it be a good idea to have a section in the forum 'low hanging fruits' for everybody who likes to contribute ? I've been asking for feedback for 3 (4?) days on the Rockchip kernel for Tinker, have even now provided a kernel package for download, and nothing. It doesn't get a lot lower hanging than that for the even mildly interested, 200 views, no downloads to date. (I think you've found my frustration)
Igor Posted February 2, 2018 Posted February 2, 2018 3 hours ago, TonyMac32 said: This is possibly a law of nature: "Jack of all trades, master of none" One of the major goals of the project is to achieve universality among big diversity. Which is good. Now, moving more toward IOT use case would be the way to go. IMO a desktop is good enough and doesn't need more attention. At least not from a primary team. If there are folks, who have the intention to tune this up, perhaps even fix some web acceleration within Chromium ... welcome to play around and fix that overbranding mentioned by @zador.blood.stained Perhaps I really went too far with it. 3 hours ago, TonyMac32 said: I've been asking for feedback for 3 (4?) days on the Rockchip kernel for Tinker, People are simply spoiled. The same case is with our "testing group" - only the first time there went through good enough, next time(s) I rather test all images on my own. This is now a serious multi-day task and it's not possible to test all. What happened if testing is not well organized? A lot of time is wasted, critical might completely slip through, frustration and anger build up. Also on the user's side, on those who ware too lazy to help to test. Frustration is usually a good motivator and we should make use of it. How? Be ready to aggressively recruit when releasing an update. Again, this we are a problem - who will take this HR like responsibility? If this is taken over by me or other individual who have not much clue what to do, just more frustration is building up on our side. 3 hours ago, TonyMac32 said: Means standard Armbian is on 'stable branch' and there is a 'tester branch' (not kernel depended) This way only some problems are discovered. We already have a beta branch which shows us what is going on with a trunk. There are people who are using this and some do report when things broke. Perhaps more systematical approach on the infrastructure which is already there? In any case, we will not find all problems on all boards this way. 8 hours ago, Tido said: People which are interested can pick up such a project, start to working on it and get some guidance from the dev or community. The idea is marvelous, just how to get it up and rolling? I think we need a moderator/project manager for this section, something like @chwe is doing in this thread. Someone who transforms our ideas and babble into tasks? We are already under heavy load, I tend to be lazy when things jump outside of a primary goal and pessimistic that someone will just take and resolve some task. On 29. 1. 2018 at 5:16 PM, zador.blood.stained said: Mainline u-boot and kernel (and some other projects) have "MAINTAINERS" files Let's simply reuse this term and - at the new web - expose this as a non-technical necessity "maintainer wanted" to move from WIP to supported section. On a related issue - yesterday, I received a question from @ebin-deb why we don't move Espressobin among stable and I point him here. Well, there are also some minor technical issues to be solved, but in a technical sense, it is ready.
chwe Posted February 3, 2018 Author Posted February 3, 2018 On 2.2.2018 at 7:27 AM, Igor said: The idea is marvelous, just how to get it up and rolling? I think we need a moderator/project manager for this section, something like @chwe is doing in this thread. Someone who transforms our ideas and babble into tasks? We are already under heavy load, I tend to be lazy when things jump outside of a primary goal and pessimistic that someone will just take and resolve some task. Let's try it with an example and lock what happens/if it works... Such a 'project manager' needs a background in the topic otherwise it's similar to marketing monkey writes product description for *random device*. I suggest we take @zador.blood.stained proposal as a test: On 27.1.2018 at 10:53 AM, zador.blood.stained said: On 27.1.2018 at 2:51 AM, TonyMac32 said: As @chwe properly summarized, I think a template for board support would be handy. Not that it was terribly hard to figure out, but I made a few mistakes along the way anyhow... Perhaps a kernel config including all the "Armbian-generic" options per kernel (yes, crappy to do with a ton of kernels. Probably start with mainline and work backward) Unfortunately AFAIK there is no good way for merging/splitting/comparing kernel configs for different kernel versions. We can start by making a list of options and menus that should be enabled or disabled. Is it possible to write a proposal what should be done out of it? On 2.2.2018 at 7:27 AM, Igor said: On 2.2.2018 at 3:34 AM, TonyMac32 said: Means standard Armbian is on 'stable branch' and there is a 'tester branch' (not kernel depended) This way only some problems are discovered. We already have a beta branch which shows us what is going on with a trunk. There are people who are using this and some do report when things broke. Perhaps more systematical approach on the infrastructure which is already there? In any case, we will not find all problems on all boards this way. On 2.2.2018 at 7:27 AM, Igor said: People are simply spoiled. The same case is with our "testing group" - only the first time there went through good enough, next time(s) I rather test all images on my own. This is now a serious multi-day task and it's not possible to test all. IMHO, it can't be a goal that you have to test all images on your own, otherwise armbian has to reduce the supported boards to much less boards. If you look into DL statistic, there are enough people downloading our images, there must be some interest from the community to report bugs (update or fresh download). Can we start with a 'testgroup lite'? IMHO most important (cause most annoying) is to avoid that the device is not bootable after update. As long as you have SSH access via ETH to the device, broken things can be fixed or at least, a backup of the data can made (I agree you should backup your system before the update - but to be honest, we have to accept that people don't do it). To avoid flooding the forum with a lot of junk from the testers group a small webservice might help: Quote Does the device boot after update? Y/N Paste sudo Armbianmonitor -u here /provide the bootlog from serial output (in case, it doesn't boot) Describe shortly errors you saw after update. With a clear statement that we don't suggest that you're test without having a serial console at hand (seems that a lot of user don't think it is necessary to have a usb serial device at home when playing with SBCs - maybe we should 'educate' our 'customers' also in this field.... ). Is it possible to have a 'board specific' update mechanism? E.g apt-update/upgrade only updates kernel/u-boot only if it's somehow on a 'positive list'? On 2.2.2018 at 7:27 AM, Igor said: One of the major goals of the project is to achieve universality among big diversity. Which is good. Now, moving more toward IOT use case would be the way to go. Internet of shitty Things is the 'new' buzzword... Since people like @Larry Bank and @sgjava strongly push the GPIO issue, we might have a good solution in 2018. To avoid more load for the maintainers and keep Armbian as general as possible, I suggest to solve it similar to the OMV project. Means that we can provide a post installation script for a 'ArmbianIoT' but IMO we should avoid providing it in 'standard Armbian'. A few questions: Do we have a nightly desktop policy? Why do we provide desktop in nightly images? Does it make sense to provide such images as long as we can't provide 'basic stability'? 2
sgjava Posted February 3, 2018 Posted February 3, 2018 sysfs is not a good solution with all the context switching, losing events, etc. I've already switched to libgpiod (see https://github.com/sgjava/libgpiod-extra). It wouldn't be difficult to add Larry's concept of a common pin mapping since that's just done with pin arrays (at the C level, so the wrappers just need to be generated for Python and Java). I just added I2C support and SPI support is coming. This will be the user space way to do things on Linux, so it will not be just for Armbian. There are other things missing like PWM, but the big three (GPIO, I2C and SPI) will be implemented. Any ways, this is all scripted already, so I'm not sure I'd include it in Armbian. Plus I'm moving at a rapid pace, so it's best to pull from master to get the latest changes/fixes.
TonyMac32 Posted February 4, 2018 Posted February 4, 2018 7 hours ago, sgjava said: sysfs is not a good solution with all the context switching, losing events, etc. accidental mis-post? Probably intended for the GPIO/IOT discussion? If so, and a mod moves it, delete my post about it as well.
TonyMac32 Posted February 4, 2018 Posted February 4, 2018 Ah ok, it seemed somewhat tangential to the topic at hand. You switched fairly recently then, I hadn't been keeping up. By the way, I tested it on Le Potato, quite simple, nice to use. Given the lack of time and the... non-descriptive commit history, where are you grabbing the GPIO names? The device tree for the mainline amlogic devices has every exposed gpio named in the tree, but that doesn't come through using gpioinfo.
chwe Posted February 18, 2018 Author Posted February 18, 2018 H6 and RK3399 boards with 'interesting features' will arrive soon (or are still there as @tkaiser shows in his 'not a review - review' ). I expect that those boards will generate a lot of new issues (mPCI/PCI allows to connect a bunch of new hardware, GPU and VPU are powerful enough for some fancy stuff - and also more kodi-like stuff). It might be a good time to do some 'house keeping' (before all those boards and their customers arrive). Can we summarize all open issues and actions which are needed to fix them? I see all your rolling eyes cause we don't know the issues before they appear ... A20: - - - H3: - CSI (camera) doesn't work on mainline, gc2035 needs an small script in legacy to start up properly - Armlogic: - - Freescale: - - Rockchip (I suggest only the one we support at the moment, not RK3399): - CSI (tinkerboard, rk3288) is supported (RK 4.4 bsp kernel) by kernel (OV6547 OV5640, imx219 - RPI-cam V1.3 resp. V2) but doesn't show up properly when booting) - Marvell ARMADA: - - Armbian related scripts: - h3consumption is legacy only - I suggest that everyone interested can quote this 'table' and fill it with issues.
TonyMac32 Posted February 18, 2018 Posted February 18, 2018 A20: @Igor - legacy kernels should go out due too overall bad kernel quality - reboot/poweroff problems on some boards H3: @chwe - CSI (camera) doesn't work on mainline, gc2035 needs an small script in legacy to start up properly - Armlogic: @TonyMac32 - Mainline support effort is still relatively new. Things like USB, audio, etc are WIP. - "Legacy" kernel that is stable is old and EOL (3.14) and I haven't fooled with it. In that world and all others Amlogic, @balbes150 is the master. - Newer legacy kernel is still a work in progress (4.9 w/bugs) - u-boot blobs are lame and make using mainline u-boot difficult (need both legacy 2015 and mainline u-boot to get a working image) - Lower quality of open source information, all more or less community driven by a very small group, unlike with say Rockchip with a large amount of published info from Rockchip themselves. Rumor/commits say this may change with newer IoT processors. Freescale: @Igor - the legacy kernel is getting obsolete. No point to have it. - possible to implement hw video acceleration on mainline kernel - Solidrun has new 4.9 kernel, but can be safely ditched for mainline Rockchip (I suggest only the one we support at the moment, not RK3399): @chwe - CSI (tinkerboard, rk3288) is supported (RK 4.4 bsp kernel) by kernel (OV6547 OV5640, imx219 - RPI-cam V1.3 resp. V2) but doesn't show up properly when booting) @TonyMac32 - Igor and tkaiser are already seeing this, but mkimage/uboot/trust can be finicky. luckily that's a "figure it out and move on" situation, but it is likely to cause headaches. - 4.4 kernel is an increasingly old kernel, now 2 LTS's in the past, however still much better than a lot of others (also has a lot of activity) - RKwifi is something I don't know the reason for. I don't know why it exists, I don't know what it does (other than cause problems). It is a wrapper for some wifi drivers/an rfkill system - Rockchip likes to use their own subsystems in many things, like the "MPP" system for media playing. This has different capabilities per SoC, so may not behave predictably to simply be able to say we know how to use it. Marvell ARMADA: @Igor - missing SFP support in mainline Armbian related scripts: @chwe - h3consumption is legacy only - 1
TonyMac32 Posted February 18, 2018 Posted February 18, 2018 A major bonus with these new H6/RK3399 boards is that we shouldn't have to worry about micro-usb. if you want the "cool stuff" you need 12V.
Recommended Posts