The new Banana PI M2 Ultra

[rexxster]

  My Opi2e is in the middle of a long compile session and I just broke out the BPI-m2u to play with when this

timely forum topic came up.

 

5 hours ago, tkaiser said:

• SATA: as slow/crappy as with A20 today
• 2 GB RAM: http://www.linuxatemyram.com
• 16GB eMMC? It's only 8 GB and maybe the slowest modules you can buy from Samsung (just search the forum, sequential writes on this eMMC is as low as 6MB/s, almost every SD card out there is faster)
• The vendor is famous for not being able to provide even correct schematic so trying to support their hardware is both an excercise in stupidity and a great way to waste your own time
• The vendor is also famous for providing best support possible: Look here for example how their official support account @sinovoip is actively helping countless users affected by the same problem: instability with this great M2 Ultra: http://forum.banana-pi.org/t/frequent-freeze-ups-of-m2u/2823

 

 Re: emmc,  Yup, my bad.  Was going by memory - haven't had it plugged in for a while.   I had shelved the m2u

because the hdmi was flakey with my old monitor.

 

 Re:  "The vendor is famous for not being able to provide even correct schematic ..."    Yes, they have a organizational failure.  Foxxconn and SinoVoip are funding them but not holding

whoever's in charge accountable.  Their english is functional, and their grammer is awful.  Communication is horrible.

 

 Re: "...trying to support their hardware is both an excercise in stupidity and a great way to waste your own time".   You know, you really are an ass.  I'll forward your sentiments to linux-sunxi

where [PATCH v2] Initial Allwinner R40 support was just dropped by Icenowy Zheng.

 

 Re: http://www.linuxatemyram.com  derp asshole.

 

  Responding to you is "both an excercise in stupidity and a great way to waste your own time".

 

  I'm done.  go ahead and rage reply or delete this post or whatever.  You're just the most toxic ..

 

peace out.

 

[tkaiser]

41 minutes ago, rexxster said:

where [PATCH v2] Initial Allwinner R40 support was just dropped by Icenowy Zheng.

 

For anyone else stumbling accross this thread: I referenced Icenowy's branches already in this thread for a reason and it should be noted that her patch series is called 'Initial Allwinner R40 support' -- not just Icenowy is concerned about still the only R40 device around being unfortunately a Banana product... and that pretty much sums it up why linux-sunxi devs are currently dealing with BPi M2 Ultra at all: no other R40 devices available

 

[tkaiser]

Scary update: BPi M2 Berry is on it's way: https://bananapi.gitbooks.io/bpi-m2-ultra-open-source-single-board-computer/content/bpi-m2-berry-hardware/bpi-m2-berry-hardware-spec.html

 

Most if not all support threads in their forum regarding Banana PI M2 Ultra are related to 'this just sucks': http://forum.banana-pi.org/c/Banana-pi-BPI-M2-Ultra

 

And instead of improving the software support situation or even answering to those many support questions or complaints those crazy 'engineers' decided to add to this mess shitty Micro USB for DC-IN to ensure that users will run into even more basic stability problems from now on: "BPI-M2 Berry power with Micro USB port (default)"

 

So they sell now a new board with RPi 3 dimensions using R40 and still SATA but no eMMC, IR and battery support any more. 4 USB receptacles means an internal USB hub (already curious whether they do it in the most stupid way as usual and as we can see on Banana Pi M3 already: not exposing one of the SoC's USB host ports and then connecting all USB receptacles through an internal hub to the remaining SoC's host port) and switching back to 'great' Micro USB will ensure that majority of users suffers from under-voltage and the usual symptoms (instability under load, maybe even boot/crash cycles. Amazing!).

 

Can we please stop adding such support nightmares like this to Armbian's build system?

[Ian]

Thanks for the work Armbian do in getting decent secure builds for these little SBC's which have been "caught between a rock and a hard place" (hard place being the CH SOC makers that historically were not interested in supporting these quasi reference boards and the rocks being the backstreet CH SBC makers who have neither the finances nor abilities to support their quasi reference boards).

 

IMHO unless the SOC makers start to properly support software wise an up to date reference SBC board for each SOC then things are not going to change that much but i think the CH SOC makers have realised that if they can IOTise their business then this can add a shed load of valuation potential and the likes of Allwinner seem to be taking typically CH baby steps in this direction.

 

I pick up these SBC boards periodically (either as samples from the SOC makers or i buy then as in the case of ODROID) and I received a R40 based BPI and out of the box it didn't inspire confidence (fingerprints/areas of residue in board coating) and the BPI website is just dire (though no worse than many of the other CH SBC's) and its no surprise they have downgraded to microusb power/no emmc to save a few pennies on its BOM - i mean how much does it cost to add an aluminium heatsink to the PMIC + SOC!

 

I'll keep this little board on the back burner for a while to play around with as the R40 ref. board has a lot of potential as a little low power headless SATA squeezeboxserver its just a pity noone else is using the R40 platform or Allwinner hasn't stepped up to the plate with decent reference board linux source for an up to date kernel/drivers.

 

i live in hope Allwinner ? while i wait to see what HardKernel's new 64bit platform is like (to replace long-term my lovely ODROID based squeezebox server my nephew has taken off to University with him)

 

 

ian          

 

 

 

 

[tkaiser]

