(08-27-2019, 01:52 PM)sjk Wrote: It seems like the current mrfixit default OS supports nearly all the functionality the PBP has to offer. Is it a armhf image or an arm64 image? I require an arm64 image for some work that I am doing, and would like to know if there is a arm64 variant that supports all the PBP's features?
This is an armhf image. There are 64bit images avaialble, they just happen to perform worse in desktop applications (my understanding is this is due to RK drivers). You can obviously use them, but will have to go through all the the trouble of getting everything setup and working by yourself ... or with other people interested.
Now, we will soon be seeing desktop mainline image with Panfrost open video drivers; I am pretty certain all these images will be 64bit.
(08-10-2019, 06:04 PM)Luke Wrote: I encourage you to always use FN+ESC [Zz] to suspend the Pinebook Pro
Why? Does that do something differently than closing the lid?
(08-27-2019, 02:31 PM)binarian Wrote: (08-10-2019, 06:04 PM)Luke Wrote: I encourage you to always use FN+ESC [Zz] to suspend the Pinebook Pro
Why? Does that do something differently than closing the lid?
Sometime an application will prevent suspend from initiating - this is very rare, but I've seen it happen (not specific to the PBP for that matter). So, you better off using the key-combo to make sure its actually in suspend since you can't really determine that with the lid closed ...
08-27-2019, 02:55 PM
(This post was last modified: 08-27-2019, 02:58 PM by Der Geist der Maschine.)
(08-27-2019, 02:39 PM)Luke Wrote: Sometime an application will prevent suspend from initiating - this is very rare, but I've seen it happen (not specific to the PBP for that matter). So, you better off using the key-combo to make sure its actually in suspend since you can't really determine that with the lid closed ...
You write a little bit earlier in this thread " LED blinks on disk activity / turns red in suspend". Is this LED not visible when the lid is closed?
Update: Ok, I spotted some leds and they are not visible when the lid is closed.
Never mind.
Yea, unless you're in a dark room and really peek at an angle, you wont see that red LED. Also, in a dark room you probably would see the LCD on, but if you check after ~10 min and the LCD has gone to sleep you have no way of knowing the laptop is actually up and running and consuming power.
Thats said, from testing 99% of time suspending by closing the lid works
Update 30/08/219
*Changed boot sequence giving SD priority
Notes: This is an important update - uboot got patched to look for extlinux in /boot partition on SD card before booting off of eMMC. This means that SD now has boot priority on the Pinebook Pro, allowing you to try out builds without Commiting as well as easy flashing (dd) of eMMC from a SD booted OS.
(08-30-2019, 02:21 AM)Luke Wrote: Update 30/08/219
*Changed boot sequence giving SD priority
Notes: This is an important update - uboot got patched to look for extlinux in /boot partition on SD card before booting off of eMMC. This means that SD now has boot priority on the Pinebook Pro, allowing you to try out builds without Commiting as well as easy flashing (dd) of eMMC from a SD booted OS.
From where does uboot run - the spi flash or the eMMC flash?
From whereever uboot runs, what if we mess it up? Is it theoretically possible to render the Pinebook unbootable?
Will this new uboot be part of the first batch?
(08-30-2019, 11:47 AM)Der Geist der Maschine Wrote: (08-30-2019, 02:21 AM)Luke Wrote: Update 30/08/219
*Changed boot sequence giving SD priority
Notes: This is an important update - uboot got patched to look for extlinux in /boot partition on SD card before booting off of eMMC. This means that SD now has boot priority on the Pinebook Pro, allowing you to try out builds without Commiting as well as easy flashing (dd) of eMMC from a SD booted OS.
From where does uboot run - the spi flash or the eMMC flash?
From whereever uboot runs, what if we mess it up? Is it theoretically possible to render the Pinebook unbootable?
Will this new uboot be part of the first batch?
eMMC. You can flash it to the SPI at your own risk (there currently is no safe way of flashing it, so not advised).
On first boot just connect to WiFi and run the updater - it will fetch the new uboot. This is risk free - if something breaks, you can reflash.
(08-30-2019, 01:38 PM)Luke Wrote: (08-30-2019, 11:47 AM)Der Geist der Maschine Wrote: (08-30-2019, 02:21 AM)Luke Wrote: Update 30/08/219
*Changed boot sequence giving SD priority
Notes: This is an important update - uboot got patched to look for extlinux in /boot partition on SD card before booting off of eMMC. This means that SD now has boot priority on the Pinebook Pro, allowing you to try out builds without Commiting as well as easy flashing (dd) of eMMC from a SD booted OS.
From where does uboot run - the spi flash or the eMMC flash?
From whereever uboot runs, what if we mess it up? Is it theoretically possible to render the Pinebook unbootable?
Will this new uboot be part of the first batch?
eMMC. You can flash it to the SPI at your own risk (there currently is no safe way of flashing it, so not advised).
On first boot just connect to WiFi and run the updater - it will fetch the new uboot. This is risk free - if something breaks, you can reflash.
Looking at Mrfixit's update script it's not obvious that uboot is updated as well. Good to know.
Risk free? What if uboot does not get properly flashed onto the eMMC? On next boot, it may start and then "die". Then, there is no way to recover the system, is there? One needs an eMMC reader to reflash the eMMC card on another computer.
It's Rockchip's design mistake to have the stage 1 loader prioritize eMMC over SD.
@ Der Geist der Maschine Right, let me qualify that. If you update uboot and something goes wrong, then its not like messing up BIOS or even GRUB on a standard PC. In fact, its likely that you'll be able to reflash uboot again to the same eMMC using some method we'll dream up (likely some autoscript running from SD like ayufan did for the Rock64/ Pro). And if all goes wrong, then you can still pull data off of the eMMC module by either booting from SD and mounting the rootfs partition of the eMMC or removing the eMMC drive and pulling data from it manually using a USB->eMMC adapter.
And yes, I too find the design choice of Rockchip to have eMMC boot prior to SD a bit peculiar.
|
