I haven’t been able to use the software store in a couple weeks now. Crashes as soon as I go to updates or try to search categories for apps. I see people talking about this megapixels app that was apparently included in the nightly build a couple nights ago but it’s not on my phone. Does updating from CLI not update the OS as well? That’s the only way I have been able to get any updates
I de-soldered the ethernet port so that it would fit in the pine64 aluminum case.
I flashed a fresh copy of armbian onto an emmc module and booted. I built and installed musikcube and tried every one of the alsa audio devices available, but I get no sound out of the dac. Any suggestions?
Code:
cbrown@rock64:~$ aplay -L
default
Playback/recording through the PulseAudio sound server
null
Discard all samples (playback) or generate zero samples (capture)
pulse
PulseAudio Sound Server
sysdefault:CARD=rockchiprk3328
rockchip,rk3328, ff000000.i2s-i2s-hifi i2s-hifi-0
Default Audio Device
dmix:CARD=rockchiprk3328,DEV=0
rockchip,rk3328, ff000000.i2s-i2s-hifi i2s-hifi-0
Direct sample mixing device
dmix:CARD=rockchiprk3328,DEV=1
rockchip,rk3328, ff010000.i2s-rk3328-hifi ff410000.codec-1
Direct sample mixing device
dmix:CARD=rockchiprk3328,DEV=2
rockchip,rk3328, ff030000.spdif-dit-hifi dit-hifi-2
Direct sample mixing device
dsnoop:CARD=rockchiprk3328,DEV=0
rockchip,rk3328, ff000000.i2s-i2s-hifi i2s-hifi-0
Direct sample snooping device
dsnoop:CARD=rockchiprk3328,DEV=1
rockchip,rk3328, ff010000.i2s-rk3328-hifi ff410000.codec-1
Direct sample snooping device
dsnoop:CARD=rockchiprk3328,DEV=2
rockchip,rk3328, ff030000.spdif-dit-hifi dit-hifi-2
Direct sample snooping device
hw:CARD=rockchiprk3328,DEV=0
rockchip,rk3328, ff000000.i2s-i2s-hifi i2s-hifi-0
Direct hardware device without any conversions
hw:CARD=rockchiprk3328,DEV=1
rockchip,rk3328, ff010000.i2s-rk3328-hifi ff410000.codec-1
Direct hardware device without any conversions
hw:CARD=rockchiprk3328,DEV=2
rockchip,rk3328, ff030000.spdif-dit-hifi dit-hifi-2
Direct hardware device without any conversions
plughw:CARD=rockchiprk3328,DEV=0
rockchip,rk3328, ff000000.i2s-i2s-hifi i2s-hifi-0
Hardware device with all software conversions
plughw:CARD=rockchiprk3328,DEV=1
rockchip,rk3328, ff010000.i2s-rk3328-hifi ff410000.codec-1
Hardware device with all software conversions
plughw:CARD=rockchiprk3328,DEV=2
rockchip,rk3328, ff030000.spdif-dit-hifi dit-hifi-2
Hardware device with all software conversions
cbrown@rock64:~$
The serial port on the RPi header has a baud of 1,500,000. This is fine for most tools, but some are capped at the values present in the baud tables in various places in the Linux kernel and other utilities.
How do I change the baud to 460800? I've found the uarts in rk3399.dtsi in the kernel tree, but am unsure how their clocks are actually generated.
As expected software seems unable to change the speed of the serial port.
Hey all, I created some Docker images to make cross-compiling for Linux arm64 easy. I've successfully used my Macbook Pro to compile software for my Pinebook Pro, and it was quite a bit faster than compiling on the PBP itself. Thought others might find the project useful, but I'm also looking for testers.
The following instructions assume you have a PBP and a non-PBP running on the same LAN, and that the non-PBP has docker installed.
If compiling for Manjaro, run this on your non-PBP:
Code:
docker run -p 3708:3708 elijahru/distcc-cross-compiler-host-archlinux:latest-amd64
If compiling for Debian, run this on your non-PBP:
Code:
docker run -p 3608:3608 elijahru/distcc-cross-compiler-host-debian-buster:latest-amd64
On your PBP, install distcc via pacman or apt and update your PATH so that the distcc wrappers for gcc, g++, etc are found first.
Run this on your Manjaro PBP (assuming you use bash):
Code:
sudo pacman -S distcc
echo 'export PATH=/usr/lib/distcc/bin:$PATH' >> ~/.bash_profile
# Replace X.Y.Z with the LAN IP address or hostname of your non-PBP
echo 'export DISTCC_HOSTS=X.Y.Z:3708' >> ~/.bash_profile
source ~/.bash_profile
Or run this on your Debian PBP:
Code:
sudo apt-get install distcc
echo 'export PATH=/usr/lib/distcc:$PATH' >> ~/.bash_profile
# Replace X.Y.Z with the LAN IP address or hostname of your non-PBP
echo 'export DISTCC_HOSTS=X.Y.Z:3608' >> ~/.bash_profile
source ~/.bash_profile
Confirm that the executable found by running which gcc on your PBP is in /usr/lib/distcc:
Now any C / C++ compilation on the PBP will be transparently offloaded to the non-PBP. You can verify this by observing the distccd output on the non-PBP.
If the non-PBP can't be reached (for instance, if you are away from your LAN, or the docker isn't running), compilation will be performed locally.
I've got a 2017 14" Pinebook with a 64 GB eMMC installed. When I got it, I put the standard Xenial Mate image to boot from eMMC and then didn't touch it for a while. I recently pulled it out and updated to the latest version of Mate available just through `do-release-upgrade`. But that seemed to break some things like the battery life indicator, so I decided to try to find a new image to flash instead.
First, I want to say that I'm pretty disappointed with the state of the wiki for the OG Pinebook. Lots of broken links and not very updated information.
After poking around looking for images to use, I decided to try out Armbian and Manjaro. I have tried the following images all with the same behavior:
Armbian_20.08.1_Pinebook-a64_bionic_current_5.8.5.img (pretty sure this was the headless server)
Anyway, on each of these I would see the bootloader start up. If I pressed space during this I'd be taken to the uboot cli. I could sit at that cli for however long I wanted. If I didn't interrupt the bootloader, I would see a splash screen for the distro pop up and after 15 or so seconds the screen would flicker and go black. Even on the headless image without the splash screen, it would go through the startup sequence and at about the same amount of time the screen would flicker and go black. The screen would occasionally light up like it was waking from sleep but then would go back to black. This would last indefinitely, I left it over night one time and it was still occasionally lighting back up just to go back to black periodically.
To make sure it wasn't a power issue I bought a new cable and a new power supply. To make sure it wasn't an SD card, I bought a couple new SD cards. As a last ditch effort I flashed the original Xenial Mate image from the wiki (xenial-mate-pinebook-bspkernel-0.7.28-136.img) and that booted up just fine. It also boots totally fine from eMMC into the original Xenial image I've update there and I can use it and leave it powered on without the screen going black and becoming unresponsive. I even tried booting from a recent Android image (android-7.1-pine-a64-pinebook-v0.3.5-r61.img - is that recent? I don't know) and that worked just fine.
I'm assuming there's something in the most recent kernel that is not compatible with the original Pinebook? Is this a known issue and is there anyone that knows what the latest version of the kernel I can use for one of these images is? I will start trying to find one on my own, but it would be great if someone already knew.
In trying to troubleshoot an unusable PPB I've just received, I bought a 64G MicroSD card to boot the Fedora 32 Xfce image. I'm partial to Fedora, and wanted something different from the Manjaro or KDE that is pre-installed for testing purposes. With dd the install was easy and Fedora booted like a charm. I've added only apps I needed, like Firefox and Geany to keep it simple. But even so, the operating system seems to think I have no space left on the MicroSD.
We have lsblk showing the MicroSD disk, mmcblk2, essentially full:
Code:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk2 179:0 0 58.2G 0 disk
├─mmcblk2p1 179:1 0 213.6M 0 part
└─mmcblk2p2 179:2 0 58G 0 part
mmcblk2boot0 179:32 0 4M 1 disk
mmcblk2boot1 179:64 0 4M 1 disk
mmcblk1 179:96 0 59.5G 0 disk
├─mmcblk1p1 179:97 0 213.6M 0 part /boot
└─mmcblk1p2 179:98 0 10.7G 0 part
$ sudo du -sh *
0 bin
134M boot
0 dev
28M etc
2.6G home
0 lib
0 lib64
4.0K lost+found
4.0K media
4.0K mnt
4.0K opt
du: cannot access 'proc/4494': No such file or directory
du: cannot access 'proc/4497/task/4497/fd/3': No such file or directory
du: cannot access 'proc/4497/task/4497/fdinfo/3': No such file or directory
du: cannot access 'proc/4497/fd/3': No such file or directory
du: cannot access 'proc/4497/fdinfo/3': No such file or directory
0 proc
3.3G root
9.5M run
0 sbin
4.0K srv
0 sys
40K tmp
3.5G usr
442M var
Your counting may be better than mine, but that doesn't look like much more than 10G. At the moment, the OS complains of lack of space, which limits my ability to do much. What am I missing here?
Any ideas much appreciated.
Kendew
I encountered this issue when I first received and tried to set up my Pinebook Pro, a little over a week ago. Life events have prevented me from revisiting it until now...
When I first started the PBP, I was presented with a screen to select a keyboard layout. As I have an ANSI variant, I used the arrow key to try to select it, but the system instead took me to the "create a user" screen. So, I typed in a user name and pressed "Enter," at which point the system reported "Configuration aborted. Restarting OEM script..." then clear the screen and print that message again.
Eventually I was able to get out of that loop using the left arrow. This would return me to the keyboard layout selection screen. At this point, I was able to select the ANSI layout but, when I pressed "Enter," the user creation screen flashed briefly, but then the system returned to "Configuation aborted. Restarting OEM script..."
I have powered the PBP down, and revisited it hours, a day, and a week later, just to see if anything would be different, but it isn't (not surprisingly, I guess)
I imagine this might be a software issue, and might be helped by working with a fresh image (which I may have some time to figure out in the next few days), but I also wondered if there might be something funky going on with the keyboard.
Has anyone experienced this behaviour and/or know how to resolve it?
I am really excited to try the PBP, but this month has been tough, and I'm feeling a little defeated at this point. Any help would be appreciated
Is there anywhere on the board where I would be able to tap into an I2C bus? Or does the board have any pads that are the equivalent of a 40-pin header with SDA/SDL pins/pads?
Hi Pine64 team, first of all I would like to thank you for your hard work, transparency with the community and wonderful products. I am a proud owner of 2 PBP (including 128gb edition) and will be getting my PineTab shortly. I have been trying to purchase PinePhone for Peru (I'm an American expat) but had issues with shipping and the pandemic (Can't order from AliExpress anymore). I was finally able to order the pmOS edition, but its retained in customs at the moment. I have provided them with the user manual, FCC ID, and the FCC certificate, hoping they will approve the importation, as I am the first person in Peru to import this particular model and Govt engineers need to review it. Now the government is asking me for more documents and I would really appreciate some help from the community and staff to get my device approved for use in Peru and imported. I plan on buying more if I can get this through customs and sell to my friends (I'm a Linux software developer) if the Peruvian government will add this phone to their "whitelist" of celular devices. If I don't provide the required information in 10 days, I will lose the PinePhone (they say can't return because of battery hazard, sounds like BS), my shipping cost, and the $40 fee I am paying to request approval for personal use of this device in Peru.
For the continuation of the approval process of the mobile terminal, you must attach: 1.- Simple copy of the technical manual of the equipment or device to be approved that contains the respective technical specifications, as well as the brand, model, name and address of the manufacturer, the aforementioned technical specifications being the following: - Range (s) of operating frequencies. - Maximum transmission power (s) per frequency range (s). - Wireless communication standard (s). 2.- IT IS RECOMMENDED to send a copy of the certificate or document stating the specific absorption rate (SAR) issued in the country of origin by a competent authority or internationally renowned laboratory. If you do not have what is requested in points 1 and 2, you can only tell us the FCC ID code of the consigned equipment. 3.- IT IS RECOMMENDED to send documentation from the manufacturer that proves that it has the Cell Broadcast or Cell Broadcast functionality, which allows it to be configured with the SISMATE parameters, according to Table N ° 2 “Selection of channels for receiving project alerts SISMATE ”contained in Number IV.1 of the Technical Annex of Ministerial Resolution No. 165-2019-MTC / 01.03. 4.- IT IS RECOMMENDED to indicate the TAC3 number assigned by the GSMA to your device, and that it corresponds to the brand and model, as requested.
Consequently, a period of 10 business days is granted for its correction; under warning of declaring your request inadmissible at the end of the term granted in case you do not send the requested information; In accordance with the provisions of article 10 of the limited regulation, it is also indicated that the presentation of false and / or adulterated documents will be subject to the corresponding legal actions (criminal complaint), in accordance with the rules on the matter .
So my understanding is that (1) should already be covered in the user manual, but I was planning on sending the PinePhone wiki page as a PDF. For (2) I already sent them the FCC + the FCC certificate. For (3) they says its "recommended" but I think its the real reason for the delay. I need some official document or update user manual from Pine64 that shows that the device emits in the specified frequencies (pretty sure it already does) and that is conforms to emergency broadcast protocols used for earthquakes, etc. If I can get a solution for (3) I am pretty confident I can get the device through customs, as 1 and 2 are provided in the wiki. Also it would help if the user manual can specify the business name and address, as well as the original manufacturer address and business name. This is not in the user manual currently. For (4) I don't have physical access to the device (retained on the coast, I live in the Amazon jungle near Brazil, no flights since March) so I don't have a way to get the IMEI number, but if there is a Org number for PinePhone (like IMEI prefix) that would help me a lot. With regards to the SISMATE in (2) you can read about it here https://portal.mtc.gob.pe/comunicaciones...ón2018.pdf , but I don't think Peru developed its own tech or anything, it probably an international standard for emergency broadcasts like all countries have. I've read that in Android there is an option to disable it so the govt forcing it is kinda useless anyways.
Original Spanish document, also attached other Spanish documents.
Code:
Señores : MILLER IV ALSEY COLEMAN RUC 15602987041 La entidad MTC ha enviado la notificación 2020122828 para la SUCE 2020440712 correspondiente al TUPA DGCSC-2 / Formato MTC001 Mensaje de la Entidad : Estimado señor(a): MILLER IV ALSEY COLEMAN De la evaluación realizada a la información remitida, se observa que su equipo corresponde a un equipo terminal móvil que realiza emisiones radioeléctricas, razón por la cual, deberá indicar si el equipo será para uso personal o comercialización, siendo para este último de acuerdo a lo dispuesto en el numeral 7.3 del artículo 7º del Decreto Supremo Nº 019-2019-MTC que modifica diversos artículos del Reglamento Específico de Homologación de Equipos y Aparatos de Telecomunicaciones, aprobado mediante D.S. Nº 001-2006-MTC, exigible contar con un título habilitante ya sea: concesión, autorización o registro de valor añadido o comercialización, otorgados por el Ministerio de Transportes y Comunicaciones. Por lo cual, para la continuación del proceso de homologación deberá indicar lo observado. Asimismo, de la evaluación realizada a la información remitida se verifica que los documentos “(Req-3) 4716874.pdf” y “(Req-0) 4716977.pdf” corresponden a una ficha de datos y la certificación del “Test Report” del equipo identificado con código FCC ID: “2AWAG-PINEPHONE”, el mismo que ha sido corroborado en el formulario de búsqueda de la FCC (Federal Communications Commission); cuyo modelo de equipo y datos (nombre y dirección) del fabricante difieren a lo consignado en su solicitud de homologación. Al respecto se precisa que los datos brindados deben ser por marca, modelo y datos del fabricante exactos contenidos en el manual técnico del equipo; además, no se adjunta documentación del fabricante que acredite que cuenta con la funcionalidad de Difusión Celular o Cell Broadcast, que permite ser configurado con los parámetros del SISMATE y número TAC. Por otro lado, de la evaluación al documento “(Req-0) PinePhone FCC SDOC Certificate-S19112602605001.pdf” corresponde a un certificado de conformidad del producto, el cual no es necesario para el trámite de homologación. Por lo tanto, de acuerdo con los literales b), c) y d) del numeral 8.1 del Art. 8º del Decreto Supremo Nº 019-2019-MTC y la Segunda Disposición Complementaria Modificatoria del D.S. Nº 038-2019-MTC, para la continuación del proceso de homologación del terminal móvil1, deberá adjuntar vía VUCE: 1.- Copia simple del manual técnico2 del equipo o aparato a homologar que contenga las respectivas especificaciones técnicas, así como la marca, modelo, nombre y dirección del fabricante, siendo las referidas especificaciones técnicas, las siguientes: - Rango(s) de frecuencias de operación. - Potencia(s) máxima(s) de transmisión por rango(s) de frecuencias. - Estándar(es) de comunicación inalámbrica. 2.- SE RECOMIENDA remitir copia del certificado o documento que consigne la tasa de absorción específica (SAR) emitido en el país de origen por autoridad competente o laboratorio de prestigio internacional. De no contar con lo solicitado en los puntos 1 y 2, puede indicarnos, únicamente, el código FCC ID del equipo consignado. 3.- SE RECOMIENDA remitir documentación del fabricante que acredite que cuenta con la funcionalidad de Difusión Celular o Cell Broadcast, que permite ser configurado con los parámetros del SISMATE, conforme a la Tabla N° 2 “Selección de canales para recepción de alertas del proyecto SISMATE” contenida en el Numeral IV.1 del Anexo Técnico de la Resolución Ministerial Nº 165-2019-MTC/01.03. 4.- SE RECOMIENDA señalar el número de TAC3 asignado por la GSMA a su equipo, y que corresponda en marca y modelo, conforme los haya solicitado. En consecuencia, se le otorga un plazo de 10 días hábiles para su subsanación; bajo apercibimiento de declarar improcedente su solicitud al término del plazo otorgado en caso no remita la información solicitada; de conformidad a lo dispuesto en el artículo 10° del reglamento acotado, asimismo, se le indica que, la presentación de documentos falsos y/o adulterados, será pasible de las acciones judiciales correspondientes (denuncia penal), conforme a las normas sobre la materia. Nota: Se adjunta las siguientes normas: Resolución Ministerial Nº 165-2019-MTC/01.03, Decreto Supremo 001-2006-MTC, Decreto Supremo N° 019-2019-MTC y Decreto Supremo Nº 038-2019-MTC. Asimismo, para la acreditación de la funcionalidad de difusión celular o cell broadcast que permite ser configurada con los parámetros del SISMATE, se adjunta formato sugerido que contiene información relevante, dicho documento deberá ser emitido por el fabricante del equipo. Atentamente, D.F.C.N.C. 1 Equipo que posee un IMEI por medio del cual se accede a las redes de las empresas operadoras, para acceder a servicios de telecomunicaciones de voz y/o datos. Esta definición no abarca a los equipos empleados para el Internet de las Cosas ni los utilizados para la comunicación Machine to Machine (M2M). 2 Según el Glosario de Términos del Reglamento de Homologación, un manual técnico se define como: “Documento emitido por el fabricante (...), que contemple funcionamiento, interoperatividad con la red y especificaciones técnicas del equipo o aparato a homologar. Asimismo, deberá permitir la identificación del fabricante, incluyendo el nombre o razón social, domicilio (…)”. Adicionalmente deberá mostrarse textualmente, la marca y el modelo del equipo solicitado. 3 Número TAC: Son los 08 primeros dígitos del código IMEI del equipo. El IMEI se obtiene de: 1) La caja del equipo. 2) Marcando *#06#. 3) En la configuración del equipo.
Apparently there is this insane requirement that the CEO or legal representative of the company has to sign a document confirming the device complies with the emergency broadcast requirements. This is the document that would need to be signed. I will provide an English translation:
MANUFACTURING COMPANY LOGO
NAME OF THE MANUFACTURING COMPANY
MANUFACTURER'S ADDRESS
This document certifies that the equipment (cell phone or smartphone) brand _______ and model ________, has the function of Cell broadcast or cell broadcast, also this equipment can be configured with the parameters of the Emergency Early Warning Messaging System - SISMATE , in accordance with the provisions of MINISTERIAL RESOLUTION No. 165-2019-MTC / 01.03, standard issued by the Ministry of Transport and Communications of the Peruvian State.
In this sense, the equipment can be configured according to the following channels defined by the Emergency Early Warning Messaging System -
Use / Channel
Local Alert: 4370
Local Alert (other languages): 4383
Information: 4382
Testing: 4380
Simulation: 4381
Reserved: 4396, 4397, 4398, 4399
Name and signature of the legal representative
Information OF THE MANUFACTURING COMPANY (Name, address)
