The Orange Pi PC can be found at Xunlong's store: http://aliexpress.com/item/Orange-Pi-PC-...Title=true
If you want to encode video in Linux forget about everything else than Raspberry Pi. We still use the RPi B+ for this purpose since it's the only platform where you can encode a video stream on the VPU in Linux (even when the RPi is downclocked to 200 MHz -- it doesn't matter since all the encoding happens on the VPU and not the ARM CPU core). We're using the RPi B+ powered over Ethernet (passive PoE) and let the VPU limit the video stream's bandwidth to approx. 2 MB/s so we're able to use an A20 (older Allwinner SoC superiour to A64 since it features SATA) equipped SBC to store the videos from up to 8 RPi simultaneously.
The problem with Banana Pi M2/M3 is that the manufacturer now faces a different situation compared to when they started with the very first Banana Pi (based on the A20 like a few other devices before). When they started everything was already existent (both software and a community). But this applies only to Allwinner's A20 SoC and to none of the SoCs used later. Now they face the problem that their hardware lacks software and support and people start to realise that this makes the difference between an SBC and an expensive paperweight. And the vendor's only strategy seems to provide another crappy OS image every few days to trick people into believing the products receive software support instead of focusing on one image that really works.
Tkaiser, not 100% sure what your issue is or if trolling is your day job, however I've noticed that pretty much every post you've written in response to the Pine A64 has been negative, derogatory or down right rude. Yes, allwinner's BSP isn't a solution in a box, we got that with your first post on the Armbian forum back on the 9th. Now you have a choice, if you think it's a sinking ship - leave and stop annoying everyone else who'd like to do what they can to make this 64bit SBC some way to a success *or* now you've pointed out all of the failings, start helping the rest of us fix them! Personally I can't see why someone who sees the PineA64 as such a screw up would actually register on their forums to post on a regular basis about how bad the situation is - and what's even more of a kicker, you actually put time and effort into your posts - a reasonable amount of research and reference - which either makes you an individual with far too much time on your hands or, as I said at the beginning, a professional troll.
The PineA64 guys (Johnson et al) have found a niche and have created a product to a price point that will generate sufficient sales to make it a success - just like many other system builders (HP, Dell, Lenovo, Sony, etc). As someone who has been a system builder for some 16 years - primarily in the bespoke market, yes - we'd all like a SBC with a top end SoC, this years graphics and a completely open source BSP, the only problem is the damn thing would cost upwards of $200 a board and no bugger would want to experiment with it for fear of burning the thing out by mistake! And yes, I'm sure there would be a market for such a product, however it would be such a small market that the tooling costs alone would bankrupt the outfit who decided to build it or if it was crowd funded it would stand little to no chance of reaching the minimum sustainable goal and would fall flat on it's face anyway.
That leaves two options I can see with some degree of viability. 1. an SBC with a removable/changeable SoC (and as each chipset to PCB mapping is different and all mobile SoC's are hard soldered - not currently a viable option or 2. A low cost SBC with the best SoC package for the price point that adds something new to the plethora of SBC's already out there on the market (as the PineA64 guys have done). Yes, it's not the best SoC from a software point of view, but - with some work by those of us with the know how and the will, we can make it a viable piece of hardware and make full use of it's capabilities.
Now, it's a 64bit SBC, as far as I've found to date there is no 2gb memory ceiling (unless someone has seen it in print from Allwinner or some other verifiable resource) - which means with enough requests a 4gb or even 6gb version *could* be tooled, making full use of the 64bit addressing. Secondly the connectivity options are very good considering the cost per unit, I can think of several very interesting uses for this SBC given some work to the BSP and collaboration from the open source community.
Also, this brings me to another point, Mr Jeng has been listening to you guys, and this is borne out in his actions - he's got ARM in on the ground floor, OpenHAB, and I suspect considering the large amount of press that the PineA64 board is getting, Allwinner is keen to meet him in person to put a face to an order number, anyone with high level business experience will realise that that gives the Pine team a valuable commodity in the modern marketplace (especially during the current financial climate) and that is leverage! If you want allwinner to open their code base up to you - Email Mr Jeng, explain the benefits to him (as I'm currently in the process of doing), point out that increased open source support, the ability to use Kernel 4.1 and 4.4 is beneficial both to Allwinner and the opensource and system builder community at large. Otherwise there are two other options available - 1. Make use of someone like ourselves who are in the software development/programming market - we sign the NDA, get access to the code base, get u-boot/grub/whichever other bootloader is desired working up to the latest version(s) and do the same for the kernel support. Then pass it back to allwinner and point out that was done with one companies resources - what would they get if they opened it up to the entire open source community? The other option is to use the current BSP if they're not willing to play ball and edit at assembler level (thankfully, one of my colleagues - Keldon Alleyne has already offered his services and experience in that regard).
My point being - it's not all doom and gloom, yes, we have some work to do and no, without everyone pulling together I think it's unlikely that we'll have distro support for every flavour of linux and every kernel by their main shipping date. But if people are willing to pull their finger out and realise that their work can and will benefit them if they want to make use of the PineA64 then not only will we end up with one of the most versatile SBC's on the market at our disposal, we'll also have given the PineA64 team a product that will be both financially viable and will likely lead to subsequent versions using newer, faster, better hardware down the line - and with some luck, better open source support out of the box.
Pine need people with experience in writing/re writing graphics drivers with a focus on OpenGL and direct hardware rendering support. They also need those who have worked with Kernel development, maintenance, porting and testing, those who have worked with u-boot, Grub and other boot managers, those who ported Android over to x86 probably have valuable insights to add also. The point is, constant negative whacks at the guys putting this product together is going to result in one thing only, less of a desire to maintain support in the long term, a lack of interest in creating PineA64 2.0 - and the only people that is going to really hurt in the long term is the customer base (because I'm damn sure an outfit like the Pine team can think of another project to sink their teeth into that will provide a return on investment). I point some of you in the know towards the Tesco Hudl 2 - who got hurt out of that - certainly not Tesco, but the customer base (and yes, before anyone says it, I'm well aware the lack of product continuation and long term support is actually down to a management level change and selling off of assets, but the end case is the same).
<steps off of soapbox/>
(12-27-2015, 09:15 PM)Kommander Wrote: Tkaiser, not 100% sure what your issue is or if trolling is your day job, however I've noticed that pretty much every post you've written in response to the Pine A64 has been negative, derogatory or down right rude. Yes, allwinner's BSP isn't a solution in a box, we got that with your first post on the Armbian forum back on the 9th. Now you have a choice, if you think it's a sinking ship - leave and stop annoying everyone else who'd like to do what they can to make this 64bit SBC some way to a success *or* now you've pointed out all of the failings, start helping the rest of us fix them! Personally I can't see why someone who sees the PineA64 as such a screw up would actually register on their forums to post on a regular basis about how bad the situation is - and what's even more of a kicker, you actually put time and effort into your posts - a reasonable amount of research and reference - which either makes you an individual with far too much time on your hands or, as I said at the beginning, a professional troll.
The PineA64 guys (Johnson et al) have found a niche and have created a product to a price point that will generate sufficient sales to make it a success - just like many other system builders (HP, Dell, Lenovo, Sony, etc). As someone who has been a system builder for some 16 years - primarily in the bespoke market, yes - we'd all like a SBC with a top end SoC, this years graphics and a completely open source BSP, the only problem is the damn thing would cost upwards of $200 a board and no bugger would want to experiment with it for fear of burning the thing out by mistake! And yes, I'm sure there would be a market for such a product, however it would be such a small market that the tooling costs alone would bankrupt the outfit who decided to build it or if it was crowd funded it would stand little to no chance of reaching the minimum sustainable goal and would fall flat on it's face anyway.
That leaves two options I can see with some degree of viability. 1. an SBC with a removable/changeable SoC (and as each chipset to PCB mapping is different and all mobile SoC's are hard soldered - not currently a viable option or 2. A low cost SBC with the best SoC package for the price point that adds something new to the plethora of SBC's already out there on the market (as the PineA64 guys have done). Yes, it's not the best SoC from a software point of view, but - with some work by those of us with the know how and the will, we can make it a viable piece of hardware and make full use of it's capabilities.
Now, it's a 64bit SBC, as far as I've found to date there is no 2gb memory ceiling (unless someone has seen it in print from Allwinner or some other verifiable resource) - which means with enough requests a 4gb or even 6gb version *could* be tooled, making full use of the 64bit addressing. Secondly the connectivity options are very good considering the cost per unit, I can think of several very interesting uses for this SBC given some work to the BSP and collaboration from the open source community.
Also, this brings me to another point, Mr Jeng has been listening to you guys, and this is borne out in his actions - he's got ARM in on the ground floor, OpenHAB, and I suspect considering the large amount of press that the PineA64 board is getting, Allwinner is keen to meet him in person to put a face to an order number, anyone with high level business experience will realise that that gives the Pine team a valuable commodity in the modern marketplace (especially during the current financial climate) and that is leverage! If you want allwinner to open their code base up to you - Email Mr Jeng, explain the benefits to him (as I'm currently in the process of doing), point out that increased open source support, the ability to use Kernel 4.1 and 4.4 is beneficial both to Allwinner and the opensource and system builder community at large. Otherwise there are two other options available - 1. Make use of someone like ourselves who are in the software development/programming market - we sign the NDA, get access to the code base, get u-boot/grub/whichever other bootloader is desired working up to the latest version(s) and do the same for the kernel support. Then pass it back to allwinner and point out that was done with one companies resources - what would they get if they opened it up to the entire open source community? The other option is to use the current BSP if they're not willing to play ball and edit at assembler level (thankfully, one of my colleagues - Keldon Alleyne has already offered his services and experience in that regard).
My point being - it's not all doom and gloom, yes, we have some work to do and no, without everyone pulling together I think it's unlikely that we'll have distro support for every flavour of linux and every kernel by their main shipping date. But if people are willing to pull their finger out and realise that their work can and will benefit them if they want to make use of the PineA64 then not only will we end up with one of the most versatile SBC's on the market at our disposal, we'll also have given the PineA64 team a product that will be both financially viable and will likely lead to subsequent versions using newer, faster, better hardware down the line - and with some luck, better open source support out of the box.
Pine need people with experience in writing/re writing graphics drivers with a focus on OpenGL and direct hardware rendering support. They also need those who have worked with Kernel development, maintenance, porting and testing, those who have worked with u-boot, Grub and other boot managers, those who ported Android over to x86 probably have valuable insights to add also. The point is, constant negative whacks at the guys putting this product together is going to result in one thing only, less of a desire to maintain support in the long term, a lack of interest in creating PineA64 2.0 - and the only people that is going to really hurt in the long term is the customer base (because I'm damn sure an outfit like the Pine team can think of another project to sink their teeth into that will provide a return on investment). I point some of you in the know towards the Tesco Hudl 2 - who got hurt out of that - certainly not Tesco, but the customer base (and yes, before anyone says it, I'm well aware the lack of product continuation and long term support is actually down to a management level change and selling off of assets, but the end case is the same).
<steps off of soapbox/>
Due to the popularity of Pine A64, we recently already establish good connection with Allwinner and I just had lunch with Allwinner CEO in China on last week. On the first contact, I have already voice out the open source concern and he responded back with positive tone. On next few days, I will sort out the Allwinner open source contact window and bridge up with Sunxi community. Next week, we will ship out the "developer" edition Pine A64 boards to interested developers in our own expense and hopefully the outstanding open source concern will gradually resolved thru Allwinner participation. Please note that I only focus on Allwinner A64 open source activity (not other Allwinner current or legacy SoC) and make the Pine A64 Linux into upstream kernel as target goal.
I highly respect Tkaiser and he is a great asset to Pine64 forum. Some of his doubt has its own valid point.
Thanks on Kommander encouragement.
... TL Lim
12-28-2015, 01:41 AM
(This post was last modified: 12-28-2015, 01:42 AM by tkaiser.)
(12-27-2015, 09:15 PM)Kommander Wrote: with enough requests a 4gb or even 6gb version *could* be tooled, making full use of the 64bit addressing [...] PineA64 2.0
Regarding max. memory it's written in the SoC's user manual: http://forum.pine64.org/showthread.php?t...d=78#pid78 (in other words: combining two 12Gb modules is the maximum. AFAIR only Samsung produces modules of this size. And that's LPDDR4 and therefore not useable with the A64. So you simply end up with 2 GB max. And if anyone starts to produce 12Gb DDR3 /DDR3L/LPDDR3 in the future you end up with 3 GB that are still within the 32 bit addressing scheme. But as already written: the difference -- for some use cases -- makes the huge virtual address space with 64 bit)
Regarding Pine64 2.0: I would believe the 'Linux experience' with the first version will prevent that automagically. Due to no central efforts to provide software there will be a huge fragmentation from the early beginnings and Linux novices will be confused if they try to follow a tutorial where's written 'do an apt-get install ...' when they would've to use pacman/yum/yast instead since they're using a different distro.
The Raspberry Pi's formula for success was simplicity, 'less is more', one single OS image that is in widespread use and concentration on the very same (already outdated) hardware so that mature software support and a community was able to evolve. Something no other vendor seems to understand (they only focus on hardware and don't realise that software is way more important).
BTW: Basic support for Aarch64 has been queued for kernel 4.6 yesterday. That means that devices based on A64, R18 or H64 (like the upcoming Orange Pi 3 or the Nobel64) might be useable when mainline kernel version is at around 4.16 
12-28-2015, 04:30 AM
(This post was last modified: 12-28-2015, 04:39 AM by Kommander.)
(12-28-2015, 01:41 AM)tkaiser Wrote: (12-27-2015, 09:15 PM)Kommander Wrote: with enough requests a 4gb or even 6gb version *could* be tooled, making full use of the 64bit addressing [...] PineA64 2.0
Regarding max. memory it's written in the SoC's user manual: http://forum.pine64.org/showthread.php?t...d=78#pid78 (in other words: combining two 12Gb modules is the maximum. AFAIR only Samsung produces modules of this size. And that's LPDDR4 and therefore not useable with the A64. So you simply end up with 2 GB max. And if anyone starts to produce 12Gb DDR3 /DDR3L/LPDDR3 in the future you end up with 3 GB that are still within the 32 bit addressing scheme. But as already written: the difference -- for some use cases -- makes the huge virtual address space with 64 bit)
Regarding Pine64 2.0: I would believe the 'Linux experience' with the first version will prevent that automagically. Due to no central efforts to provide software there will be a huge fragmentation from the early beginnings and Linux novices will be confused if they try to follow a tutorial where's written 'do an apt-get install ...' when they would've to use pacman/yum/yast instead since they're using a different distro.
The Raspberry Pi's formula for success was simplicity, 'less is more', one single OS image that is in widespread use and concentration on the very same (already outdated) hardware so that mature software support and a community was able to evolve. Something no other vendor seems to understand (they only focus on hardware and don't realise that software is way more important).
Wow, Is all I can say. Clearly you haven't read the spec of the A64 properly and have just glossed over the particulars - I point out the following line on http://linux-sunxi.org/A64 - "Large Physical Address Extensions (LPAE)" - now if you are as well heeled as you make out you may recognise part of that acronym from the x86 family of processors. To remind you, this is Arm's explaination of the new technology - http://elinux.org/images/6/6a/Elce11_marinas.pdf.
To clarify, the A64 is able to address upto 1TB of physical memory thanks to a 40bit addressing space (provided by the LPAE extension, similar to the 36bit PAE extension on the intel processors which provided physical addressing of some 64GB of memory).
Yes, the Samsung memory IC's you mention are DDR4 and therefore incompatible, however you're telling me there is NOTHING in between (I've only just got up and haven't bothered looking tbh) we're looking for 4 to 6gb if we want to keep any price increase manageable so 2x2gb DDR3LP would do nicely, or 2x3gb DDR3LP. I'm pretty sure that both of those variants are available and with the LPAE are fully usable within a 64bit environment.
As for the linux experience issue - this is not particular to the PineA64 but an issue experienced by all Linux noobies - a simple solution to this is to provide a single distro, well named so it cannot be confused with anything else the wider open source hacking community are putting together for their own uses (I use the term hacking in it's Computer Science definition of course). That way for children & newbies using the board as an entry into computing projects etc - it's both usable and understandable, secondly for the rest of us, if we want to use a certain build of a certain distro - we can also. I refer you to Cake, preparation and it's consumption, p.568 (aka, having your caking and eating it too).
Also I think you've completely forgotten about the Android environment available also which shouldn't require anywhere as much work to turn into a perfect solution for all parties.
I agree Raspberry Pi have created a brilliant device however every issue you have pointed out is either fixable or avoidable - I'm starting to get the feeling that you're the guy that gets on a plane and constantly says in hushed monotone "it's gonna crash, it's gonna crash, it's gonna crash..." making the passengers in the back 3 rows very nervous indeed. Yes, there is plenty of room for FUBAR, however these guys are going about it *largely* the right way. I'm guessing that by the fact they're using crowd funding to secure capital this is their first major enterprise into this market and therefore they have a reasonably steep learning curve to deal with. I can appreciate the flip side view however TKaiser, can I recommend that you will endear more people to you by phrasing your criticisms with more diplomatic language, my personal recommendation would be 1. problem, 2. But, this might fix it... (possible solution(s)) 3. But if anyone else has greater knowledge, can you think of a better idea? - I assure you, you'll get invited to more parties in the long run.
(12-28-2015, 02:50 AM)tkaiser Wrote: BTW: Basic support for Aarch64 has been queued for kernel 4.6 yesterday. That means that devices based on A64, R18 or H64 (like the upcoming Orange Pi 3 or the Nobel64) might be useable when mainline kernel version is at around 4.16
Wow, a positive post - I'll ignore the implied sarcasm at the bottom and take it as a positive move and a definite step in the right direction *nods*.
Right, so 4.16 is our target for Arch64, good to know. Once the festivities are over I'm planning to dive into the BSP we have got to see how much turd polishing can be done and possibly gleam some useful information that can be applied when/if we get access to a full open source code base. I think erring on the side of caution is the better methodology here so, assuming we don't get full open source access one way or another, The best way forward to newer kernel support is a low level assembler hack. So anyone who has coded in assembler, debugged assembler or otherwise has a working knowledge of it, throw your hands in the air like ya jus' don't care - as it's definitely more than a one person job.
A working knowledge of C/C++ will be of benefit also.
(12-28-2015, 04:30 AM)Kommander Wrote: we're looking for 4 to 6gb [...] To clarify, the A64 is able to address upto 1TB of physical memory
Obviously you're looking for 4G B to 6G B. And I spoke about DRAM modules. You might get 4 GB total memory with 4x8Gb modules and you might get 6 GB using 4x12Gb modules. But this doesn't apply to the A64 since there is a 3GB limitation (and its memory bus is 32 bit anyway) regardless whether you accept that or not.
I'll save my time and won't comment on the other stuff you wrote
(12-28-2015, 04:50 AM)tkaiser Wrote: (12-28-2015, 04:30 AM)Kommander Wrote: we're looking for 4 to 6gb [...] To clarify, the A64 is able to address upto 1TB of physical memory
Obviously you're looking for 4GB to 6GB. And I spoke about DRAM modules. You might get 4 GB total memory with 4x8Gb modules and you might get 6 GB using 4x12Gb modules. But this doesn't apply to the A64 since there is a 3GB limitation (and its memory bus is 32 bit anyway) regardless whether you accept that or not.
I'll save my time and won't comment on the other stuff you wrote
I'll point out that a 32bit memory bus would result in a 4gb memory ceiling, not 3gb, which either means the 3GB ceiling is imposed as a software limit or there is a hardware limit not explicitly mentioned in the manual. LPAE on ARM processors results in a 40bit memory address window which does allow for 1TB - I think the only person who can clear this up would be A: Allwinner themselves as they built the damn thing or alternatively jjeng or one of the other team who have been working with the SoC for the last month - any takers?
I also wonder why you're mentioning such large memory modules for relatively small memory allocations - that makes little to no sense - the best analogy would be buying a Bugatti Veyron and Driving it back and forth to the shops at just 30mph.
(12-28-2015, 04:59 AM)Kommander Wrote: LPAE on ARM processors
...has been introduced long ago (Cortex-A15/A7) to solve the hard 4 GB limitation that would otherwise exist due to ARMv7 being a 32 bit architecture. Does that mean that any A15/A7 SoC is able to address more than 4 GB physical memory? Of course not. This depends on the SoC in question. Most if not all Allwinner SoCs are able to address 2 GB physical memory (16Gb) and the A64 is now able to use 3 GB (24Gb) when modules become available.
Since the A64 is a tablet SoC this memory limitation is acceptable. Other ARMv8 SoCs target other uses and therefore they're able to address much much more physical memory (AMD's A1100 for example is able to use up to 128 GB).
BTW: LPAE limits you to a 40 bit address space (ARMv7) while ARMv8 is able to use an 48 bit address space. LPAE is still there since "for compatibility reasons, we still support the entire ARMv7 machine in the new ARMv8 architecture" (quoting ARM).
HTH
(12-27-2015, 09:15 PM)Kommander Wrote: Tkaiser, not 100% sure what your issue is or if trolling is your day job, however I've noticed that pretty much every post you've written in response to the Pine A64 has been negative, derogatory or down right rude.
That depends on the standards you apply. Linux kernel development is a very unusual community with its own set of rules and a very idiosyncratic tone - communication is frank, direct and very harsh. It starts with Linus and flows down. Even GregKH, who is considered to be one of the nicest guys in the community, is a stark raging sociopath by suburban PTA meeting standards. Regardless of whether you like it, it has proven to work and is not going to change. There's been plenty written on this topic, so I'm not going to rewrite War and Peace here. Suffice it to say that you and others with no prior experience of this community will need to grow a thick, flame-retardant skin to be effective in it.
By LKML standards, tkaiser's posts have been exceedingly mild. If you have an issue with his tone, simply ignore the tone and respond to the substance. None of it is personal. I will also point out that the level of criticism around Pine64 linux support and a very frank, direct and harsh assessment of what it's going to take to get said support to a workable level has already spurred some action - more engineering boards scheduled to be sent to hopefully appropriate devs (although I've seen some dubious requests, to be fair), pressure supposedly put on Allwinner to cooperate with the open source community etc. It's hard to say how much of that would've happened on its own with any certainty, but judging by the early posts on sunxi lists by Pine64 people I'd wager not much. Therefore, I'd say the application of the LKML way of doing things has already had a positive effect in the Pine64 community as well.
I understand your concerns and, personally, I choose not to post in that tone in the user/backer-facing parts of the forum, but here in linux-dev it ought to be the default imo. Please note that tllim has been taking it in his stride and trying to respond in an actionable way, which is to his and Pine64's credit.
-p
|
