Jump to content

Banana Pi Zero

CliffB

By CliffB
in Off-topic

 Share

Recommended Posts

Nora Lee

Nora Lee

Posted
Posted (edited)
Quote

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 Monday at 04:58 PM by Tido 

6

 

Welcome developers' advice then we improve BPI gitbook.

Edited by chwe
added quote
guidol

guidol

Posted
Posted
6 hours ago, lvmc said:

There is a very interesting quote on it: "great minds discuss ideas; average minds discuss events; small minds discuss people." [Eleanor Roosevelt]

Its not about people or being personally - but about finding solutions for problems....

So I found these quotes better:

 

Coming together is a beginning; keeping together is progress; working together is success.   [Henry Ford]

or
Let's not forget it's you and me vs. the problem... NOT you vs. me.  [Steve Maraboli]

1
tkaiser

tkaiser

Posted
Posted
17 hours ago, chwe said:

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

 

And it will remain like this since why fixing the hardware description even if told already multiple times: https://github.com/BPI-SINOVOIP/BPI-files/blob/c4bdb2b5d928042c5f592fafd4796f4b9f24e229/others/armbian/build/config/fex/bananapim2zero.fex#L741-L742

 

This (an 'Armbian build' with wrong settings) is the direct result of you trying what @Tido and me tried for more than 2 years now.

tkaiser

tkaiser

Posted
Posted

To stop wasting my and other's time on this boring 'issue' here a final summary:

  • Close to unbelievable but after another 'evil tkaiser attacking us' event today the hardware vendor 'fixed' voltage regulation description. Just to remind you: this file has to be correct in the first place, there's no excuse for such wrong information there, it's simply the hardware vendor describing how the board works. So now that PL01 is used for voltage regulation (now in conflict with another active PL01 entry for s_rsb_sda -- good luck!) only all gmac* entries are still wrong and cooler_table not using the 912 MHz OPP is most probably a great recipe for poor performance when overheating occurs.
  • So in case someone from SinoVoip wants to fix their pseudo Armbian build it would be wise to fix the fex first since afterwards Armbian's h3consumption tool can work without issues (today not due to still wrong fex file)
  • On their Gitbook pages the size of M2 Zero increased by 5mm (now at least this most basic info is correct), most of the other 'information' is still sparse, wrong, missing, bogus. But fortunately the hardware is still too small on their product page and of course soon everywhere around the globe in advertisements and product listings since all resellers use the wrong dimensions they've been provided with back in July.
  • So anyone interested in this board running with the outdated legacy kernel: chances are great that you get a working OS image over at bananapi.org (soon).
  • As a reminder: Armbian follows the policy to not officially support Raspberry Pi boards which of course also applies to deliberately compatible looking but mostly incompatible RPi clones like this M2 Zero here (we don't want to see this forum/community dying when RPi users or fooled M2 Zero customers arrive)
  • Armbian also tries to phase out legacy kernel support (3.4.113 which is not supported any longer since over half a year now). CSI/camera support with mainline kernel is still WiP so when switching from legacy to mainline camera functionality will also be missing. Again no reason to officially support such a device
  • Third 'problem': dishonest advertising. Nowhere is mentioned by the vendor that M2 Zero is totally incompatible to RPi cameras (which is something average buyers expect) and RPi software (which is something clueless buyers expect from something that mimics the look of an RPi Zero and is said to run 'Raspberry Pi image'). There's really no reason for us here wasting our spare time with support efforts like this: https://forum.armbian.com/topic/5579-power-off-with-hdd-over-active-hub/?do=findComment&comment=43088
13 hours ago, guidol said:

Its not about people or being personally - but about finding solutions for problems....

 

Exactly. @Lion Wang's problem is that he wants to sell hardware and his company earned a very negative reputation over the last years (believing this would be caused only by evil people outside and not related to their internal and pretty real problems). That's something where some idiots here at Armbian could help working for him in their spare time and doing his software and support work.

 

@lvmc has the problem that he wants to use this BPi board with his own camera modules. Should work now so let's please stop babbling about community and so on.

 

We have the problem that even if we wanted to support SinoVoip products they don't allow us. They refuse to cooperate, do not provide correct hardware descriptions, do not listen to community, delete community knowledge, ignore(d) even patches they got for free just due to ignorance, ignorance, ignorance.

 

A few people here suggested to give SinoVoip a final chance. I support this. The problem is... I and others are dealing with Banana madness now in the 3rd year. We have heard that so often that it simply got too boring. So let's step back now, give them 6 months of time to show that they're willing to improve, deal with their internal ignorance/stupidity problems and then let's have a look again.

 

In the meantime it would be great if people would stop asking us for anything Banana related. Thank you.

 

 

4
chwe

chwe

Posted
Posted
1 hour ago, Lion Wang said:

MIKEY have update it.

Mikey should think about this lines too: 

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

From your schematics, PA15 & PA16 are expanded on 'CON 2' header, so it would be no problem to use it (uart_type = 4).

 

Further (line 790 to 793): 

[s_rsb0]
s_rsb_used = 1
s_rsb_sck = port:PL00<2><1><2><default>
s_rsb_sda = port:PL01<2><1><2><default>

half of this bus is now used for switching between 1.1V & 1.3V so s_rsb_used = 0 cause you can't use it for other porpuses.  

 

Maybe if you want to improve things, Mikey  could also set a 1 (w1_used) here: 

[w1_para]
w1_used = 0
gpio = 10

gpio = 10 means that one-wire would be available on (PA10, means PIN35 on your expansion header) or to make it even easier for the users set 'gpio = 20' (PA20) which would than be the nice PIN40 on this header. ;) But you have to inform your users that they should set CPU min freq to 480MHz (otherwise your Forum would be full of stuff like 'why's one wire disappearing constantly?' ). This might be something for your gitbook pages. Explaining the users 'how to connect something like DS18b20 to my BPi M2 Zero' :)

 

 

1
tkaiser

tkaiser

Posted
Posted
6 hours ago, Lion Wang said:

MIKEY have update it.

 

Yes, that's known since I wrote it already hours before, it's also known that you released an 'Armbian test image' not containing this and the other necessary fixes we mentioned already above. It's nice that you confirmed 'the SinoVoip problem' (your ignorance -- it's always like talking to a wall) so let's try another way: https://archive.fo/mB1HH (besides that as pointed out to you already more than ten times within the last years: editing files on Github doesn't solve the problems your OS images have, they need update mechanisms)

 

4 hours ago, chwe said:

s_rsb_used = 0

 

I don't know whether RSB is used with H3 legacy kernel (most probably that's irrelevant since no PMIC to talk to) but as usual that's stuff 'armbianmonitor -u' is made for (and 'armbianmonitor -m' with some benchmarks to verify if voltage switching is working correctly or at all).

zador.blood.stained

zador.blood.stained

Posted
Posted
5 hours ago, chwe said:

From your schematics, PA15 & PA16 are expanded on 'CON 2' header, so it would be no problem to use it (uart_type = 4).

I see no problems with this, at least if I understand the legacy driver logic correctly. Right now for switching between 2pin and 4pin configurations you would need to change only uart_type value, and sunxi uart driver won't claim RTS/CTS pins for uart_type=2, and won't have to uncomment RTS/CTS pin definitions or even trying to find the right pin numbers and pinmux values in the datasheet.

arox

arox

Posted
Posted
On 11/6/2017 at 2:49 PM, guidol said:

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

 

I just looked how much a BPI zero is sold in France by local reseller : 20E. More than a Nanopi air, an Orangepi zero plus h3, a CHIP. All this boards having internal storage. (Raspberry pi zero is not to be compared : I never could by one !)

 

I am looking for "light" cards for my IoTs (I have trouble with CHIP reliabability). But what could justify such a price ?

lvmc

lvmc

Posted
Posted
3 hours ago, arox said:

I am looking for "light" cards for my IoTs (I have trouble with CHIP reliabability). But what could justify such a price ?

 

The key point is CSI camera support without extension board, the missing point is no eMMC and tiny embedded RTC module.

1
arox

arox

Posted
Posted
2 hours ago, guidol said:

I know not much more lighter than a NanoPi Neo.....

