Rui Ribeiro

I do not want to sound rude, however I suspect tkaiser is being kind to bananian. Within a few minutes of using bananian I was horrified by it. Armbian seems to have much more work put on it. And the OpenWRT of SinoVoip, I tested it and it was even worse than bananian.  About btrfs, never used it...do you consider it production ready now, tkaiser?

You actually tried to boot that? LOL Thanks for all the comments, I would like to buy an SbC to complement my Lamobo R1, but still very unsure of what to buy. Ideally it would be 64 bits and support FreeBSD. And I would prefer a MIPS to a ARM...but I would settle in a good ARM64 running Armbian. Yep, not that easy, I know.

So what? https://github.com/ssvb/u-boot-sunxi/commits/20160126-wip-a64-experimental

Save your time to head over there, just to name a few:
 
The U-Boot from the supplied Android image is severely crippled:
It can only read from its own partitions. Of course there is no network support whatsoever. Until all 36000 people from the crowd-funding receive their PCB it will be end of April or later.

You must use mainline kernel since nearly all the btrfs code lives in the kernel. Never ever try to use with outdated kernels like 3.4.x or even 3.10 (we had +30TB data loss at a customer relying on a broken btrfs feature and that was with 3.12 or 3.10).
 
And then you've to read through the docs if you want to make use of more advanced features.
 
 
 
You run 'btrfs scrub' regulary and check the output. There's no need to export checksums and store it anywhere above the filesystem layer since they are integral part of the filesystem itself:
https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html Important to note: When choosing Debian Wheezy you're a bit in trouble due to horribly outdated btrfs-progs packages (this package contains all the userland stuff for btrfs. Wheezy ships with a v0.19 or v.017 from 1876 or even older ). So either go with jessie, use backports or build btrfs-progs from sources.

The C.H.I.P. people contracted with free-electrons for Mainline kernel support and hired the only US employee formerly working for Allwinner.
 
And Linux (kernel 4.4) runs already on Pine64: http://irclog.whitequark.org/linux-sunxi/2016-01-18-- mainly because the A64 is a H3 with Cortex-A53 cores more or less. That means combining Allwinner's u-boot with Allwinner's 3.10.65 kernel with any Linux rootfs shouldn't be a problem at all (which is some sort of a problem -- see below)
 
Obviously the strategies regarding announcements and OS support are different. We'll see what that means in the long run.
 
I still fear for the Pine64 backers that they get flooded with a bunch of crappy Linux OS images and hope the Pine guys are smart enough to concentrate on one or two OS releases that receive full support (by whom?) to avoid crappyness. Otherwise situation could be like with Banana Pi M3 today: Many OS images all being broken more or less since the vendor fails to provide update mechanisms for the relevant parts (fixes for u-boot, sys_config.fex and kernel)

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.

That's an easy one: I've not seen anyone able to get something out of this camera with more than 640x480 resolution when running Linux (Android seems to be a different story). I've done some research since I thought about using a Banana Pi with this camera module (see here or here for example). But that's not important for the Pine64 since they chose a different module: http://wiki.pine64.org/index.php/Main_Page#Datasheet(we'll see what that means regarding drivers and the ability to use this camera in Linux).
 
Regarding recent Allwinner SoCs. I did some testing with both H3 and A83T (the former designed for OTT boxes, the latter a typical tablet SoC). Allwinner's kernel implements identical cooling strategies for both (throttling CPU/GPU cores and if that doesn't help shutting down CPU cores). By looking into the available A64 material it seems the same strategy applies to the A64. And the A83T for example isn't able to be clocked above 1.2 GHz without active cooling (or using the tablet's backcover as large heatsink). When reviewing the 'Banana Pi M3' I had to learn that using micro USB there is really crap since the board might easily draw 5V/3A current which is simply impossible when powering the board without a real DC-IN solution.
 
Apart from that: There are so many undervoltage/undercurrent problems associated with using micro USB for DC-IN (and the people aren't aware that 'not enough current' isn't the problem but voltage drops occuring under higher load) that I will not buy any device again that uses this crappy connector to be powered with.
 
We'll have to see how A64/AXP803 on the Pine64 behave. I would suspect that under full load with a connected USB disk spinning up the usual symptoms occur when choosing micro USB: Sudden power-off due to undervoltage.

I had a quick look into the operation of the A64 lichee SDK:
 
I let build.sh run with the following config (redirected output here):
export LICHEE_CHIP=sun50iw1p1 export LICHEE_PLATFORM=dragonboard export LICHEE_KERN_VER=linux-3.10 export LICHEE_BOARD=t1 And ended up with a typical Android boot.img, containing both kernel and initrd and being created by Android's mkbootimg:
mkbootimg --kernel output/bImage --ramdisk output/rootfs.cpio.gz --board sun50i --base 0x41000000 --kernel_offset 0x80000 --ramdisk_offset 0x01000000 -o output/boot.img At this point you're able to stick boot.img together with any suitable rootfs but there's still a lot of work to do. Everything users expect at the usual locations doesn't exist and everything that can be adjusted easily everywhere else doesn't work here (no config.txt as known from Raspbian, no uEnv.txt/boot.cmd known from distros using u-boot in a sane way, no easy access to sun50iw1p1-t1.dtb since we're booting from ramdisk with /boot being empty). Same situation again as with every other Allwinner SoC family in the past 
 
I'm really curious whether the Pine guys figure out how to solve this problem without delivering a virtual machine image with an installed Ubuntu and the lichee SDK to every user so they can recompile the whole BSP when they want to switch the HDMI resolution for example 
 
Seems both Allwinner's kernel and u-boot still rely on sys_config.fex (I put an example online, this one containing even lower clockspeeds defined): http://pastebin.com/Vh0P9w8a
 
BTW: build.sh indicates that we're seeing a few other ARMv8 (64-bit) chip families from Allwinner all being called sun5Xi:
if [ -n "`echo ${LICHEE_CHIP} | grep "sun5[0-9]i"`" ]; then export ARCH=arm64 fi

sun50iw1p1.dtsi
sun50iw1p1-clk.dtsi
sun50iw1p1-pinctrl.dtsi
sun50iw1p1-soc.dts
 
4 cores running between 480-1344 MHz (DVFS table containing 1200MHz@1.3V as highest value) and the contents of the cpu_budget_cooling/gpu_cooling/thermal-zones nodes: good luck without a heatsink (throttling) or with micro USB as DC-IN (sudden power-off without throttling) 
 
And OV5640 as camera? Really?

The "SDK" has been leaked. Allwinner uses kernel 3.10.65 and u-boot-2014.07 built with
aarch64-linux-gnu-gcc (Linaro GCC 4.9-2015.01-3) 4.9.3 20150113 (prerelease) BSP looks horrible as usual...

@Tido
Don't want to erase or alter anything unless it's really necessary. I am not that sensitive either
 
@khgoh
I can understand and support your genuine passion to build a good device. I really do.
 
Let's look on the device trough the marketing fog - what's reality, which we usually refuse to see, and what the history tells us. I don't believe that this board can bring any better experience if a business model remain unchanged. 
 
SoC supplier Allwinner doesn't really have a good reputation in areas like: support, working with community, playing a fair game, ... Their release of crappy outdated source code is more like a joke and it usually doesn't work without blobs.
 
It needs heavy fixing and no one has done that for previous AW chip series (A80, A83, H3, ...) in about a year. Check their Github, what's released, when and what was done after that. AW doesn't properly support their products and you also won't (be able to). Board without support isn't worth a penny but it's possible to sell it. People buy numbers and promises.
 
Our community here is mostly interested in real Linux experience where the only interesting thing most likely won't never work - 4K video within Linux and/or inside KODI under Debian or within Openelec. It also looks like 4K can go up only to 30p which is totally useless for a desktop usage. I might be wrong about not providing 4k@60p but haven't found the opposite information.
 
Stripped down: yet another limited usage Android device/setup box without a proper box, PSU and cables. I don't know how much will this 15$ board cost when it hit retail. Let's take an example of Raspberry Pi ZERO "price fraud" - the lowest price (more or less) for 5$ valued RPi Zero is 14.95 EUR + shipping cost, which means 24.90 EUR in total to get it to my desk or let's say around 20 EUR for most EU folks.
 
We talked the other day with @tkaiser and come out with conclusion that current SoC market is getting flooded with shitty boards. Not even one new board can be undoubtedly recommended for general usage.
 
I am not offended, don't worry about it. 

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 

Hi Igor,
 
As Moderator and owner of the forum, why don't you edit the $ 15.- in the topic of this thread. Makes it less an advertisement.
 
Need help on Pine A64, $15 64bit Quad Core 1.2GHz Single board computer

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.

"Enclosure" is a DHT11 and "Ambient" a DS18B20. And you will need to adjust the templates a bit since I monitor a lot of stuff there:
 

 

Safe to ignore.

I always do it that way: https://www.bananian.org/download#os_x
 
In fact the last step is 
sudo dd if=... of=/dev/rdisk? bs=1m && diskutil eject disk? && say "Whoot, There It Is"

I promise an update script which should work on all older builds. Here it is:
wget -q -O - http://upgrade.armbian.com | bash Currently only Allwinner based boards are supported. Next build will have others too.
 
I tested to upgrade from:
 
- current wheezy/jessie/trusty system, kernel to 3.4. and back to 4.x
- same situation with system on SATA/USB
- NAND boot/root NAND boot / root on SATA/USB
- some very old image (Cubietruck 2.8)
 
If you are not using standard scenarios please review the script before start.
 
Note that this is only a kernel, headers, firmware, u-boot, dtb, bin upgrade and my bashrc, nand-sata-install ... script - packets mentioned in previous post.

As a quick note, I am a specialist in FreeRadius, in a very near future I will be trying to configure 802.1X / hostap+freeradius 3.x in the armbian. As a side note, how many of you have wifes "nagging" about wifi problems when they happen? i could swear I was not the only one talking about it here

Hello Igor,
 
I am using vanilla 4.4 for labomo-r1
 
it seems zram module is missing. Do you intend to compile the kernel with this option, please?
gr@bpi:~$ sudo modprobe -Rf zram modprobe: FATAL: Module zram not found. On raspbian, kernel 3.18.x-4.1.x, there is a kernel module "zram" useful for embedded systems... working fine (also using on my x86 laptop)
 
https://wiki.gentoo.org/wiki/Zram
 
Nice week-end,
 
Regards,
 
Guillaume
 
 

Alter sunxi to udoo:
ls -l /lib/modules/4.2.3-udoo/kernel/net/netfilter/ ls -l /lib/modules/4.2.3-udoo/kernel/net/ipv4/netfilter/ I should add a note that Udoo kernel is not exactly Vanilla. It's an unofficial build so it could be (it is) a little different.

As far as I understand it's about the order of started services (ramlog has to be the very first and the last daemon started/stopped so that all other daemon's output will be inside the ramdisk). The parallelisms introduced with systemd make this a bit hard to achieve.
 
Anyway: You can run jessie with SysV init instead of systemd. I tried to summarize the way Bananian does it here: https://olimex.wordpress.com/2015/08/26/devuan-jessie-for-olinuxino-images/#comments

Or you can use deb-multimedia repository.
http://www.deb-multimedia.org/dists/jessie/main/binary-armhf/package/minidlna

The version in the repo (even jessie) is a year old. Build miniDLNA from source in case you get any problems with the old version.