Linux Kernal Development - BETA Boards
#11
(12-19-2015, 03:56 AM)jj@pine64 Wrote: If you are a kernal developer, please post here your interest in working with our team and factory to port Linux OS like CentOS, Ubuntu, etc over to PINE64. Please use this thread to post interest in working with beta boards only and if you are available to help expedite the port process. 



Thank You

Hi,

I'd be interested in helping to bring Arch to the Pine64. I currently have it running on my PC and two RPi's.

Whilst I don't have much experience in Linux kernel development, it's certainly something I'd like to get involved with.

Let me know what I can do to help.

Thonners
#12
Hi there , I have an application for these boards initially for only a few 10's-100's of units.
We have over 20 years experience in debugging Kernel builds on intel and embedded platforms.
Obviously we would be most interested in areas relating to our application but willing to do our bit in other areas also.

Contact us re above via email .

John A

P.S. we also design Acrylic cases and other items handy for board development!!
#13
(12-19-2015, 03:56 AM)jj@pine64 Wrote: If you are a kernal developer, please post here your interest in working with our team and factory to port Linux OS like CentOS, Ubuntu, etc over to PINE64. Please use this thread to post interest in working with beta boards only and if you are available to help expedite the port process. 



Thank You

Hi, JJ.

I am a kernel developer and would like to help with the port, if possible.

Here are my commits in Linux kernel.
https://git.kernel.org/cgit/linux/kernel...q=cascardo


I am also a Debian developer and would like to make Debian Installer working on PINE64.

https://qa.debian.org/developer.php?logi...debian.org

Cascardo.
#14
Ideally, I'd like to run Debian on Pine64. I'd love to help you with this in anyway I can. Even just testing and debugging.
#15
Hi,
You can download the BSP from link below,

https://drive.google.com/file/d/0B0cEs0l...sp=sharing

We are currently planning to upload the BSP to github. Will update the forum when it is done.
#16
(12-19-2015, 03:56 AM)jj@pine64 Wrote: If you are a kernal developer, please post here your interest in working with our team and factory to port Linux OS like CentOS, Ubuntu, etc over to PINE64. Please use this thread to post interest in working with beta boards only and if you are available to help expedite the port process. 

You seem to be asking both for kernel developers and distro developers - those are disjoint sets of people. Let me know if you need further explanation on this point.

There is a lot of work to be done before we can get to the various distros. Simply booting in a sane way for a start. That said, my end goal is getting Arch onto the pine64 which is both more appropriate for an sbc and less demanding in terms of minimal functionality than desktop-oriented general purpose distros by default.

The problem, as things stand, is the unavailability of boards. The way to proceed is for us to poke at them, see where we get blocked and start solving the issues one by one. I'd say there is very little chance of at least something minimal working by the time you start shipping production boards unless serious people have a chance to work on it fairly soon. When will you have the engineering boards in hand?

-p
#17
(12-27-2015, 03:55 AM)paulieg Wrote: That said, my end goal is getting Arch onto the pine64

Where's the point? As usual with a new Allwinner SoC we have an outdated kernel 3.x.something (good news: It's not 3.3/3.4 but 3.10.65 instead). Someone will manage to get the kernel booting in linux and that's all that's needed to combine a rootfs with bootloader/kernel. It will be ugly and slow but since it's that easy 'distro developers' will flood the net with crappy Linux distros for the Pine64.

People who care are concerned:

[Image: 205331icqgq73u10i1x43r.jpeg]

"End of 2015". If no one applies all kernel fixes up to 3.10.94 to Allwinner's 3.10.65 kernel within the next 4 days, the Pine64 will not be able to run with a kernel that is useable from a security point of view within the next 6/9/12 months. Support for kernel 3.10 stops right now and there's simply nothing else. None of the linux-sunxi kernel developers seems to be interested and at the moment mainline kernel support is not even in an alpha state: 

https://groups.google.com/forum/#!topic/...e_UhiO00t8
https://groups.google.com/forum/#!topic/...3S4Dlmu2hc

I don't expect the situation to improve soon. Allwinner's bootloader still makes use of the sys_config.fex stuff (good news for Allwinner's real customers who sell millions of Android devices and get an development environment they're familiar with) and it seems you can define mismatching settings in sys_config.fex and .dts (the latter being used by the kernel).

