Jump to content

Need help on Pine A64, 64bit Quad Core 1.2GHz Single board computer


khgoh

Recommended Posts

Hi,

We are currently developing a low cost single board computer base on Allwinner A64 Processor. Please refer to the pine64.com and https://www.kickstarter.com/projects/pine64/577817754?token=12cf383f for more detail on the board.

 

Currently we requesting open source community to participate and help to bring up Linux BSP to Ubuntu. Please let us know if you are interested. 

 

Thanks and regards,

KH Goh

 

Link to comment
Share on other sites

Currently we requesting open source community to participate and help to bring up Linux BSP to Ubuntu. Please let us know if you are interested. 

 

In what are you interested?

 

Paid consultancy to 'bring up Linux BSP to Ubuntu' (quite easy: simply fix the BSP you got from Allwinner here and there and add any Ubuntu rootfs you find somewhere on the net. Then you've fulfilled what 'the community' already expects: just another broken OS image for a new Allwinner SoC without 2D/3D acceleration and no HW accelerated video encoding/decoding)?

 

Or should the community do this job for free and hack together such an annoying OS image?

Link to comment
Share on other sites

BTW: I read through your FAQ on kickstarter and I hope this is just marketing chitchat: "4Kx2Kp30 H.265 decode, and 1080p60 H.264 high-profile encode and decode" have nothing to do with the GPU but are provided by Allwinner's video engine.

 

And you might be surprised how high power consumption might increase when settings are tweaked and how capable larger heatsinks used in tablets work in reality.

 

Do you made any real benchmarks already or just dubious 'MIPS'? In case you really use MIPS/MFLOPS (AKA the most useless benchmark ever invented) and compare with a PS3 and an AMD CPU it's questionable whether you understand the performance implications at all :)

Link to comment
Share on other sites

Currently, the board is running Android 5.1.1 and still under development. We tested the system with KODI, streaming H.265 4K video clips, temperature of the CPU without heat sink on it, is about the range of 40C. As for the power consumption, is about 2.5W. ( http://wiki.pine64.org/images/1/1d/Power_Consumption.jpg) For more info, please check out our wiki page at  http://wiki.pine64.org

 

As for the real benchmarks test, do you have any suggestion to have a better test method to test out the performance of the board?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Thanks for your advise. We will definitely working toward to provide a better and total system solution. For you information, there is already development to explore on CentOS by other party and will takes few months to port it to this platform.

 

Anyway, if you are interested to have some development on this platform, do let us know. We are more then willing to provide a sample board and the linux BSP.  :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest voltagex

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.

 

If less people were so eager to sign these NDAs they'd become less common.

Link to comment
Share on other sites

Hi,

We are currently developing a low cost single board computer base on Allwinner A64 Processor. Please refer to the pine64.com and https://www.kickstarter.com/projects/pine64/577817754?token=12cf383f for more detail on the board.

 

Currently we requesting open source community to participate and help to bring up Linux BSP to Ubuntu. Please let us know if you are interested. 

 

Thanks and regards,

KH Goh

 

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

Link to comment
Share on other sites

I've already integrated the kernel for Banana PI-R1 for Fedora. You always find the latest version

 

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  :P

Link to comment
Share on other sites

@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. 

Link to comment
Share on other sites

We hope that as time goes by, we can release more and more source code instate of just binary code.

 

You can always hope for such, but a better approach had been: Discuss with several SoC Manufacturers and the one who is willing to

sign the most 'open source' contract, take their SoC.

The way you and your colleagues did, is not ideal. So to say.

Link to comment
Share on other sites

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)  :P

 

And OV5640 as camera? Really?

Link to comment
Share on other sites

@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  :D 

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.

Link to comment
Share on other sites

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  :P

 

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
Link to comment
Share on other sites

@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. :)

Link to comment
Share on other sites

@khgoh - do you have any update on the plan to get sane Kernel and U-Boot for A64? I wonder if the board is worth the time or if you will end up with delivering whatever you got from Allwinner or instead hire someone from the community to do decent mainlining.

Link to comment
Share on other sites

Latest statement from the company. I just felt like some might want to know how they plan on giving people OS support... This thread and their forum at for example http://forum.pine64.org/showthread.php?tid=55&pid=300#pid300 being how they contact them I assume? It's fun to see they haven't gotten this far while putting up quotes from the media such as the board being good for high resolution video etc... I hope nobody orders this hoping to have hardware acceleration supported on their 4K video.

 

PINE64 Inc. says:

