| Welcome, Guest |
You have to register before you can post on our site.
|
| Latest Threads |
Pinebuds volume in each e...
Forum: General
Last Post: CaptSpify
8 hours ago
» Replies: 0
» Views: 12
|
Unable to switch from Was...
Forum: General Discussion on PineTime
Last Post: Bruce Kissinger
9 hours ago
» Replies: 0
» Views: 8
|
Searching for a PinePhone...
Forum: PinePhone Accessories
Last Post: RubiksCube
Yesterday, 12:35 PM
» Replies: 0
» Views: 31
|
PinePhone Beta Edition wi...
Forum: Manjaro on PinePhone
Last Post: spazz
Yesterday, 05:55 AM
» Replies: 9
» Views: 8,324
|
Unable to use umlaut key ...
Forum: General Discussion on Pinebook Pro
Last Post: ili
10-01-2024, 01:36 PM
» Replies: 2
» Views: 89
|
Shipping Update and Stock...
Forum: News
Last Post: tllim
10-01-2024, 11:05 AM
» Replies: 89
» Views: 105,514
|
Ethical sourcing practice...
Forum: General
Last Post: cinnabarwinner
09-30-2024, 07:19 PM
» Replies: 2
» Views: 419
|
FIXED-Newer ver of EC25 M...
Forum: PinePhone Hardware
Last Post: DarciFoxe
09-30-2024, 02:08 PM
» Replies: 3
» Views: 294
|
Star64: GPU firmware load...
Forum: Getting Started
Last Post: Marco2024
09-30-2024, 02:49 AM
» Replies: 14
» Views: 6,647
|
Troubleshooting Pinedio L...
Forum: PinePhone Accessories
Last Post: lavabrilliant
09-29-2024, 09:17 PM
» Replies: 2
» Views: 519
|
|
|
| Unusual streaming slowdown |
|
Posted by: Khat0varBrewMoth - 09-18-2016, 11:29 PM - Forum: Getting Started
- Replies (5)
|
 |
Hi there,
I am running 2GB version on Android. This was initially working at great speed.
Now I'm experiencing problems streaming online content (using catch up TV apps) as well as things from NAS on local network using Kodi. Streaming videos buffer really slow over wifi and wired ethernet connection. Seems to be a problem with the Pine64 rather than network issue.
Can anyone point me to a way to get some logs for more specific help here?
Cheers
|
|
|
|
| Enocean on Android |
|
Posted by: ltorsini - 09-18-2016, 09:55 PM - Forum: Android on Pine A64(+)
- No Replies
|
 |