As usual mainlining efforts will start from scratch and this will take some time. At the moment the Pine64 people rely solely on community's efforts (the C.H.I.P. people for example hired free-electrons to speed up development) so I would suspect we get many crappy OS images first (using Allwinner's u-boot and kernel implementation) and something useable at the end of 2016 maybe.
#18
(12-27-2015, 04:42 AM)tkaiser Wrote:
(12-27-2015, 03:55 AM)paulieg Wrote: That said, my end goal is getting Arch onto the pine64

Where's the point? As usual with a new Allwinner SoC we have an outdated kernel 3.x.something (good news: It's not 3.3/3.4 but 3.10.65 instead). Someone will manage to get the kernel booting in linux and that's all that's needed to combine a rootfs with bootloader/kernel. It will be ugly and slow but since it's that easy 'distro developers' will flood the net with crappy Linux distros for the Pine64.

People who care are concerned:
-- snip figure --

"End of 2015". If no one applies all kernel fixes up to 3.10.94 to Allwinner's 3.10.65 kernel within the next 4 days, the Pine64 will not be able to run with a kernel that is useable from a security point of view within the next 6/9/12 months. Support for kernel 3.10 stops right now and there's simply nothing else. None of the linux-sunxi kernel developers seems to be interested and at the moment mainline kernel support is not even in an alpha state: 

https://groups.google.com/forum/#!topic/...e_UhiO00t8
https://groups.google.com/forum/#!topic/...3S4Dlmu2hc

I don't expect the situation to improve soon. Allwinner's bootloader still makes use of the sys_config.fex stuff (good news for Allwinner's real customers who sell millions of Android devices and get an development environment they're familiar with) and it seems you can define mismatching settings in sys_config.fex and .dts (the latter being used by the kernel).

As usual mainlining efforts will start from scratch and this will take some time. At the moment the Pine64 people rely solely on community's efforts (the C.H.I.P. people for example hired free-electrons to speed up development) so I would suspect we get many crappy OS images first (using Allwinner's u-boot and kernel implementation) and something useable at the end of 2016 maybe.

I agree with a lot of the sentiments you express. I do, however, disagree with the universality of application of the conclusion you draw.

Yes, the suckage of Allwinner and the way they handle relations with the open source community that makes their business possible is difficult to overstate. They're far from alone in this and their competitors in the same price bands are often worse, but that's not an excuse. No one should be giving companies that take and don't give back a free pass. My guess is that their part was chosen for the performance it can deliver at an impressively low pricepoint and the fact it is shipping now. There aren't too many alternatives that improve on openness with comparable performance and price.

I agree that treating linux support as an afterthought and assuming it will just materialise out of thin air was a massive mistake on the part of Pine64. The almost inevitable resulting mismatch between the capabilities the part has in theory which were communicated in the KS campaign and the capabilities it will have in practice when delivered is a cock-up of monumental proportions and is a direct consequence of the former. A lot of this could have been avoided with some forethought; at the very least, the need for as yet unavailable but necessary software support for hardware features should've been clearly communicated. The 'fully open source' characterization is unlikely to ever be entirely consistent with reality. Given all of these things, presenting this part as a lego-style building block for vaguely technical users to build beefy xbmc/kodi rigs with was inappropriate, imo.

I agree that the CHIP people did the linux bit the right way. I do wish Pine64 had done it that way too. I doubt, however, that it would've been possible. My back of the napkin calculations suggest there's simpy not enough meat on the bone at these prices to have fully funded rapid, professional linux support development. The Allwinner part is very inexpensive for what it is, but it's a big chunk of change when you're trying to pay for everything out of $15 - there's a reason that pricepoint hasn't been done before with anything comparable.


What's done is done. Where are we, how do we move forward and is it worth doing so (you say no, 'Where's the point?')? We know what we're going to get in terms of hardware and, roughly speaking, linux support (at least t start with). From the beginning, I viewed this as a means of getting an eval board for a very capable part for very little money with enough bsp support to make it usable for the type of projects I'm interested in. For me and people like me, that's enough.