Hello, 
We are currently collaborate with several Linux developers on various Linux OS porting. Whether which Linux OS will be maintain and prosperous, this highly depending on open community effort. The NIC connected to dedicated MII bus, not sharing with USB bus bandwidth. You cannot simply upgrade from 100Mbps NIC to gigabit NIC, you can only buy the A64 version with 10/100 or buy the A64+ with Gigibit.

The Ethernet PHY is from Realtek which is commonly use by SBC community, this is no “locked down†situation,

Link to comment
Share on other sites

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)   :P

 

And OV5640 as camera? Really?

 

I don't think anyone was suggesting this can run on 500mA, but the standard 2A wall warts should work fine. Yes, this will be disappointing for people who were expecting to use it for more than power, but sparing the braindead should not be a design goal for a project such as this imo. The cooling issue will be interesting. Allwinner must've done their homework on the thermal envelope as it applies to use in tablets (their target market for this) ie tight space with no active cooling. What we don't know as yet is whether their solution entails active management to stay within that envelope a la intelish burst say.

 

What objection do you have to the OV5640? It's a very capable part based on the datasheet. Of special interest is the on-chip jpeg compressor which should drastically lower the bus bandwidth and timing requirements. Everything needed to develop for it is open, unlike the h264 stuff which we might never get working and definitely not without blobs, and where there's jpeg there's mjpeg with a bit of work. Compression without interframe dependencies has its place, eg in realtime applications where you expect the transport to be lossy. Maybe I'm missing something since I'm going off the datasheet rather than direct experience working with this particular device?

 

-p

Link to comment
Share on other sites

Latest statement from the company. I just felt like some might want to know how they plan on giving people OS support... This thread and their forum at for example http://forum.pine64.org/showthread.php?tid=55&pid=300#pid300 being how they contact them I assume? It's fun to see they haven't gotten this far while putting up quotes from the media such as the board being good for high resolution video etc... I hope nobody orders this hoping to have hardware acceleration supported on their 4K video.

 

Yeah, you're absolutely right that they've treated the linux support as an afterthought and the board as delivered is likely to be far less capable than they've claimed. Personally, I'm treating it as a way to get the Allwinner part which costs $5 in high volume (and likely unavailable to sample) on a somewhat reasonable eval board for $15.

 

-p

Link to comment
Share on other sites

What objection do you have to the OV5640?

 

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.

Link to comment
Share on other sites

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'm pretty darn sure I've seen datasheets for OV5640 (less likely a different model from the same series) in my travels that described the control interface for it. The alibaba vendors will often put up datasheets for the parts they re-sell with confidential/NDA stamped right on them.

 

Wrt thermal envelope and power, your experience trumps my guesswork. Thanks for the info/clarification.

 

-p

Link to comment
Share on other sites

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) 

If you talk about power (Watt) it doesn't matter of which you lack (voltage or ampere). You may be know that electricity is comparable with water, to a certain point. 

volt = pressure

ampere = quantity

If you are a firefighter, you either don't reach the third floor or you have not enough water to extinguish. Not enough power = you LOSE

MicroUSB = you loose

 

Basically it comes down to your engineering KNOW HOW.  Means: 

  1. how much can the board alone consume.
  2. how much can be consumed through the connectors your board comes with.
  3. plus some reserve.

It is actually - very very easy.

So I guess we have to "thank" the marketing greenhorns at SinoVoip/Foxconn for such lousy decisions.

 

 

I just had to add this to this document

Link to comment
Share on other sites

Basically it comes down to your engineering KNOW HOW.  Means: 

  1. how much can the board alone consume.
  2. how much can be consumed through the connectors your board comes with.
  3. plus some reserve.

 

 

And then it looks like this: http://wiki.pine64.org/index.php/Main_Page#Power_Usage

 

And at least Miss Marketing seems to believe in these numbers: 

(0:15).

 

Just kidding. There must be a reason that the clip only shows the PSU in detail when the game is paused. Marketing is so funny...

Link to comment
Share on other sites

about 6 comments down:

 

You are really spending working hours ;) 2.5W is a lesser draw than the 6W as said in the Pine specifications.
You should figure out that Angry Birds is using one thread/core instead of the full power (4 cores).
It will be interesting to see the temperature of Pine64 at maximum in order to decide if it will need air refrigeration. Anyway, thank you for the video :)

 

 

a game is not a benchmark TK. trapped

Link to comment
Share on other sites

a game is not a benchmark TK. trapped

 

I'm getting tired of all that crap people believe without thinking just a second.

 

  1. 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!)
  2. 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
  3. 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
  4. 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.

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines