The Pinephone Thread

Hardware Adaptation
#41

No, never had a problem to wake the phone.
Did you remember to wipe the boot areas of both the eMMC and the SD card (if you use one)?

Current setup:

  • SailfishOS upgraded to 4.5.0.24 (with ssu)
  • latest package of everything upgraded with zypper
  • installed boot firmware: rk2aw + primary: U-boot + Rockhip’s proprietary ddrbin +secondary: U-boot with opensource initialisation, using the version mentionned in this Megi’s log entry
  • modem OS: a preview of version 0.7.5 that fixes “Stuck message” SMS (it’s in the matrix channel, not yet on github) (flashed with fastbook, as fwup lags behind — it’s still at 0.7.2)
  • wif, etc.: the firmwares that comes in package firmware-pine64-pinephonepro, I haven’t customized anything. (I get the same “failed to suspend related to wifi”).

The only suspend-related problem I have is after wake-up, the world camera not working anymore in Shutter

Just for completedness:

  • rk2aw is just the tiny “bootloader manager” that allows you to select between primary and recovery bootloader with button presses, and which changes the prioriy order where you load U-boot from(*)
  • the bootload that helps with sleep and power is the variant of U-Boot(*) that works with Rockchip’s proprietary ddrbin.

(*): Tip for new users - you might have some left-over U-Boot installation on your eMMC or SD card, and be unintentionally booting from that (e.g.: I had the old Manjaro’s U-Boot left over on the eMMC, and after installing rk2aw, the Pinephone Pro started booting from that if I didn’t use the button to select the primary boot, which led to tons of weird behaviour in SailfishOS, like ghost presses of the volume buttons).

One way to check is what is displayed on the screen. Megi’s U-boot distributed together with rk2aw displays a boot menu with big blue buttons letting you chose between booting SFOS from the eMMC partition, sharing eMCC as a USB drive, console and poweroff. Most U-Boots on ppp don’t use display output (e.g. the original TowBoot flashed on SPI at the factory). If you get the graphical menu only when using button presses, that means the rest of the time you are booting some left-over bootloader.

#42

But do you have suspend enabled?

Yes, this is true; though it does ship one as you also say…

Good tip! So this would have been included in the image that i get from flash-it.sh installing to eMMC?
(No SD card here).
My google-fu fails me; how would i wipe the bootloader from there?

So you are saying you needed option 2 instead of 1 until that was sorted? Strangely option 2 gets me a very stock looking U-Boot, with submarine and brown buttons.

Edit: Wohoo! Boot option 3 gets me suspend. (Same stock-looking U-Boot menu though).

#43

I threw 30MB worth of zeroes at the first partition of eMMC.
Now options 1 and 2 doesn’t boot anymore. And suspend is borked on option 3.
Reflashed all the parts that came with rk2aw for good measure - no change.

#44

Hopefully the first 30mb of block device, and not the first partition? :slight_smile:

#45

Of the block device; where i had as part of my clearing it created a partition.
Now removed - no change.

Edit: now with 30MB zeroes on the actual device, i have suspend back - and use of option 2 as well.
Option 1/default still doesn’t start.

#46

have you re-ran the rk2aw scirpt? it should write to the emmc iirc

#47

Now i have. No difference unfortunately.

#48

Yes, works for me.

Flash-it doesn’t touch the bootloader, it leaves whatever is there.
On Rockchips like the PinePhone Pro’s RK3399, it resides on some freespace (starting at sector 64) before the first partition (that’s why it’s not getting overwritten by flashit: it exists in a part of the eMMC that doesn’t hold any data, thus even when changing the partition scheme, flash-it doesn’t touch it).

  • On DOS-style partitioning like Flash-it does, it’s tricky to access that area (you need to directly write on some sectors of the whole block device using 64 as an offset) (*).
  • On GPT-style partitioning (like the factory installation of Manjaro uses), you can create a special partition starting from the sector 64(**) up to the boot partition, using special type “BIOS boot”, then you just “fstrim” that partition.

(*): you use dd’s seek= option to skip to sector 64 (and leave the partition tables intact), and count= to limit it to sectors before the first boot partition, and not destroy it.

(**): It’s not possible to create a partition that covers this area in DOS patition tables, such low sectors aren’t allowed, only GPT allows these partitions. You would need to hex-edit the partition table by hand to produce such a monster.

Yup, the “stock-looking U-Boot with submarine and button menu” is what ships packaged together with rk2aw.
When you run spinor-flash-initial-setup.sh to setup rk2aw and evevrything the first time it will:

  • always flash the ddrbin Rockchip’s proprietary blob in the primary bootloader (option 2).
  • if you pass it option foss it will flash the opensource U-Boot initialisation on the fallback (option 3) otherwise will default to also flash the ddrbin blob there too.

How exactly did you write the zeros?
The proper way would be to use dd, with seek and count.
flash-it will create a boot partition that starts at the 32MB mark (you can double check with fdisk -l)
firmware tend to be <16MiB in size (the second stage of U-Boot start at sector 16’384, i.e. at the 8MiB mark)
This will zero ~15MB of storage (good enough to cover the second stage, while really away from the boot partition) starting at sector 64 (where the first stage of the boot loader either ddrbin or the opensource initializer of U-Boot):

# double check where the partitions start and that boot starts after 64+30000 sectors.
fdisk -l /dev/{{your eMMC}}

# zero sectors after the partition table and before the boot partition
# it needs to cover sector 64 (stage 1, the initializer) and 16384 (stage 2, the main part of U-Boot)
dd if=/dev/zero of=/dev/{{your eMMC}} seek=64 count=30000

Again, on DOS partition tables, dd is the only way to reach sector 64 (where Rockchip’s BROM looks for a stage 1). Unless manually hex-editing, you’re not allowed such a low starting number for a partition.

If you have an SD card installed, you might need to do that on the card, too (depending on what was flashed on the before - some linux Sd images come with a bootloader embed in there. Two-Boot wouldn’t have picked that up, rk2aw would (that’s the whole point) ).

The whole point of rk2aw is to make the phone behave like an oldschool PC where if you but a floppy in drive A:, the boot sector is loaded from there, hard-disk C:'s bootsector is only loaded if drive is empty.

So as long there are things elsewhere than the SPI (e.g. in the sector 64 of either eMMC or SD card), those will be booted instead of the SPI - (just like an oldschool PC will always try the floppy if there’s one in the drive).

Edit:

I am trying to understand: what’s your current setup?

  • You’ve flashed rk2aw + U-Boot to the internal SPI NOR.

But where are you booting SFOS from?

  • The eMMC, that you accessed over USB (either using the volume button combo of Tow-Boot, or using the graphical button menu of Megi’s U-Boot ?)
  • The SD card, that you plugged in a card reader when running flash-it ?
  • You did something more artisanal ( ← I’m guitly of that)
1 Like
#49

spinor-flash-initial-setup.sh doesn’t touch the emmc at all.
As the name suggest, it flashes stuff on the SPI NOR chip.

The basic PinePhone doesn’t have a special firmware chip and boots straight from SD card (then on eMMC).
The first batch of PinePhone Pro had an empty SPI NOR flash, so the bootrom of the RK3399 moved on to the next device and searched a bootloader on the eMMC (then on the SD card).
Current batches of PinePhone Pro have Tow-Boot on SPI NOR flash, and always boot Tow-Boot, unless you re-flash something like rk2aw on the SPI NOR fash.

1 Like
#50

Who else with a PinePhone Pro is affected by the “Back/World camera doesn’t work after suspend anymore” bug in Shutter?
Could you try if this successfully bring the camera back working:

echo ff920000.isp1 | sudo tee /sys/bus/platform/drivers/rkisp1/{unbind,bind}
1 Like
#51

Oh, those were the days. When piqued by some odd behaviour of macos, pull out a netBSD boot floppy and toy with the idea of turning the macintosh into a … mail server.

1 Like
#52

Just out of interest, does SailfishOS on the Pinephone support VoLTE?

I’m asking this because for Ubuntu Touch, the Pinephone is the only (?) device that supports VoLTE because as far as I can understand it is easier to implement on it…?
That’s why I’m curious if this also applies to SailfishOS

#53

I dont actually know … but … if you can tell me how its implemented in UT, id love to have that working … not really any reasons it cant

2 Likes
#54

A preliminary quick test looks like it is working for me out of the box. The indicator stays on 4G during the call, though mobile data isn’t working, so speed testing is one double check i cannot do right now.
The VoLTE setting from here was already set, and the two lines that are supposed to show a “1” in the fourth position during the call remains - though 2 new ones appear, one of which has a “0”. :person_shrugging:

1 Like
#55

After some more talking to @piggz on the IRC channel, i think we can now say with good certainty that VoLTE does indeed work. (On our operators at least). If i disable VoLTE, i get booted back to 2G, and this shows very clearly - so when it says 4G during the call i’m inclined to trust it.

5 Likes
#56

See my writeup Sailfish, Pinephone and VoLTE | piggz.co.uk

5 Likes
#57
#58

I have updated the PInephone/Pro version of ofono to include a patch which better handles the modem disappearing/reappearing. Its still a bit of a hack, it seems to work well enough, and is a big part of making the pinephone suitable as a daily driver. If you can, please try it out and feedback Adam Pigg: "Have made a slightly less hacky release of Ofono …" - Fosstodon

3 Likes