A newer kernel would be nice. I'm not that familiar with the trajectory of linux kernel development on anything except big x86(-64) boxes since my interest in embedded stuff is both recent and a hobby, but I sincerely doubt that 3.0.x kernels are 'slow' in an absolute sense and images based on them must therefore inevitably be 'crappy'. Not as good as they could be? Definitely, but not universally unusable. Certainly good enough for hacking on a great many types of projects. The proof is in the pudding we've already eaten - there were plenty of cool projects in general and on ARM specifically in the 3.0 days and very few if any cries of 'I can't do anything on this darn platform because the kernel sucks!'.

I understand your security concerns. There was a time when I was really into security stuff, spent my free time playing wargames, talked of nothing but strong crypto at parties and thought that security was the most important feature of a system that trumps everything, always and everywhere. I grew up. OpenBSD's marketshare and mindshare demonstrates that security is not the primary consideration for most people, most of the time on most every project to the exclusion of everything else.

Speaking in practical terms, the vast majority of projects people would have in mind for this board do not involve multi-user access. As such, a compromise would require a remote vulnerability in the linux kernel with no backported patch, a viable exploitation vector on ARM and someone bothering to implement that vector. This is exceedingly unlikely - an issue of such severity would undoubtedly result in backported patches being made available for EOLed kernel versions still in widespread use. The only such vulnerabilities I can recall were issues with the bluetooth stack, igmp, nfs-acl and cifs-vfs - all of them in 2.6 or earlier. None had a workable PoC resulting in compromise, bt obviously required at least physical proximity, igmp is inapplicable to our use case and so on. When you apply bayesian statistics to the probabilities of the various factors that would need to combine to create a genuine threat of compromise, you'll end up with a value that makes it more likely that you'd be eaten by a bear first. If we posit a usermode vulnerability that is then combined with an unpatched local vulnerability in the kernel, a fix for the usermode vulnerability would render that attack vector harmless so we're ok as long as everything we run in usermode is still under maintenance.

All of this is before we consider how much of a problem having your blinkenlights hobby project compromised really is, whether it's likely to sit somewhere publicly accessible rather than behind NAT and how easy it is to backport a security patch most of the time. I'd argue having your girlfriend's ostensibly under maintenance Windows laptop on your LAN is an immeasurably bigger security risk. Yes, this EOL is a security concern, but only for the paranoid or those who intend to run internet-accessible production projects on it which are non-commercial in nature and can therefore not pay for support. I suspect that the intersection of those sets contains a number of elements that asymptotically approach zero. As such, I would argue that 3.0.x is good enough for most people from this perspective.

As for Arch, I happen to like it and it's an excellent fit as far as general purpose distros go for low resource devices. You might well disagree and think it's 'ugly', 'crappy' etc just as you disagree on whether Pine64 is going to be usable unless it has mainline support. This comes down to preference, opinion, expectation, skill level and suitability for the type of projects you had in mind for it.

So, in your words, 'Where's the point?' The point is that this board, if it ships, will be the most appropriate platform for the project I have in mind for very little money. I, or someone else, will get it to boot and I anticipate being able to get my distro of choice on it with a bit of elbow grease. Subsequently, I expect to have fun hacking on my project on Pine64 and that, surely, is the ultimate point.

It's not going to be perfect, certainly not to start with and possibly not ever. I am, however, willing to put in a bit of effort to get it on its way. I'm sure there'll be others who do as well. It certainly won't be the first time the community has hacked on an imperfectly supported piece of hardware to make it do what we want.

-p
#19
(12-27-2015, 08:58 AM)paulieg Wrote: It certainly won't be the first time the community has hacked on an imperfectly supported piece of hardware to make it do what we want.

Sure, but devs might think different about this specific board compared to the Kickstarter crowd that only heard of the Raspberry Pi before.

I had a look into the BSP two weeks ago: http://forum.armbian.com/index.php/topic...er/?p=3173

Just to elaborate what I meant with 'crappy OS images' and 'slow'.

The problem with Allwinner's BSP is that it only provides an Android boot sequence with leads directly to problem N°1: http://forum.pine64.org/showthread.php?t...207#pid207 (Andre provided also a few first patches in the meantime that focus on compiling and not functional issues)

If this is sorted out and we're able to boot then everything that's really important does NOT live inside the rootfs of the distro in question but instead in the first sectors of the SD card used unless we (the community) develop a different bootloader approach. You want to change a kernel parameter? Rebuild the BSP! You want to adjust a small piece of hardware initialisation? Rebuild the BSP!

Most people happily joining the Pine64 club now (developers) seem not to be familiar with the linux-sunxi platform (Allwinner SoCs) and that this is one of the hardest challenges as long as we've to rely on Allwinner's kernel and bootloader. Therefore they will concentrate on the stuff they're familiar with (tuning something inside the rootfs) and that's where the crappy OS images will originate from. 

You can see that over at banana-pi.org (Banana Pi M2/M3 are just other sunxi devices with limited mainline kernel support) where even the vendor itself is only able to provide crappy OS images since he doesn't manage to escape from Allwinner's Android bootloader stuff. They told you to recompile the whole BSP to switch to a different display resolution in the past (same might happen here). In the meantime they adopted our suggestions to provide a few adjusted u-boot settings and to overwrite the first sectors on the boot media. But this 'solution' is far away from being acceptable.

And regarding 'slow': We can't benefit that much from the one important '64 bit' feature with a SoC that can only address 2 GB of physical RAM (though it helps being able to use a huge virtual address space). But to be able to benefit from the other ARMv8 feature it would be necessary to use code that has been compiled for the ARMv8 instruction set. Only then you see a performance improvement. If you're forced to use software compiled for ARMv7 or ARMv6 (I bet someone will provide a Raspbian image for the A64 rather sooner than later) then you don't benefit from Cortex-A53.