May I introduce BPi M2 Berry? Inherits all the shitty support/software situation from BPi M2 Ultra but adds Micro USB crappiness to it:

 

http://forum.banana-pi.org/t/banana-pi-bpi-m2-ultra-bpi-m2-berry-new-image-2017-05-25-raspbian-jessie-preview3-bpi-m2u-sd-emmc-img/3306

 

Please see at the bottom picture how thick the power cable inserted into the Micro USB jack is. Of course those morons do not test with an average Micro USB cable with the usual resistance way too high (that's what 99 percent of their users will use) so they repeat what happened 1.5 years ago with Banana Pi M3: While all their users out there struggled with crappy Micro USB and had even to solder a different power connector to stop this board from crashing and the other under-voltage symptoms those SinoVoip 'engineers' tested all the time only with perfect cables connected to bench power supplies and told users that they're wrong.

 

Soon this forum will get flooded by Berry users asking for software that makes their BPi Berries stable if we don't take countermeasures.

[hmartin]

On 27.5.2017 at 7:55 AM, tkaiser said:

Soon this forum will get flooded by Berry users asking for software that makes their BPi Berries stable if we don't take countermeasures.

While I agree that it is not our job to provide support to people buying the boards (that would be the manufacturer's responsibility) if someone wants to add support for the board in Armbian I don't see why we should refuse their help.

 

Of course I have zero sympathy for people who come here and complain about the hardware decisions the vendor made (e.g. microUSB power, crappy EMMC, bad 1T1R WiFi) because that is entirely outside our control.

 

So I would say, if someone does submit patches to support the Banana Pi M2U or Berry, we accept it. But it is also wise to put up a disclaimer that any images for Banana Pi come with zero support and we will ignore requests for free support on the forums.

[zador.blood.stained]

Just now, hmartin said:

So I would say, if someone does submit patches to support the Banana Pi M2U or Berry, we accept it.

"mainline based images" would be a good correction for this statement IMO.

 

1 minute ago, hmartin said:

But it is also wise to put up a disclaimer that any images for Banana Pi come with zero support and we will ignore requests for free support on the forums.

All messages, disclaimers, licenses and similar stuff doesn't work. Ethernet MAC address and wireless on Orange Pi Zero mainline images is a fresh example of that.

[tkaiser]

3 hours ago, hmartin said:

But it is also wise to put up a disclaimer that any images for Banana Pi come with zero support and we will ignore requests for free support on the forums.

 

Doesn't work as Zador already mentioned. Users don't read stuff like 'you agree that this is experimental and you don't get any support'. They open up new threads every day and get angry if stuff that worked yesterday doesn't work today after latest upgrade (which is EXACTLY what is to be expected when using using 'nightlies' especially after kernel updates and stuff like that). They also fail to understand which efforts are needed to deal with mainline kernel images (upgrade process included) as long as the 'WiP' stuff is not somewhat stable (but since Armbian doesn't have a FAQ where we could add an explanation maybe some understand...)

 

Anyway: It's also about expectations. Different devices, different user groups or 'target audiences'. If someone in 2017 buys any of those more recent Bananas this is a clear sign that he did not spent a single second on research first (just visit their forums: it's all about 'this totally sucks'). Then this specific vendor is not able to provide correct information, specifications or even schematics. Maybe they're too careless, too stupid or it's just a strategy (focussing their whole business on stupid people). Please read this about this 'M2 Berry': http://forum.banana-pi.org/t/banana-pi-bpi-m2-berry-quad-core-single-board-computer-with-allwinner-v40/3312 (archived version)

 

They do not even give a shit about the SoC used (R40 vs. V40 -- both are more or less the same but it's just weird to talk about V40 and show pictures of R40, but maybe this single guy doing all this 'documentation', 'specification' and 'announcement' stuff is just not able to care about anything important or at all?). Anyway: I'm so sick of dealing with such crap that I think we should 

• immediately think about no more releasing those absolutely useless 'nightlies' any more
• prepare a board phase out process (to get rid of shitty hardware we started to support by accident, eg. Actions Semi S500 boards)
• stop stupidly trying to convert Armbian project (good, secure and stable OS images) into a board bring up adventure (crappy and instable OS images adding more and more questionable hardware and frustrated users)

[hmartin]

On 5/28/2017 at 8:11 PM, tkaiser said:

• immediately think about no more releasing those absolutely useless 'nightlies' any more
• prepare a board phase out process (to get rid of shitty hardware we started to support by accident, eg. Actions Semi S500 boards)
• stop stupidly trying to convert Armbian project (good, secure and stable OS images) into a board bring up adventure (crappy and instable OS images adding more and more questionable hardware and frustrated users)

 

1. I still find the nightlies useful, but then again I know they are in development and don't expect them to be perfect. I realize other people don't understand this.
   1. Maybe you want to switch to a different model? Semi-regular releases with some automated testing. For people who want nightly builds, they can build it themselves.
2. Agree. There needs to be a way to phase out support for boards if there is no more community support or they cannot be maintained.
3. Agree. Armbian should not be "hey vendor, cheap out on software because Armbian will fix it for you" therefore I would propose:
   1. Only add boards where mainline support is coming/already implemented
   2. Only add boards where the hardware is of a certain quality (e.g. none of this micro USB powered shit, too time consuming to support people with stability issues)
   3. Only add boards when there is at least one dedicated developer who will be working on it (e.g. people can vote to support a new board, but unless someone is willing to contribute code, we aren't going to do the work. I'm thinking quite specifically of the Orange Pi Zero here, where people were complaining while contributing absolutely nothing)

[tkaiser]

BPi M2 Ultra specific info wrt the stability issues many boards are plagued with: https://github.com/facat/BPI-M2U-bsp/commit/dff5ffe35dc22b2904993b0441c6cf6dd54efd0f#commitcomment-22739082

[tkaiser]

3.10.106 kernel for BPi M2 Ultra: https://github.com/BPI-SINOVOIP/BPI-M2U-bsp/pull/3 (of course the brain damaged retards owning this github repo are too careless to merge this pull request)

[tkaiser]

Update on BPi M2 Berry: this board will be available in a few weeks at least here in Germany for €39: https://www.reichelt.de/?ARTICLE=202546&PROVID=2773 (Alternate lists it already, the other usual suspects like conrad.de will follow soon).

 

Advertising material called datasheet available here: http://cdn-reichelt.de/documents/datenblatt/A300/BANANA-PI-M2-BERRY_DATASHEET_V2.pdf

 

Document author is 'Vertrieb1', Language is 'de-DE', even the Raspbian they send out to testers runs with German localization (see next link below). The German company behind that is currently making a lot of money with RPi accessories and overall it looks like this M2 Berry here is just the try to answer two often asked Raspberry user questions: 'Why is there no SATA and can we have a Gigabit Ethernet upgrade?' (technical answer simple: not possible since the Raspberry SoC has only 1 USB2 OTG port and nothing else).

 

So it seems that's where the M2 Berry should jump in: Similarly priced giving the impression users will get everything a RPi 3 provides plus better network and SATA.

 

The 'datasheet' elaborates on M2 Berry being 'identically constructed as the Raspberry Pi 3B and completely compatible to all the Raspberry accessory' clearly targeting current RPi users interested in a SATA port. Compatibility to 'all the Raspberry accessory' includes enclosures but 'BPi M2 Berry did not fit in my RPi test case due to the size of the SD Card slot' (will be fixed maybe or not).

 

The advertised 'technical data' is wrong many times, eg. 'wifi antenna slot on board' where there is none, DRAM is not clocked with 733MHz since 576MHz is the allowed maximum (vendor ignores this of course and uses overclocked settings maybe responsible for instability issues), GPU cores do not clock with 500MHz but just 360MHz but at least they corrected maximum CPU clockspeed (M2 Ultra has been advertised with 1.5GHz which is just 300MHz too much).

 

What do Raspberry Pi users most probably expect and what will they get?

 

Compatibility: Though 'runs even with Raspbian' very limited in reality. Let's look into details:

1. This is a Raspbian userland combined with an insecure kernel 3.10.65 (outdated since 2.5 years containing many already fixed security vulnerabilities. It would take the vendor 1 second to fix this since community did all their work but they refuse for whatever reasons). In contrast on Raspberries you run with always up to date kernel versions 4.4, 4.9 or even higher.
2. Some GPIO stuff on the header is not useable since deactivated. If you're an expert you might be able to help yourself but don't expect any help from the vendor since they don't know what they're doing (example to get UARTs working on the header)
3. RPi Add-Ons following the HAT specifications (little EEPROM that can be readout through I2C) you can connect physically but don't expect them to be working (see 2) above) and especially not 'automagically' as it's the case on Raspberries (there the ID EEPROM will be readout at start and the necessary device-tree overlays are loaded automatically. Nothing of this is available here and will never follow since software support is as worse as possible)
4. HDMI display situation is not comparable. The M2 Berry kernel contains a crippled HDMI driver which is not EDID capable (display resolution/parameter detection), supports only a few 16:9 resolutions (you can only switch between by exchanging the bootloader with a tool called bpi-set which is of course nowhere mentioned) and /boot/config.txt as used in Raspbian to configure exotic displays is of no use here
5. By looking at the pin count of the DSI LCD connectors of both boards (30 vs 40) you should already get how this specific 'Raspberry accessory' is compatible: not at all
6. Same with camera connector (30 vs 24 pins, no drivers available for the various RPi camera add-ons). If the camera connector won't be exchanged on the final board revision it's impossible to horizontally insert a camera cable anyway when using this board with most if not all available enclosures.
7. Everything graphics related (video, 2D and 3D acceleration) is totally different since M2 Berry and real Raspberries use totally incompatible SoCs: Broadcom VideoCore IV vs. Allwinner V40. Nothing RPi users are used to will work on M2 Berry (no omxplayer, no raspivid/raspistill, no support for 'video in web browsers' and so on)

Surprisingly low level of compatibility, isn't it?

 

Performance: CPU slightly slower, graphics not comparable, networking performance outstanding, also true for storage but not that overwhelming.

1. Since most RPi 3 users run ARMv6 or ARMv7 distros CPU performance of M2 Berry's V40 ARMv7 SoC is somewhat comparable unless you try to run special software that can make use of RPi 3's ARMv8 CPU cores (if you've no idea of what I'm talking then it's not you  )
2. Don't expect any graphics performance, an out-of-the-box running Kodi or anything similar. Nothing works though community tries to fix this but gets zero help from manufacturer and chip maker
3. Networking is Gigabit Ethernet attached to an own bus (RGMII) so with appropriate settings you'll get 10 times better network performance than on any RPi ('appropriate settings' highlighted since there will never be something like Bananian or Armbian available for M2 Berry)
4. Wi-Fi/BT are the same on RPi 3 and BPi M2 Berry so performance might be identical if SinoVoip engineers did the antenna setup appropriately. No one knows yet. In fact all we know is that the manufacturer never does performance tests.
5. Storage performance is better when relying on SATA than on Raspberries but not that overwhelming. As usual community has to do all the work and @Tzahi Arnonprovided some numbers: 37/285 MB/s so 'Allwinner SATA' we're talking here about still suffers from poor write performance (compare with the '2017 SBC storage performance overview')
6. The V40 SoC used here has 2 USB host ports but most probably all the 4 USB receptacles are connected via a single internal USB hub to one of the two host ports so all USB ports have to share bandwidth (we don't know since the manufacturer isn't able to answer such simple questions and also refuses to release schematics)

Community/support: http://forum.banana-pi.org/c/Banana-pi-BPI-M2-Ultra (take 10 minutes of your time and visit a few threads to get the idea how lost you'll be)

 

Stability: Will be 'interesting' especially with the only use case where the M2 Berry would be a better choice than a RPi 3.

 

Since M2 Berry has been designed to create the impression to be as compatible as possible with Raspberries also the DC-IN connector has been chosen compatible: Micro USB. This alone will most probably make up for a great ratio of 'DOA experiences' since under-voltage will be a huge issue especially when you try to power a 2.5" HDD by the board.

 

This is long known, it is a well known issue with the first Banana Pi from 2014, then with Banana Pro, same story with the unfortunate BPi R1, their first BPi M3 batches (and many other SBC that copied the stupid decision to use crappy Micro USB). Choosing Micro USB is the best way to get boards instable (suffering from under-voltage, the higher the load, the lower the voltage --> freezes, crashes, boot loops).

 

Why do Raspberries work then with same PSU/charger and cable? Since RPi folks started to masquerade this problem starting with 2nd RPi generation. They added under-voltage detection circuitry and if voltage drops below 4.65V a GPIO will be toggled telling the firmware to downclock immediately CPU, GPU and DRAM (maybe also reducing power available on USB ports) so the RPi survives such situations but will only get slower (see here for a script to check for this on Raspberries and a link to some additional details)

 

We don't know whether it's possible to power M2 Berry more reliably (eg. GPIO header pins or SATA power pins) or whether there are step-up converters on the board using the PMIC (power management IC) to compensate from voltage drops since the manufacturer isn't able to answer such simple questions and also refuses to release schematics. Only time will tell.

 

Edit: Just a minor documentation update on how ignorance can turn into something called irreführende Werbung in Germany wrt Banana Pi BPi M2 Berry soon:

 

• armboard.de: 'Preislich liegt er jedenfalls auf dem gleichen Niveau wir der RPi3, bringt jedoch einige Verbesserungen oder die lang ersehnte und gewünschte SATA Schnittstelle mit' (Verbesserungen?), 'GPIO Schnittstelle ist Pin-kompatibel mit dem Raspberry Pi' (Ach?), 'Eine Neuanschaffung von Gehäuse, Netzteil, Display, Kamera und sonstige HAT kompatiblen RPi Erweiterungen, müssen also nicht vorgenommen werden' (viel Glück!)
• rasppishop.de: Same as above
• reichelt.de: 'Der Raspberry Pi 3 Killer - Baugleich und dennoch mehr Features wie z.B. SATA, Gigabit LAN, Android', 'Der neue Banana Pi ist Baugleich mit dem Raspberry Pi 3 und kann somit das komplette Zubehör verwenden, wie bspw. Gehäuse und Shielde' (they also sell an OS called BPI BRY OS suggesting full compatibility)
• alternate.de yet refrains from irreführende Werbung
• notebooksbilliger.de: 'Selber Formfaktur wie Raspberry Pi 3 - Zubehör ist kompatibel!' (Ach?), 'Mali 400 MP2 GPU @500MHz' (360 MHz max)
• elektor.de: 'Der Banana Pi M2 Berry ist baugleich mit dem Raspberry Pi 3 B und voll kompatibel zum gesamten Raspberry Pi-Zubehör' (except all the stuff that's not compatible of course  ), 'Mali 400 MP2 mit 500 MHz'
• allnet.de: '2GB DDR3 SDRAM' (Ach?), 'the 40 pin GPIO header is pin-compatible with Raspberry Pi' (you'll not able to use since stuff not enabled)
• conrad.de: The same wrong information used as by most others (no wonder)
• ELV currently only has the advertisement material uploaded where all of the wrong information originates from

 

How could this happen? Well, a vendor cultivating ignorance at every level. Simply don't giving a sh*t about information/documentation being correct combined with 'just wait and see' attitude trying to create the impression finally everything will be fine. I don't believe EU importer and resellers have the slightest idea what's going on.

 

BTW: Nicest M2 Berry bullshit compilation can be found on SinoVoip's advertisement compilation on Wikipedia (there almost everything is wrong, SinoVoip's human spam bot calling himself Tymaker is obviously even more careless than their copy&paste monkey responsible for their official 'technical documentation')

 

 

 

 

 

[tkaiser]

SinoVoip ignorance explained by their CEO: http://www.cnx-software.com/2017/05/29/banana-pi-bpi-m2-berry-allwinner-v40-development-board-allwinner-business-units-sdksoftware-management/#comment-543430

 

So they think it's not a problem that they don't play well (failing with providing correct information/documentation, releasing schematics, releasing sources, accepting help from community eg. the pending pull request on Github) but their problem is being reminded of that.

[tkaiser]

BPi-M2 Zero officially announced: https://archive.is/ReznS (the link to the 'technical documentation' on the bottom is the one to edit their Gitbook nonsense, SinoVoip's copy&paste monkey producing this mess all day long is maybe really the most careless person in the whole industry).

 

So they're really trying to directly compete with RPi foundation for the most clueless customers

 

M2 Berry is advertised as a fully compatible but better 'replacement' for RPi 3 and this 'M2 Zero' here is obviously the try to attack RPi Zero W sales. Camera connector is incompatible, software is incompatible (M2 thingies to Raspberries and you can't use one OS image on M2 Berry and Zero since they're also incompatible to each other), support situation is laughable and the most interesting hardware features of the H2+ SoC (Ethernet + 3 x USB2 host ports) aren't used. Who's responsible for such product 'design'?

[tkaiser]

Update on false advertising wrt BPi-M2 Berry: https://youtu.be/6BhDj3j0Hrc?t=54s

 

European resellers of this board start to lie to their potential customers due to an absolutely careless/irresponsible hardware manufacturer either providing wrong information due to their 'don't giving a sh*t about everything important' mentality or maybe even lying to their distributors/resellers.

 

'The new Banana Pi is structurally identical to the Raspberry Pi 3 and can therefore use all accessories' is a lie and also an indication that these resellers never looked into details. Camera and display connector have a different pin count so this alone prevents RPi cameras and displays to be used with BPi-M2 Berry (same applies to RPi cameras and BPi-M2 Zero), most Raspberry HATs using an I2C accessible EEPROM that require device tree overlays (applied automagically on Raspberries!) won't work correctly on BPi-M2 Berry or Zero, using the same PSU/charger from a Raspberry Pi with BPi-M2 Berry especially when trying to power a SATA disk and making use of Gigabit Ethernet might not work since there's no under-voltage detection/protection on the SinoVoip products.

 

What a mess and all just due to a company not caring about providing correct information/specifications. Soon unhappy customers, unhappy resellers, unhappy importers... and most probably the hardware manufacturer again don't giving a sh*t about their hardware being falsely/misleading advertised or not. 

 

[hmartin]

On 5/4/2017 at 10:33 PM, tkaiser said:

 

For anyone else stumbling accross this thread: I referenced Icenowy's branches already in this thread for a reason and it should be noted that her patch series is called 'Initial Allwinner R40 support' -- not just Icenowy is concerned about still the only R40 device around being unfortunately a Banana product... and that pretty much sums it up why linux-sunxi devs are currently dealing with BPi M2 Ultra at all: no other R40 devices available

 

 

Glad I searched the forum. I'm trying to get 4.13-rc4 booting on the BPiM2U because apparently dwmac support is landing in 4.13. Unfortunately, it seems that we are still pretty far from mainline support for the R40, since trying to boot gets me this far:

http://i.imgur.com/gLRPxpE.png

 

I also found out that u-boot doesn't support USB, or Ethernet. So when I was missing the dtb (because 4.13 doesn't include one for the R40) the only way to recover was to boot from sdcard and copy the dtb. Thank goodness I still happened to have the armbian Banana Pi M2 Ultra image I made earlier on an sdcard. If not I would have just thrown it to the scrap.

 

I think I'll wait until 4.13 is released before I start hacking Icesnowy patches on top.

 

Exciting times ahead...

[zador.blood.stained]

2 minutes ago, hmartin said:

Unfortunately, it seems that we are still pretty far from mainline support for the R40, since trying to boot gets me this far:

http://i.imgur.com/gLRPxpE.png

Given that the essentials like this and this didn't reach the mainline yet, I wouldn't expect the pure mainline to work for at least half a year.

[Suvad]

Any ideas on this?
Greetings, Trying to make build BPI-M2U-bsp.  

Having trouble with drivers for AP6212 & FT5x_ts. clean rootfs.

firmware and nvram.txt and config.txt are in /lib/firmware/ap6212 folder. Builded modules with the kernel itself.

Using pack script and PhoenixCard to create image:

Fex Conf for WIFI:

Spoiler

[wlan]
wlan_used                            = 1
compatible                        = "allwinner,sunxi-wlan"
clocks                = "outa"
;pinctrl-names                    = "default"
;bt_clk_gpio                        = port:PI12<4><0><0><0>
wlan_power            = "vcc-wifi"
wlan_io_regulator         = "vcc-io-wifi"
wlan_busnum                        = 1
wlan_regon                        = port:PG10<1><1><1><0>
wlan_hostwake                    = port:ower0<0><default><default><default>
;--------------------------------------------------------------------------------
;bt configuration
;clocks:                            32k clk
;bt_power:                        bt power
;wlan_io_regulator:        the power of bt io
;bt_rst_n:                  bt function enable io
;status:                            okay
;--------------------------------------------------------------------------------
[bt]
bt_used                                = 1
compatible                        = "allwinner,sunxi-bt"
clocks                                 = "outa"
pinctrl-names                    = "default"
clock_io                            = port:PI12<4><0><0><0>
bt_power                             = "vcc-wifi-2"
bt_io_regulator             = "vcc-io-wifi"
bt_rst_n                            = port:PH12<1><1><1><0>
;--------------------------------------------------------------------------------
;btlpm configuration
;uart_index:                    uart0, uart1 or uart3
;bt_wake:                   host wake-up bluetooth device
;bt_wak_host:               bt device wake-up host
;status:                            okay
;--------------------------------------------------------------------------------
[btlpm]
btlpm_used                        = 0
compatible                        = "allwinner,sunxi-btlpm"
uart_index                        = 3
bt_wake               = port:PG11<1><1><1><0>
bt_host_wake          = port:power1<0><default><default><default>
[sdc1]
sdc1_used          = 1
bus-width    = 4
sdc1_clk           = port:PG00<4><1><3><default>
sdc1_cmd           = port:PG01<4><1><3><default>
sdc1_d0            = port:PG02<4><1><3><default>
sdc1_d1            = port:PG03<4><1><3><default>
sdc1_d2            = port:PG04<4><1><3><default>
sdc1_d3            = port:PG05<4><1><3><default>
;sunxi-power-save-mode =
sd-uhs-sdr50            =
sd-uhs-ddr50            =
sd-uhs-sdr104            =
cap-sdio-irq            =
keep-power-in-suspend    =
ignore-pm-notify    =
max-frequency       = 150000000

 

modprobe: ERROR: could not inser 'bcmdhd': No such device
Output from dmesg:
sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B

Spoiler

[ 1104.440892] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1104.448462] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1104.455539] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1104.457998] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1104.459804] sunxi-mmc sdc1: smc 2 p1 err, cmd 8, RTO !!
[ 1104.466951] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing LEGACY(SDR12) dt B
[ 1104.475998] sdio_read_cis: 2 callbacks suppressed
[ 1104.476006] mmc2: queuing unknown CIS tuple 0x80 (2 bytes)
[ 1104.477514] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1104.479021] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1104.481736] mmc2: queuing unknown CIS tuple 0x80 (7 bytes)
[ 1104.574418] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1104.574584] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1104.574826] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 4 timing SD-HS(SDR25) dt B
[ 1104.578045] mmc2: new high speed SDIO card at address 0001
[ 1104.740104] wifi_platform_bus_enumerate device present 1
[ 1104.740143] sunxi-wlan wlan: bus_index: 1
[ 1104.740148] ======== Card detection to detect SDIO card! ========
[ 1106.740160] failed to power up DHD generic adapter, 3 retry left
[ 1106.756976] wifi_platform_set_power = 0
[ 1106.757002] ======== PULL WL_REG_ON LOW! ========
[ 1106.757466] wifi_platform_bus_enumerate device present 0
[ 1106.757502] sunxi-wlan wlan: bus_index: 1
[ 1106.757514] ======== Card detection to remove SDIO card! ========
[ 1106.757781] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1106.766349] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1106.774815] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1106.783234] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1106.791851] dummy_sdmmc: probe of mmc2:0001:1 failed with error -123
[ 1106.791970] dummy_sdmmc: probe of mmc2:0001:2 failed with error -123
[ 1106.792599] wifi_platform_set_power = 1
[ 1106.792613] ======== PULL WL_REG_ON HIGH! ========
[ 1106.793026] mmc2: card 0001 removed
[ 1106.793044] sunxi-wlan wlan: check wlan wlan_power voltage: 3300000
[ 1106.793516] sunxi-wlan wlan: check wlan io_regulator voltage: 2700000
[ 1106.793560] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm OD pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 1106.794668] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1106.810064] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1106.830875] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1106.838636] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1106.845514] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1106.847966] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1106.849841] sunxi-mmc sdc1: smc 2 p1 err, cmd 8, RTO !!
[ 1106.857076] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing LEGACY(SDR12) dt B
[ 1106.866230] mmc2: queuing unknown CIS tuple 0x80 (2 bytes)
[ 1106.867753] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1106.869276] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1106.872013] mmc2: queuing unknown CIS tuple 0x80 (7 bytes)
[ 1106.958769] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1106.958915] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1106.959131] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 4 timing SD-HS(SDR25) dt B
[ 1106.962376] mmc2: new high speed SDIO card at address 0001
[ 1107.110249] wifi_platform_bus_enumerate device present 1
[ 1107.110287] sunxi-wlan wlan: bus_index: 1
[ 1107.110299] ======== Card detection to detect SDIO card! ========
[ 1109.110345] failed to power up DHD generic adapter, 2 retry left
[ 1109.127198] wifi_platform_set_power = 0
[ 1109.127228] ======== PULL WL_REG_ON LOW! ========
[ 1109.127685] wifi_platform_bus_enumerate device present 0
[ 1109.127721] sunxi-wlan wlan: bus_index: 1
[ 1109.127734] ======== Card detection to remove SDIO card! ========
[ 1109.127997] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1109.136595] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1109.145018] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1109.153462] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1109.161902] dummy_sdmmc: probe of mmc2:0001:1 failed with error -123
[ 1109.162007] dummy_sdmmc: probe of mmc2:0001:2 failed with error -123
[ 1109.162429] wifi_platform_set_power = 1
[ 1109.162442] ======== PULL WL_REG_ON HIGH! ========
[ 1109.162840] sunxi-wlan wlan: check wlan wlan_power voltage: 3300000
[ 1109.163286] sunxi-wlan wlan: check wlan io_regulator voltage: 2700000
[ 1109.163354] mmc2: card 0001 removed
[ 1109.163578] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm OD pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 1109.164643] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1109.180212] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1109.200928] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1109.208689] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1109.215566] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1109.218019] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1109.219916] sunxi-mmc sdc1: smc 2 p1 err, cmd 8, RTO !!
[ 1109.227149] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing LEGACY(SDR12) dt B
[ 1109.236383] mmc2: queuing unknown CIS tuple 0x80 (2 bytes)
[ 1109.237911] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1109.328978] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1109.329141] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1109.329368] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 4 timing SD-HS(SDR25) dt B
[ 1109.333419] mmc2: new high speed SDIO card at address 0001
[ 1109.480220] wifi_platform_bus_enumerate device present 1
[ 1109.480271] sunxi-wlan wlan: bus_index: 1
[ 1109.480300] ======== Card detection to detect SDIO card! ========
[ 1111.480159] failed to power up DHD generic adapter, 1 retry left
[ 1111.497066] wifi_platform_set_power = 0
[ 1111.497093] ======== PULL WL_REG_ON LOW! ========
[ 1111.497523] wifi_platform_bus_enumerate device present 0
[ 1111.497560] sunxi-wlan wlan: bus_index: 1
[ 1111.497572] ======== Card detection to remove SDIO card! ========
[ 1111.497811] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1111.506313] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1111.514638] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1111.522410] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1111.530267] dummy_sdmmc: probe of mmc2:0001:1 failed with error -123
[ 1111.530364] dummy_sdmmc: probe of mmc2:0001:2 failed with error -123
[ 1111.531112] wifi_platform_set_power = 1
[ 1111.531127] ======== PULL WL_REG_ON HIGH! ========
[ 1111.531362] mmc2: card 0001 removed
[ 1111.531628] sunxi-wlan wlan: check wlan wlan_power voltage: 3300000
[ 1111.531854] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm OD pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 1111.532104] sunxi-wlan wlan: check wlan io_regulator voltage: 2700000
[ 1111.533160] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1111.550130] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1111.570860] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1111.578481] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1111.585445] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1111.587900] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1111.589706] sunxi-mmc sdc1: smc 2 p1 err, cmd 8, RTO !!
[ 1111.596815] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing LEGACY(SDR12) dt B
[ 1111.605852] sdio_read_cis: 2 callbacks suppressed
[ 1111.605861] mmc2: queuing unknown CIS tuple 0x80 (2 bytes)
[ 1111.607368] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1111.608876] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1111.611595] mmc2: queuing unknown CIS tuple 0x80 (7 bytes)
[ 1111.698010] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1111.698117] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 1 timing SD-HS(SDR25) dt B
[ 1111.698324] sunxi-mmc sdc1: sdc set ios: clk 50000000Hz bm PP pm ON vdd 8 width 4 timing SD-HS(SDR25) dt B
[ 1111.701703] mmc2: new high speed SDIO card at address 0001
[ 1111.870115] wifi_platform_bus_enumerate device present 1
[ 1111.870152] sunxi-wlan wlan: bus_index: 1
[ 1111.870165] ======== Card detection to detect SDIO card! ========
[ 1113.870167] failed to power up DHD generic adapter, 0 retry left
[ 1113.886987] wifi_platform_set_power = 0
[ 1113.887014] ======== PULL WL_REG_ON LOW! ========
[ 1113.887437] wifi_platform_bus_enumerate device present 0
[ 1113.887473] sunxi-wlan wlan: bus_index: 1
[ 1113.887485] ======== Card detection to remove SDIO card! ========
[ 1113.887549] failed to power up DHD generic adapter, max retry reached**
[ 1113.887592] unregister wifi platform drivers
[ 1113.887605] wifi_platform_bus_enumerate device present 0
[ 1113.887623] sunxi-wlan wlan: bus_index: 1
[ 1113.887634] ======== Card detection to remove SDIO card! ========
[ 1113.887649] dhd_module_init: Failed to load the driver, try cnt 0
[ 1113.887700] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1113.896203] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1113.904632] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1113.912878] sunxi-mmc sdc1: smc 2 p1 err, cmd 7, RTO !!
[ 1113.921255] dhd_module_init: Failed to load driver max retry reached**
[ 1113.921274] dhd_module_init: Exit err=-19
[ 1113.923230] mmc2: card 0001 removed
[ 1113.923744] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm OD pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 1113.925758] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm PP pm UP vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1113.940073] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1113.960868] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1113.968678] sunxi-mmc sdc1: smc 2 p1 err, cmd 52, RTO !!
[ 1113.975545] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1113.977990] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm PP pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1113.979869] sunxi-mmc sdc1: smc 2 p1 err, cmd 8, RTO !!
[ 1113.987439] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !!
[ 1113.995006] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !!
[ 1114.002556] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !!
[ 1114.010065] sunxi-mmc sdc1: smc 2 p1 err, cmd 5, RTO !!
[ 1114.017457] sunxi-mmc sdc1: smc 2 p1 err, cmd 55, RTO !!
[ 1114.025208] sunxi-mmc sdc1: smc 2 p1 err, cmd 55, RTO !!
[ 1114.034690] sunxi-mmc sdc1: smc 2 p1 err, cmd 55, RTO !!
[ 1114.043018] sunxi-mmc sdc1: smc 2 p1 err, cmd 55, RTO !!
[ 1114.049723] sunxi-mmc sdc1: sdc set ios: clk 400000Hz bm OD pm ON vdd 21 width 1 timing LEGACY(SDR12) dt B
[ 1114.050715] sunxi-mmc sdc1: smc 2 p1 err, cmd 1, RTO !!
[ 1114.058386] sunxi-mmc sdc1: sdc set ios: clk 0Hz bm OD pm OFF vdd 0 width 1 timing LEGACY(SDR12) dt B
[ 1179.052733] ft5x_ts: Unknown symbol input_set_power_enable (err 0)
[ 1179.052792] ft5x_ts: Unknown symbol input_init_platform_resource (err 0)
[ 1179.052812] ft5x_ts: Unknown symbol input_request_int (err 0)
[ 1179.052847] ft5x_ts: Unknown symbol input_fetch_sysconfig_para (err 0)
[ 1179.052898] ft5x_ts: Unknown symbol input_set_int_enable (err 0)
[ 1179.052965] ft5x_ts: Unknown symbol input_free_platform_resource (err 0)
[ 1179.053089] ft5x_ts: Unknown symbol input_free_int (err 0)

 

