i really appreciate what ayufan is doing. but i'd really prefer doing it myself.


is there anywhere i could find good tutorials for how to put an android release together?

Is it safe to use 5.25V with 2A for Pine64+ ?
A64 - DB - 2G - Rev B
2016-03-21

Would it be possible for a 3rd party to create a better module?

I believe with the SDIO interface, it should be possible to implement a Broadcom BCM4356 (which supports SDIO v3.0 for WiFi and GPIO for BT4.0), and achieve WiFi speeds up to 867Mbps (not to mention this chip has a built-in FM receiver, which could also be used).

Also I understand that this would raise prices for such a wireless module, but for many, it would be a better choice (especially as there's no PCIe or USB3.0 port onboard). I just feel like 150Mbps is quite limited for such a versatile device.

Hi there,
I get it installed and up running with Debian. It was continuously on for several days, with some pauses when I shut it down. Then I moved with it to our second home and there i did not get it up anymore. I noted that it did something and got through some initial steps, but then it shut down itself. Now does not even show any signs of activity. When plugged in the red led is on, but no signs of activity. I checked the micro SD card and it seems OK as far as I can see. Any ideas where to start looking for a solution.
Regards Björn

The microsd card and my Pine A64 2GB becomes corrupted after a reboot, shutdown or power outage, which in turn leads to various bugs or renders the system unbootable, even after repairing the card using fsck.

Could anyone please tell me if this could be related to the microsd card brand(it is a fast Kingston model) or if it means my Pine A64 is defective and good to go to the trash can.

This problem occurs on all Pine A64 images I've tried: ubuntu, android and debian.

Thank you in advance.

Hi,

  I bought a Pine64+ board and screen, with a view to using it as a Squeezebox Touch replacement through a USB dac. The board ticks a lot of the hardware boxes for a Squeezebox Touch, with dedicated ethernet and USB ports/busses.

Armbian runs out of the box and supports the touchscreen - at least with legacy 3.10.104 kernel. With mainline kernel (4.10 at time of writing) touchscreen support is available through the generic "goodix" module, but this requires some extra configuration.  I have not yet evaluated the mainline kernel's readiness to run the system that I have in mind.

Using Armbian legacy  (3.10.104), I have installed the packaged Squeezelite from the Armbian repository and Jivelite compiles and runs without errors using

https://github.com/sindrom91/LuaJIT/tree/ARM64

Athough touch events work perfectly in Xfce, they are "all over the place" in Jivelite, so I'm trying to create a tslib/SDL calibration.


Just now I'm struggling with
"tslib: Selected device is not a touchscreen (must support ABS and KEY event types)"

Googling throws up one or two bits of advice, such as:

From http://http://www.cubieforums.com/index....v.html#new:

Quote:Check if input-raw.c has:
    if ((ioctl(ts->fd, EVIOCGBIT(EV_ABS, sizeof(absbit)), absbit)) < 0 ||
       !(absbit[BIT_WORD(ABS_X)] & BIT_MASK(ABS_X)) ||
       !(absbit[BIT_WORD(ABS_Y)] & BIT_MASK(ABS_Y))) {
      /*fprintf(stderr, "tslib: Selected device is not a touchscreen (must support ABS_X and ABS_Y events)\n");
      return -1;*/
    }

if not, edit the file and comment the lines."

Quote:Try to add

input_dev = input_allocate_device();
[..]
set_bit(EV_ABS, input_dev->evbit);
set_bit(EV_KEY, input_dev->evbit);
So that the tslib sees the device as supporting both EV_ABS and EV_KEY events (even if it does not actually send both of those).

• TS_INFO_FILE=/sys/devices/virtual/input/input6/uevent:
        I: Bus=0018 Vendor=dead Product=beef Version=28bb
          N: Name="gt9xxf_ts"
          P: Phys=input/goodix-ts
          S: Sysfs=/devices/virtual/input/input6
          U: Uniq=
          H: Handlers=event5 autohotplug cpufreq_interactive 
          B: PROP=2
          B: EV=b
          B: KEY=400 0 0 0 0 0
          B: ABS=265000000000000
  
• # evtest /dev/input/event5
          Input driver version is 1.0.1
          Input device ID: bus 0x18 vendor 0xdead product 0xbeef version 0x28bb
          Input device name: "gt9xxf_ts"
          Supported events:
          Event type 0 (EV_SYN)
          Event type 1 (EV_KEY)
              Event code 330 (BTN_TOUCH)
          Event type 3 (EV_ABS)
              Event code 48 (ABS_MT_TOUCH_MAJOR)
                  Value      0
                  Min        0
                  Max      255
              Event code 50 (ABS_MT_WIDTH_MAJOR)
                  Value      0
                  Min        0
                  Max      255
              Event code 53 (ABS_MT_POSITION_X)
                  Value      0
                  Min        0
                  Max     1024
              Event code 54 (ABS_MT_POSITION_Y)
                  Value      0
                  Min        0
                  Max      600
              Event code 57 (ABS_MT_TRACKING_ID)
                  Value      0
                  Min        0
                  Max      255
          Properties:
              Property type 1 (INPUT_PROP_DIRECT)
  

I have been having a heck of a time trying to get 2 Pine64s to work on the same LAN. 

Router - Verizon ActionTec - I know, I know.  It sucks.

Pine64 1
Hostname: Pine64Server2
Static IP: 192.168.1.100
OS: Ubuntu headless

This works fine.  When I first plug it in after flashing the OS, it comes up as just an address (like 192.168.1.8) or I think it used to come up as "Pine64." I change the hostname (and hosts) and set the static IP and it works great. 

Here's where things get wonky.  When I try to add a second Pine64, flashed with the same OS, two things happen (or don't happen):
Pine 64 2
Hostname: Pine64 (default)
IP: DHCP
OS: Ubuntu headless

When I look on the router, suddenly my original Pine64 at 192.168.1.100 is named "Pine64" and I can't see the new Pine64 listed on the router and I can't Putty into it.

Am I doing something wrong?

Thanks

How is the battery Supposed to be mounted in the PlayBox enclosure?

I figured out the rest, but the battery seems to be a mystery. It doesn't fit under the extra panel that mounts on the side of the case opposite the card. Is supposed to be slid under and held in place by the board itself? Double sided taped to that panel?

Any suggestions?

with an extension cable  and a simple goggle mount for the lcd
a sensor set (gyro-meter, 3 axis accelerometer, etc etc).

then produce a stereoscopic view. and you have a VR system which costs 1/8th of the next least expensive option

you could 3d print the goggles but they probably wouldnt be super comfy ... should have counterweights opposite the screen to keep it from wanting to tilt forward 

anyway to make a goggle harness that holds the lcd screen + an extension 40pin cable) should cost very little, infact you could mount the pine64 and battery behind the head, for a single helmet unit, putting 2 batteries in series would allow 1 to be hot swap-able.

Yeah If I put a module of SOPINE in a standard motherboard, would it work as a processor/RAM? I'd like to put 8 of them in a server motherboard