With some issues of suspend, I noticed that hibernate is not an option on the default Debian OS.
Using flash drives, either eMMC or NVMe, returning from hibernate is pretty fast.
On implementation, I've always used hibernate with dedicated swap partition. That's not in the default Debian OS. Easy enough to fix.
Anyone interested in hibernate?
Or hybrid-sleep?
How does hibernate work with swap file?
Note: hybrid-sleep is a combination of suspend for a set time, and if not restored to full power on, automatically hibernate. The hibernate image is written at the beginning of hybrid-sleep. If battery power dies suddenly during the suspend phase, you still have your hibernate image to resume to.
I used an external USB 3.0 hard drive to both apply an additional power load on the system and to offload compilation writes (decrease writes to eMMC).
In summary:
The PBP performed well, no lockups or freezes experienced.
The max SoC temp measured during make -j6 was 74 degrees Celsius, within recommended operating range.
The SoC/GPU temperatures do differ throughout operation (to my surprise).
Data indicates that under kernel compilation with external hard drive attached, the battery does not discharge while attached to the DC power supply.
Subjectively, although the bottom of the laptop did get very warm it was not uncomfortably so. I did not think to measure the case temperature with anything other than my fingers.
UPDATE 02 DEC 2019:
The tools used to run the compile test can be found here:
Really enjoying my PineBook Pro, I don't mind working around a few niggles here and there and I appreciate the hard work that has gone into this (and is still going into this!). It's genuinely a lovely device.
I have just one issue that's a show-stopper: A key cap (or is it 'keycap'?) has fallen off, for no obvious reason, and I can't work out how to refit it. It's not had much use and I'm not a keyboard thumper, so it's a bit disappointing, but enough moaning - how do I get it back in place?
The scissor-type mechanism is still attached to the underside of the key cap (see attached image), and I can see that a part of it must slide under a metal hook-type piece on the keyboard... but I can't figure out how to manage that.
Has anyone else had to do this? Please help!
I know some people were planning to move their key caps around, instead of waiting for the ANSI keyboard I assume - anyone done that yet? If so, shout up.
If it's not possible to refit it (& I really hope it is!), is this a warranty-type situation?
Thanks, all, for your help.
Bicko.
Just wanted to give the Pine64 team a big thank you for making a computer that is fun for me again, in the sense of the hardware and OS (ARM is pretty new to me...not counting that one I ignore in my phone). There have been a few in my life...my first Amiga 1000, the first time I built a MP computer for Linux (Mandrake) and this little Pinebook Pro. Part of the fun is figuring out for yourself what you can get to work and navigating its quirks and attributes, but a big part of the fun is the anticipation of seeing what the community can do with it.
I know at $200.00 this is not a profit making enterprise, so thank you for producing a a device for and about the community.
I lose audio output whenever I reboot my PBP. I've gone through sound preferences, hardware, speaker options, tried different profiles and tested them. Currently "stereo output and stereo input" puts sound out. If I reboot, I no longer have sound even with the same profile I selected earlier. I have to go back to sound preferences and try other profiles. How can I get sound on the PBP consistently without changing the profile?
Just wonder if there's any guide on how to read the console via UART?
I've done everything written in the wiki:
1. Bought the USB to DB9 cable.
2. Soldered a 3.5mm audio jack to it (pin 2 - to the tip, pin 3 - to the ring, pin 5 - to the sleeve).
3. Switched the UART toogle on.
4. Plugged everything in.
5. Ran screen /dev/ttyUSB0 1500000.
6. Powered on the PBP.
7. Saw nothing.
I don't have yet my dev kit, but I have just started to check for the current status.
Am I wrong if I say that there is no official project for now and people are testing things/setting up their dev setup on their side ?
Look like the most advanced project is Lup Yuen Lee's rust project (https://twitter.com/MisterTechBlog), but he seems to not use this forum.
So maybe this project is kind of official ?
I was first very surprised to see he is working in rust language.
I always thought that rust is a very good language but not for IOT because of the code size and lack of full control. (just compare a hello world in rust and C (in release mode) and check the code size). After few research I saw that this big size come from libraries that are statically linked. In barre metal we dont use external library like libstd, so we are fine.
But I then dont have an answer to my question: is rust code bigger than C ? If yes is it acceptable ?
I have nothing against rust, it can be an opportunity to learn (I like the philosophy behind rust, and I have planed to learn it in the future), but when doing IOT stuff it's better to have full control on what we are doing. And in C you can understand what is happening in low level (assembly code). I suppose I wont be able to do that in rust.
Also in C you have full control of the FW size and of your structure. Is it also the case in rust ? I read in the net that Rust references can be fat ...
One argument of Lup Yuen Lee to use rust is that, rust protect us on memory corruption. But on very small system it's better to avoid use of heap (malloc/free). You dont need that. And you may even end up by fragmenting your few RAM because of different size object allocation.
And in rust if you use things like map or vector, are you then indireclty use the heap ? If yes, is there any issue on RAM fragmentation ?
One more thing: There is 512KB of ROM. In case of FW update which I suppose has to be done via bluetooth., where can we save the blob we receive ? We may have to split in 2 the ROM, right ? If it's the case then the FW code has to fit in 256 KB (less if we count the bootstrap). Is the rust code able to fit ?
Or maybe you prefer to have a smart bootloader with DFU and bluetooth inside the bootloader ?
Again I have nothing against rust, and will be happy to learn it sooner that I was expecting, but then I would like to know if someone is comfortable enough to handle this kind of issue ?