All-
Looking to integrate the Enocean USB 300U radio on Android to use their IoT kit. Before we start working I wanted to check that no one else is/has already successfully integrated the FTDI drivers on the Android image?
Thanks!
|
|
|
|
| Nexdock with Pine64 running RemixOS |
|
Posted by: bartvvr - 09-18-2016, 02:33 PM - Forum: Accessories
- Replies (4)
|
|
I received a Nexdock which is basically a display and a bluetooth keybord. The idea is that with Nexdock you can turn your Pine64 into a laptop.
https://www.indiegogo.com/projects/nexdo.../2028259#/
I'm running RemixOS 2.0 on my Pine64 2GB but I can't change the output resolution of the Pine64 to 1366x768.
1366x718 is the native resolution of the Nexdock.
Nexdock works together with Pine64, but all text is hard to read because of the wrong display setting.
Any solution or Remix OS update to fix this issue?
Thanks, Bart
|
|
|
|
| Tutorial: How to create DD images with appropriate size |
|
Posted by: tkaiser - 09-18-2016, 09:55 AM - Forum: Android on Pine A64(+)
- Replies (5)
|
|
This mini tutorial is meant for those people providing Android or RemixOS 'DD images'. The DD images currently provided have been created wrong (too large for many SD cards out there). Fortunately it's easy to do it better. Since we're talking here about SBC why not stop wasting time on both creator's and user's side, using an SBC in USB gadget mode, create images with appropriate size and speed up things?
The whole process would work with any Pine64/Pine64+ too but since AFAIK no OS image is around that uses a correctly configured kernel enabling the necessary g_mass_storage module and since a small patch might be necessary to get this working with BSP kernel (can't test right now since ran out of Pine64) we discuss this with H3 devices instead (H3 is A64's little sibling). Ingredients:
- Any H3 device from this list: http://www.armbian.com/download/
- A short USB-to-Micro-USB cable (or type A to type A when choosing the Beelink X2 or Pine64 later)
- An Armbian image for the device in question using legacy kernel since we need USB OTG support
- A 120 GB disk to store the images with 7.8, 15.8, 31.8 and 63.8 GB size (or a 250 disk when both Android and RemixOS images should be stored on the same disk)
I would choose the cheapest device possible: Orange Pi One powered through the barrel plug and establishing the USB OTG connection through the Micro USB port.
1) Prepare the disk
Connect the USB device to OPi One, the H3 board to your Windows machine, then do on the Linux box:
Code: modprobe g_mass_storage file=/dev/sda
echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
This will hand the whole device as an USB disk to your Windows PC. Since I don't own such thing (only virtualized Windows servers) in the following I will show how it looks like when the SBC is connected to a Mac. You can now use disk utility (no idea how that's called in Windows) to partition the disk that is physically connected to the SBC in reality. I created the necessary partitions in OS X that are all small enough to fit on any SD card later. Now in OS X it looks like this:
Code: macbookpro-tk:~ tk$ diskutil list
...
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *128.0 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS Ohne Titel 1 7.8 GB disk2s2
3: Apple_HFS Ohne Titel 2 15.8 GB disk2s3
4: Apple_HFS Ohne Titel 3 31.8 GB disk2s4
5: Apple_HFS Ohne Titel 4 63.8 GB disk2s5
6: Apple_HFS Ohne Titel 5 8.9 GB disk2s6
And on the SBC itself in Linux it looks like this:
Code: root@orangepiplus2e:~# cat /proc/partitions
major minor #blocks name
179 0 15267840 mmcblk0
179 1 15114128 mmcblk0p1
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
8 0 125034840 sda
8 1 204800 sda1
8 2 7617188 sda2
8 3 15253392 sda3
8 4 30957032 sda4
8 5 61658076 sda5
8 6 8688952 sda6
So we created 4 partitions that we will then feed to PhoenixCard in the next steps. Time to eject/unmount the partitions from Windows (or OS X in my case) and then remove the device back in Linux (we switch first to USB host mode which is the equivalent of disconnecting a real USB disk physically and will then unload the driver since we will use it in the next step not with /dev/sda but the individual partitions instead):
Code: echo 0 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
rmmod g_mass_storage
2) Provide the partitions as devices starting with 7.8 GB in size
In Linux /dev/sda2 is 7.8 GB in size so now we hand only this partition out to Windows (or in my case OS X):
Code: modprobe g_mass_storage file=/dev/sda2
echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role
And instantly on the connected PC a new USB device appears that's just 7.8 GB in size:
Code: macbookpro-tk:~ tk$ diskutil list
...
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: Ohne Titel 1 *7.8 GB disk2
3) Let PhoenixCard do the work
Now start PhoenixCard and point it to this virtualized 'USB thumb drive'. PhoenixCard will create a bunch of new Android/Linux partitions on /dev/disk2 (/dev/sda2 on Linux) and use the maximum disk space available (7.8 GB in our case). That's the whole trick: Creating a partition small enough to fit on any SD card later, let PhoenixCard use this partition as device and create its own partitions on this. 
4) Create the DD image on Linux
Eject/unmount the virtual USB thumb drive in Windows, mount the next one to create the 16GB version and while PhoenixCard does its job in Windows create a new device image on the SBC that will be way smaller than the images Pine64 folks provide now. The most important thing here is that we create a device image by using a partition. Now /dev/sda2 on Linux contains a bunch of partitions and therefore we use
Code: dd if=/dev/sda2 bs=10M | 7zr a -bd -t7z -m0=lzma -mx=3 -mfb=64 -md=32m -ms=on -si Android-8GB.img.7z
For the 16GB variant it would look like this (and so on):
Code: dd if=/dev/sda3 bs=10M | 7zr a -bd -t7z -m0=lzma -mx=3 -mfb=64 -md=32m -ms=on -si Android-16GB.img.7z
(I think Armbian doesn't ship with 7-zip so an 'sudo apt-get install p7zip' would be required before). This way you get pretty small DD images while PhoenixCard is already preparing the next image on the Windows host.
5) Tell your users to use appropriate tools and what's important.
When you put the compressed images online then provide GOOD documentation how to burn images correctly. Don't recommend tools that suck, it's 2016 and burning tools that verify the burning process do exist, for Android and RemixOS images it's VERY IMPORTANT that users choose SD cards that show high random IO performance. Everything is outlined here: http://docs.armbian.com/User-Guide_Getti...-a-sd-card
|
|
|
|
| Cannot DD on 16 GB SD |
|
Posted by: Sethlans - 09-18-2016, 07:34 AM - Forum: Android on Pine A64(+)
- Replies (3)
|
|
Hello everybody.
I have kingston 16GB claa 10 SD card. I have downloaded the 16 GB android image but when i try to DD the image on the SD I havn't enough space on the SD.
I have also tryed with Win32Imager but I have the same problem.
How can i solve?
|
|
|
|
| Power LED Heartbeat script |
|
Posted by: pfeerick - 09-18-2016, 05:16 AM - Forum: Pi2, Euler and Exp GPIO Ports
- Replies (3)
|
 |