[tkaiser]

On 15.8.2017 at 3:03 PM, Suvad said:

Any ideas on this?

 

Not that much. I don't think anyone here will touch M2 Ultra before there's appropriate mainline Linux support (all done by some brave linux-sunxi community souls since Allwinner doesn't care about mainline kernel).

 

Just a quick hint: I can personally confirm Wi-Fi working on BPi M2 Berry booting SinoVoip's Raspbian and latest Xenial Mate image for M2 Ultra. So if you're really keen on working with Tinalinux and the smelly BSP kernel I would fetch their latest Xenial image, compare firmware files and check script.bin there (apt install sunxi-tools / bin2fex)

[@lex]

A couple of things should be checked:

 

* Check your System.map, you should see something like:

Spoiler

c060aae0 T input_free_platform_resource
c060aaf4 T input_init_platform_resource
c060ab0c T input_fetch_sysconfig_para
c060ab24 T input_set_power_enable
c060abd8 T input_set_int_enable
c060ac34 T input_free_int
c060ac94 T input_request_int

 

A good reading: https://en.wikipedia.org/wiki/System.map

 

Seems like you have build FT5X adn AP6212 out of linux tree or maybe mixing kernel version modules, try modpost .

 

* check for file permission settings (AP6212), maybe PhoenixCard messed up your partition and file permissions. 

 

* Kernel 3.10.xx does not use script.bin , it generates a DTS file from a fex file type and then compiles it to DTB used by kernel

 

 

 

[tkaiser]

13 hours ago, @lex said:

Kernel 3.10.xx does not use script.bin , it generates a DTS file from a fex file type and then compiles it to DTB used by kernel

 

Thanks for the reminder, totally forgot that Allwinner with R40/V40 'already' switched to 3.10. So it's not sunxi-tools package that's needed but device-tree-compiler to check .dtb contents (I would not rely on 'source' stuff somewhere in SinoVoip repos but better decompile the stuff that is known to actually work on Berry/Ultra)

[Lion Wang]

Banana pi BPI-M2 Ultra update newest schematic

 

https://drive.google.com/file/d/0B4PAo2nW2KfndFpmZG1OOWJ5NEU/view

[tkaiser]

6 hours ago, Lion Wang said:

Banana pi BPI-M2 Ultra update newest schematic

 

https://drive.google.com/file/d/0B4PAo2nW2KfndFpmZG1OOWJ5NEU/view

 

As a reference:

• old schematic (Rev 1.0, internal name 'bpi-m2-ultra-v1_0-release', date on every page: 'Wednesday, November 30, 2016'), all component values have been removed before exporting to PDF
• your new schematic from above is also Rev 1.0 (why?), internal name 'bpi-m2-ultra-v1_0-20170822-r', dates on individual pages: 3 x Friday, July 29, 2016, 2 x Friday, August 05, 2016, 6 x Tuesday, August 22, 2017
• It's not reflecting latest/next PCB revision (PH23 --> vcc5v0/5V-EN as you call it on BPi M2 Berry schematic)
• There seems to be another 'confidental' one flying around (Chen-Yu reported back then when he got it from Foxconn that he is not allowed to share contents)

Do you plan to release correct schematics anytime soon or at all?

[Lion Wang]

1 hour ago, tkaiser said:

Do you plan to release correct schematics anytime soon or at all

 

yes, with friendly way. 

[hmartin]

Looks like the BananaPi M2 Ultra support is alive and well!

(this is sarcasm)

 

Mine was "working" until I decided to try mainline on it. Now I'm building Icesnowy's r40-v5 to see if there's been an progress. Please don't ask me for an Armbian image, support is nowhere near good enough to release even an alpha image.