Interview With PINE64 On the Upcoming Release of the PineBook Pro (techrepublic.com) 107
intensivevocoder writes: One of the consequences of the explosive popularity of the Raspberry Pi is the flourishing of competing ecosystems of single-board computers (SBCs). Aside from the accessibility a $35 price tag offers, the foremost benefit of the Raspberry Pi is the community -- the proliferation of projects and integrations that center around the Raspberry Pi, and the ease-of-use that creates, makes competing products that look better on spec sheets a disappointment when taken out of the box. PINE64 has attempted to head this off by fostering an involved community; the PINE64 website explains their philosophy as "the community gets to actively shape the devices, as well as the social platform, of PINE64 from the ground up. The goal is to deliver ARM64 devices that you really wish to engage with and a platform that you want to be a part of." The first-generation Pinebook was available in an 11.6" or 14" configuration, with a quad-core Allwinner A64, 2GB RAM, 16GB eMMC, and 1366x768 display for $99, beating Nicolas Negroponte's OLPC XO-1, a decade after that project sputtered.
PINE64 is differentiating itself by building not just SBCs, but notebooks, tablets, and phones with community input and feedback. Ahead of the release of the Pinebook Pro this summer, a Rockchip RK3399-based ARM laptop with 4GB LPDDR4 RAM, 64GB eMMC, and a 14" 1080p display, TechRepublic interviewed PINE64 community manager Lukasz Erecinski about the Pinebook Pro, and the PINE64 community philosophy. An excerpt from the interview: TechRepublic: Why is Pine64 building a device ecosystem of not just SBCs, but also finished devices, like tablets, laptops, and phones?
Lukasz Erecinski: While SBCs are and will remain our bread and butter, there is no denying that our vision for PINE64 has expanded beyond the SBC market. The core aim of our project remains the same however -- to foster a community and bring affordable ARM64 devices to developers and end-users. You have correctly identified that we are building eco-systems; that is to say, we strive for convergence between our SBCs and other ARM64 devices we manufacture. In result, when evaluating future SOCs, we're not only considering if they'll make for good SBCs but also laptops, modules, tablets, etc. As time progresses, you will see more and more of this type of convergence across devices from us. Allwinner A64 and Rockchip RK3399 are two examples of what we strive for: the Pine64-LTS, the SOPine, Pinebook, PineTab and PinePhone all share the Allwinner A64, whilst the RockPro64, Pinebook Pro and SORock (upcoming module akin to the SOPine) use the Rockchip RK3399.
PINE64 is differentiating itself by building not just SBCs, but notebooks, tablets, and phones with community input and feedback. Ahead of the release of the Pinebook Pro this summer, a Rockchip RK3399-based ARM laptop with 4GB LPDDR4 RAM, 64GB eMMC, and a 14" 1080p display, TechRepublic interviewed PINE64 community manager Lukasz Erecinski about the Pinebook Pro, and the PINE64 community philosophy. An excerpt from the interview: TechRepublic: Why is Pine64 building a device ecosystem of not just SBCs, but also finished devices, like tablets, laptops, and phones?
Lukasz Erecinski: While SBCs are and will remain our bread and butter, there is no denying that our vision for PINE64 has expanded beyond the SBC market. The core aim of our project remains the same however -- to foster a community and bring affordable ARM64 devices to developers and end-users. You have correctly identified that we are building eco-systems; that is to say, we strive for convergence between our SBCs and other ARM64 devices we manufacture. In result, when evaluating future SOCs, we're not only considering if they'll make for good SBCs but also laptops, modules, tablets, etc. As time progresses, you will see more and more of this type of convergence across devices from us. Allwinner A64 and Rockchip RK3399 are two examples of what we strive for: the Pine64-LTS, the SOPine, Pinebook, PineTab and PinePhone all share the Allwinner A64, whilst the RockPro64, Pinebook Pro and SORock (upcoming module akin to the SOPine) use the Rockchip RK3399.
Does it have a crank? (Score:5, Funny)
I’m not buying a $100 laptop unless it comes with a crank.
Re: (Score:2)
And the screen goes to black and white power saving mode in daytime. The OLPC design was a wonderful assembly of low cost, well engineered ideas that was blocked in the marketplace by "dumping" of low end Windows notebooks.
Re: (Score:2)
I don't recall the OLPC having a crank but a glorified game boy due to come out soon sure has one.
https://www.nintendolife.com/n... [nintendolife.com]
Re: (Score:2)
Oh, dear. The earliest proposals included a crank or foot pedal of some sort to recharge the device. A check on the current Wikipedia article indicates that they left it out that feature when finally released.
Re: (Score:2)
The earliest proposals included a crank or foot pedal of some sort to recharge the device. A check on the current Wikipedia article indicates that they left it out that feature when finally released.
They realized that it was stupid to put the charger into the device where a) it could break and then be a PITA to replace, b) it made the device bulky and c) you couldn't use it for anything else. They did develop a charger, which IIRC was based on pulling two pieces apart from one another, but I've never seen device nor charger in the flesh.
For the record, what killed OLPC was their refusal to sell them to the first world on a get-one-give-one plan. People were lined up to buy them on that basis. They coul
Re: (Score:2)
Re: (Score:2)
The latest catalog published refuses to list price or point directly to a sales site. The sales site, at https://www.one-education.org/... [one-education.org], sells them directly but the price sis no longer attractive when a modest used laptop is available at the same price point.
Re: (Score:2)
I'd have paid about $250 for one device and one kinetic charger.
LOL! A wrist-worn one that recharges while some watch videos would have succeeded, I am sure. It is common knowledge that advancement in Internet is due to one main field of activity.
Re: (Score:3)
Iâ(TM)m not buying a $100 laptop unless it comes with a crank.
If it's got RMS-written software on it then it sorta comes with a crank already.
Re: Does it have a crank? (Score:1)
Re: Does it have a crank? (Score:1)
Re: (Score:2)
It can load InfoWars, does that count?
Re: (Score:2)
In some sectors of the software industry, an "approved developer" is a legal entity with
- articles of incorporation (that is, a corporation or LLC, not a sole proprietorship)
- its own domain with incoming and outgoing email at that domain and its own static IPv4 address
- its own office, not part of a residence
- appropriate licenses from government regulators or private-sector quality certification firms
- relevant experience, which the company can show by having published profitable commercial products in th
Re: (Score:2)
If the applications are free software written to the win32 api, then there's no reason they couldn't be recompiled against libwine to produce a native arm binary.
Re: (Score:2)
Other than that none of the core dev team own a Pinebook on which to test. Or the core dev team lack the resources to scour the application for implementation-defined or otherwise unspecified behavior that happens to differ between x86 and AArch64 ABIs. Or the application uses MFC, as in the case of OpenMPT and FamiTracker music production software. I seem to remember reading about MFC having both legal and technical problems [winehq.org] with Winelib and Arm architecture.
Re: (Score:3)
The speed and responsiveness of the GPIO pins is also much faster on the Raspberry Pi 4, likely due to its faster processor. Our test uses the gpiozero Python library to toggle pins on and off continuously and measures the rate at which they switch. The Pi 4 achieved a speed of 50.8 KHz, compared to just 16.1 on the Pi 3 B+. That's an improvement of 215%.
Will it run stock distros, installed from USB? (Score:5, Interesting)
Up til now, Pine64 requires a customized distro, with a custom kernel, and some binary driver blobs to support the allwinner chipset. I'm really tired of customized distros for various ARM boards. I really wish ARM would standardize some things, like the boot process. PC's make it so easy to boot from a USB stick and install an OS to the hard drive or SSD. Arm on the other hand has all sorts of different boot systems and all sorts of storage mechanisms. Also the hardware configurations are quite varied, requiring customized kernels, device trees, and oddball drivers. I'd like to be able to just download my distro of choice, say Fedora for Arm64 (or whatever they call their ISA), and run it on the Pi, the Pine64, or whatever.
There was a great discussion of this issue on the Ask Noah show this last week. The guest made the comment that most of the Arm implementations are really weird. If I heard right, the Raspberry pi uses the GPU to boot the CPU, which means we have to use proprietary bits from Broadcom just to turn on the ARM core and boot the thing. They also discussed having to flash the OS onto a device, vs a traditional install. Was very interesting to hear someone state the concerns I've had for years with the state of ARM devices.
Re: (Score:3)
I really wish ARM would standardize some things, like the boot process.
ARM doesn't even have a standard endian. You can order them in big-endian or little-endian.
Re: (Score:2)
Amiga was never ahead in emulation of foreign processors, they are infact way behind.
MacOS provided built in transparent emulation when migrating from m68k to ppc.
MacOSX did the same when migrating from ppc to x86.
Windows NT had NTVDM which emulated an x86 dos machine on non-x86 windows nt (Alpha, Mips, PPC)
Windows NT had FX!32 which allowed the Alpha to execute x86 win32 binaries.
Linux had something similar for executing x86 code on alpha, but it was rarely used as most software could just be recompiled an
Re: (Score:2)
Yes, it does, but the previous post claimed amiga was ahead - it never was, the first public release of amigaos 4.0 was in 2004... The first macos to include m68k->ppc came out in 1994 - a whole 10 years earlier.
As for it being deprecated, you can attribute this to the fact that macos is a far more actively supported platform where virtually everything has been ported to the newer hardware, so emulation of old binaries would become an extremely niche part of the core os used by very few users. This is ge
Re: Will it run stock distros, installed from USB? (Score:2)
Re: (Score:1)
ARM wasn't meant to be a laptop, ARM was meant to be an embedded processor, and it's good at that. You want it to do all sorts of intel'ish crap, so you tack it on, and that's fine, but at it's heart is a microcontroller, and doing stupid shit like loading device drivers is userland problems, not a boot. Just read the first memory location and go from there.
RISC OS (Score:3)
ARM wasn't meant to be a laptop, ARM was meant to be an embedded processor
Then what was RISC OS meant to be?
Re:Will it run stock distros, installed from USB? (Score:5, Insightful)
Re: (Score:3)
It was originally made for the Acorn Archimedes - a desktop computer.
you sound like you're one of the few people who still remember that ARM's real name is "Acorn RISC Machines"... :)
Re: (Score:3)
In the 70's and 80's; then Intel won that fight. ARM is fine but they are not for the masses, they make custom chips, which needs custom OS. There is no standard ARM processor which is how you get phones that aren't consuming 50W but as an after-effect you get SBC's which are basically glorified phone dev kits.
Re: (Score:2)
In the 70's and 80's; then Intel won that fight. ARM is fine but they are not for the masses, they make custom chips, which needs custom OS.
That's a bit of an overstatement. There are only a handful of bootloaders in common use, there are only a handful of architectures represented by common ARM cores, et cetera. So you need custom bootloader support, and driver support can often be a sticky issue, but it doesn't add up to a custom OS.
Re: (Score:2)
You are right on your concerns. It should be possible to run any distro, and often it isn't.
The other way round is true though, there's one distro that supports a tonload (most popular) SoC/SBC devices, including pine, called armbian: https://www.armbian.com/pine64... [armbian.com]
I think it's way better distro than, say, raspbian. Unfortunately rpi's are not supported by armbian because of exactly the things you mentioned like binary blobs. In many regards armbian is just debian which is totally fine by me and close eno
Re: (Score:2)
Mod parent up.
I just used Fedora as an example.
I'm glad some folk are tackling this issue by donating time and money to maintain such a distro. Sounds like a daunting task given the vast ARM board wasteland out there. Just supporting a particular board has to take a ton of work, and keeping it up to date even more so!
Re:Will it run stock distros, installed from USB? (Score:5, Informative)
I'm really tired of customized distros for various ARM boards. I really wish ARM would standardize some things, like the boot process.
ARM is not a chip manufacturer: it is a *licensor* of processor *cores*. unlike the monopolistic and dominant Intel, ARM does *not* produce chips. over 15 years ago it had OVER SEVEN HUNDRED LICENSEES. that must be close to 1,500 by now.
in intel's case, the quotes boot simplicity quotes that you are witnessing and happy with is down to a single proprietary vendor abusing its monopolistic position, *and*, furthermore, you are witnessing the effects of the proprietary BIOSes being entirely hidden from you. Phoenix BIOS, AMI BIOS, and so on.
so there are (aside from the unethical DRM-locking of bootloaders) three factors at play here:
(1) the fact that you do not see the plethora of board-bring-up processes behind even the Intel world. to get a glimpse of that, have a look at the source code for coreboot. in the ARM world, you use u-boot, and it covers the job of quotes hiding quotes the hardware differences
(2) the MASSIVE number of licensees - that ARM simply does not have control over - who design EMBEDDED processors. efforts to get them to quotes standardise quotes by adding IDs to internal buses (similar to PCIe and USB IDs) resulted in the majority of licensees setting those IDs to zero.
(3) the fact that were are talking *EMBEDDED* cores here *NOT* Northbridge-Southbridge cores - is a fundamental key difference. each processor is literally completely and utterly different from absolutely all other cores because the peripherals are INSIDE the same silicon. Where in the monopolistically-dominated Intel world you see a PCIe bus and a USB bus and errr.... that's it... in an embedded core (nothing to do with ARM), you have memory-mapped peripherals for UART, SPI, I2C, SD/MMC, eMMC, RGB/TTL, MIPI, CANbus, GPIO, EINT and tons more, and *none of this is or EVER can or will be standardised*.
the lack of standardisation again comes from the fact that each licensee - OVER WHICH ARM HAS ABSOLUTELY NO CONTROL - is free and clear to license the third party RTL for each and every one of those interfaces, or to design their own, or in a few rare cases to utilise libre-licensed RTL (in the case of the ICubeCorp IC3128 they utilised richard herveille's excellent rgb_ttl verilog code).
the bottom line, then, is that it is pissing in the wind to imagine that "standardisation" can take place, here. where everyone in the linux kernel community was raving about how adding device-tree would "fix" the problem, from my experience in the embedded world (reverse-engineering 9 smartphones gives you a really *really* good overview of the problem-space), i pointed out that all that would happen would be that the device-driver proliferation would be moved... from c-code into dti-code.
and... what has happened? device-tree files in the ARM world have become as complex as their c-code counterparts. in some cases, there's absolutely zero point in even *having* a dtb file, because the peripheral it covers is *WORLD-WIDE* unique. device-tree is supposed to stop proliferation of device-driver "magic constants" from two or more vendors sharing the same hardware design file.
however, even that is naive, as was found out with, for example, the Mentor USB driver. one vendor memory-mapped its control/setup registers to 32-bit, and another memory-mapped them to 16-bit locations. both vendors *wrote their own driver*. utterly impossible to merge or share the two codebases, yet the hardware (RTL) is identical.
i hope that gives you a clear picture of how things are, and are always going to be. there *is* no chance of standardisation, because each vendor, of which there are hundreds, is designing a *custom* chip, for a *very specific market* that just happens to license the same core processor... *from a third party*, and that third party happens to be known by the name "ARM".
Re: (Score:1)
Piss and moan all you will about Intel, IBM and Microsoft - but they fucking created the modern world of computers. Every facet of our lives has been affected (in a mostly positive way) by the brutal standardization and commoditization of the PC platform.
ARM has missed the boat and will continue to miss the boat on desktop and server because of their idiotic "don't know, don't care" attitude towards everything outside the CPU core.
Re: (Score:3)
ARM defines APIs. They have standard APIs for peripherals and an RTOS and booting, but it's up to individual manufacturers to supply code that implements them. And they don't have to supply that code to you, they can hide it behind an NDA or copyright/paywalls.
Re: (Score:3)
Yes you're absolutely correct in what you say.
I really wish we had some x86 SoC modules, even at a slightly more expensive price point than the Pi. But I completely understand why Intel got out of that market.
And given that there's no chance of standardization means that ARM absolutely isn't going to replace Intel/AMD in nearly any capacity.
I think for most people if they need a cheap laptop, there are plenty of low-cost Windows 10 or Linux-capable x86 laptops on the market that have more utility than even
Re: (Score:2)
I wish Pine64 luck, but unless the manufacturer of their chipset comes complete clean with full open source driver support, their potential will remain hobbled.
Most people don't care about that, though. As long as they can get drivers for Android and maybe Linux, they don't really care whether the drivers are OSS. They only care whether they exist. Obviously, having OSS drivers is an advantage there, since the company doesn't have to maintain them, but if they're doing a family driver then they might maintain it anyway.
Probably not, though :)
Re: (Score:3)
you are witnessing the effects of the proprietary BIOSes being entirely hidden from you. Phoenix BIOS, AMI BIOS, and so on.
That's a feature, not a bug. Hiding the start-up complexity from the user is why it's so easy to boot up a PC. If all ARM devices used e.g. u-Boot (just to pick an example with which I am familiar) then you'd have the same benefits on ARM platforms that you do on the PC, where you only have to attain compatibility with BIOS or UEFI in order to IPL.
Re: (Score:2)
>Hiding the start-up complexity from the user is why it's so easy to boot up a PC.
Bah.
I still think it's a critical bug in all modern unix that "Going multiuser" is, at most, printed on the consul, rather than announced in Majel Barret's voice!
hawk
Re: (Score:2)
Re: (Score:3)
The PCW8256 used an Intel microcontroller to drive the printer. The printer was super low cost and had no intelligence of its own, and was specific to the Amstrad PCW range. Anyway, that microcontroller has 1k ROM, and half of it contained code for the main Z80 CPU. The glue logic chip in the machine that controlled the reset sequence mapped part of that ROM into Z80 address space so it could boot.
The ROM was so minimal that all it could do was load a boot disk, not even display any diagnostic info on scree
Outdated software (Score:5, Funny)
Adding 64-bit support will not save this outdated email client. This train sailed away 20 years ago when the first stable version of Mutt was released.
Re: (Score:3)
It's much better than ELM though.
Re: (Score:3)
Well, we know for sure it isn't ELM. Do we know it is actually better?
Re: (Score:2)
That was my first thought when I saw PINE64 too.
Now 64-big Gopher. That might be a concept that's time has come.
Re: (Score:2)
Same, for me PINE is an email client and I was wondering what this 64bits version was all about?
Re: (Score:1)
Yeah, I was wondering why anybody would want to build an entire computer to run an old email client. And I'm pretty sure Alpine is already 64 bit and has been for a long time.
What's next, 64 bit Elm?
Allwinner (Score:5, Insightful)
I've tried to play with Allwinner based sbc's before. Not again. Any saving over a pi is not worth it for the hassle.
Re: (Score:3)
They're not using an allwinner for this one. They're using a rockchip and precisely for that reason
Re:Allwinner (Score:4, Interesting)
That's like saying they're driving a Pinto because a Gremlin is crappy. I've been down the Rockchip road before with a MK908. Both the device and the chip on it were mediocre, rapidly abandoned by the manufacturer, and with flaky support from the get-go.
I've got a Pine A64+ 2GB with the wifi module, which fits the same description.
My first ARM SBC was an original raspi. I also have a Zero W. Then I got the A64+. My next SBC will almost surely be another raspi, and I don't want anything with either AllWinner or RK inside.
Re: (Score:3)
I bought some Tinker Boards after using the RPi 2 and 3, and holy hell was the Tinker Board an improvement, to the point I gave away my RPi 2's and 3's. Looking at tests of the RPi 4, the only redeeming features on it seem to be the 4GiB RAM variant, and USB3. Having two HDMI slots, while nice, they happen to be the micro variant, which has its own issues.
Re: (Score:2)
Looking at tests of the RPi 4, the only redeeming features on it seem to be the 4GiB RAM variant, and USB3.
Pretty much. I think the RAM is a big deal.
Hardkernel pay attention (Score:2)
If this thing had an Odroid XU4 or N2 as its core, I'd probably bite.....but a pine board? $200 is around that price where you can get a new i3 or a refurbished i5. Are you telling me this thing can compete with either of those? No....of course not. What they need is a laptop shell that they can dock an odroid into and secure it for movement so you can use it at home as a standalone SBC and then take it with you as a laptop....or buy the laptop dock as an upgrade for the odroid you already have.
Pineboard is
Re: (Score:2)
Pinebook isn't a SBC. If you want a SBC from Pine you can get one with Quad 64 bit cores, 2GB and GigE for $35. Getting those specs from a raspi costs $45 so clearly there is some benefit to a board based around a less well-supported SBC. One part of it is well-supported, though, since it has a Mali GPU and there is an OSS Mali driver.
Cryptography? (Score:1)
Can I change the mobo inside? (Score:2)
Because *then* I'd be interested!
Let's move past Coke/Pepsi (Score:2)
64-bit Pine is still cool (Score:2)
While I switched to a webmail interface few years back,
I still absolutely love and use Pico everyday. :-P
Shipping & availablity? Deal killers? (Score:2)
I looked at these briefly.
As I remember, shipping is about $30, and very slow. Availability is hit and miss.
When you can get, linux capable, chromebooks on sale for $200. Is it really worth $130 for one of these Pine64 books?
Re: (Score:2, Interesting)
Re: What the fuck is this bullshit? Pine64? (Score:1)
Re: (Score:2)
In the 1980's, when NASA was a big deal, second sourcing was considered essential as in, when purchasing complex, expensive, technology (for large concerns or the military) your first question was "Who is your second source?" if their answer