Just thought I'd post the current version of the shell script I am using on my Pine64 to make the user controllable System LED (the one that you can attach near the headphones jack, or via the EXP header). I added it to /etc/rc.local (make sure you put an " & " at the end, so it doesn't block rc.local continuing / exiting), so now every time the pine64 starts up, I get a little heartbeat indicator going so I know it's running ok. Since it's a gist, you can also download it via wget or curl... just copy the URL you get from the 'raw' button up the top right.
Next step will be working out how to intercept the power button... perhaps via udev, since that already responds to the power button interrupt, but doesn't know what to do with it out of the box.
https://gist.github.com/pfeerick/00b04df...b4e1f7c168
|
|
|
|
| Fixing GPIO user permission errors |
|
Posted by: pfeerick - 09-18-2016, 04:54 AM - Forum: Pi2, Euler and Exp GPIO Ports
- No Replies
|
|
A known issue from Raspberry Pi land that also effects the Pine64 is the need to use sudo in order to manipulate GPIO bits... which gets annoying pretty quickly... and tempts you to stay logged in as the root user, which is a bad idea.
There are some workarounds... i.e. using python GPIO, wiringPi (when available). But there is also a relatively simple fix you can apply in order to fix it up, which is to basically add two startup scripts that automatically fix the permissions. I've just run through this myself, and had to backtrack and check what I'd done, so please let me know if there are any mistakes or corrections needed. So... here we go!
Create a gpio group first:
Then add your username to that group:
Code: usermod -a -G gpio username
To check that everything is good so far, you can run the below command, and you should see a line that looks a bit like "gpio:x:1001:pfeerick" (last bit should be your user name).
Code: grep gpio /etc/group
Now, before that change to groups takes effect, you will need to log out of your current session. If you really, really don't want to, you may be able to run "newgrp gpio"... but YMMV.
Now, the final bit is to fix up the permissions of the sysfs GPIO file system. There are two bits that needs to be fixed - the export and unexport 'files' and the actual GPIO 'folders'
For the first bit, it is probably simplest to just add the two following lines to the bottom of (before the exit 0 line), although it may be better to put it in a separate script for neatness. They needed to be run at every startup as /sys is a virtual file system, and is created every time the pine64 is booted, so doesn't remember the permission changes.
Code: chown -R root:gpio /sys/class/gpio
chmod -R ug+rw /sys/class/gpio
At this point, when you restart your pine64, you will be able to export and unexport GPIO pins without needing sudo. And if you don't want to restart, you can just run those commands now at the command prompt. But that is only half the story... we also need to fix the GPIO 'folders' , which have the direction and value 'files''. So, next, run the below command and create following udev rule:
Code: sudo nano /etc/udev/rules.d/80-gpio-noroot.rules
Code: # /etc/udev/rules.d/80-gpio-noroot.rules
# Corrects sys GPIO permissions on the Pine64 so non-root users in the gpio group can manipulate bits
#
# Change group to gpio
SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/soc.0/*pinctrl/gpio'"
# Change user permissions to ensure user and group have read/write permissions
SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/soc.0/*pinctrl/gpio'"
This monitors the GPIO file system and makes the permission changes as needed.
To avoid needing to reboot to run this new file, just run:
Code: sudo udevadm trigger --subsystem-match=gpio
Everything should work great now!
Concept based on https://www.raspberrypi.org/forums/viewt...6&t=118879
|
|
|
|
|
![[Image: QDyQiQp.jpg]](http://i.imgur.com/QDyQiQp.jpg)