(11-08-2019, 05:52 PM)Arglebargle Wrote: RE u-boot: The script to patch u-boot on the eMMC is simple enough that it should just work, I don't think it's doing anything that would fail on chromeOS.

If for some reason it does fail I hacked a copy so I could flash to a specified device instead of the detected root; I used this to patch loopback mounted copies of ayufan's images so they're ready to use again if I need them. Just edit DEVID to point at the device you want to flash updated u-boot onto: https://pastebin.com/raw/EeK074XB.

You don't want to be working in crosh, either switch to the debug shell (ctrl+alt+f2) or drop to a proper shell from crosh by running "shell" and then switch to root. I usually just "sudo -i bash" as cronos (default password is "cronos") and away you go.

--

I tried the ChromeOS build out for a bit last night and it seemed to work well. Netflix video playback seemed significantly smoother compared to Linux, is there better support for hardware accelerated video here vs the Linux builds? My only real gripe with the experience was the touchpad, otherwise the PBP makes a pretty decent chromebook.

I've just ordered my pinetime devkit so it'll be a while before it arrives, but I was thinking the first thing we should probably do in common before we all go off to do our own things is develop a bootloader that will work in common with all our projects. It's all very well writing the flash via SWD with the devkits, but in the production version presumably we're going to need another way of writing the flash that doesn't involve opening the case.

The bootloader should be able to:

• Drive the display, bluetooth and SPI flash.
  
• Present a nice liveness/progress bar indicator during the boot process.
  
• Delay on boot, check if the button is pressed.
  
• If the button is pressed, enter "rescue" mode that will offer a serial console over bluetooth with xmodem (or similar) support to download a (compressed?) firmware image.
  
• Write any firmware image received to SPI flash, verify checksums.
  
• Check on boot if a new firmware image is available in external flash, if so write it to internal (memory mapped) flash.
  
• Protect the internal flash.
  
• Set the watchdog timer.
  
• Branch to whatever address we agree the kernel entry point should live at.
  

Hello to all

Unfortunately, for RealVNC server is no install package available, so I#m looking for a SW to access my Rock64 desktop over the internet.
It should be something cloud based and not a port release.
Teamviewer? 

Any suggestions?

I purchased a "Pinebook Serial Console" from the Pine Store to use to debug my Pinebook Pro's boot process. It seems to work fine on the USB side, but on the Pinebook side it's got some serious issues.

1. If I try to boot the machine with the cable plugged in, uboot does its thing, says it's starting the kernel, and then nothing ever happens again. No serial output, no video, no network presence. (If I yank the cable, right after making a selection, before it finishes loading the kernel, everything boots fine from there, and I can plug it in after boot completion and hit enter for a login prompt.)
2. If I plug it into a running "default Debian+MATE" system, I get errors on the kernel log about SDIO screwing up, and WiFi dies. (If said system is booted from an SD card, it also loses communication with the card and does what any Linux system does when you yank its root filesystem away.)
3. If I leave the cable plugged in during a reboot (not a cold boot), uboot fails to read the SD card and hangs—with or without an SD card plugged in.
4. Even when things are otherwise working, the connection is very unreliable. If the PBP outputs too quickly, vast quantities of output are dropped. This happens both in Linux and uboot. If I do an ifconfig, for example, I get the first line and a half or so okay, followed by mangled snippets of the remainder. And nmtui is completely unusable.

The wiki does mention that some of these cables render the PBP unbootable, but I didn't see any previous mention of this on the forums. I assume that previous discussion of this problem has happened in other media.


First messages from the kernel log after WiFi dies an untimely death:

I want to use Moeditor. I downloaded its 7z package, installed pk7zip, and unpacked it into its own directory.

How do I now install it? There is an executable Moeditor file in the directory.

Thanks.

Did any other friends receive a PBPordered in early September?
I ordered it on September 3rd and haven't received it yet.
That's the response I got.

Quote:Thanks for your message.
After checked with our production team and dispatch team, they informed us that the shipment date for Pinebook Pro will be delayed due to there was several units of Pinebook Pro are need to rework by the manufacturer.
We will get back to you again when the manufacturer release the new stock.

Quote:Thanks for your message.

We apologize for keep you waiting again, the manufacturer was given the time frame for new stock release is around 2-3 weeks.

Plugged in after receiving PBP and ran updates and then left alone to charge all day. 
Computer reported battery actually draining but charge light is on . 
Used both the original charger and USB-C separately in the last 24hrs. 
now battery is at 0% and PBP wont start on even in main power.
any suggestions?


UPDATE:
Computer finally powered back on after leaving on main for 10min
Back light on screen keeps going out


opened PBP
reset the battery plug
and clicked reset button on mother board.

still no joy. 
Making support ticket.

Here they are

Here is quick chat I had with Marius who called me from a PinePhone.

I've recently spent a little while hacking together a quick 'n dirty Debian installer for the Pinebook Pro.

https://github.com/daniel-thompson/pineb...-installer


It is not a fully fledged installer... just some code that run on the Pinebook Pro itself using an existing Debian (or maybe Ubuntu) distro. It will install an operating system from scratch to an alternative media. Nevertheless it is a "real" installer in that sense that there is no downloadable image, no default password and you get to choose the keyboard layout, locale, timezone and desktop environment for yourself!

It uses upstream Debian packages for everything except the kernel and bootloaders. Actually... on that subject I deserve no credit for the kernel (which is the v5.4 close-to-mainline kernel that @tsys has has been hacking on) or the bootloaders (which are simply the binaries from @Mrfixit2001 's update repo).

So far I have only used it to author SD cards (from a distro running from eMMC) however it has been tested with the eMMC disabled so we can be confident the bootloaders work. That means that, in principle, it is also suitable for installing to eMMC when running from SD card. I've also only tested text mode and the Gnome desktop environment (wayland, panfrost, gnome 3.34).

One interesting feature of this installer is that it is trivial to switch from arm64 (default) and armhf (add ARCH=armhf to the make command line). This allows you to run identical distros with the two different instruction sets... which could make for some interesting benchmarks if someone wants to make them.

Check out the Pine64 wiki for feature status, known issues and workarounds.