only a AcmeSystems Arietta G25 ( https://www.acmesystems.it/arietta ),

a NodeMCU 8266

or a VoCore2 ( http://vocore.io/ )

 

Cute ! But I like boards with ap6212 : I want to connect my IoTs in a mesh network (*) with ppp over bluetooth. And optionaly open a fast channel over wifi.

 

(*) Has someone some experience in building a mesh network with ad-hoc wifi and olsrd ?

mindee

mindee

Posted
Posted
4 hours ago, arox said:

 

Cute ! But I like boards with ap6212 : I want to connect my IoTs in a mesh network (*) with ppp over bluetooth. And optionaly open a fast channel over wifi.

 

(*) Has someone some experience in building a mesh network with ad-hoc wifi and olsrd ?

 

NanoPi Air is very light at 7.9g, and with AP6212, and using the faster eMMC chip already. 

 

And FriendlyARM provided stable FriendlyCore system, which is  based Linux kernel-4.11 & Ubuntu Core 16.04, includes RPi.GPIO library, Wiring library etc.

tkaiser

tkaiser

Posted
Posted
59 minutes ago, mindee said:

NanoPi Air is very light at 7.9g, and with AP6212, and using the faster eMMC chip already. 

 

Nice! Thank you for reacting so promptly on me complaining here and there ;) . Which eMMC modules do you now use on the Air?

 

59 minutes ago, mindee said:

based Linux kernel-4.11

 

BTW: this kernel is now somewhat outdated (ok, not that much as the 3.4 other H2+/H3 board makers use), please ensure that as soon as 4.14 is ready Weidong switches to this version since 4.14 will become an LTS release (long term support). IMO you should also overthink maintaining your own mainline kernel fork since it will be just PITA to merge in all upstream changes (I recommended it already to Weidong back in March: adopt Armbian's build system to your needs -- soooo easy -- and submit patches for your own devices here just like other responsible vendors do -- eg. Olimex)

 

On a related note: Weidong chose to implement DRAM configuration in an incompatible way compared to how it's done upstream. This led already to a lot of confusion since Linux and u-boot maintainers now look into your sources and overtake settings that aren't valid.

 

Please remind Weidong of the problem: https://github.com/armbian/build/commit/b57c9d767ead528a54001d8728d39470e9faf5e4#commitcomment-23045104

 

Upstream maintainers now use wrong settings (eg. just 408 MHz for NanoPi M1 Plus while choosing 672 MHz for NEO 2 and so on) and there's a lot of confusion. The best idea would be if he could simply join this thread here: https://groups.google.com/forum/#!topic/linux-sunxi/coQGctAipgI (telling he's from FriendlyELEC and explaining which DRAM clockspeeds are meant to be used for which board and maybe why you chose to go another route than the standard way defining RAM parameter definitions)

 

Thank you a lot for the heads-up. Such feedback from vendors is always welcome! :)

1
Lion Wang

Lion Wang

Posted
Posted
On 2017/11/10 at 12:07 AM, lvmc said:

 

The key point is CSI camera support without extension board, the missing point is no eMMC and tiny embedded RTC module.

 

you can check BPI-M2+ ,also can use H2+ chip on BPI-M2+, have support eMMC onboard.

chwe

chwe

Posted
Posted
2 minutes ago, Lion Wang said:

you can check BPI-M2+ ,also can use H2+ chip on BPI-M2+, have support eMMC onboard.

But BPi-M2+ has 'no voltage regulation' for CPU.

5a065016e9e03_voltage_regulation_BPIM2.jpg.b2bd739733ada4b6a6e2efcd012dbfee.jpg

Which makes it 'not useful'.  Maybe you can fix this issue (and make an annotation in your documentation for this board) when you produce the next batch of this board?

1
lvmc

lvmc

Posted
Posted
41 minutes ago, chwe said:

But BPi-M2+ has 'no voltage regulation' for CPU.

5a065016e9e03_voltage_regulation_BPIM2.jpg.b2bd739733ada4b6a6e2efcd012dbfee.jpg

Which makes it 'not useful'.  Maybe you can fix this issue (and make an annotation in your documentation for this board) when you produce the next batch of this board?

 

@Lion Wang M2+ is missing the CPUx voltage regulator, that is a MUST have feature for all your products.

Lion Wang

Lion Wang

Posted
Posted
1 hour ago, lvmc said:

 

@Lion Wang M2+ is missing the CPUx voltage regulator, that is a MUST have feature for all your products.

 

let me think about it , it mean we need do CE,FCC test,again . and many user have use BPI-M2+ inside they are product . mean we need do double inventory

1
lvmc

lvmc

Posted
Posted

@tkaiser, there is only one BSP image that is booting, all the ones based on 'Armbian' aren't. The unique difference I found was that the booting image is U-boot v2017.07 and non-booting is based on v2017.09. I'm still investigating...

 

Do you know how can I measure the CPU voltage?

chwe

chwe

Posted
Posted
41 minutes ago, lvmc said:

all the ones based on 'Armbian' aren't.

false.. it boots...  

 ____                                  ____  _   __  __ ____    _____
