I just got my Pinea64 2gb a few days ago and have been trying to get android TV to boot on it. I was able to get the official Ubuntu mate image to work so I know the board isn't bad. I have tried android tv 5.1.1, 6.0, and 7.0. All that happens when I plug it in and turn it on is the screen I'm using (both 1080p one is a large TV and one is a computer monitor, both are using straight HDMI) turns orange and after 10-15 seconds goes black and comes back as orange for 3 minutes before restarting again. Any ideas?
I would like to make an car amplifier extension board. Can anyone suggest me about the following topics:
- Volume adjustment (volume can be adjusted over I2C, what is the best way, adjusting volume of analog output of pine64 or tas524C)
- Audio input, there are four channels, pine64 has only 2 ch output. How can I do it?
- Fault, Mute, standby, clip_otw, is it necessary to use these pins with Pine?
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.
Posted by: Learnincurve - 02-06-2017, 02:30 AM - Forum: Armbian
- No Replies
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
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).
(I'm assuming this should also be in input-raw.c)
If I look at my own input-raw.c, I see:
Code:
static int check_fd(struct tslib_input *i)
{
struct tsdev *ts = i->module.dev;
int version;
long evbit[BITS_TO_LONGS(EV_CNT)];
long absbit[BITS_TO_LONGS(ABS_CNT)];
long keybit[BITS_TO_LONGS(KEY_CNT)];
long synbit[BITS_TO_LONGS(SYN_CNT)];
if (ioctl(ts->fd, EVIOCGVERSION, &version) < 0) {
fprintf(stderr, "tslib: Selected device is not a Linux input event device\n");
return -1;
}
/* support version EV_VERSION 0x010000 and 0x010001
* this check causes more troubles than it solves here */
if (version < EV_VERSION)
fprintf(stderr, "tslib: Warning: Selected device uses a different version of the event protocol than tslib was compiled for\n");
if ( (ioctl(ts->fd, EVIOCGBIT(0, sizeof(evbit)), evbit) < 0) ||
!(evbit[BIT_WORD(EV_ABS)] & BIT_MASK(EV_ABS)) ||
!(evbit[BIT_WORD(EV_KEY)] & BIT_MASK(EV_KEY)) ) {
fprintf(stderr, "tslib: Selected device is not a touchscreen (must support ABS and KEY event types)\n");
return -1;
}
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))) {
if (!(absbit[BIT_WORD(ABS_MT_POSITION_X)] & BIT_MASK(ABS_MT_POSITION_X)) ||
!(absbit[BIT_WORD(ABS_MT_POSITION_Y)] & BIT_MASK(ABS_MT_POSITION_Y))) {
fprintf(stderr, "tslib: Selected device is not a touchscreen (must support ABS_X/Y or ABS_MT_POSITION_X/Y events)\n");
return -1;
}
}
/* Since some touchscreens (eg. infrared) physically can't measure pressure,
* the input system doesn't report it on those. Tslib relies on pressure, thus
* we set it to constant 255. It's still controlled by BTN_TOUCH/BTN_LEFT -
* when not touched, the pressure is forced to 0. */
if (!(absbit[BIT_WORD(ABS_PRESSURE)] & BIT_MASK(ABS_PRESSURE)))
i->no_pressure = 1;
if ((ioctl(ts->fd, EVIOCGBIT(EV_KEY, sizeof(keybit)), keybit) < 0) ||
!(keybit[BIT_WORD(BTN_TOUCH)] & BIT_MASK(BTN_TOUCH) ||
keybit[BIT_WORD(BTN_LEFT)] & BIT_MASK(BTN_LEFT))) {
fprintf(stderr, "tslib: Selected device is not a touchscreen (must support BTN_TOUCH or BTN_LEFT events)\n");
return -1;
}
/* Remember whether we have a multitouch device. We need to know for ABS_X,
* ABS_Y and ABS_PRESSURE data. */
if ((absbit[BIT_WORD(ABS_MT_POSITION_X)] & BIT_MASK(ABS_MT_POSITION_X)) &&
(absbit[BIT_WORD(ABS_MT_POSITION_Y)] & BIT_MASK(ABS_MT_POSITION_Y)))
i->mt = 1;
/* remember if we have a device that doesn't support pressure. We have to
* set pressure ourselves in this case. */
if (i->mt && !(absbit[BIT_WORD(ABS_MT_PRESSURE)] & BIT_MASK(ABS_MT_PRESSURE)))
i->no_pressure = 1;
if (evbit[BIT_WORD(EV_SYN)] & BIT_MASK(EV_SYN))
i->using_syn = 1;
/* remember whether we have a multitouch type A device */
if (i->mt && synbit[BIT_WORD(SYN_MT_REPORT)] & BIT_MASK(SYN_MT_REPORT) &&
!(absbit[BIT_WORD(ABS_MT_SLOT)] & BIT_MASK(ABS_MT_SLOT)))
i->type_a = 1;
if (i->grab_events == GRAB_EVENTS_WANTED) {
if (ioctl(ts->fd, EVIOCGRAB, (void *)1)) {
fprintf(stderr, "tslib: Unable to grab selected input device\n");
return -1;
}
i->grab_events = GRAB_EVENTS_ACTIVE;
}
# 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)
Can anyone point me in the right direction to getting the device calibrated?
I figure that if I (with help) can get this working, it might be an excellent and cheap squeezebox touch alternative.
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.