Therefore we'll see OS images where performance differs much due to
  • used architecture (if you choose the normal armv7h Arch Linux rootfs instead of building your own on top of http://archlinuxarm.org/platforms/armv8/generic then performance will be degraded)
  • kernel settings (a few things are really important to get performance gains on slow ARM SoCs)
  • cpufreq/dvfs/thermal settings
And then it's the question of the use case. If you're a software developer that wants to start porting stuff to Aarch64 then the Pine64 might be interesting. If you just want a cheap SBC with the same CPU/GPU performance but much more I/O bandwidth you better go with an Orange Pi PC for the same price. Its SoC has 3 USB host controllers instead of just one (the 2nd USB port on the Pine64 uses the USB OTG controller. On other/older Allwinner SoCs the OTG port can use the musb app gadget controller in host emulation mode but that's not a real host controller, performance is worse and not all USB devices will work with. I would suspect the same applies to the A64 as well)
#20
(12-27-2015, 11:17 AM)tkaiser Wrote:
(12-27-2015, 08:58 AM)paulieg Wrote: It certainly won't be the first time the community has hacked on an imperfectly supported piece of hardware to make it do what we want.
Just to elaborate what I meant with 'crappy OS images' and 'slow'.

The problem with Allwinner's BSP is that it only provides an Android boot sequence with leads directly to problem N°1: http://forum.pine64.org/showthread.php?t...207#pid207 (Andre provided also a few first patches in the meantime that focus on compiling and not functional issues)

If this is sorted out and we're able to boot then everything that's really important does NOT live inside the rootfs of the distro in question but instead in the first sectors of the SD card used unless we (the community) develop a different bootloader approach. You want to change a kernel parameter? Rebuild the BSP! You want to adjust a small piece of hardware initialisation? Rebuild the BSP!

Most people happily joining the Pine64 club now (developers) seem not to be familiar with the linux-sunxi platform (Allwinner SoCs) and that this is one of the hardest challenges as long as we've to rely on Allwinner's kernel and bootloader. Therefore they will concentrate on the stuff they're familiar with (tuning something inside the rootfs) and that's where the crappy OS images will originate from. 

You can see that over at banana-pi.org (Banana Pi M2/M3 are just other sunxi devices with limited mainline kernel support) where even the vendor itself is only able to provide crappy OS images since he doesn't manage to escape from Allwinner's Android bootloader stuff. They told you to recompile the whole BSP to switch to a different display resolution in the past (same might happen here). In the meantime they adopted our suggestions to provide a few adjusted u-boot settings and to overwrite the first sectors on the boot media. But this 'solution' is far away from being acceptable.

And regarding 'slow': We can't benefit that much from the one important '64 bit' feature with a SoC that can only address 2 GB of physical RAM (though it helps being able to use a huge virtual address space). But to be able to benefit from the other ARMv8 feature it would be necessary to use code that has been compiled for the ARMv8 instruction set. Only then you see a performance improvement. If you're forced to use software compiled for ARMv7 or ARMv6 (I bet someone will provide a Raspbian image for the A64 rather sooner than later) then you don't benefit from Cortex-A53.

Therefore we'll see OS images where performance differs much due to
  • used architecture (if you choose the normal armv7h Arch Linux rootfs instead of building your own on top of http://archlinuxarm.org/platforms/armv8/generic then performance will be degraded)
  • kernel settings (a few things are really important to get performance gains on slow ARM SoCs)
  • cpufreq/dvfs/thermal settings
And then it's the question of the use case. If you're a software developer that wants to start porting stuff to Aarch64 then the Pine64 might be interesting. If you just want a cheap SBC with the same CPU/GPU performance but much more I/O bandwidth you better go with an Orange Pi PC for the same price. Its SoC has 3 USB host controllers instead of just one (the 2nd USB port on the Pine64 uses the USB OTG controller. On other/older Allwinner SoCs the OTG port can use the musb app gadget controller in host emulation mode but that's not a real host controller, performance is worse and not all USB devices will work with. I would suspect the same applies to the A64 as well)

Thank you for the very informative precis of the initial issues, their impact and some of the steps required to address them. It's much more helpful and actionable. Would you say that this state of affairs for banana pi is a consequence of fixing it being too difficult or the status quo being sufficiently workable so that no one is sufficiently incented to do the work? This might be my ignorance of linux on ARM talking, but none of it seems insurmountably difficult especially wrt u-boot.

I haven't been able to find the Orange Pi for anything near $15 - they currently run $25+ on their ali* storefront. As far as use case, I'm interested in being able to ingest video at 720p via MIPI-CSI, send it somewhere over a kludgy imitation of 802.11p using packet injection and seeing what the floor is like for end-to-end latency. Provided all of that works and I like the numbers, I'll want to see if I can adapt it to a low power platform. I'm not married to this idea though - this is a hobby after all, so I'd like to do it on a device that's more rather than less futureproof. I also happen to have a more work-related reason to be interested in 64-bit ARM and this is a cheap way to start developing some familiarity with the architecture and its performance.

-p


Possibly Related Threads…
Thread Author Replies Views Last Post
  NEMS Linux 1.5 Released for A64/A64+, A64-LTS/SOPine, Rock64, RockPro64 (NAGIOS) Baldnerd 4 6,966 03-28-2020, 06:20 PM
Last Post: ty1911
  Howto run Linux with resolution other than 1080p longsleep 28 55,254 06-13-2019, 01:53 AM
Last Post: Nilda
  NEMS Linux for Pine A64 (+) Luke 1 3,882 05-09-2019, 05:42 PM
Last Post: pineadmin
  Pine Board using linux stuck during boot sequence ktaragorn 4 5,955 03-30-2019, 06:48 AM
Last Post: ktaragorn
  Gentoo Linux test image xalius 23 39,548 01-28-2019, 11:05 PM
Last Post: necrose99
  +LTS/SOPINE +PINEBOOK Mainline Armbian for A64 boards Luke 0 1,993 01-12-2019, 06:35 AM
Last Post: Luke
  Real-time linux kernel Artyom 45 51,931 09-11-2018, 01:08 AM
Last Post: zzwpine
  linux distribution hazerty 3 4,562 04-01-2018, 02:48 PM
Last Post: dkryder
  Linux Web Server OS harcrow 2 4,580 01-30-2018, 10:26 AM
Last Post: Rustproof
  eta linux image?? firosiro 1 3,046 08-03-2017, 10:05 PM
Last Post: pfeerick

Forum Jump:


Users browsing this thread: 2 Guest(s)