| __ )  __ _ _ __   __ _ _ __   __ _  |  _ \(_) |  \/  |___ \  |__  /___ _ __
|  _ \ / _` | '_ \ / _` | '_ \ / _` | | |_) | | | |\/| | __) |   / // _ \ '__|
| |_) | (_| | | | | (_| | | | | (_| | |  __/| | | |  | |/ __/   / /|  __/ |
|____/ \__,_|_| |_|\__,_|_| |_|\__,_| |_|   |_| |_|  |_|_____| /____\___|_|


  ___
 / _ \
| (_) |
 \___/


Welcome to ARMBIAN 5.34 user-built Debian GNU/Linux 8 (jessie) 3.4.113-sun8i
System load:   4.33 1.66 0.61   Up time:       2 min
Memory usage:  13 % of 494MB    IP:            169.254.8.146 192.168.0.24
CPU temp:      69°C
Usage of /:    4% of 30G

Seems that @Lion Wang figured out which two files he had to write to build an own 'armbian'...

lvmc

lvmc

Posted
Posted

@chwe, which image are you using from http://www.banana-pi.org/zero-download.html ?

 

xenial3.4.1132017-11-08 => dd1e66d3025f1a6942cbc728b47bd41e

jessie3.4.1132017-11-10 => 3c57d44843db8201e125b25ec9214bcb

 

I got stuck on "Starting kernel..." after a few seconds the red LED start blikink (blink, blink, wait a little, blink, blink...)

chwe

chwe

Posted
Posted
26 minutes ago, chwe said:

Welcome to ARMBIAN 5.34 user-built Debian GNU/Linux 8 (jessie) 3.4.113-sun8i

it's everything there...  just open your eyes... :P

 

And I don't use it, I was only interested in the script.bin file... It boots,  wifi 'works' but without an external antenna, it's not stable in an urban environment. 

1
lvmc

lvmc

Posted
Posted

My Armbian build is very stable now, but I'm still investigating some warning / error messages shown on dmesg. If someone could help me to point the direction in any topic it would be great.

 

As soon as I finish it I'll do a PR on git. 

[    0.000000] cma: dma_declare_contiguous(266): ION reserve size should be 4m align! adjust size to 128MBytes

  

[    0.786562] mousedev: PS/2 mouse device common for all mice
[    0.786807] sunxikbd_init failed.
[    0.787376] ls_fetch_sysconfig_para: type err  device_used = -1073057264.
[    0.787388] =========script_get_err============
[    0.787397] ltr_init: ls_fetch_sysconfig_para err.
[    0.789001] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x18)
[    0.789171] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x19)
[    0.789338] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x1a)
[    0.789503] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x29)
[    0.789669] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x2a)
[    0.789835] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x2b)
[    0.790001] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x4c)
[    0.790201] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x4d)
[    0.790371] sunxi_i2c_do_xfer()985 - [i2c0] incomplete xfer (status: 0x20, dev addr: 0x4e)
[    0.790574] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x18)
[    0.790771] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x19)
[    0.790968] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x1a)
[    0.791164] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x29)
[    0.791360] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x2a)
[    0.791555] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x2b)
[    0.791751] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x4c)
[    0.791948] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x4d)
[    0.792144] sunxi_i2c_do_xfer()985 - [i2c1] incomplete xfer (status: 0x20, dev addr: 0x4e)

  

[    0.799377] no green_led, ignore it!
[    0.799386] no blue_led, ignore it!
[    0.799651] Registered led device: red_led
[    0.799668] no led_0, ignore it!
[    0.799676] no led_1, ignore it!
[    0.799683] no led_2, ignore it!
[    0.799690] no led_3, ignore it!
[    0.799697] no led_4, ignore it!
[    0.799704] no led_5, ignore it!
[    0.799711] no led_6, ignore it!
[    0.799718] no led_7, ignore it!

  

[    0.800622] usbcore: registered new interface driver usbhid
[    0.800634] usbhid: USB HID core driver
[    0.801827] [DAUDIO]sunxi-daudio cannot find any using configuration for controllers, return directly!
[    0.802002] [I2S]snddaudio cannot find any using configuration for controllers, return directly!
[    0.802016] [DAUDIO0] driver not init,just return.

  

[    0.811799] [HDMI] power vcc-hdmi-18
[    0.842954] ths_fetch_sysconfig_para: type err  device_used = 1.
[    0.844386] CPU Budget:corekeeper enabled
[    0.844639] CPU Budget:Register notifier
[    0.844654] CPU Budget:register Success

 

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

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept