Search the Community

You already helped a LOT! Indeed! Let's fix this Pinebook's troubles and we might slowly switch 4.19.y to nightly NEXT building ...

Nice to have those tested: Sopine A64 Olimex Lime 2 eMMC Those are still problematic and should be fixed before any update: Orange Pi Zero Plus2 H5 Pinebook

Good day. Can you please tell me what needs to be done to make the bluetooth work? As I understand it, you need a file https://github.com/armbian/build/blob/master/packages/bsp/pinebook/pinebook-bluetooth.service. What to do with it? My opi prime works on Armbian Stretch mainline kernel 4.14.y

It works on A64/Pinebook (LCD brightness). It should work on H5 but I haven't done any tests. DEV branch (4.19.y).

Latest build from Armbian dev 4.19.2 Still strange ... Are you using pinebook image on a pine64 board ? Because the SDIO node doesn't exist on Pine64 DT, but it is there for Pinebook ...

@Igor Did you figured out why those patch prevent Pinebook to boot ? (it didn't previously)

@gamelaster If you will try with our patchset, disable those and Pinebook should boot: general-add-overlay-compilation-support.patch general-enable-kernel-dtbs-symbol-generation.patch general-sunxi-overlays.patch

Great progress!!! We need to keep one kernel for many hw and that's why patches are a must. Current situation is still messy and I only find out that some of my additional patches are causing Pinebook to hang at boot. I also plan to merge a dozent of patches, some sent upstream to make it easier to maintain. I was working whole day yesterday and the day before and the day before ... I can add new updated test image, but it is much better for me to do nothing for a few days. When things are merged in, images can be produced automatically. No need to rush anywhere. Production ready images shell go out when DEV branch is tested very well and is moved to NEXT. We still miss suspend / resume, right? This is a must function for notebooks. I haven't saw if there is a solution developed for that?

1st build: https://dl.armbian.com/pinebook-a64/Debian_stretch_dev_desktop.7z (still cleaning patches)

which Pinebook problems? I did see that the report for the Pinebook is out of date, but there was no newer kernel as the latest report on your page. For testing other Pinebook things - I only have a "old" Pinebook - the non-1080-one at 14"

Perhaps those warnings can be cleared out even they are harmless ... @guidol tnx. I am getting close to Pinebook(s) problems.

Those boards still need to be tested - some of them I don't have: Nanopi Neo Core 2 LTS Orange Pi R1 Pinebook A64 (know to break booting atm) Sopine A64 Olimex Lime 2 eMMC Nanopi Neo Air Pine64

We need to sort that out, 4.19.y is only interesting on this Pinebook. Remove all but https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/general-packaging-4.17-dev.patch and try ... than add patch by patch. I have no idea which is breaking this ATM.

Hi! I already successfully get mainline Armbian working on Pinebook (no sound - working on fix, and also suspend took much time to wake up), but, I don't like the way how I made it. Github repo: https://github.com/gamelaster/build/tree/pinebook-build I set the branch to "next", I set kernel repository to anarsoul's kernel (contains latest patches for A64 and also for Pinebook & Sopine devices) and deleted all patches from sunxi-next (all that patches has been for 4.14), I just kept and add some of patches. But this is probably terrible idea. @Igor or anyone, can you please me suggest better way to support "next" kernel (The task is to support latest anarsoul's kernel)? I was thinking about changing KERNELFAMILY variable, but really dunno, I'm using Armbian build environment for first time. P.S. the beta automatical build for Pinebook boots u-boot, then kernel, but in kernel is something messed up (the LCD shutdowns after few second of kernel booted), but I will try to fix it, to have "dev" support too Thanks for advices! - gamiee

Earlier today I pushed a fairy large patchset containing various functional improvements of many boards. If you have Allwinner board and some spare time: 1. Build DEV image/kernel with https://github.com/armbian/build (you need to add EXPERT="yes" to the config to unlock) 2. Install DEV kernel from beta repository Optional Defreeze kernel updates Switch to nightly kernel (armbian-config -> system -> Nightly) Reboot Switch to other kernel (armbian-config -> system -> Other -> DEV) When board came up, do some exploration. Most important information is to find out if there is a regression toward kernel 4.14.y! Then make a test report https://github.com/armbian/testings#how-to-create-a-test-report. If you know how to fix certain problems, you are more than welcome! Our resources are tiny and we can't possible fix all problems This topic is a place to discuss how certain problems/bugs can be solved. When reporting a bug, provide logs with: armbianmonitor -u Bugs: - serial gadget console is not working (anywhere?) - Pinebook doesn't boot properly - Mesa (OS Mali drivers are enabled by default) / WebGL works on Debian based Chromium, fails on Ubuntu I checked those: Orangepi PC2 http://ix.io/1s2c (hdmi, dvfs) @tkaiser SBCBENCH: http://ix.io/1s5d ( @hojnikb available frequency steps: 120 MHz, 240 MHz, 480 MHz, 648 MHz, 816 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz) Olinuxino A64 http://ix.io/1s2d (hdmi, dvfs, wireless, usb, battery) SBCBENCH: http://ix.io/1s5e tested battery charging/discharging Olimex Teres 1 A64 (hdmi, dvfs, wireless, usb, battery) http://ix.io/1tJg Orangepi Prime SBCBENCH: http://ix.io/1s5R (once "powered off" during benchmarking at 92C) Orangepi +2e SBCBENCH: http://ix.io/1s5T Orangepi Win SBCBENCH: http://ix.io/1s8c Cubietruck SBCBENCH: http://ix.io/1u3W OrangepiZero +2 H3 SBCBENCH: http://ix.io/1pqd Orangepi One H3 SBCBeNCH: http://ix.io/1psZ Orangepi Lite H3 http://ix.io/1u6R Nanopi Neo2 http://ix.io/1u4A (with NAS http://ix.io/1uUM) Orangepiplus http://ix.io/1u5H Orangepi Zero H2+ http://ix.io/1u9b Nanopi Air http://ix.io/1u9d With problems: Pinebook Confirmed working: Neo2 v1.1 512MB Neo2 v1.1 1GB Pine64 Orange Pi Zero Plus2 H5 Nanopi Duo http://ix.io/1uVC Orangepi R1 http://ix.io/1uaP Nanopi Neo Core 2 LTS Nano Pi Neo Plus2 Tritium H3 and H5 Orange Pi Zero Plus Bananapi M1 For now. BTW. Do you want to become a (Allwinner) board maintainer? Duties: - responsible for content at the download page, - running latests updates and managing bug list there.

There is no diff between OdroidC2 NEXT and meson64 next since the last update. Known problems: USB hot plugging and network initialisation on some C2 boards. I don't know if this latter happens on a stock 3.x kernel too. XU4 default 3.10.y could be also added to the EOS list. Maturity is unknown to me as well. Back then I did a basic adjustment and made few tests. Known problems and shortcomings: no HDMI, no DVFS, halt on reboot, ... modern u-boot support? Not sure if this will change anytime soon. We can drop 3.x and wait with mainline for a few months else drop C1 completely? Allwinner 3.4 and 3.10/Pinebook should stay in the system. There are many users and projects such as H3Droid and Retroorangepi are dependent from it. Even there is no more development and support. Even code quality is so so ... Since we started to talk about changing u-boot update from auto to manual, which should have bigger impact on support pressure, we can lower threshold for EOS on only most obvious ones.

Hello! Thanks for the note. It seems to be the same scenario... I'm still playing around with this Bionic and then I'll give a try to Debian stretch... I'll post here in case of success with Bionic or Deb-Stretch. Thanks and I'm still open for ideas for this armbian version recommended on Pinebook's own site... kuszi@pinebook:~$ cat /etc/os-release NAME="Ubuntu" VERSION="18.04.1 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.1 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic kuszi@pinebook:~$ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=pinebook-a64 BOARD_NAME="Pinebook A64" BOARDFAMILY=sun50iw1 VERSION=5.56 LINUXFAMILY=pine64 BRANCH=default ARCH=arm64 IMAGE_TYPE=stable BOARD_TYPE=conf INITRD_ARCH=arm KERNEL_IMAGE_TYPE=Image

Today I installed the nightly version of armbian stretch ( https://dl.armbian.com/pinebook-a64/nightly/Armbian_5.59.180830_Pinebook-a64_Debian_stretch_dev_4.18.5_desktop.7z ) on my Pinebook. After using it from MicroSD card it could be installed via armbian-config to eMMC (but I did swap the original 16GB FORESEE to a 32GB SanDIsk - did buy the 32GB from Pine with my Pinebook) Seems to work - but the Wifi has on every boot a new MAC-Adress, so nmtui (Network-Manager) has many configs for the WiFi

Hello! I'm testing Armbian now on Pinebook from SD I usually used the xenial - mate image with newly replaced emmc (64GB) with 0.7.19. My problem is the graphical performance and that x2go remote sessions are glitched. So, I'm now on Armbian and the problem is the same as with xenial-mate pre-0.7.19 - it can't see the internal emmc. Could Armbian use the new emmc? Not the factory 16GB.... I tried to remember, this is maybe 5.1 or what version for what 0.7.19 was patched to work with? I'd like to use Armbian from emmc finally, but now I'm even not able to reach my files on that as it is not appearing under /dev/mmc..... Thanks for any help. Robert

I started with this 'zram on SBC' journey more than 2 years ago, testing with GUI use cases on PineBook, searching for other use cases that require huge amounts of memory, testing with old as well as brand new kernel versions and ending up with huge compile jobs as an example where heavy DRAM overcommitment is possible and zram shows its strengths. Days of work, zero help/contributions by others until recently (see @botfap contribution in the other thread). Now that as an result of this work a new default is set additional time is needed to discuss about feelings and believes? Really impressive... Care to elaborate what I did wrong when always running exactly the same set of 'monitoring' with each test (using a pretty lightweight 'iostat 1800' call which simply queries the kernel's counters and displays some numbers every 30 minutes)? Why should opinions matter if there's no reasoning provided? I'm happy to learn how and what I could test/modify again since when starting with this zram journey and GUI apps I had no way to measure different settings since everything is just 'feeling' (with zram and massive overcommitment you can open 10 more browsers tabs without the system becoming unresponsive which is not news anyway but simply as expected). So I ended up with one huge compile job as worst case test scenario. I'm happy to learn in which situations with zram only a vm.swappiness value higher than 60 results in lower performance or problems. We're talking about Armbian's new defaults: that's zram only without any other swap file mechanism on physical storage active. If users want to add additional swap space they're responsible for tuning their system on their own (and hopefully know about zswap which seems to me the way better alternative in such scenarios) so now it's really just about 'zram only'. I'm not interested in 'everyone will tell you' stories or 'in theory this should happen' but real experiences. See the reason why we switched back to lzo as default also for zram even if everyone on the Internet tells you that would be stupid and lz4 always the better option.

Sorry, I don't find the time to answer to all of this stuff in detail. My opinion on Pinebook and A64 in general: EOS for more than one reason. Also you seem to miss that I used A64 legacy kernel as an example where one developer at least took the time to rebase the vendor BSP mess on top of an outdated mainline kernel version so at least it was possible to get an idea what Allwinner changed where. A64 devices are toys, the majority of users who play with them doesn't care about security anyway. Same could be said about H3 and I really wonder why you don't get how things changed over time. At the end of 2015 Armbian supported just a few boards, H3 devices looked somewhat promising based on features and costs. Back then we took another Allwinner BSP and simply added the missing 3.4.x patches on top (and at the same time few of us already started to use H3 with mainline kernel). To be clear: THIS WAS A MISTAKE (as could be seen just a few months later --> rootmydevice). Why should we repeat mistakes? Since we're totally stupid? Or just too dumb to learn from mistakes? Seriously? Are you able to spot the difference between Rockchip's 4.4 BSP kernel that is based on a clean Linux mainline version (see the +609,000 commits) and RealTek's code drop that is now available without any history? The difference between Rockchip as one the few ARM vendors who learned some lessons pretty fast and became open source friendly while there's nothing (especially zero experiences) now with RealTek? And you talk about standards and 'double standards'? As in 'now we need to support this new platform since board vendor did what he had to do anyway'. Yeah! Sure, let's add more SoC families to Armbian. That's what is truly needed. More boards, less quality. But hey, since this projects suffers from total lack of agreed project goals such useless babbling will happen over and over again. I have no idea why we currently support way too much boards we can handle and why constantly new stuff that requires enormous efforts should be added and why are talking about stuff like this anyway.

IMO push them to open the repo immediately only to tell them after its: well no mainline no armbian is a bit.... questionable. You knew exactly before that there won't be a mainline kernel, you knew that the only efforts in mainlining the SoC is done by Andreas Färber and not Realtek and that he as a 'lone survivor' will probably not be ready to deliver a mainline (based) linux soon. Assuming you would be a copyright holder (for parts of the kernel) and we take https://github.com/torvalds/linux/blob/master/Documentation/process/kernel-enforcement-statement.rst as a baseline for 'being good' (at least a bunch of kernel developers signed it) you informed them on September 4th that they have a GPL violation and on September 19th they released the sources (15 days). Assuming you're the first one who noticed the GPL violation, the majority of the kernel developers would agree that they act as they should. For sure someone more experienced in kernel-development and bsp kernel-quality would have to check it first. But as said a full check of the BSP kernelsources was (until yet) never a prerequisite for provide Armbian with BSP-kernels. It's also obvious that this SoC is far away from mainline support and that some of the interesting features will probably never run in mainline (e.g. the whole encoding and decoding stuff cause it is partly, as far as I understand, behind some blobs e.g. 'bluecore.audio'). But as an other example, pinebook is marked as 'supported'. 3.10 got EOL a year ago (and was likely never fully reviewed too) and mainline has (as far as I know) issues with the PMIC (which will be important for a 'notebook') and only marked as beta. By those standards Pinebook should go back to wip or CSC. I completely agree that at least a headless usable mainline based linux should be available before we start to support a new SoC. I also agree that support SoCs which have only one available board is questionable (the efforts maintaining just a new set of kernels BSP/Mainline is just too much for one board - expect the MT7623 for which I might prepare a PR as soon as we reach the next LTS kernel, it works without major issues on mainline without patching, so it's only an adjustment of the config file, something I think isn't that much work I may write a THS patch cause those settings are IMO a bit conservative). But a full check of the BSP kernel as prerequisite is IMO double standard - we didn't do it for any BSP kernel in the past and this should be IMO discussed in the developer subforum first before we define it as a new standard - in this case we had to drop a bunch of 'suggested' images from the download page (e.g. RK3399, RK3328 Rock64/Renegade, A64 Pine64 et al, ). For all those boards we suggest to use the BSP kernel..

oh, play few week with this case and old kernel, change uboot to BOOTBRANCH='branch:pinebook-wip-20180909', and no any fs_devread read error for 20 startup.

need help )) .. resolved with BOOTBRANCH='branch:pinebook-wip-20180909', i has orange pi win plus, serial date at sticker 20170509 when i build with default kernel v3.10.107 - my board always boot OK when i build with next or dev kernel - uboot stops in 30-60%. always ** fs_devread read error **" in console. https://pastebin.com/prwdGXtS (error - always different !!!) i change 3 SD card, used 4A PSU, usb tester in USB and watt metter at input. so, i want ask. 1) someone else had a fs_devread read error problem with next or dev kernel ? perhaps just my orange isn't compatible with the new UBOOT. 2) sorry for my illiteracy, can I combine the stock uboot with dev or next kernel apt install ./linux-image-pine64_5.59_arm64.deb at dev kernel - not work. 3) how to enable DEBUG for uboot ? i want see more debug info in console. message like debug(" <" LBAFU ", %d, %d>\n", sector, byte_offset, byte_len); but armbian stop compile SPL I didn't find anything else, and use userpatch for add DEBUG in /include/log.h diff --git a/include/log.h b/include/log.h --- a/include/log.h +++ b/include/log.h @@ -130,7 +130,7 @@ */ #define debug_cond(cond, fmt, args...) \ do { \ - if (cond) \ + if (1) \ printf(pr_fmt(fmt), ##args); \ } while (0) and get this error on dev uboot: CC spl/lib/rand.o CC spl/lib/strto.o LD spl/lib/built-in.o LD spl/u-boot-spl /home/peter/armbian4/cache/toolchains/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld.bfd: u-boot-spl section `.rodata' will not fit in region `.sram' /home/peter/armbian4/cache/toolchains/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-ld.bfd: region `.sram' overflowed by 1192 bytes scripts/Makefile.spl:353: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 1 Makefile:1507: recipe for target 'spl/u-boot-spl' failed make: *** [spl/u-boot-spl] Error 2 [ error ] ERROR in function compile_uboot [ compilation.sh:173 ] [ error ] U-boot compilation failed [ o.k. ] Process terminated

I didnt know that this I2C-Temperature is from the PMIC - so I will live without a real temperature. Some people - like me - may think they would try to help and get some infos out of the system (not only on this SBC) for supporting armbian or other people on the forum. But it seems we doesnt know to less I think the most people do try to find a way, but we didnt got the sytsem-overview like you. Igor may build the image, because he has already a M2 Ultra (like I have a M2 Berry) - and if he find the time - he would also see the board at his home running armbian. And this board is not nailed to kernel 3.10 (like the Pinebook the most time). OK the M2 Ultra/Berry are not the newest, but their time can come - here or anywhere on the net. Old SBCs like Marvell on the SheevaPlug and BeagleBoard Black are also running newer systems without problems. And for many people they are not a waste of time. Other people will concentrate their development to more common systems/CPUs - thats OK. I think we should have both type of people and they all should have fun with their systems