wildcat_paris

I sent again an Email to SinoVoip /Foxconn asking for schematics.
So the BCM53125 ist capable, but I guess the A20 does not come with 2 ports for GBit :-(
I read on the link above, that documentation is available once you have registered for the Broadcom community.
 
If we can decrease the time, where in case of reboot the device is unsecure - it would be better than now.
 
The power issue got solved in March '15 - I will not talk about, you and I know more than enough about it.
 
 
 
I disagree, simply for the fact that it has not this all-in-one approach of the R1.
The idea is great and had I people around me who can design PCB and know how to choose the right hardware - it would be easy to build an R2.
 
Solid-run nor Turris do solve that issue of the all-in-one. Router, NAS, Cloud, Mediaplyer and with your software not from QNAP, Netgear, Zyxel, Synology.
You can get a HP ProLiant MicroServer Gen8  G1610T  but it is power hungry, big and kind of noisy beside the far higher price.
 
So all we tinkerer want, is to get the best out of the R1 and have fun that it works, right?

I am getting this one in few days. The PRO version is not in the price range of R1 but the normal / LITE could be (there is no price yet). If you consider than you get much more and I predict less troubles, than the price diff perish even compared to PRO. 
 
I don't want to judge anything before booting the beast, but it looks very well designed and right for the job. This device should be able to replace your router and NAS, while R1 doesn't come close to low end / average router and NAS capabilities.
 
Any recommendation for AC mPCI card that works well in Linux 3.18 - 4.4 (AP mode)?
 
 
 

@Zador
 
I've removed trusty.tgz (which then adds 110 minutes @home to the Armbian image making process) and *no* error messages
 
@Igor @Zador
 
I have my first fully running Armbian dev "4.81" (ok "next" is version "5.00"!) with kernel 4.4.0-rc6
and surprise, the patches from Corentin LABBE for AXP are working *now* http://sunxi.montjoie.ovh/patchs_current/
 
 

Thanks for the feedback on the testing. Any plans to test the other stuff like AES, SHA1 etc?
 
 

Hm, i really have to open this topic to find solution to my first question a minutes later. I don't know why but i have to reboot halted system during install and run - "dpkg --configure -a" . The process resumes and finish with the following errors:
but Gnome loads successfully after reboot. Of course i have to add another user instead of root to be able to login and the old problem - "the screen goes off and will not restart until reboot" remain, but it something for now.
 
So only the thing with "fb0_framebuffer_num=3" bother me for now.

You know in Waynes World when the boys went to the Alice Cooper concert and got to meet Alice Cooper (they were his biggest fans).....  All they could say was "We're not Worthy....  We're not Worthy".  That is the way I feel after downloading and installing the Jessie  version of Armbian for my Olimex Micro.  My hat is off to you....  Great Job!!!!  It blows that awful SD I got from Olimex away.....  
I really want to see your desktop now.....

I think that @Patcher has the right idea in that the only way to get an accurate measure of the battery charge is to integrate current in/out (+/-) of the battery over time (as confirmed by @KF5YFD's wikipedia link).  Fortunately the AXP209 includes a coulomb counter which should do the trick. I'm just getting started with Armbian on an Olimex Lime A20 myself, but Igor's script is a great starting point and example of communicating with the AXP209 via I2C. At some point when I have some time I might try to sort out a technique that uses the coulomb counter to track battery charge. If I do I'll be sure to post here. In any case I think the coulomb counter is the way to go.

Hi 
 
I am a bit confused.
You start with: CHIP's power design and AXP209, then you switch to AXP206 and ending with a quote about the Pine64.
 
I don't understand whether you changed devices (C.H.I.P / Pine64) somewhere in between or what you want to express. Can you edit your posting, maybe?

I'm getting tired of all that crap people believe without thinking just a second.
 
Any 2D/3D game running in Android fully utilises the GPU core(s) therefore you won't see that much CPU activity. But GPU activity can lead to high consumption too (ARM just recently announced Mali-470 as being twice as energy efficient as the outdated Mali400 from 2008 used on the A64!) Any video playback running in Android fully utilises the VPU/CedarX therefore you won't see that much CPU activity. But VPU activity can lead to high consumption too Any marketing person producing a video to proof that while playing a game consumption does not exceed 2.5W, pausing a game and then showing the consumption ONLY while the SoC is totally idle (neither before pausing the game nor after the PSU's display is shown) showcases just the opposite: If consumption is just 2.5W while being idle the consumption MUST be higher while gaming. It's that simple: If consumption would not exceed 2.5W while playing Angry Birds they would've shown it in the video. But they prefered to show idle consumption only so the conclusion is simple Apart from that that's also an interesting statement regarding the target audience BTW: Both A20 and H3 boards I've here idle at 1.5W-1.7W. Therefore either the A64 wastes energy when being idle (unlikely since Cortex-A53's strength compared to A7 is not more performance but just less consumption when using optimised software) or there's something wrong with the board or (cpufreq/dvfs) settings.

@Igor,
Through this few days of communication with the community, we has learn so much and we got the message. We will try our best, on our side to talk to AW. Hopefully, we can get through their "thick wall" and come out with some positive result.

@KH Goh  I suggest you send a sample to tkaiser - so he can try, but I must warn you: He is brutally honest. So you better attach a heat sink to it before you send it   
 
ROTFL, I just watch the movie on Kickass Krissy the marketing chick has most probably no clue what she is talking about on sec. 0:45 - but she is sweet,
so who cares   
I wonder if Kai Kreuzer (german) knows WTF he is talking about - this is nor Intel or AMD and of course his openHAB will never need to use 4k Video.

Latest version being 4.2.x? And do you realize that repackaging the work others have done is quite simple?
 
@Igor: Might be the best idea to close/delete this thread to prevent further misuse.
 
@gerhardw: 'Integrating' a new kernel build including some patches for a switch IC into a distribution that's already prepared for and using mainline u-boot/kernel isn't comparable to the challenges the Pine64 people try to delegate to the community now. All they have is the A64 BSP from Allwinner that's suited for Android device developers. And while this BSP might be a good choice for those sort of people that do not care about sane code, kernel versions or software at all (they just want to sell their tablets using Android Lollipop) the standard SDK/BSP makes it really hard to transform it into a flexible build environment necessary for any SBC.
 
I would suspect mainline kernel/u-boot will be ready maybe sometimes in 2016 so all the Pine64 guys can do is to try to find someone who knows the platform, who knows Linux, who knows Allwinner's horrible BSP and can disassemble the BSP into something flexible and useable (relying on Allwinner's outdated u-boot and 3.10 kernel in the meantime). Currently it seems they search for someone that does that for free 

Hello,
 
I've already integrated the kernel for Banana PI-R1 for Fedora. You always find the latest version at: https://www.wiesinger.com/opensource/fedora/kernel/BananaPi-R1/
 
Would be great if you can send me a pre-sample to integrate it. Just contact me via personal mail or E-Mail.
 
Ciao,
Gerhard

Hi,
First of all, I would like to apologize if I offended anyone with my posting. I am a newbie here and still got a lot to learn on this open source arena.
 
As a developer, I have a lot of passion on finding a next "Best" solution. When I first lay eye on this Soc solution,  I feel that this will be the one.
And I hope that the open source community will also have a part on it.
 
Since we are just an integrator and putting the Soc into a board, we are still tide up by the NDA lay upon us by the Soc supplier. But being having a good relationship with the supplier, we hope that we can help to get the supplier to open up more source code for the community.
 
We hope that as time goes by, we can release more and more source code instate of just binary code.

Running Android you are able to use GPU/VPU with HW acceleration and the ARM cores aren't used that much. Unfortunately linux is a different story and you'll come across users that really like to benefit from the 'quad-core A53 at 1.2GHz' since you advertise this as an SBC. Then you probably realise the difference (Allwinner SoCs aren't fast but cheap. Since the A64 is said to be able to be clocked up to 1.2 GHz I would suspect it's rather slow compared to other A53 designs and produced in an inefficient 28nm 40nm process)
 
Regarding benchmarks: They're all wrong. A good starting point when it's only about CPU performance is http://slideshare.net/brendangregg
 
But in your situation there's something special: Since you focus on Android CPU performance doesn't matter that much. It's GPU/VPU performance and the former definitely sucks (Mali400MP2 -- old and slow). But most people won't realise that since they focus on irrelevant metrics like "64 bit is twice as much as 32 bit" or "2 GB RAM is twice as much as 1 GB" or "15$ is less than $16" even if they can't tell how that really affects their use cases. You're lucky guys
 
But in case you really want to provide a good 'Linux experience' there's a lot to do.

General public is easy to mislead to backup the project - general public aka kick-starter community is dumb as hell. It's all about marketing. SBC's are still hot stuff and hardware development become ridiculous cheap so it's a great way to make money.
 
As I see you already made it to persuade investors. Why bother developers community, where you don't intent to invest more then few free boards here and there and use our channels for free marketing? BTW: You can run your marketing campaign on your own website or wherever but here you need to ask for permission. I hate ads.
 
Even before your boards become stable (to be used by professionals which is stated in your first line of your marketing appeal) you will probably restart the whole thing with a "new and better" board and hope to catch as many backers as possible. All board manufacturers are using community's current and future contribution in their business models and everyone want's to become next RPi in numbers. This is the only way you don't need to pledge anyone. Until then, we control the game.
 
Free sample? I have a bunch of boards and so do other people who develop and contribute. I don't even think to support your boards without paradigm change toward community. You collected the money for our work and you kept it. What the f*?
 
You are an engineer. It's is not your fault nor responsibility to think about this in such way. Don't take it personally either.

7 days old cache? Maybe something's up with /etc/resolv.conf (or /etc/nsswitch.conf) inside cached rootfs? Try building without rootfs cache.
 
Edit: /etc/resolv.conf is created or changed in install_kernel, so if for some reason it is not present in cached rootfs, DNS resolving in chroot won't work.

@Igor
 
Thanks for b53... I nearly achieved the quick fix last night...
my mistake: b53 needs to be included in the kernel, not as a module
 
EDIT:
Also, as you have added the patch in "lib" & I didn't remove the same patch from "userpatches", the patch was not applied twice (same file name), cool
@zador : "Zador j'adore" (like Dior perfume commercial) I like Zador

Based on kernel release schedule 4.4 should may be released in less than a week. It won't be considered stable right away, but it will be a good point to check and remove obsolete patches, test new things (like OTG on cubieruck), and it should fix UAS problem with external HDD enclosure that I have  .

@wildcat_paris
 
Everything looks ok except B53 fell out of default sunxi-dev.config ...

OK, I fixed another small mistake in code related to build script tags, now it should work like intended.
 
New debootstrap/image creation code needs testing (especially for compatibility with Trusty).

Hey,
 
yeah I meant UART1, the one available on the SOM. 
 
I had not grounded the USB-serial connecter I botched together, hence the garbage. Now it is working or well it is outputting the debug log, how do I change t hat to make it a terminal? 
 
Would be awesome to also be able to create a vanilla kernel.

Are you sure it is UART0? On A13 SOM UART0 pins are shared with microSD pins, so if you somehow connected to UART0 (old board revision?), no wonder you are getting garbage.
UART1 should be the way to go, so it needs to be configured both in u-boot and in kernel.

True That's why I wrote 'The idea the R1 is based on is good'. But you're absolutely right: the SoC, the board and the single layer 2 switch for both WAN and LAN ports are wrong. The new Marvell ARMADAs with 2 or 3 independent GbE interfaces seem to be way more suited. 
 
13 days left: https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-router#/
 
You get just the board for $99 + shipping -- given the state of R1's Wi-Fi (unuseable crap) it's simply a no-brainer to throw the R1 into the bin and pledge. I would believe the 500K stretch goal will also be reached so you get also a *good* metal case for this board for the same price.
 
Apart from that: Thanks for all the useful links. Will look through them (next year ) but not with the R1 in mind but more focused on A20's GMAC and SATA performance in general (still hoping for the quad-core A20 successor Olimex spread rumours about)

About A20 DMA engine (quote from here):
 
IMHO slapping cheap switch on a board with SoC originally designed for tablets, with single ethernet interface that doesn't support HW checksum offloading and calling it a "router" is not exactly a good concept