Jump to content

Banana Pi Zero


CliffB

Recommended Posts

4 hours ago, chwe said:

 

9 hours ago, tkaiser said:

Well, what's the use case? I've to admit that I really like H2+ since this SoC allowed for some really inexpensive SBC with dedicated Fast or even Gigabit Ethernet and 4 real USB2 ports that do not have to share bandwidth (Orange Pi Zero, NanoPi Duo). But this board is just crippled and everything I would need is not exposed

Maybe not for your use cases but for others. Not everyone has the same needs...

 

 

I'm well aware of this and as already said IF SINOVOIP WOULD START TO PROVIDE CORRECT HARDWARE DESCRIPTIONS BPi M2 Zero would've been long added as .csc (community supported board variant) so it's at least ensured that hardware settings match so other projects relying on Armbian's build system or using same legacy kernel can easily add support for BPi M2 Zero to their projects (those others are for example H3Droid, RetrOrangePi, Lakka and @jernej's community OpenELEC distro).

 

It would have already happened if the company in question would start to provide correct and not all the time missing or even wrong information.

 

That was talking about most basic support, just describing the hardware so it's useable with legacy kernel (the 3.4 that is unsupported since more than half a year since EOL in April 2017) in a good way. Impossible with SinoVoip since they do not provide the needed information (voltage regulation, if this thing can't switch to 1.1V it will permanently overheat). As soon as this is fixed it's throwing in 2 files into the build system and perfectly working OS images can fall out of it, then @lvmc would already be happy since he doesn't need community, friendlyness and the other stuff but just working OS images for his commercial use cases. Fair enough but not related to 'Armbian support', he and we are missing vendor support.

 

'Full Armbian' support would mean we actively try to support this device. Armbian wants to move away from legacy kernel so all you have with mainline kernel is then a H2+ device lacking 3 USB ports with a problematic Wi-Fi implementation (AP6212A though referenced as AP6212 by the vendor -- do you start to understand why dealing with them sucks?), only one USB OTG port, no working camera and tinkerers encouraged to solder a MagJack wrongly then then flooding our forum about Ethernet problems.

 

Adding to this: false/misleading advertising. Buyers believe M2 Zero would be compatible to RPi cameras (not true at all) and to RPi software (not true at all). And these people will later end up here in the forum (since they'll realize pretty fast that SinoVoip doesn't support SinoVoip hardware) and complain about incompatibilities. That's the other reason official Armbian support is highly questionable.

 

And may I remind you that all the work done on Armbian is done by volunteers even if the liar who called me already an asshole constantly spreads I would be paid by Xunlong. Seriously: why dealing with this stuff?

Link to comment
Share on other sites

9 hours ago, lvmc said:

They are using miss information as a business strategy over competition

Are you serious?
I can understand your argument in that regard like: our BPi Zero consumes half as much power as the RPi Zero while it does run 4 threads even 10times faster.

 

BUT,  by making it hard to develop it for, because of missing device information  ==  business strategie.
I hope you are good at coding, I wouldn't trust you for my business strategie.

 

Well, described by Mr. TK. (just above this one)

Last but not least, BPi has for more than one (1) year a gitbook - basically the step in the right direction has already been done one year ago. Why @Lion Wang and @Nora Lee - do not make it a standard before going public to have the gitbook up-to-date ... I simply do no understand.

Having a meeting with the developers, say 30min. Walk through the gitbook - identify missing information - add the task where necessary.  30min later, fixed and a great powerful new product launch - which impresses the whole armbian community.  So simply I would do that.

Edited by Tido
TK was fast, one post above the one above :)
Link to comment
Share on other sites

35 minutes ago, tkaiser said:

And these people will later end up here in the forum (since they'll realize pretty fast that SinoVoip doesn't support SinoVoip hardware)

 

See also https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=42914

 

This is what happens if Armbian starts to officially support a device. We as volunteers explain in our spare time to Banana Pi customers why/how their hardware is flawed and how to workaround these hardware issues. And at the same time the responsible company repeats the same 'design decisions' just to trick their customers into believing RPi compatibility so that will continue over and over again. Only solution: raise awareness about hardware and company issues (the guy plagued by ignorance only recognizes as 'tkaiser attacking us').

 

And now let's stop. Working on these SBCs should be fun if one is not paid (as it applies to all of us devs here). And with SinoVoip it's NO FUN AT ALL.

 

Link to comment
Share on other sites

14 minutes ago, tkaiser said:

 

See also https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=42914

 

This is what happens if Armbian starts to officially support a device. We as volunteers explain in our spare time to Banana Pi customers why/how their hardware is flawed and how to workaround these hardware issues. And at the same time the responsible company repeats the same 'design decisions' just to trick their customers into believing RPi compatibility so that will continue over and over again. Only solution: raise awareness about hardware and company issues (the guy plagued by ignorance only recognizes as 'tkaiser attacking us').

 

And now let's stop. Working on these SBCs should be fun if one is not paid (as it applies to all of us devs here). And with SinoVoip it's NO FUN AT ALL.

 

 

orange pi is a perfect product ??, not any defect ??? they have complete product information service??? and write all right doucments??? 

 

Why didn't you attack them???, why ,why .............What makes you lose basic justice??? And then you understand why I ignore you.  You even send email to our customers to let our customers choose orange PI.

 

 

Link to comment
Share on other sites

3 minutes ago, Lion Wang said:

orange pi is a perfect product ??, not any defect ??? they have complete product information service??? and write all right doucments??? 

 

Why didn't you attack them???, why ,why .............What makes you lose basic justice??? And then you understand why I ignore you.  You even send email to our customers to let our customers choose orange PI.

 

Thank you for confirming (and spreading more lies). I said it multiple times and hopefully I'll really learn the lesson now and start to ignore everything with BPi in its name: dealing with stupidity/ignorance is too annoying to further waste my spare time on it.

Link to comment
Share on other sites

46 minutes ago, Tido said:

Last but not least, BPi has for more than one (1) year a gitbook - basically the step in the right direction has already been done one year ago. Why @Lion Wang and @Nora Lee - do not make it a standard before going public to have the gitbook up-to-date ... I simply do no understand.

Having a meeting with the developers, say 30min. Walk through the gitbook - identify missing information - add the task where necessary.  30min later, fixed and a great powerful new product launch - which impresses the whole armbian community.  So simply I would do that.

 

 

@Lion Wang SinoVoip's gitbooks has to be reviewed. Technical information is not consistent and English is not good enough, it has to be fixed urgently. Over the last years I have been seeing many Chinese companies doing good products or at least pursuing to build good products but failing on how to communicate and support customers, think about it. Never forget that customers don't care about how hard is to build a new product or how insane is to run a business, they only care about how good the product is.

 

@Tido gave a good suggestion... before releasing any new product and during the entire product lifespan do short technical / writing meetings with your technical team to consolidate knowledge.

 

The entire problem here seems to be about communication, as always. Most of Chinese companies have good engineers that doesn't even speak or write in English. If it is the case, hire someone that could help you to fulfil this gap, as soon as possible.

 

@TonyMac32, @chwe thank you for focusing on the real problems, not at person level discussions. In just a few questions I think you got the answers you were looking for. That is a good start point.

 

@tkaiser I would like to suggest you to just 'stop' buddy, please.

 

Let's give the last chance to SinoVoip understand, change, react and SOLVE the main issues. Everything said here is applicable for any hardware supplier.

Link to comment
Share on other sites

9 minutes ago, lvmc said:

@tkaiser I would like to suggest you to just 'stop' buddy, please.

 

No worries, already followed your suggestion :)

 

You obviously haven't realized or read what I've written above (how easy it is to add support for this device). I had vendor fex and the optimized Armbian version as well as bananapim2zero.csc open in my editor since weeks just waiting for the company solving the mystery around voltage regulation (which for whatever reasons they aren't willing to do). I even added the gmac node correctly to 'our' fex file an hour ago but closed all 3 documents without saving now.

 

How this thread went finally could convince me to just 'stop'.

Link to comment
Share on other sites

3 minutes ago, @lex said:

+1

 

Zero not add eMMC onboard ,just BPI-M2+ can support eMMC ,also support H2+ chip .   if we add eMMC onboard ,cost will higher.:0

 

for allwinner H2+ and H3 chip PIN to PIN compatibility , so BPI-M2+ Zero also can use H3 chip onboard

 

 

BPI-M2 Zero H3 2.jpg

Link to comment
Share on other sites

3 hours ago, Lion Wang said:

orange pi is a perfect product ??, not any defect ??? they have complete product information service??? and write all right doucments??? 

 

I think nobody has a complete "perfect" product....neither "Orange Pi" nor "Banana Pi" nor "Nano Pi" nor "Raspberry Pi".

Every product has some details that could be better (lower heat, better documentation, better linux-images, better cases, less binary blobs).
So I got some of every sort :)
But - I personally - like the wiki from FriendlyElec/FriendlyARM at
http://wiki.friendlyarm.com/wiki/index.php/Main_Page

Most - NOT ALL - pages does include very interesting and valuable informations for me (PinOuts and HowTos, FAQ).

OK some should be more actual - but there are many pages for many diffrent models and if ne page hasnt the information then I could find mostly the information at a page of a other model. 

 

The downside - their forum seems mostly supported from users to users. No technican seem to take a look here on a daily basis :(

Link to comment
Share on other sites

@guidol thank you so much for sharing your thoughts, experience and pointing a direction. @Lion Wang that is the kind of feedback you MUST read, understand, SHARE with your team and act to solve the pains.

 

+1 for eMMC, a 8GB class-10 sdcard costs ~6.5USD nowdays. How much it is 8GB eMMC?

Link to comment
Share on other sites

11 minutes ago, lvmc said:

+1 for eMMC, a 8GB class-10 sdcard costs ~6.5USD nowdays. How much it is 8GB eMMC?

As price idea: 
A H3 NanoPi Neo does cost $7,99 (256MB version) plus $2 if 512MB Ram =$9,99

A H3 NanoPi Neo Air does cost $19,99 and has WiFi (no ethernet) but also has 8GB eMMC
A H3 NanoPi Neo Air with 32GB eMMC does cost $35 (+ $15,01 on top to the normal NanoPi Neo Air).

So for the 8GB a bit more than a uSD of 8GB, but for me thats OK, because eMMC should be faster and has to be soldered by the company

Link to comment
Share on other sites

50 minutes ago, guidol said:

because eMMC should be faster

 

LOL. BPi in the meantime uses 8GB KLM8G1WEMB-B031 modules (search the web, check the specifications, do a test, realize that it's really just 6.5MB/s write). FriendlyELEC uses minimally faster eMMC (7.5 MB/s write) and on inexpensive boards only Xunlong in the past used really fast eMMC (even on the 8GB models we were talking about 40/80 MB/s write/read). But this has changed in the meantime, now Xunlong at least on the Orange Pi Plus also uses the same slow EOL eMMC FriendlyELEC uses already all the time.

Link to comment
Share on other sites

10 minutes ago, tkaiser said:

LOL. 

then it would be better like on the NanoPi Duo with PCIe-SSD....booting from uSD and using / root on the PCIe:

https://www.cnx-software.com/2017/10/30/nanopi-duo-quick-start-guide-ubuntu-breadboard-mini-shield-msata-ssd/#nanopi-duo-with-mini-shield-and-ssd

 

Its a shame for the eMMC (also if they could read up to 130MB/sec)

Link to comment
Share on other sites

22 minutes ago, guidol said:

then it would be better like on the NanoPi Duo with PCIe-SSD....booting from uSD and using / root on the PCIe:

That's not PCIe, this is just USB2-to-SATA but of course capable of exceeding 'Class-10' speed requirements (mentioned earlier by @lvmc -- I just wanted to warn all those people who believe for whatever reasons eMMC would always be superiour since on many SBC the eMMC is just 'Class-6' and sometimes 'Class-8' so good luck if you want to write for example a video stream with 7MB/s since you will fail! BTW: Adding USB-to-SATA is easy on boards that expose their USB ports.

 

22 minutes ago, guidol said:

Its a shame for the eMMC (also if they could read up to 130MB/sec)

 

Well, eMMC even if showing such low sequential write performance might be faster than most SD cards if it's about random IO (though when choosing a good SD card like EVO/EVO+ this is not necessarily true) but it's important to keep in mind that what we get on BPi boards is not even compliant to SD card associations 'Class-8' speed class. But given how flash memory prices still rise such low-end eMMC will spread most probably more and more (see Xunlong example above, latest OPi Plus revision only 12.5 MB/s and not 40 MB/s any more)

Link to comment
Share on other sites

Right, my comment on eMMC is purely about reducing/removing interconnects, the primary failure point in most systems.  Speed is secondary in such embedded systems.  I would ideally use the SD card only for data storage, for instance data logging/etc.  

Link to comment
Share on other sites

7 hours ago, lvmc said:

Let's give the last chance to SinoVoip understand, change, react and SOLVE the main issues. Everything said here is applicable for any hardware supplier.

It's not about last chance, I think you missed a key point there.  Support for a new board is mostly a question of time and knowledge of an experienced developer taking care of a SBC.  When you've a look which BPi boards are supported with a 'stable' armbian. You could see that there are a few of there boards:

  • BPi M2+ (H3)
  • BPi M2 (A31s)

  • BPi Pro (A20, actually a lemaker, not SinoVoip product, correct me if I'm wrong here...)

  • BPi + (I think this is called M1+ by SinoVoip, also a A20)

  • BPi (should be the one called M1 by SinoVoip, A20)

 

IMO, the reason why you see so much more OPi boards supported by Armbian is the following: They have a real conservative 'board design philosophy' - more or less every board from xunlong is based on H2+/H3 which as Thomas said, makes it easy to add support (as long as you've correct schematics, or as xunlong does it 'never change a winning team' - you know one, you know most OPIs :P ).  SinoVoips approach to invent '20 different wheels for 15 use cases' (means having a bunch of different SoCs on their SBCs,  and therefore many different board designs make it harder to support their boards).  

 

I bought a BPi Zero (and paid the full price :P ) and I'm sure that I'll have a dedicated armbian running on it (I think I'm able to adjust the basic things I need to get my needs running if nobody from the 'core developers' are willing to do it) but I'm not able and passionate enough to be a 'maintainer' like @TonyMac32 for the tinkerboard (actually a board which has also a lot of design flaws :D ). Means I'll not spend much time on things I'm not interested in and I don't feel responsible to answer every question about it on the armbian forum.  Naming your images Raspian (something Xunlong and SinoVoip do) is IMO false advertising. First their boards are not RPIs. Second, Raspian is built on a (more or less) recent kernel (at least 4.x). Third, GPIO libraries  are working out of the box (which is often not true for these boards) and last, things like mathematica,  Node-Red & Wolfram Alpha works also out of the box (I never checked all these things on the OPis or BPis Raspians, but for the kernel it's sure - most OPis running the outdated 3.4.39 kernel BPi0 improved here slightly with a 3.4.113 kernel). Both companies don't shine on software support (but Xunglongs 'conservative design strategy' makes it easier to support their boards), so improvement there would be really appreciated. :)

 

Annotation: this part of my post has some sort of humor, sarcasm & frustration in it, if you can't deal with it, just don't read it. :D 

A basic 'board bring up' for an H2+/H3 board (as repeated a way to often in this thread :P ) is not a huge deal. But maintaining the community support clearly is (just have a look here how many questions come up for *random SBC*). More or less every week a thread 'why wifi on OPi0 does not work?' (shitty XR819 just use search engine) or 'why armbian does not support RPi display on tinkerboard?' (armbian is not the board maker, this is a spare time 'job' we don't have time to do everything in minutes,  btw. congrats to @tonymac32, you got it work! I think we're now close to ASUS advertised RPi compatibility with the tinker :P).  So, the more boards armbian supports, the more time experienced supporters of armbian are absorbed by answering this questions, testing images etc. (Thomas would say, 'waisting time' :P ).  And what's also clear,  the more a board is claimed to be raspberry compatible, the more 'inexperienced users' joining armbian (best example Tinkerboard).  This might avoid someone like Thomas being excited adding support for such a board cause he knows the consequences - more 'inexperienced users' (sometimes too ignorant following basic instructions from an experienced armbian supporter -  see here for some examples), expecting that everything on armbian should work similar than on raspian cause boardmaker claimed RPi compatibility and armbian is based on debian. So, 'no difference to *random RPi*'  (except, it has to be cheaper than a RPi and I want 'real SATA' on my board).:lol:  That's why I still like the RPi - more or less everything they advertise works on their boards. It's not the most powerful board (you get more powerful & cheaper SBCs on an H2+/H3 basis) but most things the *average SBC user* can imagine is solved by someone from the RPi world and they've targeted the 'noob problems' (it's a shame that they still use the micro USB connector for the RPi3 but nevertheless they have a 'protection mechanism' to avoid underpowering the board - one major issue on cheap H2+/H3 boards here at armbian). 

I hope you see the point in all this *random BS I talk here*

  • Board bring up would be easy
  • Support needs a lot of time
  • more *average RPi users* means more ignorant users (not all of them, but part of them are)
  • the more a bord is claimed to be 'RPi compatible' the more *average RPi users* will show up here - the more time is needed to explain to them that verdor claimed RPi compatibility doesn't mean that this is true nor armbians major goal is to be 'RPi compatible'

 

3 hours ago, tkaiser said:

Xunlong in the past used really fast eMMC (even on the 8GB models we were talking about 40/80 MB/s write/read). But this has changed in the meantime, now Xunlong at least on the Orange Pi Plus also uses the same slow EOL eMMC FriendlyELEC uses already all the time.

Seems that they run out of their 'good eMMC' chips. :P  (maybe I should sell my 'old' OPi Pc+ on ebay, advertising that it is a 'fast one'  :lol:). 

 

3 hours ago, guidol said:

then it would be better like on the NanoPi Duo with PCIe-SSD....booting from uSD and using / root on the PCIe:

IMHO no! The only reason using NanoPi Duos 'motherboard' is during product development to get 'all features' easily accessible. If you still use it 'on production scale' of your project, just go for an *random H2+/H3 SBC* which deploys this features without a 'motherboard'. The main benefit of those SBCs is their size with a drawback that not everything is deployed on the board (this could also be a benefit if you don't want to have things deployed on the place the boardmaker deploys it, e.g. ETH is deployed 'on the false edge' for your project). But this is clearly a personal opinion.... :P 

 

11 hours ago, TonyMac32 said:

If you are open to a feedback, I would say a good variant would be one of these without wifi, but instead with the additional USB's available via header, a position for a barrel jack or direct-solder power input, and an eMMC.

@Lion Wang - take care of this sort of feedback. At the moment, your BPi zero is a 'quad-core rip off' of the RPi 0 for a higher price than the original which would make it hard for most SBC customers to buy it instead of the 'original'. The fact that the camera connector is not compatible to RPi makes it even worse for a lot of use cases (you'll find a generic RPi compatible camera for ~6$ on aliexpress but a BPi compatible camera is in the range of 20$).  RPis videocore GPU works on recent kernels whereas Mali is 'work in progress' (but to my knowledge, nobody works really on it. :P ).  So, your board needs some 'features' which makes it interesting for people which are annoyed by the RPi0. This could be (personal opinion).

  • eMMC instead of/combined with SD card 
  • ETH on a pinheader (which you have)
  • more than one USB port (maybe also on a pin-header)
  • etc. 
8 hours ago, Lion Wang said:

orange pi is a perfect product ??, not any defect ??? they have complete product information service??? and write all right doucments??? 

 

Why didn't you attack them???, why ,why .............What makes you lose basic justice??? And then you understand why I ignore you.  You even send email to our customers to let our customers choose orange PI.

I said it once and now the second time,  don't bring this discussion to personal level between you and him which will end similar to the 'famous' BPi-R2 thread we had here and @Tido or myself will close it cause it's only about you don't understand why Thomas doesn't like your products and you're claiming that he must work for Xunlong.  This thread is a little bit like a baseball game - a lot of boring, not BPi0 related, stuff (maybe also provided by myself :P ), and some new information we didn't know before (e.g. ETH is accessible through pin-header, 1.1/1.3V cpu regulation is on PL1 instead of PL6, first version of schematics). But as a real American @TonyMac32 can explain to you what happens in baseball after strike two...  (hint:  I'll close the thread maybe only for a 'cool down time' maybe forever cause I don't think we need a second 'BPi-R2 thread' again).  If you felt upset by Thomas and you can't deal with it, ignore him. If you're smart you 'extract' the key concerns he has about your product/company and evaluate if it's worth to improve/adapt it. 

Link to comment
Share on other sites

8 minutes ago, chwe said:

If you felt upset by Thomas and you can't deal with it, ignore him. If you're smart you 'extract' the key concerns he has about your product/company and evaluate if it's worth to improve/adapt it. 

 

Perfect words, nothing else to say.

Link to comment
Share on other sites

Ok, I will arrange the person to spend more time on the document finishing, all the Suggestions are welcome.And I will not respond to any offensive remarks. Any good advice, I will listen, and will correct, I hope to grow with you,We all have our faults, and we all have our own specialties. Hard work doesn't always succeed, it just increases hope

 

about H2, H3, H5 chip design.  we just support BPI-M2+ and BPI-Zero module .

 

BPI-M2+ have H3 chip,1G RAM ,wifi ,gMac, 8G eMMC ,various Interfaces.

 

BPI-M2 Zero with 512 RAM ,wifi,less Interfaces for low cost.

 

This is based on inventory management considerations,  Because of batch production, at least 10K batch, And all tests, the certification costs are too high.  If the customer needs a special specification. We can only offer custom services. 

Link to comment
Share on other sites

5 hours ago, Lion Wang said:

now , 8GB eMMC ,also about 6.5 USD . DRAM , and eMMC , this year ,prices are rising too fast.

if the costs are rising to fast - how about installing a standard-eMMC socket like on the ODROID C2 or inside the Pinebook?
I think this would cost only a few cents?
For me that would be fine - then while I upgraded my Pinebook to 32GB eMMC I could use the old 16Gb eMMC on my ODROID C2

AND if the market will supply faster/bigger eMMC modules I can swap out the slower/smaller against a faster/bigger one :)

Link to comment
Share on other sites

I downloaded your image from your google drive yesterday (btw google drive is an awful storage place when you've to download large files from a console, but this small python tool helps a lot).  I mounted the fat partition and extracted script.bin from /bananapi/bpi-m2z/script.bin. A quick look at it wasn't that exciting.

 

3. line:

machine = "Banana Pi BPI-M2-Plus"

false board name as Thomas said on one of his first posts in this thread (July 30). 

 

183 - 190:

[uart3]
uart_used = 1
uart_port = 3
uart_type = 2
uart_tx = port:PA13<3><1><default><default>
uart_rx = port:PA14<3><1><default><default>
uart_rts = port:PA15<3><1><default><default>
uart_cts = port:PA16<3><1><default><default>

defined as uart_type 2 but rts and cts are defined. 

 

start at line 739:

[dvfs_table]
pmuic_type = 0
pmu_gpio0 = port:PL06<1><1><2><1>
pmu_level0 = 11300
pmu_level1 = 1100
max_freq = 1200000000
min_freq = 240000000
LV_count = 6
LV1_freq = 1200000000
LV1_volt = 1300
LV2_freq = 1008000000
LV2_volt = 1300
LV3_freq = 912000000
LV3_volt = 1100
LV4_freq = 648000000
LV4_volt = 1100
LV5_freq = 480000000
LV5_volt = 1100
LV6_freq = 240000000
LV6_volt = 1100

 

On 6.11.2017 at 11:46 AM, Lion Wang said:

about WOC , BPI-M2 Zero`s CPUX-SET is PL1,  and orange pi ,Nano Pi use PL6.  just GPIO PIN define not same.

The only place where people see that it should be PL01 instead of PL06 is your schematics and armbians forum. 

 

If you still asking yourself why Thomas is attacking constantly your company, this might be a valid reason. Besides playing with SBCs I'm doing in science where we have a peer review process for everything we publish.  As a peer reviewer, I would reject your 'script.bin paper' with a short comment that you should do your homework first before I have a more detailed look at it. 

 

FYI: I didn't check everything in the script.bin and I'll not do it until you showed that things are improving. 

BTW: PL06 is used as USB0-id, I've no clue what happens when this pin goes from high to low (or vice versa) every time the CPU clocks up if you have a USB device connected to this port...  (EDIT: https://www.maximintegrated.com/en/app-notes/index.mvp/id/1822 could be interesting if you use USB as OTG with changing roles... )

Link to comment
Share on other sites

I have to agree with@chwe on this, I am in the automotive industry, not only would I be fired for such documentation of a design, there could be federal charges brought against myself and my company ending with me in jail if incorrect documentation could be linked to a failure or unexpected behaviour. Not to mention losing all OEM business, etc.

It is not such an impossible task to document properly. But attacking anyone who points out factual errors in your paperwork causes animosity and people will refuse to support these products. Trust me, I am no stranger to poor documentation. But at least for the ASUS Tinker Board the problem is missing documentation, not incorrect documentation. Were it incorrect I would have immediately recommended Armbian drop all support for the board, no matter how popular it may be.

Now, as an engineer I am accustomed to dealing with suppliers. In this situation, that is your role. You are a supplier of single board computers to a marketplace. That gives the user (customer) a certain amount of agency over you, the customer can require correct documentation, the customer can provide negative feedback and refuse to use your product. As a supplier it is your duty to provide a product the customer wants. In the single board computer world that is more than a board, it is also the means to use it. Your product cannot simply be defined as a board, your product is a board and a manual. And that manual needs to make it possible to use the board. The manual includes complete and correct schematics, diagrams of all exposed connections, a basic board support package (device tree or equivalent, vendor-specific drivers, uboot if not mainline, etc)

As you have pointed out, most SBC suppliers in this market have flaws. But I have seen none that are outright confrontational and generally unprofessional. Do you think I don't have customers and coworkers just as disagreeable as Thomas is capable of being? Of course I do, many far worse actually. Do I respond the way you do? No, or else I would not have a job. Do I always agree with the magnitude and force of Thomas's quick anger? No. But I certainly understand it. I actually refused to reply several times during this thread because I felt my feedback would be less than professional. However, my reserved tone has apparently caused some confusion which I felt it necessary to clear up.

I want to see a good competition between board makers, and the obvious benefits that come with it. So to that end I want to see you succeed. However, for that to happen you need to also compete in documentation. You have said you will, but be aware I will not engage in any development, privately or for Armbian, until there is some proof of that effort. A big step would be addressing the concerns you have heard here so many times that I'm even tired of reading about them.

[/rant]

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

4 hours ago, lvmc said:

@chwe we are all waiting for the fixes & improvements, quickly.

 

What is going on here?

 

Which fixes and improvements are you talking about? As already said multiple times adding support for this Zero thingie could have happened in less than an hour months ago if the vendor would be willing to fix his most serious issue (the 'don't give a shit about correct information' attitude caused obviously by someone seriously retarded doing the 'technical documentation' job and censoring in their forum. This is nothing new, they know this since ever -- funnily in the meantime this also affects resellers since they also specify this Banana Zero thingie wrong, not even the physical dimensions are advertised correctly)

 

Here at Armbian we have (or had? Has this changed? When and why?) a policy to NOT support Raspberry Pi and that applies to lame Raspberry Pi clones like this one as well: https://forum.armbian.com/topic/483-support-of-raspberry-pi/  -- the reason is obvious: we can neither afford to deal with clueless RPi users nor would it make any sense. With this BPi M2 Zero thingie it would be even worse since BPi M2 Zero is totally incompatible to any Raspberry Pi so why would anyone right in his mind want to deal with fooled customers who thought they bought an RPi compatible clone that is none (explained many times in this thread already).

 

All you could get is a 'community supported config'. I had three files open in my editor since months already (thank you @chwe for reminding me when I started to look into this, it's really already months and not weeks), all that was missing is the 'don't give a shit about correct information' vendor telling us how and in which way they implemented voltage regulation.

 

This here happened one week ago: https://forum.armbian.com/topic/4801-banana-pi-zero/?do=findComment&comment=42458 -- instead of providing the needed information @Lion Wang chose to remain silent. I had PL01 already in Armbian's bananapim2zero.fex variant just waiting that stupidity/ignorance might settle down a bit and the board vendor starts to support his own hardware. But then @lvmc kindly asked me to stop supporting this board and so I deleted bananapim2zero.fex and bananapim2zero.csc.

 

What should happen now? Yes, I wasted my time already dealing with this infamous hardware vendor another time. Yes, you could do your projects already on this hardware if you wouldn't have asked me to throw away the work already done. Yes, Raspberry Pi clones won't be supported officially by Armbian (or otherwise Armbian needs to redefine itself from a volunteer project trying to support a variety of interesting ARM boards in the best way possible to a support project for clueless people -- why and how should this happen? Who wants to pay for this?). What should happen now?

 

@Tido: Can you please check the link to Banana forum here: https://forum.armbian.com/topic/971-quick-review-of-banana-pi-m2/?do=findComment&comment=7596 (that was the thread where users discovered that BPi M2+ only runs with 1.0 and not 1.2 GHz and CPU cores were killed immediately and where you and I explained a lot to @Lion Wang and @Nora Lee how/why they should use better settings (I provided for free but they ignored it as usual). It seems they did not only delete all of my posts but also the whole thread with a lot of interesting insights and knowledge shared. You're moderator over there so can you restore the deleted contents?

 

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines